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

[Christer Holmberg <[e-mail]>]

Hi Adam,



I have also been thinking about defining new BUNDLE values for media types, address types etc, but I agree it's probably something we shouldn't do - at least not for media type and net/address type.



Also, your alternatives are based on the assumption the the bundle-only m- lines are added before it is known whether the Answerer supports. There has been a suggestion that the bundle-only m- lines are added in the "2nd Offer" (BAS Offer in BUNDLE), when the Answerer has indicated support of BUNDLE, and selected the BUNDLE address for the Offerer. In that case, the BUNDLE address can be addded to each m- line (including the bundle-only m- lines) in the BUNDLE group.



Regards,



Christer



________________________________
From: [e-mail] [[e-mail]] on behalf of Adam Roach [[e-mail]]
Sent: Tuesday, 15 October 2013 6:51 PM
To: [e-mail]
Subject: [MMUSIC] Bundle-only, Port 0, and other options

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