[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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