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

[Adam Roach <[e-mail]>]

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