Subject: RE: [Sip] Proposed bug fix to RFC3261 arising from draft-elwell-s ip-state-u pdate-02

From: "Elwell, John" <[email-masked]>
Date: Fri, 01 Oct 2004 09:09:35 +0100

Paul,

Thanks for your comment. You have made it clear before that there is a
distinction between call state and dialog state, and that there is not
always a 1:1 relationship between them.

However, there are moves to deprecate dialog re-use. So although there are
examples of dialog re-use today (the REFER case being the prime example), I
don't anticipate new applications of this technique to be endorsed and there
is likely to be a move to phase out existing forms of re-use. 

Moreover there cannot be more than one call per dialog. Therefore if a
dialog supports a call, there is not a lot of difference in principle
between dialog state and call state, although if the dialog also supports a
subscription, call state information will not survive after a BYE, even
though dialog state will survive if the subscription survives.

With these considerations in mind, perhaps we don't need to put an excessive
amount of effort into distinguishing between call state and dialog state.
Call state just becomes a part of dialog state, existing on dialogs that
support calls but not on dialogs that support subscriptions.

I eliminated some of the elements such as Call-Info, the updating of which
did not appear to be of great interest to anyone and which, as you say, are
call state. Yes, session information I guess is also call state.

I forgot to add Required/Supported/Allowed headers, which I guess are in
fact part of the dialog state. From other specifications, PAI is an example
of data that is part of dialog state.

I guess the main question we need to answer is whether this proposed
clarification to RFC3261 (and eventually RFC3311) should embrace dialog
state change, call state change or both. One difficulty is that the term
"call" is not well-defined in RFC3261 (the Call-Id header unfortunately is
dialog state, not call state). Then the question arises whether we should
embark on trying to define the term call and hence call state.

So I see the following options, and I would like some feedback from the
list:

1. Do nothing.

2. Do not attempt to distinguish between call state and dialog state, on the
basis that the desire is to phase out dialog re-use (some dialogs will of
course also be calls, but a dialog should not serve two purposes:
subscription and call). In other words, continue as proposed in my previous
email (possibly restoring things like Call-Info if there is interest).

3. Stick rigidly to dialog state (so session information would be removed
from my proposal).

4. Define "call" and "call state" and distinguish them from "dialog" and
"dialog state". Handle both call state update and dialog state update.

Opinions please.

John Elwell ([email-masked])

Paul Kyzivat wrote:
I agree with what you are trying to do. But one rather significant 
detail with what you propose is that I don't believe the session 
description (SDP) is dialog state. It is call state. (A dialog that 
exists for the purpose of a SUBSCRIBE would not have this.)

That in some sense guts this proposal, since now there are no examples 
in this document of additional dialog state. However I still think the 
clarification is needed.

In addition, 3261 sweeps the distinction between dialog state and call 
state under the rug. Once alternative uses of dialogs are in play it is 
important to make this distinction clear, and to identify those items 
that are part of call state. This includes the session description info 
(the negotiated offer and answer as well as potentially another proposed 
change to offer and answer). It also includes the data associated with 
session timer, and possibly Call-Info, Alert-Info, Subject. (Which if 
any of these is truly call state remains to be discussed.)

	Paul

Elwell, John wrote:
> At the SIP meeting in San Diego, I was asked to raise on the mailing list
> the individual bug fixes proposed in the state-update draft, so that each
> can be given due scrutiny. I decided to start with RFC3261. Here only a
few
> changes are proposed and it does not seem sensible to consider these
> separately, so I propose them here as a single bug fix. If we can gain
> consensus on those, I will follow it up with messages proposing bug fixes
to
> the other documents (mainly RFC3311).
> 
> As a result of comments by Paul Kyzivat raised on the list recently, I
have
> modified the proposed changes slightly. In particular, I have dropped any
> headers that are not obviously dialog state changes, including those that
> might not be considered state at all (e.g., Alert-Info) and those that
might
> be considered call state rather than dialog state (e.g., Call-Info,
> Subject). If anyone wants these re-instating, please say so.
> 
> Proposed bug fix to RFC3261:
> 
> Add the following paragraph to the end of 12 (prior to 12.1):
> 
> "A dialog can also have certain other state information that can change
> during the lifetime of the dialog. This includes the session description
(as
> negotiated by SDP offer/answer), information from certain other headers
and
> information from certain other bodies. There are no examples from this
RFC.
> However, extensions may define other headers or bodies containing
> information that contributes to the state of a dialog and can change
during
> the lifetime of the dialog."
> 
> Add two new paragraphs to the end of 12.2 (prior to 12.2.1):
> 
> "A request, whether or not it is a target refresh request, MAY update
> certain other information transmitted at the time of dialog establishment.
> Although there are no examples in this RFC, other extensions may define
> headers or bodies that are appropriate for updating during a dialog.
> 
> "In this RFC, the only request defined that is suitable for updating
> information during a dialog is re-INVITE (see section 14). Other
extensions
> may define different requests suitable for updating information during a
> dialog."
> 
> Add to the end of the first paragraph of 14.1:
> 
> "A UAC MAY send a session description that is unchanged, if the purpose of
> the re-INVITE is solely for updating dialog-related information."
> 
> John Elwell ([email-masked])
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: "Elwell, John" <[email-masked]>
Date: Mon, 25 Oct 2004 16:38:29 +0100

I received no responses to the following mail, asking for opinions on which
direction to take. The default is, of course, option 1 (do nothing - no
clarifications to state update will be made). Therefore in the absence of
any proposals to the contrary by the Washington meeting, I will drop this
work.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Elwell, John
> Sent: 01 October 2004 09:10
> To: 'Paul Kyzivat'
> Cc: [email-masked]'
> Subject: RE: [Sip] Proposed bug fix to RFC3261 arising from 
> draft-elwell-s ip-state-u pdate-02
> 
> Paul,
>