Vodia PBX

Well I am afraid that you have to do this when you are processing your CDR. The PBX does not separate parts of the number as patterns or prefixes. IMHO those patterns should be avoided whenever possible, but I know it is not always possible.

The trunk to trunk routing in V4 was a hack to get Microsoft LCS working. In V5 we have taken the concept further to make true trunk to trunk calling possible, so that the PBX has some features known from bigger "switches". The V4 hack was to assume that the call came actually from a specific extension; in V5 that is not necessary any more and both call legs are trunk call legs.

The trunk should have a setting for that ("Inter-Office Trunk"). You need to turn on "Trunk may terminate calls for remote systems" and select the dial plan that should be used. I think the documentation link above is missing that, we probably have to update the page on that feature.

Well for hunt groups there is simply no (simple) solution available. We would have to put the hunt group CDR on the users web page; then the question is if all hunt groups should show up there or only those who were received by the extension.

So you mean you want to leave the decision what trunk to use to the user (at the end of the day)? Are we talking about a few phones which could be handled as exceptions in the dial plan or a lot of them? For cell phones, depending on where you are on this planet, this may be possible in the dial plan (e.g. Germany) or not (e.g. USA). Usually the predictability has to do with the prices for call, e.g. in the US the caller does not have to pay extra for calling a cell phone number and there is no way to see before hand if this would be a call to a cell phone.

Well it can be the firewall. Generally, such problems can be troubleshooted by turning on "Inspect Element" after right-click on the browser window. There you should see if there are any JavaScript errors or network traffic problems.

There is some information on http://www.vodia.com/documentation/pnp_snom that can help you to provision the phones.

Thanks, good points. We'll put that into the backlog.

Well, the domains are well "sandboxed" from each other. You need to give them numbers that look like phone numbers, even if they cannot be reached from the PSTN. One way is to route them to an external SIP proxy that performs the routing; this method will work well if you scale your system up beyond one server. If you stay on one server there is the option "try loopback" in the dial plan, where the PBX will try to call another domain if the number exists there.

For snom phones, if you plug and play them, there should be a nice menu that shows you the options. For other phones, you can define a DTMF sequence that will trigger the recording; however those tones will be in the audio stream and the other party will hear them.

Right now there is actually no specific call history for a hunt group on the web interface. I remember you can send daily reports on hunt groups that will then list all the calls for that specific hunt group. But what you can do is to check the domain call log for calls; they should contain (also) the hunt group calls.

Well this is a frequently asked question. Key problems are: How do you dial 911? 0-911? 9-911? What if you panic and dial 9-11, will it end up at 11? IMHO unacceptable. If you received a call from lets say 617-399-8147, do you need to edit the number before you can call back? Which number do you store in your address book? 06173998147? How do you dial an international number? 00118612345678? Or 0118612345678? IMHO this feature is a relic from analog days that is causing more trouble today that it makes life easier. Choosing 9 as a prefix does not make things easier, especially dialing 911. Our recommendation is to dial numbers as they are. This has worked very well for the cell phones, and today 99.99 % of the users understand that they should dial numbers just like on their mobile phones, without the need of cryptic prefixes.

Media playback is a HTML5 feature. Most browser support that today; however the devil is as usual in the detail. The problem is that the PBX supplies a specific audio format which is not supported by all browsers. However as far as we can tell, it should work with Chrome (IE is the problem). Maybe you just need to move to the latest browser version and then it magically works.

These are different topics. If your browser "sees" a phone number, that is because there is a piece of software plugged into your browser that scans your content for anything that looks like a phone number and puts essentially a link around it, so that you can click on it and execute a piece of code that initiates the call. How that is done depends on the PBX obviously, and here the different ways of making phone calls are competing with each other sometimes leaving a mess. Some go through TAPI and others go directly from the browser to your PBX. If you want to synchronize your google address book with the PBX, that can be done in 5.2.5 essentially by you allowing the PBX to grab a copy of your google address book and put it on the PBX, polling lets say every hour. Then those addresses are inside the PBX, and you can use them for example from the web interface or even from your phone, if it supports LDAP. Embedding a piece of code in the web server that makes it possible to launch a new window that acts essentially like a soft phone. We are working on that. It will be released with the next build.

There is no limit. From a practical point of view, performance will suffer when you have more than 100 trunks. The number of dial plans should not matter; however the length of the dial plans could be an issue if you have more than 100 entries depending on how much work needs to be done to match all those patterns.

Call forwarding an extension does not affect hunt groups. Otherwise things would get very complicated and unpredictable. Call forward all is essentially like DND, it just takes the extension off the list in that stage.

Another possibility is to set the number of maximum messages to 0.

Rufgruppen interessieren sich grundsätzlich nicht für den Zustand der Nebenstellen. Die Nebenstellen bekommen ein Call Waiting wenn ein weiterer Anruf reinkommt ("Feature"), es sei denn dass das ausgeschaltet wurde. Das wird auch als parallel Ruf bezeichnet. Wenn Anrufer seriell verarbeitet werden sollen, ist es besser eine Agentengruppe (Agent Group) zu nehmen. Dort werden die Anrufer einer nach dem anderen zugewiesen, etwas so wie Flugzeuge am Flughafen landen.

That has been changed between version 4 and version 5. Customers were complaining that they had to buy a dummy extension to have admin permission and they were right. The admins are now part of the domain setup (in the domain list).

The URL above is 404 not found... SIP is a very hairy standard, lots of RFC and interpretations. The only thing you can do is try out. The good news is that the Vodia PBX tries to make it as easy as possible and not insist on certain RFC behaviors.

In theory it should work that way, yes. Workaround could be to speed dial it to *87xx (call pickup). Make sure that you are actually allowed to pick up the call...

The point here is that when the PBX sends out a mailbox message attached to an email, it can mark the message as "saved" (not new any more). Then as more messages keep coming in, older ones automatically get deleted. This makes sense if the user listen to the messages with their email client and not with the phone system.

That problem is called one-way audio. The best way to troubleshoot this is to generate PCAP for the trunk and extension involved and analyze it with Wireshark. http://kiwi.pbxnsip.com/index.php/One-way_Audio or http://kiwi.pbxnsip.com/index.php?title=Troubleshooting_SIP_Trunk_Problems

We also have the idea to present a 2D code on the screen that you can get with the video camera of the phone. However that currently is limited to specific soft phones that support that. What I like about the email message that contains the password is that the user will be the only one who sees the password. Ultimately we have to consider having a list of passwords with expiry dates, so that you can generate new passwords when needed without having to delete the existing ones.

Wenn das Telefon tatsächlich den Ruf aufbaut könnte es vielleicht sein dass das Telefon gehackt wurde. Ich habe sowas noch nicht gesehen, aber auch Telefone sind nicht unendlich sicher und vielleicht hat sich jemand Zugang zum Telefon verschafft. Die PBX kann das Telefon nicht dazu bringen von sich selbst heraus eine Nummer zu wählen; es ist immer die PBX die das Telefon anruft und nicht umgekehrt. Wenn die SIP-Pakete auf dem Telefon noch sichtbar sind sollte man das leicht nachweisen können.