[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [AVT] draft-schierl-avt-rtp-multi-session-transmission-00.txt



<Ye-Kui.Wang at nokia.com> writes:
>>>>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).
>
>What are the (good) reasons for an intermediary to delete header
>extensions? Isn't so that if there is something an intermediary does not
>understand, it'd better not to touch the something?

True - but if you modify the main package, passing through the header
extension becomes tricky.  For example, a B2BUA may leave the payload
alone, but almost always rewrites the RTP header, and may generate it's own
(or modify passed-through) RTCP packets.  If the header extension
references the header (sequence or timestamps), you could be broken.  Or if
the header extension references the SSRC, or data carried in the RTCP
stream (like NTP time), you could also be broken, and there's no way to
know if you don't understand (and comply with) the extension.

I mention things like this because Asterisk does those actions, I think.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
rjesup at wgate.com
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)

_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt