Subject: RE: [Simple] Reacting to multiple sources of presence data (was 2 00v202)

From: Robert Sparks <[email-masked]>
Date: Tue, 13 Nov 2001 10:49:17 -0500

<snip>
> > > Another problem I pointed out is that the 2xx which was
> > > "chosen by the proxy mesh" may be a 202, and later be
> > > rejected, whereas one of the 2xx which was not chosen, is
> > > later accepted. However, its NOTIFY is discarded.
> >
> > I don't understand this scenario yet. What does it mean to be
> > later rejected or accepted?
> 
> The scenario is subscription pending subject to 
> authorisation, which may
> result in rejection or acceptance.

Thanks - that was enough to jog my memory.

<snip>
> This problem exists in a different form in case 1, where, I 
> return a fake
> 200 with my own tag in the 200. You will never get a NOTIFY 

Ok, we'll make sure to track this variant of DoS and document
it if it exists in whatever solution we end up with.

> These issues have also been discussed on the SIPPING list, my proposed
> solution was to add an additional header to the NOTIFY that indicated
> subscription state. This helps with the 200 vs 202 issue and 
> has an added
> bonus. If the state allows unauthenticated the subscription 
> can be reissued
> to the notifier directly (using the route set) and individual 
> subscriptions
> authenticated regardless of other notifiers returning 2xx.

Interesting - my apologies for not having absorbed that thread
yet. There are some folks on this list that don't also subscribe
to sipping - if there's more to your proposal than what you've
summarized above, please elaborate.
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: "James Undery" <[email-masked]>
Date: Tue, 13 Nov 2001 16:31:18 -0000

<snip>

> summarized above, please elaborate.

Basically the problem is to emulate INVITE behaviour (without breaking
rfc2543), by that I mean be able to handle multiple subscriptions even
though only a single 2xx response is recieved. The problem is multiple PUAs
may respond with a mixture of 200 and 202 responses, yet the subscriber only
recieves a single 2xx response. My suggestion was to include subscription
state (Via a header) in the NOTIFY that says if subscription is pending or
authorised.

In a rambling post I also thought (whilst posting) that this header could
also be used to solve the case when a 401 is generated by the PUA. i.e. give
the header an additional un-authenticated state. This would mean that
immediate NOTIFYs would be generated for 2xxs and optionally (PUA dependent)
401s. On receiving a NOTIFY with an un-authenticated state the subscriber
could reSUBSCRIBE to the PUA even if it had received 2xxs from other
locations. (For a use for this think about sip:[email-masked] forking to
sip:10.0.0.1 and sip:[email-masked] where "mobile.phone" is a different
domain to "ubiquity.net" and requires authentication for presence where
ubiquity do not.)

However, there are a number of problems though, firstly if the PUA did this
it would be generating state for un-authenticated requests; secondly I'd
like to see the rules for reSUBSCRIBEs change to allow them to follow the
route set for efficiency.

Anyway even though I am not totally convinced myself, it might be worth
considering as an optional feature.

James