Vodia PBX

I made a quick test here. From the phone, I could only set the call forward for all calls. Then when changing the call forward from the web interface of the PBX to call forward after timeout, the display on the phone flickers a little bit and still shows "CFwd: 45", which is not 100 % correct (because this is not call forward all, just call forward after timeout). The PBX sends: <?xml version="1.0" encoding="UTF-8"?> <ForwardingEvent xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3"> <device>49@pbx.company.com</device> <forwardingType>forwardNoAns</forwardingType> <forwardStatus>true</forwardStatus> <forwardTo>45</forwardTo> <ringCount>2</ringCount> </ForwardingEvent> So it seems to me like the phone has a problem showing the exact forward type. It is probably just a hint that calls might be forwarded, without being specific about the event.

So when you set the CFNA from the web interface, does it work as expected? The phones are using some CSTA stuff to set the parameters on the PBX. Maybe there is something buggy in the interface btw the phone and the PBX.

I think the easiest is to mount the recordings directory on the snom ONE plus, so that you can access it from the outside. I am not even sure if the snom ONE plus comes with Windows or Linux, but in both cases you can use the operating system to give outside parties access to the folder.

Well we had customers that uploaded 40000 address book entries into the domain. The problem with the search functionality is that they easily trigger a table scan, which can be a major burden for the PBX. That is th ebiggest problem that I see with LDAP (and other search methods). Honestly, if the phone gets screwed up because it has to scan 40000 entries that is not our (PBX) problem, and it does not affect a central network component and it is only one user suffering.

We are working on that right now.

Maybe for the phones that have a large memory it would really make sense to synchronize the address book into the phone, just like this is a reality with the cell phones today. Then the phone can handle such functions locally (and fast).

Could be that the file system is full. We had cases where the logging did not include the day, so that over time the file system was getting full. We had another case where the call recording filled up the file system space.

Did you set the phone to use TFTP? The default is as far as I remember FTP. And you should also set the username and the password, so that the PBX can generate the files for this extension. http://kiwi.pbxnsip.com/index.php/Polycom

There is a setting in admin/pnp/general weather the PBX should write those files to the file system or to the log.

Good point. I quickly checked the wiki for the phones, but could not figure out what the PBX needs to provision in order to have it in user mode. Yes, every extension should have its own folder.

You mean there is a loop hole so that the user could get from user login to admin login on the phone? Anyway, I think the important part is that when the user reboots, the phone fetches the admin password again and hopefully than local changes that he might have done are overwritten.

What you see in the attachment of the email is the other side of the call (the one that causes the issue). So it makes sense to see only the INVITE. With 99.99 % probabilty this is a firewall issue, maybe an issue with the UDP packet size, maybe the firewall has a built-in SIP ALG that does more hard than it helps. I would use TLS transport layer (plug and play!), then the firewall has no chance to mess with the packets and it will probably work.

It is indeed interesting that he could even log on. He should not be able to do that (thats the plan!). Are you keeping the provisioning files in the generated directory? There you can check what has been provisoned to the phone and if it contained the right password.

There are cases where this behavior is "okay" from the PBX perspective. For example, if the trunk is registered for lets say the next one hour and DSL network goes down, the PBX will believe that the trunk is fine and show "registered". After half an hour, it will try to re-register again, try to resolve DNS and this will eventually fail and the PBX cannot send the packet out. Then it is debatable if the trunk should be considered "registered" or not; because the registrar will sit there and also believe that the trunk is registered for the half hour. Eventually after the network is up again, the PBX should register again and the operation continues. There are a couple of timeouts involved here (especially on the DNS side), so I would say it should re-register after one to five minutes.

AFAIK the Vision uses CSTA, and the (only?) way to do this is to have it register to the CSTA server of the phone.

I would start editing the XML template and explicitly set the NTP server so something known to work.

It will not make it into the next release. I would say the one after that will be maybe in 3 months. But regardless we should try with head builds to see how it works in the real life (beta versions), that could happen in two weeks timeframe.

MAny providers have a problem with the RFC3325 presentation that we are doing-. Try the settings "No Indication" in the trunk settungs and see if that solves the problem.

Yea, that is a known problem... LDAP is also not the answer (more new problems that problems solved). Not sure what is the next step there, maybe we just statically provision the address book during the start up...

Some posts dont get answered, sorry when this happens. We usually check the "new posts" (which are within the last 24 hours I believe) and try to answer them or at least set reminders. No problem is you add another one with a "ping".

Whatever you do, think of calls that go over the trunk as calls that run over the public telephone network, that mens choose telephone numbers that look or are real. There is a lot of confusion if you use numbers that are 41 on one system and the other system has a 41. If there is not NAT involved (for example when you are able to use VPN), I would just use two gateway trunks. If there is NAT, then things get tricky because one trunk needs to register with another trunk. Maybe that would be another topic on the forum. If you have a lot of trunks, consider using the text form for the trunk setup (makes editing them easier) and also for the dial plan.

Well, the PBX uses the header in certain cases e.g. when redirecting to an external mailbox. But not in the case of forking the call to the cell phone. IMHO it is debatable if this is a diversion, because the desktop phones might also be ringing at the same time. But I dont see how a Diversion header would hurt, so maybe we need to add this header as well.

In the SIP messages that you sent to us only G.729A is being offered. Maybe you need to change the settings on the provider side to change the codec.

Also please try TLS. There was one issue that required an authenticated connection, and TCP does not provide that.

I assume they are all using the same registration? Also, make sure you are using TLS, there were a couple of issues with UDP at least when using the PUBLISH method.