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

[Byron Campen <[e-mail]>]

On 2/4/16 4:34 PM, Suhas Nandakumar wrote:
>
>
> On Thu, Feb 4, 2016 at 11:42 AM, Byron Campen <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>         As far as the open issues go, the proposals look fine to me.
>
>     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.
>
>
> [Suhas] Payload type asymmetry is a standard feature with SDP out of 
> RID. Should we really need to explicitly specify that fact ?
     I think so, because otherwise I predict lots of interop problems.

>
>     "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.
>
>
> [Suhas] There are 10 video codecs and need to express 3 different 
> resolutions. If I am not reading it wrong, the example shows just 
> using 10 codecs coupled with RID for defining varied resolutions 
> allows us not to exhaust the Payload Types.
>
> OTOH, if we remove the rid lines from the m= lines in the example and 
> express the resolutions as part of PT, then we will end up with 10 X 3 
> Payload Types.
>
    Each m-section has only 1 RID (because we're not doing simulcast), 
so there is no 3x multiplier here.

Best regards,
Byron Campen