Re: [Sip] draft-ietf-sip-outbound

[Dean Willis <dean.willis at softarmor.com>]

On May 9, 2008, at 2:14 AM, Christer Holmberg wrote:

>
> I don't understand Juha's argument about proxies "knowing things".
>
> If a UA does not register an outbound flow via a certain proxy that
> proxy doesn't have to know anything about other proxies, because no  
> call
> to/from the UA will ever go through that proxy.
>

The real question is to which proxy in a cluster of proxies should  
requests to you be sent?

Typically a cluster of proxies will be represented by multiple SRV  
records.

Assume there are N proxies in the cluster. If your UA is registered to  
all N, then any of them will work. It doesn't matter which SRV record  
gets picked.

Assume now that a flow drops between your UA and one of those N  
proxies.  However, according to the DNS, that proxy is still  
authoritative for your domain, and it might get a request meant for  
you. What does that proxy do if it gets a request for you? Returning a  
404 would be uncool. So it has to be able to figure out which of the  
other proxies in the pool have a flow with your UA.

In a shared-state system, some sort of database (which could be  
distributed, centralized, bus-multicast, whatever) informs every proxy  
in the cluster about your flow-bindings (either as they come and go,  
or on demand).  A proxy (like the one above) that has lost its flow  
for your UA uses this to find a proxy that has a flow with your UA in  
order to send a request.

There are all sorts of optimization hacks and approaches for making  
this work more efficiently or more manageably.

One nifty technique is to pair up the proxies, such that there are N/2  
pairs, then define a hash across the namespace that maps to each user  
ID to one of those pairs, Your UA will then end up registering to and  
forming a flow with both proxies in its assigned pair. Other proxies  
in the pool that receive a request for you can use the hash to find  
the right pair, and if either proxy in the pair has lost the flow, it  
knows to consult the other member of the pair. If a whole pair goes  
down for service (or a new pair gets brought on-line), the hash  
algorithm gets updated and the system rebalances.

Another approach is to consider the set of N proxies a ring, and  
define a hash on the namespace across the N proxies, where your UA  
ends up registered to the proxy to which it is hashed (call it M) and  
the (M+1)modN proxy. This gives a smoother distribution curve. Or one  
could use an even fancier hash (or pair of hashes) to pick two proxies  
that are not adjacent.  This buys some advantages if the allocation  
algorithm works to make a local proxy "preferred" and a non-local  
proxy "secondary" for each user -- this way, if one data center  
crashes, we don't have a real avalanche restart.

--
Dean

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip