Subject: [Sip] comments on draft-ietf-sip-events-02.txt

From: "Bob Penfield" <[email-masked]>
Date: Thu, 14 Feb 2002 13:06:32 -0500

Here are some comments on the SIP Events draft.

I found the draft well organized and easy to understand. The only trouble I
had was with dialog & route-set establishment. It is a little tricky
depending on whether one or multiple dialogs are to be established.

As I understand it, for a SUBSCRIBE sent outside of a dialog, a new dialog
can be established either by the 2xx response to the SUBSCRIBE or the first
NOTIFY request. If the package and the subscriber are willing to accept
multiple dialogs, the 2xx response or the first NOTIFY from the notifier
that sent the 2xx response establishes one dialog, and each initial NOTIFY
from other notifiers establish an additional dialog.

Now, if the package or the subscriber requires only one dialog, either the
2xx response or the first NOTIFY received (using the matching rules in
4.3.4) establishes the dialog (which ever arrives first wins), and the route
set for the dialog comes from the record-routes in that message.

The part that might get confused by implementers is when the NOTIFY arrives
first, and the 2xx that arrives later does not come from the notifier that
sent the NOTIFY. In this case, the 2xx's dialog-id (as defined in bis) will
not match the dialog-id established by the NOTIFY. This 2xx response DOES
NOT establish a new dialog and the subscriber MUST NOT use the record-route
& contact from the 2xx as the route-set for the existing dialog since they
point at the wrong notifier.

Have I got that right?

Here are some specific comments:

sec 4.1.1, 3rd para. The restriction on the server changing the expire
period disagrees with that in section 4.1.6.1. You may want to just refer to
that section rather than having the rule duplicated.

sec 4.2.3: Why is record-routing a MUST on all SUBSCRIBE and NOTIFY
requests? It certainly needs to be on the SUB & NOT that establish dialogs,
but bis-07 does not allow the route to be changed (only the target), so it
just seems like wasted bandwidth especially on subsequent NOTIFYs within the
dialog.

sec 4.2.4: I think you need a statement requiring a timely response to a
NOTIFY similar to one for SUBSCRIBE in the 1st paragraph of 4.1.6.1. The
statement "Once the notification is deemed acceptable to the subscriber..."
might be interpreted as allowing user (human) input/verification.

sec 4.3.3: I suggest adding "In accordance with the rules for proxying
non-INVITE requests in [1]" at the start of the first sentence so it is
clear that it is a basic SIP requirement.

sec 4.3.4: 1st para: s/sent on an pre-existing/sent on a pre-existing/

sec 4.3.4: 3rd para, last sent: s/unless the have/unless they have/

sec 5.4.7: 2nd para: s/used to processes the/used to process the/

sec 5.4.9: 3rd para: s/forked INVITE/forked SUBSCRIBE/

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

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

---

From: Adam Roach <[email-masked]>
Date: Fri, 15 Feb 2002 15:04:28 -0500

<snip>

> Have I got that right?

Your explanation is spot on. I'll attempt to clarify the bit about
a 200 response *not* setting up a dialog under the conditions you
describe.

> just seems like wasted bandwidth especially on subsequent 

I think this has historically been a "MUST" for some version of
bis, and I was merely reiterating it (because it was important
for the NOTIFY messages in the case of a fork). I could relax
it from MUST to SHOULD for messages sent inside an existing
dialog, since it appears to be a SHOULD as of bis-07:

     If this request is already part of a dialog, the proxy
     SHOULD insert a Record-Route header field value if it
     wishes to remain on the path of future requests in the
     dialog. In normal endpoint operation as described in
     Section 12 these Record-Route header field values will not
     have any effect on the route sets used by the endpoints.

I'm taking this comment under advisement, and may be changing the
draft accordingly. I welcome comments from any interested parties.

Thanks for the other comments. I will be incorporating them.

/a

---

From: Adam Roach <[email-masked]>
Date: Fri, 15 Feb 2002 16:45:43 -0500

> point at the wrong notifier.

Actually, as I went to edit the document, I realized that this
isn't correct for all cases. What you state above is true in the
case that only one dialog is allowed to be established. Event
packages may allow a single SUBSCRIBE message to establish several
dialogs -- in which case, this 200 may very well establish a
new dialog.

I'll put clarification on this topic in the section which describes
the two options from which event packages should select.

/a