Subject: RE: [Sipping] RE: Semi Regular Examples draft

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Tue, 5 Apr 2005 13:06:39 -0400

Charles,

OK, I give up.  I found the requirement in 13.2.2.4 that requires an ACK
for every 200 OK INVITE sent.  So, effectively the sole purpose of the
ACK is simply 200 OK suppression.

However, I would note that the behavior of a UAC sending a CANCEL, then
receiving a 200 OK triggering immediately sending a BYE should be
documented.  I can't find it in RFC-3261.  The closest it comes is in
Section 13.2.2.4 last paragraph.  But, based on other parts of 3261, the
UAC could have concluded that it already did release the dialog and
already be gone.

So the above will be documented in the exception examples draft?

Mike

>-----Original Message-----
>From: Charles Eckel (eckelcu) 
>Sent: Tuesday, April 05, 2005 12:07 PM
>To: Michael Hammer (mhammer)
>Cc: Malleswara Rao Ankem; [email-masked]; 
>[email-masked]; Miki HASEBE
>Subject: Re: [Sipping] RE: Semi Regular Examples draft
>
>I agree with the statement about having to send the BYE, 
>except that you need the send the ACK first. More inline.
>
>Michael Hammer (mhammer) wrote:
>
>> But, this leaves us in a state where:
>> 
>> UAC:
>> Sent CANCEL, receives 200 OK INVITE, sent ACK, receives 200 
>OK CANCEL, 
>> goes away.
>
>It can't. It needs to send a BYE after sending the ACK, and 
>needs retrans the ACK if it gets another 200 OK for the 
>INVITE, and needs to retrans the BYE until it gets a 200 for 
>the BYE (or times out trying). 
>It all goes back to the underlying principle of every 
>transaction completing independently.
>
>> 
>> UAS:
>> Sent 200 OK INVITE, receives CANCEL ***but doesn't act on 
>it***, sends
>> 200 OK CANCEL, receives ACK, remains in active dialog.
>
>Right, that is why the UAC needs to send the BYE.
>
>Cheers,
>Charles
>
>> That can't be right.  If it were, it would mean that the ACK 
>has no real
>> meaning and could be omitted.
>> 
>> The only part above that is not required by RFC-3261 is the 
>sending of
>> ACK.  It is not so clear, but should be that getting a 200 OK INVITE
>> after sending a CANCEL should immediately require a BYE to be sent.
>> Also, in 14.2, it says a UAS that does not get an ACK (e.g. timesout)
>> SHOULD send a BYE to terminate dialog.
>> 
>> Mike
>>  
>> 
>>  >-----Original Message-----
>>  >From: Malleswara Rao Ankem [mailto:[email-masked]]
>>  >Sent: Tuesday, April 05, 2005 12:51 AM
>>  >To: Michael Hammer (mhammer)
>>  >Cc: Miki HASEBE; [email-masked]; [email-masked]
>>  >Subject: Re: [Sipping] RE: Semi Regular Examples draft
>>  >
>>  >Hi Michael,
>>  >Some thoughts in line
>>  >
>>  >On Apr 4, 2005 9:08 PM, Michael Hammer (mhammer)
>>  ><[email-masked]> wrote:
>>  >> 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.
>>  >
>>  >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
>>  >>
>>  >> 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
>>  >>
>>  >
>> 
>> _______________________________________________
>> 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
>> 
>

_______________________________________________
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: Charles Eckel <[email-masked]>
Date: Tue, 05 Apr 2005 11:00:28 -0700

Seems like a fine idea to me.

Cheers,
Charles

---

From: Miki HASEBE <[email-masked]>
Date: Wed, 06 Apr 2005 16:53:30 +0900

Folks,

Thank you for many comments.

I will add this description to the draft of exceptional procedure.
Any additional examples or comments will be welcomed.

Regards,
Miki Hasebe