Andrei Pelinescu-Onciul wrote:
If you want to override the final reply sent by ser,
you have to catch
it in the failure route and send a new reply in its place (if you send a
reply " by hand" in the failure route, its value won't be fixed by ser
final reply processing code) e.g.:
failure_route[0]{
if (t_check_status("503")){
t_reply("503", "Keeping 503 because I don't like the rfc");
return;
}
/* ... */
}
There are other ways to do it, but I think this is the shortest one.
Andrei
This suggestion does appear to override the reply and that's great.
I found that I have to do a t_on_failure("FAILURE_ROUTE")
on all INVITEs, not just those where the @to.tag==""
(as written in the sample ser.cfg file).
However, this alteration triggers another problem, as the
logs report:
Oct 21 02:37:47 ser1 ser[19225]: WARNING: -_set_fr_timer- already added:
0x80252
7400 , tl=0x802527418!!!
Oct 21 02:37:47 ser1 ser[19225]: BUG: set_final_timer: start retr failed
for 0x8
02527400
Neither of these appear to be things I have intentionally
specified/set in ser.cfg, although perhaps they go by other
names. Anybody have any idea what it is complaining about?
The pieces that might help troubleshoot this:
route[PSTN_FORWARD]
{
log(1, "Route PSTN_FORWARD\n");
# here you could decide wether this call needs a RTP relay or not
# Set where packets should be sent. If you don't do this here,
# OPTIONS and other messages will be transmitted back to the
# outside interface and processed all over again, and you eventually
# get a Too Many Hops error on every OPTIONS message.
# Code to make this point in multiple directions would be needed
# to implement two-way origination.
rewritehost("10.131.0.2"); #Send to Telica
xlog("L_ERR", "DDD method:<%rm> From URI:<%fu> From
Tag:<%ft>
Destination Set:<%ds> Request's R-URI:<%ru> To URI:<%tu> Received
IP:<%Ri> Source IP:<%si> Sou
rce Port:<%sp> Call ID:<%ci> Host's Hostname:<%Hn> Hosts
Domainname:<%Hd> Hosts FQDN <%Hf> Hosts IP <%Hi>");
if (method == "BYE" || method == "CANCEL") {
unforce_rtp_proxy();
}
else if (method == "INVITE") {
...Customer-specific sanity checks here, pass or reject, no modifications...
# Force record routing if either party is behind NAT
$record_route_nated = true;
force_rtp_proxy("he","10.131.128.18");
}
t_on_reply("PSTN_REPLY");
# if this is called from the failure route we need to open a new
branch
if (isflagset(FLAG_FAILUREROUTE)) {
append_branch();
}
# if this is an initial INVITE (without a To-tag) we might try another
# (forwarding or voicemail) target after receiving an error
#Use_next_for_503_fixup# if (method=="INVITE" &&
@to.tag=="") {
if (method=="INVITE") {
xlog("L_ERR", "route[PSTN] arm FAILURE_ROUTE");
t_on_failure("FAILURE_ROUTE");
}
# send it out now; use stateful forwarding as it works reliably
# even for UDP2TCP
if (!t_relay()) {
sl_reply_error();
}
drop;
}
onreply_route["PSTN_REPLY"]
{
xlog("L_ERR","In onreply_route %rs %rr");
#xlog("L_ERR", "EEE method:<%rm> From URI:<%fu> From
Tag:<%ft>
Destination Set:<%ds> Request's R-URI:<%ru> To URI:<%tu> Received
IP:<%Ri> Source IP:<%si> So
urce Port:<%sp> Call ID:<%ci> Host's Hostname:<%Hn> Hosts
Domainname:<%Hd> Hosts FQDN <%Hf> Hosts IP <%Hi>");
# Rewrite Contact in 200 OK if UAS is behind NAT
if (@cseq.method == "INVITE") {
xlog("L_ERR","onreply_route[NAT_MANGLE] R1 %rs %rr");
} else {
xlog("L_ERR","onreply_route[NAT_MANGLE] R2 %rs %rr");
}
# Apply RTP proxy if necessary, but only for INVITE transactions
# and 183 or 2xx replies
if (@cseq.method != "INVITE") return;
if ((status =~ "(183)|2[0-9][0-9]") &&
search("^(Content-Type|c):.*application/sdp")) {
# xlog("L_ERR","onreply_route[NAT_MANGLE] force rtp proxy
%rs %rr K5");
# Fix outbound c= value to reflect what client can reach
route(OUTBOUND_RTP_FIXUP);
# xlog("L_ERR","onreply_route[NAT_MANGLE] back from
force_rtp_proxy %rs %rr K6");
}
return;
}
failure_route[FAILURE_ROUTE]
{
log(1, "Route ROUTE FAILURE\n");
if (t_check_status("503")) {
t_reply("503", "Keeping 503 because I don't like the
rfc");
log(1, "DID 503 FIX\n");
return;
}
# mark for the other routes that we are operating from here on from a
# failure route
setflag(FLAG_FAILUREROUTE);
# if we received a busy and a busy target is set, forward it there
# Note: again the forwarding target has to be a routeable URI
if (t_check_status("486|600")) {
if ($tu.fwd_busy_target) {
route(FORWARD);
}
# alternatively you could forward the request to SEMS/voicemail here
} else if (t_check_status("408|480")) {
# if we received no answer and the noanswer target is set,
# forward it there
# Note: again the target has to be a routeable URI
if ($tu.fwd_noanswer_target) {
route(FORWARD);
}
# alternatively you could forward the request to SEMS/voicemail here
}
}
Debugging log messages:
Oct 21 02:37:47 ser1 ser[19224]: Route PSTN_FORWARD
Oct 21 02:37:47 ser1 ser[19224]: DDD method:<INVITE> From
URI:<sip:9999999999@11.22.33.44> From Tag:<as5e682242> Destination
Set:<Contact: sip:6666666666@10.131.0.2> Request's
R-URI:<sip:6666666666@10.131.0.2> To
URI:<sip:6666666666@222.222.222.222> Received IP:<10.181.90.6> Source
IP:<11.22.33.44> Source Port:<5060> Call
ID:<5624efc06bde6e38543ebd53687a5b2b@11.22.33.44> Host's
Hostname:<ser1> Hosts Domainname:<the.test.box.notvalid> Hosts FQDN
<the.test.box.notvalid> Hosts IP <>
Oct 21 02:37:47 ser1 ser[19224]: route[PSTN] arm FAILURE_ROUTE
Oct 21 02:37:47 ser1 ser[19225]: In onreply_route 100 Trying
Oct 21 02:37:47 ser1 ser[19225]: onreply_route[NAT_MANGLE] R1 100 Trying
Oct 21 02:37:47 ser1 ser[19225]: In onreply_route 503 Service Unavailable
Oct 21 02:37:47 ser1 ser[19225]: onreply_route[NAT_MANGLE] R1 503
Service Unavailable
Oct 21 02:37:47 ser1 ser[19225]: Route ROUTE FAILURE
Oct 21 02:37:47 ser1 ser[19225]: DID 503 FIX
Oct 21 02:37:47 ser1 ser[19225]: WARNING: -_set_fr_timer- already added:
0x802527400 , tl=0x802527418!!!
Oct 21 02:37:47 ser1 ser[19225]: BUG: set_final_timer: start retr failed
for 0x802527400
Oct 21 02:37:47 ser1 ser[19224]: MAIN ROUTE WITH method:<ACK> From
URI:<sip:9999999999@11.22.33.44> From Tag:<as5e682242> Destination
Set:<<null>> Request's R-URI:<sip:6666666666@222.222.222.222> To
URI:<sip:6666666666@222.222.222.222> Received IP:<10.181.90.6> Source
IP:<11.22.33.44> Source Port:<5060> Call
ID:<5624efc06bde6e38543ebd53687a5b2b@11.22.33.44> Host's
Hostname:<ser1> Hosts Domainname:<the.test.box.notvalid> Hosts FQDN
<the.test.box.notvalid> Hosts IP <>
...
Thanks in advance for any sage advice on what is going on here.