After many talks and various vendors and more reading RFC3711 and RFC4568 below is what we have determined to be correct for SRTP negotiation in the SDP over TLS: Here is how the SDP's should look in all three cases: On but optional/preferred: v=0 o=root 1130561626 1130561626 IN IP4 10.0.1.241 s=call c=IN IP4 10.0.1.241 t=0 0 m=audio 52970 RTP/SAVP 9 0 8 2 3 18 4 101 a=rtpmap:9 g722/8000 a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:2 g726-32/8000 a=rtpmap:3 gsm/8000 a=rtpmap:18 g729/8000 a=rtpmap:4 g723/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:WvPreyjK82pM0I5vtUY2zkpIKPbRVSKH1QcPrsWP a=ptime:60 m=audio 52970 RTP/AVP 9 0 8 2 3 18 4 101 a=rtpmap:9 g722/8000 a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:2 g726-32/8000 a=rtpmap:3 gsm/8000 a=rtpmap:18 g729/8000 a=rtpmap:4 g723/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:60 On but Manditory: v=0 o=root 1130561626 1130561626 IN IP4 10.0.1.241 s=call c=IN IP4 10.0.1.241 t=0 0 m=audio 52970 RTP/SAVP 9 0 8 2 3 18 4 101 a=rtpmap:9 g722/8000 a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:2 g726-32/8000 a=rtpmap:3 gsm/8000 a=rtpmap:18 g729/8000 a=rtpmap:4 g723/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:WvPreyjK82pM0I5vtUY2zkpIKPbRVSKH1QcPrsWP a=ptime:60 Off not offered/Not Supported: v=0 o=root 1130561626 1130561626 IN IP4 10.0.1.241 s=call c=IN IP4 10.0.1.241 t=0 0 m=audio 52970 RTP/AVP 9 0 8 2 3 18 4 101 a=rtpmap:9 g722/8000 a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:2 g726-32/8000 a=rtpmap:3 gsm/8000 a=rtpmap:18 g729/8000 a=rtpmap:4 g723/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:60 I would like some feedback on this as I'm getting what seems to be some push back from vendors that do this incorrectly. i.e. having crypto lines in an RTP/AVP which is wrong. You should never have crypto lines in an RTP/AVP they belong in the RTP/SAVP profile as per RFC3711. I'm working with as many vendors as I can to ensure that they all behave the same way. Can someone tell me if I'm wrong here? Polycom already does it like this, snom should be following suit and i'm working with Grandstream and Aastra right now on this. In addition a vendor shouldn't turn on the padlock/secure logo if the exchange didn't take place over TLS. Thanks, Brian West FreeSWITCH.org