Vodia PBX

the new version needs another DLL, we are working on it... Apart from that we had a case where an automatic restart around midnight of the service was causing the issues. Sometimes the service was restarted before the email got out, sometimes after that. Generally speaking, the service should not be restarted at all; in order to accomplish failover, it is better to keep the service shut down, keep the file systems in sync and then start it when the failover event happens.

Wir haben ja sipgate im drop-down mit einem wohl einigermassen funktionierenden Setup. Kompliziert wird es (nicht nur bei Sipgate) wenn man mehrere Runfnummern darstellen will und wenn man bei Rufumleitungen die urspruengliche Nummer anzeigen will. Den meisten scheint das wohl egal zu sein. Wir haben leider keinen Test-Trunk um das mal eben auszuprobieren. Aber wenn ich den Text da oben richtig lese, machen wir es bereits richtig. Vielleicht ist das Problem nicht der Trunk, sondern generell dass die ANI nicht richtig eingestellt sind.

Well, I would then guess 90 % firewall issues! If not more. Maybe they simply run out of UDP ports.

Set the NTP port on the PBX in the port settings. That change requires a restart of the PBX as far as I remember.

You can also control what the carrier will see. For that the trunk has the setting "rewrite global numbers". I know 5.1.3 changed a couple of things, and the trunk area keeps on being dynamic. However the normalization is important in order to make it possible to call international numbers without problems.

Gibt es denn irgendwo von SIpgate eine Aussage wie sie es denn gerne hätten?

Can you check what is in the "generated" folder? There you see the setting for the NTP server. Check if the settings there make sense.

Seems you got some devices that were obviously already used by some other customers before... I would report this to snom, so that they can track this down and make sure that they can fix this in the distribution channel. Apart from that, forum.snom.com

You can use either an external NTP server or the PBX can also act as (simple) NTP server. If you put an address into the "NTP Server" field (admin/ports), it will hand this out to the phones, Otherwise put in a port for the NTP Port, e.g. 123 and the PBX will provision to use the PBX as time server. You can always check in the generated folder what has been provisioned to the phones. Very useful to troubleshoot the provisioning.

I think you need to specify the --exclude options before the directory that you want to tar. tar cvfz name-of-backup-file.tar.gz --exclude 'audio_*' --exclude recordings desired-directory

Well, we are kind of shrugging our shoulders. We have changed something in the template that had to do with the LED; But I don't think that can have any impact on the phone not properly booting up. Maybe the phone is just getting old and sending signals that it wants a hardware upgrade . Do you have other phones in the network that are newer?

4.1 is so ziemlich das Maximum was man erreichen kann. Das liegt daran dass G.711 nur 4.1 erreichen kann (CD wäre dann wohl 5.0). G.722 bietet 4.2, hat allerdings das Problem dass beim Übergang ins Festnetz die Qualität deutlich runtergeht. Wenn die Verzögerungszeit größer wird, nimmt MOS ab; auch wenn Pakete ausfallen.

We have added more logging in 5.1.3a and changed the way the CDR are being deleted. If you want, you can try upgrading to that version (before that: backup and let us know what OS you need).

Well, we found out that some changes that we made for the 3xx phone template were not so good and it caused probably more damage than it helped. Please try to save the attached file into the html folder and re-provision the phone (restart not necessary). After the next upgrade, don't forget to delete the file again. (edit:) snom_3xx_phone.xml

The SPA is a ATA, no buttons... We still have a SPA942, not sure if it is worth trying that one out. It is probably necessary that we get a SPA525G to try this out.

We had a customer where removing the pnp parameters and the certificates solved the problem (and restart the system)--although I honestly don't know why that solved the problem.

The trunk has a setting (Rewrite global numbers) where you can tell the trunk how numbers should be read, but also how numbers should be written (it is the same setting). Choose NAPNA (10 digits), that should work with your trunk provider. Also if you have found good settings it would be awesome if you can share the settings, so that we can update or add the dropdown list in the PBX.

If you really want to totally reset the address book, it is probably the easiest to rename the adrbook folder and restart the service.

The Caller-ID topic is unsatisfactory in SIP. Originally the idea was that the phone shows the From-Header. However because it is not allowed to change that header during a conversation (at least not in the beginning), the companies started to do workarounds with Remote-Party-ID, P-Asserted-Identiy and INFO messages with sipfrag attachments. Unfortunately if you got it working with one phone type, it does not work with the next type. We have it on our to-do list to try another approach like now; however honestly this will not guarantee satisfaction.

In 5.1.3, there is a setting in the trunk that tells the PBX to record all related packets in PCAP files (per call). The files are written into the pcap directory in the working directory of the PBX. You need file system access to retrieve them.

Well the fix in next version will be 5.2. Right, the fixed-digit length match does not use the address book and there is no verification. This is really to keep track for whom the call was, e.g. for law offices where it is not so much about permission to dial and more about keeping track for who the call was.

Ok, Got it. The PBX is searching for address book entries where the CMC was "". That is not okay and we'll fix that in the next build. Workaround is to use fix length CMC; then it should be working only if the CMC is found.

LoL, Check out Google voice. The PBX does not perform voice recognition. If you are looking for Caller-ID you can use the file system.

Again you can put all those three IP in the list of explicit addresses. But it would not solve your problem. With TCP and TLS, the switch must know where the registration is and send it through that TCP and TLS connection. The point is simply, that the PBX is the TCP client and the registrar is the TCP server. This is like a wire between the PBX and the switch. You can put messages only in on the two ends, "injecting" messages is not possible. So if the PBX lets say is regsitered to server #2 and you want to send a message to the PBX, you will have to send it through the connection with that server #2.

Yes and no. From a trunk association point of view, it would allow it. The PBX really does a recursive lookup of the possible IP addresses, unless explicitly specified. However it has no relevance for TCP and TLS, as the registration is always connection oriented (unless the registrar starts opening new TCP connections to the PBX, which is unlikely in case the PBX is behind NAT). The reverse lookup is only interesting for UDP-based trunk registrations.