Vodia PBX

Seems like the phone has the wrong password.

Okay, for attended transfer we can reprocude the problem. Will be fixed in 2.1.1. Interestingly, an attended transfer into conference also did not work (which really makes sense as the user can enter the PIN code for the transferred party). Workaround: blind transfer works. After the call is connected, press the Xfer button, then 8+ext, then Xfer again.

A couple of questions: Did you perform an upgrade? If yes, what was the previous and what is the new version? Are you performing an attended transfer or a blind transfer (or call deflection)?

Internal calls do not run through the dial plan. If there is a huge delay that usualy points to problem in the routing. Sometimes the SIP requests take a long way out to the Internet and then back through the firewall. If you turn the SIP packet logging on you will see more about the routing of the SIP packets and where they come from. That might help to locate the problem.

Can't you change it to "public" in order to get things working?

It is kind of dangerous with the race conditions. If you press the button just after a new call enables a call pickup, you will not call that extension but steal it's calls.

Hehe. Then you need to set the password policy in admin mode in the settings to accept any password!

You can't. That string is hard coded. Is there any need to change it?

You can clear the SIP password and put the IP address of the mediation server into the registration tab of the extension.

Interesting question. You should be able to go to your mailbox and dial the star code from the main menu (put a pound sign after the code that you want to dial).

The PBX must match the incoming caller-ID to a cell phone number. Usually the problem in NANPA is that the leading 1 there only on one side. If you choose the "Default PnP Dialplan Scheme" in the domain settings to be in North America, then the PBX will try to normalize numbers that you enter. However, if you already entered numbers, you must save the cell phone numbers again because that normalization is done during the saving of the cell phone number.

Okay, now I got you. Actually, there was a discussion about this more than a year ago - this behavior is supposed to be a feature! The point is that it is hard to say how long a recording is (especially when it is changed by the secretary) and the redirect should not kick in during the annoucement. Therefore the decision was to redirect after the annoucement is over. In your case that might a problem, as you repeat the annoucement several times. But IMHO it is still reasonable to say if the caller did not do anything during these three annoucements that you redirect him after a relatively short time to a operator, for example after 0 seconds.

Do you have a dial plan that applies to the calling card account? Either a default domain dial plan or a dial plan for the calling card account?

Well, dialog state was originally not designed for updating LED. Therefore the idea with the "buttons" package to reduce the message overload was a good idea. So far we are happy with it and it seems to solve a lot of problems. So yes can can recommend it!

What I can think of here is that you send the call to a IVR node, then match the "E" pattern and send the call to it's destination. Here I would say the solution might be to record the file long enough (maybe repeat the annoucement several times) and use the E pattern. But I think in the next version we need a explicit setting for a timeout.

No, just put the number without anything behind it into the src parameter.

Well, both calls from trunks and extensions should work if you turn the according flags on.

Looks like it was really a bug, but it is fixed in head. We will make a beta version available shortly.

Can you send me login data in a private message? We would like to try that out.

Okay!

Try using the parameter "src" in the URL (same as "dest", but for the other side of the call). Then you can define both source and destination of the call. The acconut that you provide will be charged for that call.

You can provide the credentials in the URL (see http://wiki.pbxnsip.com/index.php/Click_To_Dial). But for that the user also must be registered. IMHO everything else is just a big security leak?

Are you calling from a number that is a cell phone in one of the extensions?

Well, both "valerio_capodacqua" and "300" must exist on the PBX in the domain, preferrably "localhost".

Well - sorry at the moment you have to punch in that information one by one... But sounds like something that we can do to make life easier.