Thank you Jonathan for clearing the air. Cheers, Aman
On Wed, Nov 8, 2017 at 11:35 PM, Jonathan Lennox <[email protected]> wrote: > 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][email protected]> 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][email protected] (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][email protected] > > > > References > > > > 1. mailto:[email protected] > > 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:[email protected] > > 7. https://tools.ietf.org/html/rfc3711 > > 8. https://tools.ietf.org/html/rfc3711 > > 9. mailto:[email protected] > > -- > Jonathan Lennox > [email protected] > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
