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. > 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. /Fredrik _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
