Re: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections

Christer Holmberg <christer.holmberg@ericsson.com> Mon, 21 October 2013 20:17 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 7B3DC11E8243 for <rtcweb@ietfa.amsl.com>; Mon, 21 Oct 2013 13:17:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.67
X-Spam-Level:
X-Spam-Status: No, score=-5.67 tagged_above=-999 required=5 tests=[AWL=0.578, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, 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 b-bFx4RL3oUM for <rtcweb@ietfa.amsl.com>; Mon, 21 Oct 2013 13:17:02 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 12E0711E86DC for <rtcweb@ietf.org>; Mon, 21 Oct 2013 13:16:37 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-ee-52658ba433fd
Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id FC.EF.03802.4AB85625; Mon, 21 Oct 2013 22:16:37 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0328.009; Mon, 21 Oct 2013 22:16:36 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "Vijaya Mandava (vimandav)" <vimandav@cisco.com>, "Cullen Jennings (fluffy)" <fluffy@cisco.com>
Thread-Topic: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections
Thread-Index: Ac69tBInSk4xBHAwQSOQDX27ZZb6/AN2sSmAAAv+KVkAGZQYAAAE0Y4gAArpVgAACKGa8AB/NYkAAAWRWswAADD9eQ==
Date: Mon, 21 Oct 2013 20:16:35 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4E6402@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C4C336D@ESESSMB209.ericsson.se>, <1CDFD781608D924094E43F573C351961124C7D16@xmb-rcd-x13.cisco.com>
In-Reply-To: <1CDFD781608D924094E43F573C351961124C7D16@xmb-rcd-x13.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.147]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4E6402ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyM+Jvje7S7tQgg+c72S06JrNZrP3Xzm6x +MB9VovmaSdYHFg8pvzeyOqxZMlPpgCmKC6blNSczLLUIn27BK6MLY3SBY9CKj78fsHYwPjN rYuRk0NCwETiw7SbjBC2mMSFe+vZuhi5OIQEDjNKNB54wwrhLGGUWHlqMUsXIwcHm4CFRPc/ bZAGEYFUienPGtlBbGaBWIlDc64xgdjCAp4SXZe62UHKRQS8JC5uFYMoz5J4Of8M2C4WAVWJ DTveMoPYvAK+Euuu/maGWNXHKLH84mewOZxAic3/PrOA2IxAx30/tYYJYpe4xK0n85kgjhaQ WLLnPDOELSrx8vE/VpC9EgJKEtO2poGYzAL5Eo/epkKsEpQ4OfMJywRG0VlIBs1CqJqFpAqi xEDi/bn5zBC2tsSyha+hbH2JjV/OMkLY1hJPNpxkQVazgJFjFSN7bmJmTnq50SZGYNQd3PJb dQfjnXMihxilOViUxHk/vHUOEhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cC4u/DEvOkljddS 2IXesjCHPQtY8rTsV0euXHVR86Wi1PDjxQX/OkL0TB8tfjvtUBLPBsadbqzSC34/f6F3cfbW rXoHi5ramg/tU49entUmxr4sP8HllGDEtBkLN1qU7d7YWPObbYnhlP/2O2edvJ/fYV/f2ihc 9azxea9gdu/7h1bT+HgOBzkrsRRnJBpqMRcVJwIAoLTmvIgCAAA=
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, "Suhas Nandakumar (snandaku)" <snandaku@cisco.com>
Subject: Re: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections
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: Mon, 21 Oct 2013 20:17:19 -0000

Hi Vijaya,



> I agree that parallel  and serial forking call flows can be solved with multiple PeerConnection model.

>
> But going back to the original question you had -
>>> However, according the 3264, the ORDER of the m- lines also need to be kept the same.
>>> So, my question is: how can I ensure that the order of the m- lines in an Offer for a new PeerConnection is the same as in an Offer for an old PeerConnection?
>
> The Jsep doc 4.1.4 setLocalDescription already implies that a new PeerConenction would use/support the old local description, and reading it, assumption is that the old description m-line ordering would not be changed.

My understanding (please correct me if I'm wrong) is that you have to call createOffer before you call setLocalDescription, so it would be useful to get the right order already when calling createOffer.

> It definitely didn't mention that we would send entirely new SDP on the new PeerConnection created…

Well, it depends on what you mean with "entirely new". At least the address/candidate information would be new, as the new PeerConnections can't share the address/candidates with the old one.

Regards,

Christer




On 10/18/13 4:38 PM, "Christer Holmberg" <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> wrote:

Hi,

Again, it is not specific to parallel forking - it is also needed for SERIAL forking, in cases where you need to send updated Offers on early dialogs, and therefore cannot use PRANSWER.

I don't think I agree on that but I really want to spend my time on making sure we get the setLocal / setRemote text working for the simple case before we sort all this out.

This is how I understand it would work when discussing with Vijaya .

Now, if you don't agree, please then explain how you would implement the forking case I provided :)

Regards,

Christer



-----Alkuperäinen viesti-----
Lähettäjä: Cullen Jennings (fluffy) [mailto:fluffy@cisco.com]
Lähetetty: 18. lokakuuta 2013 22:12
Vastaanottaja: Christer Holmberg
Kopio: Suhas Nandakumar; rtcweb@ietf.org<mailto:rtcweb@ietf.org>
Aihe: Re: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections
On Oct 17, 2013, at 10:59 PM, Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> wrote:
And, I'm not asking for a solution at this point, simply that we identify it as an issue that needs to be solved :)
So I sort of disagree on two points here.
I disagree that it needs to be solved - I'm not against solving it if anyone has an easy way but every time we talk about this the conclusions comes up people don't want to bother to fully solve the parallel forking problem in the first version of the webrtc. Speaking purely for myself, SIP parallel forking has not turned out to be extremely useful and has turned out to seriously complicate the use and extensions to the protocol - basically the HERFP problem - so I don't really care if webrtc takes on that problem or not.
Second, I suspect that Invite with replaces actually does solve this.
I certainly don't mind marking it as an issue but it's not clear to me that the WG thinks it is an issue that needs to be solved or that it an issue that is not solved. I've sort of been waiting to see the other "easy" stuff in JSEP / Bundle / Unified plan get sorted out and then figured we could go back and see what was possible or not with parallel forking in SIP.

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org<mailto:rtcweb@ietf.org>
https://www.ietf.org/mailman/listinfo/rtcweb