Re: [MMUSIC] Bundle-only, Port 0, and other options

[Eric Rescorla <[e-mail]>]

On Tue, Oct 15, 2013 at 8:51 AM, Adam Roach <[e-mail]> wrote:

>  There's been a bit of a brouhaha (from small but disproportionately vocal
> quarters) around the use of port zero in an offer for bundle-only lines. So
> I wanted to take a step back and see whether we could untangle this knot a
> bit.
>
> The key property that we need here is that bundle-only lines must be
> formed in a way that causes them to be rejected by non-bundling agents, but
> accepted by bundling agents
>

Just for clarity, it must be rejected in such a way that failure to compelte
ICE, etc. does not lead to connection failure.

-Ekr


> . Since bundle deals with ports, that seems like an extremely natural
> place to make the distinction. It has the spectacular advantage of being
> defined in a crystal clear way in RFC 3264:
>
>   "A port number of zero in the offer indicates that the
>    stream is offered but MUST NOT be used.  This has no useful semantics
>    in an initial offer, but is allowed for reasons of completeness..."
>
>   "A stream that is offered with a port of zero MUST be marked with port
>    zero in the answer."
>
> By overriding this second normative statement for bundle clients, we turn
> it into an extremely well-defined extension point.
>
> ----------------------------------------------------------------------
>
> But this is exactly the approach that is causing people heartburn, so
> let's look at other potential ways of achieving the goal. In a media
> section, there are only a small handful of fields that an implementation is
> required to read and understand:
>
>   m=<media> <port>/<number of ports> <proto> <fmt> ...
>   c=<nettype> <addrtype> <connection-address>
>
> Taken one-by-one:
>
>
>    1. Extending "media" would be somewhat problematic, since we use this
>    information extensively in our use cases. We would effectively have to
>    register bundle-only variations on "audio," "video," and "application" (at
>    a minimum), which is horribly inelegant.
>
>     2. Port is discussed above.
>
>     3. Setting "number of ports" to zero would clearly have the semantics
>    that we're interested in here. The down-side of using this approach is that
>    (in my experience) there are a lot of implementations that simply ignore
>    the "number of ports" field, and a small handful that simply choke when it
>    is present.
>
>     4. Proto is an interesting one. Right now, we use RTP/SAVPF and
>    DTLS/SCTP. We could conceivably additionally register RTP/SAVPF/BUNDLEONLY
>    and DTLS/SCTP/BUNDLEONLY, which would presumably be rejected by non-bundle
>    clients as unrecognized.
>
>     5. Fmt isn't really an option -- we need to use it to identify
>    formats.
>
>     6. Moving on to the c= line (which, if present, is mandatory to
>    parse, understand, and honor), nettype is pretty much hardwired to "IN." We
>    could register an "IN-BUNDLEONLY" option, but there's a good chance that
>    implementations don't really look at the value of this field, so they
>    wouldn't reject the new value.
>
>     7. Addrtype is necessary for indicating IP4 versus IP6. We could
>    register IP4-BUNDLEONLY and IP6-BUNDLEONLY, but this is approximately as
>    elegant as option #1.
>
>     8. Overloading connection-address would be dicey, since it ruins the
>    ability to send different streams to different places. While WebRTC might
>    not care too much about these use cases, they *are* important in other
>    contexts.
>
> In summary: of the above options, the strongest option still seems to be
> "port," followed (perhaps) by "proto." We could probably force "media" or
> "addrtype" to work, but these would be pretty messy. I think "number of
> ports" and "nettype" are at high risk of being ignored by non-bundle
> implementations (i.e., they won't trigger the failure we want), and we need
> to maintain the existing meanings for "fmt" and "connection-address".
>
> Even more tersely: if we don't want to port zero, I think the only other
> realistic option is registering new "proto" values.
>
> /a
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>