28 Feb
2005
28 Feb
'05
9:43 a.m.
Juha Heinanen wrote:
Andres writes:
Just found the mistake in our ser.cfg. It turns our that at the bottom
of our main logic we had our Voicemail routing code. So if local user
was not in location database then the call was to be routed to Voicemail
(route 6). This was below all of our PSTN gateway routing code. I
never even considered that the CANCEL message would pass through that
part but I guess it did!
# If destination user is OFFLINE then send to Voicemail Server
if ((!lookup("location")) {
if (method == "INVITE"){
route(6);
break;
} else {
sl_send_reply("404", "Not Found");
break;
};
};
Changing the code to the following fixed the issue:
# If destination user is OFFLINE then send to Voicemail Server
if ((!lookup("location")) & (does_uri_exist())) {
if (method == "INVITE"){
route(6);
break;
} else {
sl_send_reply("404", "Not Found");
break;
};
};
Thanks Juha for your valuable insight. We will now be making more
extensive testing your LCR module now that we worked out this issue. We
will let you on the results.
Regards,
Andres.
That may be true for users that are local to the
SER, but I just made a
simple test on my lab server (with CVS HEAD), and it does not work for
PSTN redirections.
it should not matter if r-uri is rewritten as result of location lookup
or rewritehostport.
A simple routing scenario like the one below will
send the INVITE to
route(7), but the CANCEL will never get there. The only way the CANCEL
gets there is to place another if statement with reference to
method=="CANCEL" and route it.
are you sure that your script calls t_relay() on the cancel request? if
so, where according to ethereal did ser sent the cancel or did you get
some error message in syslog? has your gw replied with trying or
ringing before you issue cancel?
-- juha