Three way calling

[Razvan Crainea]

Hello!

I am looking for a solution to implement 3-way calling, and I need some help from rtpengine.

My scenario starts with a classic rtpengine session between A and B.

A   <-------- rtpengine -------> B

Then, at a certain point, I would like to introduce a new participant (let's call him C) in this call - to do so, I create a call between C and a media server (let's call it MC). The media server essentially sends two new SDPs, MA and MB, to "grab" the media sessions of A and B. So at the end of the scenario, I end up with 4 rtpengine sessiosn:

A -> B

A -> MA

B -> MB

C -> MC

I was wondering if there is any mechanism in rtpengine that would allow the initial A -> B rtpengine session to be modified such that instead of A talk to B, to have two sessions, A talk to MA and B talk to MB, so essentially just updating the endpoints of the two initial participants.

What I've tried so far was to offer/answer the initial session with different from/to tags, but that doesn't seem to fully work. Do you have any other ideas on how to implement this?

Otherwise, if this can't be achieve, I have a "limitation" with this approach - when A -> MA and B -> MB are created, the A -> B session remains dangling - is there any command I can use to make sure it does not dissapear / get timed out by rtpengine?

Looking forward for your thoughts.

Many thanks,
Răzvan

[Richard Fuchs]

On 13/08/2025 10.05, Razvan Crainea wrote:

I am looking for a solution to implement 3-way calling, and I need some help from rtpengine.

My scenario starts with a classic rtpengine session between A and B.

A   <-------- rtpengine -------> B

To start explaining, I need to point out that rtpengine doesn't really have an internal concept of "sessions" like this. There are "calls" (identified by unique call IDs), but calls can have any number of participants. Each participant is identified by a unique "tag," generally the from-tag and to-tag from SIP.

Your basic example would be one call with two participants, A and B, and these two would be associated with each other so that media is flowing between them.

Then, at a certain point, I would like to introduce a new participant (let's call him C) in this call - to do so, I create a call between C and a media server (let's call it MC). The media server essentially sends two new SDPs, MA and MB, to "grab" the media sessions of A and B. So at the end of the scenario, I end up with 4 rtpengine sessiosn:

A -> B

A -> MA

B -> MB

C -> MC

Instead of thinking of it as "four sessions," think of it as six participants to a call: A, B, C, MA, MB, MC.

There are ways that one participant to a call can be associated with multiple other ones (to facilitate media forking for example), but in normal call scenarios that are established through offer/answer, each participant normally is associated with just one other one. So in your example, you want associations like this:

A <> MA
B <> MB
C <> MC

All of this is assuming that this all happens within a single "call," i.e. all using the same unique call ID. If different call IDs are involved then it gets a bit trickier. (This is call IDs from rtpengine's POV - they don't necessarily have to match the SIP call IDs, assuming this is based on SIP.)

I was wondering if there is any mechanism in rtpengine that would allow the initial A -> B rtpengine session to be modified such that instead of A talk to B, to have two sessions, A talk to MA and B talk to MB, so essentially just updating the endpoints of the two initial participants.

There are a few different ways, and not all may work in all circumstances. It sounds like you've already had the right idea:

What I've tried so far was to offer/answer the initial session with different from/to tags, but that doesn't seem to fully work. Do you have any other ideas on how to implement this?

This does work and requires a fresh offer/answer exchange between all call parties, but the tags must be considered carefully. The from-tag and to-tag in each offer/answer message is used to set up media associations between call parties, and at the same time breaks up previously existing associations.

For example, with the association A <> B already established, for MA to "grab" the association to A, MA could send an offer SDP (from-tag: MA) and indicate that it's going to A (to-tag: A). When A then answers with the same from/to-tags used in the answer, this then associates A with MA and vice versa, and disassociates A from B. So now you have A <> MA, and B is left dangling.

Now MB can repeat this towards B, and this sets up B <> MB.

Setting up C <> MC is then trivial.

Again these tags are all from rtpengine's POV and don't necessarily have to match the tags in the SIP headers.

The important part is that an offer SDP coming from any particular call party is always signalled using the same from-tag, and an offer SDP going to any particular call party is always signalled using the same to-tag. Same goes for answers.

Another way to try to achieve this involves swapping out SDPs between call parties (e.g. pretending that some call party's media endpoint is somewhere else), but that's not recommended as things would start breaking if more advanced SDP options are involved (ICE, SRTP, DTLS...)

The new "connect" method could also be used to change media associations between call parties, without requiring a fresh offer/answer exchange, but might need an initial dummy peer/UA for the MA/MB call participants, before their media can be redirected to A/B.

HTH

Cheers

[Razvan Crainea]

On Wed, Aug 13, 2025 at 6:57 PM 'Richard Fuchs' via Sipwise rtpengine
<rtpe...@googlegroups.com> wrote:
>
> On 13/08/2025 10.05, Razvan Crainea wrote:
>
> I am looking for a solution to implement 3-way calling, and I need some help from rtpengine.
> My scenario starts with a classic rtpengine session between A and B.
> A <-------- rtpengine -------> B
>
> To start explaining, I need to point out that rtpengine doesn't really have an internal concept of "sessions" like this. There are "calls" (identified by unique call IDs), but calls can have any number of participants. Each participant is identified by a unique "tag," generally the from-tag and to-tag from SIP.

This is actually good news, as session would have been a limitation.
And somehow what I was presuming, but I don't claim I fully understand
the internals. Hence the mail itself :).

>
> Your basic example would be one call with two participants, A and B, and these two would be associated with each other so that media is flowing between them.
>
> Then, at a certain point, I would like to introduce a new participant (let's call him C) in this call - to do so, I create a call between C and a media server (let's call it MC). The media server essentially sends two new SDPs, MA and MB, to "grab" the media sessions of A and B. So at the end of the scenario, I end up with 4 rtpengine sessiosn:
>
> A -> B
> A -> MA
> B -> MB
> C -> MC
>
> Instead of thinking of it as "four sessions," think of it as six participants to a call: A, B, C, MA, MB, MC.
>
> There are ways that one participant to a call can be associated with multiple other ones (to facilitate media forking for example), but in normal call scenarios that are established through offer/answer, each participant normally is associated with just one other one. So in your example, you want associations like this:
>
> A <> MA
> B <> MB
> C <> MC
>
> All of this is assuming that this all happens within a single "call," i.e. all using the same unique call ID. If different call IDs are involved then it gets a bit trickier. (This is call IDs from rtpengine's POV - they don't necessarily have to match the SIP call IDs, assuming this is based on SIP.)
>
> I was wondering if there is any mechanism in rtpengine that would allow the initial A -> B rtpengine session to be modified such that instead of A talk to B, to have two sessions, A talk to MA and B talk to MB, so essentially just updating the endpoints of the two initial participants.
>
> There are a few different ways, and not all may work in all circumstances. It sounds like you've already had the right idea:
>
> What I've tried so far was to offer/answer the initial session with different from/to tags, but that doesn't seem to fully work. Do you have any other ideas on how to implement this?
>
> This does work and requires a fresh offer/answer exchange between all call parties, but the tags must be considered carefully. The from-tag and to-tag in each offer/answer message is used to set up media associations between call parties, and at the same time breaks up previously existing associations.
>
> For example, with the association A <> B already established, for MA to "grab" the association to A, MA could send an offer SDP (from-tag: MA) and indicate that it's going to A (to-tag: A). When A then answers with the same from/to-tags used in the answer, this then associates A with MA and vice versa, and disassociates A from B. So now you have A <> MA, and B is left dangling.
>
> Now MB can repeat this towards B, and this sets up B <> MB.

This is precisely what my idea was - but perhaps I missed a
combination. I will double check to see if I've done something wrong -
but it's good to know that I was on the right path.

>
> Setting up C <> MC is then trivial.

Yes, this is actually a different call by itself.

>
> Again these tags are all from rtpengine's POV and don't necessarily have to match the tags in the SIP headers.

Yeah, that's what I though so, my initial test was actually using
"caller"/"callee" tags.

>
> The important part is that an offer SDP coming from any particular call party is always signalled using the same from-tag, and an offer SDP going to any particular call party is always signalled using the same to-tag. Same goes for answers.

That's something I rely on, because at some point I'd like to revert
the setup to a 2-way call - at that points my tags need to be
offered/answered in the same way as a regular call.

>
> Another way to try to achieve this involves swapping out SDPs between call parties (e.g. pretending that some call party's media endpoint is somewhere else), but that's not recommended as things would start breaking if more advanced SDP options are involved (ICE, SRTP, DTLS...)

That's actually what I was initially doing but not using rtpengine,
and it was working fine. But indeed, I didn't get to put this in
production to identify these corner cases.

>
> The new "connect" method could also be used to change media associations between call parties, without requiring a fresh offer/answer exchange, but might need an initial dummy peer/UA for the MA/MB call participants, before their media can be redirected to A/B.

This is actually interesting - your idea would be to create a new
UA/session between MA and MB, then connect the A to MA and B to MB.
This might work, but I believe is a bit more complicated. But will
keep the new method in mind.

Thank you so much for the detailed explanation, it was really helpful!
I will revise everything tomorrow and let you know how it goes.

>
> HTH
>
> Cheers
>
> --
> You received this message because you are subscribed to a topic in the Google Groups "Sipwise rtpengine" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/rtpengine/UUMsn5RWWaY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to rtpengine+...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/rtpengine/3c13ee04-74f1-4be4-9eb0-7b06fc50c939%40sipwise.com.



--
Răzvan Crainea