Vodia PBX

No you can turn on translations and then you should see the item of the next page you are visiting. It will also write a dict file, if you feel more comfortable editing files, you can edit that file instead. It will pick it up the next time you restart the service.

You can "translate" those items in admin mode. The tag name is "sysadmin".

Well, this should work... Did you automatically provision the phone? Change anything with the display of the caller-ID? The PBX should update the caller-ID in the P-Asserted-Identity header and the phone should update its display.

The "master" snapshots sometimes contain new features where there translations are not in the release dictionary yet. Why those email are missing translations is something that should not happen, though. If you can, please try the 5.3.2a .dat file. A couple of items did not make it there which should now be included.

No we can help you only with the Vodia PBX...

Well the INVITE comes from "FPBX-2.9.0(1.8.23.1)", not from the Vodia PBX.

Can you post the INVITE here in the message thread (change the phone number to something like 123456789)? Then we may be able to see where the problem is. From your description I still don't get where the problem is and if the PBX is involved at all.

Check on the router if there is something like a application layer gateway (ALG) for SIP, and if that is so, turn it off. Or just use TLS for SIP, which is the default if you automatically provision the phones. Are we talking here about problems with the phone or with the SIP trunk provider? Who is dropping the line parameter? SIP phones usually don't send OPTION messages...

Is there a firewall involved? Can you get a SIP log from the PBX with the call messages enabled? It should show the line parameter.

I am not so sure. They should still support call waiting. They have a display, after all and it will show the incoming call. It should be easy to try that out! And the beauty of it, this would be an extremely simple solution.

Yea it is sometimes hard to keep the message threads separated. But that can also be the beauty of a forum! In the old days we had the same problem: The Call-ID generated from the PBX were not random. Actually not all. The reason is that the C-library function rand() is actually deterministic, and it always starts with the same value after a reboot. That is when we discovered the function srand. I guess that device has the same problem. If it is a soft phone, it might actually happen if it gets started up, which may happen a lot on a PC. Who ever has written the software, send them a link to the srand library function. The 2nd paragraph was about the question what the PBX should do about it. The answer is, it should still work. The Call-ID is only a part of the call identifier; only if the IP address and the To-tag are the same, the PBX will have problems telling the calls apart. This might happen if the softphone gets restarted quickly; in that case a couple of wrong CDR entries are the least problem.

Well most phones offer a call waiting function where you can see the 2nd call coming in. Then you just have to accept the 2nd call, which will put the first call on hold; then you can toggle between then and e.g. transfer them to another line. For that you don't need any group function.

Could it be that some of your phones are using the same Call-ID? For example VoIP phones that don't have the clock set don't have any random input and always generate the same Call-ID after a reboot. In that case I don't think it would be a serious problem. We have changed something in the subsystem recently that should make the PBX more robust against timeouts when calls disappear. Although I have problems making the direct connection, it might cause something like that.

Thanks, next versions will have those.

That should work. I would turn log levels for TLS and the web client to 9 and check the log.

Very old versions have two problems. First of all, they are still using the snomone.com domain which is not working any more and secondly, the vodia.com web site had to use a SHA-2 certificate which was not supported by the old PBX versions. You should upgrade to at least to 5.2.6 then it will work again.

It gives you a clue who is really operating it!

When it comes to interoperability CO lines are not a reality yet. There were some proprietary implementations from snom and from BroadSoft, but their support in the endpoints had their ups and downs. There is a new RFC available for SLA, however we are not aware about any implementations yet. If you want to get things done this year, I would rather use park orbits and/or hunt groups and ACD groups.

You could use a hunt group for that. Or you can use redirect on busy for that extension. Depending on your call volume, using an agent group could also make sense. There are several ways to get this done, this is a typical problem that can be addressed with a PBX.

You have to keep in mind that sometimes the carrier are also changing stuff. That may have that effect.

Sounds to me like a problem with the SIP trunk provider. Good that it is reproducible. A PCAP trace will probably show what the problem is. If you like, open a ticket and attach the PCAP then we can comment on it.

A 403 code generally means that the call could be identified, but was not allowed. Did you set and permissions for the extension that is supposed to be called (default is that it is allowed). I would turn on the PCAP recording feature for the gateway trunk, then you can see all the details of the call, including the proposed destination. Also, double check if the gateway keeps filling up the hard drive with log messages. This was one of the major problems with that setup. You can also give at Vodia access to the system with a phone number that we can call for testing purposes, and we'll figure it out for you. Please open a individual ticket for this.

The pattern matching is exactly the same like outbound calls, just that it looks at the "From" header not the "To" header. Did you get outbound rates working fine so far? Also there is a difference that the inbound calls are not deducted from the domain or extension balance, simply because nothing can stop incoming calls from occurring. They are reported though e.g. in the CDR.

We have some code available at http://vodia.com/documentation/vodia_php_rest_api did you see that?

If you don't PnP then there is no generated folder and no problem either. Maybe you should open a ticket and give us access to the system, so we can figure out what is wrong.