[Serusers] Race Condition on CANCEL?

[Gustavo Passos Tourinho]

Last question, I promise :)

A CANCEL request is hop-by-hop. If the proxy receives a cancel (using 
his server transaction) it should response and issue a CANCEL request 
(using his client transaction) to next hop.
So, if it receives a 200 OK after sent a CANCEL, shouldnt it send a BYE 
they self? Insted of relying it to caller?

As I promise, last question and thank you very much for your help.

Regards,

Greger V. Teigre escreveu:
> Inline.
>
> Gustavo Passos Tourinho wrote:
>> Hello All,
>>
>> I Guess that the Proxy relays 200 OK (INVITE) because it didnt 
>> destroyed the transaction correctely affter it was canceled, right?
>>   
> No, the proxy MUST relay the 200 OK. The caller UA (UAC) should then 
> send an immediate BYE. The callee UA (UAS) wrongly(?) sends a 200 OK 
> after it claims to cancel the call. However, this may happen due to a 
> race condition that is unavoidable (RFC3261)
>> I was looking for a possible configuration bug (ie. relaying 200 OK 
>> statelessly), but there is no such think. All relays are done by 
>> t_relay () function.
>>   
> Your problem is that the caller UA does not immediately send a BYE.
>> Another question. If a cancel request is not replyed with a response 
>> after some time, the UA should try to retransmit it? After reading 
>> the RFC 3 times I just so that the CANCEL cannot be challenge.
>>   
> That's correct, a CANCEL cannot be challenged (as in authentication).
> g-)
>> Well, thank you very much for your help.
>>
>> Regards,
>> Gustavo
>>
>> Greger V. Teigre escreveu:
>> > 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
>> >>>>     >>>
>> >>>   >>
>>
>>   
>