Vodia PBX

This post is as clear to me as the XML config from Cisco is...

Sounds like a problem with the 10/11-digit representation. If you have country code == "1" then use only 10-digit numbers in the dial plan.

Put the following file into the html directory: <?xml version="1.0" encoding="utf-8"?> <phone-settings> <holding_reminder perm="RW">off</holding_reminder> <user_ringer1 perm="RW">Ringer7</user_ringer1> <ring_sound perm="RW">Ringer7</ring_sound> <alert_internal_ring_sound perm="RW">Ringer7</alert_internal_ring_sound> <alert_external_ring_sound perm="RW">Ringer7</alert_external_ring_sound> </phone-settings> Check the log about what file is missing in the provisioning process. Could be "snom_320_custom.xml" or something like that.

Yes, in the regular log.

I assume you put the source IP address in the list of SOAP trusted IP addresses? Do you see this in the LOG "[5] SOAP: Need a professional license" or "[2] SOAP: Request from untrusted IP address"?

No need to record them. I think the link was wrong, try this one: http://pbxnsip.com/download/audio_tr_30.zip

Try locking the codec both on the trunk and in the Ports section. Maybe the restriction in the trunk is not enough (maxbe that option is kind of superfluous).

Okay, will be in the next version. What OS are you using? Would you try it out?

Yes that is a well-known problem. IMHO it is fine if the DND key is provisioned as button. The button profile must contain the dnd key, that might be the problem in real-life deployments.

Really strange. Attached is the RTP in the unsuccessful case. If Zoiper is supposed to detect the CNG? I can hear it loud and clear. faxproblem.mp3

You mean the ACK does not make it? What transport layer? I guess UDP? Maybe it makes sense to run Wireshark on port 5060 and record the signalling. It could be a problem with DNS SRV or the branch tags.

The CNG tone is repeated a couple of times, the receiver should be able to sense it... There must be something else. Can you get a PCAP trace and put it somewhere where we can pull it down and take a look?

If you like, please try http://pbxnsip.com/protect/pbxctrl-3.3.0.3159.exe. Please use the PnP mechanism to make sure that the phones get the right setup. Also make sure that the PnP firmware version is the 7.3.14.

Whow that is very interesting stuff!

Great!

Totally agree. We introduced the script that checks password for their "randomness". Unfortunately, due to a request from the sales front, we were asked to disable it in the default installation, so that a password like "secret" is accepted as a password (like "", the empty string).

Well, the DND option might be still available in the phone. However if it is read only, then the user cannot change it. The next version should contain a PnP that actually redirects the settings key to a XML screen, so that the user does not get to the screen at all any more. There is also has a DND item, and that could be controlled by the PBX.

Hmm. Difficult topic. Ideally the PBX would register the trunk on the gateway like it would do with a service provider; not sure if that's possible. In gateway mode, it is very difficult to find out from what trunk a call comes in (they are all using the same IP address). And it is difficult to tell the gateway which line to use on an outbound trunk. Maybe the Audiocodes has a special parameter for this. Does the AudioCodes manual say anything about how this should be done?

Yea. The Cisco phones seems to be a little "picky" with the provisioning. I believe jumbly knows the trick how to set everything up correctly for a multiple domain setup with Cisco phones.

Well, essentially you can set the DID numbers that the FXO should report for the respective line. Then on the PBX you can use the inbound trunk rules to locate the hunt group. Probably it should be sufficient to assign the right alias name to the hunt group. Another obstable could be to choose the right 10- or 11-digit format.

You could provision the DND setting on the phones and set it to "read only".

Did you set the country code for the domain? If that is the case, the PBX tries to be smart about the numbers. If you put a "49" there and use the area code (e.g. "40"), then a number like 00494012345 will be interpreted as "12345". Try to use the DID numbers in the way you would dial them from the phone. Maybe you have a problem with the matching of the numbers. In this case, you should see the INVITE packet coming to the PBX with the number (do you? what do you see?).

Release notes are not out yet. I think the biggest changes are Intercom and warning about the default password. Maybe also the way VLAN is being provisioned.

Do you have a chance to see where the router sends packets that come to port 5060? Maybe there is another device in the network that also uses port 5060 and opens a connection to the Internet - and then that port 5060 is taken already by the other device, not the PBX. Many routers have a way of seeing how the ports are allocated. If you are registering a trunk to a service provider, you will also see the real IP address and port in the Via header of the response. [Did I mention I cannot wait for IPv6? No more of these NAT problems.]

From what I read in this topic, you had to replace your old router with a new one and since then íncoming calls don't work and more. That tells me that something in the setup of the router must have changed. Maybe it is something simple like the PBX has a new IP address and the DMZ settings must be adjusted accordingly. But it might also be a problem like the new router is suddenly SIP-aware and creating a compatibility nightmare. It is hard to say from here what the problem is. If I had access to the router, I would check the DMZ, the provided IP address (DHCP) and if the firmware is the same, and if there is something else suspicious. I would also check the log file of the router for messages.