Subject: [Sip] an alternative approach for outbound proxy discovery

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 06 Jul 2006 16:10:48 -0400

I want to suggest a possible alternative approach for outbound proxy 
discovery than the one in draft-koivusalo-sip-outbound-discovery. So, 
before I get to it, two caveats:

1. I am NOT proposing that this be added to sip-outbound, and I'm not 
suggesting that a normative reference to this or another mechanism 
should be in outbound. I believe that any discovery mecanism should be 
orthogonal, and what I am about to propose below is orthogonal as well.

2. I have not been able to follow all of the nearly countless messages 
on sip-outbound, so I'm not sure if what I'm about to propose has been 
proposed. So, please point me to relevant threads if it has been

The idea is to not use DNS, but rather use SIP mechanisms for the 
discovery. I much prefer a non-DNS solution for several reasons which 
I'll enumerate below. The basic mechanism combines two things:

1. usage of the 305/service-route as I have proposed in 
http://www.ietf.org/internet-drafts/draft-rosenberg-sip-route-construct-01.txt

2. usage of a new header field in REGISTER responses which specifies 
additional URI to try REGISTERing to

So, here is the idea. UA starts with its AOR (sip:[email-masked]) for 
example, or with a domain name learned from DHCP. In either case, it 
applies RFC3263 and gets the URI for a proxy. This is going to be the 
home proxy, and there is no keepalive=stun and thus no STUN keepalives 
here yet. UA sends a REGISTER request. The proxy receives this, and 
knows that it doesn't accept REGISTER directly like this; it needs to be 
sent via an edge proxy. There are many ways the proxy can know it got 
the REGISTER directly and not through an EP. For example, requests from 
EP come to a different port, or better yet, via TLS mutual auth from 
edge proxy.

So, home proxy redirects the request with a 305. The URI in the contact 
header field is an edge proxy, and has the keepalive=stun parameter in 
it. Now, this URI can be a specific IP address, or more interestingly, a 
hostname that resolves to any number of proxies. This basically becomes 
the first proxy in the outbound proxy set. If its a hostname, client 
performs regular old RFC3263 and picks one. Client sends a request 
there, now with the topmost Route set equal to this URI (this is what I 
have proposed for 305 handling in route-construct).

This arrives at the edge proxy, which inserts itself into Path, which is 
subsequently reflected into Service-Route, which the proxy can modify on 
its way towards the client (again this is what I have proposed in 
route-construct). This Service-Route points to that edge proxy.

Now, the UA has a single proxy (so far) in that outbound proxy set. 
However, that 200 OK to the REGISTER, in addition to having a 
Service-Route, would also have another header field, called 
Additional-Proxies or something like that. This header field would 
contain one or more URI pointing to proxies that the client should 
register additional flows through. For each of those, the client 
performs a registration (each of those URI would be the topmost route 
header field in a REGISTER message, each for a different reg-id). Now, 
it a multiplicity of flows and outbound proxies all set up.

The primary benefit of this mechanism over a DNS one is its dynamic 
nature. The edge proxy which receives the original REGISTER request and 
response is the one that inserts the Additional-Proxies header field. 
Thus, it can purposefully choose a specific proxy acting as its backup, 
or choose a proxy in a different geographic region, or whatever. These 
choices can differ from user to user. The original REGISTER requests can 
be load balanced across all of the proxies in a cluster as a consequence 
of DNS, but the second flow is selected explicitly by the first proxy.

This also lends itself extremely well to mid-dialog failover solutions, 
since the backup proxy is selected by the primary. Thus, it can choose 
one to which it is replicating state. It also allows for a variety of 
algorithms in selecting a record-route value.

With this mechanism, it is clear how the provider chooses the number of 
flows that a UA makes - its an additional one for each value of the 
Additional-Proxies header field.

It also allows us to keep the existing meaning of DNS queries, which are 
meant to choose a single server and not learn a set of servers that all 
must be contacted.

There is a cost of a single extra round trip for the very first REGISTER 
to be redirected. However, I do not view this as particularly onerous.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

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

---

From: <[email-masked]>
Date: Fri, 7 Jul 2006 12:55:32 +0300

Hi Jonathan,

>additional URI to try REGISTERing to

Sounds a nice idea as it has all those good properties
that you mentioned, but it is not without some drawbacks
and open issues.

One difficulty is that such a solution would require the service 
provider to upgrade also the home proxies when starting to 
deploy outbound, instead of just upgrading the edge proxies 
and registrar. There would be no hope of autodiscovery without
such a network upgrade. For the DNS based solution what would
be needed is just a reconfiguration of the DNS server together
with the UAs which implement the procedures. No software upgrade
would be needed for any server in the network.

For the technical point of view I have the following questions:

Most importantly, how can the UA make sure what is the situation
if it does not receive 305 response or 200 OK with Additional-
Proxies for the REGISTER ?

- Was it so that the contacted proxy supports outbound and
  the network does not require the UA to contact any additional
  proxy, so that everything is fine when receiving 200 OK that 
  does not contain Additional-Proxies header ? In this case
  the UA can perfectly well start sending STUN keepalives
  towards the proxy.

- Or was it so that the proxy supports neither outbound
  nor this new optional draft and therefore did not return 305 
  or Additional-Proxies header ? In this case UA could
  make a false assumption and continue using outbound even if
  that would not work.

So I assume that 200 OK header would always have to contain 
some indication whether or not the proxy supports outbound,
right ? This is already being discussed in another thread
but your idea would add one another reason for mandating
such an indication within outbound draft.

>So, here is the idea. UA starts with its AOR (sip:[email-masked]) 
>for example, or with a domain name learned from DHCP. In either case, 
>it applies RFC3263 and gets the URI for a proxy. This is going to 
>be the home proxy.

In my understanding the main motivation for using DHCP for the
SIP proxy discovery is to find a local proxy instead of the home
proxy. Home proxy could always be found by resolving the AOR.
I am not totally sure if your idea was relying on an assumption 
that the UA would always try contacting the home proxy at first.
Anyway that is not always the case.

Mobile clients like laptop PCs and mobile phones could be attached
to a network anywhere in the world, even in different continent
than the one where the home proxy or edge proxies for a domain
are located. In those cases the UA would probably prefer using
a local proxy, if available, rather than the remote edge proxy
of user's home domain. DHCP is used to find such a local proxy.

The discovered local proxy may or may not support outbound:

- In the case it supports the proxy has to indicate the 
  support to the UA in 200 OK as told above.

- In case it does not support the proxy should redirect.
  However is it certain for such a proxy that the UA needs
  outbound support ? The UA does not send Proxy-Require
  header or anything like that to tell the local proxy about
  what it needs. Can such a local proxy rely on this
  kind of hints what you outlined below ?

>UA sends a REGISTER request. The proxy receives this, and 
>knows that it doesn't accept REGISTER directly like this; 
>it needs to be sent via an edge proxy. There are many ways 
>the proxy can know it got the REGISTER directly and not 
>through an EP. For example, requests from EP come to a 
>different port, or better yet, via TLS mutual auth from 
>edge proxy.

Regards,

Erkki 

>-----Original Message-----
>From: ext Jonathan Rosenberg [mailto:[email-masked]] 
>Sent: 06.July.2006 23:11
>To: IETF SIP List
>Subject: [Sip] an alternative approach for outbound proxy discovery
>

---

From: Juha Heinanen <[email-masked]>
Date: Sun, 9 Jul 2006 15:41:54 +0300

i liked jonathan's SIP based discovery mechanism and didn't see any
problems with it.

 > should be in outbound. 

however, i can't agree with the above statement, because i don't see any
difference with outbound discovery and rfc3263 discovery referenced in
rfc3261.  it would have been impossible to set up any vendor independent
sip services unless rfc3263 had existed and mandated by rfc3261.  or
perhaps people only want closed, vendor specific outbound
implementations?

-- juha