Subject: RE: [Sip] Bis-05 question: CANCEL

From: Robert Sparks <[email-masked]>
Date: Wed, 31 Oct 2001 09:25:41 -0500

inline

> -----Original Message-----
> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Tuesday, October 30, 2001 11:40 PM
> To: Shan Lu
> Cc: 'Gonzalo Camarillo'; 'IETF SIP Mailing List'; 'Jonathan Rosenberg'
> Subject: Re: [Sip] Bis-05 question: CANCEL
> 
> 
> 
> Hi,
> 
> I understand the arguments for buffering. BUT, by waiting for 
> the first
> 1xx we still don't solve the CANCEL/200 race condition.

Yes, we've solved this one. More after the answer to the
scenario below.

> 
> Also, consider the following case:
> 
> 
>          |------- UAS 1
> UAC --- P1
>          |------- UAS 2
> 
> 
> Now, the UAC sends an INVITE, which gets forked by P1. P1 
> also sends 100
> back to UAC. Then, the UAC decides to terminate the setup, so it sends
> CANCEL.
> 
> Now, P1 has also received 1xx from UAS 1, so it can send the CANCEL
> there.
> 
> HOWEVER, P1 has NOT received a 1xx from UAS 2, and it won't even do
> that. Instead, the UAS 2 returns 200 OK immedeately. So, what 
> does P1 do
> now? Creates a BYE transaction to UAS 2 - and when it receives a
> response to that it sends 200 for the CANCEL to the UAC??? 
> This sounds a
> little like B2BUA behaviour to me...

Its more than a little like B2BUA - P1 cannot generate
a BYE on its own. Once you take that step, you are no
longer talking about proxies.

> 
> 
> AND, the following (easier case) could also have happened in the
> scenario above: Both UAS 1 and UAS 2 DO send a 1xx, but when 
> P1 sends a
> CANCEL both UAS 1 and UAS 2 have sent 200 - so what does P1 do now? 
> 
> 1. Create a BYE to both UAS 1 and UAS 2? 
> 
> 2. Forward the 200 response for the INVITE to the UAC, and 
> sends 487 for
> the CANCEL to the UAC?

Neither.

The scenario you set up will play out as follows:

UAC            P1             UAS1            UAS2
 |INVITE        |              |               |
 |------------->| INVITE       |               |
 | 100          |------------->|               |
 |<-------------|              |  INVITE       |
 |              |----------------------------->|
 |              | 100          |               |
 | CANCEL       |<-------------|               |
 |------------->|              |               |
 | 200 (CANCEL) |              |               |
 |<-------------| CANCEL       |               |
 |              |------------->|               |
 |              | 200 (CANCEL) |               |
 |              |<-------------|               |
 |              | 487 (INVITE) |               |
 |              |<-------------|               |
 |              | ACK          |               |
 |              |------------->|               |
 |              |              |  200 (INVITE) |
 | 200 (INVITE) |<-----------------------------|
 |<-------------|              |               |
 | ACK          |              |               |
 |------------->| ACK          |               |
 |              |----------------------------->|
 |              |              |               |
 |              |              |               |
 |              |              |               |

CANCEL is hop-hop. All that a 200 means to a CANCEL
is that it got to the next hop, not that something
actually got cancelled. A CANCEL will never recieve
a 487 response (as you suggest in step 2 above. Those
only come in responses to requests that got cancelled.

Now, for the CANCEL 200 race condition - that's 
effectively what you set up with UAS2 above
(leave UAS1 out of the diagram). At the end
of the scenario, UAC knows that
1) The next hop got its CANCEL request, and
2) It didn't get to the far side in time to
   CANCEL the request (since it got a 200 to
   the INVITE).

Everyone is in sync - no crossing problem.

> 
> 
> >>As I stated previously, if the CANCEL arrives to the server 
> before the
> >>INVITE, the UAC will not have any way to cancel the request. Then it
> >>would have to wait until the INVITE is answered in order to send a
> >>BYE... and this can really take very long.
> >Why can't BYE be sent for an early dialog to terminate the dialog?
>  
> This has been discussed before, and the UAC CAN use BYE to terminate a
> dialog, assuming it has received a 1xx with a To header tag.
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
> _______________________________________________
> Sip mailing list  http://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  http://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: Christer Holmberg <[email-masked]>
Date: Wed, 31 Oct 2001 19:45:44 +0200

Hi,

>>also sends 100 back to UAC. Then, the UAC decides to terminate the setup, so it sends
>>CANCEL.
>>
>>does P1 do now? Creates a BYE transaction to UAS 2 - and when it receives a
>>This sounds a little like B2BUA behaviour to me...
> 

Good! :)

>>sends 487 for the CANCEL to the UAC?
> 
>Neither.
> 

I am sorry. I meant that 481 (not 487) would be sent for the CANCEL.

Regards,

Christer Holmberg
Ericsson Finland