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:

 

 

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  

www.nexusone.com.au   signature_2037815728

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 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