Re: [MMUSIC] MTI: PT, RID, Both, or Neither?

[Peter Thatcher <[e-mail]>]

As I stated in the previous thread where you asked the same question, I
think for use in WebRTC, only #2 and #4 are usable and #1 and #3 are not.

On Mon, Oct 26, 2015 at 9:31 AM, Adam Roach <[e-mail]> wrote:

> Clearly, I made a tactical error by including a rather serious issue in
> the same email as a bikeshed. Now that we have a giant drying mount of
> multicolor paint that has well and truly buried that poor bikeshed to the
> point of unrecognizability, I'd like to bring our attention back around to
> something of substantially more import.
>
> I'll note that the subject of this email blithely gives four single-word
> options, but there's a lot of subtlety here. I've given it quite a bit of
> thought, and -- after a rather thorough analysis (which I summarize below)
> -- came to a conclusion that was completely unlike my original instinct on
> the topic. I would ask that you carefully read through the implications of
> each choice before responding.
>
> That said, I *do* implore you to respond.
>
> The draft currently says:
>
>    An offerer that is capable of using both simulcast stream
>    identification methods MAY include one "a=simulcast" line per
>    identification method in the offer.  Note that it is in general not
>    expected that the "pt" identification method will provide feature
>    parity with the "rid" method, and the different "a=simulcast" lines
>    can therefore express different use of simulcast functionality.
>    However, for some configurations the different identification methods
>    can be equivalent.
>
>    An answerer receiving an offer listing both simulcast stream
>    identification methods MUST choose only one and remove the other from
>    the answer.  An answerer not supporting a simulcast stream
>    identification method in the offer MUST remove the non-supported
>    "a=simulcast" line from the answer, possibly falling back to not
>    using simulcast at all.
>
>
> This is clearly aimed at making one or both of the PT and RID
> identifications mechanisms optional. The document does not contain (as far
> as I've found) normative language requiring support of one or the other.
> Although there are other possible combinations, it seems that we have a
> small handful of superficially plausible approaches for offer/answer usage.
> I'm sure someone will point out if I've missed something sensible:
>
>
>    1. PT is mandatory to implement, mandatory to include in offer. RID is
>    optional to implement, and may be included alongside PT in an offer.
>    2. RID is mandatory to implement, mandatory to include in offer. PT is
>    optional to implement, and may be included alongside RID in an offer.
>    3. Both PT and RID are mandatory to implement; the offerer can elect
>    to use either.
>    4. Neither PT nor RID are mandatory to implement. The offerer includes
>    one or both, depending on what it supports.
>
>
> #1 has the benefit of not requiring the extra machinery for the RID SDES
> and extension header for all implementations. This seems like a very mild
> advantage, given that it forces burning PTs on all possible simulcast
> variations, which pretty much defeats the reason for doing RID in the first
> place. Unless I'm mis-analyzing this, there's no way this could possible be
> viable.
>
> #2 avoids all the shortcomings documented in section 8.2 of simulcast-03,
> and avoids the "PT exhaustion issue." The additional bandwidth described in
> section 8.3 should be negligibly small: on the order of 4 additional bytes
> on a small handful of packets at stream startup, and periodically
> throughout the stream (e.g., when I-frames are transmitted).
> #3 avoids the PT exhaustion issue for #1, although it imposes the
> implementation complexity of both mechanisms on all implementations. Given
> that RID is significantly more flexible than PT, it's unclear why any
> implementation would choose to ever *send* PT in an offer under this model.
> Effectively, this resolves to a model of "everyone implements both but only
> ever uses RID." If that's where we're headed, let's just pull PT from the
> spec altogether.
>
> #4 avoids the mandatory complexity described in #3, although it remains
> unclear why anyone would choose to implement only PT under this model
> (again, referring back to the limitations of using PT). You'll have some
> RID-only implementations, and some PT/RID implementations. In other words,
> if we write this down, the implementation reality will actually be #2.
> (And, if it isn't, then we'll have groups of mutually incompatible
> implementations, whenever a PT-only client meets a RID-only client).
>
>
> I've heard it stated, in private conversations, that some parties wish to
> make PT mandatory to implement and RID optional to implement. That resolves
> to #1, which isn't workable (as I describe above). The only other option I
> can think of that is congruent with this statement would be making PT
> mandatory to implement, making RID optional to implement, and making both
> optional to include in an offer. In other words, you could have a RID-only
> offer, a PT-only offer, or an offer with both RID and PT. However, if the
> offer uses only RID, and the other end has not implemented the
> (optional-to-implement) RID mechanism, then you simply have a failure to
> interoperate.
>
>
> Based on the foregoing, it seems that the only sensible recommendation
> (other than removing PT altogether) is something like #2. I know that's
> backwards from what some people have been expecting; as a concession to
> people how want things to work that way, I tried to come up with some
> option that could sensibly make PT mandatory and RID optional, but I just
> don't see it. If you see a flaw in my analysis, point it out.
>
> /a
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>