[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sipping] I-D ACTION:draft-ietf-sipping-dialogusage-02.txt
Thanks Christer -
inline
On Jun 28, 2006, at 4:53 AM, Christer Holmberg ((JO/LMF)) wrote:
Hi,
I think the draft looks pretty good, but I still have comments.
Now, since the draft proposes not to use multiple usages in the
first place we can of course discuss whether all issues need to be
solved. But, if we choose NOT to solve them, I think it still would
be good to document that the issues exist.
FIRST, where is "secure flag" defined? I think it would be good to
add a reference, because as far as I know it's not defined in RFC3261.
I can add a reference - it's in 3261 at the
last paragraph of section 12 (before the header-line for 12.1:
A dialog contains certain pieces of state needed for further message
transmissions within the dialog. This state consists of the dialog
ID, a local sequence number (used to order requests from the UA to
its peer), a remote sequence number (used to order requests from its
peer to the UA), a local URI, a remote URI, remote target, a boolean
--> flag called "secure", and a route set, which is an ordered list of
URIs. The route set is the list of servers that need to be traversed
to send a request to the peer. A dialog can also be in the "early"
state, which occurs when it is created with a provisional response,
and then transition to the "confirmed" state when a 2xx final
response arrives. For other responses, or if no response arrives at
all on that dialog, the early dialog terminates.
SECOND, chapter 1 says: "The pseudo-dialog behavior of REGISTER
could be considered a third usage. Fortunately, no existing
implementations have attempted to mix a registration usage with any
other usage."
I am not sure what implementations there are out there, but I think
it's enough to say: "The pseudo-dialog behavior of REGISTER is not
considered a third usage".
It's important to capture that there is no operational knowledge of
mixing REGISTER with other things. How about this instead:
"The pseudo-dialog behavior of REGISTER is not a third usage. There
are no known attempts to use REGISTER inside any other usage."
THIRD, chapter 3.1 says that a 200 response to BYE destroys an
Invite usage. As far as the UAC is concerned, I think that ANY
response will destroy the Invite usage.
503, 420. Then there's the 401/7 rathole of infinite depth. I believe
we want to leave this text as is.
FOURTH, chapter 3.2 says that a subscribe usage can be created by a
NOTIFY request. Do we need to clarify that it is not any NOTIFY,
but a NOTIFY associated with a SUBSCRIBE or REFER. Maybe it's
obvious, but still...
Ok - that's an easy change.
FIFTH, chapter 1 says that a dialog can contain only one Invute
dialog usage. But, as we agreed an Invite usage can not be created
within an existing dialog (no matter what type of usages already
exist within that dialog), i.e. an Invite dialog usage can ONLY be
created when the dialog itself is created, and one dialog can ONLY
contain one Invite dialog usage. So, I think we need text to
clarify that. It may sound obvious, but to avoid questions on the
list in the future...
IIRC, the text that talks about a dialog containing only one invite
usage is exploring/explaining the situation we have now, where you
_can_ send an INVITE inside a subscribe dialog.
SIXTH, chapter 4.1, for 3xx responses, I think that instead of
talking about "our example" we should say that a 3xx reponses is
condiered to affect all usages within the dialog.
The text that's there now says exactly that: Redirection mid-dialog
is not well understood in SIP,
but whatever effect it has impacts the entire dialog and all of
its usages equally.
The following sentence that ties it into the example doesn't weaken
the statement.
Now, I guess that means that, within a subscribe dialog usage,
refresh SUBSCRIBE requests shall be sent towards the new remote
destination - BUT NOTIFY requests may still come from the old
remote destination, and I assume is supposed to accept those NOTIFY
requests (?). I think we need to say that.
Not in this draft. Clarifying what 3xx inside a dialog means is one
of the action points that will come out of this draft
(remember the next step will be to develop a work plan to make
changes/clarifications to standards track documents to clear up some
of the confusing points).
For some of the 4xx responses you also talk about "our example
scenarios". I think we should be more generic, and not base our
"normative" text on examples.
Two revisions ago we went through and tried to make sure that we had
general statements in place in every section. Tying it to the example
is still important.
If you see a place remaining where it only talks in terms of the
example, but doesn't describe the general case, point it out and
we'll fix it.
SEVENTH, chapter 4.2 talks about transaction timeouts. It is
possible that the remote party is not aware that one side has
destroyed a usage, e.g. due to a transaction timeout (the message
never reached the remote party). Then, if the remote side still
sends requests for that usage. I think it would be good to mention
this, and maybe add some proposed behavior or the receiver (shall
it send 481?). This "unsynchronization" may also occur if all
entities does not understand a specific 4xx response, and some
entities remove the usage but others don't.
I'm not seeing the potential for any confusion here. 3261/5 both
cover issuing 481s in this situation explicitly.
EIGHTH, chapter 4.3 talks about the impact of an error response
"Mid-dialog requests with unknown methods cannot be matched with a
usage". Now, at one point I said that at some point there MAY be
"known" messages which do belong to a usage, but the receiver does
not know to which usage. If the sender of such message receives an
error response I think the behvior should be the same: the
This got truncated?
NINETH: At one point, I also asked whether we should define some
kind of "usage identifier". That would solve some of the problems
we've identified. In that case we could also define a new response
code, and use that instead of 603 (chapter 4.6) when refusing a new
usage (e.g. because the "maximum number of usages" have been reached).
A good conversation to have, but not one to capture in this document.
Regards,
Christer
-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat at cisco.com]
Sent: 27. kesäkuuta 2006 23:42
To: sipping; Robert Sparks
Subject: Re: [Sipping] I-D ACTION:draft-ietf-sipping-
dialogusage-02.txt
Robert,
This is pretty much done I think.
Down to nits now:
In 1:
Usages have state that is not shared in the dialog. For
example, a
subscription has a duration. Multiple subscriptions in the same
dialog each have thier own duration.
True, but subscribe usages have more state than that. Also Event
type and Event ID. (I guess the parameters on the event type are
part of the
type.) So perhaps the above should say:
Usages have state that is not shared in the dialog. For
example, a
subscription has a duration, event type, and event id. Multiple
subscriptions in the same dialog each have thier own duration,
event
type, and event id.
In description of 603 handling: Is the implication different if the
request declined is one that would terminate the usage? Or in that
case must one just wait for the usage to expire?
Thanks,
Paul
_______________________________________________
Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP Use sip-
implementors at cs.columbia.edu for questions on current sip Use
sip at ietf.org for new developments of core SIP
_______________________________________________
Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP