[Serusers] Questions on using ser.cfg version 0.9.0 for call forward/busy/noanswer
Java Rockx
javarockx at gmail.com
Mon Feb 21 01:43:26 CET 2005
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 at 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 at 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 at 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 at 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
>
More information about the sr-users
mailing list