On Wednesday, November 8 2017, "Aman" wrote to "Jonathan Lennox, sip-implementors" saying:
> Thanks Jonathan for the details. > I see all of them are the drafts for the "Opportunistic SRTP" but not > the RFCs so isn't it the(sending the above SDP) is violation of RFC > 4568 if the offer-er supports it. > please pardon my knowledge on SRTP as I'm relatively new on this. > Cheers, > Aman Yes, RFC 4568 only defines what might be called unconditional SRTP -- i.e., an offer which indicates that the answerer's only options are either to do SRTP, or to reject the call entirely. If you do Opportunistic SRTP, you're indeed not in compliance with RFC 4568; instead you're doing something different, i.e. offering a third option. I suppose this could be called a "violation" of RFC 4568, but as the saying goes, "there are no protocol police". The documents I mentioned are indeed still just Internet-Drafts, meaning they haven't yet been finalized, but opportunistic SRTP has been in use for some time (see the Implementation Status section of the osrtp draft) and the current work is largely an effort to document and formalize existing implementations' behavior. > On Tue, Nov 7, 2017 at 11:08 PM, Jonathan Lennox > <[1]len...@cs.columbia.edu> wrote: > > On Tuesday, November 7 2017, "Aman" wrote to "sip-implementors" > saying: > > Hi All, > > > > Is sending the crypto attribute to secure the RTP with the media > line > > saying "RTP/AVP" is correct way to demonstrate remote end point to > choose > > if they want to have a secure RTP or non-secure RTP as per the RFC > 4568? > This is known as "opportunistic SRTP". It has been fairly common > practice > for over a decade, but is only now being formally standardized by > the IETF. > See [2]https://tools.ietf.org/html/draft-ietf-mmusic- > opportunistic-negotiation-01 > and [3]https://tools.ietf.org/html/draft-ietf-sipbrandy-osrtp-02 for > the > current work (the latter also includes some discussion of the > history), and > [4]https://tools.ietf.org/html/draft-kaplan-mmusic-best- > effort-srtp-01 for the > original proposal from 2006. > > I mean is following a correct SDP offer, > > > > v=0 > > o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 > > s=SDP Seminar > > i=A Seminar on the session description protocol > > u=[5]http://www.example.com/seminars/sdp.pdf > > e=[6]j....@example.com (Jane Doe) > > c=IN IP4 161.44.17.12/127 > > t=2873397496 2873404696 > > m=video 51372 RTP/AVP 31 > > a=crypto:1 AES_CM_128_HMAC_SHA1_80 > > inline:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj|2^20|1:32 > > m=audio 49170 RTP/AVP 0 > > a=crypto:1 AES_CM_128_HMAC_SHA1_32 > > inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 > > m=application 32416 udp wb > > a=orient:portrait > > > > If yes, so answerer can decide if they want to have a secure RTP > or not. > > > > but as per RFC 4568 section 6, it is not, but I have seen some > call-agents > > sending offer as above. > > > > ... > > > > SRTP security descriptions MUST only be used with the SRTP > transport > > (e.g., "RTP/SAVP" or "RTP/SAVPF"). The following specifies > security > > descriptions for the "RTP/SAVP" profile, defined in [RFC3711 > > <[7]https://tools.ietf.org/html/rfc3711>]. > > However, it is expected that other secure RTP profiles (e.g., > > "RTP/SAVPF") can use the same descriptions, which are in > accordance > > with the SRTP protocol specification [RFC3711 > > <[8]https://tools.ietf.org/html/rfc3711>]. > > > > ... > -- > Jonathan Lennox > [9]len...@cs.columbia.edu > > References > > 1. mailto:len...@cs.columbia.edu > 2. > https://tools.ietf.org/html/draft-ietf-mmusic-opportunistic-negotiation-01 > 3. https://tools.ietf.org/html/draft-ietf-sipbrandy-osrtp-02 > 4. https://tools.ietf.org/html/draft-kaplan-mmusic-best-effort-srtp-01 > 5. http://www.example.com/seminars/sdp.pdf > 6. mailto:j....@example.com > 7. https://tools.ietf.org/html/rfc3711 > 8. https://tools.ietf.org/html/rfc3711 > 9. mailto:len...@cs.columbia.edu -- Jonathan Lennox len...@cs.columbia.edu _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
