Re: [MMUSIC] Comments on draft-ietf-mmusic-rid-02

[Adam Roach <[e-mail]>]

On 2/4/16 13:42, Byron Campen wrote:
>     As far as the open issues go, the proposals look fine to me.

Hooray! That's two-for-two.

> Issues:
>
>     In section 6.4, step 5, we might want to point out that the 
> offerer cannot simply look at the list of payload types, since the 
> answerer may be using payload type asymmetry. The offerer will need to 
> map each payload type to a codec description on both sides, and then 
> make sure the set of codec descriptions for that rid in the answer is 
> a subset of those in the offer.

Good point. This is pretty easy to understand, but ended up being more 
difficult to describe than I expected. :)

5. If the "a=rid" line in the answer contains a "pt=" and the
    offer did as well, the offerer verifies that the list of payload 
types is a
    subset of those sent in the corresponding "a=rid" line in the offer. 
Note
    that this matching must be performed semantically rather than on 
literal PT
    values, as the remote end may not be using symmetric PTs. For the 
purpose
    of this comparison: for each PT listed in the "pt=", the offerer 
looks up
    the "a=rtpmap" and "a=fmtp" lines in the answer.  It then searches 
the list
    of "pt=" values indicated in the offer, and attempts to find one with an
    equivalent set of "a=rtpmap" and "a=fmtp" lines in the offer. If all 
PTs in
    the answer can be matched, then the "pt=" values pass validation;
    otherwise, it fails.  If this validation fails, the offerer SHALL 
discard
    the "a=rid" line.


> "Expressing all these codecs and resolutions using 32 dynamic PTs (2 
> audio + 10x3 video) would exhaust the primary dynamic space (96-127). 
> RIDs are used to avoid PT exhaustion and express the resolution 
> constraints."
>
>     This is not adding up for me, because there is no requirement that 
> PTs be unique across m-sections. The sendrecv m-section for video 
> needs 10 PTs, but the other m-sections can overlap that. It might be 
> kinda tricky to come up with a scenario that exceeds 32 without 
> simulcast, but I don't really see why we need to talk about PT 
> exhaustion in the RID spec, since that's more of a simulcast concern.

I think you're right. I'm striking the paragraph.

> Nits/editorial:
Fixed. Thanks.

Dropping a -03 soon.

/a