3 Mar
2022
3 Mar
'22
12:07 p.m.
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=40…
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.
3 Mar
3 Mar
1:02 p.m.
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
2:13 p.m.
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.au<mailto: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.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-bounces(a)lists.kamailio.org> on behalf of Matthias Urlichs
<matthias(a)urlichs.de>
Reply to: "Kamailio (SER) - Users Mailing List"
<sr-users(a)lists.kamailio.org>
Date: Thursday, 3 March 2022 at 11:06 pm
To: "sr-users(a)lists.kamailio.org" <sr-users(a)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
2:05 p.m.
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=40…
<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(a)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(a)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
2:47 p.m.
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<mailto: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.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-bounces(a)lists.kamailio.org> on behalf of Richard Fuchs
<rfuchs(a)sipwise.com>
Organisation: Sipwise GmbH
Reply to: "Kamailio (SER) - Users Mailing List"
<sr-users(a)lists.kamailio.org>
Date: Friday, 4 March 2022 at 12:10 am
To: "sr-users(a)lists.kamailio.org" <sr-users(a)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=40…
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<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: 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<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
3:06 p.m.
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.au<mailto: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.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-bounces(a)lists.kamailio.org> on behalf of Rhys Hanrahan
<rhys(a)nexusone.com.au>
Reply to: "Kamailio (SER) - Users Mailing List"
<sr-users(a)lists.kamailio.org>
Date: Friday, 4 March 2022 at 12:57 am
To: "Kamailio (SER) - Users Mailing List" <sr-users(a)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.au<mailto: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.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-bounces(a)lists.kamailio.org> on behalf of Richard Fuchs
<rfuchs(a)sipwise.com>
Organisation: Sipwise GmbH
Reply to: "Kamailio (SER) - Users Mailing List"
<sr-users(a)lists.kamailio.org>
Date: Friday, 4 March 2022 at 12:10 am
To: "sr-users(a)lists.kamailio.org" <sr-users(a)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=40…
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<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: 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<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
3:11 p.m.
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
3:22 p.m.
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(a)lists.kamailio.org> on behalf of Richard Fuchs
<rfuchs(a)sipwise.com>
Organisation: Sipwise GmbH
Reply to: "Kamailio (SER) - Users Mailing List"
<sr-users(a)lists.kamailio.org>
Date: Friday, 4 March 2022 at 1:17 am
To: "sr-users(a)lists.kamailio.org" <sr-users(a)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
3:41 p.m.
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(a)lists.kamailio.org> on behalf of Rhys Hanrahan
<rhys(a)nexusone.com.au>
Reply to: "Kamailio (SER) - Users Mailing List"
<sr-users(a)lists.kamailio.org>
Date: Friday, 4 March 2022 at 1:29 am
To: "Kamailio (SER) - Users Mailing List" <sr-users(a)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(a)lists.kamailio.org> on behalf of Richard Fuchs
<rfuchs(a)sipwise.com>
Organisation: Sipwise GmbH
Reply to: "Kamailio (SER) - Users Mailing List"
<sr-users(a)lists.kamailio.org>
Date: Friday, 4 March 2022 at 1:17 am
To: "sr-users(a)lists.kamailio.org" <sr-users(a)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
6:01 p.m.
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
9 Mar
9 Mar
5:37 a.m.
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.au<mailto: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.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-bounces(a)lists.kamailio.org> on behalf of Richard Fuchs
<rfuchs(a)sipwise.com>
Organisation: Sipwise GmbH
Reply to: "Kamailio (SER) - Users Mailing List"
<sr-users(a)lists.kamailio.org>
Date: Friday, 4 March 2022 at 4:04 am
To: "sr-users(a)lists.kamailio.org" <sr-users(a)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
3 Mar
3 Mar
3:43 p.m.
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(a)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(a)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(a)lists.kamailio.org> on behalf of Richard Fuchs
<rfuchs(a)sipwise.com>
Organisation: Sipwise GmbH
Reply to: "Kamailio (SER) - Users Mailing List"
<sr-users(a)lists.kamailio.org>
Date: Friday, 4 March 2022 at 12:10 am
To: "sr-users(a)lists.kamailio.org" <sr-users(a)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=40…
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(a)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(a)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(a)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
--
VoIP Embedded, Inc.
http://www.voipembedded.com
3:45 p.m.
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
4:20 p.m.
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(a)lists.kamailio.org> on behalf of Matthias Urlichs
<matthias(a)urlichs.de>
Reply to: "Kamailio (SER) - Users Mailing List"
<sr-users(a)lists.kamailio.org>
Date: Friday, 4 March 2022 at 2:01 am
To: "sr-users(a)lists.kamailio.org" <sr-users(a)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
790
days inactive
796
days old
13 comments
4 participants
participants (4)
-
Matthias Urlichs -
Ovidiu Sas -
Rhys Hanrahan -
Richard Fuchs