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

From: "Elwell, John" <[email-masked]>
Date: Thu, 30 Sep 2004 17:29:48 +0100

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 30 Sep 2004 22:54:05 -0400

John,

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