Shrinivas - For the cases you are considering, one of the first two tests of 16.5 will move you to 16.6, so there isn't a great deal of burden being added.
I think your question is "why doesn't the spec say that if there is a non-empty route header field, just send to that topmost element and be done with it?". Effectively it does, in the second condition of 16.5. The remote target at this point will be the contact provided by the far endpoint and will not be a URI for which this proxy is responsible. RjS On Mon, 2002-12-02 at 04:49, [EMAIL PROTECTED] wrote: > > > 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 _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
