Hi,
I didn't get any response for this.
There are 2 cases I can think of.
1. The route-header is a pre-existing route added by UAC during dialog
initiation
(So this is a new INVITE, To tag won't be present).
Should we do location lookup here? since the end UAC is not yet
identified.
2. The route-header is formed from the RR headers. (So this is a reinvite,
To tag
would be present.). We definitely don't require to do a location lookup
here.
Since the end-to-end route is already established.
As I said, in my earlier mail, I really do think we require change in the
RFC
section 16.5 Determining Request Targets.
Looking for some response.
Thanks
Sachin
----- Original Message -----
From: "Sachin Shenoy" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; "Sip-Implementors"
<[EMAIL PROTECTED]>
Sent: Thursday, August 29, 2002 9:51 PM
Subject: Re: [Sip-implementors] Target set caluclation & Route header
> Thanks for your pointers. I still have some problem.
>
> Even though the request has route-header proxy does a location look up.
> (According to RFC this is not ruled out explicitly). The location lookup
> returns multiple targets. Now the request is forwarded to multiple
> request-uri but to the same host pointed by the route-header.
>
> How do we resolve this? If we already know that the request should go
> to a specific host given in the route-header field, why do we have to do a
> location search?
>
> There is one place in RFC that mentions a no-op location lookup, where
> the same request-uri is returned.
>
> Section 16.5
> "For example, a trivial location service is a "no-op", where the
> target URI is equal to the incoming request URI. The request is sent
> to a specific next hop proxy for further processing"
>
> Should I be using this kind of no-op lookup, when route-header is present?
>
> Hope I haven't missed something here.
>
> Thanks
> Sachin
>
>
> ----- Original Message -----
> From: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
> <[EMAIL PROTECTED]>
> Sent: Thursday, August 29, 2002 7:59 PM
> Subject: RE: [Sip-implementors] Target set caluclation & Route header
>
>
> > Check section 16.6 items 2 and 6.
> >
> > Regards,
> > Hisham
> >
> > > -----Original Message-----
> > > From: ext Sachin Shenoy [mailto:[EMAIL PROTECTED]]
> > > Sent: Thursday, August 29, 2002 4:03 PM
> > > To: Sp.Raja; Sip-Implementors
> > > Subject: Re: [Sip-implementors] Target set caluclation & Route header
> > >
> > >
> > >
> > > Do you think following lines (lines within #) have to be added within
> > > RFC section 16.5 Determining Request Targets
> > >
> > >
> > > "If the domain of the Request-URI indicates a domain this element is
> > > not responsible for, the Request-URI MUST be placed into the target
> > > set as the only target, and the element MUST proceed to the task of
> > > Request Forwarding (Section 16.6).
> > >
> > > There are many circumstances in which a proxy might receive a
> > > request for a domain it is not responsible for. A
> > > firewall proxy
> > > handling outgoing calls (the way HTTP proxies handle outgoing
> > > requests) is an example of where this is likely to occur."
> > >
> > > ####################################
> > > # Addition suggested?!
> > > If the route-header is present, the Request-URI MUST be
> > > placed into the
> > > target set as the only target, and the element MUST proceed
> > > to the task of
> > > Request Forwarding (Section 16.6).
> > > # End of Addition.
> > > #####################################
> > >
> > > "If the target set for the request has not been predetermined as
> > > described above, this implies that the element is
> > > responsible for the
> > > domain in the Request-URI, and the element MAY use
> > > whatever mechanism
> > > it desires to determine where to send the request..."
> > >
> > > Thanks
> > > Sachin
> > >
> > >
> > > ----- Original Message -----
> > > From: "Sp.Raja" <[EMAIL PROTECTED]>
> > > To: "Sachin Shenoy" <[EMAIL PROTECTED]>
> > > Cc: "Sip-Implementors" <[EMAIL PROTECTED]>
> > > Sent: Thursday, August 29, 2002 6:04 PM
> > > Subject: RE: [Sip-implementors] Target set caluclation & Route header
> > >
> > >
> > > > Even though it is not explicitly stated,
> > > >
> > > > RFC 3261 Sec 20.34 reads
> > > >
> > > > The Route header field is used to force routing for a
> > > request through
> > > >
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > the listed set of proxies. Examples of the use of the Route header
> > > > ~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > field are in Section 16.12.1.
> > > >
> > > > -Sp.Raja
> > > >
> > > > -----Original Message-----
> > > > From: [EMAIL PROTECTED]
> > > > [mailto:[EMAIL PROTECTED]]On Behalf Of
> > > Sachin Shenoy
> > > > Sent: Thursday, 29 August 2002 6:03 PM
> > > > To: Sp.Raja
> > > > Cc: Sip-Implementors
> > > > Subject: Re: [Sip-implementors] Target set caluclation &
> > > Route header
> > > >
> > > >
> > > > Thanks for you reply.
> > > >
> > > > I couldn't find mention of this explicitly anywhere in the
> > > RFC. Can you
> > > > please give me any pointer to section within RFC which
> > > deals with this.
> > > >
> > > > I expected section 16.5 Determining Request Targets, to
> > > explictly mention
> > > > that if route is present then it would be placed as the
> > > only entry within
> > > > the
> > > > target set.
> > > >
> > > > Thanks
> > > > Sachin
> > > >
> > > >
> > > > comments inline
> > > > -----Original Message-----
> > > > From: [EMAIL PROTECTED]
> > > > [mailto:[EMAIL PROTECTED]]On Behalf Of
> > > Sachin Shenoy
> > > > Sent: Thursday, 29 August 2002 5:33 PM
> > > > To: Sip-Implementors
> > > > Subject: [Sip-implementors] Target set caluclation & Route header
> > > >
> > > >
> > > > Hi,
> > > >
> > > > According to the RFC, If the domain of the request-uri is of proxies
> > > domain
> > > > then proxy is responsible for routing the request. What
> > > would happen if
> > > > the domain of the request URI is proxies domain, but the
> > > request also
> > > > contains route header?
> > > >
> > > > What should proxy do? Forward the request to the location
> > > in the route
> > > > header? Or do a locations search and forward to the
> > > locations returned
> > > > from the search.
> > > > [Raja] First preference always goes to the Route
> > > irrespective of whether
> > > the
> > > > proxy is responsible for the domain or not
> > > >
> > > > Thanks
> > > > Sachin
> > >
> > > _______________________________________________
> > > 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
