Re: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-06.txt - PeerConnection BUNDLE policy

Christer Holmberg <> Mon, 24 February 2014 17:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E0FCE1A00AF for <>; Mon, 24 Feb 2014 09:02:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.46
X-Spam-Level: *
X-Spam-Status: No, score=1.46 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vTnO0SnYp--E for <>; Mon, 24 Feb 2014 09:02:48 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 8976F1A00DD for <>; Mon, 24 Feb 2014 09:02:47 -0800 (PST)
X-AuditID: c1b4fb32-b7f4c8e0000012f5-fa-530b7b369501
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 13.A4.04853.63B7B035; Mon, 24 Feb 2014 18:02:46 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.02.0387.000; Mon, 24 Feb 2014 18:02:45 +0100
From: Christer Holmberg <>
To: Justin Uberti <>
Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-06.txt - PeerConnection BUNDLE policy
Thread-Index: Ac8pjtnjzyDELOBDTjiX88M43xAyxwDrMPeAARFru7A=
Date: Mon, 24 Feb 2014 17:02:44 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: fi-FI
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyM+Jvja5ZNXewQe8MJYutU4Us1v5rZ3dg 8liwqdRjyZKfTAFMUVw2Kak5mWWpRfp2CVwZJ47cZCrYI1Kxe9om1gbGH8JdjJwcEgImEk8O H2WBsMUkLtxbzwZiCwmcYJR48LSsi5ELyF7CKLHtxCWgIg4ONgELie5/2iA1IgJqEg9n7WIF sZkF1CXuLD7HDmILCyRIrHy1kQWiJlHi9e8ONgjbSuLlt/vMIGNYBFQlvi8pBQnzCvhKTF/x gRVi1RRGiae9XWCrOAUCJc6d8wCpYQQ67fupNUwQq8QlPhy8zgxxsoDEkj3noWxRiZeP/7FC 2EoSaw9vBxvDLKApsX6XPkSrosSU7ofsEGsFJU7OfMIygVFsFpKpsxA6ZiHpmIWkYwEjyypG yeLU4uLcdCMDvdz03BK91KLM5OLi/Dy94tRNjMDYObjlt9EOxpN77A8xSnOwKInzXmetCRIS SE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAOHWH+x3NbvFm40v83M96JLgtN5jUGW06UhZScPHH Vo3Oy3GNMe0726wFOi+caTz5L2fFxCAfPp5Vpc2M8Ysa2PfNm3i7OfPuWaN9iukBuzu5gyt1 Y5N7tr4y2vruwsdItbX1L+ojPbrabS28TbP6b/e6hNnlG8zn8/hV9nljwW1xmy1njykqsRRn JBpqMRcVJwIA5L7GfmsCAAA=
Cc: "" <>
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-06.txt - PeerConnection BUNDLE policy
X-Mailman-Version: 2.1.15
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: Mon, 24 Feb 2014 17:02:49 -0000


>> Section 4.1.1. defines, for the PeerConnection constructor, the possibility to specify BUNDLE policy.
>> However, I am missing the possibility to indicate whether, within a BUNDLE group, the same port number shall be used or not.
>> Section 5.2.1 does say:
>>        "o  The port value is set to the port of the default ICE candidate for
>>        this m= section; if this m= section is not being bundled into
>>        another m= section, the port value MUST be unique."
>> ...but, it doesn't talk about the case when the port IS being bundled into another m= section. Normally, in the initial Offer, the port value will be 
>> unique also in that case, but if the PeerConnection is created due to forking, and it is known that the remote peer supports BUNDLE, then 
>> identical port values can be used already in the initial offer.
> If a m= section is being bundled into another m= section, then the port number must be the same, as indicated in the BUNDLE WG draft. 

Before it is known whether the remote peer supports BUNDLE, each m= line must have a unique port number.

> I did not include a policy option to force use of the same port; the closest thing would be to use a policy of "all", which will mark all lines except the 
> first as bundle-only and achieve basically the same result, although it would require a second offer to update the bundle-only ports. If this is a 
> problem we could consider adding another policy value.

Not sure I follow. I think the usage of bundle-only is a separate issue.

The use-case I have in mind is where I want to guarantee interoperability, so I'd choose the "max-compat" policy.

However, I do need to be able to indicate whether the m= lines should have the same port number or not (again, depending on whether the remote peer has indicated support of BUNDLE or not).