Vodia PBX

Nope. Does it make a difference if the contact type is white or black or just transparent?

Hmm. If the registration is fine, then we can exclude wrong password or ISP blocking SIP ports. Are you sure that the account has enough money (if prepaid) or credit?

The alternative to the AA is to use the calling card account, where you can log in (actually not only from the cell phone) and place outbound calls from your account.

We heared about Firefox issues, but we were also not able to reproduce them. Can you get us a Wireshark trace (send me a private message to discuss the location)? Then we maybe can solve that riddle.

In 2.1.10 you can do that by using the tel:alias or a per-account basis, this has higher priority than the DID number setting in the trunk. This solution is okay unless you have two extensions that should both show the same DID which is not the same as the DID for the trunk (that will be fixed in 3.0).

What version are you on? I remember we took the "1" out...

Well, then that's the problem: REGISTER sip:192.168.41.223:5060 SIP/2.0. "domain.local" != "192.168.41.223" and "server.domain.local" != "192.168.41.223". Try "localhost" as alias. The string "localhost" is a magic name that matches any domain name: "localhost" == "192.168.41.223"!

Maybe you can just use the speed dial mode for a button. Not sure if you then press hold on the same button then.

In the 3.0 release we (will) have a ANI settings that should solve many of these problems.

Very strange. Do you have an alias name of "localhost" for the domain?

Well, then it will be very difficult - the PBX knows only at the end of the DTMF sequence that the code is supposed to be intercepted. I would prefer to have a option on the PAC that turns recording on and off from a user.

Apart from the usual resource limitations (number of calls etc), the number of pending transactions is limited to "1". The PBX will send out one SOAP request and wait for the answer. That means the processing of the key input will depend on the speed of the database. But I believe unless you have a absolutely crazy database the response times should be still well below one second, which should be okay for a caller. http://wiki.pbxnsip.com/index.php/Linking_..._to_an_IVR_Node shows how to do this with PHP, I guess you have already seen it. The mySQL part is missing, though. But there is plenty of resources available on this topic.

I would solve this problem by a email-to-SMS mechanism. Most cell phones even support email, which would make things even easier - just attach the voicemail and then those support guys can listen to the VM in alomost real-time in a very convenient way. The problem with calling the cellphones at the same time would be that practically most installations would run out of PSTN channels when the PBX starts "blasting" out calls. In order to solve this, those calls would have to serialized, and that is not so easy.

I would solve that problem by setting a very long timeout (like 999 seconds) on stage 3. There you can list all extensions that should ring "forever". Looping is not a good idea (though it should be possible!), the PBX has a hard time detecting and fighting such loops. Imagine that all extensions are not registered, and then the stage duration is very short (like 0 seconds), and then such a loop will be an "endless" loop. After a reboot, typically all extensions are not registered for a few seconds, and then if a call comes in you have an endless loop. The night mode should be straight-forward. Don't forget to put a 8 in front of the mailbox number, so that it does not ring the extension first.

We solve that problem by changing the the index. Instead of "1-25 26-50 51-75" and so on we'll put the actual account there, so that you can immediately click on the right link, for example "401-425 426-456 457-co9".

Will also be fixed in 2.1.11... It was indeed pretty "open".

Well, the service provider obviously uses software that discards the line parameter in the URI. This is not RFC compliant, and that is because of the problem we are facting here - someone (the PBX) registeres several contacts and when the call comes it it needs to know where exactly it should go. The workaround it to send the call to a tel:alias. But this is not very reliable and the PBX needs to perform a table scan on the trunks to locate the right trunk. If you have a lot of trunks that will take some time, and if you have a lot of calls the CPU will start choking. Maybe you can tell the service provider they need to fix this problem. The RFC was released in 2001 and it is time to support this.

What you could do is copy the message to different mailboxes. Check out http://wiki.pbxnsip.com/index.php/Mailbox, there you can see how to copy a message. Though this is not done automatically, someone must manually do the copy.

What phone? Did you go through the Wiki? If there is something missing on the Wiki we should update it, so that it works right from the beginning.

Maybe we should make this a feature. Now that we have a file-system based spool directory and a thread that can take forever to prepare the email it would be possible.

You mean the DTMF done coming from the phone?

ACK. Another fix for 2.1.11.

Well that is the purpose of the affinity... Worst case is that the Linux distribution is not supporting it, then there is not way to make sure that the core does not shift processes around.

On the PBX, it is not possible right now... Any chance to do that on the phone? What phone are you using?

Whow, you are right! Will be fixed in 2.1.11.