[Serusers] Serious defficiencies of the t_on_negative feature

Maxim Sobolev sobomax at portaone.com
Wed Apr 16 00:25:15 CEST 2003


I do not have this problem anymore after fixing those matching bugs
in the tm module and rewriting config properly. Now transactions
are being routed properly and ser sends CANCELs for all branches it
created just like RFC requires.

Thanks!

-Maxim


On Mon, Apr 07, 2003 at 11:52:16PM +0200, Jiri Kuthan wrote:
> Maxim,
> 
> I'm not sure that's a defficiency in transaction processing -- I guess
> that's an issue in your configuration. What makes me think so is that
> you are asserting that BYEs go to the same destination as INVITEs do.
> That can't simply be an defficiency in TM since TM recognizes these
> as two distinct transactions and processes them separately. So I actually
> think the issue lives in config file, my guess is it is related to
> record-routing. If you send me your config file and network dumps,
> I will try to find it for you.
> 
> Regards,
> 
> -Jiri
> 
> At 03:51 PM 2/5/2003, Maxim Sobolev wrote:
> >Folks,
> >
> >I am currently playing with t_on_negative feature trying to implement
> >overflow routing (i.e. if original destination returns an error, then
> >request should be adjusted somehow and redirected to some, possibly
> >different, destination). I've started with the following config:
> >
> >route {
> >        [...]
> >        rewriteFromRoute();
> >        if (method == "INVITE") {
> >                addRecordRoute();
> >        };
> >
> >        if (method == "INVITE) {
> >                t_on_negative("1");
> >        };
> >        t_relay_to("address1", "port1");
> >}
> >
> >reply_route[1] {
> >        rewritehostport("address2:port2");
> >        append_branch();
> >}
> >
> >But quickly found that after transaction was redirected to
> >address2:port2, ACKs, BYEs, 200K and CANCELS are still being forwarded
> >to address1:port1, despite containing valid Route fields pointing to
> >address2:port2. Then I've modified it as follows to let ser use
> >information from that field to route ACKs, 200OKs and BYEs:
> >
> >route {
> >        [...]
> >        rewriteFromRoute();
> >        if (method == "INVITE") {
> >                addRecordRoute();
> >        };
> >
> >        if (method == "INVITE" || method == "CANCEL") {
> >                # INVITEs and CANCELs
> >                if (method == "INVITE) {
> >                        t_on_negative("1");
> >                };
> >                t_relay_to("address1", "port1");
> >        } else {
> >                # ACKs, 200OKs, BYEs
> >                t_relay();
> >        };
> >}
> >
> >reply_route[1] {
> >        rewritehostport("address2:port2");
> >        append_branch();
> >}
> >
> >For the most of the time everything works like a charm - if
> >address1:port1 is unreachable or replies with an error the request is
> >being redirected to the second destination, BUT if the initiating UA
> >tries to cancel transaction when transaction is already redirected but
> >before receiving final "200 OK" from the second destination, the
> >CANCEL request is forwarded to address1:port1, not to address2:port2
> >as it should be. I've tried to modify setup as follows, thinking that
> >maybe in the case of CANCEL explicit specification of proxy address
> >confuses ser, but no avail - in this case ser forwards the CANCEL
> >request to its own address and eventually it dies with Too Many Hops.
> >
> >route {
> >        [...]
> >        rewriteFromRoute();
> >        if (method == "INVITE") {
> >                addRecordRoute();
> >        };
> >        if (method == "INVITE") {
> >                # INVITEs
> >                t_on_negative("1");
> >                t_relay_to("address1", "port1");
> >        } else {
> >                # CANCELs, ACKs, 200OKs, BYEs
> >                t_relay();
> >        };
> >}
> >
> >reply_route[1] {
> >        rewritehostport("address2:port2");
> >        append_branch();
> >}
> >
> >I think that such behaviour arises from the fact that ser after
> >branching a transaction doesn't keep an address this transaction was
> >forwarded to. In my opinion, it needs to be corrected, so that after
> >receiving CANCEL from the UA that initiated transaction ser probably
> >should CANCEL *all* branches of this transaction. To do this it needs
> >to be able to tell exactly where to send CANCELs.
> >
> >What do you think?
> >
> >-Maxim
> >_______________________________________________
> >Serusers mailing list
> >serusers at lists.iptel.org
> >http://lists.iptel.org/mailman/listinfo/serusers 
> 
> --
> Jiri Kuthan            http://iptel.org/~jiri/ 




More information about the sr-users mailing list