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 <[email protected] 
> <mailto:[email protected]>> 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 <[email protected] 
> <mailto:[email protected]>> 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 <[email protected] 
> <mailto:[email protected]>> 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 <[email protected] 
>> <mailto:[email protected]>> wrote:
>> 
>> 
>> 
>>> On 20 Apr 2020, at 10:31, Ivan Ribakov <[email protected] 
>>> <mailto:[email protected]>> 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
>>>  
>>> <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
>> [email protected] <mailto:[email protected]>
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 
>> <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> [email protected] <mailto:[email protected]>
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 
> <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
> [email protected] <mailto:[email protected]>
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

_______________________________________________
Kamailio (SER) - Users Mailing List
[email protected]
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Reply via email to