Vodia PBX

Well, without being a ATA expert IMHO it all comes down to the simple question if the PBX ports are publically visible (inbound) and the PBX knows about it (advertizing the right address on outbound traffic/SDP). Having a public IP address for the PBX on a configured interface makes life so much easier; if you have to play tricks with NAT you pay the high price of trying to fiddle around and end up in a potentially instable system. It is like the question can you ping the PBX? Which means does the packet make it to the PBX and does the response make it back (netmask, default IP gateway). One beautiful day we have IPv6 in place and having a couple of IPv6 addresses for the PBX will make life so much easier.

Where does it register? It tries to register, but it gets rejected. Later, the call does not come from the registration, it comes from an unbound trunk (open to receive calls from anywhere). For example, if you advertize your PBX in ENUM this would be the way to go. The caller will be able to call only whatever you set up for the handling of calls coming from the trunk, usually only internal numbers, no outside numbers. That means the caller will not be able to abuse the trunk to place calls from your system.

Your trunk seem to lack an outbound proxy, that might be a feature if you want to receive calls from everywhere. Also, you need to amke sure you have good passwords, otherwise the automatic blacklisting will not help you at all. If you run your PBX on public IP locking it down is essential to make sure you are not included in a "least cost routing" scheme!

Seems like OS 10 does not support the POSIX call to get the the time (that's where the process terminates). But there is a workaround that we will put in and that should IMHO solve the problem.

I guess this might explain the problem: http://www.wand.net.nz/~smr26/wordpress/20...me-in-mac-os-x/

We are not in the bounty business. But lets see if get the problem solved without a bounty. So let my try to understand what the problem is. Looking at the INVITE packet that the PBX sends to the gateway or service provider: From: "1234" <sip:1234@itsp.domain.com;user=phone> To: "4567" <sip:4567@itsp.domain.com;user=phone> P-Asserted-Identity: "2345" <sip:2345@itsp.domain.com;user=phone> P-Charging-Vector: 9876 So what you want is this: From: "1234" <sip:1234@itsp.domain.com;user=phone> To: "9876#4567" <sip:9876%234567@itsp.domain.com;user=phone> P-Asserted-Identity: "2345" <sip:2345@itsp.domain.com;user=phone> We already support RFC3455 (P-Charging-Vector) and this one depends on the trunk, so essentially my understanding is that there should be another way of indicating the charging vector?

The key might be here that you should set the country code in the domain settings. Then the PBX will present the dialled number in the NANPA-typical format, meaning always 10-digits for domestic numbers and international starting with 011. That makes it easier to set the dial plan up, no matter what the user will dial later (10 or 11 digit style). You can see the PBX matching the numbers if you increase the log level to 9. Don't forget to lower if after the job is done...

My problem is that I have no idea what is the difference between the different Mac versions. My guess would have been that they all work the same, but obviously that is not the case ... We need to wait until there is someone in the office who knows about the details. In the meantime, you can checn other posts in the Mac section of this forum. I know there are a couple of installations that work fine, but I don't know what is the difference.

Just log in, go to the license page, accept the license agreement and then select "evaluation copy of the product". Then you should be all set. You can register up to ten snom phones or two third party phones, or if you want to use the good old snom soft phone phone check out this link: http://www.snomindia.com/snomsoftphone.htm

You just need to be a little bit careful, because usernames in SIP are case-sensitive (wasn't out idea!). Also, AFAIK the hash symbol needs to be escaped, the PBX should automatically take care about this. Maybe it is something "stupid" like this...

Did you assign the right dialplan to the domain/extension? Maybe just turn logging to level 9 and see what the PBX says in the log file...

That should all be fine. Do you get emails from the PBX? Make sure that you get emails for important events. For example, it could be that the PBX starts blacklisting IP addresses because users entered the wrong password and then they are locked out for some time. I would just update to a newer build, like 4.2.0.3958 (backup first, you have plenty of space left anyway). If you are using extensively TCP (SIP/HTTP) there were issues in this build, thought I doubt there were too serious, it could help doing an upgrade. Do you have a good password set for the admin? Of course noone should be able to log in as admin and do bad things. The other thing coming to my mind is the Windows firewall that could kick in for whatever reason. Make sure that the PBX is a trusted process and that the firewall does not cut the network connectivity from time to time... Maybe the same thing applies for virus scanner that thinks the PBX sends out SPAM emails. This windows setup should be very very rock solid.

You mean something like this: http://kiwi.pbxnsip.com/index.php/Callcentric. Maybe just open a new topic for this instead of appending it to this one...

Usually there is no need to manually touch this configuration file. Only if you forget your system admin password for example you have to edit this file...

That is a message at an early point in the startup procedure. That means that something very fundamentally went wrong. This is not about ports, this is about some fundamental issues with the platform. Someone needs to take a look into this on Monday.

AFAIK that is not possible right now. I guess we have to add a dropdown to the dialplan that selects a service flag when the entry is valid. Deactivating the dial plan completely or disabling the extension will have problems with emergency calling.

For the snom ONE build, that means registrations from devices other than snom.

This is XML. If you like, you can add line breaks either in CRLF format or just in LF. Or none. It does not matter. There are XML readers available (for example Internet Explorer can do that) which can present you the file in better readable format. Because usually human does not read it, we thought it is not neccessary to beautify the output.

There is a old article on this subject, see http://kiwi.pbxnsip.com/index.php/AVM (kiwi because we took the wiki offline). Maybe this already solves the problem.

Start it manually with "./pbxctrl-xxx --no-daemon --log 9 --dir ." and look at the output. Probably there is a conflict on one of the critical ports (SIP/HTTP/HTTPS), so that the service cannot start up.

Oh, okay. That sounds like a complex setup. Try to catch the traffic on the PBX, then we can see if there is something going wrong.

There are no differences except the license stuff. As we are making new builds, those all come from the same code basis.

You have to find the root of the problem, the PBX should under no circumstances crash. I would check: I guess the rest of the server is still working okay? Then we can rule out general problems. Do you have enough hard disk space left? Maybe you have too many CDR in your system (check the file system space that is being occupied in the working directory of the PBX) What OS are you running? And what version are you using? Depending on the OS it might make sense to enable a core dump.

Are you sure the PBX is involved? I can't spot a User-Agent string with something that looks like the PBX...

Should be visible in the web interface in the menu mentioned above.