[Serusers] a question about "cancel" inforwardingscenario
zhangshuai
zhangshuai at goldentek.biz
Thu Feb 16 02:58:11 CET 2006
Dear Greger V. Teigre,
Take it easy. I really appreciate your spending time to help me figure it out. Of course I have tested the onr.cfg, a non-altered version of the onsip.org script, for many times. As I said before, the following lines:
#when caller cancel, terminate the call
if (t_check_status("487")) {
log("cancel received\n");
t_reply("487", "Request Terminated");
break;
};
in failure_route[1] never took effect in my test, because there is no corresponding log in debug info at all! Those lines only work under this circumstance: when ua1 calls ua2, ua1 cancels the call before timer hits. So, please check the debug info, I sent out last time, again
to confirm my thought.
Thanks a million.
>Your INVITE to seturi() to 200@ times out:
>0(20167) receive_msg: cleaning up
> 1(20168) DEBUG: timer routine:4,tl=0x422b9e50 next=(nil)
> 1(20168) DEBUG: retransmission_handler : request resending (t=0x422b9d38,
>INVITE si ... )
> 1(20168) DEBUG: add_to_tail_of_timer[5]: 0x422b9e50
> 1(20168) DEBUG: retransmission_handler : done
> 1(20168) DEBUG: timer routine:5,tl=0x422b9e50 next=(nil)
> 1(20168) DEBUG: retransmission_handler : request resending (t=0x422b9d38,
>INVITE si ... )
> 1(20168) DEBUG: add_to_tail_of_timer[6]: 0x422b9e50
> 1(20168) DEBUG: retransmission_handler : done
> 1(20168) DEBUG: timer routine:6,tl=0x422b9e50 next=(nil)
> 1(20168) DEBUG: retransmission_handler : request resending (t=0x422b9d38,
>INVITE si ... )
> 1(20168) DEBUG: add_to_tail_of_timer[7]: 0x422b9e50
> 1(20168) DEBUG: retransmission_handler : done
> 1(20168) DEBUG: timer routine:0,tl=0x422b9e60 next=(nil)
> 1(20168) DEBUG: final_response_handler:stop retr. and send CANCEL
>(0x422b9d38)
> 1(20168) ->>>>>>>>> T_code=100, new_code=408
> 1(20168) DEBUG: t_check: msg id=0 global id=0 T start=0x422b9d38
> 1(20168) DEBUG: t_check: T already found!
> 1(20168) DEBUG:t_check_status: checked status is <408>
>
>then it's forwarded in t_on_failure to 300@
>
>The CANCEL is received ok, forwarded ok and the 487 should NOT be met with a
>t_reply, but just break in t_on_failure!!
>
>
>As you have effectively dealt with the 487, SER only has a 408 left to send
>back.
>
>:-( I told you to use the callfwd script from onsip.org!! But you used your
>own f... up test script instead, and stupid me spent time on trying to
>figure it out. Have you tried a non-altered version of the onsip.org script
>at all?!
>
>g-(
>
>----- Original Message -----
>From: "zhangshuai" <zhangshuai at goldentek.biz>
>To: "serusers" <serusers at lists.iptel.org>
>Cc: "wuyuan" <wuyuan at goldentek.biz>
>Sent: Wednesday, February 15, 2006 10:18 AM
>Subject: Re: Re: Re: Re: [Serusers] a question about "cancel"
>inforwardingscenario
>
>
>> 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 at 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 at 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 at localhost.localdomain:5060) call
>> <sip:400 at localhost.localdomain:5060>, SER, at once, rewrites uri and sends
>> invite to ua2(sip:200 at 218.97.252.35:5060). But because ua2 is offline, SER
>> forwards the invite to ua3(sip:300 at 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 at goldentek.biz>
>>>To: "serusers" <serusers at lists.iptel.org>
>>>Cc: "wuyuan" <wuyuan at 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 at goldentek.biz>
>>>>>To: "serusers" <serusers at lists.iptel.org>
>>>>>Cc: "wuyuan" <wuyuan at 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 at 218.97.252.35:5060");
>>>>>> #append_branch("sip:300 at 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 at 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 at goldentek.biz>
>>>>>>>To: "serusers" <serusers at lists.iptel.org>
>>>>>>>Cc: "wuyuan" <wuyuan at 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 at lists.iptel.org
>>>>>>>> http://lists.iptel.org/mailman/listinfo/serusers
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> = = = = = = = = = = = = = = = = = = = =
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Serusers mailing list
>>>>>> serusers at lists.iptel.org
>>>>>> http://lists.iptel.org/mailman/listinfo/serusers
>>>>>>
>>>>>
>>>>>
>>>>
>>>> = = = = = = = = = = = = = = = = = = = =
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Serusers mailing list
>>>> serusers at lists.iptel.org
>>>> http://lists.iptel.org/mailman/listinfo/serusers
>>>>
>>>
>>>
>>
>> = = = = = = = = = = = = = = = = = = = =
>>
>>
>>
>
>
>--------------------------------------------------------------------------------
>
>
>> _______________________________________________
>> Serusers mailing list
>> serusers at lists.iptel.org
>> http://lists.iptel.org/mailman/listinfo/serusers
>>
>
>
= = = = = = = = = = = = = = = = = = = =
More information about the sr-users
mailing list