Re: [rtcweb] Minimal SDP negotiation mechanism

Iñaki Baz Castillo <ibc@aliax.net> Tue, 20 September 2011 12:13 UTC

Return-Path: <ibc@aliax.net>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51D3321F8C4B for <rtcweb@ietfa.amsl.com>; Tue, 20 Sep 2011 05:13:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.649
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRBRe97Zd36w for <rtcweb@ietfa.amsl.com>; Tue, 20 Sep 2011 05:13:45 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 35FBB21F8B0F for <rtcweb@ietf.org>; Tue, 20 Sep 2011 05:13:44 -0700 (PDT)
Received: by vws5 with SMTP id 5so730526vws.31 for <rtcweb@ietf.org>; Tue, 20 Sep 2011 05:16:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.9.129 with SMTP id l1mr179843vcl.87.1316520968951; Tue, 20 Sep 2011 05:16:08 -0700 (PDT)
Received: by 10.220.94.200 with HTTP; Tue, 20 Sep 2011 05:16:08 -0700 (PDT)
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se>
References: <4E777500.5030201@alvestrand.no> <69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se>
Date: Tue, 20 Sep 2011 14:16:08 +0200
Message-ID: <CALiegf=r7t4b+Ov=UqhEZc7x2a9+Prdm3yuar+n156CYnyyrRw@mail.gmail.com>
From: Iñaki Baz Castillo <ibc@aliax.net>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Minimal SDP negotiation mechanism
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Sep 2011 12:13:46 -0000

2011/9/20 Christer Holmberg <christer.holmberg@ericsson.com>:
> 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.



> 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"
  http://tools.ietf.org/html/rfc6228

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


Regards.


-- 
Iñaki Baz Castillo
<ibc@aliax.net>