[SR-Users] Parallel forking - first responder wins

David Villasmil david.villasmil.work at gmail.com
Mon Apr 20 15:50:16 CEST 2020


Shouldn’t 183 also be a “final” response in regards to branching?

On Mon, 20 Apr 2020 at 14:32, Ivan Ribakov <i.ribakov at zaleos.net> 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 <gmaruzz at gmail.com> 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 <gmaruzz at gmail.com>
> 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 <i.ribakov at zaleos.net>
>> 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 <oej at edvina.net> wrote:
>>>
>>>
>>>
>>> On 20 Apr 2020, at 10:31, Ivan Ribakov <i.ribakov at zaleos.net> 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 at lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
>>> _______________________________________________
>>> Kamailio (SER) - Users Mailing List
>>> sr-users at 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 at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-- 
Regards,

David Villasmil
email: david.villasmil.work at gmail.com
phone: +34669448337
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200420/06a9a2b5/attachment.html>


More information about the sr-users mailing list