On Wed, 2002-12-04 at 08:16, [EMAIL PROTECTED] wrote: > > > Hi Robert, > > Following scenario that you have explained, will work only for > the initial INVITE which will setup record-routed path. > Note that we dont even have route-set here!!!
The initial request can include a non-empty Route header field. Look at draft-ietf-sip-scvrtdisco-02.txt for an example of one way the initiating endpoint would get information to place in such a Route header field. > > In subsequent transactions of a call where request is rec-routed > with route headers, the req-URI will be the contact header specified > by the other client. Yes. > > And the contact header should ideally not match to proxy's domain. > It shall be the user@direct IP address or so. Then only 16.5 will work > comfirtably to move to steps 16.6!!! And it will unless the endpoint does something out of spec. > > Consider the case where contact header matches with the domain > that proxy owns. Then this has negative effects on what 16.5 specifies!!! > > An already established routeset is being ignored and proxy is doing > registrar lookup etc!!! You are still confounding remote target and route set. If this scenario were exercised, the routeset would _not_ get ignored, but the request might be retargeted. The remote target URI might change, but everything remaining on the route set _will_ be visited. Again, an endpoint will have to behave out of spec to exercise this case. The scenario to focus on instead is an initial request that contains a non-empty Route header field. > > please clarify, > with regards, > Shrinivas Shetti > Hughes Software Systems Ltd. > > > > > > Robert Sparks <[EMAIL PROTECTED]> on 12/03/2002 08:38:03 PM > > To: Shrinivas Shetti/HSSBLR > cc: Ravi Shiroor <[EMAIL PROTECTED]>, > [EMAIL PROTECTED] > > Subject: RE: [Sip-implementors] 16.5 Determining Request Targets > > > > > Ah - now I understand what you're looking at. > > The case you need to cover is preloaded routes in a dialog > creating request; an initial INVITE for example. You might > receive a request with a URI you own in the Request-URI > (so you need to retarget the request, perhaps even forking it) > but the Route headers are not yet exhausted (so each outbound > request will follow the remainder of the route). > > RjS > > > On Tue, 2002-12-03 at 00:40, [EMAIL PROTECTED] wrote: > > > > > > Hi Robert, > > > > Thanks a lot for your clarification. > > I understand that it is not big effort verifying if the reqURI is in > > proxy's domain. > > > > I was thinking if there is any specific reason that we do this > > check and put it as target URI (there could be some application/ > > implementation specific reasons thought about). > > Please enlighten me if so. > > > > I am just thinking if we may simply ignore the above and > > move to sec 16.6 when route count > 0, > > > > b'cos it is still some optimization when we look for performance > > enhancements, as it involves multiple comparisons over the > > req-URI address-spec, since the proxy may be responsible > > for multiple host-names/ip-addresses. > > > > regards, > > Shrinivas Shetti > > > > > > > > > > > > Robert Sparks <[EMAIL PROTECTED]> on 12/02/2002 10:07:38 PM > > > > To: Shrinivas Shetti/HSSBLR > > cc: Ravi Shiroor <[EMAIL PROTECTED]>, > > [EMAIL PROTECTED] > > > > Subject: RE: [Sip-implementors] 16.5 Determining Request Targets > > > > > > > > > > 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 > > > > > > > _______________________________________________ > 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
