[SR-Users] rtpengine - SRTP <> RTP missing a=crypto
Richard Fuchs
rfuchs at sipwise.com
Thu Mar 3 14:05:48 CET 2022
Are there multiple branches involved? Is the same invite being processed
(and manipulated by rtpengine) multiple times, perhaps with different
options (e.g. once for RTP and once for SRTP)?
Cheers
On 03/03/2022 06.07, [EXT] Rhys Hanrahan wrote:
>
> Hi Everyone,
>
> I have Kamailio sitting between MS Teams and Asterisk, and using
> rtpengine to terminate SRTP on Kamailio so that all my internal
> traffic is unencrypted. My current config works fine for inbound calls
> where I initiate the INVITE and Teams responds, but if Teams sends the
> INVITE I am having an issue where SRTP cannot finish negotiating. Non
> SRTP calls work fine with RTPEngine as well, so it’s just the RTP to
> SRTP I am struggling with.
>
> According to this I believe I must pass a=crypto in response to the
> INVITE which also has a=crypto:
> https://www.dialogic.com/-/media/1f8b54b43087407d9c2b38846c5c2cb5.ashx?h=408&w=622
> <https://www.dialogic.com/-/media/1f8b54b43087407d9c2b38846c5c2cb5.ashx?h=408&w=622>
>
> You can see that in the initial invite from Teams, I get RTP/SAVP with
> a=crypto, but I do not send one in my OK response after 183 Session In
> Progress. *As below – I am wondering if it’s because not all audio
> channels seem to be getting swapped to SAVP?*
>
> I’d like to do a generic SRTP <> RTP bridge config (I’ve tried below).
> However, I am not 100% sure on how to detect when to swap between AVP
> and SAVP, so I’ve also tried just doing rtpengine_manage() and relying
> on other code to swap between SAVP or AVP **only** when going to/from
> Teams to keep it simple. I also tried both with and without
> “replace-origin replace-session-connection ICE=remove” but I still get
> the same behaviour in all cases.
>
> Any advice appreciated, as this is my first time dealing with SRTP
> (and rtpengine). Feeling very stuck. Thanks!
>
> branch_route[MANAGE_BRANCH] {
>
> …
>
> route(NATMANAGE);
>
> route(HANDLE_SRTP);
>
> }
>
> onreply_route[MANAGE_REPLY] {
>
> xdbg("incoming reply\n");
>
> if(status=~"[12][0-9][0-9]") {
>
> route(NATMANAGE);
>
> }
>
> route(HANDLE_SRTP);
>
> }
>
> route[HANDLE_SRTP] {
>
> if (!has_body("application/sdp")) {
>
> return;
>
> }
>
> rtpengine_manage();
>
> return; # As a test, just do rtpengine_manage() and set
> SAVP/AVP elsewhere. Same behaviour.
>
> # Handle bridging of RTP and SRTP
>
> # Inbound traffic to SBC should be converted from SRTP to RTP
>
> if (proto==TLS) {
>
> rtpengine_manage("RTP/AVP");
>
> # Outbound traffic destined to a TLS destination should be
> converted from RTP to SRTP
>
> } else if ($ru =~ "transport=tls") {
>
> rtpengine_manage("RTP/SAVP");
>
> }
>
> }
>
> # INVITE from teams
>
> rtpengine_manage("replace-origin replace-session-connection ICE=remove
> RTP/AVP");
>
> # INVITE to teams
>
> rtpengine_manage("replace-origin replace-session-connection ICE=remove
> RTP/SAVP");
>
> INVITE
> sip:+614xxxx at rh.sbc-syd-01.teams.xxxx:5061;user=phone;transport=tls
> SIP/2.0^M
>
> …
> v=0^M
> o=- 57931 0 IN IP4 127.0.0.1^M
> s=session^M
> c=IN IP4 52.113.76.53^M
> b=CT:10000000^M
> t=0 0^M
> *m=audio 51398 RTP/SAVP 104 9 103 111 18 0 8 97 101 13 118^M*
> c=IN IP4 52.113.76.53^M
> a=rtcp:51399^M
> a=ice-ufrag:C8ss^M
> a=ice-pwd:2bV9D6GcXF5f8m0px/wufQD/^M
> a=rtcp-mux^M
> a=candidate:1 1 UDP 2130706431 52.113.76.53 51398 typ srflx raddr
> 10.0.32.179 rport 51398^M
> a=candidate:1 2 UDP 2130705918 52.113.76.53 51399 typ srflx raddr
> 10.0.32.179 rport 51399^M
> a=candidate:2 1 tcp-act 2121006078 52.113.76.53 49152 typ srflx raddr
> 10.0.32.179 rport 49152^M
> a=candidate:2 2 tcp-act 2121006078 52.113.76.53 49152 typ srflx raddr
> 10.0.32.179 rport 49152^M
> a=label:main-audio^M
> a=mid:1^M
> *a=crypto:1 AES_CM_128_HMAC_SHA1_80
> inline:geUHLB1mshmnI5hN83bnO57Hbdm2i7dD14sDAnpA|2^31^M*
> a=sendrecv^M
> a=rtpmap:104 SILK/16000^M
> a=rtpmap:9 G722/8000^M
> a=rtpmap:103 SILK/8000^M
> a=rtpmap:111 SIREN/16000^M
> a=fmtp:111 bitrate=16000^M
> a=rtpmap:18 G729/8000^M
> a=fmtp:18 annexb=no^M
> a=rtpmap:0 PCMU/8000^M
> a=rtpmap:8 PCMA/8000^M
> a=rtpmap:97 RED/8000^M
> a=rtpmap:101 telephone-event/8000^M
> a=fmtp:101 0-16^M
> a=rtpmap:13 CN/8000^M
> a=rtpmap:118 CN/16000^M
> a=ptime:20^M
>
> I correctly convert to/from RTP/AVP and RTP/SAVP for the 183 Session
> in progress. It is RTP/SAVP before going to Teams:
>
> SIP/2.0 183 Session Progress^M
>
> …
>
> v=0^M
> o=- 57931 2 IN IP4 1.2.3.4^M
> s=NexusOne^M
> c=IN IP4 1.2.3.4^M
> t=0 0^M
> *m=audio 37820 RTP/SAVP 9 8 0 101^M*
> a=maxptime:150^M
> a=mid:1^M
> a=rtpmap:9 G722/8000^M
> a=rtpmap:8 PCMA/8000^M
> a=rtpmap:0 PCMU/8000^M
> a=rtpmap:101 telephone-event/8000^M
> a=fmtp:101 0-16^M
> a=sendrecv^M
> a=rtcp:37821^M
> a=ptime:20^M
> *m=audio 0 RTP/AVP 104 9 103 111 18 0 8 97 101 13 118^M
> m=audio 0 RTP/AVP 104 9 103 111 18 0 8 97 101 13 118^M*
>
> But then when I send the OK after the 183, I am setting RTP/SAVP
> before sending to MS Teams, but not setting a=crypto:
>
> *Also note that I can see there are _/some/_ channels still as RTP/AVP
> so maybe this is part of the issue.*
>
> SIP/2.0 200 OK^M
>
> …
>
> v=0^M
> o=- 57931 2 IN IP4 1.2.3.4^M
> s=NexusOne^M
> c=IN IP4 1.2.3.4^M
> t=0 0^M
> *m=audio 37820 RTP/SAVP 9 8 0 101^M
> *a=maxptime:150^M
> a=mid:1^M
> a=rtpmap:9 G722/8000^M
> a=rtpmap:8 PCMA/8000^M
> a=rtpmap:0 PCMU/8000^M
> a=rtpmap:101 telephone-event/8000^M
> a=fmtp:101 0-16^M
> a=sendrecv^M
> a=rtcp:37821^M
> a=ptime:20^M
> *m=audio 0 RTP/AVP 104 9 103 111 18 0 8 97 101 13 118^M
> m=audio 0 RTP/AVP 104 9 103 111 18 0 8 97 101 13 118^M*
>
>
> *Rhys Hanrahan* | Chief Information Officer
> *e:* rhys at nexusone.com.au <mailto:rhys at nexusone.com.au>
>
> www.nexusone.com.au <http://www.nexusone.com.au/>signature_1116663581
> <http://www.fusiontech.com.au/>
> *
> **NEXUS ONE****|** FUSION TECHNOLOGY SOLUTIONS
> **p:* 1800 NEXUS1 (1800 639 871) or 1800 565 845 *|* *a:* Suite 12.03
> Level 12, 227 Elizabeth Street, Sydney NSW 2000
> www.nexusone.com.au <http://www.nexusone.com.au/> *|*
> www.fusiontech.com.au <http://www.fusiontech.com.au/>
>
> /The information in this email and any accompanying attachments may
> contain; a. Confidential information of Fusion Technology Solutions
> Pty Ltd, Nexus One Pty Ltd or third parties; b. Legally privileged
> information of Fusion Technology Solutions Pty Ltd, Nexus One Pty Ltd
> or third parties; and or c. Copyright material Fusion Technology
> Solutions Pty Ltd, Nexus One Pty Ltd or third parties. If you have
> received this email in error, please notify the sender immediately and
> delete this message. Fusion Technology Solutions Pty Ltd, Nexus One
> Pty Ltd does not accept any responsibility for loss or damage arising
> from the use or distribution of this email./
>
> /Please consider the environment before printing this email./
>
>
> __________________________________________________________
> Kamailio - Users Mailing List - Non Commercial Discussions
> *sr-users at lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the sender!
> Edit mailing list options or unsubscribe:
> *https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20220303/38cbe32f/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 13849 bytes
Desc: not available
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20220303/38cbe32f/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 9101 bytes
Desc: not available
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20220303/38cbe32f/attachment-0001.png>
More information about the sr-users
mailing list