Vodia PBX

Well in other time zones it does work. I guess it is because the "dst_start_day" (and "dst_stop_day") are missing: <zone name="CAT"> <description>Central African Time</description> <gmt_offset>7200</gmt_offset> </zone> You might want to try: <zone name="CAT"> <description>Central African Time</description> <gmt_offset>7200</gmt_offset> <dst_start_day>2</dst_start_day> </zone> For Polycom, the day gets multiplied by 7. If you want to use the raw input, use the name "dst-start-day" in the template.

You could either take the line out completely, then the user can configure the phone locally (on the phone). Or you change the button 6 line the buttons 1/2, so that the user can use the web interface of the PBX to set the button up: {if_button 6 none} <fkey idx="5" context="active" perm="RW">{enum_button 6 button+6 private=line}</fkey> {fi_button 6 none} However those changes apply to all users then and all users must set up the button.

Don't remove the entries, just leave them empty (so that the PBX will send a empty string).

Well, it seems the only way to solve both problems is to change the LDAP processing in the PBX, so that it only matches the beginning, not anywhere. It would also speed up the processing I guess.

You can edit the file ringtones.xml through the web interface (admin/web page control/templates) and put there whatever you want.

I would guess that the NAT table is full. Some routers have only 32 entries and each registration takes one (UDP or TCP); each call takes two UDP ports (RTP and RTCP). And you probably have other devices behind NAT as well.

You mean it really includes the dashes in the star code?! Then it would be very understandable that this would fail.

Well, inbound calling is more complex that it might seem at first glance, the extension alias is just a part of the problem (see http://wiki.snomone.com/index.php?title=Inbounds_Calls). For example, the question is if the number is to be found in the Request-URI or in the To-header of the call. There is even a new SIP header available, which further complicates matters (P-Called-Party-ID). Then once that is clear, the PBX needs to figure out what the number looks like in the country. For example, in the USA the number 9787462777 or 19787462777 would be +19787462777. Unfortunately, there is no standard for SIP trunking so for each and every SIP provider it becomes neccessary to finetune parameters to get it working.

Generally speaking the PBX cares no too much about the characters, it is using UTF-8 (which is easy). However, displaying the UTF-8 characters set might be challenging for the phones, as there need to be more than the usual 95 characters found in the ASCII table.

Seems like your key actication is some time ago? The new license should have more than four. Try to go to the license page and change the actication code to some bogus code, hit save, then enter the original code again, so that the PBX will be forced to fetch the latest license key.

You must do that using the general rules for outbound calls. There is no difference for the PBX between using a registered SIP extension and a cell phone when placing outbound calls. That means you can use the dial plan (maybe create one specifically for the extension that has the cell phone associated), or you can use PIN code authentication for outbound calls (also in the dial plan).

The format for creating an account and changing the alias names for an account are different. When creating an account, the slash symbol is the seperator for the names of the account. When editing the alias field of the account the names are seperated by space characters. If you set the country code, the PBX will try to internally store the alias name in a global format starting with "+", so that it is easier to compare the names in the database with the name for the incoming calls. You can see what the PBX stores by looking at the file system in the user_alias directory.

On the PBX, you can't do that, at least right now. Maybe it makes more sense to do that on the PA1, because when communication gets lost and the PA1 keeps the call on forever, you will not be able to page ever again until the reboot of the PA1. To put it another way, both sides must have a mechanism to clear the call eventually. The PBX has it, the PA1 does not have it yet and it needs to be added.

Looks like you just have to set the default route. Probably the OS randomly picked the wrong interface for this.

I know that callcentric sends the right caller-ID in case that the PBX redirects the call to the cell phone. They take a look at the "Related-Call-ID" header, so that they know that the PBX is not inventing a number.

That looks like a bug with the LDAP. Probably the phone asks the PBX "is ther eany match for 2434? And the PBX answers with the extension name. You can try to disable the LDAP port to see if that is the problem (clear the LDAP setting in the admin/ports section and restart the service).

You have to make sure that the operating system has the right IP routing setup. "route print" is your friend here. The OS sometime chooses kind of random routes, which make life difficult. But once that you have routable IP addresses and the routing is right, it should be working smoothly. Routable IP addresses don't have to be public, as long as every associated party is able to "ping" the PBX directly without NAT port forwarding tricks.

Yes you should get an email. Where did you send it? To the admin or to the user (both is possible). Also, check your SPAM folder.

That almost looks like the process is slowly running out of memory. You could switch to the 64-bit version or at least check if you have too many CDR in your system. After a restart, yo ushould check the status page of the PBX and see if there is an unusual igh number of CDR or memory.

No, memory does not go down. The way the memory allocation works in the PBX is that is does perform a garbage collection, but never returns memory to the OS. This is because of the real-time nature of the PBX and the requirement that it should run "forever" (or the next software update). Otherwise, you'll sooner or later up with memory fragmentation, that's where on the paper the process owns only relatively small amount of memory, but the OS cannot allocate new any more.

You need to turn the SIP logging on if you want to see the INVITE request, it is a SIP request.

Well, the PBX chooses a random PIN after startup. Otherwise, the PIN would be an "open secret", in other words: no secret. But of course you can set it with whatever you consider safe and secure. If you have file system access, you find the PIN in the domain XML file.

Looks to me more like trouble with the phone. While is still answers the challenge (401), it does not response to the 200 after the call connects. This does not look like a problem with the firewall, because the 401 obviously makes it.

Check out the auto attendant and the service flag. The auto attendant contains the message that should be played; and the service flag is used to define when that message should be played.

Yes, in the SIP trace, the INVITE request. There is a From-header, it would be interesting to see what is there.