Vodia PBX

BTW we partner with companies that do CDR analysis. Instead of writing this on your own, you could just use what is already available. If you are interested send an email to sales.

Its a little bit older post, IMHO this should be stable in 68.0.10.

Yes the PBX does push, there is a setting for that in the messages web page. However this is not something that you can do in a few minutes. Developing a new VoIP app will take some time.

It would be great if you could try 68.0.11.beta if I remember correctly there was an issue with internal faxing.

Not sure how it works. Seems like you plug this into the audio jack?! Then it would detect on its own if someone is talking?

bi_recording2.wav

We discussed this internally again. The solution to have a simple flag to enable or disable star code processing in the dial plan does not solve the problem well. We'll add a setting where you can just list the star codes that the system should run through the dial plan. This should address the problem in a much better way. You can try this out in the 68.0.11.beta build (Debian64/CentOS64).

Maybe you can attache the log file here (log level 9 for trunk), then we should see how the PBX processes this.

The easiest might be to modify the dial plan on the snom phone itself, like described in https://service.snom.com/display/wiki/<dialplan>+tag

Oh I think I forgot something important. When there is no local match for a valid PBX star code, it would forward that to the dial plan anyway. So there would be no need to suppress the star codes in the dial plan. If the simple pattern match does not work, just use a ERE pattern, e.g. (\*[0-9]+)@.* which should so the job as well.

58 is a very old version and I would generally recommend to stick to a newer version, especially when there are such fundamental problems. That being said I doubt that the version is the problem. I would enable a PCAP on the trunk and then just look at when the traffic between the trunk and the PBX is looking like (PCAP is a feature that is not available in 58). Usually there is something that needs to be done on the firewall.

For inbound, the PBX needs the setting for the number presentation only when there are ambiguous interpretations. For example 6173998147 means in NANPA +16173998147 while in a European context it could mean +49306173998147. The question which trunk the PBX will associate with the call is described in https://doc.vodia.com/docs/trunk-inbound-routing. For outbound, the PBX generally comes up with a CNAM and the ANI for the call. You will see the various presentations in the log when you set the log level to 9 for trunks. All you have to do is to pick the right variable and then put it into the header with a {xxx} pattern. The variables are generated based on the number presentation settings for the trunk. See https://doc.vodia.com/docs/trunk-custom-headers for the headers. We have had cases where a trunk provider needs different formats, e.g. the request-URI needs a different presentation format than the To-header. Such cases need to be handles in JavaScript, which is a separate topic. Of course if the trunk provider is on the drop down list, all of that stuff is already done for you.

Of course the same provider can service multiple countries and most actually do. However they will represent the numbers hopefully in the same format, ideally something that starts with a + to make it abundantly clear. Is the problem in the inbound call or the outbound call?

There must be something else. We tested deleting the trunk itself and also deleting the whole tenant and it all looked alright. If the XML still exists, then the trunk were really not deleted. Maybe there is a permission problem, e.g. the tenant administrator does not have the permission?

We have recently a flag "Process star codes" that will pass star codes to the dial plan. There you can use the regular rules to match star codes. However that means that all star codes are matches. If you don't want that, you could just use a special prefix like 88821 to have the same effect.

1. Yes that should be possible though we have not tried that. However obviously you need to make sure that there are no conflicts with ports, e.g. HTTP and HTTPS ports. 2. I would turn on logging for the IP address of anynode and see what packets are going back and forth. E.g. if you are running them both on the same server, would you use 127.0.0.1 or would you use the public IP? 3. You will need one certificate in anynode independent from the Vodia PBX installation. In Vodia, you should install a certificate as well, especially if you want to use the apps. 4. Hmm, in theory yes you should be able to use the same certificate because they point to the same DNS address. However practically speaking it should be easier to just use LetsEncrypt certificates for the PBX, especially if the DNS name for the PBX itself is different than the name for the SBC. On the other hand, if you issue a certificate for the whole server and include the name needed for anynode and for the PBX (and possibly separate names for tenants) as alias names, you should be able to use that certificate for both anynode and the PBX.

Well, this is not a trivial task. You can start by putting your URL there and watch the content that is being pushed to that server. In order to get the push working, you will first have to register to an extension using the web socket command that you can see in the log files. You can double check if you have the registration by looking into the fcmregs directory. You can actually get started by adding a table entry manually, just use the Vodia App to create an entry and then edit the token in the XML (this will require a restart of the PBX so that the change is loaded into memory).

The trunk has somewhat its own life when it comes to the number presentation in the tenant. It is mostly about presenting numbers when generating outbound calls, however also for inbound calls the trunk needs to understand where to send an inbound call. For example a tenant located in the USA might have a trunk in Mexico where numbers must be presented in the local format and not in NANPA format. Because of this, the trunk has its own country code and number presentation settings.

Every MAC has its own password, a device password which is generated by the PBX. This is like a "mini certificate". It is independent from the users password. For example, when the user decides to change the web password, it does not affect the VoIP phone registration.

The user frontend now checks if there is a permission to use the (mobile) app. With that one improved it did uncover a problem with the defaults for the app permission which was not in that REST API call. We'll fix that in the next build. Workaround for now is to set up a group that has the app permission and the extension as a member. You can use * to indicate all extensions are members.

The thing about the try button is that it ignores the times. That is why the try button is at this point just hard coded to use the daily statistics. In order to find out what pattern works for you the only thing is to wait and see. What you can also do so that you don't have to wait for Monday is to use e.g. 0:00/wed 0:00/day if it is currently Tuesday. Then you should receive the weekly report on Wednesday which should be just a few hours away.

The trunk has a setting for the Privacy header. Usually you put there a id when the call is supposed to be anonymous. Many SIP trunk providers recognize this and then do their part of hiding the caller-ID.

First of all, you could use a ACD and then send the calls to the agent which would solve a couple of problems e.g. with call waiting. But the main problem is that we currently don't really have anything that properly handles DTMF input from the agent. You could build something about the DTMF history in the call leg which will be part of the CDR and then use that to dig out the agent confirmation. Or ask the agent to put the call on hold (with ##) and then redirect the call into a IVR that plays a confirmation and triggers the action URL.

Try 0:00/week 0:00/day so that the week matches first. Alternatively you need to specify two distinct times so that the system generates the reports at two different times, e.g. 0:00/day 0:30/week.

The problem is that the RPS server does return server name in use, but there is no way to find the server. At least we did not figure out how to find it... IMHO the API should be updated to resolve this. The other way to get this working is to remove the server from the RPS web interface and sync the phone again.