Subject: [Sip] Comment on draft-ietf-sip-rfc2543bis-09

From: "Jeff Keyser" <[email-masked]>
Date: Mon, 27 May 2002 19:13:33 -0400

I apologize if this is not the correct place for this comment.  If this is
not, please let me know where I should direct this.

I am working with draft-ietf-sip-rfc2543bis-09 to write a SIP client, and
the INVITE transactions of section 17 don't make sense to me as written.
For both client and server INVITE transactions in the "Proceeding" state
(and "Calling" state for client transactions), if a new response status code
is 300-699, the transaction changes to the "Completed" state; and, if a new
response status code is 2xx, the transaction changes to the "Terminated"
state.  The state diagrams show this same logic.

I assume that this is supposed to be the other way around, since the
"Completed" state is used the handle the ACK request of a connected call.

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

---

From: "Prabhas Sinha" <[email-masked]>
Date: Mon, 27 May 2002 21:01:09 -0400

Thanks for bringing this up Jeff. I too had asked this question some time
back to Vijay Gurbani.
Even I am waiting to get some clarifications on it if I didnt understand the
model.

Prabhas

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 28 May 2002 01:44:15 -0400

inline.

> "Completed" state is used the handle the ACK request of a connected

No, it is correct as written. 

The reason is that this state machine represents the *transaction*
state. The transaction state machine is responsible for request/response
correlation, retransmissions, and so on. It is NOT responsible for the
management of the call state. When a 2xx is received, the transaction is
complete. There is an ACK, but this ACK constitutes a separate
transaction. Correlation of the ACK with the 2xx is done by the UAS at a
higher layer, not by the transaction machines. In contrast, for non-2xx
final responses, the ACK is part of the same transaction, and so the
state machine must stick around to handle that. 

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 28 May 2002 09:08:51 -0500

Prabhas Sinha wrote:
> Even I am waiting to get some clarifications on it if I didnt understand 
> the model.

The protocol state machine for the INVITE transaction is accurate as
it stands (a fair amount of derivative work has been done based on it,
so it's soundness is not an issue).

To understand why the state machine is as shown, you need to recognize
that the ACK to a 200 OK (INVITE) consists of a separate transaction
entirely.  It may be routed separatley from the INVITE that triggered
it.  ACKs for non-2xx responses to INVITE are considered part of the
same transaction, and in fact, are propogated on a hop-by-hop basis.

Hence, when the client state machine gets a 200 OK to an INVITE, it
enters the Terminated state (since the ACK will be a new transaction).
When the client state machine gets a non-2xx, it will generate the
ACK and then enter the Terminated state.

Hope that helps.

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216

---

From: "Jeff Keyser" <[email-masked]>
Date: Tue, 28 May 2002 19:41:28 -0400

Thanks for the clarification.  Perhaps this reasoning should be explicitly
stated in the document, since I apparently wasn't the only person who was
confused by this.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Tuesday, May 28, 2002 1:44 AM
> To: Jeff Keyser
> Cc: SIP Mailing List (E-mail)
> Subject: Re: [Sip] Comment on draft-ietf-sip-rfc2543bis-09
>
>
> inline.
>
> Jeff Keyser wrote:
> >
> > I apologize if this is not the correct place for this
> comment.  If this
> > is
> > I am working with draft-ietf-sip-rfc2543bis-09 to write a
> SIP client,
> > and
> > (and "Calling" state for client transactions), if a new
> response status
> > code
> > is 300-699, the transaction changes to the "Completed"
> state; and, if a
> > new