Shouldn’t 183 also be a “final” response in regards to branching? On Mon, 20 Apr 2020 at 14:32, Ivan Ribakov <[email protected]> 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 <[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]> > 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]> >> 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]> wrote: >>> >>> >>> >>> On 20 Apr 2020, at 10:31, Ivan Ribakov <[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) >>> 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] >>> 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 >>> >> >> >> -- >> 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] > 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 > -- Regards, David Villasmil email: [email protected] phone: +34669448337
_______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
