I think the reason why the Request-URI is replaced at the proxy, which
is responsible for the domain, is considering the scenarios when the
end point may be inside a NAT/FW. The Domain Proxy maps the URI
exposed to external world to a URI that is known inside the network.
For example [EMAIL PROTECTED] will be mapped to
[EMAIL PROTECTED]
or [EMAIL PROTECTED]
Other proxies inside the network may not have capability to do it.
After replacing the URI, the proxy can either do some more tinkering as
sprecified by the NAT/FW traversal drafts and forward directly
to the target. (in this case there are be no more entries in the Route
header);
-------------- -----------
| Domain Proxy|---------->|Joe's UAS|
-------------- -----------
OR, there may be another proxy sitting inside the network which
does the needful for NAT/FW traversal, so it will be the next hop.
(as specified in the Route header). It may also be possible that
there are multi layered FW/NAT inside aCompany itself..
-------------- ----------------------- -----
| Domain Proxy|------>|FW/NAT traversal proxy|---->|Joe|
-------------- ----------------------- -----
regards,
ravi.
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of
> [EMAIL PROTECTED]
> Sent: Tuesday, December 03, 2002 12:11 PM
> To: Robert Sparks
> Cc: Ravi Shiroor; [EMAIL PROTECTED]
> Subject: RE: [Sip-implementors] 16.5 Determining Request Targets
>
>
>
>
> 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
