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: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of
Ingemar
Johansson S
Sent: Monday, July 28, 2008 2:38 PM
To: avt at ietf.org
Cc: Colin Perkins; jo at acm.org
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
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt