9 Mar
2022
9 Mar
'22
7: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
