Vodia PBX

Well the way it is currently is that manual recordings are ending up in the owners mailbox. Automatic recordings end up in the tenants recordings. It's a little bit historic fro the desire to take notes in a call, but that is how it is today.

When you login, does the browser automatically switch to https?

The main problem is that the location needs to be verified first. We do that with Bandwidth in a way that they generate the URL for the location, which the PBX stores along with the location information. In the case of an emergency call, it then includes the URL in the Geolocation header. There were previous versions of the PBX that included the PIDF document in the INVITE, but that had to be scrapped because of the prior validation and location precision (what is the point of providing location information if the user is actually somewhere else). I would not be surprised if VoIP Innovations will go the same route because the way it looks to me right now, the SIP client can send anything — which might cause additional trouble with the emergency response centers. IMHO I would go for the static registration of the address, if your users are actually using the PBX always from the same location. If your users are using the app for calling 911 there is a much easier solution. The Vodia Apps can redirect emergency calls to the native dialer which sends the GPS location to the response center anyway.

Well the big question is if your service provider supports PIDF-LO. Most don't. Before investing time into this you should double check if it would make any difference. Most of the fines are not because of missing location information, they are because users are using caller-ID that don't belong to them (the location is already associated with the number). Some people think it's funny when it is clearly not.

If the Remote-Party-ID header is not present, it will still use the From header. I am not 100 % getting exactly what the problem is here. Because there is limited space (and only one header) for standard VoIP phones, we have the possibility to combine group names and caller-ID into the same header (Caller-ID to show to agents). If you choose a short group name, the caller-ID and the group name will still fit on the screen of a standard VoIP phone.

Ok so the problem was that the web server update broke the /fcm path in the URL. However it should be working again.

Oh can you enter as push server https://push-eu.vodia.net (in /reg_messages.htm).

Can you turn on the logging for web client to level 9 and see if it can communicate with push-xx.vodia.net?

Thanks, we'll include that in the next build (post 68).

We'll fix the in the next build, for now if you like try the 68.0.15.beta build where this should be fixed already.

There was an update on the push server, it now uses a certificate issued by lets encrypt. Please make sure that you list of trusted Root CA in the PBX is up to date.

The GRP because they don't require guessing Pxxx numbers. Do you remember what settings you changed in the template? I would not go for partial number matching because this can cause ugly conflicts with other numbers. Its better to make sure they are all presented in the +xxx-form so that they are 100 % clear.

Just a heads up, we have changed the certificate for the push servers to use LetsEncrypt. If you have problems waking up the app, please make sure that you update the list of trusted Root CA on the PBX.

This is what we have for the EUR zone: <area name="eur" description="European Union"> 0030 0031 0032 0033 0034 00351 00352 00353 00357 00358 00359 0036 00370 00371 00372 00385 00386 0039 0040 00420 00421 0043 0044 0045 0046 0048 0049 0060 </area> The main points for the list is to make dial plans simpler, e.g. for avoiding expensive routes. What would you expect for the UK? On a side note, it might be time to take the 0044 out...

You could try (\*[0-9]+)@.* as the pattern. Then the replacement could be just *.

RingCentral, 8x8, DialPad (if you consider them PBX) and Microsoft, Google, Salesforce, zoho, ... follow seats. Frankly, we are not in the position to teach them a lesson how to sell their software. There is no leadership here on our end, it would be delusional . The main problem with concurrent calls is that with focus shifting away from the call to other things like texting; the concurrent calls don't capture the situation any more. I would even argue that many resellers simply calculate their concurrent calls based on seats. Did you ever sell a concurrent call license without knowing how many seats they have? Of course clients don't care about all of that. They look at their bill and compare it to other options in the market. From our experience, most customers look at the big hosting providers for comparison. IMHO resellers do best with an understandable month-based post-paid license model that can be used as part of their invoice for service provided to clients — which can be compared to those big hosting companies. There is a tremendous opportunity for most resellers because they can actually compete well with that.

Hmm it should not strip that. I would turn logging on to level 9 (TRUNK) and see what it processes. The problem might be that the "simple" patterns have problems with matching star codes and you might have to revert to extended regular expressions?

Simultaneous call licenses are indeed a thing of the past. I would say we were flirting with the model a few years ago, but the main problem remains that is is hard to predict how many calls you need. It might have made sense if there was a PSTN gateway with a hard limit on the number of calls you can do, but in the context of SIP trunks and abundant bandwidth this has changed fundamentally. If you are too low, you are loosing business which is ridiculous IMHO and if you are too high customers feel ripped off about paying for a license that is not needed 99.9 % of the time. Extension or seat-based-models are much easier to understand and practically the whole SaaS world follows that model today, including Email, CRM and ERP software solutions. Let the big companies explain the model, all we have to do is use the same model.

Ok will be fixed in the next build (currently 68.0.15.beta).

Outbound calls are assigned to one or zero ACD. It is kind of random, because the last ACD that agent logged into is the one that gets the calls. We have to make this better understandable, maybe even a select dropbox on the softphone to make it really clear.

The photo management is not very good, we will address this properly in the next major version.

Would it make sense to make any changes to the Grandstream template? Which one...

IMHO the easiest way to do that would be to set up a service flag. It might be a service flag specifically for that extension, but you can use access that in the redirection settings for the extension and allow the app only when the service flag is on.

Well that depends on the phone... We generally try to provide the caller-ID information in the SIP header already so that there is no need for a query. The LDAP query is mostly for getting the photo of the caller, but the VoIP support is very weak.

Well according to the RFC it is okay if one direction sends a different codec than the other direction, though some service providers have a problem with it—and some devices. Seems like the DP752 cannot handle sending PCMA and receiving PCMA? I agree for the sake of better interoperability the app should prefer the codec that was also preferred by the other side of the call. We'll include that in the next build.