For outgoing calls send AES crypto in offer using corrected names
for keys of length 192 and 256, i.e. names containing _192_CM_
and _256_CM_ instead of _CM_192_ and CM_256_. For incoming calls
accept both naming conventions, decaying to same entry in SUITES.
+ fix after SRTP failed for 256 keys:
Tests showed loop removing '=' from keys in switch_core_media_build_crypto
1190 if (!switch_channel_var_true(channel, "rtp_pad_srtp_keys")) {
1191 p = strrchr((char *) b64_key, '=');
1192
1193 while (p && *p && *p == '=') {
1194 *p-- = '\0';
1195 }
1196 }
shouldn't be executed for AES_CM_256_HMAC_SHA1_32 and AES_CM_256_HMAC_SHA1_80
keys and it is meaningless for AES_CM_128_HMAC_SHA1_32 AES_CM_128_HMAC_SHA1_80
keys. Tested calling from Bria.
Introduced switch_channel_var_false and changed this to:
if (switch_channel_var_false(channel, "rtp_pad_srtp_keys"))
to enter the loop if var is set to false (and not if it is _not_ set).
For outgoing calls send AES crypto in offer using corrected names
for keys of length 192 and 256, i.e. names containing _192_CM_
and _256_CM_ instead of _CM_192_ and CM_256_. For incoming calls
accept both naming conventions, decaying to same entry in SUITES.
Previously rtp_secure_media_mki channel variable was checked only
for existence, now it is checked if it's defined and evaluates
to true with switch_channel_var_true().
MKI support for SRTP has been tested on calls to/from
Telnyx's Skype for Business from/to local extension registered to FS
and between Skype for Business clients connected to FreeSWITCH.
SfB -> FreeSWITCH -> User 1004
SRTP RTP
with
MKI
SfB <- FreeSWITCH <- User 1004
SRTP RTP
SfB <-> FreeSWITCH <-> SfB
SRTP/MKI SRTP/MKI
Channel variable "rtp_secure_media_mki" was added to drive offering
of MKI on outbound SRTP from FS.
How to use rtp_secure_media_mki
Set rtp_secure_media_mki=true to offer MKI for outgoing SRTP (if SRTP is used) in inbound call.
Export rtp_secure_media=true to offer MKI for outgoing SRTP (if SRTP is used) on outbound call.
... or set it in the codec string for bridged calls
<action application="set" data="rtp_secure_media_mki=true"/>
<action application="export" data="rtp_secure_media_mki=true"/>
<action application="bridge" data="[absolute_codec_string=^^:PCMU:PCMA:G729,rtp_secure_media=true,rtp_secure_media_mki=true]sofia/external/+12404373253@169.55.36.24:5060;transport=tls"/>
EXAMPLES
1. Set example
57 <extension name="telnyx_test_1_2">
58 <condition field="destination_number" expression="^(0012404373253)$">
59 <action application="set" data="rtp_secure_media=true"/>
60 <action application="set" data="rtp_secure_media_mki=true"/>
61 <action application="answer"/>
62 <action application="bridge" data="user/1004@${domain_name}"/>
63 </condition>
64 </extension>
Description: SRTP will be used on outbound leg in incoming call due to rtp_secure_media=true
set and MKI will be offered in SDP. SRTP will not be used on a bridged call to extension 1004.
2. Export example
75 <extension name="to_skype_for_business">
76 <condition field="destination_number" expression="^(840531022)$">
77 <action application="set" data="rtp_secure_media=optional"/>
78 <action application="export" data="rtp_secure_media_mki=true"/>
79 <action application="bridge" data="[absolute_codec_string=^^:PCMU:PCMA:G729,rtp_secure_media=true]sofia/external/+12404373728@169.55.36.24:5060;transport=tls"/>
80 </condition>
81 </extension>
Description: SRTP on inbound call has been set to optional therefore MKI will be used
on outbound SRTP in this call if SRTP is used at all. SRTP will be used on a bridged call
due to rtp_secure_media=true set in codec string and MKI will be used in offering SDP.
3. Bridging between Skype for Business clients: set
97 <extension name="S4B_fs_S4B">
98 <condition field="destination_number" expression="^(0012404373254)$">
99 <action application="set" data="rtp_secure_media=true"/>
100 <action application="set" data="rtp_secure_media_mki=true"/>
101 <action application="bridge" data="[absolute_codec_string=^^:PCMU:PCMA:G729,rtp_secure_media=true]sofia/external/+12404373253@169.55.36.$
102 </condition>
103 </extension>
Result:
2017-11-27 19:00:26.977704 [NOTICE] switch_ivr_originate.c:527 Ring Ready sofia/external/+12404373728@telnyxlab.com!
2017-11-27 19:00:32.657687 [NOTICE] switch_core_media.c:1534 Skipping MKI due to empty index
2017-11-27 19:00:32.657687 [INFO] switch_rtp.c:4079 Activating audio Secure RTP SEND
2017-11-27 19:00:32.657687 [INFO] switch_rtp.c:4057 Activating audio Secure RTP RECV
2017-11-27 19:00:32.657687 [NOTICE] sofia.c:8419 Channel [sofia/external/%2B12404373253@169.55.36.24:5060] has been answered
2017-11-27 19:00:35.317702 [INFO] switch_rtp.c:4079 Activating audio Secure RTP SEND (with MKI)
2017-11-27 19:00:35.317702 [INFO] switch_rtp.c:4057 Activating audio Secure RTP RECV (with MKI)
2017-11-27 19:00:35.317702 [NOTICE] sofia_media.c:92 Pre-Answer sofia/external/+12404373728@telnyxlab.com!
Description: SRTP with MKI is used on outbound leg of inbound call (due to use on inbound leg of this call and "set").
Standard SRTP is used in both legs of outbound call, because rtp_secure_media_mki wasn't exported
or set in codec string for the outbound call.
4. Bridging between Skype for Business clients: Set and export
97 <extension name="S4B_fs_S4B">
98 <condition field="destination_number" expression="^(0012404373254)$">
99 <action application="set" data="rtp_secure_media=true"/>
100 <action application="set" data="rtp_secure_media_mki=true"/>
101 <action application="export" data="rtp_secure_media_mki=true"/>
102 <action application="bridge" data="[absolute_codec_string=^^:PCMU:PCMA:G729,rtp_secure_media=true]sofia/external/+12404373253@169.55.36.24:5060;transport=tls"/>
103 </condition>
104 </extension>
Result:
2017-11-27 18:51:29.017689 [NOTICE] switch_ivr_originate.c:527 Ring Ready sofia/external/+12404373728@telnyxlab.com!
2017-11-27 18:51:35.097729 [INFO] switch_rtp.c:4079 Activating audio Secure RTP SEND (with MKI)
2017-11-27 18:51:35.097729 [INFO] switch_rtp.c:4057 Activating audio Secure RTP RECV (with MKI)
2017-11-27 18:51:35.097729 [NOTICE] sofia.c:8419 Channel [sofia/external/%2B12404373253@169.55.36.24:5060] has been answered
2017-11-27 18:51:37.797706 [INFO] switch_rtp.c:4079 Activating audio Secure RTP SEND (with MKI)
2017-11-27 18:51:37.797706 [INFO] switch_rtp.c:4057 Activating audio Secure RTP RECV (with MKI)
Description: Connecting Skype For Business client to Skype for Business client.
Send SRTP with MKI in both outbound streams:
- for inbound call: MKI was offered in incoming call and enabled for outbound leg with "set"
- for outbound call: MKI was enabled with "export"
5. Other examples
Setup to use SRTP with MKI only on the inbound SRTP on incoming call from Telnyx SfB
Tested dialing 0012404373253 from SfB to FS, leg SfB <-> FS uses SRTP with MKI
on inbound SRTP only
57 <extension name="telnyx_test_1_2">
58 <condition field="destination_number" expression="^(0012404373253)$">
59 <action application="set" data="rtp_secure_media=true"/>
61 <action application="answer"/>
62 <action application="bridge" data="user/1004@${domain_name}"/>
63 </condition>
64 </extension>
Result:
2017-11-23 20:44:35.406026 [INFO] mod_dialplan_xml.c:637 Processing Test02 <+12404373728>->0012404373253 in context public
2017-11-23 20:44:38.566022 [INFO] switch_rtp.c:4107 Activating audio Secure RTP SEND
2017-11-23 20:44:38.566022 [INFO] switch_rtp.c:4085 Activating audio Secure RTP RECV (with MKI)
Setup to send and receive SRTP with MKI on incoming call from Telnyx SfB
Tested dialing 0012404373253 from SfB to FS, leg SfB <-> FS uses SRTP with MKI
in both directions
57 <extension name="telnyx_test_1_2">
58 <condition field="destination_number" expression="^(0012404373253)$">
59 <action application="set" data="rtp_secure_media=true"/>
60 <action application="set" data="rtp_secure_media_mki"/>
61 <action application="answer"/>
62 <action application="bridge" data="user/1004@${domain_name}"/>
63 </condition>
64 </extension>
Result:
2017-11-23 20:42:06.026034 [INFO] mod_dialplan_xml.c:637 Processing Test02 <+12404373728>->0012404373253 in context public
2017-11-23 20:42:09.526034 [INFO] switch_rtp.c:4107 Activating audio Secure RTP SEND (with MKI)
2017-11-23 20:42:09.526034 [INFO] switch_rtp.c:4085 Activating audio Secure RTP RECV (with MKI)
Setup to offer MKI on outbound call to extension 1001 (X-Lite -> FS -> linphone)
Tested dialing 0012404373253 from user 1004, leg FS <-> 1001 uses SRTP with MKI
782 <extension name="telnyx_test_1_2">
783 <condition field="destination_number" expression="^(0012404373253)$">
784 <action application="export" data="rtp_secure_media_outbound=true"/>
785 <action application="export" data="rtp_secure_media_mki"/>
786 <action application="answer"/>
797 <action application="bridge" data="user/1001@${domain_name}"/>
798 </condition>
799 </extension>
Result:
2017-11-23 20:23:26.266034 [INFO] mod_dialplan_xml.c:637 Processing 1000 windows <1000>->0012404373253 in context default
2017-11-23 20:23:26.366035 [INFO] switch_rtp.c:4107 Activating audio Secure RTP SEND (with MKI)
2017-11-23 20:23:26.366035 [INFO] switch_rtp.c:4085 Activating audio Secure RTP RECV
SfB sometimes offers crypto with LIFETIME but no MKI index, e.g.:
a=crypto:5 AES_CM_128_HMAC_SHA1_80 inline:9OtFWi17H9E8ywlm0iazemjAqXu2RhJ3DZyo+VLJ|2^31
Defaulting to no-mki SRTP in case key material doesn't contain MKI index.
I ran into some ice failures when testing reinvites using
bypass_media_after_bridge. Every ice session has ice-ufrag and ice-pwd
attributes. When leg A sends those attributes to leg B, leg B is
supposed to send stun packets to leg A using the credentials provided in
those attributes. Freeswitch was not updating the session credentials
when the phone sent a new invite containing new ufrag and pwd
attributes. This caused ICE to fail on the client side (PJSIP in this
case).
The new_ice flag is set to true when freeswitch detects a change in
those attributes. For whatever reason, the reinvite flows that I was
testing did not set the CF_REINVITE flag on the channel, but new_ice was
true. It seems to me that freeswitch should always reactivate ice when
the ufrag and pwd credentials change.
Some clients rely on Base64 padding characters (i.e., '=') to be present
in encoded SRTP key/salt strings to determine the length of the encoded
data. However, FreeSWITCH removes these characters before including the
encoded strings in the SDP. This causes those clients that rely on the
padding to truncate the encoded data and be unable to properly set up an
encrypted SRTP session.
This change introduces a channel flag named 'rtp_pad_srtp_keys'. When
this flag is enabled, FreeSWITCH includes the Base64 padding characters
in the SDP. This allows clients that rely on the padding to retrieve the
full key and salt values and successfully negotiate an SRTP stream with
FreeSWITCH.
FS-103070 #resolve
Chris Rienzo