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

[Suhas Nandakumar <[e-mail]>]

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