Early Media Authorization Under what conditions should negotiated media flow prior to 200 OK (INVITE)?

1. Early Media AuthorizationUnder what conditions should negotiated media flow prior to 200 OK (INVITE)? Richard Ejzak

2. 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”

3. 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?

4. 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

5. 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”

6. 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

7. 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

8. 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

9. 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

10. 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

11. draft-ejzak-sipping-p-em-auth-01focuses 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

12. Header Definition • P-Early-Media=sendrecv – both way media allowed =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

13. 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

14. 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

15. 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