From: Fredrik Thulin <[EMAIL PROTECTED]> On Monday 04 September 2006 20:56, [EMAIL PROTECTED] wrote: > From: Fredrik Thulin <[EMAIL PROTECTED]> > > How is deactivating subscriptions as per RFC3265 supposed to > actually be possible? > > When the UACs send their new SUBSCRIBEs, how would it get to "the > other node in the server cluster"?
Through some kind of DNS mechanism, such as RFC3263 in my case. > There seem to be two possibilities -- One is that one domain name has > multiple addresses, the addresses of the set of nodes. In that case, > once a node has decided to go off-line, it should not respond to > requests that it receives, and not accept new TCP connections. So > any agent that attempts to send a request to a node going off-line > will see the request time-out, and the agent will eventually retry > with another address for the same domain name. Right - this makes migration from one node to another (in case you have exactly two, and bring one down) take 32 seconds to complete even though there was a way to instruct the clients to retry immediately. If you use DNS records for one host name for multiplexing the nodes, that's the best you can do, as RFC 3263 steps you from one address to another based on non-response to requests. If the delays are a problem, you'll have to choose another mechanism. (Though a really good implementation will keep a cache of which addresses are answering and which addresses are not, and will avoid choosing non-responsive addresses first, which means that you only have to suffer the delay once for each change-over.) > A better method is to have some sort of forking proxy (either in a > proxy or the UAC), whereby the To address of the SUBSCRIBE sent by > the UAC is forked to the multiple nodes. Then a node that is going > off-line can respond to all new requests with 503 (Service > Unavailable), and the forking proxy will try the other nodes. I believe this would create another problem. The SUBSCRIBEs I'm talking about are for example presence subscriptions. If I fork the SUBSCRIBE you send for my presence to two presence servers, you would receive double notifications every time my presence changes. Having the node being shut down respond with 503 to all new requests it receives seems like a good idea though. Thanks for your response. If you want to use a SIP mechanism, the right way is probably to have the UAC effectively contain a proxy which parallel-forks the SUBSCRIBE to the alterantive destinations. If it gets multiple 200 responses, the UAC/proxy will then synthesize SUBSCRIBEs with expires=0 to terminate all but one. That gives the UAC an immediate response if any node is responsive, and only maintains one subscription at one node for the UAC. Of course, there's extra work when the UAC first subscribes, but that's transient. The configuration question is how does the (integral) proxy translate the "address of record" that the UAC (hypothetically) inserts in its original SUBSCRIBE into the list of targets that are used in the over-the-wire set of SUBSCRIBEs? Having to program in an AOR translation seems like a messy extra step. I think a workable alternative is "for the domain name in the SUBSCRIBE, the target set is the set of IP addresses that DNS provides for that domain name". That should be within what RFC 3261 permits, it's configured by DNS in the way one expects, and it does what you want. And thought it isn't *required* by RFC 3261, the nodes should be prepared to service requests whose request-URIs contain their IP addresses, so it should take no unusual configuration in the nodes. Dale _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
