search

signalwire / freeswitch

FreeSWITCH is a Software Defined Telecom Stack enabling the digital transformation from proprietary telecom switches to a versatile software implementation that runs on any commodity hardware. From a Raspberry PI to a multi-core server, FreeSWITCH can unlock the telecommunications potential of any device.
https://freeswitch.com/#getting-started
Other
3.6k stars 1.42k forks source link

URGENT: Freeswitch one way audio issue with SRTP with slow media usecase #2246

Open premkumarramasamy opened 1 year ago

premkumarramasamy commented 1 year ago

Describe the bug There is an issue in freeswitch on slow media usecase(RFC3264 and RFC6337) with SRTP and Here is the description. When Freeswitch receives an ACK with SDP from other system, fs generates blindly creates a new key(master key + salt) and that was not shared to other system. This is causing decryption failures at other system because other system still have older key, freeswitch never shared the new key. Note: FS uses SRTP in this case.

To Reproduce Steps to reproduce the behavior:

  1. Create a Cube/VCube/SIPP to receive a call from freeswitch
  2. Execute a dial command to establishing a call from freeswitch to cube/sipp(Initial fs invite will have SDP with parama=crypto:7 AES_CM_128_HMAC_SHA1_80 inline:fs_encoded_key)
  3. Once the call established, send a RE-INVITE from cube/sipp to freeswitch(here SIPp sends only invite without SDP, this is called late media/slow media)
  4. FS sends 200OK for RE-INVITE and sends SDP along with it, where it contains the same key as in initial invite(SDP with parama=crypto:7 AES_CM_128_HMAC_SHA1_80 inline:same_fs_encoded_key)
  5. Then Cube/SIPp sends a ACK with SDP(SDP with parama=crypto:7 AES_CM_128_HMAC_SHA1_80 inline:sipp_encoded_key)
  6. Then Freeswitch internally creates new key for its own SRTP streams, that was not shared to SIPp/Cube that results in decryption failures.

Expected behavior Here there are two options available that FS should not change the key in this specific case and use the previous key(one issued in initial INVITE). So there will not be any encryption failures Other option is to send SIP Update to cube/SIPp, so that other system can get the new key to decrypt the audio packets.

Package version or git hash

Trace logs Sample Initial invite from freeswitch:

UDP SIP Message from SIP_LOADBAL_IP:5061 to CUBE_IP/SIPp_IP:5061
INVITE sip:+19722135002@abcserver.com;transport=tls SIP/2.0
Record-Route: <sip:SIP_LOADBAL_IP:5061;transport=tls;r2=on;lr=on>
Record-Route: <sip:SIP_LOADBAL_IP;r2=on;lr=on>
Via: SIP/2.0/TLS SIP_LOADBAL_IP:5061;branch=z9hG4bK5357.3d0598d2a20b5af67d53c9126ead0e76.0
Via: SIP/2.0/UDP FS_IP:5080;received=FS_IP;rport=5080;branch=z9hG4bK51yDHUyQF0KeN
Max-Forwards: 69
From: "agent1" <sip:+19722135001@SIP_LOADBAL_IP;otg=wcc_onsrx0naqlmgrwsuwfvkww0885_wcc;user=phone>;tag=27ZUtH5N53BFa
To: <sip:+19722135002@abcserver.com>
Call-ID: d600d1ce-a794-4b94-9c17-57ab7f4ba9f6
CSeq: 73141337 INVITE
Contact: <sip:gw+outbound-proxy@FS_IP:5080;transport=udp;gw=outbound-proxy>
User-Agent: FreeSWITCH-mod_sofia/1.10.10-release-24-4cb05e7f4a~64bit
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 576
X-BroadWorks-Correlation-Info: 2d884d9b-7ebe-483d-9d18-0f1cdf95cb05
X-RTMS-CID: aa4dd7f2-6f35-4124-9c4c-0d5c513ccb0b
X-FS-Support: update_display,send_info
Remote-Party-ID: "agent1" <sip:+19722135001@siprtms.com>;party=calling;screen=yes;privacy=off
Diversion: <sip:+19722135005@SIP_LOADBAL_IP;user=phone>;reason=follow-me
v=0
o=FreeSWITCH 1695369629 1695369630 IN IP4 FS_IP
s=FreeSWITCH
c=IN IP4 FS_IP
t=0 0
m=audio 20630 RTP/SAVP 0 8 101 13
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:13 CN/8000
a=rtcp-mux
a=rtcp:20630 IN IP4 FS_IP
a=crypto:2 AEAD_AES_256_GCM inline:LDQDs/5eAUrHM6Z6T385KBHEo6zcoecOSjbdXx19PvzLt6f33G4zWxsQ/HE=
a=crypto:4 AEAD_AES_128_GCM inline:+G7iSsmUPXtiVxvUoe9I30yJlxzjWQfGODcY6g==
a=crypto:7 AES_CM_128_HMAC_SHA1_80 inline:ntXmKQgDwh882/+DiGUAjdzI5t2cYc3ABGNTtIYN
a=ptime:20

RESPONSE from SIPp/Cube

UDP SIP Message from CUBE_IP/SIPp_IP:5061 to SIP_LOADBAL_IP:16280
SIP/2.0 200 OK
Via:SIP/2.0/TLS SIP_LOADBAL_IP:5061;branch=z9hG4bK5357.3d0598d2a20b5af67d53c9126ead0e76.0,SIP/2.0/UDP 10.192.134.33:5080;received=10.192.134.33;branch=z9hG4bK51yDHUyQF0KeN;rport=5080
From:"rtms-wxc-intg-us1 agent1"<sip:+19722135001@rt.intg-us1.rtmslab.net;user=phone;otg=wcc_onsrx0naqlmgrwsuwfvkww0885_wcc>;tag=27ZUtH5N53BFa
To:<sip:+19722135002@abcserver.com>;tag=1785632516-1695390259327
Call-ID:d600d1ce-a794-4b94-9c17-57ab7f4ba9f6
CSeq:73141337 INVITE
Contact:<sip:CUBE_IP/SIPp_IP:5061;transport=tls>
Record-Route:<sip:SIP_LOADBAL_IP:5061;transport=tls;r2=on;lr=on>,<sip:SIP_LOADBAL_IP;r2=on;lr=on>
Supported:
P-Asserted-Identity:"agent2"<sip:+19722135002@10.155.7.148;user=phone>
Privacy:none
Reason:broadworks;no-recon-on-answer
Allow:ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY
Accept:application/media_control+xml,application/sdp
X-BroadWorks-Correlation-Info:2d884d9b-7ebe-483d-9d18-0f1cdf95cb05
Session-ID:a700bf69008047db9984ab20af58a646;remote=026d28e800804b31b56fa880d59966bc
Content-Type:application/sdp
Content-Length:280
v=0
o=BroadWorks 439687 1695390263362 IN IP4 CUBE_IP/SIPp_IP_MEDIA_SERVER
s=-
c=IN IP4 CUBE_IP/SIPp_IP_MEDIA_SERVER
t=0 0
m=audio 20308 RTP/SAVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:eQW90MyTFoRuorHdA1P4cfBH7xROdB7eBJXTHESI

RE-INVITE from SIPp_IP/CUBE

UDP SIP Message from CUBE_IP/SIPp_IP:8934 to SIP_LOADBAL_IP:5061
INVITE sip:SIP_LOADBAL_IP:5061;transport=tls;r2=on;lr=on SIP/2.0
Via:SIP/2.0/TLS CUBE_IP/SIPp_IP:5061;branch=z9hG4bKBroadworksSSE.-SIP_LOADBAL_IPV5061-0-100-1785632516-1695390259327
From:<sip:+19722135002@abcserver.com>;tag=1785632516-1695390259327
To:"agent1"<sip:+19722135001@SIP_LOADBAL_IP;user=phone;otg=wcc_onsrx0naqlmgrwsuwfvkww0885_wcc>;tag=27ZUtH5N53BFa
Call-ID:d600d1ce-a794-4b94-9c17-57ab7f4ba9f6
CSeq:100 INVITE
Route:<sip:SIP_LOADBAL_IP;r2=on;lr=on>,<sip:gw+outbound-proxy@10.192.134.33:5080;transport=udp;gw=outbound-proxy>
Contact:<sip:CUBE_IP/SIPp_IP:5061;transport=tls>
P-Asserted-Identity:"agent2"<sip:+19722135002@10.155.7.148;user=phone>
Privacy:none
X-BroadWorks-Correlation-Info:2d884d9b-7ebe-483d-9d18-0f1cdf95cb05
Allow:ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY
Supported:
Accept:application/media_control+xml,application/sdp
Max-Forwards:69
Session-ID:a700bf69008047db9984ab20af58a646;remote=026d28e800804b31b56fa880d59966bc
Content-Length:0

200OK from FS to SIPp/Cube

UDP SIP Message from SIP_LOADBAL_IP:5061 to CUBE_IP/SIPp_IP:5061
SIP/2.0 200 OK
Via:SIP/2.0/TLS CUBE_IP/SIPp_IP:5061;branch=z9hG4bKBroadworksSSE.-SIP_LOADBAL_IPV5061-0-100-1785632516-1695390259327
From:<sip:+19722135002@abcserver.com>;tag=1785632516-1695390259327
To:"agent1"<sip:+19722135001@SIP_LOADBAL_IP;user=phone;otg=wcc_onsrx0naqlmgrwsuwfvkww0885_wcc>;tag=27ZUtH5N53BFa
Call-ID:d600d1ce-a794-4b94-9c17-57ab7f4ba9f6
CSeq:100 INVITE
Contact: <sip:gw+outbound-proxy@FS_IP:5080;transport=udp;gw=outbound-proxy>
User-Agent: FreeSWITCH-mod_sofia/1.10.10-release-24-4cb05e7f4a~64bit
Accept: application/sdp
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY
Supported: timer, path, replaces
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 349
v=0
o=FreeSWITCH 1695369629 1695369631 IN IP4 FS_IP
s=FreeSWITCH
c=IN IP4 FS_IP
t=0 0
m=audio 20630 RTP/SAVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=rtcp:20631 IN IP4 FS_IP
a=crypto:7 AES_CM_128_HMAC_SHA1_80 inline:ntXmKQgDwh882/+DiGUAjdzI5t2cYc3ABGNTtIYN
a=ptime:20

ACK from SIPp/Cube

UDP SIP Message from CUBE_IP/SIPp_IP:8934 to SIP_LOADBAL_IP:5061
ACK sip:SIP_LOADBAL_IP:5061;transport=tls;r2=on;lr=on SIP/2.0
Via:SIP/2.0/TLS CUBE_IP/SIPp_IP:5061;branch=z9hG4bKBroadworksSSE.-SIP_LOADBAL_IPV5061-0-100A1785632516-1695390259327
From:<sip:+19722135002@abcserver.com>;tag=1785632516-1695390259327
To:"agent1"<sip:+19722135001@SIP_LOADBAL_IP;user=phone;otg=wcc_onsrx0naqlmgrwsuwfvkww0885_wcc>;tag=27ZUtH5N53BFa
Call-ID:d600d1ce-a794-4b94-9c17-57ab7f4ba9f6
CSeq:100 ACK
Route:<sip:SIP_LOADBAL_IP;r2=on;lr=on>,<sip:gw+outbound-proxy@FS_IP:5080;transport=udp;gw=outbound-proxy>
Contact:<sip:CUBE_IP/SIPp_IP:5061;transport=tls>
X-BroadWorks-Correlation-Info:2d884d9b-7ebe-483d-9d18-0f1cdf95cb05
Max-Forwards:69
Session-ID:8843dac7ab2d4f3b8efb19cdb5c81c99;remote=026d28e800804b31b56fa880d59966bc
Content-Type:application/sdp
Content-Length:297
v=0
o=BroadWorks 439687 1695390264243 IN IP4 CUBE_IP/SIPp_IP_MEDIA_SERVER
s=-
c=IN IP4 CUBE_IP/SIPp_IP_MEDIA_SERVER
t=0 0
m=audio 20308 RTP/SAVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:ClFm7HEu+Xbc+DUZmrDfpwl57Nz1K6aeX7LtX4Ww

Is there any config to stop rotating the keys or some other workarounds to stop this issue?

briankwest commented 1 year ago

If you could kindly email brian@signalwire.com, We can discuss options for your URGENT issue.

premkumarramasamy commented 1 year ago

@briankwest, we have mailed you the details, Can you help us?

briankwest commented 1 year ago

@premkumarramasamy Can you attach your SIPP Scenario to this issue?

majortom81 commented 1 year ago

Hi,

I use freeswitch to convert SIP TLS/SRTP on clear SIP/RTP. I have the same issue. So far I extend timers as a workaround on TLS sip profile:

<param name="enable-timer" value="true"/>
<param name="minimum-session-expires" value="14400"/>
<param name="session-timeout" value="14400"/>

Is there a fix for this issue?

Thanks