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

Justin Uberti <> Sun, 02 March 2014 21:41 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7E7771A0B08 for <>; Sun, 2 Mar 2014 13:41:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.925
X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4CzfHMBRm7EX for <>; Sun, 2 Mar 2014 13:41:35 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c01::229]) by (Postfix) with ESMTP id 5C8AE1A0A3D for <>; Sun, 2 Mar 2014 13:41:35 -0800 (PST)
Received: by with SMTP id pa12so2949644veb.0 for <>; Sun, 02 Mar 2014 13:41:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=HIBUfqWuGxfCAYzF5nb7pUaI84yKY4n5pgWMQR80tCg=; b=L4IFzVk71TnUW7hnkPiojfZynOHIPkjqG7w/0zs5pY9cRM7mFkMXJMUuWUW57crfx8 iNjkhr7p6rV/kAmITdej8EHCfok5lsjcCjWASfst89ZN80wJxyrB2OJ0nanh+dTJsV69 S2HOZ9ZJFBOPJGjlvtipzzrLYrJe/5yQ/QKZbJBDiDeQQ2ZgU4ZNKEf8QR/qNHrtiwUa 9fDybEHGHmpi9zplrp1dORtHy9hK8eYHVJL0Q4sxpP4g2jl8z/NZeigxcSrek1RQdzB5 xgzcVaeXyZTB3yvuRJSfoIq0Xs5xzxsxgncUIawtuMBF6C8FoiMJCARQlZJwuCSC77BS qRkQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=HIBUfqWuGxfCAYzF5nb7pUaI84yKY4n5pgWMQR80tCg=; b=deDlo7FPV5AaLMP0qsxt2KF5AuwJANx+OLblA3dzskM4YmUEN+iRIPdGeaP9uR166/ LYXMQFkmQ3BvH3mPqzMxqBglVRZJjnXhjWeapNL3tP53K3Cz2/u5m9XOM4TDYtSPCsJT OV+/tYNm11aCLXNYPbk1dOPu7NxYfLqIQvgVVMuHkxwkEm/it8PZjvAhE4VsaP/d4Ppq I/BiZMzTX8OKzMYdZi4VvtusZtQKYhwfEfzn91z3QoN0SLiGsSQb7xnTl7VoFiMjRP99 x9if1j/kEQtI4l5zEJ8W5wGCQ2PYiETzpLJdvpleldBw+oAtk/T5NjMOvhxGWowuCOSz N3Jg==
X-Gm-Message-State: ALoCoQlP5w8fyF746E6O0HW+nQoiNjeC8iG1Ihm44uKAhL+gAbPVf8QRWgN211uoZvMTkqZBhETJ1339DVdbEqu+6fG6LmvtynTaMS2NFi/KTGzcuTm1RUiAkb9a71W1RLxvASSXsw+GhD+xMIYJonIVdnipbGlIKc2EY6YpjS9ZOVa+FPG8udZY4txjmFrrg6hQnz584zYy
X-Received: by with SMTP id e16mr14165819vct.13.1393796492518; Sun, 02 Mar 2014 13:41:32 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Sun, 2 Mar 2014 13:41:12 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
From: Justin Uberti <>
Date: Sun, 02 Mar 2014 13:41:12 -0800
Message-ID: <>
To: Christer Holmberg <>
Content-Type: multipart/alternative; boundary="001a11362cd4d392bf04f3a68819"
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: Sun, 02 Mar 2014 21:41:37 -0000

On Mon, Feb 24, 2014 at 9:02 AM, Christer Holmberg <> wrote:

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

Agreed. Setting aside BUNDLE-only for now, the implementation knows in the
first offer that BUNDLE may not be supported and will use a unique port
number for m= lines in the initial offer.

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

In the typical case, you don't need to set this; the implementation knows
to use unique ports in the initial offer and then can do the appropriate
thing in future offers (i.e., once BUNDLE support by the remote side is
known). In the case where you want to start with shared ports in the
initial offer, because you know through some mechanism that the remote side
supports this, the bundle-policy constraint could allow you to indicate
this, i.e. that you want bundling to start immediately.

I agree that a new value is needed to support this.