[Serusers] Race Condition on CANCEL?

[Greger V. Teigre]

As I said, I would start finding out why the UA sends 200 OK after it 
has sent canceling.
There is no sign of any bugs in CANCEL transaction. As I explained, the 
CVS trunk changes are related to how CANCELs are handled. Your CANCEL 
reaches the UA ok.
g-)

Gustavo Passos Tourinho wrote:
> Hi,
>
> So, is there a BUG in CANCEL transaction?
>
> How can I confirm this information?
>
> Thanks
>
> Atle Samuelsen escreveu:
>> Hi,
>>
>> I might be wrong, but I think Andrei added some code in CVS head a few
>> days back that addresses this issue. 
>>
>> -A
>>
>> * Gustavo Passos Tourinho <gustavo.passos.tourinho at gmail.com> [070511 13:57]:
>>   
>>> Thanks for your reply.
>>>
>>> Yes, I have this problem right now. The problem is that when the proxy receives 200 OK (for INVITE, confirmed by CSeq), insted of 200 Cancelling,  it issue 
>>> an RADIUS request for billing.
>>>
>>> So, I will have an "Start-Invite" (200 OK), but will have not a "Stop-Bye" because the BYE message will not be generated.
>>>
>>> How can I ensure that the proxy will not forward 200 OK for INVITE? I mean, if it is a transaction statefull and the transaction doesnt existis, why it is 
>>> stills forwarding the message? Is there any thing that I can do to prevent this kind of situation to occour?
>>>
>>> Thanks again.
>>>
>>> Regards,
>>> Gustavo
>>>
>>> Greger V. Teigre escreveu:
>>>     
>>>> No, the UAS (U2) shall answer with 200 OK to confirm that the call has been canceled and yes, it should be sent to U1.
>>>> Do you have an actual experienced problem or was the 200 OK the problem?
>>>> g-)
>>>>
>>>> Gustavo Passos Tourinho wrote:
>>>>       
>>>>> Hello,
>>>>>
>>>>> Im having some problems with cancelled calls. This is the scenario:
>>>>>
>>>>> U1                                     Proxy                                       U2
>>>>>
>>>>> INVITE   -->>>                                             <<--- 100 Trying
>>>>>                                         INVITE  -->>>
>>>>>                                                                            <<--- 100 Trying
>>>>>                               <<--- 100 Trying  CANCEL  ->>>                                              <<-- 200 Cancelling
>>>>>                                          CANCEL ->>               <<-- 180 Ringing
>>>>>                                <<-- 487 Cancelled
>>>>>                                <<-- 180 Ringing
>>>>>                                                                                                                                         <<-- 200 OK
>>>>>                                    (Wrong??)
>>>>>                                 <<-- 200 OK
>>>>>
>>>>>
>>>>> My problem is that after some time waiting for "ringing", the user cancel the call. Even that proxy responses "487" it still forward the late 200 OK.
>>>>>
>>>>> Should it forward? I guess not because the transaction was destroyed, right?
>>>>>
>>>>> Can it be a configuration problem on my ser.cfg ou it can be in t_relay implementation?
>>>>>
>>>>> Thanks in advanced.
>>>>> Regards,
>>>>>
>>>>> Gustavo                       _______________________________________________
>>>>> 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20070512/20fa0965/attachment.htm>