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:
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