Re: [rtcweb] Minimal SDP negotiation mechanism

Christer Holmberg <> Tue, 20 September 2011 12:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D91A521F8C6C for <>; Tue, 20 Sep 2011 05:34:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.385
X-Spam-Status: No, score=-6.385 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uYl+AkHdiHKZ for <>; Tue, 20 Sep 2011 05:34:01 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1796221F8C19 for <>; Tue, 20 Sep 2011 05:34:00 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c47ae000000b17-f4-4e7888cab7d5
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 75.FD.02839.AC8887E4; Tue, 20 Sep 2011 14:36:26 +0200 (CEST)
Received: from ([]) by ([]) with mapi; Tue, 20 Sep 2011 14:36:25 +0200
From: Christer Holmberg <>
To: Iñaki Baz Castillo <>
Date: Tue, 20 Sep 2011 14:36:24 +0200
Thread-Topic: [rtcweb] Minimal SDP negotiation mechanism
Thread-Index: Acx3jxSR/5BtZgBRS++4cnJ+QX60kAAAW/Kg
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: "" <>
Subject: Re: [rtcweb] 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 12:34:02 -0000


>> Whether we want the browser to support forking is one 
>> thing, and I guess it much depends on whether we want to be 
>> able to do things on the media plane during the early phase 
>> of a session establishment.
> I hope. If not, let's forget about integrating WebRTC in any 
> telephony environment.
> The point here is that *media sessions* are "independant" of 
> signaling. If we make WebRTC just to deal with media plane, 
> the signaling (coded in JavaScript by a custom or native 
> library) could handle early media sessions with no problem.
> But if we impose a signaling protocol (built-in within the 
> browser WebRTC stack) then we'll be limited to adopted design 
> constrains, which is not good.

That's not what I am suggesting. But, forking also have impacts on the media plane.

>>But, at least the API needs to allow a JS SIP app to 
>>"replace" a previously received SDP with a new one (if the 
>>SIP app, in the forking case, for example chooses to always 
>>use the latest received SDP answer).
>There is no a magic solution for that case: which media to 
>render when parallel forking occurs and more than one branch 
>replies a 180/183 with SDP?

The JS SIP app can decide that, but my point was that the JS SIP app needs to be able to "replace" the SDP answer with anohter one (received on another early dialog) - *IF* it chooses to do so.

> Note that "199" response tries to "help" a bit:
>   "SIP Response Code for Indication of Terminated Dialog"

That's such a great piece of RFC :)

And, it does help the JS SIP app to make a decission, but the API still needs to allow to "replace" the SDP answer.

>If we let it at the JS application level, the developer could 
>handle those cases and decide which media session to render.

Yes, the JS app can make the decision - but, again, the API still needs to allow the JS app to enforce that decision.
>BTW: would be possible to render various at the same time by 
>mixing the incoming audio?.

Well, that is what my first question was more or less about.