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

[Adam Roach <[e-mail]>]

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