What we did is sum up all minutes of all servers and all traffic. This gave us an average of 2 MB per minute.
So the GB count is just an estimate w/o taking codecs, audio bypass etc. into account. Actually low bitrate codecs create a higher load on our servers than G.711 because of their CPU usage. I.e. the rough calculation is not a bad measure anyhow.
• If the "audio bypass" option is used on both the extensions and the trunks, only the SIP messages will reach the PBXes servers. The voice packets will then go directly between extensions (UA to UA) or from extension to trunk (UA to B2BUA). This is the win-win scenario, both for call quality and bandwidth usage.
Here is an example to illustrate this. If two friends in Spain communicate, with an extension to extension call, and one of them has "audio bypass" set to No, every voice packet (RTP) has to loop via Germany before it reaches the other user in Spain. So even if they are physically in the same city, their packets have to go to another country instead of across town. Needless to say this drops the voice quality since the impairments grow with distance.
• The low bit-rate vocoders use less bandwidth when used, but increase the CPU load if and only if the PBXes' server has to perform transcoding from one vocoder to another.
It's a good idea to go over the trunks and extensions and verify their support for common vocoders. If both the extensions (for extension to extension calls) and the trunks (for extension to trunk calls) support common vocoders, no transcoding will take place in the PBXes server. Voice quality also drops a bit when a call is transcoded.
Although in theory audio bypass works on PUBLIC IP Addresses, if thetre is any NAT between either party and a public IP address, it is likely there will be some problems with audio bypass ON.
As an example, there is an office with 10 workers. Each has a hardphone on their desk connected to PBXes.com. It is VERY unlikely that each of these users will each have a public IP with no NAT. In this scenario Audio bypass will most certainly need to be set to NO.
STUN may halp on many systems, but it is not a fix all solution.