Subject: [Sipping] Update: dialogusage

From: Robert Sparks <[email-masked]>
Date: Fri, 3 Mar 2006 12:57:42 -0600

I've just submitted
http://www.nostrum.com/~rjsparks/draft-ietf-sipping-dialogusage-01.txt
http://www.nostrum.com/~rjsparks/draft-ietf-sipping-dialogusage-01.html

 From the changelog section:

A.1.  draft-ietf-00->draft-ietf-01

    o  Changed 481 to only affect the usage the response occured in,
       closing the last open issue.  Added some text justifying this
       recommendation.
    o  Added 422 Session Interval Too Small
    o  Added 417 Uknown Resource-Priority
    o  Added 428 Use Identity Header
    o  Added 436 Bad Identity-Info
    o  Added 437 Unsupported Certificate
    o  Added 438 Invalid Identity header
    o  Added a section categorizing messages that create and destroy
       usages
    o  Made sure all descriptions in Section 4 addressed the generic
       multi-usage case.
    o  Clarified that the mechanics described in matching messages to
       usages applied equally to UACs and UASs.
    o  More explicitly noted that REFER creates a subscribe-usage

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 03 Mar 2006 19:33:41 -0500

Robert,

I am really liking this now. (I am still not too wild about the 
preaching, but it is to a level I can tolerate and I know I am in the 
minority.)

I did find some things - mostly minor, except for one below where I used 
CAPITAL LETTERS.

I have used quoted text for excepts from the draft that I am referring to.

	Thanks for this,
	Paul

Section 1 - list of shared state: also the "secure flag".

Section 3.1 - is invite usage destroyed by the response to the BYE, or 
by the BYE? Is anybody going to keep their dialog because the BYE was 
rejected?

>    429 Provide Referrer Identity: This response won't be returned to a
>       NOTIFY as in our example scenario, but when it is returned to a
>       REFER, it is objecting to the REFER request itself, not any usage
>       the REFER occurs within.  The usage is unaffected.  Any other
>       usages sharing this dialog are unaffected.  The dialog is only
>       affected by a change in its local CSeq.

nit picking. Since REFER is a usage-establishing request, I don't think 
it should be considered to be within any existing usage.

>    480 Temporarily Unavailable: RFC 3261 is unclear on what this
>       response means for mid-usage requests.  Clarifications will be
>       made to show that this response affects only the usage in which
>       the request occurs.  No other usages are affected.  If the
>       response included a Retry-After header field, further requests in
>       that usage should not be sent until the indicated time has past.
>       Requests in other usages may still be sent at any time.

This might occur for a usage-establishing request not in an existing 
usage. In that case further requests should probably not be sent that 
attempt the same kind of usage. But this might only mean not subscribing 
to the same event package - subscribing to some other event package 
might be ok. Very fuzzy. (Even out of dialog it is fuzzy.)

>    500 and 5xx unrecognized responses: These responses are complaints
>       against the request (transaction), not the usage.  If the response
>       contains a Retry-After header field value, the server thinks the
>       condition is temporary and the request can be retried after the
>       indicated interval.  This usage, and any other usages sharing the
>       dialog are unaffected.  If the response does not contain a Retry-
>       After header field value, the UA may decide to retry after an
>       interval of its choosing or attempt to gracefully terminate the
>       usage.  Whether or not to terminate other usages depends on the
>       application.  If the UA receives a 500 (or unrecognized 5xx) in
>       response to an attempt to gracefully terminate this usage, it can
>       treat this usage as terminated.  If this is the last usage sharing
>       the dialog, the dialog is also terminated.

A large part of the above text appears to be applicable to many of the 
4nn responses.

>    MESSAGE requests are not currently allowed inside a dialog (though
>    some implementations use it that way, against the standard
>    recommendation).  As it is not meant to be part of any given dialog,
>    it cannot be part of any given usage.  A failed MESSAGE request
>    should have similar effects on a dialog and its usages as a failed
>    OPTIONS request.

The restriction is more nuanced than that. From 3428:

    The authors recognize that there may be valid reasons to send MESSAGE
    requests in the context of a dialog.  For example, one participant in
    a voice session may wish to send an IM to another participant, and
    associate that IM with the session.  But implementations SHOULD NOT
    create dialogs for the primary purpose of associating MESSAGE
    requests with one another.

Section 4.5:

>    Abnormal termination can effect all usages on a dialog.  Rejecting a
>    NOTIFY with a 481 (incorrectly recommended in the past as an
>    inexpensive way to terminate a REFER subscription) destroys the
>    dialog and all of its usages.

THIS IS REALLY WRONG NOW - inconsistent with earlier language.

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 8 Mar 2006 09:27:10 +0100

Robert,

Could you elaborate on the difference between "destruction" and 
"termination" of a usage? RFC4235 states that sending a BYE transitions the 
call state to Terminated (read "invite-usage" instead of call here). In 
section 3.1, your draft states that 200 responses to BYE "destroy" an 
invite-usage. My interpretation would be that after termination of the last 
usage, no new usages should be accepted, and destruction involves freeing 
the resources / state involved with the usage (and possibly the dialog when 
all usages have been destroyed).

Second, I think that _any_ response or timeout for a BYE / NOTIFY w/ 
terminated should destroy the usage. If not, you get into an akward 
situation in which a peer can refuse e.g. a BYE and keep you from freeing 
resources.

Third (this may already exist or have been said before), there should be a 
mechanism to ensure that SUBSCRIBE w/ Expires=0 eventually destroys the 
subscribe-usage, at least at the subscriber side. Currently the draft states 
that timeout of this transaction destroys the usage, but what if a response 
comes back but a NOTIFY is never received? It seems like a timer is needed 
here. I also remember seeing some draft about setting a flag in the 
SUBSCRIBE to avoid the NOTIFY - in such a case the usage should be destroyed 
for any response.

Regards,

jeroen

---

From: Robert Sparks <[email-masked]>
Date: Wed, 8 Mar 2006 09:17:01 -0600

On Mar 8, 2006, at 2:27 AM, Jeroen van Bemmel wrote:

> "termination" of a usage? RFC4235 states that sending a BYE  
> transitions the call state to Terminated (read "invite-usage"  
> instead of call here). In section 3.1, your draft states that 200  
> responses to BYE "destroy" an invite-usage. My interpretation would  
> be that after termination of the last usage, no new usages should  
> be accepted, and destruction involves freeing the resources / state  
> involved with the usage (and possibly the dialog when all usages  
> have been destroyed).

I've been using them as synonyms in the draft. During the next edit I  
will choose one and stick with it.
In all cases, the _instant_ a dialog has no more usages, it is  
terminated and its resources can be freed.

>
> Second, I think that _any_ response or timeout for a BYE / NOTIFY  
> w/ terminated should destroy the usage. If not, you get into an  
> akward situation in which a peer can refuse e.g. a BYE and keep you  
> from freeing resources.

This is a long running and oft-repeated discussion. The points argued  
are that if you don't wait for responses, you
cant challenge so have introduced a risk of accepting malicious BYEs.  
Identity could make this better. And at any
time, if you have evidence that your peer is being malicious or  
violating protocol, you can walk away from the state.

>
> Third (this may already exist or have been said before), there  
> should be a mechanism to ensure that SUBSCRIBE w/ Expires=0  
> eventually destroys the subscribe-usage, at least at the subscriber  
> side. Currently the draft states that timeout of this transaction  
> destroys the usage, but what if a response comes back but a NOTIFY  
> is never received? It seems like a timer is needed here. I also  
> remember seeing some draft about setting a flag in the SUBSCRIBE to  
> avoid the NOTIFY - in such a case the usage should be destroyed for  
> any response.
Clarifying how long to wait to receive a NOTIFY to an initial or  
refresh subscription has already been identified
as an action to the next update of 3265. I will note that in this draft.
There is no usage for a refer/norefer-sub. Its just a transaction.