Vodia PBX

Skype: Most probably a problem with the certificate chain. If you are on 4.5, rename your certs directory and restart the PBX service.

Es könnte sein dass der Carrier die Nummer anders darstellt, das ist leider nicht immer ganz einheitlich. Ich würde die Log Levels mal hochdrehen und sehen was da vom Carrier kommt. Oder eben die Lösung über die Liste von Nummern wählen, wo man sich mit diesem Setting in der Leitung/Trunk nicht herumärgern muß.

Nebenstellen können nicht nur einen Namen haben, sondern mehrere. Normalerweise nimmt man kurze nummern z.B. "40", aber man kann eben auch lange Namen nehmen, insbesondere die "Telefonnummer" für die Nebenstelle. Die Liste wird durch Leerzeichen getrennt. Damit kann man jede eingehende Telefonnummer einer Nebenstelle zuweisen, z.B. "40 0221123456 0049221123456" würde dann auf "40", "0221123456" oder "0049221123456" hören. Auf Deutsch heisst das ganze "Nummer(n) für dieses Konto".

Oh, okay. Wie wäre es damit: !0800123456!123! !([0-9]{2})$!\1!10

Also, check out the domain setting for the trunk. There you can define what domain name should presented to the trunk provider.

Da würde ich !0$!123! !([0-9]{2})$!\1!10 vorschlagen (wenn für die 0 stehen soll). Oder einfach ein Alias für den Account für 0 anlagen.

Maybe just move the certs directory to certs-old, restart the service and let the PBX load all the certificates again. This is a 4.5 feature; if you are running an older version ask Pradeep to ZIP you his certs directory and send it to you by email.

snom Vision unterstützt keine "buttons" soweit mir das bekannt ist.

You can also click on the web interface on the certificate to view it.

Check if you have been black listed. If you can access the working directory, check the contents of the accesslist directory.

The night mode flags actually accept a list of service flags, seperated by spaces. So does the field for the redirection targets. So if there is a match lets say on the 2nd service flag, the call would get routed to the 2nd destination.

Yea it is still not clear what's the best version for snom ONE. So far we still kept it on 8.4.32; hopefully we'll soon see a version that combines the best of all 8.4 versions.

You can add just something like this: <rf>recordings/personal_ringback123.wav</rf>. Please notice that the tags in XML are case sensitive. Also, you need to restart the PBX to get this working (maybe try this out on a test system). And, as always when experimenting, make a backup of the PBX working directory so that if you screw something up, you can restore the content.

The settings are right now like this: <user_ldap_outgoing_phonebook perm="RW" idx="{lc}">true</user_ldap_outgoing_phonebook> <user_ldap_lookup_incoming perm="RW" idx="{lc}">true</user_ldap_lookup_incoming> <user_ldap_name_filter perm="RW" idx="{lc}">(cn=%)</user_ldap_name_filter> <user_ldap_number_filter perm="RW" idx="{lc}">(telephoneNumber=%)</user_ldap_number_filter> <user_ldap_name_attributes perm="RW" idx="{lc}">cn</user_ldap_name_attributes> <user_ldap_number_attributes perm="RW" idx="{lc}">telephoneNumber mobileTelephoneNumber</user_ldap_number_attributes> <user_ldap_display_name perm="RW" idx="{lc}">%cn</user_ldap_display_name> <user_ldap_server perm="RW" idx="{lc}">{ip-adr}</user_ldap_server> <user_ldap_port perm="RW" idx="{lc}">{ldap-port}</user_ldap_port> <user_ldap_base perm="RW" idx="{lc}">ou=people</user_ldap_base> <user_ldap_username perm="RW" idx="{lc}">{domain}\{account}</user_ldap_username> <user_ldap_password perm="RW" idx="{lc}">{web-pass}</user_ldap_password> <user_ldap_max_hits perm="RW" idx="{lc}">50</user_ldap_max_hits> If you are using PnP, it should work like this.

Actually, there is a setting for each user called "rf" (check the xml files in the users directory) and there is also a way to set this location in the domain (domains/nnn.xml xml tag "rb"). I am not aware about a way to control this from the web interface, but this should work for hunt groups, ACD, and for extension calls.

We need to address the fact that the snom ONE yellow and blue should have different default configuration files. The default.tar file can just depend on the license type. I agree with you it does not make sense to sell a blue with a 2 digit dial plan. Workaround right now is to set one Blue up the way you like it, then clone the configuration or domain for other clients. I share with you the frustration about the 7.1.30 factory firmware. To defend the snom team, I believe the reason is that there are still lots of other PBX vendors that certified that version and are happy with it. In theory, it should automatically upgrade to the latest version for snom ONE; another action item for the snom ONE plus box is that we need to copy the firmware images on the file system (tftp folder), so that the phones don't have to go to the Internet to upgrade to that version. We need to try out what happens when you plug a 7.1.30 phone into the network. Also, the 3xx series should finally get a certificate, which makes it easier to deploy phone over the WAN without the need of a password. I guess the bottom line action item is that someone in snom needs to grab a snom ONE plus, some phones from the factory, a router, switch, some analog PSTN lines, plug everything in and see what happens.

About the opt-out: The AA has a setting which extensions cannot be dialled from that AA. That also includes the dial by name feature. About the confirmation: Good point.

Something for the next upcoming versions is probably a dial plan for inbound purposes. We probably need to apply that inbound dial plan to every header that contains a useful Caller-ID, e.g. RequestURI, From, To and P-Asserted-Identity. The currente ERE-based list is a start, flexible, but not easy to undestand for the average PBX user.

Some people put their own ringback.wav into the audio directory to achieve that goal. The drawback here is that it affects all calls, not only the one to the specific group.

Ach so. Ich würde in so einem Fall einfach die letzten beiden Stellen rausfischen: !([0-9]{2})$!\1!10 Wenn die beiden letzten Stellen dann keine gültige Durchwahl finden, geht der Anruf dann an die 10. Alternativ könnte man den Nebenstellen die direkte Telefonnummer zuweisen. Der Name der Nebenstelle wäre dann z.B. "10 0221432410". Leerzeichen seperiert die Nummern die für die Nebenstellen gelten.

It is Linux and I believe a cron service is running, so it is up to you to add a script that does the magic. That is almost a religious discussion. IMHO OSX is not so much mainstream in the server world, but Linux and Windows are pretty mainstream these days and depending on your skills, you will prefer either one.

Strange. Sounds like an attack from aliens or what. I am not a big fan of that. The problem is if you accidentially entered the password wrong three times in the web interface, you are screwed. I believe reasonably secure passwords and a one-hour lock out duration are absolutely enough to defend attacks. If you have 8 digits with true 5 bits randomness, this is 40 bits equal to 1,000,000,000,000 combinations and each hour you have three tries, the expectation value for hacking one account would be 300,000,000,000 hours, which is more than 5 million years. For most services that is good enough... Most people make the mistake to choose extension 40 with password 40, and then are surprised that their system got hacked. Thats why we added the password policy and a warning sign next to the account to tell the admin that a user just refused to cooperate on a good password.

The way the PBX processes the list is by the netmask. It searches the more special entries first. So if you specify /0 netmark, this entry is processed last. So if you want to blacklist everything as a general rule, thats file. Just make sure that the subnet where you are coming from is already there when you add the general rule. If you screw it up, you can still go to the file system, remove the last added rule and restart the system.

Can you limit the log to SIP call messages? Otherwise there are so many messages that we cannot see the whole call context. Also maybe just do a guick try to set the "Remote Party/Privacy Indication" on the trunk to "No indication" to see if the problem is on the SIP headers side?

No blacklisting also works on the HTTP ports (80 and 443).