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

[Justin Uberti <[e-mail]>]

On Mon, Feb 24, 2014 at 9:02 AM, Christer Holmberg <
[e-mail]> 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.