[Serusers] a question about "cancel" in forwardingscenario
zhangshuai
zhangshuai at goldentek.biz
Wed Feb 15 10:18:49 CET 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 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
>>
>
>
= = = = = = = = = = = = = = = = = = = =
-------------- next part --------------
A non-text attachment was scrubbed...
Name: debug
Type: application/octet-stream
Size: 14175 bytes
Desc: not available
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20060215/ba8bd459/attachment.obj>
More information about the sr-users
mailing list