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!!!
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.
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!!!
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!!!
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
