[Serusers] a question about "cancel" in forwarding scenario

[zhangshuai]

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 at lists.iptel.org
>http://lists.iptel.org/mailman/listinfo/serusers
>