Re: [Serusers] request for comments

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