Comments inline... Thanks, Nataraju A B
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:sip-implementors- > [EMAIL PROTECTED] On Behalf Of Alf Salte > Sent: Thursday, September 28, 2006 5:03 PM > To: Bob Penfield > Cc: [EMAIL PROTECTED]; Sip- > [EMAIL PROTECTED] > Subject: Re: [Sip-implementors] query regarding parallel forking > > 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. > [ABN] even this is mentioned in RFC, CANCEL all the transient legs upon 2xx/6xx You can refer sec 3261 sec "16.7 Response Processing" 5. Check response for forwarding It means you can decide to cancel pending transactions once you received the 2xx/6xx. It's a configuration @ proxy, so that you would receive the final response on other legs as part of the RC. And finally the best response selection would decide which one to finally send it back to UAC. > > > > > > > > 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 _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
