Vodia PBX

Well if *87 is run against the dial plan than that code is not part of the domain star code collection?! Check the codes of the domain, maybe something has changed there by accident. Although in that case the directed pickup should not work either. For *87 the PBX would go through the pickup preference for the extension, maybe there is something wrong on the extension setting.

Backup ist immer eine gute Idee. Allerdings sollte das Upgrade die Konten nicht beeinflussen... 5.1.2r braucht noch ein paar Feinschliffe, auch wenn eigentlich sowas nicht passieren sollte dass die Konten weg sind.

Well regarding installer you can as well take the version 5 installer. There is no difference. If you still have the version 4 pbxctrl executable, you can just copy it over into the installation directory. The files on snom.com with the version 4 images were deleted. We don't have a copy.

You don't need to change anything with opensips. The PBX sends out a request with the from-header tag when receives it sets it own to-tag, so that it can determine which calls is being addressed. The dial plan should just use a gateway trunk pointing to the SIP proxy. This trunk must be a global trunk. In the dial plan don't use the try loopback, just use that global trunk.

Hmm. Is it really numbers starting with 8? Remember that the mailbox prefix is usually 8. Maybe that is causing the issue. The other issue that comes to my mind is that the DTMF tones might be garbled up and so the PB receives multiple 8 instead of just 8. You should be able to see what DTMF tones the PBX has received in the log.

Stimmt denn die Uhrzeit auf dem Server auf dem die PBX läuft? Vielleicht ist ja das Telefon mit dem Server gepaart. Auf dem Telefon würde ich nichts ändern, sonder das lieber der automatischen Provisionierung überlassen.

Well the URI should look like this: Alternatively you can use a trunk and make sure that it is a global trunk (allowed to send calls into every domain). Then the PBX will look for the +30123456789 in all domains.

First if all make sure that you have the loopback detection turned off (admin/SIP settings). Then the PBX can accept calls with the same Call-ID and uses the tags in the From/To-header to differentiate between the calls. The PBX needs a clear indication in which domain the calls should happen. Ideally, the SIP URI contains the phone number to be called in the domain starting with a + and then at least 6 digits. It must also contain the domain name. Redirect is a bad idea. This is ending in a SIP RFC massacre that has interesting challenges, but just just costing us all a lot of time for troubleshooting tricky problems.

Oh. In version 4, provisioning was different than in version 5. The authentication was done using the certificates of the phone. That works only if you are using https instead of http. But I am not even sure if that's the whole story. The TFTP actually redirects the files to https://192.168.102.250/prov/snom760.htm (notice the prov in the path). The problem is that if you have different models, it all does not work properly and option 66 becomes difficult. Plus you might want to be able to provision also other manufacturers devices, but that was not a priority with snom ONE version 4. The other problem is that snom decided to change the default transport layer to HTTP. So you would have to put tftp://192.168.102.250 into the option 66. I think the easiest is to put that tftp URI into the DHCP server and make sure that the PBX is serving TFTP. In version 5 we have changed that approach and went back to using the MAC explicitly in the filename, so that also devices without TLS can be easily provisioned. It saves us all a lot of time.

The PBX TFTP server does not just send existing files, it also generates files on the fly, depending on the MAC address. That feature makes it possible to provision the phones. You can turn it off; however then you must make sure that the phones are using HTTP instead of TFTP to fetch their provisioning data. If you have option 66 under your control, why don't you just put http://192.168.102.250 there. If you turn SolarWinds off, then you also need to restart the PBX so that it tries again to bind to the TFTP socket. Also you should consider feeding a newer version to the phones. 8.7.3.25 has been released and that version seems to fix a lot of problems that we have seen with the 8.7.3.19 version.

It looks to me like there is another TFTP server running on the PBX host.

Weird. Did you modify any pages? Anything in the HTML folder? Anything in the webpages folder? Did you hit F5?

You need to have Internet access if you want to add something to the license. The activation is is just a token for the real license code that contains all the details of the license and it must be downloaded by the PBX.

Ich schätze das Problem ist dass die maximale Anzahl an Anrufen erreicht ist. *52 ist auch ein Call, also sind es insgesamt zwei Anrufe, da verweigert das System den neuen Anruf.

Those reports are generated inside the PBX. Unfortunately we can't use JavaScript here, so everything is pretty much hard coded. We did double-check the code, and at that point it is actually very simple anyway. But we did some optimizations on the underlying database engine that could have caused it; and hopefully the newer versions have it already fixed. Because of the randomness of the event it is hard to say, though.

You need to make sure that you select the right system before checking out. You will see the activation code behind the system name, and that code must be the same as the one that was already activated on the system. Then re-activate the license. If this still does not work, it might be because the PBX has lost it's internet connection to the license server. Also keep in mind that the number of trial licenses is limited. If you have used the CSTA license more than once then probably only the first one will work. If you need get another CSTA license send us an email and we'll make it happen.

Einfach als muster !E!-! eintragen. Das bedeutet: Wenn das Muster E (Ende) gefunden wird, wird zu "-" umgelenkt (was auflegen bedeutet)...

Das ganze haben wir sowieso massiv auf HTML5 umgestellt, 5.1.2r hat es bereits eingebaut.

*52 sollte eigentlich funktionieren. Zuerst muss das aktuelle Gespräch gehalten werden, dann *52 anrufen. Tschuldigung für mein schlechtes Deutsch ...

yes in newer version we have added a log message if the format is not what the PBX expects. At least it saves the time to figure out what is going on.

In version 4, when you upload a file through the web interface it will "land" in the audio_moh folder. The big problem with that is that it will overwrite files that have the same name (even the pre-installed files). Make sure that you choose a file name that does not exist in the audio_moh folder before uploading a new one.

No, for extensions it is always midnight--whatever that is. Timezone depends on the extension. When stepping through the call list, there is not much difference between 13, 12, and 11 o'clock (in 24 hour format, which it is internally). So it is hard to see why the 12 would make any difference. If the problem would be around 12 AM, well then it would be a much more obvious problem. Because the CDR is written at the end of the call, there might be some minor misunderstandings around midnight; but not at noon.

At what time is the email being sent out? The PBX needs to determine the term "previous day" and does that by subtracting 12 hours from the current time, then getting the year, month and day of that time-stamp. The current time should be close to the email sent time, so that might serve as a clue. Other reasons can be that the CDR is simply not there any more. There is a system settings that tells the PBX how many CDR should be kept in total. When that number is hit, the PBX starts deleting the oldest ones and that could also delete records of the previous day. Make sure that the total number is sufficiently high.

Oh. Yea there something has changed. Thanks for pointing that out, that could be really the issue!