4 Nov
2024
4 Nov
'24
5 p.m.
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().
4 Nov
4 Nov
5:16 p.m.
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
5:49 p.m.
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(a)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
21
days inactive
21
days old
2 comments
2 participants
participants (2)
-
Anton Yabchinskiy -
Daniel-Constantin Mierla