You should not need to share transaction state in order for clustering to work with transaction stateful proxies. The ACK is a separate transaction; therefore, there is no transaction state to be shared. The ACK should be able to be handled by any proxy in the cluster.
Cheers, Charles > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Kundan Singh > Sent: Friday, March 17, 2006 12:23 PM > To: leslie wang > Cc: [email protected] > Subject: Re: [Sip-implementors] SIP cluster questions > > > Hi Expert > > > > SIP proxys can be groupped to work as a cluster. I have > some questions on > > it: > > 1. Is there any RFC to describe the work flow for it? > > 2. The cluster will use domain name to communicate other > proxy. When proxy > > send an INVITE messge to cluster with a IP address A, but > later ACK message > > use another IP address B. The call will fail. So how can > cluster avoid such > > a failure. > > Please take a look at > http://www1.cs.columbia.edu/~kns10/papers/sipload.pdf > (section 4.2 and > 4.5) for our cluster which uses Hash(user-id) to locate the > proxy; thus > all requests for one user/call will always go to the same > second stage > proxy block. For the first stage, which is *stateless*, it doesn't > matter which proxy handles the ACK. > > For transaction stateful proxies with single stage cluster > (similar to > traditional web clustering), it becomes difficult to share > state as you > mentioned/hinted. But this is not impossible; e.g., the transaction > state may be stored in the backend replicated database. > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
