Hi Kundan, Proxies do not retransmit 200s, and I do not see why the handling of a retransmitted 200 or a retransmitted ACK requires any sharing of transaction state. Perhaps you could use shared transaction state to allow you to more efficiently send retransmitted ACKs to alternate destinations, but that is more of an optimization than a necessity. I think you need to send the ACK to a destination identified by Record-Route added by the proxy in the 200 response. If that resolved to the same proxy that handled the INVITE, then send the ACK to it. If it resolve to some other proxy, send the ACK to that other proxy.
Cheers, Charles > -----Original Message----- > From: Kundan Singh [mailto:[EMAIL PROTECTED] > Sent: Monday, March 20, 2006 7:56 PM > To: Charles Eckel (eckelcu) > Cc: leslie wang; [email protected] > Subject: Re: [Sip-implementors] SIP cluster questions > > > > 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
