Subject: RE: [Simple] 200 vs. 202

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 21 Nov 2001 14:59:39 -0500

how about this:

1. if the subscriber hasn't gotten a 2xx to the SUBSCRIBE, it accepts the
NOTIFY
2. once the response to the SUBSCRIBE comes, if its not a match for the
NOTIFY, the subscriber refreshes the dialog associated with the NOTIFY, but
with Expires:0, to terminate it.

This avoids the tight transaction timing interdependencies at the expense of
some additional higher level processing.

BTW, this is really a sip-events issue not so much a simple issue.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com
  
-----Original Message-----
From: Brian Stucker [mailto:[email-masked]]
Sent: Wednesday, November 21, 2001 2:23 PM
To: adam.roach; simple
Subject: RE: [Simple] 200 vs. 202

You bring up an important point about the watcher having to wait for the
response to the SUBSCRIBE before processing the NOTIFY. This could give us
problems if the 200 takes a long time getting back to the watcher, and the
NOTIFY, in the meantime, is just sitting there being retransmitted over and
over, waiting for a response. Depending on the T1 and T2 timers being used,
this could create a race condition that might cause a subscription to fail
because there was no response to the immediate NOTIFY.
In general, what happens when a NOTIFY to the inital SUBSCRIBE fails to be
acknowledged?  Does the subscription go away like it does for later NOTIFY
messages? The reason I ask, is because it would seem to leave the watcher in
an undefined state. What are the responsibilities of a watcher that sends a
SUBSCRIBE, gets a 200, and then no NOTIFY?
A possible solution would be to silently throw away and NOTIFY messages that
we have not gotten a response (200) on the request to create a dialogue for
(the SUBSCRIBE). If we do that, then we could wait for some period of time
(say the expires header in the 200 response). If that period of time elapses
without a NOTIFY, then we send the SUBSCRIBE again (if we got a 200).
Thoughts? 
Brian 
-----Original Message----- 
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, November 20, 2001 3:18 PM 
To: simple 
Subject: RE: [Simple] 200 vs. 202 

While I disagree with Brian and Jonathan about the problems presented 
by having multiple PAs in the network, I am willing to quit the topic 
for the sake of moving forward. 
I am very wary, however, of any discussions which use arguments about 
the general case of forking of SUBSCRIBE requests instead of those 
involving multiple PAs. I wouldn't have even entered the fray if the 
arguments presented by several parties didn't attack the very notion 
of SUBSCRIBE forking (instead of limiting themselves to presence in 
particular). 
So, with my capitulation, I'll attempt to enumerate what I think 
we've all agreed on: 
 1. SUBSCRIBE requests may fork. 
 2. Subscribers may choose to accept zero or more of the 
    NOTIFY requests that arrive by responding to them with 
    a 200. 
 3. Subscribers may choose to reject zero or more of the 
    NOTIFY requests that arrive by responding to them with 
    a 481. 
 4. Subscribers _to_ _presence_ _information_ SHOULD or MUST (I 
    don't personally care which) accept exactly one NOTIFY 
    message with a 200, and reject all others with a 481. 
 5. Subscribers _to_ _presence_ _information_ select which 
    NOTIFY to accept based on the dialog information 
    established by the 2xx response to the SUBSCRIBE. 
Moving forward, then, I see two sets of problems to be addressed: 
Forking SUBSCRIBE: 
  - How do we perform authentication for forked SUBSCRIBE messages? 
    This is actually a more general problem which can be phrased 
    "How do we perform authentication for forked XXX messages?" where 
    XXX includes INVITE. I would *really*, *really* like to see a 
    more general solution to this problem before we start trying 
    to cobble something together for SUBSCRIBE. 
  - How do we protect against the DOS attacks that Robert describes? 
Presence: 
  - In a forking situation, it is likely (probable, even) that the 
    NOTIFY requests will arrive at the subscriber before the 2xx 
    reply to the SUBSCRIBE. Does that mean that the response to the 
    NOTIFY requests will be suppressed until the SUBSCRIBE request 
    completes? If so, this should be well documented in the 
    presence event package. 
  - Some of the arguments made against accepting multiple dialogs 
    created by a single SUBSCRIBE were privacy based: an aggregation 
    point must exist in the network to provide a consistent policy. 
    Given that there is no way to enforce that only one dialog is 
    accepted, are there any privacy concerns that can arise from 
    rogue clients accepting all received NOTIFYs? 
/a 
_______________________________________________ 
simple mailing list 
[email-masked] 
http://mailman.dynamicsoft.com/mailman/listinfo/simple 
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: [email-masked]
Date: Mon, 26 Nov 2001 11:14:23 -0600

That works, but it seems like a lot of extra implementation effort.

There's really nothing magical about the dialog established by the
200-class response to the SUBSCRIBE; it's just an arbitrary leg
which happens to have responded first.

Given that fact, why don't we just change the scheme so that the
dialog associated with the SUBSCRIBE response isn't special, and
we just accept the first NOTIFY that arrives (and reject all the
other dialogs)?

Is there something I'm overlooking? Accepting the first NOTIFY
seems much easier to implement than keeping track of dialogs that
will just need to be torn down.

/a

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Wednesday, November 21, 2001 2:00 PM
> To: 'Brian Stucker'; adam.roach; simple

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 26 Nov 2001 16:21:20 -0500

Is there something you are overlooking? I think so:

I think you are overlooking the possibility that there are multiple
subcription requests outstanding at the same time. And there are also
implicit subscriptions generated in some cases. And of course there are
also previously established subscriptions that continue to send
notifies. Some of these may fork, and when that happens, you want to
accept the stream of notifies from one of those forks.

So how do you sort out which notifies to accept (because they are from
distinct subscriptions or subsequent members of a series of
notifications from a previously accepted source), and which should be
refused because they they come from extra forks? According to
draft-ietf-sip-events-00:

     5.2.1. Correlation

     NOTIFY requests MUST contain the same Call-ID, local URI, and
     remote URI as the SUBSCRIBE request which ordered them. This is
     the same set of criteria that define a call leg.

I believe this implies that something akin to a call leg (aka Dialog) be
present.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 26 Nov 2001 18:10:30 -0500

I just noticed that I quoted from the obsolete draft-ietf-sip-events-00
rather than the newer draft-ietf-sip-events-01. The corresponding
section there is different in detail, but (I think) similar in intent:

     4.2.1. Correlation to dialogs, calls, and terminals

     ... Responses to SUBSCRIBE requests MUST contain a "tag" 
     parameter in the "To" header.

     The "tag" in the "To" header allows the subscriber to
     differentiate between NOTIFY requests from different clients in
     the case that the SUBSCRIBE request was forked.

You need to retain the tags from the subscribe in order to figure out
what subscription a particular notify belongs to.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 26 Nov 2001 18:33:39 -0500

[email-masked] wrote:
> 
> You might be surprised that, as the author of that draft, I was
> aware of that fact.
> 
> I'm sorry for not being sufficiently clear; I was trying to get
> the general idea across, not crafting language for a specification.
> 
> Of *course* I meant that you would accept the first NOTIFY
> that could reasonably correspond to the pending SUBSCRIBE as being
> the one dialog that gets established -- not just the first NOTIFY
> that happened to float down the wire.
> 
> /a

Sorry if I was pointing out the obvious.

But if you have to save state from the subscribe in order to decide what
notify to accept, and if, once you accept a notify, you are going to
establish a long lasting dialog and even refresh it periodically by
sending new subscribe requests, do you save anything by not establishing
the dialog as part of the initial subscription?

	Paul

---

From: [email-masked]
Date: Mon, 26 Nov 2001 18:11:15 -0600

> From: Paul Kyzivat [mailto:[email-masked]]
>

The issue being discussed is that the NOTIFY can arrive
before the response to the SUBSCRIBE. In fact, if the
SUBSCRIBE is forked, this is the most common scenario.

One of my early (strawman) proposals was to wait until the
SUBSCRIBE completed before responding to the NOTIFY. This
is really rather complex to implement correctly.

An improvement on this scheme was proposed by Jonathan:
accept the NOTIFYs that arrive while the SUBSCRIBE is
pending, and then un-subscribe to any that do not match
the SUBSCRIBE response.

After some analysis, I determined that this could
probably be simplified (from an implementation point of view)
further by simply accepting the first NOTIFY that could
reasonably belong to the pending SUBSCRIBE, and reject the
rest with 481s. The logic behind this simplification is
that the SUBSCRIBE response isn't special; it just represents
the response that happened to race to the forking proxy
the fastest. It's not "better" than any of the other
potential dialogs in any way.

Sorry for continuing this discussion on the SIMPLE list;
as Jonathan has pointed out a couple of times, this really
has turned more into a sip-events issue than a SIMPLE issue.

/a

---

From: [email-masked]
Date: Mon, 26 Nov 2001 17:24:38 -0600

/a

> Sent: Monday, November 26, 2001 5:11 PM
> To: [email-masked]; 'Jonathan Rosenberg'; 'Brian Stucker';
> simple
> Subject: Re: [Simple] 200 vs. 202
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 27 Nov 2001 08:39:35 -0500

OK. Thanks for the tutorial - I think I get it now.

But, all the complexity and loose ends suggests to me that there is
something fundamentally wrong with the mechanism here. As you say, this
is really an events issue, not a SIMPLE issue. 

	Paul