[Serdev] Concept for a SIP cluster implementation

[Evan Borgstrom]

	All of the issues mentioned here are solvable today with some 
creativity. We currently have a multi-domain, multi-proxy, multi-backend 
spread over multiple physical sites using nothing but SER (with our own 
cacheless usrloc implementation), nathelper, rtpproxy & mysql (4.1 
cluster). The only external component we have that's not a open source 
item is SIP hardware load balancers doing global load balancing between 
the physical sites instead of using SRV records (we're currently 
deploying this right now to start moving away from SRV records).

	The dst_ip patch I subbmitted to the AVPOPs module was a big part in 
getting this all working. Store the IP of the proxy the user registered 
with via AVPOPs, when a new message comes in compare $dst_ip with the 
value stored in the database, if != forward off to the value from the 
database and do ALL processing there. That ensures that all messages 
that are required to pass through the NAT pin hole do. Some gotcha's to 
watch out for include things like making sure accounting is only done 
once, and use registered() instead of lookup() right until the VERY end 
before you t_relay() the message to ensure as it bounces around the 
proxies the URI is kept correct.

-Evan

Jan Janak wrote:
> On 27-09-2005 13:00, Klaus Darilion wrote:
>> Jan Janak wrote:
>>>  - A user agent does not have to send INVITE messages through the same
>>>    proxy instance as REGISTER messages. The proxy server that received
>>>    the INVITE request can make sure that the uac is reachable
>>>    for the duration of the transaction by retransmitting the
>>>    provisional response periodically (simulates NAT ping). All other
>>>    transactions finish immediately and do not need this.
>> What happens in the callee hangs up (send the BYE)? This will be 
>> loose-routed via the same proxy, which may not have a pinhole to 
>> traverse the NAT :-(
> 
>   In my case the proxy would insert the IP of the correct proxy (the one
>   that keeps the NAT hole open) because it knows it.
> 
>     Jan.
> 
> _______________________________________________
> Serdev mailing list
> serdev at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serdev