Re: [MMUSIC] Optional SRTP?

[Alan Johnston <alan at sipstation.com>]

Rick,

This is an important requirement that I call opportunistic media 
encryption.

Unfortunately, all the current solutions today require a separate RTP 
profile for secure vs. non-secure media.  As a result, a single media 
stream (m= line) must be either secure or non-secure.  The only solution 
today is to offer two separate SDP offers - one with a secure media 
stream, the other insecure, and send them as multipart alternative in 
SIP.  Unfortunately, support of mulitpart alternative is optional in SIP 
and causes many current UAs to crash and often doesn't even generate the 
correct error response.

Another bad alternative is to offer a secure SDP offer first, and then 
if it fails, send a second insecure SDP offer.

ZRTP (draft-zimmermann-avt-zrtp-01.txt) supports opportunistic media 
encryption because it is an extension to RTP and uses a normal m= line 
in the SDP.  If both endpoints support ZRTP, the session switches to 
SRTP.  If one side does not, the call continues as RTP.

Opportunistic encryption could be supported by other approaches as well 
if the a=crypto and a=key-mgt attributes could be used with a normal 
non-secure m= line.  As an optional attribute, the keying material would 
simply be ignored if the other UA does not support SRTP.

All devices that support opportunistic encryption also require a user 
interface to let the user know if the media is secure or insecure.  For 
example, audio tones or graphics can be used for this.

Thanks,
Alan

Rick Porter wrote:

> How do you make a call and optionally do SRTP? I'd like to have a single
> media stream that may do encryption, if the other end supports it.
>
> Thank you,
> Rick
>
> _______________________________________________
> mmusic mailing list
> mmusic at ietf.org
> https://www1.ietf.org/mailman/listinfo/mmusic
>
>
>  


_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic