Re: [sipcore] Dialog state - Scope in draft-ietf-sipcore-reinvite

[Paul Kyzivat <[e-mail]>]

Gonzalo,

Gonzalo Camarillo wrote:
> Hi,
> 
> the re-INVITE draft talks about modifications in the session state,
> dialog state, and the dialog's remote target. While it is relatively
> well understood what we mean by session state and the dialog's remote
> target, we do not really have a good definition for dialog state.
> 
> We have discussed it in the past and what people had in mind were things
> such as called party identity. However, the draft is too vague at this
> point; it should be more precise regarding which piece of "dialog state"
> the rules in the draft apply to.
> 
> My suggestion would be to have the draft talk only about session state
> and the dialog's remote target, and forget about any other dialog state.
> New extensions whose parameters can be modified by re-INVITEs can
> specify their own rules, possibly referring to this draft and using the
> rules defined in it by reference. In this way, the applicability of this
> draft would be much clearer.

This is one of those areas that has bugged me for a long time.
3261 defines dialog state, but the definitions are spread through the 
text, and subject to interpretation. Things identifiable in 3261:

- remote URI
- local URI
- dialog id
   * local tag
   * remote tag
   * call-id
- local sequence number
- remote sequence number
- route set
- secure flag

- early / final
- local SDP
- remote SDP

(I just coined terms local/remote SDP. AFAIK its never mentioned as 
state, but clearly it is.) Of course there is no distinction between 
dialog state and dialog usage state - that distinction was made later. 
But based on subsequent refinements we now know that most of the above 
is generic dialog state, *except* for the local/remote SDP and the 
early/final attribute. (Early dialogs can only arise with INVITE.)

Clearly *reinvite* cannot really affect non-invite usages. So I think 
attributes of non-invite usages are out of scope for this draft.

I don't know of an exhaustive list of dialog state or invite-usage state 
that has been introduced in other documents. And in fact its not 
especially clear which things should be considered dialog/dialog-usage 
state, vs. just being transient/transaction state.

I do think it would be a good thing if an exhaustive list of dialog and 
dialog-usage state was documented, and possibly made an IANA registry. 
But the information certainly doesn't change much, or often, so maybe we 
can get by without that.

Its interesting that the "rollback" we have been so concerned with 
regarding reinvite in fact does not impact *any* of the *dialog* state - 
only some of the invite-usage state, and not all of that. So the 
rollback is really very limited, and should probably be described in 
terms of what it *does* affect rather than what it does not affect.

The modifications to the remote target discussed in this draft are 
indeed about *dialog* state, which affects other usages. But the 
*issues* about the remote target change are only applicable to INVITE, 
because only it can use provisional responses. The update of remote and 
local targets in other (i.e. subscribe) usages is straightforward.

You mention p-called-party, to which one might add p-asserted-id, 
p-preferred-id, etc. Its not at all clear to me whether those are even 
intended to be stateful. If they are, then they are dialog state, not 
invite-usage state.

	Thanks,
	Paul