OK, it looks like you need to invest money in an actual pre-built solution. Siremis has nothing to do with the actual functioning of Kamailio. Zero. None. Nada. It just is a nice way to add stuff to the database for you and makes it more friendlier for you. Like when an option in the database is 1 but that really means udp, in Siremis the option just says "UDP".
This sounds like you just need turn-key solution.
Matthew,
Thanks for taking the time to share your experience with this process. I kind of expected something along those lines if we migrated now, but we weren't sure about the ramifications of holding off and were trying to figure out what to do. I think that at this point we'll wait it out.
Oh really, like what?
VoIP.ms
This is fixed, the problem was I changed the time zone from UTC to my local time zone, and the DHCP lease would time out before it renewed, because it thought it wasn't time to renew due to the time zone change. Changing it back to UTC fixed the issue.
I highly recommend AWS EC2 for FreePBX as there have been no other issues.
Well now we're getting into a realm of research which I can't do for you because I do not know many of the factors that would determine if a solution is right for you or not. It just seems that part of the criteria for this solution has to account for doing most of the logic for you. Basically plug and play, for a lack of a better term.
It sounds like you guys are following more of a Tier IV model, which is basically deploying and selling pre-designed solutions, either by the platform or by the vendor. Mainly meaning, your services are limited to and subject to the limitations of the solution you've deployed. Like FreePBX.
I follow a more Tier II/III model which is I use vendors for their infrastructure and service delivery but I build all the products/services the end user receives. Sure I use FreePBX but it's just a piece of the overall solution and I've had to make it so FreePBX can work with all parts of the overall solution it needs to.
NOC System x 1
SMTP Relay Server x 1
Digital FAX Appliance x 1
Kamailio as Class 4 Switch x 2
MySQL Servers x 2 (Master/Slave failover)
Name Servers x 2 (Primary/Secondary)
Kamailio as Class 5 Switch x 2
--> XMPP Services
--> SMS Services
Core FreePBX Systems x 6 (FreePBX in all cases heavily modified and overridden using existing methods for such purposes)
That is everything in place just for the voice services, not counting straight up hosted PBX systems. "Core FreePBX" are because two of them act as "Media Gateways" providing voicemail services for Resi/SOHO service users and all calls do flow through them so I can have control of the media before sending it to the carriers. This is really a bandaid until budget permits a real SBC solution to be put in place so I can see handle media but not have to answer and open a new channel to do it.
The rest of the FreePBX systems act as "hosted voice" systems and thus are heavily modified in the sense a lot of the custom file options are used for adding SIP settings to extension configs, interjecting a wide range of custom dialplan contexts and using the extensions_override to make small tweaks to existing macros. I create custom "from-internal" style contexts for each "hosted" instance and set that for the context of those extensions. It mimics what from-internal does and just calls on dialplan contexts in the order I want them to be traversed. In some cases certain contexts are not accessible for a user but it allows me to include my custom contexts into the dialplan and hook into all the existing dialplan.
Wait, what about end users with the same extensions?!! That is why they have their own custom context to be called on. To the end user, they are registering to Kamailio which is based on user@domain so instead of an IP they are giving FQDNs so 110@domain1 is completely different than 110@domain2. What I assign as the "extension" number in FreePBX is arbitrary but I try to make it close as possible if there is conflict. Because they have their own custom context I can say 110 dials the 7110 peer which did require the dial macros to be adjusted to send a dial string format that includes FQDNs and modifies the TO/FROM headers properly.
Things like IVRs, Ring Groups, Queues, Conferences, etc those are all still managed normally by FreePBX just that my custom contexts for users just don't give full access to those contexts. I just jump to the proper ones needed from within their custom context.
One of the great things behind all this is that if a PBX providing hosted voice services does crap about, I can kick in a spare and the Kamailio servers will detect that quickly. Even if there isn't a ready spare of that particular instance, Kamailio will send the inbound calls to one of the media gateways that will route the calls to Class 5 Kamailio server where the devices are registered. Sure they enter a general ring group style or single extension destination but they are still getting calls and all devices can still make outbound calls because Kamailio will route them out a media gateway. And since it takes like under 10 minutes for a new instance to be spun up it's not a bad "OH CRAP" solution.
The real question is how serious are you about providing services? What is the "Standards Bar" to meet for your services? As you can see, I've spent a lot of time putting together an entire network to support and deliver services as high level as possible.
You think I messed up by following this tutorial somewhere and moving me to 13 prematurely?
Hi!
Right now there are like 3 (known) problems that can cause loss of network connectivity.
I don't think it's that easy in this case since this problem was reported early on by one of the early testers (ie @waldrondigital) over a month ago.
I was one of those early testers and had the loss of network connectivity problem but in my case early on it seemed to be related to my DAHDI card which, once it's drivers are loaded, appears like a network card.
(I could not say with certainty until very recently...)
Back when I ran the distro upgrade "script" there were other issues with those DAHDI drivers and the ones specific to my card (Wanpipe drivers for my Sangoma A200) and it looks like this might actually have helped in some ways because I think it might be once those DAHDI drivers got updated/moved out of the way that my system network connectivity was restored.
I still had a problem which was causing a slow but for me but lost of network connectivity for others which I thought I fixed this week but I had a weird problem today so I am not sure anymore.
Each time someone reports a network connectivity problem my first two questions are "Are you running a VM and do you have DAHDI hardware?" because, early on, this seemed to be what was tying those network connectivity problems together...
(It's actually me who referred @mattbratt to the post he referred you too like a day or two ago.. 
)
I believe the network connectivity test is actually in response to the network connectivity problems @waldrondigital and me had that this test was added to stop the upgrade as soon as the problem was noticed...
I have not played with VMs in quite a while but Iwould not be surprised it would a missing driver thing and that they might not be allowed to distribute the VMware one or something like that..
What I guess they could do is try to detect your network card is setup like this and tell you to change before allowing the script to run further.
As for IPv6, someone reported having IPv6 activated was causing him DNS issues and those tend to look like network connectivity problems even though it is something only name resolution problems...
Of those problems, as an early tester, I only had one but had quiiiiite a few others, most of which have been fixed...
Good luck and have a nice day!
Nick
Hi!
As I said here:
Only consider running it if you have a looooooooot of time on your hands which is something usually not possible in Production...
CDR, when lost during the upgrade, are usually caused by one of two things...
re:
re:
(and the message after it)...
I actually opened a ticket for it even though I did not have this specific problem, see FREEPBX-1581.
Unfortunately since I did not have that problem I cannot provide the logs @GameGamer43 is asking for in that ticket... If anyone encounters this problem please upload your logs to this ticket so he can track down the problem...
If you mentioned this problem on the forums and I did not suggest this (or if it did not work), I am sorry...
As for dependencies, this type of problem or something different?
By the way, I did remove those conflicts manually after...
The only one which needed special treatment was kmod-dahdi IIRC...
I did consider that once my system started working but I wanted to see if I could figure out how to fix all the issues I had and report them if it seemed like it was unlikely it was fixed...
Have a nice day!
I am pretty sure with User Management, you can give the office manager access to view call logs for other people's extension via UCP. You might be able to speed this up by granting the OM access to view a group, and then adding everyone she should see to that group. (I have not tried this)
Hi!
Chances are, if your system is relatively stock and
You might not have problems or have problems which are easy to fix and already have documented fixes...
Problem is you might not notice them immediately (like non-working CDR) and once you do it might be too late and you might have lost information you had to keep (like those CDR entries...).
One person had a non-working Fax Pro module and IIRC it was down for days until it was found his system was missing a package because the content of one package was split into two on the new distro upstream (It's Centos based)...
The Fax Pro module might be commercial I believe you kind of say your (official) commercial support goodbye until it is out of beta...
Hopefully he doesn't use much faxes anymore but still needed this to work...
You might also have the weirdest of problems we have not encountered before of don't have easy and documented fixes...
I ran the distro upgrade "script" on a system you could call "Production" but it's the system I use for my home phone...
If things don't work quite right there is an automatic failover of the most important phone line(s) to mobile phones and I can temporarily setup something (I did setup an ATA as a temporary solution) if things take too much time to resolve...
Even though it's the system which handles my home phone it's also a test system as well with multiple DIDs, VoIP providers, outbound routes, etc... Not exactly a company phone system but definitely more than an home phone system...
I made sure I had backups, time and was willing to have downtime if it turned out to be necessary but there were while for you acceptable downtime might be like 4 hours, mine was more than 4 days (of course after having setup that ATA...).
Good luck and have a nice day!
Nick
I can't help but think that an SBC might be a good fit here:
I have been trying for many hours now to get email working on a fresh install of freepbx hoping to easily get email to work. I have a licensed user on my account I am trying to use for authentication. I have tried over a 100 tweeks to the settings and checked the logs. I generally either get a bounced message, or an authentication error. I am using the admin module for email and choosing the office 365 option.
It seems like this should be easy but after about 10 hours of failing to get it to work, I am hoping someone can point me in the right direction.
Here is a recent smippit from my log files:
Sep 23 17:46:57 freepbx postfix/smtp[27710]: 6F80962ABF20: to=myusername@my365domain.com, relay=smtp.office365.com[40.97.121.34]:587, delay=7.7, delays=0.01/0/2.5/5.2, dsn=5.7.60, status=bounced (host smtp.office365.com[40.97.121.34] said: 550 5.7.60 SMTP; Client does not have permissions to send as this sender [BN6PR20MB1474.namprd20.prod.outlook.com] (in reply to end of DATA command))
Hi!
Considering who is behind SIPStation, they definitely deserve to be mentioned...
I personally don't use them however...
My main VoIP provider is VoIP.ms and I do use Flowroute for T.38 (fax).
I do use a few other providers but mainly as fallbacks to the others...
At one point I was using DIDLogic for outbound calling because their outbound rates are usually better than all the others but I barely do anymore because DTMF has always proved very unreliable with them regardless of setting...
While my main provider is still VoIP.ms if I could find something with similar rates and services I would switch...
Why?
There were multiples "incidents" earlier this year were credentials were obviously leaked and an even earlier incident which suggested they might have been aware of it...
In July many people reported having their credentials leaked and calls attempted with them in the preceding month or months, some of them successful, some not...
That was attempted on one of my own sub-accounts which, fortunately, didn't allow calls to the destination the hacker tried to call...
Now I understand it might be easy to "guess" the main account since it looks like it's simply a sequence but sub-accounts are the main account "number" + an alphanumeric suffix you choose...
Mine wasn't easily guessable and you have to pair it with the right account "number" plus password...
For others, it was actually hardly guessable...
By the way, there are multiple threads about this on DSLreports, none of which received an official answer from the VoIP.ms spokeperson(s) AFAIK..
IIRC, the ones whose hacks attempts were successful were not always fully reimbursed according to those threads even though the leak was more than likely on VoIP.ms' side..
I said there was an earlier "incident"...
Back in January of this year VoIP.ms decided to resets everyone list of allowed international countries...
We were not given a choice whether to have this done on our accounts or not...
We were not given the list of internal countries we allowed and which one we actually called and asked to reconfirm them...
We were not given advance warning..
No...
So they ran their one-shut and later sent us all an email telling us they had done this with the security of our accounts in mind... 
The criteria they had decided on was the international countries we had called in the last 3 months..
Now, I don't know about you but I allow calls to some destinations I might not call for well over 3 months so this too was unacceptable if done without any confirmation on our part...
There was also a big problem with the script...
VoIP.ms has short feature codes...
They had forgotten to remove feature codes from their "logic" to determine what countries we had called in the last 3 months...
They had also forgotten to make sure the phone number we had called was actually long enough to be an international call..
I don't believe that specific feature code still exist but in my case one of my calls to one of these feature codes had opened up calling for South Korea if I recall correctly...
They had removed every other international country from my personal list and added South Korea..
I guess it could have been worse and they could have allowed me to call their northern neighbours...
Now, if they had bothered, at least in tests, to compare the new list of allowed countries to the old one they would have immediately spotted the problem but they didn't...
This all seemed like something they had rushed to take care of a problem...
If there was indeed a "problem" we were never told about it...
Now what is preferable?
That this was simply poorly thought of and poorly realized or that this was rushed to address a "problem" they simply forgot to tell us about?
This too has a thread about it on DSLreports...
Definitely something to think about...
Good luck and have a nice day!
Nick
Hi!
maybe?
Good luck and have a nice day!
Nick
Why do I get this when trying to log into PBXact?
I assume it's something similar to FreePBX so I'm reaching out to anyone who can assist me with this. The system is only four months old. I don't feel I should have to pay for support when this system isn't that old. Furthermore, it only had a problem after an update.
I cannot seem to get my system working correctly. Can someone please help me with this?
Hi!
Dumb question but what are you expecting to see exactly?
This looks like part of the screen we get for the login prompt of FreePBX, is the problem is that you only see that?
Have you tried clearing your browser cache in case the problem is something as simple as that?
Good luck and have a nice day!
Nick
Poor SPF record that doesn't have the IP of the PBX in it. This is a DNS issue for your domain.
I seriously hope they provide a more concise error message for SPF / Sender-Id (MS variant IIRC...)
Most of what I found suggests "Send as" rights such as this:
By default the Postfix installed on the FreePBX distro tries to send emails from non-existent domains IIRC (which is a big no-no) so what @waldrondigital is suggesting, to remap all of those to real addresses, definitely makes sense...
Considering SPF is meant to be validated by the server receiving the email and what the OP appears to want to do with office 365 servers is relaying it would be a misuse of those records IMHO...
Nick
Some decent replies in here to get someone started. But I get a bit frustrated in that there is no comprehensive guide to setting up FreePBX with Office 365. Regardless if you see the option in the Commercial Admin module. Yes, it gets you closer to getting it to work, but you still have to beat FreePBX/Centos with a stick to get it to work.
I will post a "how to" in a moment. Stand by.