Offer both RTP and SRTP to remote party

[Ivan Ribakov]

I'm making outbound calls using RTP on the inner call leg (CALLER -> Kamailio/RTPEngine) and using SRTP on the public side of the call (Kamailio/RTPEngine -> CALLEE).

I have the conversion working as expected using "transport-protocol=RTP/(S)AVP" depending on the SDP direction. I'm now facing a problem that I don't always know if the CALLEE supports SRTP or not. If I convert RTP->SRTP on the outbound call, CALLEE just rejects the call with 488. However I would like to give CALLEE an option to choose between encrypted and non-encrypted media depending on it's capabilities and preferences. 

My intuitive approach was to look for the way to make RTPEngine offer 2 media types (encrypted and non-encrypted) on the public leg, but I didn't see anything of the sorts in the docs. Did I miss something? Or is this kind of problem supposed to be handled in some other way?

Thanks in advance for any tips/pointers!

[johan de clercq]

that's the old way : you give them sdp rtp/avp and rtp/savp.  The problem with that is that your SBC will send 488.

Nowadays, if rtp/savp is offered always continue like that. 

--
You received this message because you are subscribed to the Google Groups "Sipwise rtpengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtpengine+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/rtpengine/aaa8181d-f3ed-43aa-a752-66ca1554b2b4n%40googlegroups.com.

[Richard Fuchs]

On 06/03/2026 04.49, Ivan Ribakov wrote:

My intuitive approach was to look for the way to make RTPEngine offer 2 media types (encrypted and non-encrypted) on the public leg, but I didn't see anything of the sorts in the docs. Did I miss something? Or is this kind of problem supposed to be handled in some other way?

What you describe is a somewhat common but also non-standard approach to achieve what you're looking for. Whether it will work depends on the receiving UA: Some don't like being offered multiple audio streams and may still reject the call.

The standard method is described in RFC 8643. With this, the advertised transport is kept as plaintext RTP, but the attributes required for SRTP (SDES and/or DTLS) are still included. This should work against most UAs, as UAs are supposed to simply ignore attributes they don't understand. On the downside it requires explicit support to make SRTP work, and with this being a somewhat newer RFC, older UAs would likely fall back to plaintext RTP even if they otherwise would support SRTP.

Both of these are supported by rtpengine. Look for the `OSRTP=...` key passed to offer/answer flags: https://rtpengine.readthedocs.io/en/latest/ng_control_protocol.html

Which one you should choose depends on what kinds of UAs you're dealing with.

Alternatively you can handle it on the SIP layer: intercept the 488 and retry the offer.

Cheers

[Ivan Ribakov]

> Both of these are supported by rtpengine. Look for the `OSRTP=...` key passed to offer/answer flags: https://rtpengine.readthedocs.io/en/latest/ng_control_protocol.html

This is exactly what I was looking for!

> The standard method is described in RFC 8643. ... This should work against most UAs,

I found out the hard way that pjproject does not support RFC8643...

> Which one you should choose depends on what kinds of UAs you're dealing with.
> Alternatively you can handle it on the SIP layer: intercept the 488 and retry the offer.

Understood, thank you Richard for the clear breakdown and guidance!