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

From: "Mark Watson" <[email-masked]>
Date: Mon, 12 Nov 2001 14:20:33 -0000

Do you mean that to be consistent with the usage of the term 'established'
through the draft, then a dialog should be consided 'established' as soon as
any non-failure response is received ?

So, let's say 'confirmed' for dialogs where a final response has been
received. Note that a 'confirmed' dialog is also 'established'.

Also, we might as well have a term for the state before any response has
been received, let's say 'started'.

So we have three states for dialog (as well as the state in which the dialog
does not exist at all), as follows:
'started' - between INVITE and any response
'established and not confirmed' - between 1xx and 2xx
'established and confirmed' after 2xx

I suppose this state machine exists at UAC, UAS and each dialog-stateful
proxy.

Question: how long does the 'started' dialog exist ?

On receipt of a response, an 'established' dialog is created by filling in
the remote address in the 'started' dialog. But subsequent responses from
other UASs (due to forking of the request) will create further 'established'
dialogs with different remote addresses - so in a sense the 'started' dialog
(which has only a local address) still exists as a separate entity from the
'established' ones. How long does it persist for ? (i.e. at what point are
further response from new endpoints no longer allowed ?)

Finally, you mention that we need to initiate regular transaction on early
(established and not confirmed) dialogs, but 12.2 allows us to initiate any
transactions, not just regular ones. i.e. we can sent a Re-INVITE.

...Mark

-----Original Message-----
From: Bob Penfield [mailto:[email-masked]]
Sent: 12 November 2001 13:43
To: Watson, Mark [MDN05:EP10:EXCH]
Cc: sip
Subject: Re: [Sip] Bis-05: Dialog establishment ambiguity

No, we need to be able to initiate regular transactions on early dialogs
(like BYE). I now think that we need a different term for a dialog after
2xx. After scanning bis-05, the term 'established' is used when referring to
dialogs of either type in many places.

(-: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: "'Bob Penfield'" <[email-masked]>
Sent: Monday, November 12, 2001 5:44 AM
Subject: RE: [Sip] Bis-05: Diaglog establishment ambiguity

> Bob,
>
> I don't care about the terminology, so long as it is unambiguous, but
unless
> you modify 12.2 as well, your changes below would imply that new requests
> within a dialog cannot be sent until we have a final response for the
dialog
> - was that your proposal ?
>
> Regards...Mark
>
> -----Original Message-----
> From: Bob Penfield [mailto:[email-masked]]
> Sent: 09 November 2001 13:58
> To: Watson, Mark [MDN05:EP10:EXCH]; sip
> Subject: Re: [Sip] Bis-05: Diaglog establishment ambiguity
>
>
> 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

---

From: "Bob Penfield" <[email-masked]>
Date: Mon, 12 Nov 2001 10:05:42 -0500

----- Original Message -----
From: "Mark Watson" <[email-masked]>
To: "'Bob Penfield'" <[email-masked]>
Cc: "sip" <[email-masked]>
Sent: Monday, November 12, 2001 9:20 AM
Subject: RE: [Sip] Bis-05: Dialog establishment ambiguity

> any non-failure response is received ?

Yes more or less. Since the words establish and established are used in many
places when talking about a dialog in either state, we should not use
"established" as one of the states. Some of the text may need to be
clarified if when it says "established dialogic" it means post-2xx.

We should have "early" and "confirmed" (or whatever term the authors desire)
as the states of an established dialog. Thus a dialog is establised/created
by the first 1xx/2xx with a To tag.

> I suppose this state machine exists at UAC, UAS and each dialog-stateful

I see only 2 states: 'early' and 'confirmed' (or whatever the authors want
to call it).
What you call 'started' is "the state in which the dialog does not exist at
all". The current draft does not mention this state. I don't think that we
need to extend it. The state machine you talk about would not need to be
instantiated until the dialog is created/established. Besides there is no
way to know ahead of time how many dialogs might get created when a UAC
sends an INVITE.

> further response from new endpoints no longer allowed ?)

Again, there is no instance of a dialog before you get a 1xx/2xx. You just
have the client transaction at the UAC. The UAC uses the client transaction
state machine for timing out the INVITE.

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