Re: [Sip] WGLC for draft-ietf-sip-subnot-etags-01

[Aki Niemi <[e-mail]>]

On ti, 2008-02-26 at 16:31 -0500, ext [e-mail] wrote:
>    The subscriber really need not know. It is the notifier's responsibility
>    to keep the entity-tags unique across all of the insanely difficult SIP
>    routing that it may deploy in front of it.
> 
> The notifier cannot know what routing is in front of it, because it
> cannot know what URIs might route to it.

Then that's bad. How does the notifier then know which PIDF to pick in
presence subscriptions?

<snip>
>    > It is not clear that there is any solution to these problems, and we
>    > may only be able to document that the subscriber is responsible for
>    > assuring that successive subscription requests are delivered to the
>    > same resource.
> 
>    This isn't the subscriber's problem. Moreover, I really doubt that it is
>    even feasible to build a system where a new subscription sent to the
>    same AoR will randomly reach a different notifier instance that is in no
>    way synchronized (as in state, entity-tag values, etc) with the other
>    instances.
> 
> There is no requirement that the SUBSCRIBE was sent to an "AoR" (even
> if that term was well-defined).
> 
> It is trivial to build a system where a new subscription could go to a
> place that is much different than a previous subscription:
> 
> sip:a.example.com forwards to sip:b.example.com - I think of this as
> "my call center".  What I don't know is:
> 
> sip:b.example.com uses time-of-day-based routing to forward to either
> sip:c1.example.com or sip:c2.example.com - My company has outsourced
> the call center to two different companies in in two different places,
> one for the day shift and one for the night shift.
> 
> sip:c1.example.com parallel-forks to sip:d1a.example.com and
> sip:d1b.example.com - The day-shift call center workers are in several
> locations.
> 
> sip:c2.example.com parallel-forks to sip:d2a.example.com and
> sip:d2b.example.com - And so are the night-shift call center workers.
> 
> OK, now I send "SUBSCRIBE sip:a.example.com".  Unless I know the
> details of the above routing, there's no way for me to know that the
> routing changes with time.  Similarly, there's no way for the
> notifiers at d1a.example.com, d1b.example.com, d2a.example.com, and
> d2a.example.com to even know what notifiers they *might* have to
> synchronize with.

I agree this kind of setup presents a problem. But I also think that
what we're dealing with here is not that different from the web world.
There are a lot of load balancing schemes that can be used with HTTP,
which result in a GET ending up in different data centers in different
parts of the world at different times.

What's important to note there is that if the service that is accessed
via this GET needs sessions and gives out cookies, then the backend
system needs to be synchronized. Otherwise, the servers will be unaware
of each others cookies, and the service won't work correctly.

Similarly, the backend to the SIP notifiers needs a synchronized
backend, otherwise, subnot-etags won't work.  Naturally, the etags just
like cookies can be constructed in such a way that they contain the
necessary state.

Cheers,
Aki


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