Vodia PBX

There is still an old API available where you can mess with the internal tables, see http://kiwi.pbxnsip.com/index.php/Access_to_the_Database. However as we are moving more and more to the new REST interface, and depending on your timing, you might want to wait a few more builds and then just use REST.

While we are waiting for a new firmware, it is time for a better workaround. For now, we will not provision the star code any more, and rely on the feature synchronization. All in all, this seems to be the best solution. At least we don't get calls when the user changes the DND state.

In the park orbit, you can choose your MoH source. You can also select if want to hear just a short tone or the park orbit announcement. Right now we don't have audio prompts similar to the ACD. I agree, this is something that makes sense to add as well. Workaround is obviously to create a WAV file that includes the prompts and then use that as the MoH source.

If you need help with 3CX you should actually post the question on the 3CX forum.

I guess you want to ask this question on forum.snom.com?

There is a problem with the snom phones. The synchronization of the DND and redirection state between the PBX and the phones make the phone send a redirection, although this must not be done on the phone (this is done on the PBX). Yealink, Grandstream, Polycom work this way. There is a trouble ticket open with snom for a couple of moons and AFAIK it will be included in the next firmware release. If you want to test a beta firmware or get the release date, please contact snom for details.

Well, snom ONE does not support session timer (the RFC). But the RFC says you don't have to support it. Session timer is only useful when the PBX has no other means to see if the session is still alive. But the PBX checks every few milliseconds, because of the RTP awareness. So there is no need for session timer. The problem with the session timer is probably a wrong implementation of the RFC. But we need to take a look at the trace what the problem is.

because users accidentally enter that in the wrong field in the web interface? I would kill that rather in the JavaScript in the web interface then...

Go to https://snomone.zendesk.com ...

Hmm, was 4.3 already a snom ONE image? I don't remember there were ever images made for the CS410. On of the main point of move from pbxnsip to snom was to allow only snom phone registrations. That's when you get that message "3rd party registration licenses exceeded". About the blacklisting: I would just white-list the SPA IP address, then you should not get that blacklisting message. The demonstration license key does not expire. The only problem with is that technically it is only a demo key, not for productive usage. Whatever you do, make sure that you have a backup. You can also log in to the CS410 with SSH and tar the working directory. This is better than using the web interface, because it includes all information.

Can you open a ticket on that one? Please include the SIP trace, filtered by the IP address of the provider.

Take a look at the BeagleBoard. This one has a better power supply connector, and the price difference is not that much compared to the Pi and it has enough memory to run the PBX. The form factor makes it possible to put it into a good-looking housing. Maybe you have a 3D printer in your basement!

There is a difference between call forward and cell. In the first case, it is just the extension paying for the call; in the latter it is the extension being on the call (and paying for it). When you forward a call, it should not be possible for the connected party for example to hold the call and then go into the extensions mailbox--the mailbox of the extension who paid for the redirection.

well with all the talk about the NSA happening right now it must be seen as a product feature not to have any backdoor. You must have physical access to the device, I think that is the right approach. The explanation how to perform the factory reset is difficult to understand, and it is also difficult to write. The reset button is checked in a shell script, which you can find in the working directory of the PBX. It was made publicly readable, for example to give resellers the possibility to change it (for example, to make sure that in areas with public access, people are not factory-resetting the devices). The following code shows what is going on: #! /bin/sh led=/sys/class/leds/guruplug:green:wmode/trigger ints=/proc/interrupts wdir=/usr/local/snomONE ownname=$0 function factory() { for i in *; do if [[ "$i" == *.sh ]]; then continue; fi if [[ "$i" == pbxctrl* ]]; then continue; fi if [[ "$i" == audio_* ]]; then continue; fi if [ $i == "restore" ]; then continue; fi rm -Rf $i done cp restore/interfaces /etc/network/interfaces cp restore/shadow /etc/shadow sync sleep 1 sync } cd $wdir read v1 <<< $(awk '{if($4=="gpio_btn")print $2}' $ints) while [ 1 ]; do # Read the key read v2 <<< $(awk '{if($4=="gpio_btn")print $2}' $ints) if [ "$v1" != "$v2" ]; then # Okay, user has pressed the key. Now see if the user wants to # reboot or reset. Blink a couple of times, if the button gets pressed three times it is a factory reset otherwise a reboot l=0 c=0 while [ $l -lt 20 ]; do echo -n default-on >$led sleep 0.1 echo -n none >$led sleep 0.1 l=$[$l+1] read v3 <<< $(awk '{if($4=="gpio_btn")print $2}' $ints) if [ "$v2" != "$v3" ]; then c=$[$c+1] fi v2=$v3 done if [ "$c" = "2" ]; then factory fi /sbin/reboot # Don't leave the loop any more: exit else # Wait a while sleep 1 fi v1=$v2 done

We are waiting for a new firmware release .

Well, I guess this is a limitation of the service. I guess Skype does not want to be responsible for caller-ID spoofing. Actually, many service providers have that problem. The PBX uses the In-Reply-To header (see RFC3261) to give the provider the chance to verify that the caller-ID is *not* spoofed. However even though it is in the SIP standard, the support is very low for this.

Those file were on the snom web server and have been removed there. We did not receive copies. Anyway, I don't see a reason to stay on the 4.3 branch; if you want to stay on version 4 you can as well skip to 4.5.1 which has a lot of bugs fixed, including the one in this thread. The 4.5.1 build are available from the wiki.

Oh. Did not see the version in the text spaghetti above. It could be that the PBX has to suppress the call quality metric in the SDP to get it working; that was added in some 5.0.x version (many service providers actually have that problem). Maybe install a version 5 (free) on a test host and get the trunk working; then you can copy & paste the setting into the version 4 to see if that solves the problem.

Did you set the trunk up using the drop-down in the page for setting up trunks? Then all settings should be automatically right.

Well, the setting is about suppressing the MWI, even if the phone subscribes for it. What you need is a entry in the registration overview on the bottom of the page. There is probably an entry for REGISTER, what we need is something for message-waiting. If you manually set up phones, be prepared for a long (costly) learning curve. SIP phones are a far more difficult to set up than analog phones. You might save a few bucks on buying refurbished old Cisco phones, but it will cost you (and us all) a lot of time to get them working.

Is that limited to Cisco phones? Maybe you have a very old MWI sitting there on the phone which never gets updated. In the log, try to filter SIP packets by the IP address of the phone. There should be SUBSCRIBE messages going back and forth sometimes, with message-waiting event type. If not, then you need to double check your phone configuration. Unfortunately the way SIP is specified, MWI is not included in the standard registration and you need to have an extra dialog between the PBX and the phone for that.

Can you see in the registrations tab for the extension if there is a message subscription? If not, then the phone did not subscribe for MWI, which perfectly explains why it does not work.

We had an issue with too many Polycom phones on an older PoE switch, where the phones were behavior erratic, especially with long Ethernet packets. Swapping out the switch solved the problem, or having less phones on the old switch. But if the PBX sends out a CANCEL, it should be possible to figure out by looking at the logs why it think it had to cancel the call. I am pretty sure that the power supply of the PBX host is not the problem here.

We had seen the iPad adaptor, which is at the end still an iPad. The phones seem to be new. No plans yet. We'll see what the market feedback is!

Hmm... Good point. Looks like we have to add another settings to the trunk!