Early Media Indirection (EMIND)

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