Early Media in SIP: Problem Statement, Requirements,

and Analysis of Solutions

draft-barnes-sip-em-ps-req-sol

Richard Barnes BBN Technologies

IETF 68, Prague, CZ

Overview

• Early media is a longstanding problem• Lots of proposed solutions, no

consensus• This document tries to provide

structure for the discussion– Clear problem statement– Consolidated list of requirements– Initial analysis of solution space

What is Early Media?

• Media that flows before the 200/OK response in an INVITE transaction.

UAC / offeror UAS / answerer

INVITESDP offer

200/OKSDP answer

Early Media

Why Early Media a problem?

• UAC gets media with no SDP answer• The asymmetry of information is what

causes problems– Forking: Multiple un-signaled streams– Security: Can’t use signaling to complete a

Diffie-Hellman exchange

• Draft uses the definition “early” = “before the offeror has received an answer”

• This definition still allows pre-200 media, as long as an answer is sent

What’s the solution

• A normative update to RFC 3261 and RFC 3264 (et al.) that requires an SDP answer to be received by the offeror before anyone sends media.– Provide reliable transport for an SDP

answer– Forbid sending media until receipt of

answer is acknowledged

Sketch of a SolutionUAC / offeror UAS / answerer

INVITESDP offer

200/OK(SDP answer)

pre-200 Media

pre-200SDP answer

Existing Solutions

• Lots of solutions have been come and gone– RFC 3960 - too vague– Reliable 183 - requires PRACK– ICE - Uses non-SIP messages

• None were mandatory to implement • All met with objections• So lets consolidate those objections

into requirements …

Requirements

1. Ensure an answer before media2. Minimize additional messaging3. Backward-compatibility with SIP as

defined today4. Well-defined PSTN interactions5. No new DoS opportunities6. Free from IPR constraints• Others?

Solution space

• Messages with SIP INVITE transaction– Early 200/OK– Offer-less INVITE– Reliable provisional response– Separate INVITE

• 3960 App. Server Model / EMIND

• Non-INVITE SIP mechanisms– INFO / UPDATE (3960 Gateway Model)– Other response codes (e.g. 401 w/ null auth)

• Non-SIP mechanisms– Lower-layer protocol