Vodia PBX

Seems that there was a bug creeping in. Try http://pbxnsip.com/cs410/update-3.0.0.2995.tgz.

That sounds to me like the password in the PBX differs from the the password on the phone. Try re-setting the passwords.

That is indeed very strange. Is that reproducable? Do the phones reject the call? Maybe there is something that makes them reject anonymous calls.

Yes, they also count. I think that is reasonable, because the SNMP stuff is about resource usage of the system, and a MWI subscription is as expensive as a regular extension registration to the PBX.

Well the first time someone enters the queue should be only half of the waiting time. But I get the point. Maybe we should extend the syntax for the waiting time and say the first number if for all prompts and the second (if present) specially for the first prompt. Default would still be the duration divided by 2. Gap between announcements (s): 20 5 Would mean: Usually wait 20 seconds, and for the first prompt wait 5 seconds. What do you think?

In any case I would suggest to update to http://www.pbxnsip.com/cs410/update-2992.tgz. Maybe it already fixes the problem. Make a backup before doing that, just in case anything goes wrong.

Two things... The first thing is that obviously something was broken and the language provisioning for snom wasn't working out of the box (that should be fixed in the next build). The other thing is that the automatic provisioning works only for languages that are available as web interface languages. That might be insufficient. Maybe we have to introduce a PnP parameter for this (though I really like the idea of controlling that through the vendor-independent language settings for the account).

The name of the key would be something like "3 Minute Demo". That string shows up under admin/status.

If you have access to the file system, there is a simple workaround. Just record the prompt with on of the *98 codes and check what file has been written to the recordings directory. Than replace that file with the recording that you actually want to load through the web interface. That should save your day. For the static noise, make sure the file is 8 kHz sampling frequency mono, 16 bit/s sample WAV format. In the meantime we'll check what going on with the upload.

Okay, what version are you on the PBX? Where exactly do you see that the extension is on DND in the web interface? Did you ever hit the save button on the DND web page?

You see the DND status in the web interface changing without someone touching the phone? Do they have a good password set for the web interface? Maybe someone has some fun teasing you? Or can you trace the SIP traffic to the registered phones? Maybe they get bored and start calling the PBX when they are idling... There is no little genie in the PBX that does things like that...

Maybe there is a speed dial somewhere for DND. I would turn sending emails for status change on, then the user will get an email when the status changes. The user will tell you what he did in order to get this email ("I did nothing, just press this button").

Does the moderator have a email address setup in the account? Only the moderator should receive an email, not the participants. It should also work for adhoc-conferences. The following participants are currently in the conference: StartNumber2008/08/17 09:01:17482008/08/17 09:03:2144 Do not reply to this Email. It was sent automatically.

You you see DND set on the PBX??? That would be very strange. Does the phone accidentially send a call to the PBX and set it to DND? You should be able to see than in the call log. Also, the PBX can send an email when the DND status changes.

So the phone believes it is on DND? What version? Make sure that you are running 7.1.33. There are two ways of dealing with this. The first is to reprogram the DND button as speed dial, use the same code for DND on and DND off and put that code behind the speed dial. The second is to use the buttons and assign the DND "button" as DND. Then it should work similar to the speed dial, but also show the DND symbol on the screen.

Are you using the 3 minute demo key??? Had the same problem with testing here .

Try http://www.pbxnsip.com/protect/pbxctrl-debian4.0-3.0.0.2993.

Sounds like you could use the domain address book for this? Such service exists, but you have to pay for it... THe other thing is: For the PBX that is tricky, because there might be a significant response time and then the user will have the impression the PBX hangs. In SIP it is generally difficult to change the To/From-headers once the INVITE has been sent (or let's say the support from the phones is pretty poor).

Okay, just another idea. When you call from your cell to an auto attendant, and that number is in your extension, then the PBX gives you the option to call out. In that case IMHO it would use the extension caller-ID. Maybe that solves the problem?

Okay, got it. That will be indeed difficult/impossible. Hmm. The alternative could be to define a pattern in the trunk that tries to send the call to a hunt group, and if that fails it uses the dialplan. I am thinking about a pattern like this: !555!555! ![0-9]*!\1! Not sure if it really works, just a wild offline idea.

We are getting ready for the next major release - 3.0. The image seems to be pretty stable now, the next action item missing is the release notes and then updating the Wiki. For those who can't wait and want to get the latest and greatest you are welcome to grab the Windows build at: http://pbxnsip.com/protect/pbxctrl-3.0.0.2994.exe The license keys for version 2 also work on version 3. When doing an upgrade, it is a good opportunity to make a backup of the 2.0 directory, just in case that you decide to roll back. The upgrade itself should work automatically. Important things to consider when doing the upgrade (so far): The tel:alias semantics has changed. Tel:alias is only used for inbound calls, and only if the trunk is marked as a "global" trunk (that was a security fix that we also applied to version 2.14). For outbound caller-ID representation, we added a field ANI that can be assigned on account basis. We will post other important upgrade issues here as we find them.

Well, then don't record the annoucement number 0, just record number 1 (e.g. *98123*0 and *98123*1). The special about number 0 is that is always played back, especially in the case you are mentioning.

Maybe you should reserve special prefix for hunt groups, extensions etc and then split it up in the dial plan. The dangerous thing here are loops, make sure that such groups do not end up in endless call loops between OCS and the PBX. Those are really hard to deal with and instanteneously create the maximum number of allowed calls. Call it DoS if you want...

Check out http://pbxnsip.com/cs410/update-2993.tgz and see if that fixes the problem.

Okay, the phone really does not send RTP, even if "RTP Keepalive" is set to "on". At least in version 7.1.33. But it does send RTCP. I think we can also use that as a indication that the call is alive. It might have problems with NAT, but I think it is reasonable to say that RTCP also is a sign that the UA is still connected. What OS are you on? May we give you a image to try it out?