[SR-Users] Manage multiple RTP streams with different TO-tags (forking)

[Julien Klingenmeyer]

Hi,

I faced a quite same situation recently and I have asked on RTPEngine Github: https://github.com/sipwise/rtpengine/issues/1330
Your scenario is a bit different but with the workaround described in the issue (overriding to-tag flag in rtpengine request), maybe you can fix your issue.

Just also be careful when either Alice or Bob sends ReInvites within the call, to-tag (or from-tag depending on who sent the request) will need to be overridden too.

Julien

De : sr-users <sr-users-bounces at lists.kamailio.org> au nom de Arsen Semenov <arsperger at gmail.com>
Répondre à : "Kamailio (SER) - Users Mailing List" <sr-users at lists.kamailio.org>
Date : vendredi 27 août 2021 à 07:28
À : "Kamailio (SER) - Users Mailing List" <sr-users at lists.kamailio.org>
Objet : Re: [SR-Users] Manage multiple RTP streams with different TO-tags (forking)

it's legal to get responses with different to-tags, since the request is forked. this is what's happening in this scenario.
I think this is an issue of UAC/rtpengin how it is reacting to the second SDP in 183

are the SDPs in 183 responses carried reliably?

On Fri, Aug 27, 2021 at 2:51 PM Yuriy Gorlichenko <ovoshlook at gmail.com<mailto:ovoshlook at gmail.com>> wrote:
Hello.
The first thing: to tag can't be changed due session once it passed.

If provider uses forking mechanism the it has to be hidden from your system.

Regarding SDP according
https://datatracker.ietf.org/doc/html/rfc3261#section-13.2.1
They can't change SDP answer description on the fly. Only first SDP answer used as proper, all othe answers will be ignored.

On Fri, 27 Aug 2021, 11:27 B. Tietz, <benjamin.tietz at berlin.de<mailto:benjamin.tietz at berlin.de>> wrote:
Hello,

following situation.
I have a Kamailio (5.4) using rtpengine to loadbalance calls.

If a call from Alice comes in, Kamailio decides to send the call to Carrier B from Bob.
Bobs Phone is ringing and the carrier B send a 183 Session Progress with SDP and To-tag=abcd. The SDP has G722 as codec and port 1234.
A few moments later carrier B send a second 183 Session Progress with SDP and TO-tag=fghi. The SDP has G711 as codec and port 5678. This is done, to play some funky music as ringtone -.-
If Bob answers the call, carrier B sends a 200 OK WITHOUT SDP and TO-tag=abcd. So this should instruct our Kamailio to switch to the first G722 and port 1234.

But sadly, this is just not working as expected.

We tried to set the flags media-handover and port-latching for the rtpengine options and additionally set a to-tag when using rtpenging_manage.
But this doesn't solve the codec change, so we have only audio when Bob answers the call, but no ringtone-music. If we allow G711 only in the outgoing INVITE to Bob, we have also tha ringtone-muisic, because there is no codec-change.

Carrier B tells us, they are using a fork-mechanism.

Is there something we can do, to support the codec change in 183? Or enforce carrier B to send SDP in 200 OK? Or anything else?

Carrier B can not change anything in the ringtone-music-backend. They are stuck on G711.

Thanks!
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users at lists.kamailio.org<mailto:sr-users at lists.kamailio.org>
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users at lists.kamailio.org<mailto:sr-users at lists.kamailio.org>
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users


--
Arsen Semenov

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20210827/5013fa31/attachment.htm>