[SR-Users] rtpengine - SRTP <> RTP missing a=crypto

[Richard Fuchs]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20220303/61af5cf6/attachment.htm>