5 Feb
2003
5 Feb
'03
2:51 p.m.
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