So, here is our story:
Our company started reselling a SIP trunk provider service, one that has been working well for our customers, and we finally committed ourselves to primarily use SIP trunks once our contract with Cox and our PRI service expired.
And we started experiencing weird problems.
We would be working just great, making and receiving calls, when suddenly! all our connections would drop, and the trunks would go down, sort of. We would receive multiple connections for the same call, but we couldn't answer them, and when we tried to dial out, we would get long pauses, before being told that the call could not be routed.
This condition would last for 10 minutes or so, and then the connection would restore automatically.
This was not a problem that our other customers had experienced.
We went to tech support. Tech support said that the SIP logs showed we were sending data out, but we were not getting a response back. The SIP provider said THEY were sending information to us, but not getting a response back.
Back and forth we went.
We thought it was our router.
Brought in outside help. They claimed it was the type of router we were using, which was a Fortigate. The guy said that Fortigate had some built in SIP trunking capabilities that would interfere with our use of SIP on the phone system.
Ultimately, we switched to a Microtik router.
Did NOT fix the problem either!
Head-Desk. Repeatedly.
Started the wheel over again, this time with a Mitel tech who was smarter than their average phone monkey over there.
Had us turn on Wire Shark captures at the switch port for the phone system, and had us turn on ADD and we would freeze the system when the next incident occurred.
And he caught the problem.
"Why do you have your IP connection Audio Stream Receive Port set to 5004? It needs to be 6004"
When the IP phones on the system initiated calls, the system would use an Audio Stream number, the next one that was available. The numbers would increment through the day, until we hit 5060.
5060
Which is the same port number as SIP trunking.
So, when the phone system started seeing Audio Stream data coming in on the SIP port, it was deciding it was "under attack", and would shut down communication on that port for about 10 minutes, until the condition was clear again.
So, why was the Audio Stream value set to 5004?
Because:
Before we were using the 5000 system, we were using an Axxess system in our office.
And, years ago, when we migrated, I simply used the upgrade tool to migrate the existing database from the Axxess to the 5000.
Some old timers here may recall that the Axxess used a default value for Audio Stream at ....(wait for it)
5004.
When we did the upgrade, that value migrated over with rest of the data. And we never noticed it-
until we started using SIP trunks.
The older 5000 software version also used this default value, but later on, changed the value to 6004. Why? Because they didn't want to interfere with SIP traffic.
And this is why our other customers (all newer customers) did not experience what we were dealing with.
So, the lesson for today is:
If you are working on a 5000, and it's an older system (or an upgrade from Axxess), MAKE ABSOLUTELY SURE that the Audio port value starts at 6004, and NOT 5004.
Also be warned, if you have to change it on a live system, the system WILL reset, so be cautious when you do so.
I hope this cautionary tale helps others out there in the field.
