Charles,
It's rather hard to say why you are having problems. Perhaps if you
use ngrep to produce a SIP debug output and email it to the serusers
list I'll be able to see what is happening.
Regards,
Paul
On Mon, 21 Feb 2005 02:16:47 +0800, Charles Wang <lazy.charles(a)gmail.com> wrote:
Dear Paul:
Thank you for your explanation, and I know what's it wrong on my plan.
Now, I change my value to sip:0939749xxx@ser.xxx.net.tw. If its
attribute is "callfwd", the call will be forward to my mobile
phone(0939749xxx) using route(3) to PSTN. So the result is OK.
But I rename the attribute "callfwd" to "fwdnoanswer" and use the
same value.
I want to test the no answer forward function.
UA 1011 make a call to UA 1022 and UA 1022 no answer. It should goto
failure_route[1] and make a call to route(3) depending on its "uri"
(phone number).
And I also find it runs to failure_route[1] and jump to route(3). But
the connection will disconnect for a few seconds. And displays "408
Request Timeout" on my X-Pro Client. I find it jumps to another
route(2) after disconnect.
I know I should not disturb you too much because of your works and
your new best example cfg file for us. But can you please help me to
discover what reason about it.
I think it should be the reason in my TM modules.
I am a Taiwanese and using a poor English.
Best Regard
Charles
Error Logs lists below:
------------------------------------------------------------------------------------------------------
SER: Failure Route section failure_route(1)
SER: fork to fwdnoanswer
SER: No Answer Failure and Jump to route(3)
SER: Demestic Call Off-Net section route(3)
SER: Connecting to PSTN.... <=========== Connect to PSTN here!!!!.
error: mediaproxy/sendMediaproxyCommand(): can't connect to MediaProxy
PDT:prefix2domain: no prefix found in [1022]
SER: SIP Call On-Net section route(2)
Subset of ser.cfg ( tm params, route[3] and failure_route[1] ) lists below:
------------------------------------------------------------------------------------------------------
# -- tm params --
modparam("tm", "fr_timer", 15)
modparam("tm", "fr_inv_timer", 22)
modparam("tm", "wt_timer", 5)
modparam("tm", "fr_inv_timer_avp", "inv_timeout")
route[3] {
log(1, "SER: Demestic Call Off-Net section route(3)\n");
# All Domestic Calls Go To CISCO 5300
if (method=="INVITE") {
if (!proxy_authorize("", "subscriber")) {
proxy_challenge("", "0");
break;
} else if (!check_from()) {
log(1, "Spoofed SIP call attempt");
sl_send_reply("403", "Use From=ID");
break;
} else if (!(is_from_local() || is_uri_host_local())) {
sl_send_reply("403", "Please register to use our
service");
break;
};
# enable caller id blocking for PSTN calls
if (isflagset(25)) {
append_rpid_hf();
};
};
# SIP->PSTN calls get 45 seconds to timeout
log(1, "SER: Connecting to PSTN.....\n");
avp_write("i:45", "inv_timeout");
rewritehost("61.220.190.243");
if (uri=~"[@:](192\.168\.|10\.|172\.(1[6-9]|2[0-9]|3[0-1])\.)"
&&
!search("^Route:")){
sl_send_reply("479", "We don't forward to private IP
addresses");
break;
};
if (method=="INVITE" || method=="ACK") {
use_media_proxy();
};
if (isflagset(31)) {
t_on_failure("1");
};
t_on_reply("1");
if (!t_relay()) {
if (method=="INVITE" || method=="ACK") {
end_media_session();
};
sl_reply_error();
};
}
failure_route[1] {
log(1, "SER: Failure Route section failure_route(1)\n");
# if caller hung up then don't sent to voicemail
if (t_check_status("487")) {
break;
};
if (isflagset(26) && t_check_status("486")) {
# forward busy is flag 26
if (avp_pushto("$ruri", "s:fwdbusy")) {
log(1, "SER: fork to fwdbusy\n");
avp_delete("s:fwdbusy");
append_branch();
resetflag(26);
# test for domestic PSTN gateway
if (uri=~"^sip:0[0-9]{9}@") {
# if (avp_check("$fwd_busy_type",
"eq/dom/i")) {
# test for domestic PSTN gateway
log(1, "SER: Busy Failure and Jump to
route(3)\n");
route(3);
} else if (uri=~"^sip:002[1-9][0-9]*@") {
# } else if (avp_check("$fwd_busy_type",
"eq/int/i")) {
# test for international PSTN gateway
log(1, "SER: Busy Failure and Jump to
route(6)\n");
route(6);
} else {
# default to sip call
log(1, "SER: Busy Failure and Jump to
route(2)\n");
route(2);
};
break;
};
};
# here we can have either voicemail __OR__ forward no answer
if (isflagset(27) && t_check_status("408")) {
# forward no answer is flag 27
if (avp_pushto("$ruri", "s:fwdnoanswer")) {
log(1, "SER: fork to fwdnoanswer\n");
avp_delete("s:fwdnoanswer");
append_branch();
resetflag(27);
if (uri=~"^sip:0[0-9]{9}@") {
# if (avp_check("$fwd_no_answer_type",
"eq/dom/i")) {
# test for domestic PSTN gateway
log(1, "SER: No Answer Failure and Jump to
route(3)\n");
route(3);
} else if (uri=~"^sip:002[1-9][0-9]*@") {
# } else if (avp_check("$fwd_no_answer_type",
"eq/int/i")) {
# test for international PSTN gateway
log(1, "SER: No Answer Failure and Jump to
route(6)\n");
route(6);
} else {
# default to sip call
log(1, "SER: No Answer Failure and Jump to
route(2)\n");
route(2);
};
break;
};
} else if (isflagset(31) && avp_pushto("$ruri",
"$voicemail")) {
avp_delete("$voicemail");
log(1, "SER: No Answer Failure and Jump to route(4)\n");
route(4);
break;
};
}
On Sun, 20 Feb 2005 00:29:50 -0500, Java Rockx <javarockx(a)gmail.com> wrote:
Charles,
One problem I see is that the value for the forwarded number is not a
valid SIP URI.
The values stored in the usr_preferences table must look like this:
sip:4075551212@mycompany.com
As for you question about the "-", "dom", and "int" avp
lines, these
are not database related. Instead this is a bit of a hack. I use these
three values as AVPs which get referenced in other route blocks. The
reason I call this a hack is that it would be better to move this kind
of validation to a custom C module.
Anyhow, the whole point of that route block is to validate the
destination number that the user is trying to have forwarded to. For
example, the user should not be allowed to forward to 911 or an
international number (unless they are entitled to international
dialing).
One more note: That ser.cfg that you're referencing is very unwieldy.
I've since restructured the entire thing for simplicity reasons. This
ser.cfg follows the very simple concepts shown in the default ser.cfg
example.
I feel it is much better to follow a per-method-type approach. For
example in the main route block I now have:
if (method=="BYE") {
route(1); # BYE message handler
} else if (method=="ACK") {
route(2); # ACK message handler
} else ....
I'm hoping to post my entire reworked ser.cfg to the mailing list this
week and seek comments and feedback on establishing "best coding
practices" for ser because as far as I know this hasn't been
addressed. My hopes are that the next ser.cfg I post, would at a
minimum, get the ball rolling on defining how best to code ser.cfg
logic.
Regards,
Paul