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

From: "Mark Watson" <[email-masked]>
Date: Mon, 12 Nov 2001 17:25:09 -0000

You have to have some state between INVITE and the response(s) to match
incoming responses against, whether you consider this part of the INVITE
transaction or as part of a 'started' dialog is probably a matter of
preference.

For my part, I like to keep the layers self-contained, suggesting that this
information is at the 'dialog' layer, and not at the 'transaction' layer. I
would suggest that we model things so that there is always some for of
'dialog state' after the INVITE is sent. If this is an INVITE on an
established dialog, then this state consists of the full dialog state,
otherwise it consists of only the Local Address.

...Mark

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

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

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

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.

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

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.

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

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.

>
> 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 12:52:13 -0500

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

> transaction or as part of a 'started' dialog is probably a matter of

The client transaction and its FSM (section 17 of bis) is exactly what you
are describing.

> otherwise it consists of only the Local Address.
I agree with your idea of layering. However, I don't think there is anything
missing from the client transaction model that would affect
interoperability. Any state machine you design to become 'call-stateful' or
'dialog-stateful' is up to your implementation. I don't think we need to
make a dialog more complicated in the protocol.

_______________________________________________
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