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@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@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