[Serusers] Race Condition on CANCEL?

[Greger V. Teigre]

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
> >>>>     
> >>>
> >>>   
> >>
>
>