Subject: [Sipping] Is ACK needed for 2xx (INVITE) after sending

From: Jun KOSHIKO <[email-masked]>
Date: Fri, 20 Oct 2006 15:47:07 +0900

Folks,

Is ACK for 2xx (INVITE) required in the following sequence?

    Alice                             Bob
      |                                |
      |         ini-INVITE             |
      |------------------------------->|
      |            180                 |
      |<-------------------------------|
      |                                |
      |    BYE           200(INVITE)   |
      |-------------     --------------|
      |              \ /               |
      |               X                |
      |              / \               |
      |<------------     ------------->|
      |    ACK?             200(BYE)   |
      |-------------     --------------|
      |              \ /               |
      |               X                |
      |              / \               |
      |<------------     ------------->|
      |                                |
      |                                |

I hope I would like to discuss
how the UA (Alice) should behave in this case.

One way to understand this could be
that TU does not send ACK in the Terminated state 
because the ACK for 2xx is sent by TU,
not the INVITE client transaction.

Another might be that TU sends ACK even in the Terminated state,
because it has to complete the INVITE transaction.

According to RFC3261, either way seems to be possible.

But, the latter option could be a bit awkward,
since the TU has to control the ACK
which does not relate to the transaction or the dialog.

In writing of the race condition draft,
I am wondering what the best understanding of this case is.

I appreciate comments and advice.

Thank you.

Jun KOSHIKO

---------------------------------------------------------
Jun KOSHIKO
Next Generation Strategy
Research and Development Center
NTT-east Corporation

Telephone  +81 3 5359 5104
Facsimile  +81 3 5359 1236
E-mail: [email-masked]
19-2 Nishi-shinjuku 3-chome Shinjuku-ku Tokyo 163-8019 Japan
---------------------------------------------------------

_______________________________________________
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: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Fri, 20 Oct 2006 08:50:25 +0200

Hi,

Yes, ACK is needed. The INVITE transaction shall complete even if you
send a BYE, and sending ACK is part of that completion.

Regards,

Christer

> -----Original Message-----
> From: Jun KOSHIKO [mailto:[email-masked]] 
> Sent: 20. lokakuuta 2006 9:47
> To: sipping
> Cc: Paul Kyzivat; Miki Hasebe; Akihiro SHIMIZU
> Subject: [Sipping] Is ACK needed for 2xx (INVITE) after sending
> 
> Folks,
> 
> that TU does not send ACK in the Terminated state because the 
> ACK for 2xx is sent by TU, not the INVITE client transaction.
> 
> Another might be that TU sends ACK even in the Terminated 
> state, because it has to complete the INVITE transaction.
> 
> But, the latter option could be a bit awkward, since the TU 
> has to control the ACK which does not relate to the 
> transaction or the dialog.
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 20 Oct 2006 09:32:08 -0400

Christer,

I think the point is that when a 200 is returned to an INVITE, that ends 
the *transaction*. In that case the ACK is a separate, though special, 
transaction. That is why there is a question about this case.

I'm not sure at this point what answer I prefer, so I'm waiting to see 
some compelling arguments one way or the other.

	Paul

---

From: Robert Sparks <[email-masked]>
Date: Sat, 21 Oct 2006 12:09:21 -0400

This ACK is still required.
The TU will continue to retransmit the 200-INVITE until it sees the  
ack or it runs its timers to exhaustion. The BYE will have no effect  
on that behavior.

RjS

---

From: Jun KOSHIKO <[email-masked]>
Date: Thu, 26 Oct 2006 15:38:47 +0900

Thank you for your comments. Sorry for the late reply.

I understood that your point was that
  "ACK to a final response to INVITE is a MUST."

* If CANCEL request is successful, ACK to the final response is
  handled by INVITE transaction.
* If CANCEL request fails, Early-Dialogue exists in UAC, 
  and it will transition to Confirmed-Dialogue, so ACK shall be
  transmitted.

I understand that you are concerning the case in which
user terminal sends BYE on Early-Dialogue in spite of RFC3261's 
recommendation.

In case that 200OK to ini-INVITE is returned although UAC has sent BYE,
it would not send ACK because UAC has already been in Mortal state,
wouldn't it? And what you are concerning is the point that it becomes
inconsistent with the condition of "ACK to a final response to INVITE is
a MUST", isn't it?

We are wondering whether race-example draft should cover the behavior
in such a case that UAC sends BYE before it receives 200OK to the
ini-INVITE. 
(because we think that BYE in that case is regulated under RFC3261,
 so that the problem in concern will not happen.)

However, we might have to consider the following case.
That is, if re-INVITE in Confirmed-Dialogue is used,
the same kind of sequence may happen.

In case UAC sends re-INVITE and BYE nearly at the same time,
UAS will reply 200OK(INVITE) immediately.
(Certainly, 200(BYE) will immediately follow.)

In this case, since Dialogue in UAS becomes mortal,
ACK to 200OK(INVITE) will not be sent by UAC.
But, since UAS receives BYE, and the dilog transiton to mortal,
retransmission of 200OK from UAS will be stopped.
Therefore, not replying an ACK doesn't occur a problem, does it?

Now reconsidering the case of ini-INVITE,
200OK's retransmission will not happen for the same reason,
if BYE is effective on UAS.

Rather, proactive ACK to 200OK may cause the situation
in which UAS will transition to Confirmed-Dialogue and
a conflict of dialog state between UAC and UAS
may happen.
Therefore, I think that you should not adhere to the principle
that 
  "ACK is a MUST to complete the INVITE transaction"
  "ACK to a final response to INVITE is a MUST."
in this case.

What do you think about that?
I hope I would like to have your opinions and thoughts.

Thank you.

Jun KOSHIKO

---

From: Robert Sparks <[email-masked]>
Date: Thu, 26 Oct 2006 09:32:40 -0500

> inconsistent with the condition of "ACK to a final response to  
Correct. The presence of the BYE will not change how the ACK is sent.
>  so that the problem in concern will not happen.)
A UAC can send a BYE on an early-dialog. Once it has a to-tag from
a provisional response between 101 and 199, it can send a BYE with
that to tag to terminate that early dialog. The race to capture is  
having
that BYE and the 200 to the INVITE cross on the wire.

To make sure we're talking about the same thing, the text in 3261 I  
think
you're referring to is on page 89:

    The caller's UA MAY send a BYE for either
    confirmed or early dialogs, and the callee's UA MAY send a BYE on
    confirmed dialogs, but MUST NOT send a BYE on early dialogs.

What you are describing above is the caller UA (caller is the endpoint
sending the INVITE), and 3261 does allow a BYE to an early dialog
in that case. What it doesn't allow is having the callee (the endpoint
receiving the INVITE) sending a BYE before it sends a final response
to the INVITE.

> retransmission of 200OK from UAS will be stopped.
No, it wouldn't stop retransmitting. Be careful with the new states
you are adding. They are states used to better describe the behavior
specified in the current specs, correct? There is NO condition under
which a UAC doesn't try to send the ACK.
> a conflict of dialog state between UAC and UAS

Not if both sides have properly noted the BYE. This race condition draft
is there to help show the implementation community how to avoid that.
I do not see a case here where the conflict of dialog state is  
unavoidable.
(There is such a case when the network stops working, but then there
is no call or recovery path anyhow).

The position you are wanting to take is a change to the protocol, not
an explanation or a clarification off the existing specifications.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Oct 2006 11:06:42 -0400

I'd like to step back from exactly what the documents currently say, to 
understand from an implementation perspective how this can/should work.

It seems to me that there is a significant distribution of 
responsibility among elements with differing lifetimes:

- the individual transactions
- the dialog usage
- the dialog

Of those, the dialog is the least interesting. I don't think it enters 
this discussion at all. It just goes away when all the usages are gone, 
and it doesn't have any responsibilities of its own.

Transactions have a lifetime dictated by timers and events, and they 
control certain retransmissions. Some transactions (the ones we are 
concerned with here) are associated with a dialog usage. A dialog usage 
is usually coincident with the sending of some request that also 
initiates a transaction. (A dialog usage can also come into existence as 
the result of receiving a response with a new to-tag to an existing 
transaction.)

The end of a dialog usage is somewhat trickier. The race conditions 
draft is trying to talk about this without making the distinction 
between dialog usage and dialog. (That may be ok for this discussion.)

A question that isn't clear to me is: must a dialog usage remain in some 
state as long as any of the transactions associated with it remain? Or 
can the dialog usage go away, leaving transactions that had previously 
been associated with it to work themselves out?

I think the problem that Jun is having is that when there has been a 200 
response to an INVITE, the invite *transaction* is done. The requirement 
for the UAS to retransmit the 200 if the ACK isn't received, and for the 
UAC to retransmit the ACK if a retransmitted 200 is received, isn't with 
the transaction - it is the UAC/UAS Core. So where is the state to 
support doing that? It must reside within the invite usage. So the 
lifetime of the invite usage must be tied up with these rules for which 
messages must be transmitted in and around the end of life of the invite 
usage. If BYE ends the dialog usage, then it won't be possible for an 
ACK to subsequently be sent.

	Paul

Robert Sparks wrote:
> that to tag to terminate that early dialog. The race to capture is having
> To make sure we're talking about the same thing, the text in 3261 I think
> I do not see a case here where the conflict of dialog state is unavoidable.

---

From: Robert Sparks <[email-masked]>
Date: Thu, 26 Oct 2006 10:27:53 -0500

inline
On Oct 26, 2006, at 10:06 AM, Paul Kyzivat wrote:

> I'd like to step back from exactly what the documents currently  
> say, to understand from an implementation perspective how this can/ 
> should work.
>
> Of those, the dialog is the least interesting. I don't think it  
> enters this discussion at all. It just goes away when all the  
> usages are gone, and it doesn't have any responsibilities of its own.
>
> Transactions have a lifetime dictated by timers and events, and  
> they control certain retransmissions. Some transactions (the ones  
> we are concerned with here) are associated with a dialog usage. A  
> dialog usage is usually coincident with the sending of some request  
> that also initiates a transaction. (A dialog usage can also come  
> into existence as the result of receiving a response with a new to- 
> tag to an existing transaction.)
>
> A question that isn't clear to me is: must a dialog usage remain in  
> some state as long as any of the transactions associated with it  
> remain? Or can the dialog usage go away, leaving transactions that  
> had previously been associated with it to work themselves out?
>
> I think the problem that Jun is having is that when there has been  
> a 200 response to an INVITE, the invite *transaction* is done. The  
> requirement for the UAS to retransmit the 200 if the ACK isn't  
> received, and for the UAC to retransmit the ACK if a retransmitted  
> 200 is received, isn't with the transaction - it is the UAC/UAS  
> Core. So where is the state to support doing that? It must reside  
> within the invite usage. So the lifetime of the invite usage must  
> be tied up with these rules for which messages must be transmitted  
> in and around the end of life of the invite usage. If BYE ends the  
> dialog usage, then it won't be possible for an ACK to subsequently  
> be sent.
Ok - so the concept to focus on is what is the moment of the  
destruction of the usage state. The suggestion that the usage  
continue as long as there is transaction state from a transaction  
that started within the usage is probably the correct way to model it  
- it's certainly sufficient.