Vodia PBX

That is a very debatable view... Most service providers will not accept a caller ID except one that is on the system. Otherwise just pretend that you want to call back President Obama and the PBX should present the caller ID of him? If the carrier will allow this then we will see a lot of funny caller-ID very soon...

What version are you using? Maybe you are using a version that does not support more destinations. However, check the content of the xx.xml file in the attendants directory. You may "hack" this by just writing the file there into the xml file--also requires a restart. But this might save you from upgrading the system.

It is for Wireshark. Just grab the traffic on port 5061 of the PBX.

You definitevely have to restart the system to pick up the new prompts. If you also have a English directory, copy the prompts also there (even if they are actually Spanish), so that the PBX can find these files.

4.0 changes the way certificates are being handled. Maybe you have to import the certificate again. If it still does not work, can you get a Wireshark trace?

Check out http://forum.pbxnsip.com/index.php?showtopic=3522...

Right now the DTMF logging just contains the DTMF, but no link to the call. Usually you can see in the next line what action was taken (if at all) after receiving the DTMF. This is sub-optimal. We need to include call-related information; but if we do this just for the DTMF, there is still no link to the call. We need to clean this up in the next version. For now, you have to dig your way through the log and see by the context which call was issuing the DTF.

Put the address of the service provider into "Explicitly list addresses for inbound traffic", for example "12.32.12.32" or a DNS A/AAAA name like "sip.proxy.com".

Duplicated it... There were some superfluous line breaks in the file that broke those settings. Next build will have this fixed.

I did a quick try here. If I am using the "Explicitly list addresses for inbound traffic" then it works; without that setting I also get not found. We changed some things in the way the PBX treats trunks. Previously, the outbound proxy was also the inbound proxy. That caused a lot of confusion, so we decided to add an explicit setting for the inbound traffic. Seems for "normal" domain trunks that algororithm is backward compatible. But for global trunks it does not. Will further investigate; but setting the inbound addresses seems to be the solution for global trunks now.

The problem is that in the newer snom firmware, the username cannot contain the "@" sign. Believe it or not! In snom phones, you must use the form "40;domain=pbx.company.com". In other words, instead of "@" use ";domain=".

In the extension settings on the registration tab, there is a flag "enable call waiting". If you turn it off then the PBX will give you a busy signal when the extension is already talking.

Paging with multicast is currently a no-go. I don't know any deployment where multicast packets would be sent into remote locations. What might make sense is to send the paging to a unicast address which then gets routed to a multicast address in the CPE LAN. Not sure if that would require an application running on CPE, or a tricky router setup could achieve this as well.

Could this be an upgrade problem? When there are new feature codes in the upgrade, the PBX does not automatically fill them in. If you create a new domain, then those codes are automatically filled in.

Something got screwed up. Should be working in the final release image.

I don't think so. You can verify with Wireshark and see the IP headers.

In any case, try to use 8.2.29 this is the "officially" released firmware now. You can delete the pnp entries in the working directory and restart the pbx to make this happen easily. We'll take a look anyway. Maybe something else got screwed up.

That sounds very complicated... Maybe just tar or zip the cdre directory and send me a private message how we can download it...

Which phone and which version are you using?

If it only happens with one specific phone, then there must be something special about it. Mabe it is the only phone which is behind a special firewall, or is has a different firmware, or maybe you just need to factor reset it and re-provision it.

I also have difficulties to see the sorting here. Any chance to see the XML records that correspond to the calls? That is what the PBX is using internally. Maybe it is easier to see the problem there (you can use grep in Linux or findstr in Windows to search in the cdre directory). We had this issue some months ago and my personal call log makes sense; I was under the impression it was under control.

Yes, this is strange. This should be really a easy fix.

Not sure what is cheaper: Upgrading Exchange or using the fax program...

The biggest fix is that the delayed reading of the large tables could screw up the start sequence. This was a new 4.0 feature, so it will not pop up in the release notes for 3 to 4... The other things that worked on was the loopback call (try loopback), the feature code list in the user interface was incomplete, there were problems with recording of calls (double recording), also double CDR entries. And the web interface thread could get into and endless loop if the client disconnected the connection at the wrong time.

It is definievely sorted--however it might not be so obvious what field it is. It could be as simple as the order in which the calls disconnected (which is not neccessarily the order in which they were started). And keep in mind the newest call is at the top, not the bottom.