Subject: [SIP] Route learnt out of band

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 18 Oct 2000 15:32:43 +0300

Hi,

UACs build Route headers based on the Record-Route header received in a
previous response. But, can a UAC build a Route header that is not based
on any previous response received? That is, the UAC builds a Route
header based on information obtained out of band and then sends the
INVITE.

There are many scenarios where this feature would be very useful. 

For instance, I am in Heslinki connected to the Internet (outside the
Ericsson intranet) and I want to call a guy in Ericsson Helsinki. I want
to reach that guy at sip:[email-masked]

Ericsson has firewalls, so the calls have to be routed by a SIP proxy
that belongs to Ericsson. If I send an INVITE with
Request-URI=sip:[email-masked] it will be stopped by the
firewall.

If I send an INVITE with a Request-URI=sip:[email-masked]
(that is his public address) it will reach first the SIP server handling
the ericsson.com domain. This server is in the States. Then, it will
forward the INVITE to the SIP server hanlding ericsson Finland and so
on. The INVITE traverses a bunch of different servers until if gets to
ws1234.ericsson.fi (his workstation).

If I could build my INVITE with a Route header as follows:
Route: <sip:[email-masked]>,
       <sip:[email-masked]>

I would save lots of hops in the path.

This is just one scenario among many others (probaly more useful) where
this could be employed.

Does anybody see any problem with this?

Best regards,

Gonzalo

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Anders Kristensen <[email-masked]>
Date: Wed, 18 Oct 2000 15:53:40 +0200

This ability to perform source routing for an initial INVITE came up
recently as a desirable feature in a slightly different context.  I
think most people agreed it was a good idea but it's not guaranteed to
work with proxies implementing either rfc2543 or the current bis draft.

It seems a pretty straightforward generalisation but I think one
potential  complication is that the Route used might be incomplete, i.e.
the initial INVITE (or other method for that matter) may need to
traverse proxies not explicitly on the Route. These proxies should have
a chance to stay on the signaling path, i.e. must be allowed to add
themselves to a Record-Route header. The issue then is whether all
proxies will add themselves to the Record-Route (even if they may be on
the Route) and whether the endpoints will update their routes.

There are probably other problems.

Anders

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 18 Oct 2000 17:18:56 +0300

Hej Anders,

Anders Kristensen wrote:
> recently as a desirable feature in a slightly different context.

As I said in my mail, there are many scenarios where this feature could
be useful. I believe this is a general mechanism with general
applicability.
Which context are you referring to?

>I

If folks think this is a interesting feature we can work on all the
issues.

Best regards,

Gonzalo

---

From: Anders Kristensen <[email-masked]>
Date: Wed, 18 Oct 2000 16:36:44 +0200

> Hej Anders,

Hejsa!

> Which context are you referring to?

http://lists.bell-labs.com/pipermail/sip/2000q3/thread.html thread named
"Outbound call routing".  Explicit route used to enable services on home
proxy when making calls from visited domain.

--
Anders Kristensen

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 19 Oct 2000 14:24:54 +0300

Hi,

Taking a look at both threads, "outbound call routing" and "Route learnt
out of band", I have found similarities and some differences in the
problems they are trying to address.

Basically we have the same issue: how to perform source routing using
SIP.

However, folks are speaking about two types of source routing. Using IP
terminology, they are "loose source routing" and "strict source
routing".

In loose source routing the source wants the request to traverse a
particular set of nodes. The request can traverse other nodes as well,
but at least has to traverse this particular nodes.

In strict source routing the source wants the request to follow a
particular path. They request must traverse a particular set of nodes,
and it cannot go to any other node.

The "Outbound call routing" problem, where I want my request to go thru
a certain proxy seems to me a loose source routing problem. I want the
request to go to this outbound proxy and then I want it to be routed
towards its destination.

The semantics of the current Route header are not appropiate for this.

I find the Route header more appropiate for performing strict source
routing. That is, when the UAC knows in advance all the servers (the UAS
included) that the request should traverse.

I would like to use the current Route header for this purpose. The only
new thing would be that the Route header could be used even without
having received a Record-Route previously.

Comments?

Best regards,

Gonzalo

P.D: Thanks for the pointer, Anders.

---

From: "Jo Hornsby" <[email-masked]>
Date: Thu, 19 Oct 2000 12:51:28 +0100

> included) that the request should traverse.

I'm not sure that this is necessarily true.  If you look to bis02,
we have:
    6.34.3 Request Destination
        Unless this would cause a loop, any client, including
    the UAC, SHOULD send the next request for this call leg
    to the first Request-URI in the Route request header field.
    A client MAY forward the request to a designated proxy
    instead, for example, if it lacks DNS resolution capability.
    If a client uses the first Route entry to route the request,
    it removes it.

Thus there is flexibility here.

When is a proxy likely to ignore a Route directive?  My initial
thoughts are when there are networking issues (it knows it has
to go via some ALG-proxy, for instance), or when there are
billing issues.  But there is nothing wrong with this.

Thus I would say that as long as a proxy is happy to receive a
request with Route headers in for an unknown call leg, things
should work out okay; it will use other proxies as necessary,
and any of these will Record-Route if they need to remain in
the signalling path.

Cheers,

 - Jo.

---

From: Anders Kristensen <[email-masked]>
Date: Thu, 19 Oct 2000 14:29:16 +0200

> and any of these will Record-Route if they need to remain in

The problem I was mentioning earlier is that things break down when a
proxi is NOT happy to proxy requests for unknown legs with Route headers
without being able to add itself to the Record-Route and stay on the
signaling path. OK, so it can always try and recourd-route, the question
is whether other proxies and the UAs play along, i.e. other proxies also
adds themselves to the RR even when they're already on the Route and
also whether UAs updates their routes. Neither is assured by the current
draft, I think (haven't checked).

The distinction between loose and strict source routing seems to me
useful in understanding the problem, but most of the time a UAC can't
know for sure whether what it's doing is loose or strict.

--
Anders Kristensen

---

From: "Jo Hornsby" <[email-masked]>
Date: Thu, 19 Oct 2000 14:11:07 +0100

> also whether UAs updates their routes.

Since neither UA has seen a Record-Route yet, I would suggest that
they should have no well-defined Route for this Call (Call Leg)
yet.  The originating UA may well supply an initial Route list, but
it should be discarded for subsequent requests, and the "normal"
behaviour used.

Mostly it comes down to the "if their proxy/UA doesn't support it,
don't buyfrom/routewith them" approach.  It's unlikely that someone
is going to require routing across a disparate set of proxies which
have no real relation to each other (I would guess typically one is
going to want to route through, say their "home" proxy, and their
favourite ASP proxy, for instance).

> Neither is assured by the current

UAs should not update their Routes (save noting new Contact
addresses); the only thing that proxies continually reinserting
Record-Route s buys is recovery after a crash.

> know for sure whether what it's doing is loose or strict.

Agreed.  The question is: does this really matter if the request
visits all the desired proxies in both cases?

 - Jo.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 19 Oct 2000 16:35:12 +0300

Hi,

I see three possible choices here:

1) The UAC adds a Route header to the INVITE. This Route header is to be
used just by this first INVITE. The following transactions will follow
the path resulting from the Record-Route header coming in the 200 OK (or
in the first provisional response). The UAC knows that the first Route
header was built by him, so the Route header in subsequent requests will
be ellaborated with the RR information received.

A proxy will receive a INVITE with a Route header. This proxy does not
have any state for this call-leg. It will add himself to the
Record-Route (this is already recommended for robustness in the bis
draft) and forward the INVITE based on the Route header.

The weak point of this approach is the situation when the proxy is not
happy with receiving INVITEs with Route headers without having any state
for it.
Anyway, for robustness, any existing server will most likely perform the
same actions I have just described. When an existing implementation
crashes and goes up again, it should handle re-INVITEs with Route
headers for call legs whose state got lost when the server crashed.

2) The Route header is added to the Request-URI as Sean suggests in
http://lists.bell-labs.com/pipermail/sip/2000q3/002748.html

This works if all the proxies in the path understand Request-URIs with
headers. If any proxy in the path does not it will remove them and go on
routing the call without taking into consideration the Route header in
the Request-URI.

3) Adding a new header called something like Source-Route. If a proxy
does not understand this new header it will ignore it. If the next proxy
does understand, it will route the call based on it. This can generate
loops.
Thus, a require header would be necessary if such a new header was
created.

Solution number 1 seems to me to be the best.
Solution number 2 might break some implementations that use fix-length
arrays for storing the request-URI (request-URIs would become very big).
Solution number 3 does not look good.

Any concerns with solution number 1?

Regards,

Gonzalo

---

From: Anders Kristensen <[email-masked]>
Date: Thu, 19 Oct 2000 15:37:14 +0200

> it should be discarded for subsequent requests, and the "normal"

Yes. Needs to be written into the bis draft, though.

> favourite ASP proxy, for instance).

I'm not sure this is true but it doesn't really matter. The behaviour
needs to be defined in the spec regardless (if agreed upon).

> Record-Route s buys is recovery after a crash.

Right, so it is in fact a problem.

> visits all the desired proxies in both cases?

That's a good point but strictly speaking just because a proxy not on
the initial Route happened to be on the path actually taken for the
initial request doesn't mean it will necessarily be on the path of
subsequent requests unless it gets to be on the route. This is maybe
especially true for requests going in the opposite direction.

--
Anders Kristensen

---

From: "Jo Hornsby" <[email-masked]>
Date: Thu, 19 Oct 2000 14:49:33 +0100

> be ellaborated with the RR information received.

Indeed.

> draft) and forward the INVITE based on the Route header.

I don't know that we even need to be this strict.  If a proxy has
to send this request to another proxy, or another N proxies,
because of billing, for instance, then we're still cool as long as
the Nth proxy obeys the Route header (and presuming that the
intermediate non-Route-obeying proxies didn't pop Routes anyway).

> happy with receiving INVITEs with Route headers without having any state

Yeah, this is where everything might fall down.

> routing the call without taking into consideration the Route header in

I do quite like this as an idea, but I'm not sure that in this
case.  In actual fact, bis02 currently forbids headers being
in the Request-URI (but this is a small issue).

I think that the general notion of a SIP URL being able to specify
source routing is quite powerful.  It could be used in web "links"
for instance; or in Registrar DBs (think Contact addresses in
REGISTERs).

> Solution number 3 does not look good.

Agreed.  The bonus is that I would imagine that many proxies would be
able to fly with Solution 1 today (UAs having user-configurable
Routes for an initial INVITE is less likely, I guess).

 - Jo.

---

From: "Jo Hornsby" <[email-masked]>
Date: Thu, 19 Oct 2000 15:09:50 +0100

> needs to be defined in the spec regardless (if agreed upon).

Yes.  It would be nice if we RECOMMENDED that proxies obeyed Route
headers, regardless; if they have to do some sort of additionally
funky Challenge as a result -- so be it.

> especially true for requests going in the opposite direction.

I'm lost now.  As long as this proxy Record-Route d, why would it
not be on the path?  Or are you thinking of a case where I would
like my "home" proxy, for instance, to stay in the signalling path,
but it doesn't Record-Route?

If it's the latter, I guess this might be problematic.  Playing
with Routes post-INVITE/200 does seem more risky.  Thus it might
be useful to note in the spec that if a proxy is coerced into a
Call, it might want to think extra hard before opting out on
subsequent Requests.

Cheers,

 - Jo.

---

From: Anders Kristensen <[email-masked]>
Date: Thu, 19 Oct 2000 16:25:06 +0200

I thought 1) was what we'd been talking about all along. I see no point
whatsoever of putting the Route header into the request-URL. My
understanding is that the grammar for SIP URLs allow headers and body in
URLs simply so that URLs can be passed around out-of-band, e.g. in an
HTML page, with extra info, for example a Subject line. When the user
clicks the URL, the UAC constructs a request adding headers and body
from the selected URL.  As of 3) it might be the cleaner approach but
I'd rather see Route work in this case also.

Anders

---

From: Anders Kristensen <[email-masked]>
Date: Fri, 20 Oct 2000 12:22:32 +0200

Sean Olson wrote:
> 
> There is a potential issue with solution 1 depending on the scope of the
> problem that you are trying to solve. Consider the situation below:
> 
> UAC ---> Outbound ---> Arbitrary SIP network ---> Service Network
>          Proxy                                    Entry Point
> 
> If you are trying to define the Route: between the Outbound Proxy
> and the Entry Point into your service network, then solution 1 works
> fine. If, however, you are trying to specify the route to take *once
> you reach the entry point*, then solution 1 does not help you.
> That was the problem I was trying to solve by storing the Route:
> headers in the Request-URI. The Request-URI would point to the
> Entry Point. When the request arrived at the Entry Point, the
> Entry Point could use the Route: headers in the Request-URI
> to route the request within the service network.

OK, I get it.

> 
> Basically, the problem is that Route: headers are interpreted by
> the first node that receives the SIP request, even if the Route:
> headers are not intended for that node.

Right, but I would still prefer correcting that behaviour rather than
adding new syntax to URIs. So in the updated routing algorithm a proxy
receiving a request with URI sip:user@X and some Route would pop the top
Route element and route the request to it, ONLY if the host part of the
request URI identifies itself, otherwise it would proxy to that request
URI and leave both the request URI and Route intact.  Would that work?

This is all under the assumption that the problem is a real one and is
worth solving.

> 
> I realize this is an odd case, but I thought this was the problem
> that was being looked at. The problem of specifying a Route:
> from the outbound proxy onward is much simpler, I think.

Maybe, but thinking that current proxies would actually work in that
scenario is, IMHO, overly optimistic.

Anders

> 
> --
> Sean Olson <[email-masked]>
> 
> Anders Kristensen wrote:
> 

--
Anders Kristensen

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 20 Oct 2000 14:00:22 +0300

Hi,

Yes, we have many possible problems, and probably many possible
solutions. Anyway, let's start with the simplest case and then let's
continue studying more complex problems (with probably more complex
solutions).

I would like to identify if there are issues with allowing the first
request of a call-leg to carry a Route header.

I believe SIP proxies should accept this type of requests for
robustness. If a SIP proxy crashes it loses the state information. The
next request (maybe a re-INVITE for the session timer) will carry a
Route header and it will look to that proxy like the 1st request of a
new call-leg. The proxy should not discard this request just because of
this.

Thefore, it seems to me that this would be the normal behavior of any
current proxy. No changes in the protocol. We need just to explicitly
say that the 1st request MAY carry a Route header (if we agree upon
this). The behavior of the proxy upon reception of Route headers remains
untouched.

Besides robustness, this will enable services such as the ones
previously described in this thread.

Any issues that have not been identified so far?

Regards,

Gonzalo

---

From: Sean Olson <[email-masked]>
Date: Fri, 20 Oct 2000 10:31:37 +0200