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...
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@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@nexusone.com.aumailto:rhys@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.auhttp://www.nexusone.com.au/ | www.fusiontech.com.auhttp://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.
On 03.03.22 12:07, Rhys Hanrahan wrote:
Any advice appreciated, as this is my first time dealing with SRTP (and rtpengine). Feeling very stuck. Thanks!
Yeah, me too. ;-)
Basically you need to call "rtpengine_manage" with the correct parameter, i.e. either RTP/AVP or RTP/SAVP, based on whether audio to the destination of the message is to be encrypted or not. This applies to basically any message with "application/sdp" content, i.e. both the INVITE *and* the 183 or 200 reply.
Thus if you relay from encrypted to plaintext, the INVITE's handler needs to call rtpengine_manage("… RTP/AVP") and the response handler needs to call rtpengine_manage("… RTP/SAVP").
In my code I discover these settings (for both call source and destination) during the INVITE, then I save them in a couple of XAVU variables. All the other handlers just select source / destination based on whether the message's source IP address is the same as the INVITE's.
IMHO it's way easier to program the whole thing in Python instead of Kamailio's language. This in turn would be much simpler if Kamailio used threads instead of separate processes and shared memory, but apparently you can't have everything. :-P
Hey Matthias,
Thanks for the reply, and the pointers!
I guess the thing that’s confusing me most is that in my existing config, the 183 reply from Asterisk comes in as RTP/AVP and then Kamailio *does* change it to RTP/SAVP in the 183 forwarded to teams *and* the same thing happens for the subsequent 200 OK. So to me that indicates that rtpengine_manage is already re-writing the SDP offers between RTP and SRTP to some level? But for some reason the crypto attribute is still missing in this one case.
If I remove my attempts to re-write to/from RTP/SAVP then it’s RTP/AVP all the way through (as that’s what Asterisk sends to Kamailio) and it gets rejected because SRTP is required, whereas right now it fails because SRTP fails to negotiate – so it’s not the same error.
Regardless, I am still working on a solution based on what you’ve said where I more explicitly call rtpengine_manage and pass in RTP/AVP or SAVP in MANAGE_BRANCH and MANAGE_REPLY. But no luck yet! Still missing the crypto attribute in the same spot unfortunately.
Thanks.
Rhys Hanrahan | Chief Information Officer e: rhys@nexusone.com.aumailto:rhys@nexusone.com.au
[www.nexusone.com.au]http://www.nexusone.com.au/ [signature_21907561] 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.auhttp://www.nexusone.com.au/ | www.fusiontech.com.auhttp://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.
From: sr-users sr-users-bounces@lists.kamailio.org on behalf of Matthias Urlichs matthias@urlichs.de Reply to: "Kamailio (SER) - Users Mailing List" sr-users@lists.kamailio.org Date: Thursday, 3 March 2022 at 11:06 pm To: "sr-users@lists.kamailio.org" sr-users@lists.kamailio.org Subject: Re: [SR-Users] rtpengine - SRTP <> RTP missing a=crypto
On 03.03.22 12:07, Rhys Hanrahan wrote: Any advice appreciated, as this is my first time dealing with SRTP (and rtpengine). Feeling very stuck. Thanks!
Yeah, me too. ;-)
Basically you need to call "rtpengine_manage" with the correct parameter, i.e. either RTP/AVP or RTP/SAVP, based on whether audio to the destination of the message is to be encrypted or not. This applies to basically any message with "application/sdp" content, i.e. both the INVITE *and* the 183 or 200 reply.
Thus if you relay from encrypted to plaintext, the INVITE's handler needs to call rtpengine_manage("… RTP/AVP") and the response handler needs to call rtpengine_manage("… RTP/SAVP").
In my code I discover these settings (for both call source and destination) during the INVITE, then I save them in a couple of XAVU variables. All the other handlers just select source / destination based on whether the message's source IP address is the same as the INVITE's.
IMHO it's way easier to program the whole thing in Python instead of Kamailio's language. This in turn would be much simpler if Kamailio used threads instead of separate processes and shared memory, but apparently you can't have everything. :-P
--
-- Matthias Urlichs
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... 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@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@nexusone.com.au mailto:rhys@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@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
Hi Richard,
Yes, from what I’ve seen in the logs there are multiple branches happening. One between Teams and Kamailio and one between Kamailio and Asterisk.
In terms of the rtpengine processing, I’ve tried lots of different variations, but right now I’ve got:
* Rtpengine_manage() by itself for new branches and replies (MANAGE_BRANCH, MANAGE_REPLY) * Rtpengine_manage(“RTP/AVP”) or rtpengine_manage(“RTP/SAVP”) essentially in request_route for the initial invites to/from Teams * I do also have the stock NATMANAGE using rtpengine but there’s no NAT involved here so I don’t think it applies.
So as far as I can tell, I shouldn’t be calling rtpengine_manage multiple times. Is this bad to do? I did have previous configs where I was doing this. E.g. during RELAY I would call it with general options and then just modify AVP or SAVP in another section.
Interestingly, I noticed that a new branch is created just as I answer the call, and this is when it fails, so perhaps the issue is with how I’m handling new branches then? Below is a bit of a log to try and summarise what’s happening. Unfortunately it’s not logging the MS Teams side of the call except for the initial invite.
I will work on getting you a sip dump as it’s probably the easiest way to properly see what’s going on. Thanks!
root@sbc5-syd-01:/etc/kamailio# tail -f /var/log/syslog | grep RTPEngine Mar 4 00:39:38 sbc5-syd-01 kamailio[9240]: 44(9311) ERROR: {1 1 INVITE 5b76dfb297c455358bb0ec0dac3c1af7} <script>: -- RTPEngine: Converting Teams outbound call from SRTP to RTP before relay. Mar 4 00:39:38 sbc5-syd-01 kamailio[9240]: 44(9311) ERROR: {1 1 INVITE 5b76dfb297c455358bb0ec0dac3c1af7} <script>: -- RTPEngine: New Branch to sip:+61xxx@kamailio:5060 Mar 4 00:39:38 sbc5-syd-01 kamailio[9240]: 44(9311) ERROR: {1 1 INVITE 5b76dfb297c455358bb0ec0dac3c1af7} <script>: RTPEngine: Converting to RTP Mar 4 00:39:38 sbc5-syd-01 kamailio[9240]: 11(9278) ERROR: {2 1 INVITE 5b76dfb297c455358bb0ec0dac3c1af7} <script>: -- RTPEngine: Reply 100 from kamailio:5060 to asterisk:5060 Mar 4 00:39:40 sbc5-syd-01 kamailio[9240]: 9(9276) ERROR: {2 1 INVITE 5b76dfb297c455358bb0ec0dac3c1af7} <script>: -- RTPEngine: Reply 183 from kamailio:5060 to asterisk:5060 Mar 4 00:39:40 sbc5-syd-01 kamailio[9240]: 9(9276) ERROR: {2 1 INVITE 5b76dfb297c455358bb0ec0dac3c1af7} <script>: RTPEngine: Sticking to SRTP Mar 4 00:39:40 sbc5-syd-01 kamailio[9240]: 15(9282) ERROR: {2 1 INVITE 5b76dfb297c455358bb0ec0dac3c1af7} <script>: -- RTPEngine: Reply 183 from kamailio:5060 to asterisk:5060 Mar 4 00:39:40 sbc5-syd-01 kamailio[9240]: 15(9282) ERROR: {2 1 INVITE 5b76dfb297c455358bb0ec0dac3c1af7} <script>: RTPEngine: Sticking to SRTP Mar 4 00:39:49 sbc5-syd-01 kamailio[9240]: 16(9283) ERROR: {2 1 INVITE 5b76dfb297c455358bb0ec0dac3c1af7} <script>: -- RTPEngine: Reply 200 from kamailio:5060 to asterisk:5060 Mar 4 00:39:49 sbc5-syd-01 kamailio[9240]: 16(9283) ERROR: {2 1 INVITE 5b76dfb297c455358bb0ec0dac3c1af7} <script>: RTPEngine: Sticking to SRTP Mar 4 00:39:49 sbc5-syd-01 kamailio[9240]: 46(9314) ERROR: {1 2 BYE 5b76dfb297c455358bb0ec0dac3c1af7} <script>: -- RTPEngine: New Branch to sip:asterisk:5060 *** Call fails here
Rhys Hanrahan | Chief Information Officer e: rhys@nexusone.com.aumailto:rhys@nexusone.com.au
[www.nexusone.com.au]http://www.nexusone.com.au/ [signature_769552444] 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.auhttp://www.nexusone.com.au/ | www.fusiontech.com.auhttp://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.
From: sr-users sr-users-bounces@lists.kamailio.org on behalf of Richard Fuchs rfuchs@sipwise.com Organisation: Sipwise GmbH Reply to: "Kamailio (SER) - Users Mailing List" sr-users@lists.kamailio.org Date: Friday, 4 March 2022 at 12:10 am To: "sr-users@lists.kamailio.org" sr-users@lists.kamailio.org Subject: Re: [SR-Users] rtpengine - SRTP <> RTP missing a=crypto
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...
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@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^Mmid:1%5eM 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^Mmid:1%5eM 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^Mmid:1%5eM 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@nexusone.com.aumailto:rhys@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.auhttp://www.nexusone.com.au/ | www.fusiontech.com.auhttp://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@lists.kamailio.orgmailto:sr-users@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
Hi Richard,
I’ve attached an annotated (and sanitised) sipdump log – hopefully that explains a bit better what the flow is. If this is too much info let me know and I’ll try and give you some better info (about to go to bed so might be in the morning).
Overall: INVITE from Teams > Kamailio > Asterisk > Upstream Carrier (this is not visible in the sipdump).
Thanks for your guidance!
Rhys Hanrahan | Chief Information Officer e: rhys@nexusone.com.aumailto:rhys@nexusone.com.au
[www.nexusone.com.au]http://www.nexusone.com.au/ [signature_203132158] 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.auhttp://www.nexusone.com.au/ | www.fusiontech.com.auhttp://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.
From: sr-users sr-users-bounces@lists.kamailio.org on behalf of Rhys Hanrahan rhys@nexusone.com.au Reply to: "Kamailio (SER) - Users Mailing List" sr-users@lists.kamailio.org Date: Friday, 4 March 2022 at 12:57 am To: "Kamailio (SER) - Users Mailing List" sr-users@lists.kamailio.org Subject: Re: [SR-Users] rtpengine - SRTP <> RTP missing a=crypto
Hi Richard,
Yes, from what I’ve seen in the logs there are multiple branches happening. One between Teams and Kamailio and one between Kamailio and Asterisk.
In terms of the rtpengine processing, I’ve tried lots of different variations, but right now I’ve got:
* Rtpengine_manage() by itself for new branches and replies (MANAGE_BRANCH, MANAGE_REPLY) * Rtpengine_manage(“RTP/AVP”) or rtpengine_manage(“RTP/SAVP”) essentially in request_route for the initial invites to/from Teams * I do also have the stock NATMANAGE using rtpengine but there’s no NAT involved here so I don’t think it applies.
So as far as I can tell, I shouldn’t be calling rtpengine_manage multiple times. Is this bad to do? I did have previous configs where I was doing this. E.g. during RELAY I would call it with general options and then just modify AVP or SAVP in another section.
Interestingly, I noticed that a new branch is created just as I answer the call, and this is when it fails, so perhaps the issue is with how I’m handling new branches then? Below is a bit of a log to try and summarise what’s happening. Unfortunately it’s not logging the MS Teams side of the call except for the initial invite.
I will work on getting you a sip dump as it’s probably the easiest way to properly see what’s going on. Thanks!
root@sbc5-syd-01:/etc/kamailio# tail -f /var/log/syslog | grep RTPEngine Mar 4 00:39:38 sbc5-syd-01 kamailio[9240]: 44(9311) ERROR: {1 1 INVITE 5b76dfb297c455358bb0ec0dac3c1af7} <script>: -- RTPEngine: Converting Teams outbound call from SRTP to RTP before relay. Mar 4 00:39:38 sbc5-syd-01 kamailio[9240]: 44(9311) ERROR: {1 1 INVITE 5b76dfb297c455358bb0ec0dac3c1af7} <script>: -- RTPEngine: New Branch to sip:+61xxx@kamailio:5060 Mar 4 00:39:38 sbc5-syd-01 kamailio[9240]: 44(9311) ERROR: {1 1 INVITE 5b76dfb297c455358bb0ec0dac3c1af7} <script>: RTPEngine: Converting to RTP Mar 4 00:39:38 sbc5-syd-01 kamailio[9240]: 11(9278) ERROR: {2 1 INVITE 5b76dfb297c455358bb0ec0dac3c1af7} <script>: -- RTPEngine: Reply 100 from kamailio:5060 to asterisk:5060 Mar 4 00:39:40 sbc5-syd-01 kamailio[9240]: 9(9276) ERROR: {2 1 INVITE 5b76dfb297c455358bb0ec0dac3c1af7} <script>: -- RTPEngine: Reply 183 from kamailio:5060 to asterisk:5060 Mar 4 00:39:40 sbc5-syd-01 kamailio[9240]: 9(9276) ERROR: {2 1 INVITE 5b76dfb297c455358bb0ec0dac3c1af7} <script>: RTPEngine: Sticking to SRTP Mar 4 00:39:40 sbc5-syd-01 kamailio[9240]: 15(9282) ERROR: {2 1 INVITE 5b76dfb297c455358bb0ec0dac3c1af7} <script>: -- RTPEngine: Reply 183 from kamailio:5060 to asterisk:5060 Mar 4 00:39:40 sbc5-syd-01 kamailio[9240]: 15(9282) ERROR: {2 1 INVITE 5b76dfb297c455358bb0ec0dac3c1af7} <script>: RTPEngine: Sticking to SRTP Mar 4 00:39:49 sbc5-syd-01 kamailio[9240]: 16(9283) ERROR: {2 1 INVITE 5b76dfb297c455358bb0ec0dac3c1af7} <script>: -- RTPEngine: Reply 200 from kamailio:5060 to asterisk:5060 Mar 4 00:39:49 sbc5-syd-01 kamailio[9240]: 16(9283) ERROR: {2 1 INVITE 5b76dfb297c455358bb0ec0dac3c1af7} <script>: RTPEngine: Sticking to SRTP Mar 4 00:39:49 sbc5-syd-01 kamailio[9240]: 46(9314) ERROR: {1 2 BYE 5b76dfb297c455358bb0ec0dac3c1af7} <script>: -- RTPEngine: New Branch to sip:asterisk:5060 *** Call fails here
Rhys Hanrahan | Chief Information Officer e: rhys@nexusone.com.aumailto:rhys@nexusone.com.au
[cid:image003.png@01D82F64.15D9CCE0]http://www.nexusone.com.au/ [signature_769552444] 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.auhttp://www.nexusone.com.au/ | www.fusiontech.com.auhttp://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.
From: sr-users sr-users-bounces@lists.kamailio.org on behalf of Richard Fuchs rfuchs@sipwise.com Organisation: Sipwise GmbH Reply to: "Kamailio (SER) - Users Mailing List" sr-users@lists.kamailio.org Date: Friday, 4 March 2022 at 12:10 am To: "sr-users@lists.kamailio.org" sr-users@lists.kamailio.org Subject: Re: [SR-Users] rtpengine - SRTP <> RTP missing a=crypto
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...
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@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^Mmid:1%5eM 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^Mmid:1%5eM 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^Mmid:1%5eM 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@nexusone.com.aumailto:rhys@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.auhttp://www.nexusone.com.au/ | www.fusiontech.com.auhttp://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@lists.kamailio.orgmailto:sr-users@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
On 03/03/2022 08.47, [EXT] Rhys Hanrahan wrote:
Hi Richard,
Yes, from what I’ve seen in the logs there are multiple branches happening. One between Teams and Kamailio and one between Kamailio and Asterisk.
In terms of the rtpengine processing, I’ve tried lots of different variations, but right now I’ve got:
- Rtpengine_manage() by itself for new branches and replies (MANAGE_BRANCH, MANAGE_REPLY)
- Rtpengine_manage(“RTP/AVP”) or rtpengine_manage(“RTP/SAVP”) essentially in request_route for the initial invites to/from Teams
- I do also have the stock NATMANAGE using rtpengine but there’s no NAT involved here so I don’t think it applies.
So as far as I can tell, I shouldn’t be calling rtpengine_manage multiple times. Is this bad to do? I did have previous configs where I was doing this. E.g. during RELAY I would call it with general options and then just modify AVP or SAVP in another section.
Interestingly, I noticed that a new branch is created just as I answer the call, and this is when it fails, so perhaps the issue is with how I’m handling new branches then? Below is a bit of a log to try and summarise what’s happening. Unfortunately it’s not logging the MS Teams side of the call except for the initial invite.
What usually happens (and this is a common mistake that can be confirmed by looking at the logs produced by rtpengine) is that rtpengine is invoked multiple times for the same invite (once in each branch) with different options, but without telling rtpengine that these are branches. From rtpengine's POV these invites are all in the same branch then, and the options used in a later invocation are simply overriding the options used in previous invocations. So when the last invocation was using plain RTP and then the reply is using SRTP belonging to a different invocations, then rtpengine would not know about the SRTP attributes any more.
But without detailed logs this is just a speculation. You can see the actual signalling to rtpengine in the logs produced by rtpengine (especially with debug logging enabled). It's also possible that the signalling direction is reversed for example.
BTW we have a mailing list dedicated to rtpengine questions: https://rtpengine.com/mailing-list
Cheers
Awesome, thank you for this. I did take a look at the rtpengine logs earlier but they didn’t seem particularly useful at the time. I will have to take a look tomorrow at how to enable debug logs, and will likely post on the rtpengine list for further advice, so thanks for pointing that out.
Thanks, Rhys.
From: sr-users sr-users-bounces@lists.kamailio.org on behalf of Richard Fuchs rfuchs@sipwise.com Organisation: Sipwise GmbH Reply to: "Kamailio (SER) - Users Mailing List" sr-users@lists.kamailio.org Date: Friday, 4 March 2022 at 1:17 am To: "sr-users@lists.kamailio.org" sr-users@lists.kamailio.org Subject: Re: [SR-Users] rtpengine - SRTP <> RTP missing a=crypto
On 03/03/2022 08.47, [EXT] Rhys Hanrahan wrote: Hi Richard,
Yes, from what I’ve seen in the logs there are multiple branches happening. One between Teams and Kamailio and one between Kamailio and Asterisk.
In terms of the rtpengine processing, I’ve tried lots of different variations, but right now I’ve got:
1. Rtpengine_manage() by itself for new branches and replies (MANAGE_BRANCH, MANAGE_REPLY) 2. Rtpengine_manage(“RTP/AVP”) or rtpengine_manage(“RTP/SAVP”) essentially in request_route for the initial invites to/from Teams 3. I do also have the stock NATMANAGE using rtpengine but there’s no NAT involved here so I don’t think it applies.
So as far as I can tell, I shouldn’t be calling rtpengine_manage multiple times. Is this bad to do? I did have previous configs where I was doing this. E.g. during RELAY I would call it with general options and then just modify AVP or SAVP in another section.
Interestingly, I noticed that a new branch is created just as I answer the call, and this is when it fails, so perhaps the issue is with how I’m handling new branches then? Below is a bit of a log to try and summarise what’s happening. Unfortunately it’s not logging the MS Teams side of the call except for the initial invite.
What usually happens (and this is a common mistake that can be confirmed by looking at the logs produced by rtpengine) is that rtpengine is invoked multiple times for the same invite (once in each branch) with different options, but without telling rtpengine that these are branches. From rtpengine's POV these invites are all in the same branch then, and the options used in a later invocation are simply overriding the options used in previous invocations. So when the last invocation was using plain RTP and then the reply is using SRTP belonging to a different invocations, then rtpengine would not know about the SRTP attributes any more.
But without detailed logs this is just a speculation. You can see the actual signalling to rtpengine in the logs produced by rtpengine (especially with debug logging enabled). It's also possible that the signalling direction is reversed for example.
BTW we have a mailing list dedicated to rtpengine questions: https://rtpengine.com/mailing-list
Cheers
OK, I know this might be better served on the rtpengine list but just wanted to quickly post a debug log incase you get a chance to take a look overnight (my night hehe). https://pastebin.com/iHRQSTuD
Thanks! Rhys.
From: sr-users sr-users-bounces@lists.kamailio.org on behalf of Rhys Hanrahan rhys@nexusone.com.au Reply to: "Kamailio (SER) - Users Mailing List" sr-users@lists.kamailio.org Date: Friday, 4 March 2022 at 1:29 am To: "Kamailio (SER) - Users Mailing List" sr-users@lists.kamailio.org Subject: Re: [SR-Users] rtpengine - SRTP <> RTP missing a=crypto
Awesome, thank you for this. I did take a look at the rtpengine logs earlier but they didn’t seem particularly useful at the time. I will have to take a look tomorrow at how to enable debug logs, and will likely post on the rtpengine list for further advice, so thanks for pointing that out.
Thanks, Rhys.
From: sr-users sr-users-bounces@lists.kamailio.org on behalf of Richard Fuchs rfuchs@sipwise.com Organisation: Sipwise GmbH Reply to: "Kamailio (SER) - Users Mailing List" sr-users@lists.kamailio.org Date: Friday, 4 March 2022 at 1:17 am To: "sr-users@lists.kamailio.org" sr-users@lists.kamailio.org Subject: Re: [SR-Users] rtpengine - SRTP <> RTP missing a=crypto
On 03/03/2022 08.47, [EXT] Rhys Hanrahan wrote: Hi Richard,
Yes, from what I’ve seen in the logs there are multiple branches happening. One between Teams and Kamailio and one between Kamailio and Asterisk.
In terms of the rtpengine processing, I’ve tried lots of different variations, but right now I’ve got:
1. Rtpengine_manage() by itself for new branches and replies (MANAGE_BRANCH, MANAGE_REPLY) 2. Rtpengine_manage(“RTP/AVP”) or rtpengine_manage(“RTP/SAVP”) essentially in request_route for the initial invites to/from Teams 3. I do also have the stock NATMANAGE using rtpengine but there’s no NAT involved here so I don’t think it applies.
So as far as I can tell, I shouldn’t be calling rtpengine_manage multiple times. Is this bad to do? I did have previous configs where I was doing this. E.g. during RELAY I would call it with general options and then just modify AVP or SAVP in another section.
Interestingly, I noticed that a new branch is created just as I answer the call, and this is when it fails, so perhaps the issue is with how I’m handling new branches then? Below is a bit of a log to try and summarise what’s happening. Unfortunately it’s not logging the MS Teams side of the call except for the initial invite.
What usually happens (and this is a common mistake that can be confirmed by looking at the logs produced by rtpengine) is that rtpengine is invoked multiple times for the same invite (once in each branch) with different options, but without telling rtpengine that these are branches. From rtpengine's POV these invites are all in the same branch then, and the options used in a later invocation are simply overriding the options used in previous invocations. So when the last invocation was using plain RTP and then the reply is using SRTP belonging to a different invocations, then rtpengine would not know about the SRTP attributes any more.
But without detailed logs this is just a speculation. You can see the actual signalling to rtpengine in the logs produced by rtpengine (especially with debug logging enabled). It's also possible that the signalling direction is reversed for example.
BTW we have a mailing list dedicated to rtpengine questions: https://rtpengine.com/mailing-list
Cheers
On 03/03/2022 09.41, [EXT] Rhys Hanrahan wrote:
OK, I know this might be better served on the rtpengine list but just wanted to quickly post a debug log incase you get a chance to take a look overnight (my night hehe). https://pastebin.com/iHRQSTuD
First off, this does show the "offer" being given to rtpengine multiple times (with slightly different options) which does suggest that there are multiple branches, but this alone is not why you see what you see. The telltale log line is this:
Mar 4 01:32:39 sbc5-syd-01 rtpengine[12534]: [1646317959.098841] DEBUG: [f9d974b1ef245c3384400fa47beee1fb]: enabling passthrough mode
At this point rtpengine disables all data manipulation (including SRTP handling) and reverts to dumb UDP forwarding mode. It does this because in the last "offer" given there was no `ICE=` option given, and the incoming "offer" had ICE attributes present. I'm guessing this is a slightly older version of rtpengine (because newer versions have a saner default behaviour for this case) but in this case the combination of incoming ICE offer and lack of `ICE=` option puts rtpengine into "optional ICE relay" mode, which means it cannot be sure that media will pass through it, requiring it to fallback to passthrough mode.
Long explanation short: either upgrade, or make sure to always add an `ICE=` option to your offer flags (either ICE=remove or ICE=force).
Branch handling should also be addressed but is a separate topic. If you're doing the branching yourself, usually adding `via-branch=next` to the offer flags and `via-branch=1` to the answer flags does the trick.
Cheers
Hey Richard,
Just wanted to confirm you were 100% correct. It turned out I was indeed running an old version of RTPEngine (doh!). I had built this lab a couple of years ago but only recently started using RTPEngine properly.
Also as you suggested, for now, I’ve added ICE=remove. I had tried this before but unfortunately my log trawling led me to think that the NATMANAGE route block was not touched for a Teams call. When in reality, even though it’s not touched on the initial routing of the invite, for subsequent branches/replies it is used, and extra logging made this easy to see.
This fixed the error Reason header I got on the BYE of: SrtpNegotiationFailed, InternalErrorPhrase: Cannot negotiate SRTP encryption with remote participant
As an FYI to others, after doing this I ran into a couple of other errors:
* InternalErrorPhrase: Incorrect number of media streams in SDP answer – This *was* because I had rtpengine_manage() called twice during the initial INVITE. By simplifying my config, this error went away.
* SdpParsingErrorInternalException, InternalErrorPhrase: Exception occurred during SDP parsing (line 0): System.NullReferenceException: Object reference not set to an instance of an object.\0d\0a at Micros" – This one I am still investigating. I haven’t had time to re-work my rtp engine config to do proper RTP<>SRTP conversion this week so far, but hopefully will progress it soon and come back with a solution.
Thanks everyone for your help on this! Hopefully I finish getting it sorted out soon.
Rhys Hanrahan | Chief Information Officer e: rhys@nexusone.com.aumailto:rhys@nexusone.com.au
[www.nexusone.com.au]http://www.nexusone.com.au/ [signature_2037815728] 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.auhttp://www.nexusone.com.au/ | www.fusiontech.com.auhttp://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.
From: sr-users sr-users-bounces@lists.kamailio.org on behalf of Richard Fuchs rfuchs@sipwise.com Organisation: Sipwise GmbH Reply to: "Kamailio (SER) - Users Mailing List" sr-users@lists.kamailio.org Date: Friday, 4 March 2022 at 4:04 am To: "sr-users@lists.kamailio.org" sr-users@lists.kamailio.org Subject: Re: [SR-Users] rtpengine - SRTP <> RTP missing a=crypto
On 03/03/2022 09.41, [EXT] Rhys Hanrahan wrote: OK, I know this might be better served on the rtpengine list but just wanted to quickly post a debug log incase you get a chance to take a look overnight (my night hehe). https://pastebin.com/iHRQSTuD
First off, this does show the "offer" being given to rtpengine multiple times (with slightly different options) which does suggest that there are multiple branches, but this alone is not why you see what you see. The telltale log line is this: Mar 4 01:32:39 sbc5-syd-01 rtpengine[12534]: [1646317959.098841] DEBUG: [f9d974b1ef245c3384400fa47beee1fb]: enabling passthrough mode At this point rtpengine disables all data manipulation (including SRTP handling) and reverts to dumb UDP forwarding mode. It does this because in the last "offer" given there was no `ICE=` option given, and the incoming "offer" had ICE attributes present. I'm guessing this is a slightly older version of rtpengine (because newer versions have a saner default behaviour for this case) but in this case the combination of incoming ICE offer and lack of `ICE=` option puts rtpengine into "optional ICE relay" mode, which means it cannot be sure that media will pass through it, requiring it to fallback to passthrough mode.
Long explanation short: either upgrade, or make sure to always add an `ICE=` option to your offer flags (either ICE=remove or ICE=force).
Branch handling should also be addressed but is a separate topic. If you're doing the branching yourself, usually adding `via-branch=next` to the offer flags and `via-branch=1` to the answer flags does the trick.
Cheers
Are you sure that you have multiple branches? You mentioned that you have kamailio in between asterisk and MS. In this case, usually this is a simple call with one branch. You have multiple branches if you fork the call (parallel forking: sending to multiple destinations when the initial invite is received or serial forking: re-routing the call to a new destination when negative replies are received).
-ovidiu
On Thu, Mar 3, 2022 at 8:50 AM Rhys Hanrahan rhys@nexusone.com.au wrote:
Hi Richard,
Yes, from what I’ve seen in the logs there are multiple branches happening. One between Teams and Kamailio and one between Kamailio and Asterisk.
In terms of the rtpengine processing, I’ve tried lots of different variations, but right now I’ve got:
Rtpengine_manage() by itself for new branches and replies (MANAGE_BRANCH, MANAGE_REPLY) Rtpengine_manage(“RTP/AVP”) or rtpengine_manage(“RTP/SAVP”) essentially in request_route for the initial invites to/from Teams I do also have the stock NATMANAGE using rtpengine but there’s no NAT involved here so I don’t think it applies.
So as far as I can tell, I shouldn’t be calling rtpengine_manage multiple times. Is this bad to do? I did have previous configs where I was doing this. E.g. during RELAY I would call it with general options and then just modify AVP or SAVP in another section.
Interestingly, I noticed that a new branch is created just as I answer the call, and this is when it fails, so perhaps the issue is with how I’m handling new branches then? Below is a bit of a log to try and summarise what’s happening. Unfortunately it’s not logging the MS Teams side of the call except for the initial invite.
I will work on getting you a sip dump as it’s probably the easiest way to properly see what’s going on. Thanks!
root@sbc5-syd-01:/etc/kamailio# tail -f /var/log/syslog | grep RTPEngine
Mar 4 00:39:38 sbc5-syd-01 kamailio[9240]: 44(9311) ERROR: {1 1 INVITE 5b76dfb297c455358bb0ec0dac3c1af7} <script>: -- RTPEngine: Converting Teams outbound call from SRTP to RTP before relay.
Mar 4 00:39:38 sbc5-syd-01 kamailio[9240]: 44(9311) ERROR: {1 1 INVITE 5b76dfb297c455358bb0ec0dac3c1af7} <script>: -- RTPEngine: New Branch to sip:+61xxx@kamailio:5060
Mar 4 00:39:38 sbc5-syd-01 kamailio[9240]: 44(9311) ERROR: {1 1 INVITE 5b76dfb297c455358bb0ec0dac3c1af7} <script>: RTPEngine: Converting to RTP
Mar 4 00:39:38 sbc5-syd-01 kamailio[9240]: 11(9278) ERROR: {2 1 INVITE 5b76dfb297c455358bb0ec0dac3c1af7} <script>: -- RTPEngine: Reply 100 from kamailio:5060 to asterisk:5060
Mar 4 00:39:40 sbc5-syd-01 kamailio[9240]: 9(9276) ERROR: {2 1 INVITE 5b76dfb297c455358bb0ec0dac3c1af7} <script>: -- RTPEngine: Reply 183 from kamailio:5060 to asterisk:5060
Mar 4 00:39:40 sbc5-syd-01 kamailio[9240]: 9(9276) ERROR: {2 1 INVITE 5b76dfb297c455358bb0ec0dac3c1af7} <script>: RTPEngine: Sticking to SRTP
Mar 4 00:39:40 sbc5-syd-01 kamailio[9240]: 15(9282) ERROR: {2 1 INVITE 5b76dfb297c455358bb0ec0dac3c1af7} <script>: -- RTPEngine: Reply 183 from kamailio:5060 to asterisk:5060
Mar 4 00:39:40 sbc5-syd-01 kamailio[9240]: 15(9282) ERROR: {2 1 INVITE 5b76dfb297c455358bb0ec0dac3c1af7} <script>: RTPEngine: Sticking to SRTP
Mar 4 00:39:49 sbc5-syd-01 kamailio[9240]: 16(9283) ERROR: {2 1 INVITE 5b76dfb297c455358bb0ec0dac3c1af7} <script>: -- RTPEngine: Reply 200 from kamailio:5060 to asterisk:5060
Mar 4 00:39:49 sbc5-syd-01 kamailio[9240]: 16(9283) ERROR: {2 1 INVITE 5b76dfb297c455358bb0ec0dac3c1af7} <script>: RTPEngine: Sticking to SRTP
Mar 4 00:39:49 sbc5-syd-01 kamailio[9240]: 46(9314) ERROR: {1 2 BYE 5b76dfb297c455358bb0ec0dac3c1af7} <script>: -- RTPEngine: New Branch to sip:asterisk:5060
*** Call fails here
Rhys Hanrahan | Chief Information Officer e: rhys@nexusone.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 | 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.
From: sr-users sr-users-bounces@lists.kamailio.org on behalf of Richard Fuchs rfuchs@sipwise.com Organisation: Sipwise GmbH Reply to: "Kamailio (SER) - Users Mailing List" sr-users@lists.kamailio.org Date: Friday, 4 March 2022 at 12:10 am To: "sr-users@lists.kamailio.org" sr-users@lists.kamailio.org Subject: Re: [SR-Users] rtpengine - SRTP <> RTP missing a=crypto
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...
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@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@nexusone.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 | 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@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
On 03.03.22 14:47, Rhys Hanrahan wrote:
Yes, from what I’ve seen in the logs there are multiple branches happening. One between Teams and Kamailio and one between Kamailio and Asterisk.
That's just one branch; the incoming call doesn't count. "Real" additional branches are created by calling functions like "append_branch".
You should definitely ensure (by adding appropriate logging calls) that "rtpengine_manage" is called exactly once per outgoing application/sdp message, with all requisite arguments(*). Anything else is a recipe for confusion. In my experience that's sufficient(**) to get it all working quite nicely.
(*) "trust-address replace-origin replace-session-connection", plus either RTP/AVP or RTP/SAVP
(**) unless the opposite end is broken. Right now, for instance, talking to Zoom Europe requires a heap of "SDES-no-RANDOM_CRYPTO_ALGORITHM" arguments, for both incoming and outgoing calls. Discovering that fix was decidedly nontrivial.
Thanks guys! I was definitely just going off the default logging calls saying “new branch to xxx” in MANAGE_BRANCH. I am not intentionally creating separate branches in my config, so I guess it must be 1 branch! Good to know. Branches is another topic I still need to learn a lot more about.
Hopefully I can come up with the right config. I will keep working on it and let you know how I go.
Thanks, Rhys.
From: sr-users sr-users-bounces@lists.kamailio.org on behalf of Matthias Urlichs matthias@urlichs.de Reply to: "Kamailio (SER) - Users Mailing List" sr-users@lists.kamailio.org Date: Friday, 4 March 2022 at 2:01 am To: "sr-users@lists.kamailio.org" sr-users@lists.kamailio.org Subject: Re: [SR-Users] rtpengine - SRTP <> RTP missing a=crypto
On 03.03.22 14:47, Rhys Hanrahan wrote: Yes, from what I’ve seen in the logs there are multiple branches happening. One between Teams and Kamailio and one between Kamailio and Asterisk.
That's just one branch; the incoming call doesn't count. "Real" additional branches are created by calling functions like "append_branch".
You should definitely ensure (by adding appropriate logging calls) that "rtpengine_manage" is called exactly once per outgoing application/sdp message, with all requisite arguments(*). Anything else is a recipe for confusion. In my experience that's sufficient(**) to get it all working quite nicely.
(*) "trust-address replace-origin replace-session-connection", plus either RTP/AVP or RTP/SAVP
(**) unless the opposite end is broken. Right now, for instance, talking to Zoom Europe requires a heap of "SDES-no-RANDOM_CRYPTO_ALGORITHM" arguments, for both incoming and outgoing calls. Discovering that fix was decidedly nontrivial.
--
-- regards
--
-- Matthias Urlichs
-
Matthias Urlichs -
Ovidiu Sas -
Rhys Hanrahan -
Richard Fuchs