Vodia PBX

It is much better if the gateway can do this (practically all relevant gateway do it). For example, this is better for packet loss. We had inband detection from old CS410 times; but today that has no more practical relevance.

In principle absolutely yet. However it depends on how you terminate your calls back into the PSTN. Many service providers don't allow presenting numbers that the subscriber does not own. You should check your your provider how this can be achieved. snom ONE has very flexible SIP header settings and it should be possible to tweak the settings for your service provider too.

There is no hard-coded limit. When the CPU gets too much load, it will automatically reject more incoming calls. However you have to keep in mind that the more people are in the conference and they don't use their mute button, the more noise you get. Worst-case scenario are cell phones in cars in hands-free mode in the conference room. If you have ten of them, a productive conference will be impossible.

Yea, this is becoming a useless pain in the neck. We'll change the algorithm so that the user gets only blacklisted if there are several real attempts to get into the system without having the right credentials.

The columns in the CSV should be first name, last name, fixed number, speed dial, client matter code, cell phone. As far as a I remember you can do bulk changes of accounts using the CSV import function http://wiki.snomone.com/index.php?title=Using_CSV_Files.

No but it shows that the phone needs to address this topic.

I agree with you. It is a shame because CSTA is a lot more difficult that just hacking a snom-internal protocol that tunnels the behavior of the keys on the phone itself into the vision. In the 3xx series that worked very well and it would be great if that would also work with the Vision.

Yes it is already fixed and will be in the next version. For those who cannot wait, edit the template for dom_acd.htm, dom_hunt.htm and dom_attendant.htm and change process_telnum into process_telnum (notice the plural). When upgrading to the new version, please don't forget to revert the changes back to the default, so that you also get future updates.

The snom Vision is a very special device. Unfortunately the communication between the Vision and the phone is using CSTA. I would not have any idea on how to get button functionality implemented over CSTA. I am afraid that the Vision software cannot be used as extension board with the current firmware.

Yes, 8.7.4.7 is obviously beta. This cannot be a permanent solution.

That could happen if the password does not comply with the password policy for the system. Also, this might depend on the browser as the form is loaded in a JavaScript.

I just tested that with 5.0.6 and 8.7.4.7 on 720 (sorry for using beta firmware :-P). It worked for me... The phone also needs to cooperate here, maybe there was a bug in the phone. If anybody could upgrade the phone to 8.7.4.7 and test again it would be appreciated.

You can hide all extensions, but not one specific. However you can define who can call the person (in the extension permission settings). For example, if you put only the number of the assistant there, then all calls must go through that assistant. IMHO hiding the extension number is a difficult task anyway. If it "leaks out", you need to set up a rule who can call this person anyway.

That sounds like a coincidence to me. I would try to get a complete PCAP for the trunk traffic and then get a clue if the media is coming to the PBX or not. The PBX is a B2BUA with very little dependence between the sides and should be isolating such problems very well.

No. That is not the problem.

We cannot check that here... I would double double check that you put the right password in there and that the MAC that you are using is a "fresh" one (not used anywhere else). It should work--it does work for us, tested again in other cases today.

The SRTP does not flow "through" the PBX. The PBX does always SRTP transcoding. The trunk should be completely isolated from SRTP problem the the phone. Can you isolate the problem with extension-to-extension calls? Also the question is what phone firmware you are using. There were versions years ago that had issues with SRTP. IMHO 8.4.35 should be working well with SRTP. We are also testing 8.7.4.7, although this version is still in beta. The 8.7.3 builds did not work so well for 3xx phones for us.

Yea, it was actually not the mailbox message duration, it was the inactivity timeout kicking in. If you don't press any key in the mailbox for five minutes, it hangs up. We fixed that now in the code, regardless from the message length duration setting. Next build will have it fixed properly.

It is debatable; the snom phones implement this behavior by default for a reason. I guess in this case they want to make sure that the user does not forget that there is someone one the other side of the call waiting for an action. You have to keep in mind the certain regions expect different behavior. We try to override the defaults only if the overwhelming number of users need a different behavior. In other cases, it is easier to override the defaults with the templates.

The hold key was sometimes in the old systems also called "exclusive hold" versus "non-exclusive hold/park". Exclusive means that only the person who holds the call can retrieve it again. Parked calls can be retrieves by other persons as well. Calls must be parked in orbits, and there can be only one call be parked in an orbit. That is the user's perspective. Technically, a held call is still a call between the two parties, while a parked call is a call only between the remote party and the PBX. A held call has two legs while a parked call has only one. Having the same functionality like in the old days is difficult in SIP land. If you are using snom phones, then you can program the buttons to get close. A park button then must be associated with a park orbit. The you have not only one hold button, but as many park buttons as you have orbits. Most users are okay with the hold functionality. Once a call is (exclusively) held, they can either perform a blind or attended transfer and get the hob done this way.

P.S. I assume that you did register with snom? You will get the username and password from snom (in Germany).

Just checked on our server... Everything seems to be fine over here... Real MAC address replaced with XXXXXX. [5] 2013/03/24 16:03:33: Prov request: <?xml version='1.0'?> <methodCall> <methodName>redirect.registerPhone</methodName> <params> <param> <value><string>000413XXXXXX</string></value> </param> <param> <value><string>http://server1.snomone.com</string></value> </param> </params> </methodCall> [8] 2013/03/24 16:03:41: HTTP client: Connect to 80.237.155.31:8083, pending requests 1 [5] 2013/03/24 16:03:52: Prov response: <?xml version='1.0'?> <methodResponse> <params> <param> <value><array><data> <value><boolean>1</boolean></value> <value><string>Ok</string></value> </data></array></value> </param> </params> </methodResponse>

The problem is related to the maximum message duration, which is 5 minutes by default (Maximum voice-mail duration in the domain mailbox settings). We'll offer more drop-down options in the next version. Until then, workaround is to change this in the XML in the domain directory and restart the service.

Sorry, please try again. The image was just missing.

5.0.7 does not come with exciting new features, more with a lot of clarifications and some bug-fixes. If you are on MacOS, upgrade. If you are using Polycom phones, you also want to do this upgrade. Check out the release notes http://wiki.snomone.com/index.php?title=Release_5.0 for more details.