Vodia PBX

Well if you disable the VM after thee attempts, it is very easy to DoS the mailbox. I dont this is a good solution.

You dont have to purchase new trunks. Just create more trunks with the same outbound proxy and set them to outbound only (no inbound). Then you can select the right trunk from the dropdown in the dial plan. You can use the trunk text mode to quickly copy & paste a trunk. Trunks can also have their own ANI, so you dont have to do this for each extension; you can also do it on trunk basis.

The way to get this working is to use the ANI as a list. In the extension setting, you can not only put one ANI there, you can actually put a list of ANI there (sepersted by spaces). If you want to link a ANI to a specific trunk, you can put the trunk name in front of it, e.g. "Trunk1:3392271234 9781234567". Then on "Trunk1" it would use the 339 number, otherwise by default the 978 number for this extension.

The link above is buggy because the closing bracket did not make it.

Well, then from a license perspective, you cannot switch from a pbxnsip version to a newer snom ONE version I guess. I think the easiest is to talk to the sales guys and figure something out.

Also sometimes the problem is that the PBX latches on to the wrong interface if you have multiple. Windows has its own preference which interface should join the multicast as far as I know.

There are a couple of different time durations here. First of all, the trunk have a different view on the CDR, as it does not care if the call is in the ACD or AA or IVR node or whatever. Then from the account perspective, there is the time when the call is in the "ringing/unconnected" state (technically it can be already connected, but in the ACD the callers are considered unconnected until the agent picks up) and then there is the time how long the call is on hold, e.g. when the agent puts the call on hold. Maybe this is causing the confusion.

The "video" feature actually makes the phone fetches a XML through HTTP and then after that fetch a JPEG, then fetch another XML which makes the phone fetch another JPEG and so on. In other words, a ugly workaround that comes close to a DoS (especially for SheevaPlug). Rumor has it that the phones will support MJPEG soon and then it is time to take the "video" feature out. Then the phone can fetch the video stream directly from the camera.

I have not seen or even used this device before. From the specification, it looks like it would work. The price is not too expensive, looks like this is worth a try. If it does work, it could be a great complimentary device for snom ONE. I would definitevely interested in a report!

Do you have a upgrade protection license? Does it say on the status screen something like "Additional license information: Upgrade: 01 01 2012"?

You can do a workaround and redirect it first ot an IVR node, then play the message there. Then at the end of the message redirect the call into the hunt group.

I remember we talked about this problem in a previous thread, some time ago. Essentially what we need is to play back DTMF tones as soon as the call is connected. The easiest way is to do this on the trunk. So it would essentially send everything everything before the comma character to the trunk as usual; then keep the stuff after the comma for the playback after the connect event. Then we can kep this a general concent and dont limit it to the speed dial codes.

Whow. I love to hear when problems are solved. Though 7.3.30 is pretty old; watch out for new versions; rumor has it there is a 8.4.33 on the way with lots of fixes, maybe one of them fixes your problem as well.

My feeling is that this is just the tip of the iceberg. Is everything else working fine? Is the device registered all the time? Maybe there is a problem with the network. We had cases, where the cable to the device was broken with all kinds of "funny" effects.

The problem is that the PBX does not send the number out as DTMF... It just passes the number on to the trunk in the Request-URI. So the answer is, you can put in anything that the service provider or gateway understands... Realistically, chances are pretty low that they support it.

I believe so far the only way for this is to change the ringback.wav file on the file system. However that would apply to all calls, not just to a specific hunt group. You might be able to treak it a little with the ringback country selection, but franky the feature does not really exist for the hunt group. For more complex things we always recommend to use the ACD; there you have a lot of settings to customize the behavior.

Hmm. This is the snom ONE forum, we dont have too much expertise about the phone. However, if you can attach the SIP trace maybe we are able to figure out what is going on.

The latest version which has been released just before Christmas should have the certificate built-in. If you upgrade, make sure that you delete all certificates from the list of certificates or just remove the whole working directory (at least the certificates directory) from your install before restarting the service. If you get 404 the problem might be a different one. Maybe you are subscribing to the wrong number. Lets see if we can come up with an updated description on how to connect snom ONE to Skype.

Hmm. In theory the idea was that snom products trust snom products (through the cerfiticate chain). Of course the minute you load a different certificate into the PBX that would not work any more. You can check if that is the problem by turning the certificate check off for the m9 (m9 web interface/security/certificate policy). But this is something we have to try out in the lab again. This should really be plug and play.

It might be wise to use a PC for experimental things to keep life easier. Then when it is clear, you can move the stuff to the embedded platform. You should be able to see the SIP packets in the PBX log. Just turn the SIP packet logging on for call-related SIP packets. There used to be a page where you can upload ringtones.xml; seems like that page was removed during the update to the web template model where you can modify the web pages directly through the web interface (admin/web page control/phone/pnp/ringtones.xml). Not sure if this has immediate effect... Maybe you can try to modify the snom phone header first and see if you get a change (looking at the phone SIP trace) without reboot and if that is okay, you can add other user-agent types there.

When the PBX sends the INVITE to the phone, do you see n Alert-Info header? Does it contain the "Auto Answer"? You can also load the ringtones.xml through the web interface, then it should not be neccessary to restart the service.

It is all about provisioning the Polycom right. From the old pbxnsip days we know that the key was to provision the phone so that it would react on a Alert-Info with the content "Auto Answer". Not sure how much time you want to put into this; but for sure you have to provision the phone right and then add a line to the ringtones.xml file that tells the PBX to send the magic word "Auto Answer". Maybe the easiest is to find an old pbxnsip binary that does this right and then copy the generated PnP files into the tftp folder and provision the phones from there. I think you can also use the search-engine-of-your-choice using the words "pbxnsip polycom auto answer". The search-engine-of-your-choice does not forget!

The problem with the ALG is that the router manufacturers have to deal with so many different SIP interpretations and even buggy implementations that it becomes impossible to please everyone. SIP was not designed for ALG at all, and you need to do really difficult things to get this done properly. IMHO SIP ALG are not very useful anyway because practically all SIP providers today support a far-end NAT solution (SBC), and there is no need to fix things on the router. Sometimes it is even counter productive.

The router might be trouble (see http://forum.snom.com/index.php?showtopic=7952). The IP address is definitevely VERY suspicious. I would have no idea who else would put this IP address there...

Is this a smart gateway/firewall? maybe it sees the public IP address of the service provider and patches it to it's own address, so that it may relay the media. But in many cases, such "favours" cause more trouble that they help.