Bridging and splitting media

[Ivan Ribakov]

I'm evaluating usage of RTPEngine for media anchoring in a B2BUA. I did a simple PoC and was able to anchor media for a basic one-to-one call by using the call-id of just one side of the call. I'm now trying to understand whether RTPEngine will support a couple of more advanced scenarios:

1. Bridging media legs from 2 calls where the second call is the result of an INVITE + Replaces header. The requirement is to handle Replaces header on the B2BUA without forwarding the INVITE to the end UA. So from media perspective it would look something like this:

    - Alice <--- Media Leg 1 ---> RTPEngine (Call 1)

    - Bob   <--- Media Leg 2 ---> RTPEngine (Call 1)

    - Bob   <--- Media Leg 3 ---> RTPEngine (Call 2 + Replaces)

Can RTPEngine proxy media from leg 1 to leg 3 and backwards instead of leg 2?

2. Splitting 2 media legs to inject Media Mixer in between. From media perspective it would mean transitioning from 2 media legs:

    - Alice <--- Media Leg 1 ---> RTPEngine

    - Bob   <--- Media Leg 2 ---> RTPEngine

to 4 media legs: 

    - Alice  <--- Media Leg 1 ---> RTPEngine

    - Bob    <--- Media Leg 2 ---> RTPEngine

    - Mixer <--- Media Leg 3 ---> RTPEngine (to/from Alice on leg 1)

    - Mixer <--- Media Leg 4 ---> RTPEngine (to/from Bob on leg 2)

The reason behind this sub-optimal approach is to avoid reINVITEs as some UAs don't handle them properly.

Thanks in advance!

[Richard Fuchs]

On 30/07/2024 17.59, Ivan Ribakov wrote:

I'm evaluating usage of RTPEngine for media anchoring in a B2BUA. I did a simple PoC and was able to anchor media for a basic one-to-one call by using the call-id of just one side of the call. I'm now trying to understand whether RTPEngine will support a couple of more advanced scenarios:

1. Bridging media legs from 2 calls where the second call is the result of an INVITE + Replaces header. The requirement is to handle Replaces header on the B2BUA without forwarding the INVITE to the end UA. So from media perspective it would look something like this:

    - Alice <--- Media Leg 1 ---> RTPEngine (Call 1)

    - Bob   <--- Media Leg 2 ---> RTPEngine (Call 1)

    - Bob   <--- Media Leg 3 ---> RTPEngine (Call 2 + Replaces)

Can RTPEngine proxy media from leg 1 to leg 3 and backwards instead of leg 2?

Assuming these are established using different call IDs, currently the answer is no. You can do this between multiple different parties to a single call (same call ID), but currently we can't cross-connect between different calls (call IDs). There's a long-standing TODO to make this possible, but it has been on the back burner.

A common workaround is to have rtpengine proxy media to itself for every call using a hidden internal call leg

2. Splitting 2 media legs to inject Media Mixer in between. From media perspective it would mean transitioning from 2 media legs:

    - Alice <--- Media Leg 1 ---> RTPEngine

    - Bob   <--- Media Leg 2 ---> RTPEngine

to 4 media legs: 

    - Alice  <--- Media Leg 1 ---> RTPEngine

    - Bob    <--- Media Leg 2 ---> RTPEngine

    - Mixer <--- Media Leg 3 ---> RTPEngine (to/from Alice on leg 1)

    - Mixer <--- Media Leg 4 ---> RTPEngine (to/from Bob on leg 2)

The reason behind this sub-optimal approach is to avoid reINVITEs as some UAs don't handle them properly.

This is certainly possible using the right signalling to rtpengine, and is a bit like the hidden internal call leg I just mentioned. The mixer would have to act as a sort of B2BUA (it doesn't have to be SIP, but it needs to talk to rtpengine with SDPs). It would need either different call IDs for the two call legs, or different from/to-tags within the same call ID.

Cheers

[Ivan Ribakov]

> Assuming these are established using different call IDs, currently the answer is no.

Ok, that was least of my concerns. B2BUA should be able to maintain a "meta-call-id" to group multiple leg SIP Call-IDs under one logical call identifier.

> You can do this between multiple different parties to a single call (same call ID)

Could you please elaborate on this a little bit more? My understanding is that each call in RTPEngine can only have 2 parties identified by the from and to tags respectively. How would one go about dealing with more than 2 parties?

> A common workaround is to have rtpengine proxy media to itself for every call using a hidden internal call leg

Is there any documentation that covers this scenario? I think I understand what is expected to happen form the SDP offer/answer exchange perspective but I'm not sure which RTPEngine commands are needed to trigger that behaviour.

[Richard Fuchs]

On 31/07/2024 10.49, Ivan Ribakov wrote:
> > Assuming these are established using different call IDs, currently
> the answer is no.
>
> Ok, that was least of my concerns. B2BUA should be able to maintain a
> "meta-call-id" to group multiple leg SIP Call-IDs under one logical
> call identifier.
>
> > You can do this between multiple different parties to a single call
> (same call ID)
>
> Could you please elaborate on this a little bit more? My understanding
> is that each call in RTPEngine can only have 2 parties identified by
> the from and to tags respectively. How would one go about dealing with
> more than 2 parties?

Not at all, you can have any number of media flows or call legs within
the same call ID, as long as they have unique from/to-tags. So for
example you can have one call leg or media flow established with a SIP
invite with from-tag A and a corresponding answer from to-tag B, and
then have a completely separate media flow between from-tag C and to-tag
D. And then with appropriate signalling (basically pretending to do a
re-invite) you could connect from-tag A to to-tag C, or any other way.

> > A common workaround is to have rtpengine proxy media to itself for
> every call using a hidden internal call leg
>
> Is there any documentation that covers this scenario? I think I
> understand what is expected to happen form the SDP offer/answer
> exchange perspective but I'm not sure which RTPEngine commands are
> needed to trigger that behaviour.

This isn't really a separate feature as such, but rather a specific
(ab)use of the normal offer/answer signalling. Instead of taking the
offer SDP from Alice, feeding it to rtpengine as "offer", then taking
the output SDP and sending it to Bob, you would rather take the offer
SDP from Alice, feed it to rtpengine as "offer", take the output SDP,
feed it back into rtpengine as another input SDP to another "offer", but
with a different call ID or different from-tag, and finally take the
output SDP from that second offer and send it to Bob. Then for the
answer you repeat this procedure but in reverse (second call leg first,
first call leg second). Using this approach, you can take the
intermediate SDPs and feed them into rtpengine on different call legs to
connect various parties.

All this can be very error prone though, and it can be tricky to get it
to work right, especially when you use rtpengine to bridge between
different feature sets used by different call parties (i.e. RTP/SRTP,
transcoding, IPv4/6, etc), so I wouldn't recommend it, although I know
this is somewhat commonly done.

Cheers