Is it possible to set a conference call with rtpengine?

[Tiago Mendes]

I am working on a project for the bachelors final project and am trying to achieve a Push-to-Talk flow with RTP Engine.

Is it possible to use it to create a conference call? If so, how do I need to create offer and answer commands? I expect the flow as below

[Richard Fuchs]

On 19/03/2026 06.09, Tiago Mendes wrote:
> I am working on a project for the bachelors final project and am
> trying to achieve a Push-to-Talk flow with RTP Engine.
>
> Is it possible to use it to create a conference call? If so, how do I
> need to create offer and answer commands?

It certainly isn't possible with offer/answer as it would go against its
design principle (offer/answer between A and B).

You could do this using the publish/subscribe mechanism, but at the
moment rtpengine only supports one-way media for these (i.e. as a simple
SFU), so each call participant would end up with multiple separate audio
streams, which typically isn't how an audio conference call is supposed
to work.

We do have support for mixing multiple audio streams into one in
rtpengine, but at the moment this is only used in cases where multiple
RTP streams are received from one call party.

There is ongoing work to extend the publish/subscribe mechanism to
support a full offer/answer exchange not between A and B, but rather
between X and rtpengine directly, and in the (near?) future this should
make it possible to establish arbitrary media flows between arbitrary
parties to a call, which basically would be a conference call. You would
still need support from some SIP UA though, either to act as the peer
endpoint to each A/B call, or as something like a B2B UA to facilitate
the necessary signalling to move call parties from an A/B call into a
conference.

Cheers

[Tiago Mendes]

Hi,

Thanks for the reply. After reading it I think publish/subscribe might actually fit our use case, since we're more of a Push-to-Talk (just like a Walkie-Talkie) and not a conference call.

We have a custom B2BUA between Kamailio and the clients. Each client affiliates to a group channel by sending an INVITE to a group URI, and the B2BUA controls rtpengine via the ng protocol. The idea is: 

1. Each client M affiliates via INVITE. The SIP AS sends ng offer(call_id=M, from_tag=M, sdp=SDP_M) and gets back a relay_SDP_M, which is returned to M in the 200 OK
2. The first member to affiliate becomes the talker. All subsequent members become listeners. For each listener L, the SIP AS sends subscribe_request pointing to the talker's session, with SDP_L as the subscriber SDP so rtpengine knows where to forward the talker's RTP
3. When the floor changes from a talker T to a member B, the SIP AS sends unsubscribe for all active subscriptions, then subscribe_request for each remaining member pointing to B's session

For floor requests we were thinking of having the listener send a re-INVITE of sorts (perhaps a SIP INFO?) with a custom header as a lightweight signal to the B2BUA, though we're not sure if that's the right place to hook into this or if there's a more natural way

Since only one person sends RTP at a time, the one-way limitation shouldn't matter. Before we go further though, a few things we're unsure about:

• Is ng offer without ng answer a stable session state, or does rtpengine expect an answer before it considers the session usable?
• In subscribe_request, should sdp be the client's original SDP or the relay_SDP returned by the offer?
• Any known issues with N active subscriptions pointing at the same source session?

Expected flow: https://snipboard.io/3qrno8.jpg

Thanks!

[Richard Fuchs]

On 19/03/2026 09.11, Tiago Mendes wrote:

Since only one person sends RTP at a time, the one-way limitation shouldn't matter. Before we go further though, a few things we're unsure about:

• Is ng offer without ng answer a stable session state, or does rtpengine expect an answer before it considers the session usable?

It is not. Every offer needs an answer. In fact this:

• Each client M affiliates via INVITE. The SIP AS sends ng offer(call_id=M, from_tag=M, sdp=SDP_M) and gets back a relay_SDP_M, which is returned to M in the 200 OK

is not a valid use of "offer." The SDP that is returned from an "offer" is not an answer SDP that can be sent back to the offerer as a reply. The returned SDP is still an offer SDP, that is supposed to be sent to a B party which then produces the answer.

You probably want to use "publish" for this, which does return an answer SDP. (There's a patch to support bidirectional/sendrecv "publish" pending to be submitted to git, if that's needed.)

• In subscribe_request, should sdp be the client's original SDP or the relay_SDP returned by the offer?

There's no input SDP to a subscribe request, and the output SDP that is returned is an offer SDP that can be given to a listener. It's a reflection of what is being subscribed to, and generally corresponds to the receive direction (i.e. the received offer SDP from an offer or a publish).

The answer SDP returned by the listener is then used as input to the subscribe answer.

• Any known issues with N active subscriptions pointing at the same source session?

No, in fact that is explicitly what it was designed to do.

Cheers