<Ye-Kui.Wang at nokia.com> writes:
I tend to agree with Ingemar that the problem of the RTP header extension
mechanism is not serious. If the RTP header extension mechanism is based
on decoder order numbers of coded data units, then I think it is really
generic and applies to any layered or multi-source codec, including
flexible scalable video codecs such as SVC.
Ingemar Johansson writes;
I have a comment on
draft-schierl-avt-rtp-multi-session-transmission-00.txt
=============
7.2.6. RTP header extension
The RTP header extension may be used to add generic signaling about
Data Alignment to RTP packets.
7.2.6.1. Identified problems
RTP header extensions are required to be ancillary information which
can safely be discarded by receivers which do not understand them.
Data alignment mechanisms do not satisfy this requirement.
=============
My question is ..how serious is the identified problem ?.
My gut feeling is that a receiver that implements e.g decoding
of G.718 content will likely update the RTP stack to recognize
header extensions if header extensions are used to carry e.g
the NTP timestamp related to the RTP timetstamp in the RTP header.
What if an intermediary deletes the header extension? (SBC, B2BUA,
raw message store, etc).
This isn't to say it might not be a good idea - but requiring header
extensions to pass through may not be a good idea. You also have issues
where you can't use multiple header extensions in the same RTP packet, so
moving too much to them is a problem.