[Serusers] request for comments

[Zeus Ng]

I may share some of my experience on a similar concept. Notice that it's not
a solution but more an idea sharing. From the experiment, I found that there
is a fundamental weakness in ser (plus UDP plus NAT) to support a
distributed SIP environment. I'm not saying it can't be done. However, to
make ser more distributed, I think there is a need to redesign the way ser
handle user location. 

The lab environment I have is 4 ser proxies and 2 ser location servers. The
4 ser proxies were used as front end for proxying SIP requests. They have a
SRV record in the DNS server for UAs which understand this record. For UA
that doesn't understand SRV, the DNS also reply the proxies IP in a round
robin fashion.

When a UA lookup the IP of the proxy, it get one from either the SRV record
or round robin A record.

All REGISTER requests are forwarded from the proxies to the primary location
server. This is than replicated to the secondary location server by
t_replicate. So, the proxies has no knowledge of UA location. Only the
location servers know where to reach the UA.

For other SIP requests, I have tried two different methods to handle them.

1. Forward all requests to location server and use record_route to keep the
proxy in the path:

This works great to maintain dialogue as INVITE, reINVITE, BYE, CANCEL will
all proxy back to the location server which has the transaction state. OTOH,
it is poor in NAT handling since the location server was never directly
contacted by the NAT device. The nat ping will not keep a hole in the NAT
device. Also, it has no performance improvement over one single
"proxy+location" server as all requests end up in location server.

2. Proxy querying UA location via SQL

In this method, I've written a small SQL script to be run by the proxy via
exec_dst to check the UA location from the location server DB backend. (I
know that DB is not the best place to check location but it is easier than
writing C program to query the memory USRLOC on the location server.) This
works best for performance as the proxies are sharing the requests as well
as RTP proxying. However, it is relatively poor in NAT and transaction as
the INVITE, BYE and CANCEL can be handled by different proxy due DNS
resolution. 

One way I see ser going distributed is to follow the idea of squid plus some
enhancement. The group of proxies are put into partnership. When the proxy
receive a REGISTER request, it check whether one of its partner has a record
of that UA or not. If yes, it forward the request to the other proxy and
forget it. Otherwise, it save the location in its memory, do NAT stuff and
becomes the authoritive proxy for that UA until the REGISTER expires. When
other request comes in, the proxy do the same check with its partner again
and forward the request to the authoritive proxy. This way, the authoritive
proxy maintains the nat ping, shares the RTP proxying and keep trace of
transactions.

When a new proxy comes in, we just need to tell ser that there is a new
member in the partnership. (Though, we need to find a way to tell ser about
this without restarting so that it maintains the USRLOC in memory)
Instantly, this proxy can serve new UA that was never seen before or its
REGISTER has expires somewhere.

The only thing I haven't figured out a solution would be how to pick up UA
location when one of the proxy fails. I don't like the way t_replicate works
as it requires hard coding other proxies in the script and needs restarting
ser for failover.

Zeus
> -----Original Message-----
> From: serusers-bounces at lists.iptel.org 
> [mailto:serusers-bounces at lists.iptel.org] On Behalf Of Jev
> Sent: Wednesday, 30 June 2004 8:53 AM
> To: Andrei Pelinescu-Onciul
> Cc: serusers at lists.iptel.org
> Subject: Re: [Serusers] request for comments
> 
> 
> Andrei Pelinescu-Onciul wrote:
> [snip]
> > So all the packets comming from the same ip will be sent to 
> the same 
> > fron end SER? (hashing after src ip)?
> 
> Yes, using ciscos "Sticky IP" which I admit, I do not know about, but 
> I'm told it will do this job properly.
> 
> > Anyway there are some problems related to the nat traversal:
> > 
> > 1. nat ping - nat ping needs to access usrloc, so that it 
> would know 
> > which users to ping. However on your setup the front-end 
> servers have 
> > no ideea about this, so they wouldn't be able to nat ping. 
> The "main" 
> > server (User accounts) knows who to ping but its ping won't 
> traverse a 
> > symmetric nat (the nat will have an open binding only with the 
> > outbound proxy, which would be one of the load balanced front-ends).
> 
> I do realize this now, so I'm considering running a non-persistent 
> usr_loc (no mysql back end) on all the front end servers, and using 
> t_replicate between all of them. I admit I have not verified 
> if this is 
> possible, so please forgive me if I'm talking non-sense here at this 
> stage. My concern here, as I mentioned in my reply to Klaus's 
> post, is 
> that if I use t_replicate will all my front end ser servers, 
> will they 
> all spit udp at a single natted client when the client has 
> only one udp 
> session with one front end server?
> 
> 
> > 2. consider user A calling user B, where at least B is 
> behind a nat. 
> > The invite would reach the "main" server which will look up 
> B and will 
> > try to send the message to B's address. Unfortunately B's nat will 
> > drop the packet, because it has an open binding only 
> between B and the 
> > load balanced ip. (this will work only if B has a full cone 
> nat which 
> > is very very unlikely)
> 
> I'm not sure on the solution here. I will need to make the 
> call go via 
> the front end ser server that has the active udp session with the 
> client. I'm going to sleep on this!
> 
> 
> > 3. assuming the above stuff will work somehow, you still have to be 
> > very carefull to open only one rtp proxy session (since 
> each front end 
> > has its own rtp proxy you should make sure you use 
> force_rtp_proxy on 
> > only one of them, for the same call)
> 
> 
> I agree, and I realize that I'm making some challenging issues for 
> myself :)
> Thank you Andrei for your comments!
> 
> -Jev
> 
> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
>