[Serusers] Race Condition on CANCEL?

Greger V. Teigre greger at teigre.com
Fri May 11 15:04:48 CEST 2007


Yes, it's related (i.e. early CANCELs), but his code modifies how 
t_relay handles early CANCEL (to simplify routing logic by for example 
sending the CANCEL to the out r-uri of the matching INVITE, dropping it, 
or just relaying it).
g-)

Atle Samuelsen wrote:
> 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/20070511/702357fb/attachment.htm>


More information about the sr-users mailing list