On Thu, 2006-09-28 at 07:09 -0400, Bob Penfield wrote: > inline. > ----- Original Message ----- > From: "Alf Salte" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]>; > <[email protected]> > Sent: Thursday, September 28, 2006 5:45 AM > Subject: Re: [Sip-implementors] query regarding parallel forking > > > > This is not specified in any RFC. It is up to the proxy how to handle > > this. > > This is not correct. RFC 3261 requires that a proxy send all 2xx responses > to the UAC (See section 16.7). Upon receipt of the first 2xx response, the > proxy sends a CANCEL on all other branches of the fork (that have not > received a final response). However, this does not prevent another UAS from > sending a 200-OK (in the case where the CANCEL does not reach the UAS in > time).
Yes, you are correct. I was thinking of the fact that the proxy can choose whether to send CANCEL or not and that is not specified in the RFC. However, as you say, if it chooses to send CANCEL but the CANCEL do not reach the UAS in time and so the branch still send a 2xx response the proxy MUST forward that 2xx response as well and thus the UAC receives multiple 2xx responses. My point was that whether or not a proxy chooses to send CANCEL to other brances in this situation - is left to the implementation of the proxy and is not specified in the RFC. > > > > > There are essentially two models: > > > > 1. Each 200 OK is returned to caller and caller creates and maintains a > > dialog for each of them. The proxy two have to create and maintain a > > dialog for each of them in this case (a forking proxy is never a > > stateless proxy AFAIK). > > A transaction stateful proxy does not maintain dialog state. A proxy that > does maintain dialog state would have to add itself to the Record-Route so > that it saw subsequent in-dialog requests, including the BYE (or terminating > NOTIFY in the case of subscriptions). > > A forking proxy MUST be transaction stateful. > > > > > 2. The first (one of them is received before the other unless you have > > true paralell computing and even then one of them is faster than the > > other at grabbing a mutex or other synchronizing device which you must > > use for them to update the state of the transaction which is shared > > among the threads). The first 200 OK is then returned to the caller and > > all later 200 OK's are dropped (not transmitted to caller) and a ACK > > followed by BYE is sent to them. Any other forks which has not yet sent > > a final response should have a CANCEL sent to them to cancel the INVITE > > so that only the fork that sent the first 200 OK is accepted and > > returned to caller. > > > > The second model forks but shield the forking to the caller so that > > caller only have to have one dialog - whoever is the first to respond. > > The first model creates and maintains a dialog for each of the > > responses. > > > > For example if you make a call and the call goes to a person's work > > phone and his home phone then if someone at work lift the phone to > > respond and the person at home also do the same then whoever is first > > get the call in second model and both persons get the call in the first > > model. > > > > Another example can be when you make a call to some technical service or > > other service line where a number of people is connected to it and the > > first one to respond gets the call. All the others should be > > disconnected. In this case the second model should be used exclusively. > > > > It is perfectly valid to implement a proxy so that only model 2 is used. > > Again, RFC 3261 requires the proxy to send all 2xx responses to the UAC, so > this is not valid. > > > I don't think it makes much sense to have a proxy where only model 1 is > > used but it does make sense to have a proxy where a configuration may > > say that this address uses model 1 and another address uses model 2. > > > > Model 1 is of course simpler to implement from a proxy point of view but > > Model 2 is the one that makes most sense in most cases. Typically if you > > have both a regular phone and a cell phone and the fork goes to both you > > will typically respond in one of them and not respond in both and so the > > problem of both sending 200 OK is rarely a problem. > > > > If your regular phone is connected to some answering machine it might > > happen though and in that case it would make sense to configure the > > proxy so that if you get response from both, drop the home phone (which > > is answering machine) and keep the cell phone (which is a real person > > responding) or vice versa if the cell phone is connected to some > > automatic response system such as an answering machine. > > > > It is in other words very much a configuration question rather than a > > fixed answer to all cases. > > > > Alf > > > > On Thu, 2006-09-28 at 14:18 +0530, > > [EMAIL PROTECTED] wrote: > >> Hi, > >> > >> When parallel forking is enabled at proxy and proxy fork INVITE request > >> to n no. of registered contact .In case if proxy receives 200 OK from any > >> two contact simaltaneously, then what shall be the proxy behaviour , > >> whether it forwards both the 200 OK to UAC or it drops one of the 200 > >> OK > >> response. > >> > >> > >> > >> > >> > >> > >> "The fragrance of flowers spreads only in the direction of the wind. But > >> the goodness of a person spreads in all direction." > >> > >> > >> > >> Thanks & regards > >> Sanjiv kumar Jaiswal > >> Software Engineer > >> Flextronics Software System > >> Emp ID-8494 > >> TEL-918051069164 > >> MOB-919886189960 > >> > >> *********************** FSS-Private *********************** > >> "DISCLAIMER: This message is proprietary to Flextronics Software Systems > >> (FSS) and is intended solely for the use of > >> the individual to whom it is addressed. It may contain privileged or > >> confidential information and should not be > >> circulated or used for any purpose other than for what it is intended. If > >> you have received this message in error, > >> please notify the originator immediately. If you are not the intended > >> recipient, you are notified that you are strictly > >> prohibited from using, copying, altering, or disclosing the contents of > >> this message. FSS accepts no responsibility for > >> loss or damage arising from the use of the information transmitted by > >> this email including damage from virus." > >> _______________________________________________ > >> 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 > > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
