Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism

Christer Holmberg <> Thu, 22 September 2011 19:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9A2DE21F8B52 for <>; Thu, 22 Sep 2011 12:38:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.235
X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[AWL=-0.236, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WQgqqLYutLYv for <>; Thu, 22 Sep 2011 12:38:51 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B458A21F8B53 for <>; Thu, 22 Sep 2011 12:38:50 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c47ae000000b17-cb-4e7b8f5c5af9
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 5C.47.02839.C5F8B7E4; Thu, 22 Sep 2011 21:41:16 +0200 (CEST)
Received: from ([]) by ([]) with mapi; Thu, 22 Sep 2011 21:41:16 +0200
From: Christer Holmberg <>
To: 'Hadriel Kaplan' <>, Cullen Jennings <>
Date: Thu, 22 Sep 2011 21:41:15 +0200
Thread-Topic: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism
Thread-Index: AQHMd+W4GbLdjZqw9U+hWOGtS5YVCZVZys0g
Message-ID: <>
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: "" <>
Subject: Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 22 Sep 2011 19:38:51 -0000


>> That said, I think that doing both forking and early media is hard. Lets assume we are using a signaling gateway that is not a media gateway to translate between a SIP call on one side and whatever is happening over on the browser 
>>de. The basic issue is the browser initiating the communications needs to be able to start receiving multiple RTP streams before it even has signaling information to tell it how many it might receive.
>Not really - there will be signaling, because there has to be SDP answers even just to get ICE to work before the media starts flowing in many NAT cases.  And even in practice in SIP there're usually SDP answers in 18x to open 
>"gates", and to get upstream DTMF.  So if the concern is just that there's no signaling to tell the browser there are multiple RTP streams coming, I think that can be allayed.  
>The really hard part is knowing which stream to use/render/send-to, imho.  And putting that decision in the gateway isn't good - the best decider of that is probably the JS in the browser.

I am not sure whether the JS app would be able to make better decisions than the gateway - and I've never seen a SIP client which would allow the user to choose which early media to listen to. 

And, sometimes SBGs, eventhough they allow multiple early dialogs to pass towards the user, still only allow media associted with one of the early dialogs to pass.

In my opinion the best thing would be if we could come up with some common BCP, e.g. saying that media associated with the early dialog on which the latest SDP answer was received is considered "active", and will be presented to the user etc. 

Or something like that...

The network will then have to make sure that SDP answers are forwarded towards the user in a way that the "correct" media will be accepted and presented.

That was, once again, my input for the annual how-to-support-early-media debate :)

>>To simplify this problem, Cary and my draft proposes not allowing forking on the SIP side of the signaling gateway but still allowing early media. If you wanted to do do forking in this case, one would need a SBC that processed 
>>media and turned the forked medial legs into one media leg. 
>Obviously you can request that a request not be forked, using caller-prefs, but you can't "not allow" forking on the SIP side.  That would make it not SIP.  I know forking is hard, but that's life.  It's not appropriate for this WG 
>to make fundamental changes/limitations to the SIP protocol, just because some of it's "hard" for a browser. 

We need to keep in mind that supporting forking and supporting media from multiple locations are two different things, and I think we need to be very clear about what we mean when discussing.