[Serusers] Serious defficiencies of the t_on_negative feature

[Jiri Kuthan]

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/