Vodia PBX

The PBX has to provision the Custom_CA_Rule - this is no big deal. However as fas as I can see the PBX domain name needs to be a read DNS address - in other words this will not work if the domain name is "localhost".

Well getting the certificate is not so easy - IMHO near impossible definitively impractical. We will add something to the next template that will try to provision the certificate along with the other information.

Cisco by default trust only certificated issued by Cisco. You'll need to import the Root CA that has signed the PBX certificate - e.g. the letsencrypt Root CA.

Previously the blacklisting was strictly on per port basis, which did not make much sense for TCP/TLS. Now it is on address basis unless there is something whitelisted on that address already. We still have an issue with trunks, it is not clear what exactly triggers it.

There was still one glitch with at least one of the the 61.1 builds - which was fixed with 62.0. We still have reports that trunks get blacklisted, it seems to be related to using DNS addresses in the explicit list for the approved IP addresses.

Try to move to 62.0, we have made a lot of changes to get the 8851 working perfectly, including settings the button profiles from the PBX web interface.

No Grandstream works completely different that Yealink. In 62 you can always see what was sent to the phone right from the web interface (except the passwords), including the LDAP settings. Usually that helps a lot troubleshooting the issues.

I would turn logging for the webclient and watch what is happening when you hit the test button. There should be messages going back and forth with freshbooks; the authentication phase is the important one. Another thing is that you need at least some history - after you have set it up you might have to wait a day to see any useful usage information.

I think the yealink_favorite came in after 61.0

Something must be out of sync here ... Are we talking version 62.0?

We don't touch the local address book of the phone - users are welcome to use it for "penciling down" their contacts; however to the PBX they are invisible. LDAP is the opposite - nothing stored on the phone, everything comes from the PBX. Yealink has a preference file that tells the phone which address books are available, which is in the yealink_favorite.xml file. Do you see this file being sent to the phone during the provisioning process?

For Yealink and Grandstream we provision the settings that are needed to pull the address book from LDAP - this should work completely invisible to the user and just work. If there is a problem I would try to get a PCAP trace (Yealink can do this right from the web interface) and see if there may be a problem in network layer doing LDAP.

LoL RFC3261 has many concepts and ideas, e.g. we would love to see support for the In-Reply-To header from SIP trunk providers. Also SDP is not even in 3261. Anyway, I would just try it out with a demo code on version 62.

Are you sure this message comes from the PBX? The PBX does not generate a message like this as far as I can see.

Without really looking into the details (this is a pretty old version) the problem will be that the door phone sends a SDP with multiple m-lines, which probably confuses the PBX. What you can try here is to disable the video function on the door phone or make a backup and try and upgrade to version 62 to see if it works there without problems.

There is some documentation at https://doc.vodia.com/trunk_ani on how the PBX determines the caller-ID. However many carries don't allow caller-ID that are no owned by the PBX on their trunks, which is understandable considering the problems with SPAM calls.

The From/To headers have become useless - the remote party is usually indicated in the P-Asserted-Identity header. We are not aware about one single way to address this with all SIP trunk providers, it seems that everybody has a slightly different opinion about it. It would be great what provider you are using and how they want it.

You also have to keep in mind that Freshbooks came up with a API V2 - which is totally different from API V1. If you recently signed up you'll need the V2 support. That was no available when 5.2.5 was made.

This should be fixed in the latest version so an upgrade would also solve the issue.

The idea about the logo is that this a a company logo - usually easily presentable as a vector with colors. The problem is that most VoIP phones today take a very technical view on it and provide a mechanism to upload a wall paper which on some phones stays there even if there is a call going on. This is not the same thing. We are now provisioning well over 100 different models that have color displays. It is not very easy to keep up with new displays and user interfaces - it would be great if new VoIP phone firmware would be able to pull a PNG or SVG image and handle the logo display locally and properly.

Sorry about that confusion. 888VoIP is a US distribution company. We highly recommend them if you are purchasing in the USA. For other countries everything stays the same. The portal for vodia is still available for you 24/7.

Well lets face it - shared lines are a dinosaur like like the prefix that got killed with Kari's law this year. There is simply no such thing as a line in the world of SIP trunks. We still have something that shows the state of a CO line account, but it is not the same like a original TDM CO line. It would be much easier to just use a park orbit or use the hold/transfer features that practically every VoIP phones offers today. We had many clients that came from CO-line world and they did not cry a single tear dropping the concept and more on to park orbits or handling the calls locally on their phones.

In the later versions (I would assume at least 61.0 has it) the qop gets quoted only if it contains a comma. So it would send qop=auth and qop="auth,auth-int". This should work with anything out there without the need to introduce a setting for this.

Latest 61.1 version has {domain-alias} for this purpose.

If you have a newer Polycom phone (possibly XXV series) maybe you can compare how they work and then check in how far the older models are compatible to that.