New subject: [Serusers] a question about "cancel" inforwardingscenario

15 Feb 2006


      Dear Greger V. Teigre,
Thanks for your suggestion.
I've reset the fr_inv_timer and debug level, and put some log functions into ser.cfg:
# ----------- global configuration parameters ------------------------
debug=7         # debug level (cmd line: -dddddddddd)
fork=no
log_stderror=yes        # (cmd line: -E)
listen=218.97.252.39
check_via=no    # (cmd. line: -v)
dns=no           # (cmd. line: -r)
rev_dns=no      # (cmd. line: -R)
#port=5060
#children=4
alias=localhost.localdomain
alias=218.97.252.39
# ------------------ module loading ----------------------------------
loadmodule "/usr/local/lib/ser/modules/sl.so"
loadmodule "/usr/local/lib/ser/modules/tm.so"
# ----------------- setting module-specific parameters ---------------
# -- tm params --
# set time for which ser will be waiting for a final response;
# fr_inv_timer sets value for INVITE transactions, fr_timer
# for all others
modparam("tm", "fr_inv_timer", 120 )
modparam("tm", "fr_timer", 10 )
# -------------------------  request routing logic -------------------
# main routing logic
route{
        # for testing purposes, simply okay all REGISTERs
        if (method=="REGISTER") {
                log("REGISTER\n");
                sl_send_reply("200", "ok");
                break;
        };
        seturi("sip:200@218.97.252.35:5060");
        # if we do not get a positive reply, continue at reply_route[1]
        log("for test\n");
        t_on_failure("1");
        # forward the request to all destinations in destination set now
        t_relay();
}
failure_route[1] {
        #when caller cancel, terminate the call
        if (t_check_status("487")) {
              log("cancel received\n");
              t_reply("487", "Request Terminated");
              break;
        };
        # forwarding failed -- try again at another destination
        append_branch("sip:300@218.97.252.44:5060");
        log(1,"first redirection\n");
        # if this alternative destination fails too, proceed to reply_route[2]
        #t_on_failure("2");
        t_relay();
}
Here is my test:
When ua1(sip:100@localhost.localdomain:5060) call sip:400@localhost.localdomain:5060, SER, at once, rewrites uri and sends invite to ua2(sip:200@218.97.252.35:5060). But because ua2 is offline, SER forwards the invite to ua3(sip:300@218.97.252.44:5060) and then ua3 begins ringing. Now, ua1 sends cancel to SER, SER sends cancel to ua3. ua3 returns "487" to SER and SER sends "408" to ua1. I don't know whether the timers were reset properly before forwarding.
And with the attachment is the ser debug info. Please have a look.
    
Thanks again.
...
I think you need to make an ngrep SIP trace of the two scenarios. SER will 
not generate a 408 unless the timer hits. Increase the timer (it will be 
easier to see what happens). You use a very low timer value 
(fr_inv_timer=15). Set it to 120. Then look for the CANCEL from ua3. Does 
SER receive the CANCEL and process it (use debug mode 7)?
I'm not sure if this is the same as mentioned in the bug referred to in 
another reply, but let's try to find out.
Please post the ngrep trace for the two scenarios.
g-)
----- Original Message ----- 
From: "zhangshuai" zhangshuai@goldentek.biz
To: "serusers" serusers@lists.iptel.org
Cc: "wuyuan" wuyuan@goldentek.biz
Sent: Tuesday, February 14, 2006 9:41 AM
Subject: Re: Re: Re: [Serusers] a question about "cancel" in 
forwardingscenario
...
Dear Greger V. Teigre,
I've tried t_on_failure("2").
failure_route[2] {
    #when caller cancel, terminate the call
    if (t_check_status("487")) {
         log(1,"cancel received\n");
         t_reply("487", "Request Terminated");
         break;
    }
}
There are similar lines in failure_route[1]. When ua2 is ringing and ua1 
cancel the call, the value of "t_check_status("487")" in failure_route[1] 
will be true. However, When ua3 is ringing and ua1 cancel the call, the 
value of "t_check_status("487")" in failure_route[2] will be false. This 
time, t_check_status() returns "408". I don't know why SER generates "408" 
under this circumstance. My ser's version is 0.9.3 and I just run 
update_from_cvs. And I found similar description here:
http://bugs.sip-router.org/browse/SER-63
Is it an unsolved problem?
...
Do some logging, what happens in the failure route? To me, it looks like
your config appends a branch. BTW, run update_from_cvs in your SER source
dir top make sure you get the latest bug fixes!
g-)
----- Original Message ----- 
From: "zhangshuai" zhangshuai@goldentek.biz
To: "serusers" serusers@lists.iptel.org
Cc: "wuyuan" wuyuan@goldentek.biz
Sent: Tuesday, February 14, 2006 3:49 AM
Subject: Re: Re: [Serusers] a question about "cancel" in forwarding 
scenario
...
Dear Greger V. Teigre,
Thanks for your quick reply.
I have read the sergettingstarted05.pdf (Based upon SER version 0.9.3) 
and
tested the onr.cfg in
ser-0.9.3.GettingStarted.1.3.tar.gz/ser-0.9.3/examples many times. SER
sent out "408" to caller immediately after received "486" from ua3. I
don't know how does ser's failure route deal with this kind of "cancel"
when the invite has been forwarded. Any ideas will help me a lot. 
Thanks!
Here is the onr.cfg:
# ------------------ module loading ----------------------------------
loadmodule "/usr/local/lib/ser/modules/sl.so"
loadmodule "/usr/local/lib/ser/modules/tm.so"
# ----------------- setting module-specific parameters ---------------
# -- tm params --
# set time for which ser will be waiting for a final response;
# fr_inv_timer sets value for INVITE transactions, fr_timer
# for all others
modparam("tm", "fr_inv_timer", 15 )
modparam("tm", "fr_timer", 10 )
# -------------------------  request routing logic -------------------
# main routing logic
route{
       # for testing purposes, simply okay all REGISTERs
       if (method=="REGISTER") {
               log("REGISTER");
               sl_send_reply("200", "ok");
               break;
       };
       # try these two destinations first in parallel; the second
       # destination is targeted to sink port -- that will make ser
       # wait until timer hits
       seturi("sip:200@218.97.252.35:5060");
       #append_branch("sip:300@218.97.252.36:5060");
       # if we do not get a positive reply, continue at reply_route[1]
       t_on_failure("1");
       # forward the request to all destinations in destination set now
       t_relay();
}
failure_route[1] {
       #when caller cancel, terminate the call
    if (t_check_status("487")) {
      t_reply("487", "Request Terminated");
      break;
    };
       # forwarding failed -- try again at another destination
       append_branch("sip:300@218.97.252.44:5060");
       log(1,"first redirection\n");
       # if this alternative destination fails too, proceed to
reply_route[2]
       #t_on_failure("2");
       t_relay();
}
Thanks in advance.
Have a good day!
Shuai
...
The internal SER timer hits and the request times out (the request is 
not
terminated).
See SER-GettingStarted doc at ONsip.org for a full example of call
features
like forwarding.
g-)
----- Original Message ----- 
From: "zhangshuai" zhangshuai@goldentek.biz
To: "serusers" serusers@lists.iptel.org
Cc: "wuyuan" wuyuan@goldentek.biz
Sent: Friday, February 10, 2006 11:18 AM
Subject: [Serusers] a question about "cancel" in forwarding scenario
...
Dear All,
I want to make use of avpops module to achieve forward on-no-reply. 
When
ua1 calls ua2 and ua2 is off-line, or busy, or doesn't answer the 
phone,
the invite should be forwarded to ua3 and ua3 begins ringing.
In my tests, first, ua1 sends "cancel" when ua2 is ringing. Ua1 
receives
"487 Request Terminated" from SER. Second, ua1 sends "cancel" when ua3
is
ringing. So, theoretically, ua1 should receive "487 Request 
Terminated"
after "200 canceling" from SER, right? But, ua1 received "408 Request
Timeout" instead. So strange. How come?
I think something is wrong with my ser.cfg. Could anyone help me about
this? Thanks in advance.
Here is my ser.cfg:
# ------------------ module loading ----------------------------------
loadmodule "/usr/local/lib/ser/modules/sl.so"
loadmodule "/usr/local/lib/ser/modules/tm.so"
loadmodule "/usr/local/lib/ser/modules/rr.so"
loadmodule "/usr/local/lib/ser/modules/maxfwd.so"
loadmodule "/usr/local/lib/ser/modules/usrloc.so"
loadmodule "/usr/local/lib/ser/modules/registrar.so"
loadmodule "/usr/local/lib/ser/modules/textops.so"
loadmodule "/usr/local/lib/ser/modules/avp.so"
loadmodule "/usr/local/lib/ser/modules/acc.so"
loadmodule "/usr/local/lib/ser/modules/mysql.so"
loadmodule "/usr/local/lib/ser/modules/dbtext.so"
loadmodule "/usr/local/lib/ser/modules/avpops.so"
#loadmodule "/usr/local/lib/ser/modules/postgres.so"
#loadmodule "/usr/local/lib/ser/modules/flatstore.so"
# Uncomment this if you want digest authentication
# mysql.so must be loaded !
loadmodule "/usr/local/lib/ser/modules/auth.so"
#loadmodule "/usr/local/lib/ser/modules/auth_db.so"
loadmodule "/usr/local/lib/ser/modules/auth_radius.so"
loadmodule "/usr/local/lib/ser/modules/group_radius.so"
loadmodule "/usr/local/lib/ser/modules/uri_radius.so"
# ----------------- setting module-specific parameters ---------------
# -- usrloc params --
#modparam("usrloc", "db_mode",   0)
# Uncomment this if you want to use SQL database
# for persistent storage and comment the previous line
modparam("usrloc", "db_mode", 1)
# -- auth params --
# Uncomment if you are using auth module
#
#modparam("auth_db", "calculate_ha1", yes)
#
# If you set "calculate_ha1" parameter to yes (which true in this
config),
# uncomment also the following parameter)
#
#modparam("auth_db", "password_column", "password")
# -- rr params --
# add value to ;lr param to make some broken UAs happy
modparam("rr", "enable_full_lr", 1)
modparam("tm", "fr_timer", 10 )
modparam("tm", "fr_inv_timer", 20)
modparam("tm", "noisy_ctimer", 1)
modparam("auth_radius|uri_radius|group_radius", "radius_config",
"/usr/local/etc/radiusclient-ng/radiusclient.conf")
modparam("avpops","avp_url","mysql://ser:heslo@localhost/ser")
modparam("avpops","avp_table","usr_preferences")
# -------------------------  request routing logic -------------------
# main routing logic
route{
       # initial sanity checks -- messages with
       # max_forwards==0, or excessively long requests
       if (!mf_process_maxfwd_header("10")) {
               sl_send_reply("483","Too Many Hops");
               break;
       };
       if (msg:len >=  2048 ) {
               sl_send_reply("513", "Message too big");
               break;
       };
   if (!method=="REGISTER") record_route();

   if (loose_route()) {
           t_relay();
           break;
   };

   if (method=="INVITE") {
           lookup("location");
           #if (!lookup("location")) {
        #       sl_send_reply("404", "Not Found");
    #       break;
        #};
   }

if (method=="REGISTER") {
    log("REGISTER\n");
           if (!radius_www_authorize("localhost.localdomain")) {
                    www_challenge("localhost.localdomain", "0");
                    break;
           };
           save("location");
    break;
};

   if (method=="INVITE") {
           if (!radius_proxy_authorize("localhost.localdomain")) {
                   proxy_challenge("localhost.localdomain", "1");
                   break;
           };
   }

# if we do not get a positive reply, continue at failure_route[1]
   t_on_failure("1");
# forward the request to all destinations in destination set now
t_relay();

#if (!t_relay()) {
#   sl_reply_error();
#};

}
failure_route[1] {
   #when caller cancel, terminate the call
if (t_check_status("487")) {
  t_reply("487", "Request Terminated");
  break;
};

if ( ( avp_db_load("$ruri","s:redirect_on_failure")  &&

avp_check("redirect_on_failure","eq/i:1"))) {
      # User need to forward
      log(1, "User wants redirection.\n");
      if ( ( avp_db_load("$ruri","s:redirectnumber") &&
!avp_check("redirectnumber","re/^$"))) {
                       log(1,"first redirect\n");
                       #avp_print();
            attr2uri("redirect number");
                       lookup("location");
            append_branch();
            #t_on_failure("2");
            t_relay();
      }
      else {
            t_reply("408", "TimeOut");
            break;
      };
    }
    else {
      t_reply("404", "Not Found");
      break;
    };
}

Serusers mailing list
serusers@lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
= = = = = = = = = = = = = = = = = = = =

Serusers mailing list
serusers@lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
= = = = = = = = = = = = = = = = = = = =

Serusers mailing list
serusers@lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
= = = = = = = = = = = = = = = = = = = =

Re: Re: Re: Re: [Serusers] a question about "cancel" in forwardingscenario