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

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 31 Jul 2001 03:09:44 -0400

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]]
> Sent: Monday, July 30, 2001 3:04 PM
> To: Gonzalo Camarillo; James Undery
> Cc: Sudharsana krishnan P; Sipping (E-mail)
> Subject: Re: [Sipping] How to Get Outbound Services from A Non-Local
> Proxy?
> 
> 
> 
> 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.

One thing to note about the %@ routing is that its not for free. Remember,
the interpretation of the LHS of the @ is at the discretion of the server
handling the domain on the RHS. So, if you have:

sip:[email-masked]

This will only work if myhomeproxy.myhome.com knows to look for URL-encoded
user@hosts in the LHS of the @. Thats why, in general, constructing URLs is
not going to work, you need to make use of a URL that has been handed to you
in some way (business card, message, etc.).

James Undery wrote:
> >
> > 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).
> 
> 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.

I think the normal behavior as defined in bis-03 onwards will support the
maddr approach. The spec talks about using the maddr to route if its "not an
interface you are listening on", and stripping it if it is. Normally,
interfaces are associated with IP addresses, not domains. But, if you simply
resolve the domain and then apply the logic, it will work. Probably the bis
spec itself needs to be clarified on the treatment of maddr with domain
name. 

James also writes:
> 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)

I think the spec does say the outbound proxy will pop the route and use it.
Are you proposing alternate behavior?

Dean wrote:
> 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.

I'm really not sure I agree that the problems are identical. There is an
important distinction between the application layer routing and IP routing -
all elements are directly addressable. Strict source routing fails in IP
when a router doesn't have a "direct" connection to the next hop IP. But, in
SIP, in principal a proxy can send a request to any URL and it will go there
(yeah, yeah, nats and firewalls and other evils...). Load balancing is not a
problem in the SIP routing model because of things like SRV, and you'll get
similar failover capabilities. So, the problem is nowhere of the same scope.

That said, I do realize there are things like I-CSCFs and other beasties
that need to be traversed to get from A to B. As such, I do agree with you,
Dean, that the UA should not need to specify the route for these things
explicitly. Rather, the UA should be able to say "call A by somehow getting
this request to proxy P and going from there". In other words, the caller is
asking for proxy P to take some user field and route it to some other place.
That, to me, argues for something like the % embedded approach.

A few variants on that approach, which I think are documented in Hennings
registration draft in part:

1. before making the call, the caller sends a REGISTER to establish
forwarding logic:

REGISTER sip:myhomeproxy.com SIP/2.0
From: sip:[email-masked]
To: sip:[email-masked]
Contact: sip:[email-masked]

It then sends an INVITE to sip:[email-masked] which will get
routed properly.

2. We can define a new user parameter. We have user=ip and user=phone. These
things are meant to define specify a particular semantics and syntax of the
user part. Well, thats what we're doing here. I'd generalize it, though, to
something like:

sip:[email-masked];user=url

which means that the LHS of the @ is interpreted as a URL to which the
request should be sent. This construct will allow arbitrarily deep nesting,
and also solve the issue I raise above, of how the proxy would know to
interpret the LHS in the way you want. It would also allow us to put tel
URLs and other things in the user part.

My preference is solution 2.  

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
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: "Neil Deason" <[email-masked]>
Date: Tue, 31 Jul 2001 11:30:45 +0100

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> Jonathan Rosenberg
> Sent: 31 July 2001 08:10
> To: 'Dean Willis'; Gonzalo Camarillo; James Undery
> Subject: RE: [Sipping] How to Get Outbound Services from A Non-Local
> Proxy?
>

I think what the registrations draft suggested for
obtaining home services while in a visited network was
a preloaded Route header employing the maddr trick ...

From:  <sip:[email-masked]>
Route: <sip:[email-masked];maddr=wonderland.com>

> My preference is solution 2.

Escaping URLs still doesn't come for free though and
will require a proxy to play along in the correct fashion.
As for defining user=url we can already carry tel numbers
through user=phone and I am unconvinced that the user part
of SIP URLs is the cleanest way to carry HTTP URLs for
VoiceXML scripts to be played to the caller or whatever.
Why not put them unescaped in a separate header (Call-Info
may stretch to fit or define a new one).

Meanwhile an issue we are disregarding here whilst
wrangling with the mechanism to make the routing
happen is how does a UA know to do any of this in
the first place? I can't think of any UAs that are
configurable in this fashion.

Which brings me back to Dean's original posting.
3GPP seem to have adopted a mechanism
where a signaling path to a home server is
established when user registration occurs. Like
Dean I too worry about how routing for services is
going to work (funny that). However, I am perhaps
more sympathetic to the mechanism 3gpp has reached
- discovering the path to services at registration.

This has been called 'persistent strict source routing
based on the REGISTER path'. But, as Jonathan pointed
out, compared to strict source routing at the IP layer
many of the load-balancing, multi-path networks, and
node failure are greatly negated by use of URLs + DNS.
This also softens the blow that the path duration
is tied to the registration duration. Which can also
be maintained at a reasonable interval to ensure
refreshes by the registrar. The persistence of the
route also needs to be qualified. It would not
necessarily be for the entire session. Pre-loaded
Routes only exist for the first transaction after
that the Record-Route headers take effect. It is
therefore up to a server on the signaling path to
decide if it wants to stay on the signaling path for
the duration by adding a Record-Route entry first
time around.

Also the 3gpp restriction that you cannot make a
call if you haven't registered seems to be a contrived
one. You could use a similar type of mechanism to
route to home server if a path is known (i.e. one
was discovered during registration) but otherwise
just use usual SIP routing to make a regular call.

So the idea that, maybe a loose, route to services
made up from pre-loaded Route headers learned through
registration is not unthinkable to me.

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

---

From: "Bob Penfield" <[email-masked]>
Date: Tue, 31 Jul 2001 08:44:07 -0400

> My preference is solution 2.

OK, I'll stick my neck out.

Whether you use a Route header or the % embedded approach, you are
essentially asking the proxy to do what Dean compares to strict source
routing. Given that some proxies will not deal with the LHS and even more
will not understand "user=url", it seems to me that using the Route header
is the cleanest and most likely to succeed. The likelyhood of success in
routing to myhomeproxy.com is the same regardless of how the proxy extracted
the URL. I think using a Route header is the best. The other methods seem a
bit hackish to me. Why can't the UAC be up front about wanting to route to
its home proxy?

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 31 Jul 2001 16:24:03 +0300

Hello,

I still prefer escaping the @ in the user part than the path solution.
We have to keep in mind that we are already using that solution when
interworking with the PSTN.

We want to call +1-212-939-7171 from a SIP phone. The request URI that
we will use will look like:

sip:[email-masked]

The user part of this SIP URL is a tel URL. Therefore, what we are
saying is exactly what Dean wants: "my INVITE has to reach the tel URL
specified, but it has to traverse before gateway.com"

So, if it is OK to use a tel URL as a user part of a SIP URL, why is it
not OK to use a SIP URL as a user part of another SIP URL??. To me it
seems like the same thing.

Let's define user=url and use this approach.

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: Gonzalo Camarillo <[email-masked]>
Date: Tue, 31 Jul 2001 17:44:03 +0300

Hello,

I have changed the subject of this thread because this issue is not
specific of 3GPP or of a UA that wants services from this home proxy.
The source routing mechanism that we are looking for will be useful as
well to generate replace URLs as defined in
draft-rosenberg-sip-call-package-00.txt. These URLs have to be globally
routable. Let's assume that in order to make a SIP call to an Ericsson
employee the INVITE has to traverse a proxy at ericsson.com (otherwise
the firewall would not let it thru). If my UA wants to generate a
replace URL to be sent in a NOTIFY it will look as follows:

sip:[email-masked];user=url

Best regards,

Gonzalo

---

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

Hello,

Yet another scenario where this is useful is symmetric NAT traversal. 

If domain.com has several proxies that consult the same location
database, incoming requests can be handled by any of them. They
typically are contacted using SRV load balancing mechanism.

However, if the user is behind a symmetric NAT, only the proxy/REGISTRAR
that handled the user's registration can handle the INVITE for him.
Let's assume that proxy1.domain.com handled the REGISTER. This
information is contained in the location server. If proxy2.domain.com
receives an INVITE for that user, it has to forward it to
proxy1.domain.com

Jonathan's draft recommends that proxy2.domain.com inserts a Route
header in the INVITE and sets the request URI to sip:proxy1.domain.com

It would be nicer if proxy2 did not include any Route header but set the
request-URI to sip:user%4022.1.20.3:[email-masked];user=url

By the waym if we define user=url, we will have to add a parameter
indicating which type of URL. It might be sip:tel:[email-masked], for
instance...

Best regards,

Gonzalo