Re: [rtcweb] Minimal SDP negotiation mechanism

Iñaki Baz Castillo <> Tue, 20 September 2011 12:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 51D3321F8C4B for <>; Tue, 20 Sep 2011 05:13:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.649
X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KRBRe97Zd36w for <>; Tue, 20 Sep 2011 05:13:45 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 35FBB21F8B0F for <>; Tue, 20 Sep 2011 05:13:44 -0700 (PDT)
Received: by vws5 with SMTP id 5so730526vws.31 for <>; Tue, 20 Sep 2011 05:16:09 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id l1mr179843vcl.87.1316520968951; Tue, 20 Sep 2011 05:16:08 -0700 (PDT)
Received: by with HTTP; Tue, 20 Sep 2011 05:16:08 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Tue, 20 Sep 2011 14:16:08 +0200
Message-ID: <>
From: Iñaki Baz Castillo <>
To: Christer Holmberg <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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:13:46 -0000

2011/9/20 Christer Holmberg <>:
> 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

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.

> 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?
Note that "199" response tries to "help" a bit:

  "SIP Response Code for Indication of Terminated Dialog"

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

BTW: would be possible to render various at the same time by mixing
the incoming audio?.


Iñaki Baz Castillo