[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sipping] I-D ACTION:draft-ietf-sipping-dialogusage-02.txt
Hi,
>>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.
[CHH] Ok, I found it. I guess the usage of it may depend on the SIPS discussion we're having, but that's a separate issue...
>>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."
[CHH] Sounds good.
>>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.
[CHH] Ok, I agree :)
>>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.
[CHH] Ok. But, in that case I think we need to clarify that the INVITE shall not be regarded as a re-INVITE, because it WILL contain a To tag.
>>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).
[CHH] Fair enough. But, should we then document those action points somehow, so we don't forget about them?
>>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.
[CHH] I guess it's ok. I don't like the idea of having different behaviour for different types of response codes within the same "group" (4xx, 5xx or 6xx), but I understand it would be difficult to come up with something more generic.
>>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?
[CHH] Yes. Sorry for that. What I meant to say was: If the sender of such message receives an error response I think the behavior should be the same as for unknown methods which cannot be matched with a usage. Ie if the sender receives an error response for a method (known OR unknown) which the receiver may not match to a specific usage, it should not terminate the usage. I don't think we have such known methods today, though.
>>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.
[CHH] An action point?
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