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

[Paul Kyzivat <[e-mail]>]

Adam,

I agree with most of your analysis. Comment inline.

On 10/15/13 11:51 AM, Adam Roach 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. 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.

I don't understand this last point. We are only talking about 
bundle-only lines that are either going to use the address and port of 
the bundle (defined elsewhere) or aren't going to be used at all.

IMO we *could* use an invalid address (pick one) as the indicator if the 
port number is a problem.

OTOH, I'm not convinced this is better. I can imagine problems arising 
from this too.

	Thanks,
	Paul

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