Polycom Phones

to answer your question ............ YES .. a huge nat problem. In addition youve told your phones to register every 60 damn seconds. Is this pbx intended to have more than 40 phones on it? Is this MTE? What the hell kind of impact do you think you are going to have when 1000 handsets are all re-registering to new port mappings every 60 seconds? Thats 20 registrations per second and each registration is a database write. So instead of asterisk doing things like, oh i don't know, Routing and handling calls, its spending its entire duty load having to write and re-wite entries in the ASTDB 20 times per second.

calls routing to the wrong phones is a common problem with too many devices behind NAT. You should also be afeared regarding running that many devices on the same network as the PC's for both quality as well as they are now tricking the phones into giving up their username/password/server info to place fraudulent calls on behalf of the victim.

I was able to get the phones to stay connected and my setting are as follows
Nat=yes
Qualify=yes

And I read that if keep.alive.interval is left null which is this way in MTE by default it is 30 sec
So I put an entry in the config to make this 25.

All is working now do you see a problem with this other than I need to find and plan to find a packaged solution for siproxd to install on customer sites.

Thanks

they arent cheap but I like the features edgemarc offers with their devices. The traffic shaping actually works (ive had many a promised traffic shaping not dynamically limit data). Additionally, if the customer already has a firewall, I can still stick the edgemarc in front and use its proxy-arp feature to pass traffic for its IP over to the firewall without having to do crappy NAT or anything. The firewall will think its plugged straight into the WAN.

about the only downside to edgemarc is the pricing. The 5 call licensing isnt so bad, but keep in mind that if one handset calls another handset, you have 2 'calls' going across your wan and subject to 2 calls of licensing.

this brings me to another point.. 40 handsets. That many handsets running on MTE has a strong chance that you dont have nearly enough bandwidth to support that many handsets, and if you do, would still consume a good chunk of it just to do inter-office calling. The likelihood of a large amount of inter-office calling increases as your handset count increases. When calculating bandwidth needs you have to not only consider 1 callpath across the wan link for every call to/from the PSTN, but also 2 callpaths for inter-office calling and 1 callpath whenever they call to check voicemail; none of which tend to get considered when they think they only make '5 calls at any one time'. That pretty-much rules out DSL since the DSL edgemarcs only license up to 10 call licenses. Cable connections may or may not work. In my region cable is a token-ring technology and all the bittorrent uploaders hog the tokens which results in audio discards from excess jitter. I would likely investigate the need for a dedicated T1 solely for their voice traffic. If you had 20 concurrent wan sessions (either 10 internal calls or a combination adding to 20), even with g.729 compression you're pushing half a t1 in bandwidth just for the phonecalls.

So for a 15 phone site the settings above will work fine?

As for the edge devices I will look into this closer.

Have you abandoned the siproxd units?

well the siproxd application worked fine, but bundling it with pfSense ran into traffic shaping issues. If you dont have bandwidth limitations its great. If you have limited bandwidth and want to make sure a file transfer or other stuff gets choked out in order to preserve voice quality, it didnt do that great of a job at it. I had to use the traffic shaper as more of a bandwidth limited, restricting the data vlan to less bandwidth so that it could never take the full pie.