This is not specified in any RFC. It is up to the proxy how to handle this.
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). 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. 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
