Re: [Serusers] request for comments

Zeus Ng wrote: Solutions are nice, but I really want to hear ideas :) Provides food for thought! :) > 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

> 2 ser location servers. The > 4 ser proxies were used as front end for proxying SIP

> 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

> round > robin fashion. > When a UA lookup the IP of the proxy, it get one from

> record > or round robin A record. > All REGISTER requests are forwarded from the proxies to

> location > server. This is than replicated to the secondary location server by > t_replicate. So, the proxies has no knowledge of UA

> location servers know where to reach the UA. > For other SIP requests, I have tried two different methods

> 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

So you had the backend location server contacting the UAC directly? I'm attempting to route the invite back through the

end proxy that has the nat session already established with

UAC. At the moment this only works because I am rewriting the (hardcoded) hostname in my config, but I'm looking at doing this dynamically so that any requests to the user location

their hostname rewritten to the previous hop. > 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

> than > writing C program to query the memory USRLOC on the

> This > works best for performance as the proxies are sharing the

> well > as RTP proxying. However, it is relatively poor in NAT and > transaction as > the INVITE, BYE and CANCEL can be handled by different

I really want to keep my operations within SIP messaging

having to rely on external mechanisms such as sql queries. This maintains our flexibility to use any SIP compliant device. It's a great idea thogh! :) > One way I see ser going distributed is to follow the idea of squid > plus some > enhancement. The group of proxies are put into

> proxy > receive a REGISTER request, it check whether one of its

> record > of that UA or not. If yes, it forward the request to the

> and > forget it. Otherwise, it save the location in its memory, do NAT > stuff and > becomes the authoritive proxy for that UA until the

> When > other request comes in, the proxy do the same check with

> again > and forward the request to the authoritive proxy. This way, the > authoritive > proxy maintains the nat ping, shares the RTP proxying and

> of > transactions. > When a new proxy comes in, we just need to tell ser that

> new > member in the partnership. (Though, we need to find a way

> about > this without restarting so that it maintains the USRLOC in memory) > Instantly, this proxy can serve new UA that was never seen

This sounds like a cool idea, I'm not familiar with squids proxiy partnership model, but what you explain seems sound to me.

ser proxies could use SRV records to learn about new 'partner' ser proxies? Or would this be a miss-aplication of the SRV feature? > The only thing I haven't figured out a solution would be

If a proxy that is maintaing a NAT session with a UAC goes

no way of passing off this session/location to another

just waiting for the UAC to re-register. > Zeus >> -----Original Message----- >> From: serusers-bounces(a)lists.iptel.org

>> On Behalf Of Jev >> Sent: Wednesday, 30 June 2004 8:53 AM >> To: Andrei Pelinescu-Onciul >> Cc: serusers(a)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,

>> t_replicate between all of them. I admit I have not

>> is possible, so please forgive me if I'm talking

>> this stage. My concern here, as I mentioned in my reply

>> 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

>> 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

>>> 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

_______________________________________________ Serusers mailing list serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers