Vodia PBX

Sorry forgot to point out that you can use that trick to set the outbound proxy for all devices. Just use 0.0.0.0/0 as the net mask and it will apply to everything.

You must make sure that you use the 32 bit version on a 32 bit system and the 64 bit version on the 64 bit system. The TSP has data structures that make it impossible to stay backward compatible. Maybe that was the problem!

Yes, unfortunately debugging TAPI is not so easy. You cannot imagine how many times we had to reboot the system to get the TSP working... That is probably also necessary in order to get the logging going. When you install office 365 and/or Lync, you have to change the registry in order to use TAPI (see http://www.vodia.com/documentation/tsp at the bottom); I assume you have already done that. Hopefully we can get a log, then we can hopefully get a clue what the problem is.

Is that something that we should include in the yealink provisioning template?

In 5.2 you can control the outbound proxy based on the location where the phone is being provisioned. The classical use case for this is that a corporate office is using a local SIP-aware firewall that should act as proxy (so that the bandwidth can be properly allocated). More information on http://www.vodia.com/documentation/domain_settings and http://blog.vodia.com/2014/04/hosted-pbx-and-sip-alg.html

Well that should really, really work unless you have a firewall that blocks TLS.

These days it is easy to get paranoid. Are they somehow accessible from the public Internet? Maybe there is a scanner that is causing those calls. We got bashed in the old days for dropping packets not coming from the registrar as it is not RFC compliant; but now in the world we are living in such RFC compliance can hit you hard. I don't think this is a software bug on the phones per se. There must be some traffic hitting the phone. Maybe there is a way to find out with PCAP and port mirroring on the switch they are connected to. If there are so many calls per day it should be easy to find out where it comes from (unless they also spoof the source IP, which is easy on UDP). At least we can see if the packet comes from the PBX.

Well what phones are you using? Did you change the templates?

Do you have a hangup problem? Some PSTN gateways don't properly detect hangup and then you have exactly that problem. Or does refreshing the web page show it immediately (then we would have a problem maybe with the websocket connection, which could be related to the firewall).

Sounds like a problem with the browser cache? If you look at this from a different computer, do you see the picture then?

Sure. Actually it should be the default e.g. for snom phones (not sure about Polycom at that time). Make sure that the transport layer on the phone SIP registration is TLS. You might have to put the PBX certificate into the phone, so that it will trust the PBX.

Well in an ideal world, the phone would get the list of missed calls from the PBX, so that the PBX has the option to take a missed call off that list when the number is being called. However in the SIP world, the phones keep their own list of missed calls, the PBX can only control if a call should be considered missed or not. That is why we went for the workaround for the missed call email (in the hunt group settings). If we tell the phone that the call was missed, we can do this only for those phones who are actively ringing at the time when the A party cancel the call. Once the hunt group moves on to another stage, phones that were only present on previous stages will not get notified. Moving to the final stage will not count as "missed call".

This is a kind of FAQ. The problem is that if the call shows as "missed" on each phone, people would call back (hopefully) and the client would receíve multiple callbacks, which is quite annoying. Because of this problem we have put in the possibility to send out an email in that case, which can be processed in a way that avoids multiple callbacks.

That means that you need to set the SIP and the HTTP password for that extension. This is a potential security problem.

It took a while, but now we have the new VDSL connection (with own IPv6 address :-)) I guess in the next couple of days we can give it a try.

Hmm. Not sure but maybe it is just caused by the phone and it is normal. Some devices need to take a deep breath before they get going. For example it might go through its address book to check if it already has the number stored somewhere (depending on the intelligent implementation that might take some time even if the address book is empty).

Do you press the "dial" button after entering the number? How long is the lag?

Ok. Next version will have this. In the meantime, you can exit the pbx.xml and change the nat_tcp2 setting to 600 (which requires a restart). As long as you don't save anything on the page, this should be working fine for you.

That looks pretty cool. Did you already try to get a PCAP trace for this? Is the join.me server responding at all?

In France the country code would be 33, not 0033 (at least that is what you would put into the domain setting). The problem with the call history is when the call comes in, you show the number without the prefix. Lets say you are in France and receive a call from Germany. The number you would see would be for example 0049301234567. Then when you call back, the PBX would see the first 0 and say "aha, that is a outbound call" and then dial 049301234567 which would be some number in France. The PBX does not put anything into the call history to add a prefix. I know this would be a solution so that customers can call back numbers in case that they have missed a call. I have seen (other vendors) PBX system that do that, but at the end of the day the users were penciling down the numbers and then entering them again with/out the prefix. And they were not happy with their phone system, understandably.

If you want to use prefixes, it is important that you do not use a country code in the domain. The country code tells the PBX how to interpret numbers (this is done pretty much like your cell phone would read a number in the region). If you want to put prefixes there to imitate the good-old line-seize behavior when every digit was sent to the PBX, then numbers starting with a zero will obviously confuse the PBX.

Well your license might have only one domain. You can check on the status web page of the PBX.

No this is not possible as it would violate the "sandbox" principle (tenants).

There is some information on http://www.vodia.com/documentation/ivrnodes, if you need further help please purchase a ticket for individual support.

Those texts are generally multi-language texts, so they are not in the email templates themselves. You can turn on translation and "translate" the text to whatever you need.