Internet Telephony Service Providers (ITSPs) don't have or even pretend to have every possible configuration for every PBX manufacturer or a running updated configuration. This presents two issues: First, the certified PBX initial configuration is never static because the software will change, possibly impacting the SIP trunks. Second, not every installation is the same, and boiler-plating the configuration is a great concept, but it's still not practical.
For example, since 2007 after implementing SIP trunks, we've noted several discrepancies between the premises equipment and the provider. The registration re-sending interval is a timer set to a value in seconds, and in one particular case, it was set for 300 seconds (or 5 minutes). This means that whenever the SIP trunks, DNS or Internet WAN links fail or go offline for maintenance, the SIP trunks would remain in an out-of-service condition for exactly 5 minutes.
Tracking the failures using the maintenance log revealed that most (~99%) of the failures occurred between midnight and 5 am. In every case, the SIP trunks were down for 5 minutes. Changing the registration re-sending interval to 30 seconds decreased the downtime of the trunks to approximately 1 minute.
This setting for this platform doesn't mean that all solutions should use 30-second settings for registration re-sending, because each solution is different. What it does mean is that trial and error may prevail for the given software release at the premises and provider ends.
Another anomaly is the failure of failover service. When the ITSP does not receive answer back from the on-premises solution, when will the ITSP fail the call over to an alternative route or service such as POTS? The issue emerges as a result of new complaints of callers describing "high-and-dry" calls, meaning they dial a number and it never rings, or if it does ring, it may take 15-20 seconds of silence before hearing ring-back tone. This amount of time is an eternity for most callers, and they will simply hang up.
Then when the primary WAN link fails and a secondary WAN link starts receiving traffic such as outbound or inbound VoIP calls, there may be a delay ranging from seconds to one or two minutes. During this time, if the probes on the firewall or router have not established new connectivity for the secondary (failover WAN) port, new offered calls both inbound and outbound may experience high-and-dry conditions. Again, the probes and how they are set up in each case are all customizable settings that vary from installation to installation. There is no universal setting, and this usually means that "fine tuning" is required along with copious notes taken during testing.
These are just a few examples of communications failures in the process, and you can help avoid them by setting up expectations that every install is not the same. Also, plan to test and re-test over and over, and make adjustments to obtain the best configuration for your particular installation.
Remember that the factory, manual and provider seldom agree on all settings for the SIP trunk profiles and related hardware, so for those that install them to think that they will all concur is the first and common critical mistake in moving ahead. The best practice is to establish service using test trunks during a trial period after you have gathered your initial documentation.
Follow Matt Brunk on Twitter and Google+!
@telecomworx
Matt Brunk on Google+
