Vodia Telephone System

On the snom phone web interface, under the identity in use, under tab RTP, check the setting "RTP Encryption:" It should be on. If it is off, that's the problem then we have to see why it is be provisioned as off and not on. Thanks.

Can you please factory reset one phone (for testing) and re-provision it. The problem is the snom phones don't overwrite provisioning settings and with the new version something needs to be updated. That can be done if the phone is in factory reset mode and then provisioned. I am assuming that will be the problem. Thanks.

The top save button is for the picture saving only (next to the picture). Maybe it should say, save picture.

Yes there was a problem we found. It should work in the next build of the version. Thanks.

These are star codes that need to be prefixed with the speed dial extension. So for example if you need to dial *87 before an extension that you want to pick up say 40, then to achieve *8740 in order to pickup the call ringing on 40 you have to give this prefix *87 in the prefix field and the parameter will be as usual the extension, 40 in this case. Thanks.

Hmmm it works fine here. Which version of the pbx? 5.5.4? Thanks.

I just checked it on my snom870 and it works perfectly for me. Of course it's not 320 and the firmware version could be the problem. As from the PBX log (with logging for subsription/notify set to yes), you can check if this message is being sent or not: NOTIFY sip:40@192.168.1.171:3296;transport=tls;line=ifobeqx9 SIP/2.0 Via: SIP/2.0/TLS 192.168.1.166:5061;branch=z9hG4bK-6a25066843af9e2a126370a8afd70d66;rport From: "Jeff McCormick" <sip:40@localhost>;tag=f67ec58c2f To: <sip:40@localhost>;tag=alkg5bnl7o Call-ID: 2867ab576a95-6ycvmd3xz92d CSeq: 25739 NOTIFY Max-Forwards: 70 Contact: <sip:192.168.1.166:5061;transport=tls> Event: as-feature-event Subscription-State: active;expires=113 Content-Type: application/x-as-feature-event+xml Content-Length: 223 <?xml version="1.0" encoding="UTF-8"?> <DoNotDisturbEvent xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3"> <device>40@localhost</device> <doNotDisturbOn>true</doNotDisturbOn> </DoNotDisturbEvent>

No, that is not possible at this moment. We are considering it in a future version.

The location document has been added here: https://vodia.com/doc/location

Okay, we have added it and the next minor release should have it. Thanks.

We are glad you like the new look and design. Thanks for your feedback which helps us to improve it further. That's certainly something we will consider to add.

That's probably because the domain is bigger than the default size allowed to download. You can change the default by entering the following the browser, after you sign in as admin: http://YOURPBX/reg_settings.htm?save=save&max_tcp_length=83886080 The value 83886080 (80 x 1024 x 1024) for 80 MB which is up to you what you want to set. YOURPBX is the of course the URL of the PBX. I hope that helps you. Thanks.

Sorry for the late response. I assume you have already checked the click to dial documentation here: https://vodia.com/doc/click2dial And the webrtc click to dial doc here: https://vodia.com/doc/webrtc_clicktocall Thanks.

That probably needs to be added. For now it is quite simple though. You create the locations in the domain and set them for the users either in the domain or the user mode and the emergency email triggered by the emergency numbers (both are domain settings) will should provide the location information in that email (if everything is set and works right, like email account setup, address etc.). Example: Account 42@localhost (Kyle Mason) is calling the emergency number 911 at 2016/07/01 17:35:59. From location set as: Name: domloc4 Street: def City: abc State: MA Zip code: 01801 Country: usa

Hmmm, it works in every case for me and on multiple different accounts. Could you please give it a try on 5.4.1a, where we have also changed the user portal significantly. It's about to be released. Thanks.

I don't see any reason here why it would fail to get a token if the authcode was correct. Just to be sure, could you please confirm the following: You used a gmail address in the email field? Then you pressed "Get Auth Code" button, which opened a new window where you entered your login email and password? It entered your account where you pressed the button Allow Access, which opens another page with the Authorization code, asking you to paste it in your application? Then you pasted that code in the "Paste Auth Code Here:" field and pressed "Login/Refresh"? Thanks

I am sorry, the post unfortunately doesn't show up immediately right now somehow, so I didn't see that it skipped the settings in the paste. Here they are again: LDAP name filter: (|(sn=%)(gn=%)) LDAP number filter: (|(telephoneNumber=%)(mobile=%)) Server Address: (PBX IP) Port: (PBX PORT) Base: ou=people Username: localhost\40 Password: userpassword Max. Hits: 50 LDAP name attributes: cn sn givenName LDAP number attributes: telephoneNumber mobileTelephoneNumber LDAP display name: %cn By the way you are talking about snom300, I thought you were talking about the dect handsets. With snom 300 you should be able to provision it without any problems. Thanks.

If you use your android chrome and enter the same address https://servername.domainname.com, does it reach your server login page? Because from there it should also work the same way, so that we can narrow the problem down. If it can't reach from there either then maybe the address isn't reachable somehow. Also, your android must be on lollypop (5.0 or above).

What does the PBX log say? If you can make a clean log by turning all other logs to 0 or off and just turn the "Log TFTP and PnP events" to 9, and then make a clean provisioning of the device, that'll be very helpful. Thanks.

LDAP: LDAP name filter: LDAP number filter: Server Address: Port: Base: Username: Password: Max. Hits: LDAP name attributes: LDAP number attributes: LDAP display name: We have yet to get a hand on that phone to be able to decipher and provision it. Until then the above settings should be helpful. Thanks.

Well on the admin level you have the page "User Page Control" that gives you some control. I know it's not the complete list of everything but still covers the important settings they should not change. Thanks, Asad

It already makes and receives call. But a lot has been changed so I am sure which version are you talking about? Although 5.4.1a has not been released yet, but that has the latest so far. As for answering the call, you should click on the notification itself as it says in the notification, that is if you are talking about the desktop chrome notification. Thanks.

Well you seem to be doing it correctly. GS did change stuff around and it is reflected in our latest versions like 5.4.1a. But are you saying all buttons aren't working and that it doesn't reflect the changes only OR the buttons never get setup correct even on first provisioning? Thanks.

Although it has been supported for quite a while, of course things are constantly being added and 5.4.1 should have the most. Chrome on mobile devices also does it and I think it would also be best on chrome in desktop. In future we will consider using a more generic API so anyone can use it. For now you can look into the files usr_phone.js in the user portal for how we handle signalling through websockets and make the call flows for a soft phone. Thanks.

Yes it is done in the user portal under ACD's. If you copy the usr_index.js from your browser to a file of the same name in the html folder of the pbx, then that file will be used for the user portal instead of the built in one. So that you can make changes to that file and observe. The acd related functions explain how we present data. Specifically how the information is obtained from the pbx with calls like: // All ACD information, for individual ACDs var acds = getRest("/rest/user/" + encodeURIComponent(session.cuser + "@" + session.cdomain) + "/wallboard"); // A single ACD information, for individual agents var acd = getRest("/rest/user/" + encodeURIComponent(session.cuser + "@" + session.cdomain) + "/wallboard/" + encodeURIComponent(groups)); Where REST is used to make the request. The user is a particular extension and domain is the domain in which the ACDs reside. Make sure this extension is logged in and is the queue manager. To make an extension a queue, you to set the setting "Queue manager" with the extension(s) that you want to be queue manager. The setting is found in the ACD main settings.