Over the past several months, I’ve spent an insane amount of time working with my business’s NEC vendor and our Cisco vendor to implement a SIP integration between a Cisco CallManager Express install and our existing NEC IPK II PBX phone system. Eventually, this post will become a full step-by-step, but for now I’ll start with a list of the major problems and quick solutions:

1. Make sure your NEC system has a slot with enough power for the SIP card, otherwise, you can configure it all you want, but it will never be able to establish a call. Total time spent by our vendor on this: 1.5 months. Reason: We actually had multiple hardware failures on the NEC side during this diagnostic, so we spent more time fixing those than dealing with the SIP integration.
2. Don’t let your vendor convince you that “station side” implementation is either necessary or recommended. In fact, SIP Trunking is definitely recommended unless you need more than 24 trunk ports between the two systems. Total time spent on this debate: 2 weeks. Reason: Your NEC SIP licenses are essentially “per connection”. If you’re like me, you plan to grow your Cisco solution but won’t have more than 24 concurrent connections between the two. This way is cheaper and keeps you less dependent on the NEC system. The reason station side is recommended by NEC is that it supposedly allows more functionality and control on the NEC side which probably isn’t all the desirable, and really I haven’t seen any evidence of it being true.
3. DTMF (touch tone) support isn’t going to work with the default settings on either system. In order to make it work, on your NEC system you have to go to 84-13 in System Data to enable DTMF Relay Mode as RFC2833. On the Cisco system, you need to enable dtmf-relay rtp-nte for each dial-peer (except your Cisco voicemail/auto-attendants which should be sip-notify) along with nte-end-digit-delay 50 for each ephone device connected. Total time spent determining this fix: 3 weeks, and I finally figured it out since our NEC vendor washed their hands of it and the Cisco vendor was convinced the config was right with just the rtp-nte. Actually, it really is a problem on the NEC side, because IPK II doesn’t allow the beginning and end packets to be sent/received at the same time per the RFC2833 spec. the nte-end-digit-delay setting basically provides a work-around to tell the Cisco system to slow down the tone packets so that the NEC system can get a clue what to do.
4. Caller ID is still a problem for us… Cisco to Cisco and Cisco to NEC is perfect, but the NEC system doesn’t seem to pass the proper Caller ID information back to the Cisco system. I’m still working on finding a solution, but I’m on my own, because our NEC vendor insists that it’s not possible, just like they insisted DTMF was never going to work. Update: I finally discovered that the issue is how NEC is sending the ID string during call initiation. While the standard is “Display Name”[Extension@SIP_IP_ADDRESS], NEC insists on using “Extension”[PrimaryNumber@SIP_IP_ADDRESS] which is not standard practice. I’m still looking for a fix for this.
5. Make sure you have decent vendors on both sides. There’s going to be a lot of blame to pass around when things don’t work. Don’t make it worse by allowing either vendor to be incompetent about the process. Work with them both directly, and make both work together to get it working! Hopefully my advice here will make someone else’s life a whole lot easier!

All that said, moving away from the NEC PBX solution to a full-blown Cisco VoIP solution is highly recommended, and much more cost effective in the long run. You may pay more up-front for the Cisco implementation, but the support costs are drastically reduced and support efforts significantly reduced… not to mention the total boost in functionality and expandability by comparison.

This entry was posted on Wednesday, November 18th, 2009 at 11:07 PM and is filed under Tech News.