From: Aki Niemi <[EMAIL PROTECTED]> On pe, 2008-02-29 at 22:08 -0500, ext [EMAIL PROTECTED] 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 [email protected] 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 [EMAIL PROTECTED] 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, [EMAIL PROTECTED] This service routes all requests based on time-of-day to either my desk phone at my job, [EMAIL PROTECTED], or my cell phone, [EMAIL PROTECTED] As expected, a presence subscription (or any other subscription) sent to [EMAIL PROTECTED] 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 [EMAIL PROTECTED], some times it will go to the UAS at [EMAIL PROTECTED], and sometimes to the UAS at [EMAIL PROTECTED] (Or to servers implementing the events on their behalf.) The entity-tags chosen by [EMAIL PROTECTED] and by [EMAIL PROTECTED] 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 [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
