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

Hadriel Kaplan <> Tue, 20 September 2011 22:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BA01A1F0C56 for <>; Tue, 20 Sep 2011 15:33:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.226
X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=-0.227, BAYES_00=-2.599, J_CHICKENPOX_52=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dKID-x82r1EQ for <>; Tue, 20 Sep 2011 15:33:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 358741F0C43 for <>; Tue, 20 Sep 2011 15:33:55 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 20 Sep 2011 18:36:21 -0400
Received: from ([]) by ([]) with mapi id 14.01.0270.001; Tue, 20 Sep 2011 18:36:21 -0400
From: Hadriel Kaplan <>
To: Cullen Jennings <>
Thread-Topic: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism
Thread-Index: AQHMd+W4GbLdjZqw9U+hWOGtS5YVCQ==
Date: Tue, 20 Sep 2011 22:36:21 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
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: Tue, 20 Sep 2011 22:33:56 -0000

On Sep 20, 2011, at 4:07 PM, Cullen Jennings wrote:

> 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 side. 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.

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