Vodia PBX

Debian: http://pbxnsip.com/protect/pbxctrl-debian4.0-3.1.1.3094 ANI: Did you try choosing the "Remote Party/Privacy Indication"? Maybe just set it to "No Indication"?

Yea, that problem is fixed in 3.1 - but we are still working on getting a good 3.1.1 that we can release publically.

Sure you should be able to do that. Check out the above file, there is for example {account} in the file that depends on the MAC.

It should be working. Did you also put a second destination there? Every Service Flag Account must correspond to a Night Service Number.

All you have to do is put the above file into the html directory. Then you can also make local changes there. Only if you add a PnP parameter you need to restart the system, otherwise the file drop will already do the job.

You mean if you keep the WAV in the system then it also does not work? IMHO it should only be a problem if you select that the message is deleted after the email has been sent. The idea about the exploder is related to your email service. If you can set up a group email account then the email server will distribute the email to the group members and the PBX has to send only one account.

There was probably another problem with empty user names. If you can make the gateway use "anonymous@..." it would of course solve the problem. We'll try to incorporate a fix in the 3.1.1 version. If you want a preview, let me know what OS you have.

Well, currently we are using the attached template. Ideally, if you have a improvement proposal we just add it there. We can also add PnP parameters to make the file a little bit more flexible. spa_phone.txt

What did you put in as country code? Seems the beautification tried to be tooo nice...

G.711 needs 64 kbit/s, and RTP adds an overhead of 24 kbit if you have 20 ms packets. That is 88 kbit/s per channel, so 176 for both channels. Add some extra for the SIP packets and then 192 is pretty realistic. If you choose different codecs the picture changes. G.711 is a "worst case" scenario.

Hmm, not sure why FreeSWITCH replies with with a "call" when trying to register. But that looks like a bug to me. Or maybe it is something trivial like that user really does not exist.

Okay, that setting is fine. Of course it is possible to have callers in the queue for 2 minutes (unfortunately for them). 2 minutes just sound like there is a problem on the SIP level. Is there anything in the log where the PBX explains why it disconnects the call? Are you using redirections with the value of two minutes?

The problem is that we delete the file after the first email is out. It is hard to keep track of the "last" email. If we send just one email you can see who else receives the voicemail; though this seems to me the best way to solve this problem. Workaround is to use a email-list, so that the email server "explodes" the email to the various recipients.

If you don't have to, don't upgrade. Release notes for 3.1 are here: http://wiki.pbxnsip.com/index.php/Release_Notes_3.1. Maybe you wait for 3.1.1; then you will probably have no upgrade problem.

That's a feature. You can also spefify the initial waiting time, just updated http://wiki.pbxnsip.com/index.php/Agent_Group. Are those calls technically connected (on SIP level, did the PBX send "200 Ok")? Otherwise, this is just the regular ringing timeout. Calls generally cannot stay unconnected for a too long time. What is the "Event for connecting the call"?

You can have a preview version already Currently at http://pbxnsip.com/protect/pbxctrl-3.1.1.3091.exe.

Yes, there is - send a email to support and then you get it.

Yea, this is really strange (was also reported by other people). If you like, try http://pbxnsip.com/protect/pbxctrl-3.1.1.3091.exe this may fix the problem.

Even the temporary fix is not so easy as we need to split the cell phone entry up into a own table. So I would vote for doing it right and skipping a fix.

Yea, that was a good one. This fix will be included in 3.1.1.

We checked this feature - in principle that's possible. The reason why we did not have this yet is that the trunk requires a failover context, and for a calls we currently have only one. It is not a huge problem; it is that it just needs to be done and we want to make sure we don't create any side effects...

The intention is that this box is not being used as a PBX for a large organization and usually three trunks should be really enough (PSTN, ITSP, HQ trunk). However, I believe that if you send a friendly email to sales they won't be too bitchy about it and give you a upgrade.

Did you use "1" as country code? Then those transformations IMHO make sense. Okay, the upgrade procedure is a little bit bumpy, but then we have a clean solution. The whole magic is disabled when there is no country code. But IMHO it makes sense to specify the country code and let the PBX convert the different telephone number formats into a normalized format.

Version 3.1 will have it's seperate PnP dialplan in the domain. Maybe that solves this problem. The attached dialplan is the current state. snom_3xx_dialplan_usa3.xml

Presence is a topic that sounds nice on the datasheet, but I never saw real people in real life using something else than MSN, Yahoo or Skype. Believe it or not, but the PBX has a presence agent. Nobody knows about it or even uses it. The problem is that publishing presence from a phone is just too inconvient. Once you have a PC, it is just so much easier and colorful to use MSN & Co. Just my two cents!