[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Some views on Secure RTP
Dan Wing wrote:
>> None of these are trivially interopable across protocol
>> boundaries because they all require changes to the
>> signalling channel, and some of them require a PKI
>> ZRTP "just works"
> Yes, most of the time ZRTP does just work. It is also available
> as an SDK so it's easy to plug it into existing software or
> run it underneath existing software without any software
> modifications. Fully agreed there.
> However, the reason it 'just works' is that it doesn't signal
> itself in the SIP/H.323/XMPP call signaling path. This is not
> without problems:
> Specifically, some networks have slotted schedulers -- such as 3GPP
> wireless networks and such as DOCSIS cable networks. In those
> networks, the bandwidth needed to run a codec is carefully calculated
> based on the SDP. When used with audio, SRTP typically adds 4 bytes
> to the length of the normal RTP payload. This additional 4 bytes
> exceeds the bandwidth of slotted schedulers. When this is exceeded,
> the packets are either dropped or given best-effort treatment (instead
> of being prioritized). This causes degradation in the voice quality.
> In order to work correctly on those networks, the bandwidth of SRTP
> needs to be properly signaled, and this is done by indicating RTP/SAVP
> in the SDP.
Well, I don't see any reason why a SIP application (SIP UAC) that uses
ZRTP cannot indicate RTP/SAVP in the SDP. Or is there any reason that
prohibits that? Indicating a profile is not relevant for security. If
it is not indicated it may disturb such networks but no harm to the
security is done, AFAIK
> Guidance provided by the MMUSIC and AVT working groups is that we need
> to signal the RTP profile (RTP/SAVP), so that such slotted schedulers
> can continue to their job of prioritizing media traffic and providing
> adequate bandwidth for that media traffic. It is for this reason that
> a subset of the MMUSIC working group have been working hard to
> complete draft-ietf-mmusic-sdp-capability-negotiation.
> I expect you are not using such a network with a slotted scheduler,
> and your response might be "so what". However, the remote peer
> you are communicating with might be on such a network, and in
> order to provide proper operation that remote network needs to
> know the bandwidth of the media. My point is that ZRTP will not
> 'just work' on such a network unless that network assumes all
> endpoints are using ZRTP and allocates additional bandwidth for
> the length of the (unsignaled) SRTP authentication tag.