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

From: "Dean Willis" <[email-masked]>
Date: Mon, 23 Jul 2001 15:22:53 -0500

One of the SIP-things I've been worrying at for the last few months  turns
out to actually be a hot topic in some of the SIP-using environemngts like
3G wireless.

Here's the problem: I have a proxy server that provides nifty application
support for calls that I originate. Unfortunately, it's at home (my house,
that is) and the SIP phone on my desk at the office uses a proxy at the
office for making outbound calls. Since the office-proxy follows normal
proxy rules and resolves the request-URI directly, my outbound calls never
see my home proxy and it can't provide services. I can't just bypass the
officeproxy, as it might control the firewall and failure to talk to it
would cause dead calls.

In the 3G space, this problem affects roaming wireless users, at least where
mobile IP is not used, meaning it's an issue for "Simple IP" mode for 3GPP2
and all the time for 3GPP. The scenario there looks like:

phone-->visitedproxy--->homeproxy--->destination

Here's the problem: The phone discovers its default outbound proxy through a
mechanism like DHCP, or is statically configured to use a specific outbound
proxy. SIP conventions allow the phone to direct all requests through this
specific proxy, which then uses normal determination rules to find the next
hop.  There's not realy a way to put something in the signaling that says
"oh by the way, somewhere during this call please visit proxy my home
proxy".

SIP does have a strict source-routing mechanism, using Record-Route and
Route headers. Normally, this allows proxies that want to be included in
future messages to stay "in the loop" by doing a Record-Route during an
early message. The phones then use the Record-Route headers to construct a
set of Route headers on later transactions in the call. If Route headrs are
present, a forwarding node basically strips one off and sends the message
there instead of looking at the Request-URI. This works reasonably well for
messages relating to a single call.

The spec doesn't say one can't preload Route headers into a request, thereby
producing a persistent strict source route. It also doesn't specify a
mechanism whereby one might obtain such a list of route headers, save for
the discovery mechansim of Record-Route. If one's "home proxy" is the same
as one's "registrar", then one might do a "Record-Route" on REGISTER, and
save the resulting Route: headers for use in future INVITES. This has been
proposed in 3GPP, using a new REGISTER header called "Path", which works
basically like Record-Route does on INVITE. As a result, one ends up with a
fixed set of nodes which are traversed, in-order, for ALL messages to/from a
particular user.

However, the evils of strict source routing have long been known to the
IETF, and that's why we use dynamic routing protocols. If there's any kind
of change in network topology, one has to re-route, and that can be a messy
process. This makes load-balancing, multi-path networks, and failure
suvivability really complex. And this particular approach (learning the
strict source route from the path of the REGISTER method) is a service
crippler, for two reasons.

Problems with strict source routing based on the REGISTER path:

1) It requires REGISTER be completed by a phone before an INVITE can be
initiated. In pure SIP, there is no requirement to use REGISTER at all, much
lessa a requirement to REGISTER in order to be able to place a call.
REGISTER is just one way to inform a server about a way to contact a given
party -- its about call forwarding TO  a given user, not about granting that
user permission to make calls. This has lots of potentially bad
implications.

2) The source route established is invariant for the duration of the
registration. If a new path is needed, one, must re-register. That's a whole
lot of application messaging being done to support a simple change in
routing topology.

So, what can we do instead?

A couple of ideas spring to mind:

1) Loose (as opposed to strict) source routing: We could put in a set of
loose-source-route headers. These would be slightly different  from the
strict Route headers. For a forwarding node (proxy), the logic would be "If
you have a direct route to the target of the first loose-route header, pop
the header and send the request to that destination. If not, process the
request URI according to usual routing rules." This lets only those nodes
which MUST be invariant for call processing to stay in the loop. This is
different from strict source routing, which defines the whole vector of
nodes that will be traversed by all future messages.

2) Path-based addressing -- for example, if  to call [email-masked] using
services from myproxy.net, I might use a request-URI of
[email-masked]@myproxy.net.  The request would be sent to the FQDN on the
right of the rightmost @ until received by a proxy responsible for that
FQDN, which would then strip itself off and process the remainder of the
RequestURI as usual.

Thoughts? Opinions? My opinion -- strict source routing is not a good idea.
There's got to be a better way to request service composition.

--
Dean

_______________________________________________
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: "Sudharsana krishnan P" <[email-masked]>
Date: Tue, 24 Jul 2001 09:29:10 +0530

Hello Dean 
	I thought something like 

INVITE sip:[email-masked];maddr=myhomeproxy.myhome.com SIP/2.0

would solve the problem.

1, The assumption here is that the UA has a little more intelligence
   The User configures when/when not to route the calls through 
   the home proxy. When the user wants to route through home,
   the UA just adds an maddr into the Request URI of every 
   outgoing request with the address of the home proxy (statically configured)
2, The information needed to figure out any SLAs are probably present 
   in the message itself.
3, The same thing can be done for register requests also if needed.
4, Please note that the syntax may not be exactly correct.

Am I missing something here.

--
Best Regards,
krish

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Dean Willis
Sent: Tuesday, July 24, 2001 1:53 AM
To: IETF SIPPING
Subject: [Sipping] How to Get Outbound Services from A Non-Local Proxy?

--
Dean

---

From: James Undery <[email-masked]>
Date: Tue, 24 Jul 2001 09:14:03 +0100

> INVITE sip:[email-masked];maddr=myhomeproxy.myhome.com SIP/2.0

I don't know about other people but

sip:[email-masked]

seems a more consistent URI, but I guess it's a matter of taste.

James Undery

---

From: "Eric Burger" <[email-masked]>
Date: Fri, 27 Jul 2001 17:21:06 -0400

The thing I don't like about hacking the address bit of the SIP Request-URI
is that the address bit represents the target user agent (called party).  In
the example below, the target user agent is "sip:[email-masked]", not
"sip:[email-masked]@myhomeproxy.myhome.com".

I would thus vote for something more along the lines of the maddr
suggestion, as what we're trying to accomplish is to give a routing "hint"
to the outbound proxy (a parameter thing) as opposed to changing the
destination (an address thing).

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
James Undery
Sent: Tuesday, July 24, 2001 4:14 AM
To: Sudharsana krishnan P
Cc: 'Dean Willis'; Sipping (E-mail)
Subject: Re: [Sipping] How to Get Outbound Services from A Non-Local
Proxy?

James Undery

> Am I missing something here.
[snip]

---

From: James Undery <[email-masked]>
Date: Mon, 30 Jul 2001 16:04:14 +0100

Firstly I'd like to point out all these methods are ugly hacks

> "sip:[email-masked]@myhomeproxy.myhome.com".

I'd contend the To header is the target user agent and I never suggested
changing that.

> destination (an address thing).

The problem with maddr is how it gets treated, the outbound proxy has to remove
the maddr (breaking it's normal behaviour) or the second proxy has to ignore the
maddr.

A third option is pre loaded Route header.

e.g.
INVITE sip:myhomeproxy.myhome.com SIP/2.0
Route: sip:[email-masked]

(IIRC the outbound proxy should not pop and use the route)

But as I said all these are fairly ugly and require a UA to create a
non-standard INVITE where the initial request uri doesn't match the destination.
Personally I dislike the maddr option the most because of the overloading of
semantics, the other two are equally distasteful in my mind.

James

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 30 Jul 2001 19:50:00 +0300

Hello Dean,

I did not like the Path idea from the beginning, and I still don't like
it. About your second proposal:
[email-masked]@myproxy.net

as James points out, we have to escape the first @:
sip:[email-masked]

It is worthwhile taking into accout that the user portion of the URL is
case sensitive while the domain portion is case insensitive (user@host).
Therefore, using this chain of URLs we might run into trouble comparing
URLs because we are placing a case insensitive field into a case
sensitive one. However, the same ways as email applications typically
trear the user portion as a case insensitive variable, SIP entities
typically do the same. So, this should not represent a problem.

I like this approach because it does not change how routing is performed
in SIP. A request is forwarded until it reaches a proxy in the domain
specified in the domain part of the request-URI that knows of the user
part (in this case the new request-URI).

Even defining some simple rules for escaping characters it would be
possible to make a request traverse several proxies.

Some time ago we had a discussion about source routing in the old SIP
mailing list, and it seems to me that the "best" way to perform loose
source routing is this one.

Best regards,

Gonzalo

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              [email-masked]

---

From: "Dean Willis" <[email-masked]>
Date: Mon, 30 Jul 2001 14:04:17 -0500

Here's another point -- according to the developers I talked to, hacking the
existing code to deal with %@ routing is easier than dealing with maddr,
which seems to require fundamental parser changes as well as mods to the
spec.

Maybe we should use ! routing ala UUCP? (That's a JOKE, ok? Please don't
actually do it!)

Any other bright ideas out there?

--
Dean

----- Original Message -----
From: "Gonzalo Camarillo" <[email-masked]>
To: "James Undery" <[email-masked]>
Cc: "Sudharsana krishnan P" <[email-masked]>; "'Dean
Willis'" <[email-masked]>; "Sipping (E-mail)" <[email-masked]>
Sent: Monday, July 30, 2001 11:50 AM
Subject: Re: [Sipping] How to Get Outbound Services from A Non-Local Proxy?

---

From: "Cullen Jennings" <[email-masked]>
Date: Tue, 31 Jul 2001 08:27:40 -0700

> Route: sip:[email-masked]

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?

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 31 Jul 2001 19:13:23 +0300

Hello,

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

Regards,

Gonzalo