Subject: [Sip] Bis-05: Diaglog establishment ambiguity

From: "Mark Watson" <[email-masked]>
Date: Fri, 9 Nov 2001 11:13:38 -0000

Apologies if this has already been covered.

There is an ambiguity in the specification with respect to the
'establishment' of a dialog.

Section 12.1 states:

"Dialogs are created through the generation of non-failure responses to
requests with specific methods. Within this specification, only the 2xx and
1xx responses to INVITE establish a dialog. A dialog established by a
non-final response to a request is called an early dialog."

i.e. a dialog is considered 'established' as soon as any 1xx or 2xx is
received. This means that 'establishing' a dialog is equivalent to
'creating' it.

However, the introduction to Section 12 states at the end:

"A dialog can also be in the "early" state, which occurs when it is created
with a provisional response, and then transition to the "established" state
when the final response comes."

i.e. the dialog is not considered 'established' until a *final* response is
received.

Aside from the need to make the terminology unambiguous, section 12.2
indicates that new requests within a dialog can be sent once it is
'established' so the definition of 'established' is clearly important.

I would suggest sticking with the description of 12.1 - i.e. that the dialog
is established as soon as a non-failure response is received - this is all
that is required to ensure both UAS & UAC have the required, synchronised
state information. If it is necessary to distinguish between dialog state
before and after a final response, then I'd suggest using the term
'confirmed' for dialogs where there has been a final response. I'm not sure
there is such a need - whether a response is provisional or final is a
transaction layer concept - does it need to be reflected in dialog state ?

Regards,

Mark Watson
Nortel Networks

---

From: Lei Liang <[email-masked]>
Date: Fri, 9 Nov 2001 13:00:32 +0000 (GMT)

hi, Mark,
  it is a little bit ambiguity in terminology. 
  I think the 'establish' means user can begin to talk or hear the
feedback ringing. so when a non-final response received, it could be
defined as 'establish'. And because CONCEL(new request) can be send after
request even without final response, so it can be said that the dialog is
established after receiving non-final or final response.
cheers.
lei

receiving final response 

> transaction layer concept - does it need to be reflected in dialog state ?

_______________________________________________
Sip mailing list  http://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: Anders Kristensen <[email-masked]>
Date: Fri, 09 Nov 2001 08:23:18 -0500

I don't think the intention is to say that *all* 2xx's and 1xx's
establish dialogs but that *some* of them do. This is maybe not
completely clear.

Anders

Mark Watson wrote:
> "Dialogs are created through the generation of non-failure responses
> to requests with specific methods. Within this specification, only the
> 2xx and 1xx responses to INVITE establish a dialog. A dialog
> established by a non-final response to a request is called an early
> dialog."
> 
> "A dialog can also be in the "early" state, which occurs when it is
> created with a provisional response, and then transition to the
> "established" state when the final response comes."
> 
> i.e. the dialog is not considered 'established' until a *final*
> response is received.
> 
> I would suggest sticking with the description of 12.1 - i.e. that the
> dialog is established as soon as a non-failure response is received -
> this is all that is required to ensure both UAS & UAC have the
> required, synchronised state information. If it is necessary to
> distinguish between dialog state before and after a final response,
> then I'd suggest using the term 'confirmed' for dialogs where there
> has been a final response. I'm not sure there is such a need - whether
> a response is provisional or final is a transaction layer concept -
> does it need to be reflected in dialog state ?
> 
> Regards,
> 
> Mark Watson
> Nortel Networks

---

From: "Bob Penfield" <[email-masked]>
Date: Fri, 9 Nov 2001 08:57:56 -0500

I think we should have "early" and "established" states for the dialog. I
suggest the paragraph in section be re-worded as follows:

 "Dialogs are created through the generation of non-failure responses to
 requests with specific methods. Within this specification, only the 2xx and
 1xx responses to INVITE create a dialog. A dialog created by a
 non-final response to a request is called an early dialog. An established
dialog
 is created by a final response. Once a final response is received for an
 early dialog, it becomes an established dialog"

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

----- Original Message -----
From: "Mark Watson" <[email-masked]>
To: <[email-masked]>
Sent: Friday, November 09, 2001 6:13 AM
Subject: [Sip] Bis-05: Diaglog establishment ambiguity

> "A dialog can also be in the "early" state, which occurs when it is
created
> I would suggest sticking with the description of 12.1 - i.e. that the
dialog

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 22 Nov 2001 00:35:03 +0200

Hello,

we have finally chosen "early" and "confirmed" as the states of a
dialog. A 1xx responses different than 100 creates a dialog in "early"
state. When the 2xx is received it transitions to the "confirmed" state.

It is of course possible for a dialog to be created in the "confirmed"
state directly.

Regards,

Gonzalo

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              [email-masked]