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

[[e-mail]]

   From: Aki Niemi <[e-mail]>

   On pe, 2008-02-29 at 22:08 -0500, ext [e-mail] wrote:
   >    Then that's bad. How does the notifier then know which PIDF to pick in
   >    presence subscriptions?
   > 
   > Especially if it's not a presence subscription.  But seriously, is
   > this proposal confined to presence events?  I see no such text.

   Of course it is not. But clearly presence won't work correctly, if the
   notifier doesn't know which URIs route to it, i.e., which resources it
   is responsible for. I assume this to be the case for most applications
   of SIP events. Can you give an example of a currently specified event
   package that doesn't require this?

In all the cases I'm aware of, the notifier determines the resource in
question by examining the request-URI.  This certainly seems to be the
case when phones are generating dialog events.  A solution to the
"proxy loose-routing problem" would improve the results by giving the
notifier more information on the intentions of the subscriber.

   > In general, a SUBSCRIBE will fork, and the subscriber presumably knows
   > how it wants to integrate the events it will receive from the various
   > subscriptions, based on the semantics of its situation.

   Then presumably the semantics of the situation will also describe how
   entity-tags are handled? Especially if they are not all of the same
   value in the different dialogs.

The problem isn't combining entity-tags from different subscriptions
created by a single SUBSCRIBE, since the NOTIFYs can be differentiated
by which subscription they are part of.  The problem is when
establishing a later subscription, how to correlate (or not) the
entity-tags from the later subscription with those from the earlier
subscription.

Unfortunately, the safe assumption is to consider the entity-tags to
be non-matching between the different subscriptions, but that violates
the requirement for which the mechanism was defined -- the ability to
avoid re-sending values in later subscriptions that were already sent
in earlier subscriptions.

   >    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.
   > 
   > There's a hidden philosophical problem:  People think of SIP routing
   > as being like PSTN routing, where the caller sends the call to a
   > number which designates one destination, or at least, a single device
   > which has total knowledge of a small number of possible destinations.
   > The caller knows the globally-recongized *name* of the
   > destination-group, and every destination knows of and is coordinated
   > with *every other possible destination*.
   > 
   > Your HTTP model is similar; you assume the request will reach one of a
   > set of servers that are co-adminstered.
   > 
   > But the reality is that SIP routing can be like sending e-mail to a
   > mailing list -- the sender doesn't know what the possible destinations
   > are, and each destination doesn't know what all the destinations are
   > either, because some of the routing can be done by agents that are not
   > co-administered with either the sender or the destination.

   What you are saying is similar to having [e-mail] route to multiple
   mailman instances, each of which has a different set of subscribed email
   addresses. But that's not how mailing lists work either.

What is interesting is the case where there is no central server that
knows all of the destinations, which implies that the destinations do
not all know each other.

In the case of mailing lists, one such structure would be for everyone
at my company to subscribe to a local redistribution, and the local
redistributor would have a single subscription to [e-mail].  But a
friend of mine also wants the mail, so I program my workstation to
forward to him a copy of all the messages I'm sent.

A more realistic case would be along these lines:

I subscribe to a virtual phone service that provides me with an AOR,
[e-mail].  This service routes all requests based on time-of-day
to either my desk phone at my job, [e-mail], or my cell phone,
[e-mail].

As expected, a presence subscription (or any other subscription) sent
to [e-mail] does the right thing, it routes to the phone that I am
present at at that time.  (There's a bit of a problem with
subscriptions that span the cutover between the two desitnations.)

If some UAC wants to do periodic polling-type SUBSCRIBEs of
[e-mail], some times it will go to the UAS at [e-mail], and
sometimes to the UAS at [e-mail].  (Or to servers implementing the
events on their behalf.)

The entity-tags chosen by [e-mail] and by [e-mail] are (by
hypothesis) uncoordinated with each other, and there is some risk that
the previous value from one server will be different from the current
value from the other server, but the two will happen to assign the
same entity-tags to those particular values.

Dale
_______________________________________________
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