Vodia PBX

Well, sounds like you want to do "number guessing" (call completion is something else: When you call comeone and you can't connect, the system will give the phone a hint when the extension becomes available again). Number guessing via LDAP is a difficult beast. Do you want to do this locally on the phone? Or do you want to involve the PBX? Locally on the phone might be easier, though a reboot would kill your list. Via LDAP might be a problem, we had some posts in this area recently.

The log is susped to be from the side that had no media (attaching the healthy side would make not so much sense).

As for domains: Nope. The answer here is to have one template domain with everything 100 % right and then clone this over and over. Once that is done, changes are becoming difficult. For extensions there are certain operations that can be done for multiple extensions in a domain, e.g. rebott. And loading settings via CSV is an option to get multiple things done quickly.

It will be difficult to get that done in PHP I believe. CSTA has little to do with HTTP, you would have to operate PHP on naked sockets. You could try to use the click-to-dial URL method, which is able to initiate a call; however things like hanging up are already a problem.

Well, we discussed that recently. Problem is that in the call center environment, people love to use such codes to trace when agents logged in and out. For me the answer was: Show star codes in the CDR, but dont show them in the web interface. We are moving things to JavaScript anyway here, so that at the end of the day this will be in the hands if the web code anyway and if neccessary, admins can change it.

It could be that the user has seized a CO-line when placing the call (why is another question). Anyway, I remember there were some situations where the CO line could get stuck "on", but as far as I remember the situation goes away after the next reboot or after the seizure timeout (usually 60 seconds).

Oh yes, the loopback thing has changed. It should be properly documented in the wiki. Sorry about that, but the version 3 loopback was problematic in many ways.

Hmm. It is not very clear. Do you have trunk logging turned on? If it would associate the call with a trunk, it would say so in the log. And if it would not associate the call with a trunk and the from-User is not known, then it would also say so. Otherwise, you would see that it tries to go through a dialplan, but again nothing in the log. For for now, I think the "bug" must be in the logging part...

Check this: Do you have a domain with the name "domain.com"? Configured on your PBX? Did you set a country code for the domain? If you set it to "1", all numbers in the dialplan will be presented as 10-digit numbers (xxxxxxxxxx or 011yxz). Make sure that the dialplan does that. If you have only one domain running on your PBX, you can also add the name "localhost" to the list of domains, this acts like a wildcard Do you have a account with the name "12" on your system? Does this account have a dial plan assigned either on account level or domain level that allows dialling this number? I guess the call does never make it to the trunk level, looking at the log. Right?

In the trunk routing section (see http://wiki.snomone.com/index.php?title=Inbounds_Calls#How_the_System_Routes_a_Call_to_the_Proper_Extension), you can use the "f" flag to send the call to an extension that depends on the "From" field. You can change the domain alias to look like a HTTP (or SIP) domain. Make sure you keep the "localhost" name in the list of alias names, this makes youe life easier in environments where you have only one domain (like in the snom ONE free). I think in version 4 we have a setting for the routing prefix (like a tech prefix) that you can use, check out your trunk settings. (in the next version this will be a lot more flexible, there you can put anything you like). A little bit hard to say as I dont undestand the Asterisk scripting language; however take a look at the "send call to extension" section of the Wiki, you can also get a lot of things done there. Also keep in mind that you can assign alias names not only to domains, but also to accounts inside the domain, expecially for 10-digit numbers which gives you additional routing flexibility.

The link does not work for me... Can you attach it here?

Thats probably the problem. Did you "play" with the outbound proxy or the "Explicitly list addresses for inbound traffic"? Maybe just put 192.168.0.90 there.

CSTA is the way to go. If there is something (useful) missung let us know and we'll schedule it for an upcoming release.

That looks pretty okay to me. The calls with MOS 1 probably just means there was a device that does not support RTCP properly or at all.

Maybe lets do a step back and discuss what kind of problem you have. Maybe we have to change the LDAP on the server side to get this done.

Eh yea seems you went down to road of billing... Do you need that? I would remove everything that has to do with billing: rates, credit in the domain and the extension.

The MOS is really only about the network performance, it does not matter if the users are talking nonsense or not. You also have to see it statistically. Especially short calls can have a high uncertanty regarding the quality, and then you have such blips on the radar. The last picture has a lot of low-quality calls, and that would concern me. The next version will have those graphs also per extension and per trunk, so it is easier to find the root of the problem.

Maybe you can quickly check if there is any redirection going on. What could happen is that callers get redirected in a circle then end up at the beginning of the queue.

If the other side does not support the AOC information, it should (silently) drop it. Actually, technically, 400 on a INFO does not terminate the dialog and it does not have to. Anyway, the AOC information probably comes from the trunk rates. If your service provider drops the call on this, it is probably not possible to do rates on this trunk. Try to remove the rates and see if the calls go through.

If UDP or TCP should work, check if you are checking the certificates. maybe because of the time, the phone now believes that the certificate is invalid because of the time for which it has been signed (if the phone is in the year 1970 it might complain that the certificate is not valid before 2010).

Please keep in mind that the LDAP server on the PBX has a very limited functionality. The PnP mechanism provisons something into the LDAP settings of the phone that should work. If you start editing t, changes are pretty hght you are hitting something that is simply not implemented on the PBX.

What is your NIC setup? Are you using both NIC? Unfortunately it is not possible to log in to the box and take a look (design decision ). Maybe there is just something wrong with the iptables on the box.

Made some more progress today... There was more than one bug in this area

You can also use PnP in Starbucks. But you need to manually put in the provisioning URL, the username and the password. Then the phone will pull down the configuration over the internet and all settings are fine (at least a working starting point). This will save you a lot of time for try & error. The URL that you need to copy into the settings server of the PBX is here: http://wiki.snomone.com/index.php?title=Plug_and_Play.

Don't use the dialog-state BLF, this is very difficult to get working and you get another subscription for each button you have (not many in the case of 821, but a design misconception). You should just use buttons, which you can conveniently setup from the PBX web interface and then PnP to the phone.