Hi Gang
Parallel forking situation.
A => B A => C
A invites with g711,g722 which is forked to B and C B reports ringing by sending 183 + SDP g711 C report 180 ringing. C establishes connection 200 OK + SDP g722
https://www.rfc-editor.org/rfc/rfc3261.html#page-78
o If the initial offer is in an INVITE, the answer MUST be in a reliable non-failure message from UAS back to UAC which is correlated to that INVITE. For this specification, that is only the final 2xx response to that INVITE. That same exact answer MAY also be placed in any provisional responses sent prior to the answer. The UAC MUST treat the first session description it receives as the answer, and MUST ignore any session descriptions in subsequent responses to the initial INVITE.
Now we run into the situation in which A received the 183 g711 and being RFC compliant, dropped the 2nd SDP from the 200 OK.
=> No audio!
Has anyone encountered this situation and found a nice solution? Like generating an UPDATE or RE-INVITE towards A to change the codec in an RFC compliant way after the call is established?
Or is the only solution to remove all codecs except the required g711a one when more than one contact are registered on an AOR?
Mit freundlichen Grüssen
-Benoît Panizzon-
Hello,
On 15.10.24 09:41, Benoit Panizzon via sr-users wrote:
Hi Gang
Parallel forking situation.
A => B A => C
A invites with g711,g722 which is forked to B and C B reports ringing by sending 183 + SDP g711 C report 180 ringing. C establishes connection 200 OK + SDP g722
https://www.rfc-editor.org/rfc/rfc3261.html#page-78
o If the initial offer is in an INVITE, the answer MUST be in a reliable non-failure message from UAS back to UAC which is correlated to that INVITE. For this specification, that is only the final 2xx response to that INVITE. That same exact answer MAY also be placed in any provisional responses sent prior to the answer. The UAC MUST treat the first session description it receives as the answer, and MUST ignore any session descriptions in subsequent responses to the initial INVITE.Now we run into the situation in which A received the 183 g711 and being RFC compliant, dropped the 2nd SDP from the 200 OK.
=> No audio!
Has anyone encountered this situation and found a nice solution? Like generating an UPDATE or RE-INVITE towards A to change the codec in an RFC compliant way after the call is established?
Or is the only solution to remove all codecs except the required g711a one when more than one contact are registered on an AOR?
this is a common scenario and the UAC (the phone) should be able to cope with it.
By parallel forking, there will be two different To-tags, so practically during the call setup, the UAC has to maintain two different (early-state) dialogs, when one is answered with 200ok, the other one is cancelled.
If the UAC that you use doesn't support parallel forking by downstream proxies, then either you replace it with a capable one; configure it with a single codec; as you suggested, strip codecs on proxy leaving a single option; or route first via a transcoding system.
Cheers, Daniel
Hi Daniel
this is a common scenario and the UAC (the phone) should be able to cope with it.
By parallel forking, there will be two different To-tags, so practically during the call setup, the UAC has to maintain two different (early-state) dialogs, when one is answered with 200ok, the other one is cancelled.
If the UAC that you use doesn't support parallel forking by downstream proxies, then either you replace it with a capable one; configure it with a single codec; as you suggested, strip codecs on proxy leaving a single option; or route first via a transcoding system.
The UAC in question, is the Swisscom Mobile Network.
I guess it's not feasible to tell Swisscom to replace all the millions of mobile phones in operation. :-)
They tell me it's in the RFC, you side is not RFC compliant.
Mit freundlichen Grüssen
-Benoît Panizzon-
Hello,
I think the Swisscom UAC is not acting RFC compliant in this case, but the standard is a bit ambiguously phrased. The phrase related to the ignorance of any subsequent responses is about the 18x and 200OK for each particular dialog, but not that you just accept the first SDP that you receive and ignore the rest.
As per RFC:
13.2.2.4 2xx Responses
Multiple 2xx responses may arrive at the UAC for a single INVITE request due to a forking proxy. Each response is distinguished by the tag parameter in the To header field, and each represents a distinct dialog, with a distinct dialog identifier.
Additional to the options mentioned from Daniel, you could also just remove all SDP from provisional responses, but this will break early media obviously.
You maybe want to discuss this again with Swisscom, as it was a common error many years ago also for German provider infrastructure, and got fixed after some time.
Cheers,
Henning
-----Original Message----- From: Benoit Panizzon via sr-users sr-users@lists.kamailio.org Sent: Tuesday, October 15, 2024 1:17 PM To: Daniel-Constantin Mierla miconda@gmail.com Cc: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org; Benoit Panizzon benoit.panizzon@imp.ch Subject: [SR-Users] Re: parallel forking: how to fix 183 g711 then 200 ok g722?
Hi Daniel
this is a common scenario and the UAC (the phone) should be able to cope with it.
By parallel forking, there will be two different To-tags, so practically during the call setup, the UAC has to maintain two different (early-state) dialogs, when one is answered with 200ok, the other one is cancelled.
If the UAC that you use doesn't support parallel forking by downstream proxies, then either you replace it with a capable one; configure it with a single codec; as you suggested, strip codecs on proxy leaving a single option; or route first via a transcoding system.
The UAC in question, is the Swisscom Mobile Network.
I guess it's not feasible to tell Swisscom to replace all the millions of mobile phones in operation. :-)
They tell me it's in the RFC, you side is not RFC compliant.
Mit freundlichen Grüssen
-Benoît Panizzon-
Hi
Parallel forking situation.
Btw, exactly same issue also happens with serial forking.
A => B => C
A invites with g711/g722 B generates early 'ringback' audio g711 durcing 183 B times out, serial forking to C with inital SDP from A B answers with g722
I agree with Daniel, that messages from C contain a different to tag than the ones from B, so one could argue, this is not the same session.
But I doubt the companies building SBC takes such details into account.
In fact, I traced the issue again, our commercial SBC, operating in B2BUA mode is using a different set of ToTag,FromTag on each leg and the ToTag on the A leg are the same despite the ToTag on the B leg being different after forking. So from A's point of view, an additional SDP answer is receivedin the same session, which shall be dropped.
So, still wondering, is there a way so issue a Re-Invite or Update from Kamailio?
Mit freundlichen Grüssen
-Benoît Panizzon-
Hello,
as frequently mentioned, Kamailio is a SIP proxy and not a B2BUA in its core. There are some modules that implement limited B2BUA functions, like rtp_media_server. But I think if you want to go that route you should look into another B2BUA, or as suggested before use one of the other strategies.
Cheers,
Henning
-----Original Message----- From: Benoit Panizzon via sr-users sr-users@lists.kamailio.org Sent: Tuesday, October 15, 2024 2:54 PM To: Benoit Panizzon via sr-users sr-users@lists.kamailio.org Cc: Benoit Panizzon benoit.panizzon@imp.ch Subject: [SR-Users] Re: parallel forking: how to fix 183 g711 then 200 ok g722?
Hi
Parallel forking situation.
Btw, exactly same issue also happens with serial forking.
A => B => C
A invites with g711/g722 B generates early 'ringback' audio g711 durcing 183 B times out, serial forking to C with inital SDP from A B answers with g722
I agree with Daniel, that messages from C contain a different to tag than the ones from B, so one could argue, this is not the same session.
But I doubt the companies building SBC takes such details into account.
In fact, I traced the issue again, our commercial SBC, operating in B2BUA mode is using a different set of ToTag,FromTag on each leg and the ToTag on the A leg are the same despite the ToTag on the B leg being different after forking. So from A's point of view, an additional SDP answer is receivedin the same session, which shall be dropped.
So, still wondering, is there a way so issue a Re-Invite or Update from Kamailio?
Mit freundlichen Grüssen
-Benoît Panizzon-
-
Benoit Panizzon -
Daniel-Constantin Mierla -
Henning Westerholt