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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

-- Jiri Kuthan http://iptel.org/~jiri/