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

[Randell Jesup <rjesup at wgate.com>]

"Ingemar Johansson S" <ingemar.s.johansson at ericsson.com> writes:
>> >> What if an intermediary deletes the header extension?  (SBC, B2BUA,
>> >> raw message store, etc).
>> >There is of course a risk that this may happen.  However I am curious
>> >as to what extent this may actually happen as it would also cause the
>> >authentication to fail in case SRTP is used.
>> 
>> SRTP doesn't use header extensions.  (I think ZRTP was doing 
>> so, but I don't know if they kept that or if there were 
>> alternatives, and I think ZRTP just would consider that a 
>> case where the channel couldn't be secured if there's no 
>> alternative channel (RTCP?) for key exchange.)

>Maybe I misunderstand things here but..Tried to read through RFC3711 but
>I failed to find anything that metions something like that SRTP
>precludes the use of header extensions. It is correct that the header
>exension is sent as open information but I don't see this as an issue as
>long as the information in the header extension does not reveal any
>encrypted information. 

Header extensions are fine with SRTP (I've used them)>  You said:

   However I am curious as to what extent this may actually happen as it
   would also cause the authentication to fail in case SRTP is used.

You're correct that an SBC/B2BUA/etc can't just delete anything from an
SRTP packet (as you know).  (Extensions are authenticated but not
encrypted, so sensitive information cannot be transmitted in them.)  A
B2BUA typically would need to decrypt and re-encrypt anyways, and an SBC
might be able to depending on the key and encryption setup.  (For example,
if it's SIP-over-TLS with sdesc, then the SBC probably has access to the
encryption keys.)

However, quite a few SBC's/etc pretty much ignore SRTP and treat it like
RTP.  Also, using either best-effort-srtp methods or cap-neg drafts, the
SBC might not even be aware that the stream is an SRTP stream.

I worry most about things like Asterisk, which is a pseudo-B2BUA.  I
suspect strongly it doesn't pass-through header extensions.

>> The scheduling issues may mean that these extensions don't 
>> get transmitted for a while, but another issue is that the 
>> inserters of the extensions aren't always coordinated -- 
>> witness ZRTP which in the current implementation acts as a 
>> wrapper layer - if the main RTP stack adds an extension, that 
>> means that ZRTP can't use that packet for an extension.
>> This should be ok, and ZRTP has to account for this 
>> possibility (as well as packet loss).

>I believe that for cases like SVC and G.718 it should be possible to
>synchronize the transmission of "alignment-info" as the layers after all
>stem from the same encoder and it is probably in these cases that the
>need to ensure perfect alignment is the biggest (for audio codecs it
>must match to the sample) 

My point was that you can't synchronize with the prototypical ZRTP
implementation, since that occurs downstream of the encoder and main
application, in a black box (pseudo-proxy), so you have to leave enough
slots open for applications like that.

-- 
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