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

Christer Holmberg <christer.holmberg@ericsson.com> Mon, 24 February 2014 17:02 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0FCE1A00AF for <rtcweb@ietfa.amsl.com>; Mon, 24 Feb 2014 09:02:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTnO0SnYp--E for <rtcweb@ietfa.amsl.com>; Mon, 24 Feb 2014 09:02:48 -0800 (PST)
Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 8976F1A00DD for <rtcweb@ietf.org>; Mon, 24 Feb 2014 09:02:47 -0800 (PST)
X-AuditID: c1b4fb32-b7f4c8e0000012f5-fa-530b7b369501
Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 13.A4.04853.63B7B035; Mon, 24 Feb 2014 18:02:46 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.216]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0387.000; Mon, 24 Feb 2014 18:02:45 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Justin Uberti <juberti@google.com>
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: <7594FB04B1934943A5C02806D1A2204B1D1B5588@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1D1730E7@ESESSMB209.ericsson.se> <CAOJ7v-2ecnurvXs426-TsZwwjpwiVQNPNWqw8=0+bsEHCcDeoA@mail.gmail.com>
In-Reply-To: <CAOJ7v-2ecnurvXs426-TsZwwjpwiVQNPNWqw8=0+bsEHCcDeoA@mail.gmail.com>
Accept-Language: en-US
Content-Language: fi-FI
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.149]
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=
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/LnY8wFL4S4C3qusQvPBV5DVbXVM
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-06.txt - PeerConnection BUNDLE policy
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2014 17:02:49 -0000

Hi,

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

Regards,

Christer