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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5977421F8B64 for <>; Thu, 22 Sep 2011 12:45:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.232
X-Spam-Status: No, score=-6.232 tagged_above=-999 required=5 tests=[AWL=-0.234, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nY6gI4PZQkCM for <>; Thu, 22 Sep 2011 12:45:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A8BF021F8B5E for <>; Thu, 22 Sep 2011 12:45:30 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-f3-4e7b90f241d8
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id F1.71.20773.2F09B7E4; Thu, 22 Sep 2011 21:48:02 +0200 (CEST)
Received: from ([]) by ([]) with mapi; Thu, 22 Sep 2011 21:48:02 +0200
From: Christer Holmberg <>
To: 'Roman Shpount' <>, Ravindran Parthasarathi <>
Date: Thu, 22 Sep 2011 21:48:00 +0200
Thread-Topic: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism
Thread-Index: Acx4BRN+GpUfNoLrTvGpLg90/8yu1gBWwc+w
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A05852233D45FBAESESSCMS0356e_"
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:45:32 -0000


>I would consider it very unfortunate if we decide not to support forking in RTC. It needs to be handled, and not in signaling, but by defining what to do with multiple incoming media RTP streams and multiple answers. The simplest model would be ignore everything except the RTP media defined in the last
>answer and have an ability to update the answer to the last offer.


>Alternative would be to create a new PeerConnection based on a new answer (this is API change so should probably go to W3C).

This is one of the things that maybe should be put in the "nice to have in a later release" bucket :)



On Tue, Sep 20, 2011 at 10:11 PM, Ravindran Parthasarathi <<>> wrote:
Forking in SIP does not apply in the literal sense to lot of SIP
applications (ISDN-SIP gateway, End-point which can't perform mixing).
In case of ISDN-SIP gateway, SIP callleg has to handle all forked
dialogs till 200 OK is received from anyone of the UAS and reject all
other dialogs with CANCEL, the media plane update is depend upon the
implementation whether to override the last SDP in media plane in case
mixing is not possible. I'm saying in this mail thread to highlight
forking handling in browser (as a SIP UA application) is not an
exception and it is the decision which has to be taken by any SIP
application development (and not SIP framework) for that matter.

SIP application forking behavior depends upon RTP model (endpoint or
mixer). In case browser acts only as endpoint, I agree with Cullen that
forking shall be handled by browser without application aware and no
need of API or callback.

The counter argument may be that my innovative mixing application in
browser is stopped by this API model.  In the generic SIP framework, the
callbacks are provided to handle this situation, default callback
function (browser as endpoint) are provided to reduce the application
awareness. From the API perspective, offer & answer state machine is not
required to be handled in application but we required to know whether
the application prefers which media model whether as end-point or mixer
and let end-point model be default. IMO, it is browser API design which
belongs to W3C. Please correct me here in case this API design is
somehow related to IETF.


>-----Original Message-----
>From:<> [<>] On
>Of Hadriel Kaplan
>Sent: Wednesday, September 21, 2011 4:06 AM
>To: Cullen Jennings
>Subject: Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP
>negotiation mechanism
>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
>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
>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
>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.
>rtcweb mailing list
rtcweb mailing list<>