Re: [SR-Users] Parallel forking - first responder wins

Kamailio should definitely not consider evolving “B2BUA support”. :-)  — Sent from mobile, with due apologies for brevity and errors. > On Apr 21, 2020, at 11:35 AM, Julien Chavanton wrote: > >  > The main gain in using a B2BUA is that you take responsibility for > terminating the extra

Re: [SR-Users] Parallel forking - first responder wins

The main gain in using a B2BUA is that you take responsibility for terminating the extra call legs, it is as good as your B2BUA will be, by delegating the responsibility upstream you can not always be sure it is handled properly. I wonder if Kamailio should consider evolving in B2BUA support. I

Re: [SR-Users] Parallel forking - first responder wins

Hi Alex, Isn't the option of generating multiple call legs with a B2BUA more subject to dead air/ghost calls than letting kamailio handle parallel forking? Nuno On Tue, Apr 21, 2020 at 12:06 AM Alex Balashov wrote: > It should be noted at a rather general level that parallel forking is >

Re: [SR-Users] Parallel forking - first responder wins

It should be noted at a rather general level that parallel forking is replete with race conditions, and is a nasty and unwieldy aspect of SIP. The pain of using parallel forking to implement something like "ring groups", for example, is often not worth the savings in architectural complexity. If

Re: [SR-Users] Parallel forking - first responder wins

That is the reply route. Start testing and adding logging. The case with multiple 200 OK is something we have tested many times. The proxy should NOT try to do anything in that case, just forward the multiple 200 OK to the caller and let the UA decide what to do. The UA needs to ACK both, and

Re: [SR-Users] Parallel forking - first responder wins

You are right that this is not very explicit. Kamailio will cancel automatically once one branch connects but if it failed to cancel (meaning other branches connects) The originiting UAC will have to disconnect the extra calls. Which is something that is handled properly by most if not all. On

Re: [SR-Users] Parallel forking - first responder wins

Just thought of a follow up question - is it possible to find out which of the branches Kamailio chose as the winner? According to RFC multiple 200 OK could arrive before CANCEL is sent. Do I need to look for an outgoing ACK to know for sure which branch was chosen for sure or is there a way I

Re: [SR-Users] Parallel forking - first responder wins

Shouldn’t 183 also be a “final” response in regards to branching? On Mon, 20 Apr 2020 at 14:32, Ivan Ribakov wrote: > Thanks for pointing me to the specific section, Giovanni! I was searching > RFC for the “fork” and “merge” keywords so I never got even close to this > part of RFC. > > > On 20

Re: [SR-Users] Parallel forking - first responder wins

Thanks for pointing me to the specific section, Giovanni! I was searching RFC for the “fork” and “merge” keywords so I never got even close to this part of RFC. > On 20 Apr 2020, at 13:27, Giovanni Maruzzelli > wrote: > > ( and is implemented in automatic: when

Re: [SR-Users] Parallel forking - first responder wins

( and is implemented in automatic: when receive the 200 OK for a branch (the winning one), Kamailio sends CANCEL to the other branches ) On Mon, Apr 20, 2020 at 12:48 PM Giovanni Maruzzelli wrote: > Maybe is not very explicit, but I believe section 16.7(10) of RFC 3261 > deal with it (sends

Re: [SR-Users] Parallel forking - first responder wins

Maybe is not very explicit, but I believe section 16.7(10) of RFC 3261 deal with it (sends CANCEL to branches) -giovanni On Mon, Apr 20, 2020 at 11:48 AM Ivan Ribakov wrote: > As far as I understand, RFC3261 is not providing any instructions on how > to deal with forked INVITES specifically.

Re: [SR-Users] Parallel forking - first responder wins

As far as I understand, RFC3261 is not providing any instructions on how to deal with forked INVITES specifically. It just says that forking can result in multiple dialogs that are part of the same original call. I couldn’t find any prescriptions on how/when to deal with these multiple dialogs

Re: [SR-Users] Parallel forking - first responder wins

> On 20 Apr 2020, at 10:31, Ivan Ribakov wrote: > > Hi all, > > What I’m trying to achieve is to have Kamailio fork an INVITE to multiple > endpoints in parallel but only maintain the branch that responds first (first > to respond with 200 OK I guess). > > I’ve read the TM module

[SR-Users] Parallel forking - first responder wins

Hi all, What I’m trying to achieve is to have Kamailio fork an INVITE to multiple endpoints in parallel but only maintain the branch that responds first (first to respond with 200 OK I guess). I’ve read the TM module documentation on forking