Two and a half years ago Cisco came out with Call Manager version 5. There were a few notable changes in this release. Besides running on linux, it was the first version that supported both SIP phones and SIP trunks. As fortune would have it, one of our customers at the time had more prescience than I, and had researched the cost savings capabilities of using a SIP trunk for PRI replacement. Since I have never shied away from deploying the latest Cisco voice technology, we agreed to put the system in place.
The cost savings of the SIP trunk is what funded a majority of the deployment. 
Since the customer had a main site in Atlanta with 3 PRI’s, servers in a local colocation facility, and 9 remote sites, each with its own PRI, there were 12 PRI’s that could be eliminated. By putting in an MPLS WAN at the same time, ten internet T1′s could be turned down as well, which was a wash as far as pricing went. The SIP trunk plan included all long-distance as well, which was a further cost savings. An important point is that the local numbers on each of the 12 PRI’s were ported over to the SIP trunk, so no phone numbers had to be changed.
The cost savings of 12 PRI’s is about 12 x $600/month, or $7200/month. The SIP trunk cost about $3000/month at the time, so that left $4200/month for financing equipment and installation. Furthermore, the customer received the other standard benefits of a Unified Communications system, including a single point of system management, 4 digit dialing between all sites, and managing the voice system like any other application running on a server.
Things were rolling along great on the deployment. The SIP trunk was working for inbound and outbound voice calls, the SIP loads on the handsets were doing well, all the Quality of Service was set up properly so voice quality was good. We were going through the SIP trunk signoff checklist when we got to the line about DTMF tones. Although it seems minor not to be able to use the keypad during a call, this turned out to be the starting point of a very educational process for me.
It turns out that although SIP is a standard, at that time not every piece of network gear implemented all parts of the standard. The SIP trunk provider sent and received DTMF tones inband. The Cisco call manager and voice gateway sent and received DTMF tones as inband INFO, or what is known as RFC 2833. The provider and Cisco were both compliant with the SIP specification, but each with different parts of it!
Nowadays all SIP trunk providers are RFC 2833 compliant, but it was a major issue then. The only way to solve it and get the system into production was to turn up two Asterisk servers, and use them to perform the conversion, but that is a whole nother story.
The next issue I ran into was faxing. Now, faxing over VoIP networks has always been something that has to be dealt with in a methodical fashion, and we got the majority of the faxing worked out properly. The issue came with turning up the Fax over IP server. We use the market leading Xmedius product, and it is great because it takes a direct T.38 feed, and can be set up with either H.323 or SIP. Usually we take the PRI into the voice gateway, convert it to T.38, and send it to the fax server, and everything works great. Unfortunately the SIP trunk provider did not send faxes as T.38.
Just like the DTMF tones were sent as noise in the RTP stream, the faxes were sent as noise in the RTP stream as well. After a bit of thought, I ended up terminating the fax calls on a Cisco IPIP gateway (now known as CUBE), sending them out a PRI port as inband fax, looping that back into the same router, and converting them from PRI to T.38 fax. After that the faxing worked fairly well.
All the calls were coming in from the SIP trunk provider as G.711. For the remote sites we transcoded those to G.729 to save bandwidth. That was planned for and it worked well. Later on the customer bought more bandwidth and had all the calls running as G.711 since they liked that level of voice quality better.
After a week or two of the system running in production, we started to get some complaints about calls to outside IVR systems. Instead of calling in and receiving a menu, the call would just ring and ring. It was puzzling and took quite a bit of troubleshooting through SIP logs to determine the issue, and the solution.
Basically, these IVR’s required the call to be connected on our side before they would answer the call. My understanding is still somewhat incomplete, but the answer was that SIP early media was required on all outgoing calls.
SIP early media was generated at the Cisco Call Manager by checking the MTP required check box of the SIP trunk, which at that time defined the codec as G.711 and connected the call. That required provisioning of multiple MTP resources. The Call Manager could only have 24 MTP resources, so I had to define software MTP’s on the voice gateways. In this deployment defining two voice gateways at the colocation facility with MTP’s worked out just fine. It turns out that every SIP deployment has the same requirements for early media, so now I just cut to the chase and define the MTP’s properly up front.
After working through the DTMF, T.38, codec, and early media issues with MTP’s, all that remained was the basics of any good voice deployment, which is a high level of attention to detail, proper end-user training, and immediate followup with any perceived end-user issue. End-users don’t care about the technical issues, of course. They just want it to work.
In subsequent deployments at other customers, where the SIP trunk is being provided over the MPLS WAN, the precise definition of Call Manager Media Resource Groups and Lists, with the careful ordering of MTP’s on remote voice gateways, is absolutely essential to good voice quality and proper bandwidth utilization. MTP’s are tricky to do correctly, but they are an essential part of a multisite SIP deployment and have to be handled properly. MTP issues often appear to be QoS issues, which makes them even more difficult to solve.
Cisco is now on Call Manager version 7. We are finishing up a 20 site SIP deployment at a local customer, and everything is humming along fine. They are saving lots of money on phone bills, have a shiny new phone system and network in place, and are experiencing a high level of both reliability and voice quality.
SIP trunking is definitely a big deal, and it can certainly save an organization a lot of money. There are definitely many details that need to be addressed in any multi-site SIP deployment to ensure success, and anyone that says otherwise does not have the depth of experience to conduct one properly.
____________________________________
Author: Rolf Versluis
Adcap Network Systems – Atlanta and Miami
Great Local Engineers Creating Systems that Work!
Posted at Adcap Tech Tips
No related posts.
Last Updated: November 18th, 2011 |
