Vodia PBX

There is a general problem with calls that don't hang up. A typical case is a call from a PSTN gateway that is not able to detect call hangup. In the AA, there is a hangup timeout for calls that never connect anywhere. This is typically a relatively short timeout (e.g. a minute). Once the call is in the mailbox, the maximum mailbox recording duration will determine when to hang up. This is usually also an acceptable duration. If the caller has to press a DTMF tone, this is usually a good way to check if there is a real person connected. The AA may help to perform that check: Calls to other accounts are routed only after the caller pressed a key that tells the PBX where to send the call.

Was den zweiten Teil angeht... Ja das finde ich auch sehr spannend. Geht im Endeffekt in den Bereich Home Automation. Da stellt sich die Frage, ob man das über SIP machen muß oder ob es auch HTTP tut (z.B. über IVR Node i.v.m. ActionURL). Ich habe mal vor Jahren was bei Allnet gesehen was hier die Lösung sein könnte.

If you are using already 5.1.3, I would turn PCAP tracing on and get a trace for the call, both for the phone and for the trunk. It could be something stupid like a stuck key on the phone.

In V5 we have turned that into a small JavaScript that offers some popular patterns. Whenever it comes to ERE, the road becomes slippery!

Okay, we have tested a loopback call in 5.1.3. It worked... In any case, we needed to have the country code set to make sure that all numbers internally start with +. And loopback detection was set to "off". When the test setup was using "try loopback" in the dial plan, it worked right out of the box. When using a trunk (which we looped back through 127.0.0.1 because we did not have an external proxy) we needed to make sure that the number was presented in the +-format. Then it also worked.

There is a glitch in 5.1.3 when editing domains. If there is no alias name set, then it would not take it. Workaround: Assign a dummy alias name to the domain.

Well the WAV file is named "aa_offer_cellphone.wav" and it should say "press 3 to call the cell phone". Seems like I promised too much... The prompt is missing also here. We'll have to include that with the next recording; if you want to have it earlier, you have to record it quickly yourself.

In US-English it is there. But in other languages that have not been recorded lately it is probably missing.

The PBX starts inviting agents in steps. You can define how many agents are added in each step. However I would keep the numbers relatively low, so that the CPU does not have to invite too many participants at a time.

5.1.3 has some improvements compared to 5.1.2d. It should work with Chrome and Mozilla/Firefox. I am not sure about Opera. IE remains to be a problem as it supports only MP3 and AAC, but not WAV (even though it is a trivial format). We will probably have to add a IE handling that offers the file download for the recording playback. For users we cannot recommend IE at this point if they want to listen to the recordings from the web interface.

No, the Polycoms take any cert (even the built-in one). The older Polycom are becoming more and more difficult, especially when used in networks that also use the newer phones (VVX). We have a hard time to come up with a TFTP folder that serves them all.

No, sorry just IP addresses. The access list must not be time-consuming, as it would otherwise be an open door for DoS...

Well that is kind of progress... But the topic is not that complicated. You need to make sure that all your trunks have an outbound proxy set and that your extensions have reasonable secure passwords, which can be enforced with the password policy on the PBX.

As far as I can see the packets look roughly okay and they seem to arrive every 20 ms. However the packet length looks strange. Maybe this is stereo? If you have a PCAP it is okay to keep it very short and send it to me by private message.

The certificate is provisioned into the phones. For this, you must have Polycom version 4 or higher. If it is less than version 4, then the PBX provisions the phones without TLS. Unfortunately it is difficult to provision the Polycom phones the right firmware. The firmware has to be copied into the PBX directory and this must be done manually because of the licence agreement before the download.

You don't have to try all browsers. With Chrome it should be working. Also, right now we don't use any "fancy" mechanisms like AJAX or REST there, just a plain HTTP POST. This part should be really working fine, especially if you see the pop-up with the warning that this would open the selected extensions for provisioning. Just for clarifications: You did select the extension that would want to provision? You should see the P10:00 (or a different time) in the extensions view. This information is not visible in the "all" view where all accounts are shown. It must be something simple that we are missing mere...

Hmm. Why don't you update the phones to 8.7.3.25? 8.7.3.19 had a lot of bugs. From our research so far we could not find any reason why the phones most of the times ring and sometimes don't. If you can reproduce that problem, it would be great to find out what is different in your environment. Then snom can easily fix the problem and release a new firmware where that bug has been resolved. When you are using 5.1.3, please use the PCAP feature to get us a trace for the extension. Maybe we are able to see anything unusual.

If VLC and the PBX are running on the same host, I would try 127.0.0.1 as destination. If that does not work either, I would send the RTP stream to another computer for testing purposes and get a PCAP (Wireshark) trace (that computer does not have to run the PBX). Then we can take a look if this looks like RTP that the PBX can understand. Once that is okay, you can change the destination back to the PBX.

Are you sure about 8.7.3.19? The 5.1.3 release by default upgrades the phones. Maybe that bug was already present in 8.7.3.19, who knows.

I remember there were some problems... honestly it was never a priority. If anybody else knows where the problem is we'll spend some time trying to fix it.

Well, the latest snom firmware has a lot of improvements. But it seems that the incoming call indication has some glitches (see http://wiki.snom.com/Firmware/V8/Release_Notes/8.7.3.25/Known_Issues). We have not seen this issue during our tests, but have heard from other sources that this problem exists. As for now, our recommendation is to factory reset the phone, provision the phone and don't make any changes in the alert tone area. I assume that snom will come up with a new firmware version soon as this is an important feature of the phone that it rings when a call comes in.

Insider knowledge the text topic is still in flux and documentation lagging behind.

The syntax generally depends on your service provider. The PBX replaces several tags inside the URL: {text} is replaced with the message it self {text-iso} like text, but in ISO/IEC_8859-1 encoding {text-utf} like text, but in UTF-8 encoding {to} is the destination number {to-local} the destination number in the domain representation (depending on the county code) {to-e164} is the global number without the leading + Hope this helps

The clock is not ticking back in the browser. You will have to reload the page to see it going down. It it gets stuck in 5 minutes there might be a more serious problem: The phone keeps on requesting configuration data in an endless loop.

This is caused by the new JavaScript loading of the translations. We have also seen those patterns sometimes. It seems to depend on the browser type and the cache status. it is not critical. We'll try to fix this with the next release. Usually it disappears after pressing F5 and logging in the next time. Yes the file size is less; we have removed a lot legacy stuff that was never referenced ("junk").