How to set transport-protocol flags for SRTP(PRIVATE) to SRTP(PUBLIC)?

[xiaofang han (hance)]

Hi everyone,

I have a question about configuring the correct offer flags in rtpengine when bridging calls between PRIVATE and PUBLIC interfaces with different transport protocols.

Here are the scenarios I am working with. In all cases, A is the caller on the PRIVATE interface, and B is the callee on the PUBLIC interface.

Case 1: SRTP to RTP
A (PRIVATE, SRTP) —> RTPEngine —> B (PUBLIC, RTP)
offer flags = ‘direction=PRIVATE direction=PUBLIC transport-protocol=RTP/AVP’

Case 2: RTP to SRTP
A (PRIVATE, RTP) —> RTPEngine —> B (PUBLIC, SRTP)
offer flags = ‘direction=PRIVATE direction=PUBLIC transport-protocol=RTP/SAVP’

Case 3: SRTP to SRTP
A (PRIVATE, SRTP) —> RTPEngine —> B (PUBLIC, SRTP)
offer flags = ‘direction=PRIVATE direction=PUBLIC ???’

My question is regarding Case 3:
If the incoming offer from A is already SRTP, and I want RTPEngine to also offer SRTP to B on the public interface, what should the correct transport-protocol (and any other necessary crypto flags like SDES-off/SDES-only) be in the offer string?

Any advice or examples would be greatly appreciated!

Thanks in advance,

Han

[Richard Fuchs]

On 20/08/2026 03.24, xiaofang han (hance) wrote:
> Case 3: SRTP to SRTP
> A (PRIVATE, SRTP) —> RTPEngine —> B (PUBLIC, SRTP)
> offer flags = ‘direction=PRIVATE direction=PUBLIC ???’
>
> My question is regarding Case 3:
> If the incoming offer from A is already SRTP, and I want RTPEngine to
> also offer SRTP to B on the public interface, what should the correct
> transport-protocol (and any other necessary crypto flags like
> SDES-off/SDES-only) be in the offer string?

Transport protocols and interface selection are completely independent
from each other. So you can ignore the interface aspect of this.

The transport protocol you tell rtpengine should match what you know
about your B-party, as it acts as an override to what was received from A.

If you know that B supports SRTP, you would tell rtpengine to use
RTP/SAVP. If you know that B only supports plaintext RTP, you would tell
it to use RTP/AVP.

If you don't know what B may or may not support, you can omit the
transport protocol. In that case A and B would negotiate between each
other (sometimes unsuccessfully). There is also an option for OSRTP,
which would theoretically allow either SRTP or RTP with a single offer,
but that is also depending on what B supports.

In case the offer to B ends up being SRTP, by default all SRTP options
are offered (SDES with all crypto suites, plus DTLS). A well behaved
client would choose the SRTP method it supports and/or prefers, and
ignore the others, and the call would work. In other cases, when you
know that B has a problem with one of these options, you can tell
rtpengine to disable them (e.g. a call to WebRTC, which disallows SDES
and may reject an offer with SDES options).

IOW, TLDR, generally you shouldn't worry about what was received from A
and only give whatever flags are needed/appropriate for B.

Cheers