Vodia PBX

Okay, now we know that this is not specific to *77. The version that you are running is somewhat outdated; what could be a problem is that the number of G.729A codecs is exhausted. There was a bug in the older version that could cause this problem. Any chance to upgrade? 4.5 (Beta Corodindis) is available. If you backup your configuration and see if the trunks are working fine after the upgrade (try this after hours to minimize the disturbance), it would be worth giving it a try. If not, you can move back to the previous version.

We thought it would be a good idea to give it in addition to the number also names, and we went for comets. A, B, next is C. Alpha and Beta are somewhat confusing because people might think the Alpha release it totally untested. But when we come out with the "C" it will become clear how it works...

Well, if you can, try to upgrade to 4.5 (make a backup of the directory so that you can revert back any time). We did not hear much about the trunk reregistration problem any more for some time, consider that problem fixed.

Das ist schon sehr seltsam. Falls nach einem Reboot Caller-ID wieder geht, wird es nicht daran liegen dass sich die Konfiguration über Nacht geändert hat.

Is there something dangling in the MAC table (in the working directory)? Maybe something got screwed up. Try to overwrite the MAC address by changing it to a dummy MAC, hit save, then put the old MAC back, hit save.

Can't you just login using IPv6? That should always be possible. The URL is something like http://[fe80::204:13ff:fe44:1234], where 44:12:34 would be the last 6 numbers from the MAC address.

Before you reboot, can you take a screen shot from the status screen? It looks to me more like there are some dangling call objects there that stop the PBX from making more calls. is it only the *77 code?! I dont see what is so special about the code, there must be also other things be affected.

Well unfortunately a couple of things are different on Apple OS. http://superuser.com/questions/149312/how-to-set-processor-affinity-on-os-x says that this is not possible on MacOS; not sure if in the meantime the feature was added to the MacOS. Maybe until then, having more than one core on Mac is not a good idea

Okay, it turned out that the * character is a problem in Windows (see http://blogs.msdn.com/b/brian_dewey/archive/2004/01/19/60263.aspx). The workaround could be using a special prefix \\?\, but I guess the better solution would be to avoid asterisk characters in caller-ID or recording file path.

As far as I can see from the Internet search, it is just a Asterisk card which does not support SIP.

It is not really a limit. These are the first 32 entries; you can refine the search by entering more digits (2=ABC, 3=DEF and so on).

Please get in contact with snom (support at the snom dot com domain) and mention the IP address (and port) of the system, for example port forward, so that we can take care about this.

Ops! Are internal calls from those certain extensions working okay (that would mean we have a problem with the PSTN termination)? Is this a snom ONE plus? Or what gateway is being used?

Smells pretty much like a problem with NAT, specifically a problem with a router. Some routers have only very small NAT tables, which easily get exhaused and then you experience problems like these. If you can, try a "bigger" router to see if that changes anything.

The way to resolve that problem is to give snom SSH access to the box and we set a password that you have chosen.

Yes it was a unfortunate decision to keep users out from the system. We are looking for ways out of this.

The problem is when the hunt group calls the cell phone, it is the hunt group not the extension. Keep in mind there may be several other people trying to redirect that call as well while you punch in DTMF digits and you cannot be sure who will be the first. It is actually pretty much the same when the PBX receives a 3xx code from a SIP phone, it also takes that as a pure rejection. We went through the discussion like 5 years ago and the result is that groups and extensions have different semantics on redirection features.

On a hunt group, you dont have all options. Does it work when you call the extension directly?

Well, this should work. Did you try to turn all recording flags on on domain level and hunt group level? You can override the domain default in a hunt group, maybe thats where the problem is.

Thats not looking bad. Did you check if the file has been generated? Maybe at recordings/pippo/...? Usually those file names are relative to the working directory of the PBX. Of course, the PBX needs the permission to write a file there and also to create new directories.

I guess that will not show the problem. Generally speaking, the phones have a setting on how to show a SIP caller-ID in the form "display name" <sip:user@domain>. Usually not everything fits on the screen, so the phone picks some parts of it, which is controlled by a setting. Probably the problem is that we need to differentiate between the models when provisioning this setting. E.g. on the snom 300, you probably just want to see the user part, while on the devices with large color display, you want to see the name.

Actually, the files should be available as templates. So you can change them from the web interface and "play" with it, add custom content like the service flags. Alternatively, you can put them into the html folder, the path would then be html/snom/menu.xml. It is all content for the mini browser, the snom Wiki describes how to use it.

For example !01234567!90!f!

Hmm. Telefon nochmal neu provisionieren (neustarten)? Welches Modell ist das denn?

Das geht. Man kann es über *80 machen (http://wiki.snomone.com/index.php?title=Call_Forwarding_Codes). Das geht auch von aussen: Einfach in die eigene Maibox reintelefoinieren, über PIN einloggen, dann *80xxx wählen.