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