Re: [rtcweb] Minimal SDP negotiation mechanism
Christer Holmberg <christer.holmberg@ericsson.com> Tue, 20 September 2011 12:34 UTC
Return-Path: <christer.holmberg@ericsson.com>
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 D91A521F8C6C for <rtcweb@ietfa.amsl.com>; Tue, 20 Sep 2011 05:34:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.385
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uYl+AkHdiHKZ for <rtcweb@ietfa.amsl.com>; Tue, 20 Sep 2011 05:34:01 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 1796221F8C19 for <rtcweb@ietf.org>; Tue, 20 Sep 2011 05:34:00 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c47ae000000b17-f4-4e7888cab7d5
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 75.FD.02839.AC8887E4; Tue, 20 Sep 2011 14:36:26 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Tue, 20 Sep 2011 14:36:25 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Iñaki Baz Castillo <ibc@aliax.net>
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: <7F2072F1E0DE894DA4B517B93C6A05852233F6F291@ESESSCMS0356.eemea.ericsson.se>
References: <4E777500.5030201@alvestrand.no> <69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se> <CALiegf=r7t4b+Ov=UqhEZc7x2a9+Prdm3yuar+n156CYnyyrRw@mail.gmail.com>
In-Reply-To: <CALiegf=r7t4b+Ov=UqhEZc7x2a9+Prdm3yuar+n156CYnyyrRw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
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: "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:34:02 -0000
Hi, >> 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" > http://tools.ietf.org/html/rfc6228 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. Regards, Christer
- Re: [rtcweb] Minimal SDP negotiation mechanism Olle E. Johansson
- [rtcweb] Minimal SDP negotiation mechanism Harald Alvestrand
- Re: [rtcweb] Minimal SDP negotiation mechanism Paul Kyzivat
- Re: [rtcweb] Minimal SDP negotiation mechanism Hadriel Kaplan
- Re: [rtcweb] Forking & Early Media - Was Re: Mini… Olle E. Johansson
- Re: [rtcweb] Minimal SDP negotiation mechanism Christer Holmberg
- Re: [rtcweb] Minimal SDP negotiation mechanism Iñaki Baz Castillo
- Re: [rtcweb] Minimal SDP negotiation mechanism Harald Alvestrand
- Re: [rtcweb] Minimal SDP negotiation mechanism Christer Holmberg
- Re: [rtcweb] Minimal SDP negotiation mechanism Christer Holmberg
- Re: [rtcweb] Minimal SDP negotiation mechanism Harald Alvestrand
- Re: [rtcweb] Minimal SDP negotiation mechanism Olle E. Johansson
- Re: [rtcweb] Minimal SDP negotiation mechanism Christer Holmberg
- Re: [rtcweb] Minimal SDP negotiation mechanism Iñaki Baz Castillo
- Re: [rtcweb] Minimal SDP negotiation mechanism Magnus Westerlund
- Re: [rtcweb] Minimal SDP negotiation mechanism Roman Shpount
- Re: [rtcweb] Minimal SDP negotiation mechanism Olle E. Johansson
- Re: [rtcweb] Minimal SDP negotiation mechanism Cullen Jennings
- [rtcweb] Forking & Early Media - Was Re: Minimal … Cullen Jennings
- Re: [rtcweb] Minimal SDP negotiation mechanism Cullen Jennings
- Re: [rtcweb] Forking & Early Media - Was Re: Mini… Cullen Jennings
- Re: [rtcweb] Forking & Early Media - Was Re: Mini… Olle E. Johansson
- Re: [rtcweb] Minimal SDP negotiation mechanism Hadriel Kaplan
- Re: [rtcweb] Forking & Early Media - Was Re: Mini… Dzonatas Sol
- Re: [rtcweb] Forking & Early Media - Was Re: Mini… Hadriel Kaplan
- Re: [rtcweb] Forking & Early Media - Was Re: Mini… Hadriel Kaplan
- Re: [rtcweb] Forking & Early Media - Was Re: Mini… Ravindran Parthasarathi
- Re: [rtcweb] Forking & Early Media - Was Re: Mini… Roman Shpount
- Re: [rtcweb] Forking & Early Media - Was Re: Mini… Olle E. Johansson
- Re: [rtcweb] Forking & Early Media - Was Re: Mini… Ravindran Parthasarathi
- Re: [rtcweb] Forking & Early Media - Was Re: Mini… Saúl Ibarra Corretgé
- Re: [rtcweb] Minimal SDP negotiation mechanism Harald Alvestrand
- Re: [rtcweb] Forking & Early Media - Proposal Randell Jesup
- Re: [rtcweb] Forking & Early Media - Proposal Olle E. Johansson
- Re: [rtcweb] Minimal SDP negotiation mechanism Magnus Westerlund
- Re: [rtcweb] Minimal SDP negotiation mechanism Harald Alvestrand
- Re: [rtcweb] Forking & Early Media - Was Re: Mini… Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] Forking & Early Media - Was Re: Mini… Roman Shpount
- Re: [rtcweb] Forking & Early Media - Proposal Roman Shpount
- Re: [rtcweb] Forking & Early Media - Proposal Randell Jesup
- Re: [rtcweb] Forking & Early Media - Was Re: Mini… Hadriel Kaplan
- Re: [rtcweb] Forking & Early Media - Was Re: Mini… Cullen Jennings
- [rtcweb] SIP Glare - Re: Minimal SDP negotiation … Cullen Jennings
- Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiat… Tim Panton
- Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiat… Hadriel Kaplan
- Re: [rtcweb] Forking & Early Media - Was Re: Mini… Roman Shpount
- Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiat… Roman Shpount
- Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiat… Magnus Westerlund
- Re: [rtcweb] Forking & Early Media - Proposal Elwell, John
- Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiat… Harald Alvestrand
- Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiat… Iñaki Baz Castillo
- Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiat… Cullen Jennings
- Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiat… Dzonatas Sol
- Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiat… Matthew Kaufman
- Re: [rtcweb] Forking & Early Media - Was Re: Mini… Christer Holmberg
- Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiat… Iñaki Baz Castillo
- Re: [rtcweb] Forking & Early Media - Was Re: Mini… Christer Holmberg
- Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiat… Cullen Jennings
- Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiat… Iñaki Baz Castillo
- Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiat… Cullen Jennings
- Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiat… Matthew Kaufman
- Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiat… Christer Holmberg
- Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiat… Cullen Jennings
- Re: [rtcweb] Forking & Early Media - Was Re: Mini… Hadriel Kaplan
- Re: [rtcweb] Forking & Early Media - Was Re: Mini… Roman Shpount
- Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiat… Randell Jesup
- Re: [rtcweb] Forking & Early Media - Was Re: Mini… Christer Holmberg
- Re: [rtcweb] Forking & Early Media - Was Re: Mini… Christer Holmberg
- Re: [rtcweb] Forking & Early Media - Was Re: Mini… Hadriel Kaplan
- Re: [rtcweb] SIP Glare - Re: Minimal SDP negotiat… Magnus Westerlund
- Re: [rtcweb] Forking & Early Media - Was Re: Mini… Harald Alvestrand
- Re: [rtcweb] Forking & Early Media - Was Re: Mini… Christer Holmberg