>Just to add to what others have already said, we looked into this within >the SIP Parity AG of IMTC and concluded that while RFC 5939 is the >correct standards compliant way to achieve best effort security, >supporting the negotiation of crypto attributes using the RTP/AVP media >profile is useful for interworking with implementations that have not >yet added support for RFC 5939 to address this properly.
As one of the people behind best-effort-srtp (http://tools.ietf.org/html/draft-kaplan-mmusic-best-effort-srtp-01) I concur, and that's probably what they're trying to do. The problem with RFC 5939 (though I haven't looked at the final form) is that it's complex to implement and perhaps even more so to test, and when best-effort was written, we were a long way from RFC 5939 being done. Plus, to a degree, best-effort was documenting and standardizing an existing practice that people had independently decided was needed, which was a small subset of what Capabilities can do. >Cheers, >Charles > >> -----Original Message----- >> From: [email protected] >[mailto:sip-implementors- >> [email protected]] On Behalf Of Alan Johnston >> Sent: Monday, April 11, 2011 7:38 AM >> To: Nenad Milidrag >> Cc: Jean-Hugues Royer; [email protected] >> Subject: Re: [Sip-implementors] RTP/AVP with crypto attribute >> >> ZRTP also permits best-effort encryption: allowing SRTP to be used >> with the standards RTP/AVP profile in the SDP: >> >> http://tools.ietf.org/html/draft-zimmermann-avt-zrtp-22 >> >> - Alan - >> >> On Mon, Apr 11, 2011 at 8:58 AM, Nenad Milidrag <[email protected]> >wrote: >> > Hi Jean-Hugues, >> > >> > There is also a draft >> > http://tools.ietf.org/html/draft-kaplan-mmusic-best-effort-srtp-01, >that >> > was interpreting SAVP as SRTP only while AVP in combination with >crypto >> > is used as "best-effort SRTP". >> > >> > Regards, >> > Nenad >> > >> > >> > >> > -----Original Message----- >> > From: [email protected] >> > [mailto:[email protected]] On Behalf Of >> > Jean-Hugues Royer >> > Sent: Saturday, April 09, 2011 1:35 PM >> > To: [email protected] >> > Subject: [Sip-implementors] RTP/AVP with crypto attribute >> > >> > Hi, >> > >> > What is the recommended behavior when you receive a SDP offer with a >> > RTP/AVP media protocol including a crypto attribute ? >> > >> > Ignore the media ? Ignore the crypto attribute ? Process it as a >> > RTP/SAVP when SRTP is locally supported ? In that case answer with >> > a RTP/AVP or change it to a RTP/SAVP ? >> > >> > Is there any document that actually restricts the use of a crypto >> > attribute to a media with RTP/SAVP ? (RFC4568 doesn't) >> > >> > SNOM is one the several producers of such offers when they want to >> > optionally offer SRTP. >> > >> > Their argument for not using two medias (RTP/AVP & RTP/SAVP) by >> > default in the offer (as it should be) is that some proxies doesn't >> > support multiples medias, are you aware of such proxies ? >> > -- Randell Jesup, Worldgate (developers of the Ojo videophone) [email protected] _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
