Re: Re: Re: Re: Re: [Serusers] a question about "cancel" inforwardingscenario

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(a)goldentek.biz> >To: "serusers" <serusers(a)lists.iptel.org> >Cc: "wuyuan" <wuyuan(a)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(a)goldentek.biz> >>>To: "serusers" <serusers(a)lists.iptel.org> >>>Cc: "wuyuan" <wuyuan(a)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(a)lists.iptel.org >>>> http://lists.iptel.org/mailman/listinfo/serusers >>>> >>> >>> >> >> = = = = = = = = = = = = = = = = = = = = >> >> >> >> >> >> _______________________________________________ >> Serusers mailing list >> serusers(a)lists.iptel.org >> http://lists.iptel.org/mailman/listinfo/serusers >> > > = = = = = = = = = = = = = = = = = = = = _______________________________________________ Serusers mailing list serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers