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: r...@nexusone.com.au<mailto:r...@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.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.
From: sr-users <sr-users-boun...@lists.kamailio.org> on behalf of Richard Fuchs
<rfu...@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&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:+614x...@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<mid: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^M<mid: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^M<mid: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: r...@nexusone.com.au<mailto:r...@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<mailto: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
__________________________________________________________
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
