Hello,
In our system we've encountered the following situation.
There's a Kamailio proxy and a few REGISTER'ed devices behind the proxy. When there's an INVITE to these multiple devices, two of them simultaneously answer the call. Kamailio proxy accepts the first 200 OK from one of the devices and tries to CANCEL all other branches. But the second 200 OK device have already responded OK and doesn't acknowledge the CANCEL. So, there's now one established dialog with media, and another "established" one neither having media nor being correctly terminated.
Looks like the similar scenario is described in section 3.1.2 of RFC 5407 (Example Call Flows of Race Conditions in the Session Initiation Protocol (SIP)).
Is it possible to mitigate such scenarios in a Kamailio proxy? E.g., is it possible to send an additional BYE to these CANCEL'led branches?
In current configuration, Kamailio proxy retrieves contacts with registrar:lookup() and does parallel forking with tm:t_relay().
Hello,
On 04.11.24 15:00, Anton Yabchinskiy via sr-users wrote:
Hello,
In our system we've encountered the following situation.
There's a Kamailio proxy and a few REGISTER'ed devices behind the proxy. When there's an INVITE to these multiple devices, two of them simultaneously answer the call. Kamailio proxy accepts the first 200 OK from one of the devices and tries to CANCEL all other branches. But the second 200 OK device have already responded OK and doesn't acknowledge the CANCEL. So, there's now one established dialog with media, and another "established" one neither having media nor being correctly terminated.
Looks like the similar scenario is described in section 3.1.2 of RFC 5407 (Example Call Flows of Race Conditions in the Session Initiation Protocol (SIP)).
Is it possible to mitigate such scenarios in a Kamailio proxy? E.g., is it possible to send an additional BYE to these CANCEL'led branches?
In current configuration, Kamailio proxy retrieves contacts with registrar:lookup() and does parallel forking with tm:t_relay().
the handling of such case is done by the calling device, which should send the BYE to the branch that it does not want to continue with. Theoretically, the calling UA can consider the 2nd 200ok better option (e.g., with wideband codec) and terminate the branch with the first 200ok, although I never saw it happening so far.
Is the calling UA sending ACK for the 2nd 200ok?
Cheers, Daniel
the handling of such case is done by the calling device, which should send the BYE to the branch that it does not want to continue with.
Ah, I see.
I don't have any .pcap files for the actual call yet, and I'm trying to reproduce the call with the proxy and a bunch of SIPp scenarios. And that's indeed that happens in my tests: Kamailio passes both 200 OK for the INVITE to the caller.
Thanks!
________________________________________ От: Daniel-Constantin Mierla miconda@gmail.com Отправлено: 4 ноября 2024 г. 16:16 Кому: Kamailio (SER) - Users Mailing List Копия: Anton Yabchinskiy Тема: Re: [SR-Users] Simultaneous INVITE responses from multiple branches
[EXTERNAL]
Hello,
On 04.11.24 15:00, Anton Yabchinskiy via sr-users wrote:
Hello,
In our system we've encountered the following situation.
There's a Kamailio proxy and a few REGISTER'ed devices behind the proxy. When there's an INVITE to these multiple devices, two of them simultaneously answer the call. Kamailio proxy accepts the first 200 OK from one of the devices and tries to CANCEL all other branches. But the second 200 OK device have already responded OK and doesn't acknowledge the CANCEL. So, there's now one established dialog with media, and another "established" one neither having media nor being correctly terminated.
Looks like the similar scenario is described in section 3.1.2 of RFC 5407 (Example Call Flows of Race Conditions in the Session Initiation Protocol (SIP)).
Is it possible to mitigate such scenarios in a Kamailio proxy? E.g., is it possible to send an additional BYE to these CANCEL'led branches?
In current configuration, Kamailio proxy retrieves contacts with registrar:lookup() and does parallel forking with tm:t_relay().
the handling of such case is done by the calling device, which should send the BYE to the branch that it does not want to continue with. Theoretically, the calling UA can consider the 2nd 200ok better option (e.g., with wideband codec) and terminate the branch with the first 200ok, although I never saw it happening so far.
Is the calling UA sending ACK for the 2nd 200ok?
Cheers, Daniel
-- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy, Training and Development Services -- asipto.com
-
Anton Yabchinskiy -
Daniel-Constantin Mierla