Vodia PBX

I guess the pattern should be more like this: !^(4122[0-9]*)!300!f! !^(4121[0-9]*)!400!f! 800

As the phone is the TLS client you must either turn off certificate checking on the phone or import the snom Root CA (snom ONE built-in certificates are usually derived from that, at least when you are using snom ONE blue/yellow/green/white/purple and so on). Alternatively, you can purchase a certificate for the PBX and import it in the PBX; make sure that the phone trusts the certificate issuer. Welcome to the wonderful world of certificates.

RMA would probably not help as this looks pretty much like a software issue. Did you plug and play the device? At first glance, it sounds like a problem with the SRTP. Are you using UDP transport layer and have SRTP turned on? Anything in the log like "Wrong SRTP MAC"?

Both Mediatrix and Patton work fine with snom ONE. The setup is not too difficult, there are some old forum posts available regarding this topic.

Well, you are talking about the "optimistic case". The PBX must be prepared for the case when one of the users presses the hold button (then the PBX has to generate music encoded in G.729A) or when someone barges into the call (adding the audiostreams requires decoding and then encoding). We are thinking about adding more free codecs, then we don't have to worry about codec licenses so much.

Is that a file that came with the audio files for the PBX or did you create it on your own? The PBX understands only a narrow subset of the WAV file capabilities, for example it will not take stereo files and the sampling frequency must be 8 kHz.

If you have file system access, I would just backup the working directory and restore it on the other computer. If you go through the web interface, you might hit the size limit and then you get those 0 kb files.

Well, there is something in the middle: 213.131.156.66. Usually, the PBX should receive registrations directly from the endpoint (and also INVITE requests). This can be the source for the trouble. What is also strange is that it advertized two different IP addresses in the SDP (213.50.90.4 and 88.131.158.234), which is also suspicious... The PBX does receive traffic in the beginning. This is a good sign. There is a Re-INVITE, obviously because the other side wants to enforce symmetrical codecs. Maybe you can set the flag "Lock codec during conversation" (admin/settings/ports/rtp) to make sure that both side always talk the same codec and avoid the Re-INVITE.

Right now there are some specific method implemented, I can think of the detection of calls from cell phones (associated with extensions) and when a caller calls into a agent group it may route the call to the agent that spoke with the person last time. We have the pattern "t" in the routing area for the trunk already. Thinking about it, it makes so much sense to include a "f" field there as well (and it is so easy), we'll include in the next version!

Seems the DNS server is very slow. This might be an issue only during the first registration. Try to use another DNS server (e.g. 8.8.8.8) or use "sip:gw3.theiptele.com:5060" as the outbound proxy (the 5060 means forget about NAPTR and SRV and just do AAAA/A lookup). Please attach the REGISTER and the 401 message, then we can see where the problem is.

I believe there is a fix on the way!

I guess this is the problem. The contact header in the 200 Ok (coming on on TCP transport layer) tells the PBX to use UDP, which it does. But the ACK obviously does not make it. Maybe you can ask if they intenionally choose UDP for the ACK. I guess not, and maybe/probably the gateway discards the ACK and that is the reason for the trouble. Could it be that there is a firewall in between? For example, in Windows you can tell the personal firewall that UDP is not allowed on a application; maybe for the PBX that is the case. Or if you have a firewall in the network, maybe UDP as not enabled.

Dazu muss auf jeden Fall das entsprechende Directory vorhanden sein (audio_de), wo sich die Dateien für die Sprache befinden müssen. Dann sollte es (nach einem Neustart) möglich sein, die Sprache auszuwählen.

Does the HG4000 support UDP? This is because the 200 Ok comes on TCP transport layer and contains a contact that is implies UDP. So the PBX sends it on UDP. Because the gateway repeats the 200 Ok, it seems that the ACK does not make it and this transport layer problem could be the reason.

The general rule still applies: If you present a password that shows you are a user, you get only what you are allowed to see as the user. CSTA, SIP or HTTP it does not make a difference.

We are looking into it...

This might be the case if you are coming from an IP address that is listed as "trustd IP address" (e.g. 127.0.0.1). But other than that, this should definitevely not possible!

You might be a "victim" of the 8 seconds TCP disconnect issue when the TCP/TLS connection did not register. if you send a pivate message to pbx_support and indicate what OS you have, your problem might go away already.

Sure. We can do that after the RTP processing is out of the executable. This is one of the hard nuts for 5.0.

For two handsets I would put the MAC address there, hit the save button and that's it. If you have a large number, you can create a CSV and import it, and include for example the MAC, the name, and other features of the extension.

Oh. 3.4 did not support 64 bit yet. Maybe you can consider upgrading to version 4. There are many features, but also many bugfixes in version 4, including the option to run 64 bit! If you can, create a small testinstallation with version 4 and see if you can smoothly upgrade: If you did nothing special, the upgrade should be easy.

Well, take a look at the pbx.xml file, there you should see the host. Anyway, you can as well edit the XML template for the phone and do the change there.

There is a problem is you have too many HTTP or SIP traffic on TCP/TLS. This is because the PBX forks a thread for each of them. In such cases, you should use the 64-bit version of the PBX, which has enough virtual memory address space to for enough threads. (One thread takes usually about 10 MB in the VM, so that with 200 threads you are already taking 2 GB, which is pretty much all you have in 32 bit).

A few months ago, we found out that the PBX closes a connection that has not been authenticated with a successful registration, after 8 seconds (this is to keep hackers away). We extended the logic so that also successful INVITE requests also keep the connection alive. It seems like you dont have the latest version (where did you get the link from), maybe just private message pbx_support, indicate your OS and then we'll send you the link with the latest build.

Looks like the PBX did not associate the call with the trunk to the exchange server. Did you set the outbound proxy right? Maybe you should just set the explciit inbound addresses. Also, make sure that the PBX has has the "assume call comes from user" set in the trunk. This is neccessary because the trunk needs to know which dial plan to use and which user to charge (you can't charge a trunk on the PBX).