Vodia PBX

Or just use JavaScript...

Did anybody already try to increase the value of "max_loop"? With so many redirections, this might cause the issue?

If the voicemail in the email attachment is barely audible, there must be a gain problem with the PSTN. Can you try to increase the gain? Maybe the phones compensate the low volume with the automatic gain control. But if the gain is too low on the PSTN trunk, then it is much better to fix it there.

The way to do that is go take that phone out of the standard provisioning right from the first file. You can use the files in the "generated" directory as the template for those files, but you will have to rename them (so that they include the MAC). Usually the phones request a file with the name "snom370-000413123456.htm" or so, and if you have that file in the tftp directory that's where it starts. In that file you have to change the links as well, so that it will then take the other files out of the tftp directory as well. It is not very convenient, we are working on the possibility to customize the pnp pages also per domain and per extension, so that such a change would be a trivial task one day.

Whats in the From-header? Something like "<sip:12.23.45.56>"? Then that's what the Caller-ID looks like...

Nothing gets forgotten in the Internet!

Windows explorer should already do a good job... In the UNIX world, you can use find(1).

Well, someone is "transcoding" DTMF tones. It could be the PSTN gateway, or even the PBX. The problem is that for example the PSTN gateway cannot know if someone down the path wants to receive out of band DTMF tones, so it does it anyway. DTMF is a big problem in VoIP. Unfortunately there is no good answer what to do.

Okay, getting closer... I suspect that Exchange has a problem matching the request to something valid. Maybe this is something that can be setup on the Exchange. If the To-headers are the same, IMHO that should be possible. I am not a big Exchange expert, maybe someone else can help out here.

I dont see what that would keep the PBX from sending the call to Exchange. Can you check if the PBX tries to send the call to Exchange (SIP messages between the PBX and Exchange)?

You can log in as user and then (if the domain admin has set you up) you can see the calls of the ACD queue where you are a agent.

Right, we have some plans to change the CO line behavior. It does make sense to have them seperated from the trunk, so that the admin can edit other properies like "only inbound", "only outbound", who can seize it and other things related to the caller ID for the CO-line.

No, they will be cut off. Otherwise they could continue and create possibily significant additional costs! If you enable the billing tones, the PBX will beep every minute one and before the last minute it will beep three times. This way, the person who makes the call will get an early warning before the PBX disconnects the call.

snom ONE green will also allow third party devices to do transfer. Pricing will be above snom ONE blue, but still an unbeatable offering I am sure.

You mean the "From" header shows "anonymous"? Where does the call come from? From an extension or from a trunk?

You can use for example ([a-z]*)@.* as the pattern (note the inclusion of the domain name), sip:\1@skype.sipnet.ru as the replacement.

Right now the parsing of the list of entries is really inefficient, it was really every time starting to parse the list again (next version will have it faster). Is there any way you can combine these 200 pattern into less? ERE are powerful...

Yes, seems like 188.161.235.136 comes from "Palestinian Territory". I would blacklist 188.161.235.0/255.255.255.0 to fix the problem at hand.

Of course.

No. This would be in the folder "102". No. That can also not be the point. I would cd into the cdre directory, and search an antry which matches the extension e.g. 102@bla.com. Then you can see what IP address that was coming from, and potentially blacklist that.

So what do you mean by "hacked"? Someone making unauthorized phone calls from this extension? Ideas why: The real password leaked out. For example, if the attacket has access to the file system, all security is rendered useless. If the provisioning got hacked, you would see the generated files for the extension in the file system (the "generated" directory) You can see in the CDR the IP address where the call was initiated from. That might help you find the source of the problem. If neccessary, you can blacklist that address or the whole subnet.

The typical dialplan usually contains digits, but it can also contain alphanumeric characters, see http://wiki.snomone.com/index.php?title=Dial_Plan_Samples. For example a pattern could be "name@skype.sipnet.ru".

Sounds to me like there is trouble in certificate land. You can try to log TLS on log level 9 and see if you got an alert. Maybe you have to load the Root CA for their service into the PBX.

No that's not available yet.

In the case of the snom m3 (cry file) thats okay. This is just to prevent a message that the file was not found.