Transcript Early Media Authorization

Early Media Authorization
Under what conditions should negotiated media
flow prior to 200 OK (INVITE)?
Richard Ejzak
1
What RFCs say about Early Media
Some RFCs assume (early) media can flow immediately upon
signaling SDP
– According to signaled directionality (RFC 3264)
– When preconditions met (RFC 3312)
– No exceptions described for early media
Other RFCs describe conditions in which early media will not
be rendered
– RFC 3261: 180 Response “may be used to initiate local
ringback”
– RFC 3960:
• May not render multiple sources during forking
• “A UAC should develop its local policy regarding local ringing
generation”
2
What the PSTN says about early media
“Answer” is usually the trigger to begin billing
Users don’t expect to be billed for unanswered calls
Networks don’t allow users to exchange data before “Answer”
The terminating switch usually “cuts through” media to called
party on “Answer”
The terminating switch provides “call progress” early media to
the calling party
There is no “terminating switch” to police early media in a
typical SIP network
How do we know if early media is being exchanged with an
authorized network entity or an end user?
3
Some Applications of Early Media
Play custom ringing tone (CRBT)
Play network announcements
– Error messages
– Forwarding
– Queuing, etc.
Prompt and collect add’l dialing info
To confirm availability of media path
4
Local Policy options
Some implementations disallow early media:
– Before receiving SDP answer (to verify target contacted)
– Before receiving 200 OK (INVITE) (to provide alternate/local
alerting indication)
– From RTP source address other than remote RTP destination
address (can cause clipping or total media blocking)
– To render alternate call progress info (CRBT)
– To render alternate media/dialog (forking)
– When media capabilities limited (e.g., parallel sessions)
– To give priority to Alert-Info header media
– To give priority to early-session media
– To prevent potentially fraudulent exchange of user data when
billing starts with “answer”
5
What media to render prior to “answer”?
Local ringback upon receipt of 180 Response
Alert-Info header media
Early media
Early-session media
Media from alternate dialogs
Unclear how to prioritize these various sources
Flexibility of local policy needed
6
How to turn off unwanted sources?
Muting of media
– Call HOLD (a=sendonly)
Black hole address (zero address in offer)
Preconditions
Blocking (gating) of media
– Only network option when serving end user SIP device
Accept media packets but do not render to user
7
Problems with muting
How do we know the offerer’s intention?
– Do we alert a user when receiving inactive or sendonly
offer?
– What resources do we reserve for the session?
– How does answerer know that HOLD will be immediately
removed at 200 OK (INVITE)?
– Black hole address better
• Cannot confuse user’s intention
How do we know whom to mute during forking?
More media clipping than with media blocking
8
Problems with blocking
Interactions with RTCP
– Should not expect accurate reports on traffic prior to 200
OK (INVITE)
Interactions with ICE
Can’t identify sources during parallel forking
9
RFC 3960 Recommendations
Early media takes precedence when present
Otherwise render ringback/Alert-Info/early-session
until media appears
Other procedures allowed based on local policy
– For example SIP-I uses early media exclusively
Recommended procedures breaks down
– During parallel forking
– When desire higher priority for alternate media (e.g.,
CRBT)
– When need to control sources of early media due to billing
policies
10
draft-ejzak-sipping-p-em-auth-01
focuses on narrow problem
Applicable only to private networks with transitive
trust model
Network able to perform media blocking (gating) near
UAs
Identifies authorized sources of early media to avoid
blocking
Works well with RFC 3960 since authorized early
media always passed and takes precedence
Significant objections raised since UAS does not
know when early media blocking occurs
– Network may block without the header
– No guarantee early media will be rendered
11
Header Definition
 P-Early-Media=sendrecv – both way media allowed





12
=sendonly – backward media allowed
=recvonly – forward media allowed
=inactive – no media allowed
Sent from UAS to UAC to indicate authorization for early
media
Proxies can modify for security or policy reasons
Indication that backward early media is authorized using
“sendonly” or “sendrecv” also indicates remote end will
provide call progress media that should be rendered
Indication that backward media not authorized shown using
“inactive” or “recvonly”, also indicates that local end should
render another source
May send in initial INVITE to indicate support of header
Rejected Alternatives to draft
Use option tag in Required header to indicate that early media
authorization procedures may be used
– UAS may request early media but may not get it
Use option tag in Required header to indicate that early media
will be blocked
– Prevents network from implementing policies based on
information in responses (must decide up front)
• Transitive trust model (making authorization decisions based on
knowledge of next hop server) may not apply outside of network
Calls using either approach will fail unless UAS upgraded
(no incentive to upgrade outside of private network)
Either modification effectively prevents private network from
using extension to control access to early media
13
Blocking at the private network border
The header is not strictly needed if blocking policy is
implemented at the place where the policy decision
is made
– e.g., at the network border (SBC)
– So why is it so controversial?
Header allows use of existing media control point in
networks like IMS (at P-CSCF)
Header enables interconnection without SBC
between trusted networks implementing different
early media authorization policies
14
Additional problem to be solved?
Provide means for UAS to discover if early media will
be rendered
– So UAS can consider using alternative procedures when
early media unavailable
Would solve existing problem separately from early
media authorization
– Should allow existing draft to proceed
Provides incentive for UAs requiring availability of
early media to implement new extension
15