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

[Byron Campen <[e-mail]>]

     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.

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

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