Vodia PBX

Upgrade to 5.0.6, this was a bug in 5.0.5 and earlier. Will be hopefully be released today!

The SIP call flow between Patton and the PBX looks okay. The question is how the call flow between the phones and the PBX looks like.

Zwischen Patton und PBX sieht alles okay aus. Die Frage ist was zwischen Telefon und PBX passiert. Wird hier TLS als Transport layer verwendet (PnP)?

The PBX stays out of the video stream. I remember that MJPEG has been added to the phones, but you have to manually configure this on the phone or in the phone template on the PBX.

If you use the PnP with snom ONE this should work automatically.

You should get an email like this: From: "ABC" <sip:123@xxx.snomone.local> To: "8421" <sip:8421@xxx.snomone.local;user=phone> Primary-CID: 1day87czmb Call-ID: 1day87czmb Direction: I Type: mailbox Remote: Local: 421 TrunkName: TrunkID: Domain: xxx.snomone.local LocalTime: 20130301224315 Start: 20130301144315 Connect: 20130301144315 DurationHHMMSS: 0:00:11 DurationSec: 11 End: 20130301144326 AccountNumber: 43 IPAdr: tls:1.2.3.4:3568

Not being a blackberry user... I believe there are two ways to go: Click to dial with HTTP (http://wiki.snomone.com/index.php?title=Click_to_Dial) and CSTA. CSTA is the more sophisticated way to get this done; I did a quick search on the net, but did not find anything useful there. So HTTP might be the easier way to get this done.

Seems like the user has decided to stay anonymous (see http://wiki.snomone.com/index.php?title=Anonymous_Calls, *67).

At first glance I would say the problem is that your user turned CLIP on.

The number to be called needs to be in the To-header. This is because the device registers it's contact, and according to the RFC the PBX must present that contact in the request-URI when calling the device up. Please check in your device if it is able to get the destination information out of the To-header.

There is some information about CDR here: http://wiki.snomone.com/index.php?title=Call_Detail_Records_(CDRs) please check if that solves your problem.

Obviously there are trade-offs. If you want to get PnP working with 710 and 4.5, you have to invest time into the templates. If you just register the phones, you get only the basic feature set.

Si vous souhaitez évaluer le produit, vous devez maintenant utiliser la version 5. Dans la nouvelle version, vous pouvez avoir jusqu'à 5 postes.

Whow. Try to use the cell phone twinning feature instead of redirection. Then they actually ring at the same time.

Did you try a factory reset before provisioning the phone? Maybe the *78/*79 is a leftover from previous provisionings/versions.

8.7.3.15 has too many problems with snom ONE, I would generally not recommend to use that version. 8.7.3.19 also has some errands, I hope that the next version will also address the problems with the not-hanging-up calls. Especially if other phones like 870 seem to do it right.

Hmm trying to understand the problem... First of all, the phone synchronizes the status with the PBX over a special kind of subscription. Try to set the DND from the web interface to see if the phone gets the status changes. The question is if the phone gets into trouble when it is receiving the update during a call. Just tried a couple of times, worked fine with me (720 on 8.7.3.19 on 5.0.5), both for *78/*79 and also other calls. Also pressing the DND key on/off/on/off does not seem to be any problem. Actually when I press the button, the phone does not call into the PBX, it just changes the status.

Generally you should use trunks to connect to gateways. The gateway should not register to snom ONE. There is one exception/workaround if the gateway is behind NAT. Then you can register it to and extension and in the dial plan select "send call to extension" and put the extension number in the destination field.

The integration between Lync and snom ONE is essentially limited to presence. The PBX might also act as PSTN gateway from Lync perspective, but snom ONE is not qualified for that. IMHO you have to make a decision where you want your "voice" calls (essentially phone calls with the public telephone network). Having voice in both Lync and snom ONE ends up in a lot of problems.

Argh seems that change was forgotten in the reg_texts.htm. You may change the reg_texts.htm in the template on your own or wait for the next build.

By default is is not there, and it does not have to be there. Only if you want to put new defaults in there you need it. If you just want to edit the templates, you can do that from the web interface.

Yea there was a lot of confusion about calls and call legs. A call may have multiple call legs, for example when calling a hunt group during the ring phase there might be many of them. The problem is that for the PBX and from a resource point of view, call legs are important. But for the user, the term "call" usually refers to a call object with multiple legs, and that is what is usually sold to hosted PBX domain tenants. To put the long story short: In the domain, calls means calls, not call legs.

No that's perfectly fine. A SIP connection is only set up during registration. After that, all SIP traffic including calls are going through that pipe.

We also saw the message "SW update failed" in version 5. This seems to be some strange bug in the phone. I cannot even guarantee that after you upgrade to V5 this message will disappear. It seems that 7.3.19 is still the latest & greatest version, hopefully those strange messages will disappear in the next version. The phone on my desk (a 710 :-)) made it and the SW update message is not there any more.

4.5.0 was released around June 2012. That's why the 710 did not make it. We had support cases where people tried to get the 710 working with 4.5, and the bottom line is: Of course they work in 4.5, but you better manually configure them. We added more than just a few pnp.xml entries to the new release. If you look at the file structure you will notice that several things have changed. The button provisioning has been overhauled. Also the MAC-based provisioning which uses the 7xx certificates has been reworked. XML-RPC has been added. These are things that you don't just put into the pnp.xml file and hit the save button.