> 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.
Ideally, ACK for a *non-2xx* final response should be sent to the same host that received the initial INVITE, as it affects the original transaction state-machine of INVITE (Fig.7 of RFC 3261 and Sec. 17). But for 2xx responses, ACK is indeed a separate transaction that may also be sent end-to-end without even going through the proxy. Moreover, sharing of transaction state in the cluster is also needed for handling retransmissions. > > 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
