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

Christer Holmberg <christer.holmberg@ericsson.com> Fri, 14 February 2014 14:22 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 03F9C1A0289 for <rtcweb@ietfa.amsl.com>; Fri, 14 Feb 2014 06:22:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham
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 E0v9UlUxJl0F for <rtcweb@ietfa.amsl.com>; Fri, 14 Feb 2014 06:22:51 -0800 (PST)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB491A025C for <rtcweb@ietf.org>; Fri, 14 Feb 2014 06:22:49 -0800 (PST)
X-AuditID: c1b4fb38-b7f418e000001099-47-52fe26b7f624
Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id E2.F2.04249.7B62EF25; Fri, 14 Feb 2014 15:22:47 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0387.000; Fri, 14 Feb 2014 15:22:46 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-06.txt - PeerConnection BUNDLE policy
Thread-Index: Ac8pjtnjzyDELOBDTjiX88M43xAyxw==
Date: Fri, 14 Feb 2014 14:22:46 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D1730E7@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.146]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPLMWRmVeSWpSXmKPExsUyM+Jvje52tX9BBsvvSFms/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujEf7DjIVvGOr+NCxna2BcS1rFyMnh4SAicTJRy1sELaYxIV7 64FsLg4hgSOMEkf2vWCCcBYzStx/PJ+li5GDg03AQqL7nzZIg4iAusTlhxfYQWxhgQSJNffX MELEEyVe/+5gg7D1JE4eXgpmswioSuxcdJ8FxOYV8JU4c7MBrJcRaPH3U2uYQGxmAXGJW0/m M0EcJCCxZM95ZghbVOLl439QRytJ/NhwiQWiXkdiwe5PbBC2tsSyha+ZIeYLSpyc+YRlAqPw LCRjZyFpmYWkZRaSlgWMLKsYOYpTi5Ny040MNjECA/nglt8WOxgv/7U5xCjNwaIkzvvxrXOQ kEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsa9fWs3KEfFHJtmP6NObn+J/KzGlprAONeonZHq mn5pZ+LVJr31ksjKiP1Z9fbvbbd/iRUMN7TYvxf+8XL5OXfO/K5jM6pNt+XsipiX8HWvwy9t ibJP3cE7/c0jXFTqzdZcE7vqsZGnqMymzD7zinSHlFN4aEdai9XqNn+pDzfXP7x7NO5hsxJL cUaioRZzUXEiAAPq0yIyAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/PXj0Uqi_ML4t9iEg2TNz_OTVwaY
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: Fri, 14 Feb 2014 14:22:53 -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.

Regards,

Christer