Subject: RE: SIP: CANCEL method/forking proxy

From: Jerome Privat <[email-masked]>
Date: Thu, 30 Jul 1998 18:14:59 +0100

Jonathan,

Thanks for your answer.
I thought that the CANCEL method could only be addressed to a UAS. If it
can also be addressed to a proxy server, the example of section 14.5
makes sense.
But in this case I have some other questions.
Let's take the example of section 14.5, but this time, we specify that
sip:[email-masked] is a proxy server, and that 2 UAS have registered
with him (UAS1 sip:[email-masked] and UAS2 sip:[email-masked]).
Let's assume that UAS1 has returned a 200 OK.
Then P sends a CANCEL sip:[email-masked] SIP/2.0.
sip:[email-masked] proxies the CANCEL to UAS1 and UAS2.
Now CANCEL should only terminate the transaction with UAS2 but not with
UAS1.
What I still struggle to understand is how UAS1 and UAS2 reacts
differently when they receive the CANCEL? (because in this case the
request has not been addressed to one of them but to the ACM proxy).
One possibility would be that if UAS1 has received an ACK, then it
ignores the CANCEL. But in this case, what would happen if the ACK got
delayed and the CANCEL arrived before it to UAS 1? 
Or is the rule: if a UAS has sent a 200 OK, then it ignores any CANCEL
coming later?
 
Thanks in advance for your answer,

Jerome

Jerome Privat
BT Labs
email: [email-masked]

>----------
>From: 	Jonathan Rosenberg[SMTP:[email-masked]]
>Sent: 	30 July 1998 06:58
>To: 	Jerome Privat
>Cc: 	[email-masked]'; [email-masked]'; [email-masked]'
>Subject: 	Re: SIP: CANCEL method/forking proxy
>
>Jerome Privat wrote:
>> 
>> I'd like to be sure that I understand why BYE cannot be used to cancel
>> pending searches (in other terms: why do we need to use CANCEL?).
>> 
>> In section 4.2.5, it is written:
>> "The BYE request cannot be used to cancel branches of a parallel search,
>> since several branches may, through intermediate proxies, find the same
>> user agent and terminate the call."
>> 
>> First of all, in the example of section 14.5 Forking Proxy, it seems to
>> me that we could send a:
>> BYE sip:[email-masked] SIP/2.0
>> (instead of CANCEL sip:[email-masked] SIP/2.0).
>> 
>> If my understanding is correct, we need a more complex example to
>> justify the use of CANCEL.
>
>No, this example is fine. When P sends the CANCEL, it doesn't know if
>the next hop (sip:[email-masked]) is a proxy (likely it is, in fact),
>or
>a UAS. If it was a proxy, the CANCEL would have been further proxied.
>So, if Watson had also registered sip:[email-masked] with the
>ACM
>proxy, the CANCEL would arrive to Y as well. This is fine, since a
>CANCEL does not terminate a call which has already been answered with a
>200. Now, had P sent a BYE instead, the BYE would have hit Y and
>terminated the call unintentionally.
>
>-Jonathan R.
>-- 
>Jonathan D. Rosenberg                       Lucent Technologies
>Member of Technical Staff                   101 Crawfords Corner Rd.
>High Speed Networks Research                Holmdel, NJ 07733
>FAX: (732) 834-5379                         Rm. 4C-526
>EMAIL: [email-masked]
>URL: http://www.cs.columbia.edu/~jdrosen
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 30 Jul 1998 23:03:53 -0400

> can also be addressed to a proxy server, the example of section 14.5

A CANCEL is processed by all the proxies along the path up to, and
including any UAS which receive the CANCEL. It effectively tears down
the state along the tree set up by a request.

> differently when they receive the CANCEL?

UAS1 will receive the CANCEL, note that it has already responded, won't
change any state established by the INVITE, and send a 200 OK response
to the CANCEL. UAS2 will receive the CANCEL, note that it hasn't
responded, send a 200 OK to the CANCEL, and stop alerting the user. It
won't send any response to the original INVITE. 

 (because in this case the
> Or is the rule: if a UAS has sent a 200 OK, then it ignores any CANCEL

Almost. A UAS receiving a CANCEL won't send a definitive response to the
request if it hasn't already done so. If it has already sent a
definitive response, it ignores the CANCEL (but still responds to it
with a 200 OK). A proxy receiving a CANCEL forwards it on all branches
which haven't yet completed with a definitive response. A proxy will
also generally become stateless after it has received an OK to all of
the CANCEL's it has sent.

-Jonathan R.