blog.myitdepartment.net

Remembering when I had a problem with my first pfSense installation, I had some help from a friend who did a quick packet capture. it seems the ITSP, even after being told three times they were, was still not sending signalling to sipXecs on port 5080. It was being sent to 5060.

In doing a quick packet capture, Diagnostics>Packet Capture, it was very easy to turn capture on for the WAN port, call the system from the outside and stop the capture. Then download the capture file and open with wireshark on your PC.

Don’t have wireshark? Go get it from the wireshark.org download page!

In my case, looking at the capture file showed the signalling still being sent to port 5060. So that explained a lot. While there are a lot of firewall packages I like, a lot of them lack this feature.

GO PFSENSE!

Recently, I took a look the traffic shaper wizard in pfSense (1.2.3Prelease version).

I liked the fact that they had an easy to follow definition in there. I tinkered with two files that defined the protocol/port and name of VOIP related services so it would work well for sipXbridge in an ITSP trunking role and for remote workers coming into the network.

If you’d like to try, replace these files located in /usr/local/www/wizards (winscp makes that easy):

traffic_shaper_wizard.inc

traffic_shaper_wizard.xml

If you start the wizard and state your connection upload/download speed, it will allow you to do four things:

1. Prioritize VOIP over all other bandwidth.
2. Choose your VOIP provider (in this case you choose sipXecs). Specifying sipXecs specifies the ports/protocols used by sipXecs for trunking and remote workers.
3. Specify the internal IP address of your sipXecs installation
4. Set the total amount of reserved bandwidth to 80% from a dropdown box.

The overall rates can be adjusted but the margins (80%) cannot.  I would encourage some feedback on the sipx-users list to modify this so it can be included on a wiki somewhere. What I find is if I have a pipe almost solely dedicated to voice traffic, I have to overstate my upload speed in order to specify MORE bandwidth for voice traffic to free up the last 20% and prevent data from over-running my voice.

Even if your circuit is completely dedicated to voice for sipXecs, there is still DNS and voicemail to email traffic as well as remote UserUI traffic happening, and I want voice traffic prioritized FIRST.  You can also preset the bandwidth amounts in the “inc” file to make it brainless for your installs. I have already approximated 86k of bandwidth in increment steps (so you can prioritize by the number of calls you will have at your site).

Example: I have a 7100k (7.1Mb download) and 768k upload DSL connection, you should use this as an example.

Here I say I have a 7100k download speed and a 1200k upload speed (I have to fudge the upload to get the most out of my upload bandwidth, since that’s the more limiting factor here). The Real-time control over shaping only allow you to state 80% of your total bandwidth in either direction for shaping.

Here you state your desire to prioritize VOIP, choose sipXecs as the provider, put in your sipXecs IP address on your LAN, and choose your nearest “best guess” of total VOIP bandwidth (number of call times 86k) and choose the best selection from the drop down box. (Hint: For four calls simultaneous from the outside, select the fourth speed in the list).

Now this will finish, hopefully without an error. If you get an error about exceeding “80%”, start over and REMOVE SHAPER. State a slightly higher upload speed than you really have if you need to.

WAIT! A bug in their shaper doesn’t actually activate it until you apply it, so. What i do is go back to the FIREWALL>SHAPER screen and edit the description of the rules with the “e” edit icon. By default it will have VOIP adapter. I just scroll to the bottom and change it to VOIP then click “SAVE” and APPLY SETTINGS button at the top which actually starts to run the shaper (a bug with the wizard).

You can go to STATUS>QUEUES and watch the rules in action now!

Thanks and ENJOY!

Published a new basic guide on setting up sipXbridge with bandwidth.com.

This is my first attempt at a how-to, and while it might not meet every need, should be handy for folks connecting to bandwidth.com who need a basic step-by-step guide. I’ll be polishing this up after I get some feedback.

Three_things_I_really_like_about_sipXecs_4.pdf

Call-Setup-Example-sipXecs-through-ITSP

sipx_bridge_pfsense_bandwidth-dot-com.pdf