Hi, route header preprocessing in sec 16.4 is related to loose routing specification.
ie, case 1. if the previous hop is strict router the message would have come as below. requri: <My rec-route inserted> routes: <next hop1>, <next hop2>, <next hop3>, <end point> after pre processing req uri: <end point> routes: <next hop1>, <next hop2>, <next hop3> ----- case 2. if the previous hop is loose router the message would have come as below. requri: <end point> routes: <My rec-route inserted>, <next hop1>, <next hop2>, <next hop3> after pre processing req uri: <end point> routes: <next hop1>, <next hop2>, <next hop3> ----- Please observe that "req-uri" after route preprocessing does not become the next hop destination. The next hop destination is still in the route set. Determining next hop through route set is specified under section "16.6 Request forwarding" under its subsections 6 and 7. Here is where topmost route header might become the req-uri, based on whether the next hop is strict or loose. But in between 16.4 and 16.6 comes 16.5, which should also be followed by a proxy. My question is that many steps performed in this section (16.5) may be "exempted" in cases where the message still has route-set as in examples above even after executing step 16.4 . And I would like to know why we have not "exempted" 16.5 steps for this case? In 16.5 we continue to process req-URI, which need not have been done. I assume that there could be some reason behind the same. Would like to know the same. hope my doubt is clear. regards, Shrinivas Shetti "Ravi Shiroor" <[EMAIL PROTECTED]> on 12/02/2002 11:31:57 AM To: Shrinivas Shetti/HSSBLR cc: [EMAIL PROTECTED] Subject: RE: [Sip-implementors] 16.5 Determining Request Targets 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 _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
