Re: Re: Re: Re: [Serusers] a question about "cancel" in forwarding scenario - sr-users

14 Feb 2006

Dear Antonio Rabena,

You mean parallel forking. Not forwarding, right? I receive the correct signal,
"486", in parallel forking scenario. Only after the invite was forwarded, I
experience the "cancel" problem, which is bothering so many days. Have you
tested serial forking or forwarding? 

...
 Hi,

Im also experiencing the same problem.  The only diff. is  ua2 and 
ua3 are using same sip account so when ua1 sends invite to that sip 
account, both ua2 and ua3 ring, and when ua1 cancels the call,  it 
receives 408 Request Timeout".

At 04:41 PM 2/14/2006, you wrote:
 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-)
 > 

_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers