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

Christer Holmberg <> Fri, 18 October 2013 19:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 18BB811E8319 for <>; Fri, 18 Oct 2013 12:35:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.688
X-Spam-Status: No, score=-5.688 tagged_above=-999 required=5 tests=[AWL=0.561, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Oqavnq7qoaPe for <>; Fri, 18 Oct 2013 12:35:01 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9F12B11E8311 for <>; Fri, 18 Oct 2013 12:34:48 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-c0-52618d57b02e
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 65.0C.03802.75D81625; Fri, 18 Oct 2013 21:34:47 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.02.0328.009; Fri, 18 Oct 2013 21:34:47 +0200
From: Christer Holmberg <>
To: "Cullen Jennings (fluffy)" <>
Thread-Topic: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections
Thread-Index: Ac69tBInSk4xBHAwQSOQDX27ZZb6/AN2sSmAAAv+KVkAGZQYAAAE0Y4g
Date: Fri, 18 Oct 2013 19:34:45 +0000
Message-ID: <>
References: <>, <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: fi-FI
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+JvjW54b2KQQesyPYuOyWwWa/+1s1vs nNvB7MDsMeX3RlaPnbPusnssWfKTKYA5issmJTUnsyy1SN8ugSvj9PoVzAXfBSoaOp+wNjBu 4+1i5OCQEDCRWDe/uIuRE8gUk7hwbz1bFyMXh5DAYUaJZx8bmSGcJYwS7w/cZQJpYBOwkOj+ pw3SICJgKNG0Zx4TiM0sECjR3v+WBcQWFvCUmH6wgx2kXETAS+LiVjGIcjeJSWcmMYLYLAKq EitedbOD2LwCvhJ3Pqxnh1g1lUmie/EzsDmcQImdFy+D2YxAx30/tQZql7jEh4PXmSGOFpBY suc8lC0q8fLxP1YIW0lixfZLjBD1ehI3pk5hg7C1JZYtfM0MsVhQ4uTMJywTGMVmIRk7C0nL LCQts5C0LGBkWcXInpuYmZNebrSJERgzB7f8Vt3BeOecyCFGaQ4WJXHeD2+dg4QE0hNLUrNT UwtSi+KLSnNSiw8xMnFwSjUw+t4TSUicVDk59+l2nfaFR5Jzcpbx5lvOuFz7ILHhz+MHM5pj wpnm/jaZzm7d4Lf+joycq/myMGF+lQ+XPqVN54trXHDLxzSh9+x+x+bt+Uoa3OxxXbtDA989 +T7By2XefcvNTWm3J+UX7O51bDq6tpfr/Fbl8K+S2lwCG/h6PpW59t1MtjBWYinOSDTUYi4q TgQADC3RnGcCAAA=
Cc: "" <>
Subject: Re: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections
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: Fri, 18 Oct 2013 19:35:08 -0000


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.

As far as the solution is concerned: on a high level, whenever you create a new PC (or, when you add the media streams to it), you need to be able to indicate the order of the m- lines. Whether it is done explicitly, or implicitly e.g. by somehow referencing the old PC, I don't know, but I don't think it should be very difficult.



-----Alkuperäinen viesti-----
Lähettäjä: Cullen Jennings (fluffy) [] 
Lähetetty: 18. lokakuuta 2013 22:12
Vastaanottaja: Christer Holmberg
Kopio: Suhas Nandakumar;
Aihe: Re: [rtcweb] JSEP: Order of m- lines in multiple PeerConnections

On Oct 17, 2013, at 10:59 PM, Christer Holmberg <> 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.