Vodia PBX

Yes that is correct. The upgrade to version 4.5 should be smooth with the exception of the SIP header representation in the trunks. There you might have to fiddle around a little bit. Please take a screen shot of the config in version 3; if the upgrade does not go smoothly there, we can help you settings the right settings on the trunk that work as previously in version 3 (if that is not happening automatically). And of course, this is as always an excellent opportunity to backup your working directory...

SIP says that the PBX may propose a value, but what counts is the value of the service provider. Because that can cause problems in NAT environments, the trunk has a settings that may override the response. That's the "Keep alive" field Mr X mentioned. If you put a number there, that's the number of seconds the PBX will wait before refreshing the registration no matter what has been set from the service provider.

Ops seems you are the first to find that out after two years .

Das Thema Rufnummernanzeige ist ein sehr leidiges Thema und leider kein Ruhmesblatt für den SIP "Standard", der hier nämlich sehr unverbindlich ist. Deswegen haben wir nach Jahren in den sauren Apfel gebissen und die SIP-Header Darstellung enorm flexibilisiert. Leider ist es ein Risiko beim Update auf 4.5 dass man da wahrscheinlich die Trunk-Einstellungen anfassen muss und wieder rumfummeln bis es funktioniert. Ich würde dennoch zum Upgrade raten, da 4.5 wirklich eine riesige Menge an Verbesserungen bringt, und abgesehen von den Trunks sind die Upgrades soweit eher unproblematisch verlaufen. Wenn es Probleme gibt, würde ich die Trunk-Einstellungen auf "No Indication" stellen (keine besondere Anzeige der Nummer) und wir können dann über HTTP-Login von snom aus helfen, die optimalen Einstellungen zu ermitteln. Welcher Provider kommt denn zum Einsatz?

Die PBX hat das Sagen. SIP kennt zwar keine Rollen wie PBX oder Endgerät; aber die PBX hält sich an die programmierte Reihenfolge. Das klappt normalerweise auch gut. Am Telefon würde ich auf keinen Fall "rumfummeln", die Telefone sollten über PnP konfiguriert werden. Ist denn alles im LAN? Falls ja würde ich auf jeden Fall G.711 (ulaw oder alaw macht da keinen Unterschied) wählen. Alles anderen Codecs verringern die Qualität hörbar; selbst wenn scheinbar bessere Codecs wie G.722 verwendet werden. Letzlich muss es raus auf das ISDN, und da wird G.711 verwendet. Bei einer Umcodierung von einen in den anderen Standard gehen immer Informationen verloren (Ausnahme ist zwischen G.711 alaw und ulaw, das sind nur andere Bitdarstellungen). Warum snom ONE plus?! Wenn das Gateway extern ist hätte es auch ein normaler Server getan...

Es ist in der Tat verwirrend. "Ein" bedeutet dass die Umleitung "ein"geschaltet wurde. Wen es stört, kann auf jeden Fall die Files tauschen.

No that's a feature. Because there are so many CDR, there is a special binary format for those entries. Background is that XML parsing cost a lot of CPU and you cannot just copy the contents because characters need to be un-escaped. TLV stands for Tag-Length-Value, and this is a primitive format to parse the contents of a stream.

127.0.0.1 does not look healthy. First of all, there must be something going on with the routing table on your host if it uses the loopback interface address on outbound traffic. If you know bash on Mac, "route" is the command that you can use to view the current route configuration. That will probably just get you the private IP address of the PBX, which is usually okay for providers like BroadVox. I would test a few times and see if the private IP address shows up all the time. Maybe your problem is solved already then. If it does not work properly yet, you have to "pretend" that the PBX is running on a public IP address. There is a global settings on the PBX called "IP Routing List" (admin/settings/ports) that you can tweak to manipulate the IP address which are being presented to the outside world. http://wiki.snomone.com/index.php?title=Server_Behind_NAT shows you how to use this setting. But again, I would check first why you see 127.0.0.1, may guess is that this is screwing things up.

The problem is probably that the Request-URI contains not the destination number as with BeroFix. But that can be easily fixed on the trunk with the settings "Send call to extension". There are some examples on http://wiki.snomone.com/index.php?title=Inbounds_Calls.

It actually seems that netborder express grabbed port 5060 on the system. This seems to be a (rare) race condition during bootup; we are checking if there is a way to make 100 % sure that the gateway does not grab port 5060.

I would first check if the hardware is still okay: Does the box reach to ping? Can you log in to the web interface? In the web interface, can you check the access (maybe your phones just have been blacklisted for a day or two).

It depends who proposes the codec. If the carrier insists on G.729A, there is little that the PBX can do but accept it. Two things: Transcoding is not evil per se. The log entries above look okay to me, and at least both parties should be able to talk normally even though transcoding does reduce the audio quality. Second, there must be something special with that trunk. This is not a common problem. Maybe the provider takes the liberty to switch the codec without properly negotiating it; SIP is not very strict with such things. I know it is difficult to get a PCAP, but a PCAP would be able to pinpoint the problem.

How big is that file? If it is too big, you can also copy the files from one file system to another (e.g. using tar). However, make sure that you keep the executable and the license string (you can copy that from the web interface).

This is a global administration setting. The value depends on UDP or TCP/TLS transport layer and if the device is behind NAT. For more information, see http://wiki.snomone.com/index.php?title=System_Performance_Settings.

Die Einstellungen für die Konferenz sind im Domain-Mode in der Konferenz selbst. In der Übersicht über die Konten (Accounts) einfach auf die Konferenz klicken.

This seems to work fine: Display Name: 05603412345 Account: 05603412345 Domain: bmnhb-03.bt.com Username: 05603412345 Password: ************ Proxy Address: sip:www.bbvservice-560348.bt.com:5060 Send call to extension: 70 Remote Party/Privacy Indication: Remote-Party-ID Everything else on default. The extension where to send the call is of course depending on where you want the call. 70 is usually the auto attendant.

The PCAP would be on the PBX. Yes, I would for now limit the codec on the system to PCMU. If you have enough bandwidth, this is definitively a good idea. Then after hours, you can try to get a PCAP with the codecs unlimited to see where the problem is.

If you just want to use a SIP trunk to the public Internet you can usually lust keep the private IP address. The SBC of the service provider will fix the problem that the IP address in the SIP packet can practically just be ignored. You only need a routable IP address if you want to register phones from remote locations and you don't have a VPN. Then you could configure the device only with the public IP address; in many cases the local router will be smart enough to keep the traffic local ("hair pinning"). You can see this as hosting your PBX in your own little cloud.

I think we are getting closer. I don't think that NAT is the problem here (at least not at this stage), then you would get nothing back. Unfortunately, the SIP standard leaves a lot of options open, and every service provider in the whole wide world uses them differently :-( You probably have to use a geographical number in the from header and your authentication number in the credentials. If you send us a private message with the login data provided to you, we can try out if we can get it working from a test system. Then after that you can change the password and start using the trunk.

Right. The default SSH username is "root" and the default password either "nosoup4u" or "snomONE", unless you have changed the password for the PBX system admin account (then it is that password). You can also modify the page "reg_plug_ip.htm". There is a function called generate_interfaces, where you can add your code for eth0.0 as shown in that Debian web page. Note!!! You are working on a dangerous part of the system. If you loose the IP configuration, your box will be a brick. The SoHo does not have a factory reset button (unlike the snom ONE mini). You should definitively make sure that you can log in to the SSH through IPv6 link local address. If you have a Debian standard Linux system somewhere, try out what configuration works, and after it works try it out on the SoHo.

Not an easy case. I agree, it is somewhere in the area where the PBX starts transcoding. It would be great to get a PCAP trace of this (wireshark); then we see what kind of traffic on the media side is coming from the provider.

It will take probably two weeks, as we are currently in the process of migrating a server and the new server did not show up yet :-(

That is possible. In Linux, you can generally have many IP addresses on the same (physical) interface. The SoHo is running a Debian if I remember correctly, we don't support this kind of configuration from the (default) web interface. http://wiki.debian.org/NetworkConfiguration#Multiple_IP_addresses_on_One_Interface contains what needs to be done. Actually you can log in through the SSH to the system and edit the file directly. Alternatively, you can customize the web page on the PBX where you can set the static IP address for the SoHo, so that the JavaScript there generates a different configuration file. Probably the first is easier.

So I assume this is version 4.5 of the PBX (some build number). I would try on the trunk to set the "Remote Party/Privacy Indication" to "No indication". Then the PBX behaves similar to a SIP phone, however you'll loose the ability to show the original caller on redirected/forked calls (e.g. when doing the cell phone twinning). On inbound calls, you should check the setting "Send call to extension" and set it for example to the extension where your phone is registered. If that works file, you can work on directing it to the extension that was actually dialed.

That was just one example of the things that need to be done. Interoperability with the Speech Server is not trivial. Please check the link, there is a step-by-step guide (at the bottom) of what you need to do on the PBX side.