Subject: [Sipping] RE: Semi Regular Examples draft

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Mon, 4 Apr 2005 11:38:42 -0400

Miki,

If we did cover this specific aspect before, it is probably in the SIP
email archive.  But, to save time looking for that, let's look at this
closely now.  Email below trimmed to specific issue.  I re-read the note
text in beginning of Section 15 of RFC-3261.  It addresses the cleaning
up state of the UAS, but does not discuss all possible message sequences
from the UAC.  What the UAC sends and when is the main issue below.

>-----Original Message-----
>From: Miki HASEBE [mailto:[email-masked]] 
>Sent: Monday, April 04, 2005 7:59 AM
>To: Michael Hammer (mhammer)
>Cc: Kenneth Ho; Cullen Jennings (fluffy); 
>[email-masked]; Dean Willis; 
>[email-masked]; Gonzalo Camarillo
>Subject: Semi Regular Examples draft

[snip]

>> 2) how you can send a CANCEL then ACK a 200 OK, (seems like 
>> a retrans of CANCEL or a BYE would do the trick here)
>
>Considering notes about "hanging up" on chapter 15 of RFC3261, 
>this is considered to be the recommendation specification that 
>the software in phones need to maintain state for a short 
>while in order to clean up properly.
>
>Therefore, I think UAC should send ACK to the 200 OK.
>I think we would like to add the sequence to the draft, that 
>is sending BYE soon after sending ACK.

I still don't like sending the ACK after a CANCEL was sent.  This leads
to the possibility that the CANCEL is lost (or 200 OK's suppressing
further CANCELs but not acted upon) and the ACK is received, leading the
UAS to think the dialog is really complete.  The only advantage you seem
to get is that the UAS can now send a BYE, if the called party hears
nothing and decides to hang up.  The down side is that the UAC won't
send another message since it will get a 200 OK to CANCEL, and the UAS
won't timeout, since it got the ACK.  So, the called party listens to a
mute call until he gets angry and hangs up.  Not getting the ACK would
give the UAS a clue that something is wrong.  Also, once it times out
waiting for the ACK, it could then send a BYE.

But, if the UAC sends a CANCEL, then receives a 200 OK to INVITE, it
knows that the CANCEL was not received in time and will have no effect
on the UAS (see Section 9, p. 53, and 9.2, p. 55).  Therefore, it needs
to immediately send a BYE.  (Note: This is not covered in Section 9.1,
nor in Section 9.2 that only covers the case of CANCEL received before
final response sent).  By transitioning from retransmissions of CANCELs
to sending and retransmission of BYEs the UAC can be more assured of
ending the call.

Last, note that Section 9.2 says that a CANCEL is reponded with a 200 OK
if it matches an existing transaction, which is the case here.  This
seems to be true whether it arrives before a final response is sent or
after, even though no action will be taken on it.

[snip]

>> 4) If you receive a CANCEL, accept that and the fact that an 
>ACK won't be forthcoming to the 200 OK.  There is no sense 
>trying to complete that dialog once both sides know it is 
>going to fail.
>
>As you have pointed out, I also think that receiving the 
>CANCEL may be considered as failure of the dialog establishment.
>According to RFC3261, UAC MAY send a BYE in this situation.
>But surely UAS knows that the dialog establishment has failed, 
>so I would like to consider the recommendation of UAS behavior.

[snip]

My whole goal above is to not send the UAS mixed (contradictory)
signals.  Let me know what you think.

Mike

_______________________________________________
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: Malleswara Rao Ankem <[email-masked]>
Date: Tue, 5 Apr 2005 10:20:54 +0530

Hi Michael,
Some thoughts in line

> waiting for the ACK, it could then send a BYE.

a) Instead of sending a ACK the UAC can send a BYE (presuming that
this would stop any retransmissions from the UAS side which is waiting
for a ACK).
b) Moreover, UAS MUST NOT send a BYE before it receives an ACK for its
200OK. So this is one of the reasons sending an ACK is not harmful as
you say.

regards
Mallesh