Subject: RE: [Sipping] How to Get Outbound Services from A Non-Local Proxy?

From: "Neil Deason" <[email-masked]>
Date: Wed, 1 Aug 2001 15:39:18 +0100

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> Gonzalo Camarillo
> Sent: 31 July 2001 17:13
> To: Cullen Jennings
> Cc: James Undery; [email-masked]; Sipping (E-mail)
> Subject: Re: [Sipping] How to Get Outbound Services from A Non-Local
> Proxy?
>
>
> Hello,
>
> > This seems like an idea that is fairly consistent with the
> existing standard
> > and implementations. What's wrong with this that is causing
> people to be
> > keener on the other solutions?
>
> A proxy receiving a request with a Route header will
> typically send the
> request directly to the address contained in the Route
> header. However,
> this is not what you want to happen.
>
> For instance, in order to provide me with services, when I am in my
> office all my outgoing requests traverse 3 proxies (application
> servers). If I send an INVITE with request URI:
>
> sip:[email-masked]
>
> I want it to traverse my 3 local proxies, then go to my home proxy and
> then to bobhome.com
>
> If I send the INVITE with a Route header, my first local
> proxy will send
> the INVITE to myhome.com directly.
>
> That's the difference between strict and loose source routing.

I don't think this equation between escaped URLs = loose
and pre-loaded Route = strict is necessarily correct.
I note the bis spec now says that pre-loaded route headers
are the equivalent to strict source routing in IP but I
don't entirely agree with that analysis. For one thing
DNS incapable clients ignore record route to send to a
local out bound proxy. I think there are going to be times
when a proxy may want to have this flexibility over
routing too, allowing outbound proxies for proxies.
(This just came up on the SIP list under 'RE: [Sip]
proxy routing of a request' for those trying to keep up
with mult lists).

Even in this example the first two proxies must always know
that they are not to route according to normal rules
anyway or they would just go straight to the myhome.com
proxy via an SRV record.

This example also re-asserts that the discovery of
the path that must be taken that is an interesting problem.
How do the 3 local proxies + your home proxy get to be
included in the first place? You could rely on local policy
for the 3 local ones and then DNS SRV for the home one. But
in some cases the idea of discovering a possible route when
you registered with your home proxy may have some merit,
especially if you accept the looseness of any route
discovered. I have a pretty good chance of getting my
services on an inbound call due the association with my
registration. This would do the same for outbound calling.
Not perfect I know but routing for services is hard and
this might be a start.

Cheers,
Neil.
--
Ubiquity Software Corporation, UK        http://www.ubiquity.net

_______________________________________________
Sipping mailing list  http://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 3 Aug 2001 09:12:11 +0300 (EEST)

> That's the difference between strict and loose source routing.

ok, but then a much cleaner solution would be to add a parameter to the
route header that would tell if the route is loose or strict.  this is
what many other signaling protocols have.  the % stuff should be
history.

-- juha

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 3 Aug 2001 09:25:25 +0300 (EEST)

> proxy routing of a request' for those trying to keep up

i too think that it is a good idea to always consider the route header
as specifying a loose source route.  if a ua or another proxy has been
configured with an outbound proxy, it simply forwards the message to
that and leaves the route header as is.  so this is purely a
configuration issue in the ua or proxy and has nothing to do with dns
capabilities as the current text incorrectly says.

-- juha