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

[Suhas Nandakumar <[e-mail]>]

On Thu, Feb 4, 2016 at 11:42 AM, Byron Campen <[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 ?



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



> Nits/editorial:
>
> "there is need a way to"
>
> "This framework can be thought of as complementary extension"
>
> I think it would read better if the paragraph beginning with "The
> additional constraints on individual streams are indicated with a " would
> follow the paragraph beginning with "This specification defines a new SDP
> framework for constraining", since both discuss SDP and how rid interacts
> with other methods of constraining streams.
>
> "supported constraints in their offer, abd (b) having answerers ignore"
>
> "possible during near resolution change boundaries. "
>
> "Codec-specific configuration set via format parameters ("a=fmtp"); for
> example, the H.264 "max-fs" format parameter"
>
>     We should probably cite RFC 6185 here.
>
> "a=imgattr"
>
>     should be a=imageattr
>
> "The SDP given below skips few lines"
>
> Best regards,
> Byron Campen
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>