[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sip] Comments on draft-elwell-sip-state-update-02
Paul,
Thanks for your explanation. You are of course correct that a dialog, a call
and a subscription are different objects and that there is not always a 1:1
relationship between the objects.
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, I don't think we need to put an excessive
amount of effort into distinguishing between states relating to the three
classes of object.
On the other hand, my concerns are more with those elements that you do
indeed regard as dialog state, rather than with those that you consider
either call state or just transient information. Therefore I am inclined to
limit my proposed bug fixes to just dialog state.
For RFC3261 this would really just involve some general statements and
coverage of the Allowed, Supported and Required headers (not currently
included).
Your proposal was that any dialog state information should be refreshed at
every opportunity and that this principle should be applied to the Allowed,
Supported and Required headers. It seems a sensible thing to do (otherwise
there is no way of indicating that a capability is no longer available), but
I am not sure whether this would break current implementations. I would like
to hear other opinions.
John
-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat at cisco.com]
Sent: 05 August 2004 20:07
To: Elwell, John
Cc: sip at ietf.org
Subject: Re: [Sip] Comments on draft-elwell-sip-state-update-02
Elwell, John wrote:
> Paul,
>
> By "call" I guess you mean "INVITE-initiated dialog".
Not quite.
There are dialogs, things that initiate dialogs, and things that
use/depend on dialogs.
Things that can initiate a dialog in a UAS are:
- INVITE without a to-tag
- SUBSCRIBE without a to-tag
- REFER without a to-tag
Things that can initiate a dialog in a UAC are:
- first response with to-tag to INVITE without to-tag
- first response with to-tag to SUBSCRIBE without to-tag
- first response with to-tag to REFER without to-tag
- first NOTIFY with from&to-tags in response to SUBSCRIBE or REFER
without to-tag. (If dialog wasn't already set up.)
Note that an INVITE/SUBSCRIBE/REFER doesn't initiate a dialog if sent
within one. You can (in theory anyway) send an INVITE within a dialog
initiated by a SUBSCRIBE. And you can send a additional SUBSCRIBEs
within a dialog initiated by either an INVITE or SUBSCRIBE.
The state of the dialog is not a function of how it was initiated.
In addition to possibly initiating dialogs, INVITE, SUBSCRIBE, and REFER
are also users of dialogs, but have their own state, which is in
addition to the state of the dialog itself. It is the state associated
with an INVITE that I was referring to as a *call*. In UML I would model
this as:
----------
| Dialog |
| State |
----------
1/ \1
/ \
0-1/ \0-n
--------- ----------------
| Call | | Subscription |
| State | | State |
--------- ----------------
Dialog state consists of the local and remote targets, route set, and
some other things that are shared by all uses of the dialog.
As currently specified there is little call state - in fact I think it
just consists of the presence or absence of a call within the dialog.
However you could consider the currently negotiated local and remote
session descriptions to be part of this state if you like. And Call-Info
could belong here.
Subscription state is more complex, because there can be multiple
subscriptions. It includes at least the event type and event id. This
can also cover REFER, since once it is established it is just another
subscription.
> I am not sure that a
> distinction needs to be made between state information associated with any
> dialog and state information associated only with an INVITE-initiated
> dialog. As far as the proposed modifications to RFC3261 are concerned,
> RFC3261 deals only with INVITE-initiated dialogs, so the distinction is
> unnecessary. I believe the same is also true of RFC3311.
Well, if you ignore all uses of dialogs except INVITE, then since there
can only be one INVITE per dialog, you can merge the two states. But
that then causes problems for the other uses of dialogs (like SUBSCRIBE)
that appear in other RFCs. A dialog that is used only for subscriptions
doesn't need state that is only associated with an INVITE.
This still isn't a problem if there isn't any state associated with an
INVITE beyond what is in the basic dialog, which is what 3261 suggests.
But what you are suggesting is that there is indeed additional state.
And some of that is only relevant for INVITEs, not other uses of dialogs.
> There may be one or two items that could be considered just message
> attributes rather than state, but I believe it is still valid to include
> these in a re-INVITE or UPDATE request. Is this just a matter of wording,
or
> do you believe they should not be included?
Its all just a matter of wording. :-)
If this is indeed state that must be maintained, then I think we
describe it differently than if it is just transient information carried
in a request. If it is transient information, then we probably need to
justify each place that it might go. If it is something that updates
state, then it is easier to justify carrying it in any message that is
used to modify other aspects of the same state.
The name of your draft talks about updating state. So it would be good
for it to focus on that, and to identify the stateful entities and their
state models.
Paul
> John Elwell (john.elwell at ietf.org)
>
>
>
>>-----Original Message-----
>>From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On
>>Behalf Of Paul Kyzivat
>>Sent: 01 August 2004 20:10
>>To: sip at ietf.org
>>Subject: [Sip] Comments on draft-elwell-sip-state-update-02
>>
>>
>>One issue that is very fuzzy in this draft is the distinction between
>>what is *dialog* state, and what is *call* state. My point is that
>>dialog state is common, and possibly shared, among invitations,
>>subscriptions, refers, and any other use of dialogs that may
>>come along
>>in the future. Call state is state that is specific to an invitation.
>>
>>The things mentioned in this draft are a combination of the two:
>>- Call-Info header
>>- Alert-Info header (early dialogs only)
>>- Contact header (change of feature tags)
>>- Reply-To header
>>- Subject header.
>>- P-Asserted-Identity header
>>- Privacy header
>>- Authenticated Identity Body (AIB)
>>- Bodies with Content-Disposition "icon" or "alert"
>>- Allowed header
>>- Supported header
>>- Required header
>>
>>If we are to clarify this, we need to clarify that there are
>>two state
>>models and augment them appropriately.
>>
>>For each of these it is debatable whether they are truly state, or
>>simply an attribute of the message that carries them.
>>
>>Call-Info, Reply-To, Subject: unclear to me. Could be viewed
>>as simply
>>an attribute of the message, or it could truly be call state.
>>
>>Alert-Info: seems more like at attribute of a message - 180 or 183 -
>>than as dialog state, even of an early dialog.
>>
>>Contact: clearly dialog state. No open questions here that I know of.
>>
>>P-A-I, Privacy, AIB: IMO these are indeed dialog state.
>>
>>Allowed, Supported, Required: IMO these should be considered
>>as dialog
>>state.
>>
>>For those that are deemed stateful, it must made clear
>>whether they must
>>be refreshed at every opportunity or if they remain until explicitly
>>overridden. IMO this is currently an ambiguity in the case of
>>Allowed,
>>Supported, Required. To work right in a stateful model, since
>>there is
>>no way to explictly negate one, I think they must be
>>refreshed in every
>>message. So every message in a dialog would have to provide
>>the full set
>>of supported options.
>>
>> Paul
>>
>>
>>
>>_______________________________________________
>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
>>This list is for NEW development of the core SIP Protocol
>>Use sip-implementors at cs.columbia.edu for questions on current sip
>>Use sipping at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip