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

From: "Mark Watson" <[email-masked]>
Date: Thu, 22 Nov 2001 13:52:18 -0000

Is it planned to remove the term 'established' entirely from a draft, or
will 'established' be a term which refers to a dialog which is in either
state ('early' or 'confirmed') ?

The next question (which is academic really) is what is the material
difference between an Early and Confirmed dialog with respect to actual
Proxy or UA behaviour at the dialog layer ? i.e. what does a proxy/UA do
differently with a confirmed dialog compared to an early one ?

I would have thought that most changes in behaviour on receiving a final
response are as a result of the *transaction* being completed, not as a
result of the dialog being confirmed.

Regards...Mark

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]]
Sent: 21 November 2001 22:35
To: Bob Penfield
Cc: Watson, Mark [MDN05:EP10:EXCH]; [email-masked]
Subject: Re: [Sip] Bis-05: Diaglog establishment ambiguity

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

Bob Penfield wrote:
> 
> 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
> 
> > 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
> >
> 
> _______________________________________________
> 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

-- 
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]

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 22 Nov 2001 18:06:47 +0200

Hello,

> Is it planned to remove the term 'established' entirely from a draft,
> or will 'established' be a term which refers to a dialog which is in
> either state ('early' or 'confirmed') ?

we still use "establish", but without a formal definition. Example: " a
180 response establishes a dialog which, at that point of time, is at
the early state."

> difference between an Early and Confirmed dialog with respect to
> actual Proxy or UA behaviour at the dialog layer ? i.e. what does a
> proxy/UA do differently with a confirmed dialog compared to an early
> one ?

One difference is that you terminate the early dialog with CANCEL and
the confirmed one with BYE. Another difference is that many pieces of
state in a confirmed dialog are fixed (except the Contact in the Route
set) whereas in an early dialog the 2xx response will change these
pieces of state.

> 
> I would have thought that most changes in behaviour on receiving a
> final response are as a result of the *transaction* being completed,
> not as a result of the dialog being confirmed.

As soon as you begin using early media, for instance, this distintion
between early and confirmed is very important.

Regards,

Gonzalo

> >  requests with specific methods. Within this specification, only the
> 2xx and
> > > is established as soon as a non-failure response is received -
> this is all
> > > state information. If it is necessary to distinguish between
> dialog state
> > > transaction layer concept - does it need to be reflected in dialog
> state ?
> > >
> > > Regards,
> > >
> > > Mark Watson
> > > Nortel Networks
> > >
> >

---

From: "Bob Penfield" <[email-masked]>
Date: Thu, 22 Nov 2001 11:38:34 -0500

> the confirmed one with BYE.

Just to be complete, CANCEL will terminate any and all early dialogs
resulting from an INVITE. BYE is used by the UAC to terminate a specific
early dialog.