Subject: AW: [Simple] 200 vs. 202

From: Brazier Lachlan <[email-masked]>
Date: Thu, 22 Nov 2001 11:53:59 +0100

Hello,

no objections against these solutions. Anyway my first guess would have been
to send 1xx responses to he NOTIFY, until the resposne to the SUBSCRIBE
arrives. There's no need for an additional SUBSCRIBE then, for which I need
to keep the routing path established by the NOTIFY.

Comments

Lachlan

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
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple