Vodia PBX

I tried to set the SMTP server to 127.0.0.1, send a test message, and got a timeout... Maybe the problem is gone in 5.5.4

Well, that should work... Are you sure there is no error in the JavaScript console? Looks to me like we touched something in Safari that it not supported there. Otherwise we have to look into this next week.

What you can do it so make a Wireshark trace of the call and verify it is not a problem with SIP. Maybe there is one-way audio and the PBX disconnects the media because of that. Regarding the file system, the PBX opens the file, writes something to it, closes it, waits then opens again, append, and close again. If you are using NFS, it will be a problem.

With or without a mail serer actually running there?!

Approved... We have requested an upgrade of the forum software, we are using the hosted edition ... Password changes should work now. We still have a lot of posts from the well-known SPAM countries. Record was 60000 new users in a few hours, phew. I did not know we are so popular! So the problem is with the SNMP server still? Latest version?

What version are we talking about? Anything in the JavaScript console?

That is 90 seconds. It could be that this is the chunk size for the WAV file cache, which might not get flushed properly. You should make sure that the file system does not touch the file while it is being recorded. And there is a 4.5.1 version available, maybe you at least try upgrade to that one. You should also check if the SIP looks file. Maybe you get a media timeout problem after 90 seconds, which has nothing to do with the mailbox recording itself.

There is nothing you can really do here. If the record does not show an agent, then that information is simply not there. Of course the question is: why? There are some unusual cases like the call gets picked up from someone who is not an agent of the group. Are there any agents at all on your list? Maybe you can see a "pattern" when there are agents and when there are not, and then work from there to make sure that the agents are properly listed for each call.

The keys are different between V4 and V5. You cannot use a V4 key on a V5 executable, it will simply not work. We recommend that you upgrade to V5, not only for move to a newer OS, but there are also tons of fixes, including the acceptance of SHA-2 certificates which were not common back in the V4 days (now they are mandatory). Windows XP was also a great OS in the old days, but is outdated these days.

1) That is not necessary actually a bad idea if you have a country code set. The job of the country code is to transform those numbers into exactly the same (string-comparable) format at least internally. If you don't have a country code set, well then you need to do that. 2) On the server side the list is not limited. What is the exact file you looking at? I see some 1000 limitation in the recording files; where that number could be changed in the template. Down the road the proper way to have those long lists is to have a better REST API for those records, so that the records are downloaded in a pages fashion. The goal for the next generation is to make every list paged, so that you can have millions of numbers everywhere. For V5, well there are limits of what we can do.

Yea this is all handcrafted JavaScript, not even using jQuery... We can make the links bold, at least. Export as CSV well the workaround is to take a look at the network traffic in the browser, from there you can copy & paste the list. The next new web interface will do things differently.

The other common problem is how numbers are exactly written. To the human, +1-617-399-8147 may be the same like 6173998147 or 16173998147 but it is not for a string comparison. The country code in the domain is supposed to transform those numbers into the same string, make sure that it is set. Also sometimes the display portion of the SIP From-field contains the number, but the user part does not. The blacklisting happens based on the user-part in the URI.

You might have a problem with a prefix, e.g. 8 is usually a prefix for the mailbox of an account.

What you can generally do (not only with the PBX web sites) is to switch your browser in the debugger mode and watch what traffic is going back and forth with the PBX. Then you can easily spot the REST requests and their answers, usually nicely parsed for you to see the content right there. That will help to understand what is happening "under the hood" with the PBX, and it will also make easier to understand how we can make changes that will serve your needs. You can also script REST requests, e.g. with curl.

Should be working now...

We will update the server tonight to a newer version that should support the 745.

I think that this is a web presentation issue. Because the PBX has to somehow limit the amount of information it presents on the web page, it shows the first 1000 blacklisted numbers. If you grep in the address book directory, I think you should be able to verify that the records are in the system.

The page is not rendered on the server side, it is build up on the client (HTML5). It would be a possibility to parse the URL in the client as well and then load the page that was requested, skipping the loading of the first page.

Currently it is coded in the dom_calllog.htm page: var count = json_ajax({ "action": "count-cdr-summary", "start": 0, "length": 1000, "domain": true }); You could edit the template and set it to another value. However it will obviously take its toll on the CPU, you need to be aware about that.

That would make it impossible to cache the site. an alternative would be the form ...htm?page=123 but like with most modern web pages REST is the way to go, where all that stuff happens behind the curtains.

Yes you can delete them. They are generated when the PBX cleans up calls after 8 hours with some hints what could have gone wrong, similar to a "Dr. Watson" report, but without shutting the system down

There are obviously limits with what you can do with the PBX itself. If there are many recordings, you might want to use an external solution like http://call-recording.tmcnet.com/news/2016/05/19/8366620.htm

Yes, yes. I have opened a ticket on this.

Sorry, trying to understand where this thread was going. Can anybody tell me what CUE is (even if this might be a stupid question)? If there is no voicemail on the extension this is not the end of the world, the PBX will then apply the rules when the extension is not available.

Redirections are only affecting direct calls to the extension. But what you can do is use a service flag to control the redirection in the hunt group. What might also be interesting is the "mini hunt group" that comes with the extension. It is called "Include following extensions when this extension is being called". There is no delay calling the other extensions, but redirection will work.