Of course the DSS/BLF on my phone glows red and it did three times since implementation meaning SIP trunk failures. The button on my phone shows all alarms in the IP-PBX. Why did only the SIP trunks fail?The failures on 4/16 and 4/25 could not be tracked because the events were too old according to the NOC. The next event on 5/2 @ 04:50 am was a maintenance issue of some sort. So the lesson here is don't wait to report any outage. I got to thinking about our UPS and our FIOS which has its own battery, so I paid some due diligence and tested it and surprisingly due to its age, found it to hold a charge and operating fine. The small battery pack is replaceable or we can simply disconnect the ribbon cable and feed the FIOS gear from our UPS. We also had severe thunderstorms on both dates in April but no other alarms except for the SIP trunk failures.
Our Verizon bill took a strange twist in that Verizon mailed a final bill even though we still have FIOS. They explained a new bill is being issued since there is no longer phone service and the main billed telephone number was the link to the account. Our Broadvox bill appears via email, which is cool and the details are more than adequate. We were billed for an 800 number that we didn't order or don't own, but the customer service folks were quick to fix that.
Call quality for 1,055 calls: MOS Excellent: 839 Good: 215 Fair: 1
I noted in a prior post that we are using SIP-to-Cell to transfer calls out to our iPhones. Depending upon time of day, usually 2-3 in the afternoons, I notice that latency kicks up a bit and voice becomes almost satellite quality. Still, audio is preserved, no premature disconnects and it's not a frequent occurrence.
The call trap that we setup in our ACD/Automated Attendant was the one small detail that really works well. We don't use auto attendant normally, only as a last resort when we don't answer calls in the office and in the field -it happens. The other thing that happens is the cell network gets jammed too. The time it takes to process a call to deliver ringback to the caller and to ring the cell station is sometimes delayed. Callers are not patient and they will wait 3 rings, maybe 4, but bail out after 5. The auto attendant captures the calls based upon time, not ring cycles. Time is better I think because it is a solid metric to use. Of the few calls that we "saved" or trapped--only one was a customer leaving a callback. The other calls were telemarketers that are on our annoying list.
We did not allocate more than 10% of available bandwidth for SIP trunk calls. I also mentioned the number of opportunities in the last post. I'm thinking that the provider that comes up with an a la carte menu of offerings may be wiser than those offering few services and applications. I've often said put intelligence in the network but I think today it means move intelligence to the network. Our ACD can be hosted in the cloud and this would make the connections to the iPhones even better. My buddy Eric posted two interesting blogs this week: Are You Nervous? and a SIP Trunking Adoption Poll. Clearly both are related and clearly many of you are holding out--note that I didn't say holding on. Not to misunderstand that I don't understand or appreciate that large enterprise folks have large issues, concerns and problems and do want to get everything right. Those "voice is just an application" claims appear to be pretty challenging after all.
