the functionality of Route Header Preprocessing *is* to decide if the route header has to be consluted (by checking if it requested to be in the path or not), and then, if needed replace the current Request-URI with the next hop URI, as indicated by the Route header.
once this (16.4)is done, the proxy can proceed (to 16.5)as if it received the request with the next hop correctly set in the Request-URI. HTH, ravi. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of > [EMAIL PROTECTED] > Sent: Monday, December 02, 2002 11:03 AM > To: Ravi Shiroor > Cc: [EMAIL PROTECTED] > Subject: RE: [Sip-implementors] 16.5 Determining Request Targets > > > > > section 16.4 only explains the route header pre processing. > It doesnt say how we arrive deciding target URI for resolving next hop. > It is the section 16.5 which addresses same. > > but this section assumes all operations over request-URI alone, "with out" > considering > existence of route set, where you may have to bypass many operations > defined under > this section. > > Why is it so? does it mean that proxy undergoes all steps explained sec > 16.5 > despite knowing that route set is present. > Is there some reason why section 16.5 doesnt refer to route set existence? > > Or is it OK if section 16.5 is bypassed when route-set is present and > proceed on > topmost route as target? > > regards, > Shetti > > > > > "Ravi Shiroor" <[EMAIL PROTECTED]> on 12/02/2002 10:24:20 AM > > To: Shrinivas Shetti/HSSBLR, [EMAIL PROTECTED] > cc: > > Subject: RE: [Sip-implementors] 16.5 Determining Request Targets > > > > > section 16.4, Route Information Preprocessing, takes care of this. > > regards, > ravi. > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of > > [EMAIL PROTECTED] > > Sent: Saturday, November 30, 2002 4:55 PM > > To: [EMAIL PROTECTED] > > Subject: [Sip-implementors] 16.5 Determining Request Targets > > > > > > > > > > Hi, > > Section 16.5 of RFC explains determining targets for a request. > > This section doesnot consider existence of route header set in > > the message. > > > > If the route headers are present, then the "top-most route will be > > the target" instead of the request-URI. > > > > Therefore we need not go for processing the request-URI or > > go for determining contact set or DNS resolution for the request-URI. > > > > Please clarify. > > > > regards, > > Shrinivas Shetti > > Hughes Software Systems Ltd. > > http://www.hssworld.com/ > > > > > > > > > > > > > > > > This message is proprietary to Hughes Software Systems Limited > > (HSS) 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. HSS 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] > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > > _______________________________________________ > Sip-implementors mailing list > [EMAIL PROTECTED] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > > _______________________________________________ > Sip-implementors mailing list > [EMAIL PROTECTED] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
