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

From: Byron Campen <[email-masked]>
Date: Thu, 4 Feb 2016 13:42:03 -0600

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

---

From: Suhas Nandakumar <[email-masked]>
Date: Thu, 4 Feb 2016 14:34:08 -0800

On Thu, Feb 4, 2016 at 11:42 AM, Byron Campen <[email-masked]> wrote:

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

> 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.
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>

---

From: Byron Campen <[email-masked]>
Date: Thu, 4 Feb 2016 16:46:29 -0600

On 2/4/16 4:34 PM, Suhas Nandakumar wrote:
>
>
> On Thu, Feb 4, 2016 at 11:42 AM, Byron Campen <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>         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.
>
>
> 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.
>
    Each m-section has only 1 RID (because we're not doing simulcast), 
so there is no 3x multiplier here.

Best regards,
Byron Campen

---

From: Adam Roach <[email-masked]>
Date: Fri, 5 Feb 2016 16:54:27 -0600

>     As far as the open issues go, the proposals look fine to me.

Hooray! That's two-for-two.

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

> 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