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

From: Adam Roach <[email-masked]>
Date: Tue, 15 Oct 2013 10:51:58 -0500

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

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 15 Oct 2013 16:25:28 +0000

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: [email-masked] [[email-masked]] on behalf of Adam Roach [[email-masked]]
Sent: Tuesday, 15 October 2013 6:51 PM
To: [email-masked]
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:

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:

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.

  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.

  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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Oct 2013 14:07:18 -0400

Adam,

I agree with most of your analysis. Comment inline.

> turn it into an extremely well-defined extension point.

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

> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 15 Oct 2013 11:19:05 -0700

On 15 October 2013 08:51, Adam Roach <[email-masked]> wrote:
> 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.

While this is your "backup", I'm not sure that it's safe, given what
we've seen regarding this field.  Folks are using the wrong string and
somehow, things still proceed.  That would suggest that unsupported
"proto" isn't being used as grounds for rejecting a media section.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 15 Oct 2013 18:26:34 +0000

Hi,

> port number is a problem.

0.0.0.0

Regards,

Christer

---

From: Adam Roach <[email-masked]>
Date: Tue, 15 Oct 2013 14:06:52 -0500

> the bundle (defined elsewhere) or aren't going to be used at all.

What I'm thinking about is something that defines a setup like this:

...
a=group:BUNDLE a1 a2
a=group:BUNDLE v1 v2
...
m=audio ...
c=IN IP4 1.1.1.1
a=mid:a1
...
m=audio ...
c=IN IP4 1.1.1.1
a=mid:a2
...
m=video ...
c=IN IP4 2.2.2.2
a=mid:v1
...
m=video ...
c=IN IP4 2.2.2.2
a=mid:v2
...

Or, in plain English: we want to two audio streams to be bundled 
together and sent to 1.1.1.1; and the two video streams to be bundled 
together and sent to 2.2.2.2. And now I see what you're saying: if we 
just used 0.0.0.0 in the "bundle only" lines, then you'd get the 
transport address from the non-bundle-only sections in the bundle, just 
like we were proposing to do for the ports.

So, yes, I agree that this would be a potentially viable way to put 
together a line that "won't work" for legacy clients; however, given 
that implementations may not check for "0.0.0.0" as a special value, 
their behavior is likely to be far more difficult to predict than using 
port 0 (which has well-defined, crystal clear semantics in legacy use).

/a

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 15 Oct 2013 19:22:22 +0000

Hi,

> port 0 (which has well-defined, crystal clear semantics in legacy use).

It would have the same semantics also in bundle use - EXCEPT when used in that one initial Offer :)

Regards,

Christer

---

From: Suhas Nandakumar <[email-masked]>
Date: Tue, 15 Oct 2013 13:07:02 -0700

RFC3264 also says the following about 0.0.0.0

"RFC 2543 [10] specified that placing a user on hold was accomplished

   by setting the connection address to 0.0.0.0.  Its usage for putting
   a call on hold is no longer recommended, since it doesn't allow for
   RTCP to be used with held streams, doesn't work with IPv6, and breaks
   with connection oriented media.  However, it can be useful in an
   initial offer when the offerer knows it wants to use a particular set
   of media streams and formats, but doesn't know the addresses and
   ports at the time of the offer.  Of course, when used, the port
   number MUST NOT be zero, which would specify that the stream has been
   disabled.  An agent MUST be capable of receiving SDP with a
   connection address of 0.0.0.0, in which case it means that neither
   RTP nor RTCP should be sent to the peer."

>From the above, 0.0.0.0  can be used along with bundle-only along with
the combination of things being discussed here.. Since with this, the
end-points that are BUNDLE capable will be able to parse this and
respond with answerer's BUNDLE address.  Ofcourse, this will be
followed by updated Offer with Offerer's BUNDLE Address to complete
the BAS procedures.

./Suhas

On Tue, Oct 15, 2013 at 8:51 AM, Adam Roach <[email-masked]> 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.
>
> 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:
>
> By overriding this second normative statement for bundle clients, we turn
> it into an extremely well-defined extension point.
>
> section, there are only a small handful of fields that an implementation is
> required to read and understand:
>
>    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.
>
>    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.
>
>    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.
>
>     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.
>
>    register IP4-BUNDLEONLY and IP6-BUNDLEONLY, but this is approximately as
>    elegant as option #1.
>
>    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.
>
> "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".
>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 21 Oct 2013 21:24:57 -0700

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

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