Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiation-12 - Colin's comments

From: Christer Holmberg <[email-masked]>
Date: Tue, 14 Oct 2014 18:06:13 +0000

Hi Colin,

Thanks for your comments! See inline.

>- Section 1, 7th paragraph: typo "a new RTP SDES item" -> "a new RTCP SDES item"

I actually use "RTP SDES item" and "RTP MID SDES item" terminology in quite a few places.

The reason is because that is what they are called in the IANA registry:

http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml#rtp-parameters-5

But, I have problem to change to "RTCP SDES item" if that is the correct terminology :)

------------------------

>- Section 10.1.1: the third bullet point says that a given SSRC "SHOULD NOT" transmit RTP >packets using payload types that originate from different bundled "m=" lines, and follows >this with an explanatory note. Given the problems that SSRC reuse will cause, I suggest >strengthening this to "MUST NOT", then adding a further note to address the case where >SSRC reuse works saying "However, once an SSRC has left the RTP session by sending an >RTCP BYE packet, that SSRC value can later be reused by another source, possibly on a >different bundled m= line". 

So, something like:

  o  A given SSRC MUST NOT transmit RTP packets using payload types
      that originate from different bundled "m=" lines.

   NOTE: The last bullet above is to avoid sending multiple media types
   from the same SSRC.  If transmission of multiple media types are done
   with time overlap, RTP and RTCP fail to function.  Even if done in
   proper sequence this causes RTP Timestamp rate switching issues
   [RFC7160]. However, once an SSRC has left the RTP session (by sending
   an RTCP BYE packet), that SSRC value can later be reused by another source
   (possible associated with a different bundled "m=" line.

------------------------

>- Section 10.3.1: the last sentence is unclear what separate 5-tuple will be used if RTP/RTCP >multiplexing is not enabled. This is explained in Section 10.3.2.3, and the draft would be >clearer if 10.3.1 referenced this.

While I agree that it would make the text clearer, I was asked to avoid forward referencing.

But, as 10.3.1 is a General section, I assume it doesn't matter.

------------------------

> - Section 13.2: it may be useful to clarify that the mid value is not zero terminated.

Can you suggest text? :)

------------------------

> - Section 13.3: again, clarify that the mid value is not zero terminated. It may also be useful > to remind implementers that the RFC 5285 format requires padding out to the next 32-bit 
> boundary using zero bytes if the size of the header extension isn't a multiple of 32 bits. This > padding could easily be confused with a terminating zero by a careless implementer.

Can you suggest text? :)

Regards,

Christer

---

From: Colin Perkins <[email-masked]>
Date: Tue, 14 Oct 2014 19:29:09 +0100

Hi,

On 14 Oct 2014, at 19:06, Christer Holmberg <[email-masked]> wrote:
> But, I have problem to change to “RTCP SDES item" if that is the correct terminology :)

It’s not especially important; I just want to make sure it’s not confused with RTP security descriptions, which is sometimes referred to as SDES.

> ————————————

Sure.

> But, as 10.3.1 is a General section, I assume it doesn't matter.

“The mid value is not zero terminated”

“The mid value is not zero terminated. Note, however, that RTP header extensions that are not a multiple of 32 bits in length MUST be padded to the next 32-bit boundary using zero bytes; these padding bytes are not included in the header length field [RFC5285].”

-- 
Colin Perkins
https://csperkins.org/

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 15 Oct 2014 19:25:04 +0000

Hi Colin,

> It's not especially important; I just want to make sure it's not confused with RTP security descriptions, which is sometimes referred to as SDES.

You know better than me what terminology is used out there :)

------------------------
 
> "The mid value is not zero terminated"

Ok :)

------------------------
 
>>> - Section 13.3: again, clarify that the mid value is not zero 
>>> terminated. It may also be useful to remind implementers that the RFC 5285 format requires 
>>> padding out to the next 32-bit boundary using zero bytes if the size of the header extension 
>>> isn't a multiple of 32 bits. This > padding could easily be confused with a terminating zero by 
>>> a careless implementer.
>> 
>> Can you suggest text? :)
>
> "The mid value is not zero terminated. Note, however, that RTP header extensions that are not a multiple of 32 bits in length MUST be padded to the next 32-bit boundary using zero 
> bytes; these padding bytes are not included in the header length field [RFC5285]."

Thanks!

Regards,

Christer

---

From: Stephen Casner <[email-masked]>
Date: Wed, 15 Oct 2014 17:02:20 -0700 (PDT)

> http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml#rtp-parameters-5

Aha.  The registry title should be changed.

                                                        -- Steve

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 16 Oct 2014 11:46:28 +0000

Hi Stephen,

So, I will use "RTCP SDES" terminology.

Anything I need to do in order to change the registry title? I guess that cannot be done as an IANA consideration within the draft, can it?

Regards,

Christer

-----Original Message-----
From: Stephen Casner [mailto:[email-masked]] 
Sent: 16. lokakuuta 2014 3:02
To: Christer Holmberg
Cc: Colin Perkins; Flemming Andreasen; [email-masked]; mmusic
Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-sdp-bundle-negotiation-12 - Colin's comments

                                                        -- Steve

---

From: Stephen Casner <[email-masked]>
Date: Thu, 16 Oct 2014 08:34:54 -0700 (PDT)

Christer,

> So, I will use "RTCP SDES" terminology.

Good.

> Anything I need to do in order to change the registry title? I guess
> that cannot be done as an IANA consideration within the draft, can
> it?

I agree that this does not belong in the IANA considerations of your
draft.  Instead, I think the change should just be a direct request to
IANA.  I note that the immediately preceding registry on the same page
is "RTCP Control Packet types (PT)", so that one is correctly named.
I also see that in the Note section of the "RTP SDES item types"
registry says that the list of item types is "for the RTCP SDES
control packet".  Thus, I would not expect IANA to object to the
change.

For the "RTCP Control Packet types (PT)" registry, Magnus and I are
listed as experts, but there are no experts listed for the "RTP SDES
item types" registry.  I could send a message to IANA, but it might be
more appropriate for the request to come from the AVTCORE WG, that is,
from the current chair.

                                                        -- Steve