Subject: [Sipping] dialog-usage: should 481 response to CANCEL terminate dialog usage

From: Benny Prijono <[email-masked]>
Date: Fri, 08 Dec 2006 15:00:58 +0000

Hi all,

I have a doubt regarding processing of 481 response to CANCEL with 
regard to terminating dialog as suggested by dialogusage-05.

RFC 3261 Section 9.2 says that it SHOULD respond CANCEL with 481 if 
it cannot find matching INVITE transaction.

While dialogusage-05 says that any 481 response will terminate the 
dialog usage, regardless of the SIP method.

I think dialogusage-05 is wrong in this case, since it will wrongly 
terminate the INVITE session upon receiving 481 response to CANCEL. 
I think it should say that 481 should terminate dialog usage ONLY 
when the method is NOT cancel.

cheers
-benny

-- 
Benny Prijono
http://www.pjsip.org

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

---

From: "Nayak, Subhransu S" <[email-masked]>
Date: Sun, 10 Dec 2006 19:26:28 -0500

The primary purpose of the CANCEL request is to terminate a pending transaction. The CANCEL request is never sent to terminate a SIP dialog or, a session. The UAC upon receiving the error response to a CANCEL request should destroy the transaction ( e.g. INVITE ) for which it issued the CANCEL request. The same error ( final ) response completes the CANCEL transaction. It is the UAC who should decide whether to release the dialog when the transaction ( INVITE ) is destroyed.

Now take this specific example:

UAC                       UAS 
 ------------------------> INVITE
 <----------------------- 100 Trying 
 <----------------------- 180 Ringing
 UAS reboots right after sending 180 and comes backup .
 -----------------------> CANCEL 
 <---------------------- 481 CANCEL

INVITE transaction should be destroyed on the UAC side. Now should the UAC delete the original dialog ? 

Thanks,
- Subhransu
 
-----Original Message-----
From: Benny Prijono [mailto:[email-masked]]
Sent: Friday, December 08, 2006 10:01 AM
To: [email-masked]
Subject: [Sipping] dialog-usage: should 481 response to CANCEL
terminatedialog usage

Hi all,

cheers
-benny

-- 
Benny Prijono
http://www.pjsip.org

---

From: Benny Prijono <[email-masked]>
Date: Mon, 11 Dec 2006 11:10:45 +0000

> The primary purpose of the CANCEL request is to terminate a pending transaction. The CANCEL request is never sent to terminate a SIP dialog or, a session. The UAC upon receiving the error response…

I understand this and I wasn't asking about the purpose of CANCEL. 
What I was asking was the ambiguity of the 481 response to CANCEL, 
because IMO it can mean two different things:

1) UAS has sent 200 response to INVITE and it has destroyed the 
INVITE transaction (as governed by RFC 3261), and the CANCEL request 
has crossed the wire with the 200/INVITE response. In this case, the 
UAS will send 481 response to CANCEL (as said in RFC 3261 Section 9.2).

2) UAS has lost the session (e.g. because it has rebooted) thus it 
sends 481 response to CANCEL.

The dialogusage-05 draft suggests that upon receiving *any* 481 
response, the UAC will terminate the session unconditionally. I 
agree with this, but unfortunately it contradicts with RFC 3261 rule 
in the first case above. So which one is correct? We have two solutions:

a) if dialogusage-05 is correct, then RFC 3261 needs to be revised 
so that it disallows sending 481 response to CANCEL for the first 
case above (and instead send 200/OK to CANCEL).

b) RFC 3261 is still correct, and dialogusage-05 needs to be revised 
so that it doesn't terminate dialog unconditionally upon receiving 
481 response to CANCEL. But then we're still left with the ambiguity 
of the meaning of 481 response to CANCEL.

I personally prefer solution a) since it solves the ambiguity, but 
unfortunately this violates the current rule in RFC 3261.

-benny

---

From: [email-masked]
Date: Mon, 11 Dec 2006 10:49:14 -0500

From: Benny Prijono <[email-masked]>

This is a problem with the wording of RFC 3261.  It should never say a
transaction is "destroyed", it should only say that it is
"completed".  Completed transactions can be garbage-collected once
they are far enough in the past that no messages regarding them can be
in the network any more.

So if you receive a CANCEL for an INVITE that you've already sent a
200 to, you should never "not find the transaction", unless the CANCEL
was delayed in some extraordinary way.

But that probably isn't important...

When the UAC sends a CANCEL for an INVITE, there are a bunch of known
race conditions that can result in the INVITE establishing a dialog
(at the UAS) anyway.  The UAC must ensure that any such dialog is
destroyed.  But it can always detect that such a dialog was created by
a success response to the INVITE, and send a BYE to destroy it.

As a general rule, the response to CANCEL does not tell what happened
in regard to the INVITE.  The result of the INVITE is shown by the
response to the INVITE.

Dale

---

From: "Nayak, Subhransu S" <[email-masked]>
Date: Mon, 11 Dec 2006 11:40:21 -0500

The ambiguity is because the 481 is returned by the UAS when an incoming request doesn't match a dialog or, a transaction. If you read the reason phrase for 481 : "Call Leg/Transaction Does Not Exist" . So your option a) which suggests to change the RFC 3261 not to send 481 for CANCEL may not be the right thing.

Now for the specific cases you mentioned, the dialog can still be released to be compliant with dialogusage-05. 

[Subhransu] When UAC sends a CANCEL request, it really wants to terminate the transaction. In this case , UAC can destroy the transaction and release the dialog upon receiving 481 to CANCEL and just ignores the 200 OK/INVITE received from the UAS. UAS will release its dialog resources upon 200OK/ACK timeout. 

2) UAS has lost the session (e.g. because it has rebooted) thus it 
sends 481 response to CANCEL.
[Subhransu]UAC can destroy the dialog / transaction. 

-----Original Message-----
From: Benny Prijono [mailto:[email-masked]]
Sent: Monday, December 11, 2006 6:11 AM
To: Nayak, Subhransu S; [email-masked]
Subject: Re: [Sipping] dialog-usage: should 481 response to CANCEL
terminate dialog usage

-benny

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Mon, 11 Dec 2006 22:47:19 +0100

Benny,

Your representation of dialogusage-05 below is incorrect. It does not say 
that 481 unconditionally terminates the dialog, it says that it destroys the 
*usage*. However, it does go on stating that CANCEL is part of the INVITE 
usage, which means that it will destroy the dialog if it is the last usage.

481 for CANCEL always means: transaction does not exist. It should not 
terminate the INVITE usage, to prevent case (1) below. So the dialogusage 
draft should be updated in this respect

Your suggestion b) would lead the UAC to believe that the CANCEL was 
succesful and a 487 will follow for the INVITE. While it should not depend 
on this due to backwards compatibility with RFC2543, it introduces ambiguity 
rather than removing it

Regards,
Jeroen

Benny Prijono wrote:
>> The primary purpose of the CANCEL request is to terminate a pending
>> transaction. The CANCEL request is never sent to terminate a SIP
>> dialog or, a session. The UAC upon receiving the error response to a
>> CANCEL request should destroy the transaction ( e.g. INVITE ) for
>> which it issued the CANCEL request. The same error ( final )
>> response completes the CANCEL transaction. It is the UAC who should
>> decide whether to release the dialog when the transaction ( INVITE )
>> is destroyed.
>