90 likes | 199 Views
Coping with Early Media. Brian Stucker Nortel Systems/Standards Architect November 6th, 2006. Overview of Draft. Identify common problems with early media in SIP: Identify common ways that proxies and endpoints deal with early media
E N D
Coping with Early Media Brian StuckerNortel Systems/Standards ArchitectNovember 6th, 2006
Overview of Draft • Identify common problems with early media in SIP: • Identify common ways that proxies and endpoints deal with early media • Identify a set of requirement boundaries that any changes to the protocol should fit within • Identify a set of recommendations to start working the problems
Problems with Early Media (non-exhaustive) • Signaling path and media are disconnected • Clipping • No correlation b/w signaling and media stream • “SDP in a bottle” • SDP offerer must render all media streams sent to it • Untrusted data may be sent prior to answer • Forking interactions • Mob of media streams can result • Offerer may have little or no control over where media streams are coming from
Types of Early Media • Pre-routing • Triggered by proxy prior to routing step via SDP. • Pre-presentation • Triggered by proxy after initial routing step, but before forwarding INVITE to next hop via SDP. • Post-presentation • Triggered by subsequent hops after proxy has forwarded request (includes forking) via SDP. • Non-SDP • Triggered (typically by an end-device) through SIP signaling (Ex: Alert-Info header).
Coping Mechanisms • Proxy SDP manipulation • Stripping/Delaying – SDP answer is manipulated in 18x responses. • Weighting – May be used in conjunction with stripping/delaying to allow early media it prefers to be presented. • Client Forking Detection • Client may ignore early media once forking is detected • Client Slow-Start • Client makes potential early media generators the offerer.
Problems w/ Coping Mechanisms • Proxy SDP Stripping/Delaying – • Clipping • Fake forking may confuse client • PRACK • Breaks other early media • Proxy SDP weighting – • Breaks other early media • Client Forking Detection – • Breaks early media either all the time, or in a semi-random manner • Bad interaction with fake forking. • Client Slow-Start • Clipping • When multiple SDP offers are received, no idea which one ‘wins’.
Requirements Identified • Cannot deprecate forking from SIP. • Cannot deprecate early media from SIP. • Elimination of blind rendering of media packets by SDP offerer. • Creation of a mechanism by which an originating SIP UA can signal early media acceptance outside of codec negotiation/preconditions. • Creation of a mechanism by which a terminating SIP UA can signal the rendering requirements of early media. • Backward-compatibility is secondary goal, some clients will never get fixed (e.g. interworking). • Mechanisms must be able to deal with recursive forking scenarios. • Mechanisms must not require exchange of packets on the media path due to common gating mechanisms.
Draft Recommendations • Recommendations included are intended to START conversation. • Early Media Classification and Prioritization. • Provide a means of signaling what the early media might contain and how important it is that it be rendered. • Exact mechanism is left open. • Early Media Flow Negotiation • Provide a means of signaling that a particular endpoint is ready or not to begin sending/receiving early media and an identifier for the RTP packets. • New emflow SDP attribute defined. • Need more investigation into how SRTP specification in SDP, key exchanges and operation with early media should work.
Desired Result of Draft • A set of procedures that fixes early media to a large extent, or at least makes it more predictable without major deprecations to the protocol. • In cases where fixes can’t be made without major changes: • A clear, one-stop-shop explanation of what is fundamentally broken and why it can’t be fixed. • Recommendations on the best way to deal with early media in these cases that causes the least interruption to other parts of the protocol. • Discouragement of egregiously bad behavior that is likely to break other things. • SIP is complex. Having a reference to guide implementers and other SDOs is a good thing™.