[FS-5755] Allow better control over incoming/outgoing secure media offers Created: 03/Sep/13  Updated: 10/Mar/15  Resolved: 10/Mar/15

Status: Closed
Project: FreeSWITCH
Component/s: mod_sofia
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Kristian Kielhofner Assignee: Anthony Minessale II
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

CPU Architecture:
x86
Kernel:
Linux
Userland:
GNU/Linux
Compiler:
gcc
FreeSWITCH GIT Revision: All
GIT Master Revision hash:: All

 Description   
Ideally there would be "codec like" means to control inbound and outbound SRTP behavior. Currently setting sip_secure_media/rtp_secure_media doesn't seem to have the expected affect when compared to codecs, for example:

A leg endpoint sends the following SDP:

   v=0
   o=- 1377289399 1377289399 IN IP4 10.41.22.51
   s=Polycom IP Phone
   c=IN IP4 10.41.22.51
   t=0 0
   a=sendrecv
   m=audio 2222 RTP/SAVP 9 0 8 18 101
   a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:zXsSyzAa4QvE6ZtZDktSWqQSgvOvCrBprAmsMg9p
   a=rtpmap:9 G722/8000
   a=rtpmap:0 PCMU/8000
   a=rtpmap:8 PCMA/8000
   a=rtpmap:18 G729/8000
   a=fmtp:18 annexb=no
   a=rtpmap:101 telephone-event/8000
   m=audio 2222 RTP/AVP 9 0 8 18 101
   a=rtpmap:9 G722/8000
   a=rtpmap:0 PCMU/8000
   a=rtpmap:8 PCMA/8000
   a=rtpmap:18 G729/8000
   a=fmtp:18 annexb=no
   a=rtpmap:101 telephone-event/8000

If I wanted to select the codec I could parse ${ep_codec_string} and set ${absolute_codec} to the codec I wanted to select. I could also export absolute_codec to contain only the codecs I wanted to offer on the B leg. However, FreeSWITCH will automatically enable crypto in this case on the A leg because of the crypto offer. Ideally I could set sip_secure_media=false and FreeSWITCH would decline the crypto offer on the A leg, just like I can export sip_secure_media to offer crypto on the B leg today.

However, in this case the Polycom gives control of AES_CM_128_HMAC_SHA1_80, AES_CM_128_HMAC_SHA1_32, RTP/SAVP + RTP/AVP, RTP/SAVP only, etc. Ideally FreeSWITCH would also allow inbound and outbound control over the crypto suite selected/offered.

I'd also like the ability for FreeSWITCH to offer RTP/AVP + RTP/SAVP on the B leg for selection by the remote endpoint. It seems that allowing the export of "sip_secure_media=both" or "sip_secure_media=optional" might make sense for this.


 Comments   
Comment by Brian West [ 02/Oct/13 ]
These are working:

rtp_secure_media = true | AES_CM_128_HMAC_SHA1_32 | AES_CM_128_HMAC_SHA1_80

bgapi originate {absolute_codec_string=PCMU,rtp_secure_media=AES_CM_128_HMAC_SHA1_80}sofia/internal/sip:123@asdf.com &echo


2013-10-02 14:21:45.364538 [DEBUG] sofia_glue.c:1225 Local SDP:
v=0
o=FreeSWITCH 1380682555 1380682556 IN IP4 192.168.1.43
s=FreeSWITCH
c=IN IP4 192.168.1.43
t=0 0
m=audio 59150 RTP/SAVP 0 101 13
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:vNT3MFFcQeBD0u9DzZLHVV/kPir6poMqwMALTnbi
a=ptime:20
a=sendrecv
m=audio 59150 RTP/AVP 0 101 13
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv



bgapi originate {absolute_codec_string=PCMU,rtp_secure_media=AES_CM_128_HMAC_SHA1_32}sofia/internal/sip:123@asdf.com &echo



2013-10-02 14:22:09.244542 [DEBUG] sofia_glue.c:1225 Local SDP:
v=0
o=FreeSWITCH 1380683465 1380683466 IN IP4 192.168.1.43
s=FreeSWITCH
c=IN IP4 192.168.1.43
t=0 0
m=audio 58264 RTP/SAVP 0 101 13
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:S9+s7P2IQr8RtFgTpPwq6iXvnyjHuMCrvih+qLG4
a=ptime:20
a=sendrecv
m=audio 58264 RTP/AVP 0 101 13
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv
Comment by Brian West [ 02/Oct/13 ]
Needed:

Incoming:
rtp_secure_media=false (disallow 488 any SAVP only invite, fallback to AVP if invite offers SAVP)

Outbound:
rtp_secure_media=mandatory ( only offer SAVP)
rtp_secure_media=optional ( offer SAVP/AVP)

Move suite to:
rtp_secure_suite= AES_CM_128_HMAC_SHA1_32 | AES_CM_128_HMAC_SHA1_80

Thoughts?



Comment by Kristian Kielhofner [ 02/Oct/13 ]
That would be perfect.
Comment by Kristian Kielhofner [ 06/Nov/13 ]
Also, make sure to support AES-GCM mode (being worked on here):

http://jira.freeswitch.org/browse/FS-5937
Comment by Kristian Kielhofner [ 07/Nov/13 ]
Also, support at least parsing the crypto map lines defined in "big AES":

http://tools.ietf.org/html/rfc6188

Ideally these modes would be supported along with AES-GCM:

http://tools.ietf.org/html/draft-ietf-avtcore-srtp-aes-gcm-10
Comment by Git [ 23/Jan/14 ]
Repository: freeswitch
Branch: refs/heads/master
Commit: bd7182c http://fisheye.freeswitch.org/changelog/freeswitch/?cs=bd7182c
Updated By: anthm@freeswitch.org

Comment:
FS-5755 part 1


FreeSWITCH Support Contracts and Consulting Services available!

Contact us:
Email: consulting@freeswitch.org
Web: http://www.freeswitch.org
Phone: +1-918-420-9266
Tollfree: +1-877-742-2583
Fax: +1-918-420-9267
iNum: +883 5100 1420 9266


Come To ClueCon in August to learn more about FreeSWITCH and Internet Telephony!
http://www.cluecon.com

Comment by Anthony Minessale II [ 23/Jan/14 ]
outbound:
sdp_secure_savp_only=true true: only savp, false: both
rtp_secure_media can be set to AES_CM_128_HMAC_SHA1_32 or AES_CM_128_HMAC_SHA1_80 but not both at once.


inbound:
rtp_secure_media=false will disable srtp and reject if its the only offered method

Comment by Git [ 24/Feb/14 ]
Repository: freeswitch
Branch: refs/heads/master
Commit: b41d3a2 http://fisheye.freeswitch.org/changelog/freeswitch/?cs=b41d3a2
Updated By: anthm@freeswitch.org

Comment:
FS-5755 minor regression


FreeSWITCH Support Contracts and Consulting Services available!

Contact us:
Email: consulting@freeswitch.org
Web: http://www.freeswitch.org
Phone: +1-918-420-9266
Tollfree: +1-877-742-2583
Fax: +1-918-420-9267
iNum: +883 5100 1420 9266


Come To ClueCon in August to learn more about FreeSWITCH and Internet Telephony!
http://www.cluecon.com

Comment by Kristian Kielhofner [ 25/Feb/14 ]
You're going to hate me but now that FS-5937 is complete would it be possible to specify multiple crypto suites with rtp_secure_media on outbound:

rtp_secure_media=AEAD_AES_256_GCM_8,AES_CM_128_HMAC_SHA1_80

-or-

rtp_secure_media=AEAD_AES_256_GCM_8|AES_CM_128_HMAC_SHA1_80

To end up with an SDP from FS like this:

a=crypto:1 AEAD_AES_256_GCM_8 inline:46nPB0X2kuML6iJWkOkCLOzKcybBVYLurRBoKKbd5/HIlGNQ5TBmVqK3jSfIxQ==
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:xI1XRNeefUKObZKfgWZMV+sBo2KbRRPkPoGXeVJc
Comment by Git [ 27/Feb/14 ]
Repository: freeswitch
Branch: refs/heads/master
Commit: 3dad15f http://fisheye.freeswitch.org/changelog/freeswitch/?cs=3dad15f
Updated By: anthm@freeswitch.org

Comment:
FS-5755 part 2


FreeSWITCH Support Contracts and Consulting Services available!

Contact us:
Email: consulting@freeswitch.org
Web: http://www.freeswitch.org
Phone: +1-918-420-9266
Tollfree: +1-877-742-2583
Fax: +1-918-420-9267
iNum: +883 5100 1420 9266


Come To ClueCon in August to learn more about FreeSWITCH and Internet Telephony!
http://www.cluecon.com

Comment by Anthony Minessale II [ 27/Feb/14 ]
    rtp_secure_media=true
    --inbound: Accept the srongest supported offered crypto suite, MUST result in a negotiated crypto or aborts.
    
    --outbound: offer all supported crypto suites, MUST result in a negotiated crypto or aborts.
    
    rtp_secure_media=optional
    --inbound: Accept the srongest supported offered crypto suite, fall back to no crypto if no valid ones accepted.
    
    --outbound: offer all supported crypto suites, OPTIONAL result in a negotiated crypto falls back to no crypto.
    
    rtp_secure_media=<suite1>,<suiteN>
    --inbound: same behaviour as rtp_secure_media=true with smaller set of acceptable suites.
    --outbound: offer supplied crypto suites, same behaviour as rtp_secure_media=true with smaller set of suites.
Comment by Kristian Kielhofner [ 28/Feb/14 ]
There's a pretty significant behavior change here and I want to make sure it's documented/considered. With this commit if you don't have late-negotiation enabled on the profile incoming SRTP only offers will fail:

2014-02-28 19:53:56.905351 [WARNING] switch_core_media.c:1078 Crypto suite: [1 AES_CM_128_HMAC_SHA1_32 inline:gV+gGQRvACPCWw+hGbsWO+SkMGkFEywTXWtUcUmz] not valid in this context.
2014-02-28 19:53:56.905351 [WARNING] switch_core_media.c:1078 Crypto suite: [2 AES_CM_128_HMAC_SHA1_80 inline:gV+gGQRvACPCWw+hGbsWO+SkMGkFEywTXWtUcUmz] not valid in this context.

With late-negotiation enabled they will succeed, however, the strongest crypto suite is not the one selected by FreeSWITCH. FreeSWITCH will select the first crypto suite offered by the endpoint, even when it isn't the strongest:

   a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:9l+w0OyYSb97K22cppzTY5c10EhRj/Cnmqmz1JZM
   a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:9l+w0OyYSb97K22cppzTY5c10EhRj/Cnmqmz1JZM

return in 200 OK from FS:

   a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:MpyNMxtOHKPGlh7gx7HSatNNeZcoFzSJs4+y7GUc

However, if rtp_secure_media is limited to AES_CM_128_HMAC_SHA1_80 FreeSWITCH will negotiate that:

   a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:TKfrWiXdXWYr4bLKpii8tgMVW7oNJ6iGGBbiKgC2
   a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:TKfrWiXdXWYr4bLKpii8tgMVW7oNJ6iGGBbiKgC2

return in 200 OK from FS:

 a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:YGW45eFFRTiU5/FW6mzdlCpqcqW+M+kc0GzAfX6z
Comment by Git [ 04/Mar/14 ]
Repository: freeswitch
Branch: refs/heads/master
Commit: 84c0680 http://fisheye.freeswitch.org/changelog/freeswitch/?cs=84c0680
Updated By: mochouinard@moctel.com

Comment:
FS-5755 Fix regression if rtp_secure_media=false, it will force encryption.


FreeSWITCH Support Contracts and Consulting Services available!

Contact us:
Email: consulting@freeswitch.org
Web: http://www.freeswitch.org
Phone: +1-918-420-9266
Tollfree: +1-877-742-2583
Fax: +1-918-420-9267
iNum: +883 5100 1420 9266


Come To ClueCon in August to learn more about FreeSWITCH and Internet Telephony!
http://www.cluecon.com

Comment by Frank Carmickle [ 04/Mar/14 ]
As of master from March 3rd with rtp_secure_media=optional, I can setup calls from a polycom with srtp required, to both srtp and rtp endpoints. I can not receive calls from rtp endpoints, freeswitch transcoding rtp to srtp. It would be nice if optional always offered the highest security option to the B-leg even if the A-leg didn't have any crypto. Is this available as some other setting that I have missed?
Comment by Anthony Minessale II [ 04/Mar/14 ]
you can set the var in that B leg by defining the variable in the dial string brackets {rtp_secure_media=optional}
Comment by Frank Carmickle [ 04/Mar/14 ]
setting
{rtp_secure_media=optional}
in the dialstring for the particular user allows the phone to ring. When the call is answered no media flows in either direction but the call is up.

Setting
{rtp_secure_media=true}
allows the phone to ring. When the call is answered the A-leg falls through to voicemail.

Again for clarity, if rtp_secure_media isn't set than the phone will not ring.
Comment by Anthony Minessale II [ 04/Mar/14 ]
i'd need a trace. Maybe polycom is not able to handle the many keys at once. you can try setting it to a specific suite so there is only 1 in the offer.
Comment by Brian West [ 04/Mar/14 ]
I'm working to replicate some of these test scenarios.
/b
Comment by Brian West [ 04/Mar/14 ]
2014-03-04 16:41:57.983583 [DEBUG] sofia_glue.c:1225 sofia/internal/sip:1015@192.168.1.110:38565 sending invite version: 1.5.11b git 84c0680 2014-03-04 14:42:17Z 64bit
Local SDP:
v=0
o=FreeSWITCH 1393954509 1393954510 IN IP4 192.168.1.43
s=FreeSWITCH
c=IN IP4 192.168.1.43
t=0 0
m=audio 18408 RTP/SAVP 9 0 101 13
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=crypto:1 AEAD_AES_256_GCM_8 inline:OdYtWV+36/05uldbF6AtUfTuhPwpW0icVwTYVUuHLYYzY/uVk/3lKkDDotR8Hg
a=crypto:2 AEAD_AES_128_GCM_8 inline:lwZc6AJHy2lfvTMJjFaJfQeRpJ+UXFYXc0OjNcMm
a=crypto:3 AES_CM_256_HMAC_SHA1_80 inline:1s5uvawxsNx+thP5lcTosFigFPXWfkHe2kCxEwu7D6ry0SXIthekIW6kDt8g4Q
a=crypto:4 AES_CM_192_HMAC_SHA1_80 inline:sTnzmD5E+Rg341pBRD5Red4NJLDuksBzSjA31/6zXNyYDlos+zU
a=crypto:5 AES_CM_128_HMAC_SHA1_80 inline:12wDXZs/vw8Fka3DWd5UQUqwHYpIhFl7WHevw5uo
a=crypto:6 AES_CM_256_HMAC_SHA1_32 inline:so4AXLayif4XiZChQZPPVlx32Rir1dtNhXuWTNIDCdmpZeED9T5Yjv3Qr8WgoQ
a=crypto:7 AES_CM_192_HMAC_SHA1_32 inline:Tk17T5eLXOWlXvRSmQERhEh4KPIaCaMZWEv8Ns3VRuvm/llCT1A
a=crypto:8 AES_CM_128_HMAC_SHA1_32 inline:vCMwPaE9/fGRzdwrOTiBNZs6LULtEGDdysTsfaSX
a=crypto:9 AES_CM_128_NULL_AUTH inline:LTgP8DqDOAJhT7Fgfml8+ZtCN0y2Uiyz4iT7B+0M
a=ptime:20
a=sendrecv
m=audio 18408 RTP/AVP 9 0 101 13
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv

2014-03-04 16:41:59.643560 [DEBUG] sofia.c:6142 Channel sofia/internal/sip:1015@192.168.1.110:38565 entering state [completing][200]
2014-03-04 16:41:59.643560 [DEBUG] sofia.c:6152 Remote SDP:
v=0
o=- 1393972919 1393972919 IN IP4 192.168.1.110
s=Polycom IP Phone
c=IN IP4 192.168.1.110
t=0 0
m=audio 2224 RTP/SAVP 9 101
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=crypto:5 AES_CM_128_HMAC_SHA1_80 inline:0FUmO7bEP+1RjcOg/raAesQVmkul1+iYSNIwNUb8
m=audio 0 RTP/AVP 9 0 101 13
2014-03-04 16:41:59.643560 [INFO] switch_rtp.c:3150 Activating Audio Secure RTP SEND
2014-03-04 16:41:59.643560 [INFO] switch_rtp.c:3128 Activating Audio Secure RTP RECV
2014-03-04 16:41:59.643560 [DEBUG] switch_core_sqldb.c:2357 Secure Type: srtp:sdes:AES_CM_128_HMAC_SHA1_80
2014-03-04 16:41:59.643560 [DEBUG] switch_core_sqldb.c:2357 Secure Type: srtp:sdes:AES_CM_128_HMAC_SHA1_80

{rtp_secure_media=optional} Phone rings and answers echo app works fine.





Comment by Brian West [ 04/Mar/14 ]
2014-03-04 16:43:18.323538 [DEBUG] sofia_glue.c:1225 sofia/internal/sip:1015@192.168.1.110:38565 sending invite version: 1.5.11b git 84c0680 2014-03-04 14:42:17Z 64bit
Local SDP:
v=0
o=FreeSWITCH 1393949142 1393949143 IN IP4 192.168.1.43
s=FreeSWITCH
c=IN IP4 192.168.1.43
t=0 0
m=audio 23856 RTP/SAVP 9 0 101 13
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=crypto:1 AEAD_AES_256_GCM_8 inline:yg0fmIwAcNf3zD2OshFuv6Ckm/bNTes0SHGw1xs5Fvr7yah6GmPu8Vn10cPzUg
a=crypto:2 AEAD_AES_128_GCM_8 inline:YPn8FKaFYmScHbpmDYxxtuhJ4Ar/k5n6jsPo1m47
a=crypto:3 AES_CM_256_HMAC_SHA1_80 inline:3Lj5GXpe9Hu26avYwOLP8M07pgUlSCINmW2telC5V6HBtRcJQw05UAhWXWVXIw
a=crypto:4 AES_CM_192_HMAC_SHA1_80 inline:vqLZqPWCQP9je6AJbOnHDtg6agmtlwcVj+HDwBuYZy0brKli+B8
a=crypto:5 AES_CM_128_HMAC_SHA1_80 inline:0saId4bG8UpnUdHrUpGAFicn1wHuIbrdW1hksEBx
a=crypto:6 AES_CM_256_HMAC_SHA1_32 inline:pnnrEWpHv44Tl6iVXbOxfAt9JrDW9OaE0YFq+XIXrLT4rfpK9VoKTuF34VMRFg
a=crypto:7 AES_CM_192_HMAC_SHA1_32 inline:fmCDNdgu4cDO8BA2rflkY62/qVxEhOrt1sJtk87bEk9QAQpKg9Q
a=crypto:8 AES_CM_128_HMAC_SHA1_32 inline:sztfnH1nQjXu2TjHipmKkLUEqz3dfJXyd7R/3Xnu
a=crypto:9 AES_CM_128_NULL_AUTH inline:po5Gc7LDTWpxBuCBQ2DmYzzXMdTvvpMWnl9V5Ssg
a=ptime:20
a=sendrecv
m=audio 23856 RTP/AVP 9 0 101 13
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv




{rtp_secure_media=true} , Should mean mandatory, clearly it doesn't. I have these and more scenarios for testing, I can not get my Polycom to misbehave. Running 4.0.4.2906

/b
Comment by Brian West [ 04/Mar/14 ]
Its not the sleep its the fact you need to global_setvar rtp_secure_media=true on the inbound call prior t answer... no clue why I didn't recognize that till now.
Comment by Brian West [ 04/Mar/14 ]
Ok the issue with the inbound call is we don't automatically kick on SRTP anymore this was a behavior change from previous. The problem is the fact you need to set rtp_secure_media=true prior to answer on late-negotiation calls and it has to be set as a global on non-late-negotation setups.

With late-negotiation its now up to you to determine via regex to the SDP to tell if they support AVP and SAVP or one vs the other and set the appropriate variables.

/b
Comment by Brian West [ 04/Mar/14 ]
Also happy to report we properly roll the keys on hold/unhold with Polycom!

/b
Comment by Brian West [ 04/Mar/14 ]
Maybe we need rtp_secure_media=mandatory to only offer/accept an SAVP , In addition true should be both doing secure if offered and taking the most secure suite. Falling back to AVP if no crypto is offered.

Thoughts?

/b
Comment by Brian West [ 04/Mar/14 ]
Spoke with Tony you can set sdp_secure_savp_only=true to offer only savp. We may consider a mandatory setting to emulate that behavior for consistent.

/b
Comment by Git [ 04/Mar/14 ]
Repository: freeswitch
Branch: refs/heads/master
Commit: 6ae038a http://fisheye.freeswitch.org/changelog/freeswitch/?cs=6ae038a
Updated By: anthm@freeswitch.org

Comment:
FS-5755 84c06801530cbd64876a284f726fab505dc83a08 is wrong. It made optional enforce crypto.


FreeSWITCH Support Contracts and Consulting Services available!

Contact us:
Email: consulting@freeswitch.org
Web: http://www.freeswitch.org
Phone: +1-918-420-9266
Tollfree: +1-877-742-2583
Fax: +1-918-420-9267
iNum: +883 5100 1420 9266


Come To ClueCon in August to learn more about FreeSWITCH and Internet Telephony!
http://www.cluecon.com

Comment by Travis Cross [ 04/Mar/14 ]
To preempt Moc likely defending himself here, I'll note that Moc's commit wasn't actually so much wrong as just incomplete. Confusion is understandable, though, because:

if (!(switch_false(var) || !strcasecmp(var, "optional")))

contains a hefty number of double negatives. It would have been more clear had he written:

if (!switch_false(var) && strcasecmp(var, "optional"))

which is logically equivalent.

Either way it was incomplete because further down in the branch we had a test for !switch_true(var). While it is possible for a value to be both !switch_true and !switch_false, clearly it wasn't well thought through.
Comment by Marc Olivier Chouinard [ 05/Mar/14 ]
Thanks Travis, I actually I did it this way so the optimization will stop after switch_false() if it return true, so we don't have to do a strcasecmp if we don't have to. But since we just run that code 'once per call', I shouldn't have care that much. (second is I find the way I did it easier to understand than the second option)

I don't understand the logic for the setting -1 only when sdp_type == SDP_TYPE_REQUEST. for example, if -1, it seem to still check for crypto in the sdp, and if found, override the got_crypto with return from switch_core_session_check_incoming_crypto() which set the suite to true if not set to optional... and will print error about 'false' not being a valid suite.

So there still some clean up to be done there.

I think it should be made to default to secure media to false in the code rather than optional like it is right now. And enable either force or optional from those parameters. Then the logic might be easier to follow.
Comment by Marc Olivier Chouinard [ 05/Mar/14 ]
Also, may I suggest that rtp_secure_media be only of value true(optional)/false/mandatory, and use a different variable like rtp_secure_media_crypto to define the list of crypto allowed.
Comment by Travis Cross [ 05/Mar/14 ]
Here's the current tentative proposal:

rtp_secure_media=true ;; (default) we accept both SAVP and AVP offers and prefer the SAVP offer; we send both SAVP and AVP offers

rtp_secure_media=only ;; we accept only SAVP offers; we send only SAVP offers

rtp_secure_media=false ;; we accept only AVP offers; we send only AVP offers

inbound_rtp_secure_media=<X> ;; if set, on an inbound leg, set rtp_secure_media=<X>
outbound_rtp_secure_media=<X> ;; if set, on an outbound leg, set rtp_secure_media=<X>

rtp_cipher_prefs=AEAD_AES_256_GCM_8,AEAD_AES_128_GCM_8,AES_CM_256_HMAC_SHA1_80,AES_CM_192_HMAC_SHA1_80,AES_CM_128_HMAC_SHA1_80,AES_CM_256_HMAC_SHA1_32,AES_CM_192_HMAC_SHA1_32,AES_CM_128_HMAC_SHA1_32 ;; (default) the list of supported ciphers, and the order in which they should be preferred; on inbound channels we'll pick the first cipher in the offer that matches one of the ciphers in this list, or reject the call if no matching cipher is found; on outbound legs we offer the ciphers is this list in this order

inbound_rtp_cipher_prefs=<X> ;; if set, on an inbound leg, set rtp_cipher_prefs=<X>
outbound_rtp_cipher_prefs=<X> ;; if set, on an outbound leg, set rtp_cipher_prefs=<X>
Comment by Marc Olivier Chouinard [ 05/Mar/14 ]
I'm not sure I understand the use for the inbound_rtp_cipher_prefs... And maybe it should end with _inbound _outbound to keep the beginning the same. (unless we have a function inside FS that will auto copy the content of inbound_* or outbound_* to it variable name.

Without reading any documentation, rtp_secure_media=true mean force and not optional to me. I think rtp_secure_media=optional might be better.

One thing I suggest is that the code is done so it false by default, and only then, if we check the variable is not set that we enable it to optional (or true, depending what you decide in the end for the default). The idea behind this is that the part that enable srtp are clearly exposed in the code. It make it less probable to have errors that might lead to behaviour that is not what expected so if someone else try to change that part of code, he can clearly see what get srtp on and can make it easier to not break it. In the end it the same functionality, it just make it less prone to problems like we have right now and keep the code more structure.
Comment by Travis Cross [ 05/Mar/14 ]
Moc: The use of inbound_rtp_cipher_prefs would be to e.g. tell FS which cipher it should pick when given the choice by the offer, or to ensure certain ciphers are never chosen by excluding them from the list.

Regarding your parenthetical, as I said, the idea with inbound_* and outbound_* is that they are copied over to the * variable on bridge or (pre)answer.

Prefixing with inbound_ and outbound_ is better as it maintains consistency with inbound-codec-prefs and outbound-codec-prefs.

sip_secure_media has always meant optional, so this is less of a change than the alternative of setting true=mandatory. I would find true=mandatory more surprising, as I read rtp_secure_media=true as "enable SRTP" which doesn't imply "force SRTP" to me.

I don't fully follow your last paragraph. If the variables are not set by the user we should pick a reasonable cipher prefs list by default, and should accept both SAVP and AVP offers (preferring SAVP) and send both SAVP and AVP offers.
Comment by Git [ 05/Mar/14 ]
Repository: freeswitch
Branch: refs/heads/master
Commit: e5b2915 http://fisheye.freeswitch.org/changelog/freeswitch/?cs=e5b2915
Updated By: anthm@freeswitch.org

Comment:
FS-5755


FreeSWITCH Support Contracts and Consulting Services available!

Contact us:
Email: consulting@freeswitch.org
Web: http://www.freeswitch.org
Phone: +1-918-420-9266
Tollfree: +1-877-742-2583
Fax: +1-918-420-9267
iNum: +883 5100 1420 9266


Come To ClueCon in August to learn more about FreeSWITCH and Internet Telephony!
http://www.cluecon.com

Comment by Anthony Minessale II [ 05/Mar/14 ]
rtp_secure_media=mandatory
rtp_secure_media=optional
rtp_secure_media=mandatory:AES_CM_256_HMAC_SHA1_80,AES_CM_256_HMAC_SHA1_32
rtp_secure_media=optional:AES_CM_256_HMAC_SHA1_80
rtp_secure_media=forbidden

true implies mandatory
false implies forbidden
not set implies optional

rtp_secure_media_inbound or rtp_secure_media_outbound take precedence and are treated the same way based on leg direction
Comment by Marc Olivier Chouinard [ 05/Mar/14 ]
Travis, my reasoning for rtp_secure_media=true as mandatory is rtp secure media = true, it mean to be secure, so mandatory. If it was rtp_srtp_enable=true, then I would have agreed optional would make sense.

As for the inbound/outbound first or after... I don't care much, except that if it a standard feature, it would be ok and even useful: Eg: inbound_effective_caller_id_name="Inbound call". But I don't think this is the case now. having everything start with rtp_secure_media might be simpler though to script extracting of variable name and matching them together. But whatever you guys go... I just wanted to give my 2 cent on this one rather than say what should be done.

For my long comment, I know I wasn't clear (and the reason it was that long too). In the end, Tony patch look perfect. The only thing I find confusing still is the got_crypto variable and the implication of it value, but I won't play with that code, so don't change it for my sake.
Comment by Brian West [ 10/Mar/15 ]
We've done this, Please reopen if the controls we've done aren't what you were thinking, They are outlined in vars.xml in the latest tree.
Generated at Tue Sep 26 11:14:06 CDT 2017 using JIRA 7.3.3#73014-sha1:d5be8da522213be2ca9ad7b043c51da6e4cc9754.