Properly trunking via IAX2 will minimize your bandwidth requirements by
combining multiple calls into one trunk connection, minimizing IP
overhad. The wiki @ www.voip-info.org has a good explanation of this.

In you are bandwidth constrained you're going to need to manage traffic
VERY carefully when using G.711 codecs. I have switched to using the
G.729a codec and find that traffic shaping is a lot less critical. Each
call consumes about 32k per leg, including IP overhead. Absolute call
quality is slightly reduced, but remains much better than a G.711 call
that's suffering bandwidth issues.

Michael

On Tue, 19 Dec 2006 07:57:33 -0600, Lonnie Abelbeck wrote:

>Chris, (and Aaron)
>
>Your comment is a good one to reduce costs and complexity. (1  
>asterisk box, multiple IP phones, 2 locations)
>
>All inter-location calls are cheap and easy.
>
>The problem is when the remote location makes or receives a VoIP call  
>from a VoIP provider.  All the bandwidth (90kbps up and 90kbps down  
>for ulaw) must run through the home location's IP channel both in and  
>out... a total of 180kbps up and 180kbps down at the home location  
>(SIP reinvites might help here, but that is another mailing list).  A  
>couple of phone calls at the remote location could cramp your home  
>location's up IP channel.  An asterisk box at the remote location can  
>make your voice 'routes' smarter.
>
>Additionally, I have found traffic shaping very important to  
>maintaining good quality asterisk voice, and m0n0wall does this well  
>(after some twiddling) , this gives an advantage to not running your  
>voice through a VPN as there is no way to traffic shape your IPSec  
>data (can you prioritize the whole tunnel in m0n0wall using the built- 
>in IPSec?).
>
>Lonnie
>
>On Dec 19, 2006, at 7:14 AM, Christopher M. Iarocci wrote:
>
>> Aaron,
>>
>> Question, do you have hard phone lines at each location?  If not,  
>> or if you want to get rid of the lines at one of the locations, you  
>> could simply install IP phones in the 2nd location and connect them  
>> to the Asterisk box at the 1st location.  This could save them  
>> money on phone lines, and equipment since you'll only need 1  
>> asterisk box.  Of course phone service at the 2nd location will  
>> depend on the uptime of the internet connection.  You would only  
>> want to consider this if you have a T1 or better at both ends.  DSL  
>> or cable is not reliable enough in my opinion, unless you have a  
>> service level agreement with the provider that makes it so.
>>
>> Chris
>>
>>
>> Aaron wrote:
>>>
>>> Thanks for all of the replies about this. I'm hoping it will work  
>>> out well. I curious about was if an IPSec tunnel will add  
>>> complexity or unreliability into the equation than is really  
>>> needed Bandwidth should be OK (~500 & ~750Kbps actual upstream  
>>> throughput = 3+ calls w/ULAW = no problem), A Net4801 on one end  
>>> and a P133 on the other.
>>>
>>> Since I do have static IP addresses and asterisk at both ends, it  
>>> should be fairly easy to do it without IPSec. But, IPSec might  
>>> allow for more flexibility as I could easily register phones to  
>>> either end (or both) without having NAT issues with the SIP based  
>>> phones. But, with asterisk at both ends, I probably don't need it,  
>>> and probably don't really need the IPSec tunnel. However it might  
>>> allow for a more convenient or flexible setup - especially when  
>>> configuring other network services/devices to work seamlessly for  
>>> them.
>>>
>>> I may be back for more help soon...static routes and IPSec are new  
>>> for me and suggestions are still welcome.
>>>
>>> Thanks!
>>> Aaron
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
>>> For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
>> For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
>For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
>
>
>

--
Michael Graves                           mgraves at pixelpower dot com
Sr. Product Specialist                          www.pixelpower.com
Pixel Power Inc.                                 mgraves at mstvp dot com

o713-861-4005
o800-905-6412
c713-201-1262
skye mjgraves
fwd 54245