Subject: RE: [Sip] CANCEL in Bis-09

From: Robert Sparks <[email-masked]>
Date: 06 Jun 2002 13:08:04 -0500

On Thu, 2002-06-06 at 12:29, George Foti (LMC) wrote:

> Given that, can you please explain how this legitimate case be handled
> 
> UAa----------P1-------------P2---------------UAb
> 
> P1, P2 are stateful.
> A session is already established between UAa & UAb
> 
> UAa sends a BYE followed by a CANCEL.
> P1 proxies the BYE to P2 then answers UAa with 200 OK for the CANCEL, then
> proxies the CANCEL to P2. UAa & P1 now beleive that the BYE has been
> succesfully cancelled.

No, at this point UAa believes the CANCEL was received and processed.
UAa will have no knowledge of whether the BYE was successfully canceled
until it receives the final response to the BYE.

CANCELs are not (statefully) proxied. They are hop-by-hop. P1 accepted
the cancel from UAa and is now trying to cancel its request to P2. P1
does _NOT_ believe the BYE has been successfully cancelled. 

> P2 receives the CANCEL before BYE, returns a 481, then receives the BYE.
> P2 forwards the BYE to UAb.

This is exactly the race condition that motivated the SHOULD NOT send
CANCEL for non-INVITE in bis-09. This is bad because the BYE now 
_cannot_ be successfully canceled (there is no way to retry the cancel),
but it does _not_ result in an inconsistent view of dialog state.

> UAb returns 200 OK for the BYE which gets proxied all the way to UAa.

And thus UAa knows the BYE was not successfully canceled. There is no
inconsistent view of state in this scenario.

> 
> We  have now an inconsistent view of the session due to a race condition.
> UAa, P1 beleive that the session is still ongoing. P2 & UAb believe that the
> session is still gone
> 
> Rgds
> /gf
> > -----Original Message-----
> > From: Robert Sparks [mailto:[email-masked]]
> > Sent: Thursday, June 06, 2002 10:38 AM
> > To: George Foti (LMC)
> > Cc: [email-masked]
> > Subject: Re: [Sip] CANCEL in Bis-09
> > 
> > 
> > This is not an inconsistency.
> > 
> > The strength of the requirement to not send provisional
> > responses to non-INVITE requests is SHOULD NOT.
> > 
> > See line 1348 of the pdf.
> > 
> > RjS
> > 
> > On Thu, 2002-06-06 at 06:09, George Foti (LMC) wrote:
> > > Hi,
> > > Section 9.1 lines 1448 states that a CANCEL  request SHOULD 
> > NOT be sent to
> > > cancel a request other than INVITE (due to race conditions).
> > > 
> > > Following that lines 1464-1465 state that if no provisional 
> > response has
> > > been received, the CANCEL request MUST NOT be sent.
> > > 
> > > Since provisional responses are only used with INVITES, it 
> > looks like the
> > > strength on line 1448 needs to be changed to MUST NOT fo 
> > consistency.
> > > 
> > > Rgds/
> > > George Foti
> > > Ericsson Research Canada
> > > 
> > > _______________________________________________
> > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > This list is for NEW development of the core SIP Protocol
> > > Use [email-masked] for questions on current sip
> > > Use [email-masked] for new developments on the application of sip
> > 
> > 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "George Foti (LMC)" <[email-masked]>
Date: Thu, 6 Jun 2002 13:29:27 -0400

P1, P2 are stateful.

Rgds
/gf