1 / 5

Early Media Indirection (EMIND)

Early Media Indirection (EMIND). Brian Stucker Nortel Systems/Standards Architect March 8 th , 2007. History/Mechanism. Draft proposes a thumbnail solution to early media for consideration/discussion by the working group.

sook
Download Presentation

Early Media Indirection (EMIND)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Early Media Indirection (EMIND) Brian StuckerNortel Systems/Standards ArchitectMarch 8th, 2007

  2. History/Mechanism • Draft proposes a thumbnail solution to early media for consideration/discussion by the working group. • Next step from draft-stucker-sipping-early-media-coping-03 which identified various problems that exist within SIP for early media today. • Mechanism uses secondary dialogs to specifically handle early media. • URL supplied via new header “Early-Media” in response message. • Discrimination of early/final media streams handled by using a unique dynamic RTP payload for early media endpoints. • Endpoint can switch over to next media stream when it detects a change in payload type to the preferred media stream, or additional “Early-Media” URL in SIP provisional. • Alternative to RFC-3959. • Minimal new protocol requirements.

  3. User A supports emind, calls B. Receives Early-Media header in 180 w/ URL. Proxy inserts Early-Media header. Generates secondary dialog to Early-Media URL. Uses unique RTP Type for media to detect final media later. Early media flows to user. User B answers, begins speaking. User A detects RTP arriving with “final” RTP type. Switches to final media (no clipping). User A ends dialog with early media endpoint.

  4. RFC-3959 (Early Session Disposition Type) • RFC uses overlapping SDP offer/answer exchanges in the same dialog. • Any implementations of this technique? • RFC mentions using a separate dialog. • RFC contains a list of advantages it has over the separate dialog approach: • It is simpler • Lack of synchronization problems, all early dialogs terminated upon session acceptance. • Does not require GRUUs. • Does not introduce service interaction issues related to services that may be wrongly applied to the new dialog. • Easier firewall management.

  5. Comparison to RFC-3959 • 3959 is simpler? • Probably not simpler in many, if not most cases. • No BBUAs are necessary if client establishes separate dialog. • Possible synchronization problems? • Client knows to end early media dialog when RTP payload type switches in media stream to the “final” payload type. • Requirement to use GRUUs? • Usage of a GRUU for the early media dialog is entirely optional. • Many types of early media are not provided by an element associated with the final set of endpoints that may accept the session. • “Does not introduce service interaction issues related to services that may be wrongly applied to the new dialog?” • What? • Better Firewall management than RFC 3959 • Client can reuse the interface established for “final” media for early media dialogs. • No special SBC behavior, etc.

More Related