Subject: Re: [AVT] RTCP_APP and RTCP guidelines

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 15 Aug 2009 23:39:20 -0400

Folks,

Notwithstanding the fact that we have an Internet Draft on this topic that
seems to discourage the use of RTCP extensions, they exist and there are
reasons for them in certain environments.  I apologize for dragging out a
message that's so old, but it's still relevant and I did not see a whole lot
of discussion on this topic this past year.

I think what Joerg has written in the I-D
(http://www.ietf.org/id/draft-ietf-avt-rtcp-guidelines-01.txt) provides good
guidance on extending RTCP.  However, since there are those cases where
folks want to define extensions and since I'm pragmatic person that believes
the world will not crumble to the ground because somebody somewhere is using
an extension that might border on the "unintended use" category, I think we
ought to define a generic extension mechanism and let standards organization
like 3GPP define messages for whatever purpose they see fit.

I'd propose something like this:

=================================

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V=2|P|  auth   |   PT=GEN=2xx  |             length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           SSRC/CSRC                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |E|                        message identifier                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             generic data                    ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

(Where "2xx" is some IANA assigned PT value.)

Where "auth" is the authority that assigns the message identifiers:
  0 = IETF
  1 = ETSI
  2 = ITU
  ...

Extension (E): 1 bit message identifier extension indicator.  If the
indicator is 0, then the message identifier that follows represents the last
of bits that comprise the message identifier.  If the indicator is 1, then
it means that there is another 32 bits immediately following that contains
another extension bit and message identifier bits.  All of the bits from all
message identifier fields are concatenated in network byte order to form the
message identifier.  If the first extension bit in the RTCP packet is set to
1, then the bits in the message identifier field in that 32-bit block must
have at least one non-zero bit. (This is to prevent left-padding bits with
zeros that have no significance.)

Message Identifier: These bits form an integer identifier that identify the
contents of the payload that is present as "generic data".

Generic Data: this shall be treated as binary data, the contents and meaning
of which are defined in a separate document that defines the particular
message identifier.

=================================

If we do not define something like this, then I would suspect folks will
continue to use APP packets (PT=204) and just hope the name does not
collide.

Perhaps this was debated at length somewhere (list of WG meeting), but I
didn't find anything when I searched that suggested there was a firm
conclusion.

What is the disposition of the group on this matter?

Paul

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ingemar
> Johansson S
> Sent: Monday, July 28, 2008 2:38 PM
> To: [email-masked]
> Cc: Colin Perkins; [email-masked]
> Subject: [AVT] RTCP_APP and RTCP guidelines
> 
> Hi
> 
> As I dare to say that there is atleast some kind of consensus that
RTCP_APP
> should be avoided.
> Lets pretend that we change all the RTCP_APP packets defined in 3GPP. The
> involved specs I know are.
> 3GPP TS 26.114
> and
> 3GPP TS 26.234
> If one decide to use the AVPF feedback types (205, 206) instead we need to
> fetch two numbers from the pool. In the payload-specific feedback messages
> pool there are currently 26 unused numbers, which means that one could
> probably use two of these numbers.
> 
> One problem I see is that many of the feedback messages are very
specialized
> towards one particular service or codec which may conflict with the strive
to
> define generic (feedback) messages. Also there is a risk of running out of
> numbers, something that, as I understand, can be solved with a few RTCP
> payload type number.
> 
> Organizations like 3GPP likes to get their standards set relatively fast
and
> this is one reason why RTCP_APP is the given choice. To avoid this the
> alternative must be almost equally simple. I does not need to be as
simple, I
> believe that in some cases it would be better to sit down and think about
the
> options (like is hinted in the draft).
> 
> Suppose that 3GPP sends a request for a AVPF feedback type for a new
service
> (could be an LS), what is the work order?, how is the new feedback number
> registered (a new RFC?). I beleieve that something that describes this
clearly
> would be good to have in the RTCP guidlines.
> 
> /Ingemar
> *******************************************
> Ingemar Johansson
> Senior Research Engineer, IETF "nethead"
> EAB/TVP - Multimedia Technologies
> Ericsson Research Ericsson AB
> Box 920 S-971 28 Luleå, Sweden
> Tel: +46 (0)8 4043042
> ECN: 850-43042
> ECC: 850-43074
> Mobile: +46 (0)730 783289
> *******************************************
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>

---

From: Colin Perkins <[email-masked]>
Date: Sun, 16 Aug 2009 10:31:58 +0100

Paul,

I'm perhaps missing your point, but I thought we already had such an  
extension mechanism: register a new RTCP packet type? The ITU, 3GPP,  
or other standards bodies can register them with IANA as easily as can  
the IETF.

Colin

On 16 Aug 2009, at 04:39, Paul E. Jones wrote:

> Folks,
>
> Notwithstanding the fact that we have an Internet Draft on this  
> topic that seems to discourage the use of RTCP extensions, they  
> exist and there are reasons for them in certain environments.  I  
> apologize for dragging out a message that's so old, but it's still  
> relevant and I did not see a whole lot of discussion on this topic  
> this past year.
>
> (http://www.ietf.org/id/draft-ietf-avt-rtcp-guidelines-01.txt)  
> provides good guidance on extending RTCP.  However, since there are  
> those cases where folks want to define extensions and since I'm  
> pragmatic person that believes the world will not crumble to the  
> ground because somebody somewhere is using an extension that might  
> border on the "unintended use" category, I think we ought to define  
> a generic extension mechanism and let standards organization like  
> 3GPP define messages for whatever purpose they see fit.
>
> indicator is 0, then the message identifier that follows represents  
> the last of bits that comprise the message identifier.  If the  
> indicator is 1, then it means that there is another 32 bits  
> immediately following that contains another extension bit and  
> message identifier bits.  All of the bits from all message  
> identifier fields are concatenated in network byte order to form the  
> message identifier.  If the first extension bit in the RTCP packet  
> is set to 1, then the bits in the message identifier field in that  
> 32-bit block must have at least one non-zero bit. (This is to  
> prevent left-padding bits with zeros that have no significance.)
>
> Message Identifier: These bits form an integer identifier that  
> identify the contents of the payload that is present as "generic  
> data".
>
> Generic Data: this shall be treated as binary data, the contents and  
> meaning of which are defined in a separate document that defines the  
> particular message identifier.
>
> If we do not define something like this, then I would suspect folks  
> will continue to use APP packets (PT=204) and just hope the name  
> does not collide.
>
> Perhaps this was debated at length somewhere (list of WG meeting),  
> but I didn't find anything when I searched that suggested there was  
> a firm conclusion.
>

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