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

2020-04-21 Thread Alex Balashov 
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 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 am expecting to receive tomatoes.
> 
> 
> 
>> On Tue, Apr 21, 2020 at 3:50 AM Nuno Ferreira  wrote:
>> 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
>>> 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 you have some other means of accomplishing what you want to
>>> accomplish, e.g. using a B2BUA to generate multiple independent call
>>> legs simultaneously ringing multiple destinations, I strongly advise you
>>> to go with that instead.
>>> 
>>> -- Alex
>>> 
>>> -- 
>>> Alex Balashov | Principal | Evariste Systems LLC
>>> 
>>> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
>>> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
>>> 
>>> ___
>>> Kamailio (SER) - Users Mailing List
>>> sr-users@lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>> 
>> 
>> 
>> *Confidentiality Notice: The information contained in this e-mail and any
>> attachments may be confidential. If you are not an intended recipient, you
>> are hereby notified that any dissemination, distribution or copying of this
>> e-mail is strictly prohibited. If you have received this e-mail in error,
>> please notify the sender and permanently delete the e-mail and any
>> attachments immediately. You should not retain, copy or use this e-mail or
>> any attachment for any purpose, nor disclose all or any part of the
>> contents to any other person. Thank 
>> you.*___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

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

2020-04-21 Thread Julien Chavanton 
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 am expecting to receive tomatoes.



On Tue, Apr 21, 2020 at 3:50 AM Nuno Ferreira  wrote:

> 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
>> 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 you have some other means of accomplishing what you want to
>> accomplish, e.g. using a B2BUA to generate multiple independent call
>> legs simultaneously ringing multiple destinations, I strongly advise you
>> to go with that instead.
>>
>> -- Alex
>>
>> --
>> Alex Balashov | Principal | Evariste Systems LLC
>>
>> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
>> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
>>
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>
>
>
> *Confidentiality Notice: The information contained in this e-mail and any
> attachments may be confidential. If you are not an intended recipient, you
> are hereby notified that any dissemination, distribution or copying of this
> e-mail is strictly prohibited. If you have received this e-mail in error,
> please notify the sender and permanently delete the e-mail and any
> attachments immediately. You should not retain, copy or use this e-mail or
> any attachment for any purpose, nor disclose all or any part of the
> contents to any other person. Thank you.*
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

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

2020-04-21 Thread Nuno Ferreira 
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
> 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 you have some other means of accomplishing what you want to
> accomplish, e.g. using a B2BUA to generate multiple independent call
> legs simultaneously ringing multiple destinations, I strongly advise you
> to go with that instead.
>
> -- Alex
>
> --
> Alex Balashov | Principal | Evariste Systems LLC
>
> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>

-- 
*Confidentiality Notice: The information contained in this e-mail and any

attachments may be confidential. If you are not an intended recipient, you

are hereby notified that any dissemination, distribution or copying of this

e-mail is strictly prohibited. If you have received this e-mail in error,

please notify the sender and permanently delete the e-mail and any

attachments immediately. You should not retain, copy or use this e-mail or

any attachment for any purpose, nor disclose all or any part of the

contents to any other person. Thank you.*
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

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

2020-04-20 Thread Alex Balashov 
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 you have some other means of accomplishing what you want to
accomplish, e.g. using a B2BUA to generate multiple independent call
legs simultaneously ringing multiple destinations, I strongly advise you
to go with that instead.

-- Alex

-- 
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

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

2020-04-20 Thread Olle E. Johansson 
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 if it can’t somehow
handle multiple calls, send a BYE to one of them.

/O

> On 20 Apr 2020, at 15:55, Ivan Ribakov  wrote:
> 
> 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 could 
> “catch” a winning branch through some sort of custom branch route (thinking 
> along the lines of “t_on_branch_success”)?
> 
> Thanks,
> Ivan
> 
>> On 20 Apr 2020, at 15:28, 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 Apr 2020, at 13:27, Giovanni Maruzzelli >> > wrote:
>>> 
>>> ( 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 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. 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 
>>> specifically which makes me think it depends on the application. Once 
>>> again, please correct me if I’m wrong.
>>> 
>>> So, in the same way as RFC3261 is not talking about forked INVITE 
>>> priorities or parallelism, but Kamailio (TM module) is providing a 
>>> mechanism for forking in parallel/serial modes (advanced feature that is 
>>> not part of RFC3261, but is built on top of it), I’m wondering whether 
>>> Kamailio (TM module) is providing any advanced features for dealing with 
>>> forked INVITE responses.
>>> 
>>> Thanks,
>>> Ivan
>>> 
>>> 
 On 20 Apr 2020, at 11:13, Olle E. Johansson >>> > wrote:
 
 
 
> 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 documentation on forking 
> (https://www.kamailio.org/docs/modules/stable/modules/tm.html#tm.serial_forking
>  
> )
>  and as far as I understood a combination of “seturi()” + 
> “append_branch()” + “t_relay()” command calls will allow me to send 
> multiple forked INVITEs in parallel. 
> 
> What I couldn't find information about in the documentation (please point 
> me to it in case I missed it) is what controls (if any) do I have over 
> forked requests. Do I need to keep track of the branches myself and 
> cancel others when first succeeds or does Kamailio have some kind of 
> setting for implementing such behaviour?
 
 It’s all implemented according to the RFC 3261 where you can read all the 
 cool details!
 
 /O
 
 ___
 Kamailio (SER) - Users Mailing List
 sr-users@lists.kamailio.org 
 https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 
 
>>> ___
>>> Kamailio (SER) - Users Mailing List
>>> sr-users@lists.kamailio.org 
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 
>>> 
>>> 
>>> 
>>> -- 
>>> Sincerely,
>>> 
>>> Giovanni Maruzzelli
>>> OpenTelecom.IT
>>> cell: +39 347 266 56 18
>>> 
>>> 
>>> 
>>> -- 
>>> Sincerely,
>>> 
>>> Giovanni Maruzzelli
>>> OpenTelecom.IT
>>> cell: +39 347 266 56 18
>>> 
>>> ___
>>> Kamailio (SER) - Users Mailing List
>>> sr-users@lists.kamailio.org 
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

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

2020-04-20 Thread Julien Chavanton 
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 Mon, Apr 20, 2020, 01: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 documentation on forking (
> https://www.kamailio.org/docs/modules/stable/modules/tm.html#tm.serial_forking)
> and as far as I understood a combination of “seturi()” + “append_branch()”
> + “t_relay()” command calls will allow me to send multiple forked INVITEs
> in parallel.
>
> What I couldn't find information about in the documentation (please point
> me to it in case I missed it) is what controls (if any) do I have over
> forked requests. Do I need to keep track of the branches myself and cancel
> others when first succeeds or does Kamailio have some kind of setting for
> implementing such behaviour?
>
> Thanks,
> Ivan
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

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

2020-04-20 Thread Ivan Ribakov 
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 could “catch” a 
winning branch through some sort of custom branch route (thinking along the 
lines of “t_on_branch_success”)?

Thanks,
Ivan

> On 20 Apr 2020, at 15:28, 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 Apr 2020, at 13:27, Giovanni Maruzzelli > > wrote:
>> 
>> ( 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 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. 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 
>> specifically which makes me think it depends on the application. Once again, 
>> please correct me if I’m wrong.
>> 
>> So, in the same way as RFC3261 is not talking about forked INVITE priorities 
>> or parallelism, but Kamailio (TM module) is providing a mechanism for 
>> forking in parallel/serial modes (advanced feature that is not part of 
>> RFC3261, but is built on top of it), I’m wondering whether Kamailio (TM 
>> module) is providing any advanced features for dealing with forked INVITE 
>> responses.
>> 
>> Thanks,
>> Ivan
>> 
>> 
>>> On 20 Apr 2020, at 11:13, Olle E. Johansson >> > wrote:
>>> 
>>> 
>>> 
 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 documentation on forking 
 (https://www.kamailio.org/docs/modules/stable/modules/tm.html#tm.serial_forking
  
 )
  and as far as I understood a combination of “seturi()” + 
 “append_branch()” + “t_relay()” command calls will allow me to send 
 multiple forked INVITEs in parallel. 
 
 What I couldn't find information about in the documentation (please point 
 me to it in case I missed it) is what controls (if any) do I have over 
 forked requests. Do I need to keep track of the branches myself and cancel 
 others when first succeeds or does Kamailio have some kind of setting for 
 implementing such behaviour?
>>> 
>>> It’s all implemented according to the RFC 3261 where you can read all the 
>>> cool details!
>>> 
>>> /O
>>> 
>>> ___
>>> Kamailio (SER) - Users Mailing List
>>> sr-users@lists.kamailio.org 
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 
>>> 
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org 
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 
>> 
>> 
>> 
>> -- 
>> Sincerely,
>> 
>> Giovanni Maruzzelli
>> OpenTelecom.IT
>> cell: +39 347 266 56 18
>> 
>> 
>> 
>> -- 
>> Sincerely,
>> 
>> Giovanni Maruzzelli
>> OpenTelecom.IT
>> cell: +39 347 266 56 18
>> 
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org 
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 
>> 
> 

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

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

2020-04-20 Thread David Villasmil 
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 Apr 2020, at 13:27, Giovanni Maruzzelli  wrote:
>
> ( 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 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. 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 specifically which makes me think it depends on the application.
>>> Once again, please correct me if I’m wrong.
>>>
>>> So, in the same way as RFC3261 is not talking about forked INVITE
>>> priorities or parallelism, but Kamailio (TM module) is providing a
>>> mechanism for forking in parallel/serial modes (advanced feature that is
>>> not part of RFC3261, but is built on top of it), I’m wondering whether
>>> Kamailio (TM module) is providing any advanced features for dealing with
>>> forked INVITE responses.
>>>
>>> Thanks,
>>> Ivan
>>>
>>>
>>> On 20 Apr 2020, at 11:13, Olle E. Johansson  wrote:
>>>
>>>
>>>
>>> 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 documentation on forking (
>>> https://www.kamailio.org/docs/modules/stable/modules/tm.html#tm.serial_forking)
>>> and as far as I understood a combination of “seturi()” + “append_branch()”
>>> + “t_relay()” command calls will allow me to send multiple forked INVITEs
>>> in parallel.
>>>
>>> What I couldn't find information about in the documentation (please
>>> point me to it in case I missed it) is what controls (if any) do I have
>>> over forked requests. Do I need to keep track of the branches myself and
>>> cancel others when first succeeds or does Kamailio have some kind of
>>> setting for implementing such behaviour?
>>>
>>>
>>> It’s all implemented according to the RFC 3261 where you can read all
>>> the cool details!
>>>
>>> /O
>>>
>>> ___
>>> Kamailio (SER) - Users Mailing List
>>> sr-users@lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
>>> ___
>>> Kamailio (SER) - Users Mailing List
>>> sr-users@lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>
>>
>> --
>> Sincerely,
>>
>> Giovanni Maruzzelli
>> OpenTelecom.IT
>> cell: +39 347 266 56 18
>>
>>
>
> --
> Sincerely,
>
> Giovanni Maruzzelli
> OpenTelecom.IT
> cell: +39 347 266 56 18
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-- 
Regards,

David Villasmil
email: david.villasmil.w...@gmail.com
phone: +34669448337
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

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

2020-04-20 Thread Ivan Ribakov 
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 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 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. 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 
> specifically which makes me think it depends on the application. Once again, 
> please correct me if I’m wrong.
> 
> So, in the same way as RFC3261 is not talking about forked INVITE priorities 
> or parallelism, but Kamailio (TM module) is providing a mechanism for forking 
> in parallel/serial modes (advanced feature that is not part of RFC3261, but 
> is built on top of it), I’m wondering whether Kamailio (TM module) is 
> providing any advanced features for dealing with forked INVITE responses.
> 
> Thanks,
> Ivan
> 
> 
>> On 20 Apr 2020, at 11:13, Olle E. Johansson > > wrote:
>> 
>> 
>> 
>>> 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 documentation on forking 
>>> (https://www.kamailio.org/docs/modules/stable/modules/tm.html#tm.serial_forking
>>>  
>>> )
>>>  and as far as I understood a combination of “seturi()” + “append_branch()” 
>>> + “t_relay()” command calls will allow me to send multiple forked INVITEs 
>>> in parallel. 
>>> 
>>> What I couldn't find information about in the documentation (please point 
>>> me to it in case I missed it) is what controls (if any) do I have over 
>>> forked requests. Do I need to keep track of the branches myself and cancel 
>>> others when first succeeds or does Kamailio have some kind of setting for 
>>> implementing such behaviour?
>> 
>> It’s all implemented according to the RFC 3261 where you can read all the 
>> cool details!
>> 
>> /O
>> 
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org 
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 
>> 
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org 
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 
> 
> 
> 
> -- 
> Sincerely,
> 
> Giovanni Maruzzelli
> OpenTelecom.IT
> cell: +39 347 266 56 18
> 
> 
> 
> -- 
> Sincerely,
> 
> Giovanni Maruzzelli
> OpenTelecom.IT
> cell: +39 347 266 56 18
> 
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org 
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

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

2020-04-20 Thread Giovanni Maruzzelli 
( 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 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. 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 specifically which makes me think it depends on the application.
>> Once again, please correct me if I’m wrong.
>>
>> So, in the same way as RFC3261 is not talking about forked INVITE
>> priorities or parallelism, but Kamailio (TM module) is providing a
>> mechanism for forking in parallel/serial modes (advanced feature that is
>> not part of RFC3261, but is built on top of it), I’m wondering whether
>> Kamailio (TM module) is providing any advanced features for dealing with
>> forked INVITE responses.
>>
>> Thanks,
>> Ivan
>>
>>
>> On 20 Apr 2020, at 11:13, Olle E. Johansson  wrote:
>>
>>
>>
>> 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 documentation on forking (
>> https://www.kamailio.org/docs/modules/stable/modules/tm.html#tm.serial_forking)
>> and as far as I understood a combination of “seturi()” + “append_branch()”
>> + “t_relay()” command calls will allow me to send multiple forked INVITEs
>> in parallel.
>>
>> What I couldn't find information about in the documentation (please point
>> me to it in case I missed it) is what controls (if any) do I have over
>> forked requests. Do I need to keep track of the branches myself and cancel
>> others when first succeeds or does Kamailio have some kind of setting for
>> implementing such behaviour?
>>
>>
>> It’s all implemented according to the RFC 3261 where you can read all the
>> cool details!
>>
>> /O
>>
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>
>
> --
> Sincerely,
>
> Giovanni Maruzzelli
> OpenTelecom.IT
> cell: +39 347 266 56 18
>
>

-- 
Sincerely,

Giovanni Maruzzelli
OpenTelecom.IT
cell: +39 347 266 56 18
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

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

2020-04-20 Thread Giovanni Maruzzelli 
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. 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 specifically which makes me think it depends on the application.
> Once again, please correct me if I’m wrong.
>
> So, in the same way as RFC3261 is not talking about forked INVITE
> priorities or parallelism, but Kamailio (TM module) is providing a
> mechanism for forking in parallel/serial modes (advanced feature that is
> not part of RFC3261, but is built on top of it), I’m wondering whether
> Kamailio (TM module) is providing any advanced features for dealing with
> forked INVITE responses.
>
> Thanks,
> Ivan
>
>
> On 20 Apr 2020, at 11:13, Olle E. Johansson  wrote:
>
>
>
> 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 documentation on forking (
> https://www.kamailio.org/docs/modules/stable/modules/tm.html#tm.serial_forking)
> and as far as I understood a combination of “seturi()” + “append_branch()”
> + “t_relay()” command calls will allow me to send multiple forked INVITEs
> in parallel.
>
> What I couldn't find information about in the documentation (please point
> me to it in case I missed it) is what controls (if any) do I have over
> forked requests. Do I need to keep track of the branches myself and cancel
> others when first succeeds or does Kamailio have some kind of setting for
> implementing such behaviour?
>
>
> It’s all implemented according to the RFC 3261 where you can read all the
> cool details!
>
> /O
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>


-- 
Sincerely,

Giovanni Maruzzelli
OpenTelecom.IT
cell: +39 347 266 56 18
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

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

2020-04-20 Thread Ivan Ribakov 
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 specifically 
which makes me think it depends on the application. Once again, please correct 
me if I’m wrong.

So, in the same way as RFC3261 is not talking about forked INVITE priorities or 
parallelism, but Kamailio (TM module) is providing a mechanism for forking in 
parallel/serial modes (advanced feature that is not part of RFC3261, but is 
built on top of it), I’m wondering whether Kamailio (TM module) is providing 
any advanced features for dealing with forked INVITE responses.

Thanks,
Ivan


> On 20 Apr 2020, at 11:13, Olle E. Johansson  wrote:
> 
> 
> 
>> 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 documentation on forking 
>> (https://www.kamailio.org/docs/modules/stable/modules/tm.html#tm.serial_forking
>>  
>> )
>>  and as far as I understood a combination of “seturi()” + “append_branch()” 
>> + “t_relay()” command calls will allow me to send multiple forked INVITEs in 
>> parallel. 
>> 
>> What I couldn't find information about in the documentation (please point me 
>> to it in case I missed it) is what controls (if any) do I have over forked 
>> requests. Do I need to keep track of the branches myself and cancel others 
>> when first succeeds or does Kamailio have some kind of setting for 
>> implementing such behaviour?
> 
> It’s all implemented according to the RFC 3261 where you can read all the 
> cool details!
> 
> /O
> 
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org 
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 
> 
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

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

2020-04-20 Thread Olle E. Johansson 


> 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 documentation on forking 
> (https://www.kamailio.org/docs/modules/stable/modules/tm.html#tm.serial_forking
>  
> )
>  and as far as I understood a combination of “seturi()” + “append_branch()” + 
> “t_relay()” command calls will allow me to send multiple forked INVITEs in 
> parallel. 
> 
> What I couldn't find information about in the documentation (please point me 
> to it in case I missed it) is what controls (if any) do I have over forked 
> requests. Do I need to keep track of the branches myself and cancel others 
> when first succeeds or does Kamailio have some kind of setting for 
> implementing such behaviour?

It’s all implemented according to the RFC 3261 where you can read all the cool 
details!

/O

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users