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). > > 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
