Vodia PBX

Hmm. So your billing platform bills based on IP addresses. That means you want essentially trunks to be bound to specific IP addresses. That will be difficult... We would have to introduce a seperate socket for each trunk (okay, it would also solve problems with the identification of inbound SIP traffic, but so far we could always work around). Any alternatives? Check out ICID (RFC 3455), I think that is a very simple and very effective way of identifying what trunk was used for a call. If you can change anything on the billing platform, that would solve the problem.

You'll need a network that can carry VoIP traffic. For each call, that network must be able to transport 80 kbit/s in each direction of the call. Ideally, you set up MPLS connections between the PBX and the branch offices and run the phones in their own VLAN with priority set higher than the other VLAN. But there are also other possibilities. For example, you can just rent another Internet access for VoIP, so that you physically seperate the data and voice traffic. Just having a regular Internet connection that you share with other applications like email or www will result in a very bad call quality and overall frustration. For the PSTN termination you'll need a PSTN gateway or a SIP service provider (SIP trunks). PSTN gateways are easy and safe. However, SIP trunk providers usually give you better rates and you don't have to run a PSTN cable into your office. Also, SIP trunks are usually better in detecting Caller-ID and hangup detection. If you want to include analog devices, you also need to think about FXS gateways (usually called ATA). For example, FAX uses such devices. When you want to send FAX over the Internet, you must make sure that both the PSTN gateway and the ATA supports T.38. Otherwise, FAX will get stuck when a packet gets lost. We also recommend to have some kind of network monitoring tool. In a setup with several hundred seats, you want to know what is going on. Otherwise, you will have a hard time getting the system working in a stable fashion and your users will send you bad emails (especially if they cannot call you).

Well... Today NAPTR is practically non-existant. The PBX should sort after the priority, not sure what'S wrong here... But IMHO the best way to deal with this is to avoid NAPTR at all. It is asking for trouble, and we don't want that!

Ops, you are right. One step forward, one step back. Will be fixed in the release.

Well, in gateway mode you can use the "domain" name to present something else than "localhost" (for example, you can put your public IP there). Always use the outbound proxy! Broadvox also changed their software a lot, there is no need to turn UUID off now any more. Registration mode has the advantage that you can register easily; but the caller-ID presentation is more difficult. Therefore I would tend to prefer the gateway mode. You can switch the trunk in the PBX between gateway and registration mode either during the setup or later in the select field when editing the trunk. BTW I think it is awesome that Broadvox supports both register mode and gateway mode. I see you like to good old stuff. Consider moving to the latest (maybe first with a 3-minute demo key, get it here: http://www.pbxnsip.com/trial). A lot of new feature and improvements over the last couple of years!

The problem is the failover in the dial plan. Not a big problem, but we don't want to bring new features into the 3.1 release at this point.

Well, maybe then they should also start support calling two registered devices on one extension...

Well, then you need something that converts this into plain audio. We ran a MP3 player that supported Internet radio for some time and had to find out that this thing had a memory leak that eventually brought the host down...

Probably a problem with the license. In 3.0 you need the recording license for this. In 3.1 we split this up into a "full" recording license and a adhoc-recording license. The adhoc would be for the user-initiated recording that goes into the user's mailbox.

You can set the address of the time server in the pnp.xml file in the setting "ntp_host". See http://wiki.pbxnsip.com/index.php/Global_Configuration_File on how to change that setting without having to change the pnp.xml file or restarting the server. In the new versions of the PBX we will include a small NTP server that can also be used instead of a public NTP server. This way we get rid of such problems.

Hmm, is that the right bootrom? I remember it should be something like 4.x for SIP version 3.1.1 of Polycom?

What format are they supporting? Do they support RTP? What codec? G.711? Then that should be possible. You can also have more than just one RTP MoH source, and then you can assign it to different domains.

No, not really neccessary to fix it. There are two parts in the PBX, a lower part doing the SIP work and an upper part, doing the application logic. It can happen that they get a little bit out of sync - for example the upper part responses to a registration request while the lower part already removed it. In such a case the lower part would complain that the registration parameters cannot be applied. Such a case gets more probably when the upper part takes a long time to process requests. I would only be concerned about this if the overall CPU load gets too high and the system is on the edge.

The "CDR Tool" is/was a collection of PHP scripts that work with mySQL. IMHO it went too much into "spaghetti". If you can wait a little, then I would say the option to use direct writing into mySQL sounds more suitable to me...

Yes, the seperate extension will solve the problem. Yes, this will require more licenses (think about the margin that you make, hehe). If they are buying another PBX license for the branch office, maybe it is possible to make a package deal, so that the costs are not exploding. Today I would technically solve the problem with just more extensions and do a deal with the licenses. We have to check how much side effects it would be if we allow the trunk destination to be either an account or an external number.

Whow maybe Sprint is now also using VoIP and they are mixing ports up? Haha, just joking. Another easy thing to check would be that you have enough RTP ports. Having 1000 RTP ports does not hurt, even if you have far less calls. If the problem does not go away, you might have to start Wireshark (maybe rotation mode) on the system. This will involve some data mining, but then the root of the problem will become obvious.

Probably no restart necessary!

Regarding the CDR you can do the following things: Keep them on the PBX Use the SOAP method to push the CDR out. That requires that you run a SOAP-enabled HTTP server somewhere in your network that parses the messages and then processes them (possibly put them into a local DB). Use the "Simple CDR" method. This essentially avoids the relatively complicated SOAP method. Instead of writing and setting up your own software, you can use existing software like Metropolis that will process the CDR and generate the reports that you like to have. You can receive the CDR in a daily email. This can be done on per-domain basis or per-extension basis. I know that the CDR topic is important. We are thinking about two more options: (1) Appending the Simple CDR to a file just like we do with the log file. The file name may include the day name, so that you get one file per day. (2) Writing the CDR natively to a SQL database (probably mySQL first).

Hmm. If the caller calls a resource on the PBX (say an extension, or an auto attendant, or something else), the PBX is able to involve outbound calls. For example, when calling an extension, the PBX can fork the call also to a phone number. Or when calling an auto attendant, the call can also be redirected to an external number. So far, that seems to make most of the users happy. The only "problem" we had so far was Microsoft Exchange and it's click to dial feature. Because then the call comes in on the Exchange trunk and it is supposed to go out on another trunk. That problem we did solve with the "Accept Redirect" flag and the "Assume call comes from extension" setting. In this case, all calls from that trunk are redirected to an outgoing number - even if the call might go to a local resource. I believe your problem can be solved just by using the "redirect all" feature of the PBX. Just use a local extension and then redirect all calls to the PSTN number.

The items are the internal representation of the functionality described in the Wiki. There is no extra description on how these items are stored in the database. And IMHO you should not touch it, as it is "subject to change without notice"...

Do you have the account set and/or username in the trunk? What trunk type are you using?

Okay... Some service providers give you an IP address only for one day. This is because they just running out of IPv4 addresses. When they change the IP address there is a "hickup" in the network that would explain why you get the warning from the PBX. That is fine. I believe SonicWall is a pretty reliable device. So I would think that the refresh time is too short. Check your admin settings for "UDP NAT Refresh" and consider making it shorter. Also check the settings of the Firewall - the SonicWall has a lot of them and maybe there is a setting where you specify how long to keep a NAT binding alive.

This is usually a sign that there is a port conflict with RTP. For some reason, two calls point to the same IP port. This might be caused by the router (if it is buggy) or maybe the carrier has a problem there (less probable I would say). Some routers have only 32 NAT entries, and if you have too many NAT bindings you may have an effect like this. How to troubleshoot this? Difficult. If you have a cheap router, I would just try another router from another company and see if that changes anything.

Can you elaborate on what a transit call is?

If it happens every couple of minutes: Yes, either your refresh time for NAT is too long or you just have a router there that is not suitable for VoIP. If it happens once per day: The carrier is rotating IP addresses. There is nothing that you can do apart from mailing them and asking them when you can have a IPv6 address...