This turned out to be more complex than I had initially planned ;-) This post quickly summarizes the final working setup.
The initial goal was to balance traffic between two outbound interfaces. This was accomplished with the following: * one master asterisk that handles local SIP peers * slave asterisks running on openvz VEs, one for each external outbound interface The master asterisk registers with both VE asterisks, and has one context to forward calls to each asterisk VE. SIP peers are statically split between both contexts. Each VE asterisk acts as a simple proxy, accepting registration from the master and registering with the VoIP provider. The shorewall configuration is based on the openvz+shorewall guidelines. Additionally, it routes outbound traffic from each VE to a specific interface through entries in route_rules. Furthermore, traffic shaping is used to prioritize VoIP traffic. Downsides: completely static and no failover at all! Regards, Pedro On Thu, Apr 7, 2011 at 4:25 PM, Pedro Bulach Gapski <[email protected]> wrote: > This post summarizes what has been done for the reference of others. > > The initial goal was to load balance SIP traffic flowing from a single > box to two different internet connections on two different interfaces. > The traffic generated from asterisk version 1.4 (debian lenny). > > The attempted solution was as follows: > 1. create two trunks for SIP calls > 2. split peers between these two trunks > 3. bind each trunk to a different interface > 4. register asterisk on both trunks > > AFAIK, 1, 2 and 3 were successful, but 4 failed because of SIP NAT > problems and asterisk limitations (to my best knowledge). > > Steps 1 and 2 were done in the asterisk configuration. > > Step 3 was done with shorewall. A standard configuration was used as the base: > a. interfaces listed in the providers file; > b. traffic shaping in tcrules. > > Additionally, an extension script was used to bind each SIP trunk to a > different interface, using iptables -m string extensions. I ended > using the 'started' shorewall entry-point with the following > configuration: > run_iptables -t mangle -A OUTPUT -d 200.219.209.250 -p udp --dport > 5060 -m string --string "<sip:[email protected]>" --algo bm -j > MARK --set-mark 0x100 > run_iptables -t mangle -A OUTPUT -d 200.219.209.250 -p udp --dport > 5060 -m string --string "<sip:[email protected]>" --algo bm -j > MARK --set-mark 0x200 > run_iptables -t mangle -A OUTPUT -d 200.219.209.250 -p udp --dport > 5060 -j CONNMARK --save-mark > > I call this 'one ugly hack', but it worked :-P Traffic was correctly > assigned to the determined interface. Shorewall rocks :-) > > Step 4 failed, it seems, because asterisk binds to all interfaces but > always uses the address of the first interface in the Via header, or > the configured unique external ip. Without a configured external ip, > traffic bound to the second interface contains a Via header with the > address of the first interface, and is not replied to. With a > configured extenal ip, the Via header always uses this address, which > is appropriate for one of the interfaces but not the other. I believe > this could be made to work by patching asterisk to allow for different > external ip for each trunk. > > Comments and suggestions are welcome. > > Pedro > ------------------------------------------------------------------------------ Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo _______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
