Testing IP-Flex with Avaya Core Systems

The 5 key elements to help you find and fix trunk issues

Testing IP-Flex with Avaya Core Systems by Wellington Paez

Testing IP-Flex with Avaya Core Systems

The 5 key elements to help you find and fix trunk issues

In this post “Integrating IP-Flex with Avaya Core Systems” learn the 5 key elements to identify early issues to avoid implementation mishaps, delays due to system misconfigurations, and lack of urgency to test each solution prior to deployment can cause long hours of implementation during the T1 Cut.

As I help customers with their converged Carrier Services (Internet/Line Service Provider) especially those using SIP technologies converted to ISDN-PRI T1s, I can’t help find misconfigurations sometimes in our systems, and at times at the Service Provider’s equipment.

While I was troubleshooting this particular IP-Flex trunk I found the Service Provider was using different rules to allow and disallow traffic from the Voice network, causing the RTP stream flow one way but not the other. For us it was very aggravating as we had to change parts thinking the trouble existed in our system.

Here, we go over the 5 key elements when troubleshooting IP-Flex trunking=

  • 1.- Understand the technology
  • 2.- Learn Customer needs
  • 3.- Checking the Hardware
  • 4.- Verify system configuration
  • 5.- Before going live

1.- Understand the technology

IP-Flex is a SIP-Based technology that helps keep your legacy DS1s without the need of licensing and implementing new hardware to accommodate SIP trunks. This is ideal for those small/Medium businesses without the budget to forklift their existing legacy systems.

Besides Voice these services come packaged with Data Services making it attractive to customers. Providing high speed Internet.

2.- Learn Customer needs

IP-Flex allows the use of Long Distance, Conferencing, among other features with a minimum cost. Because these calls are riding on Packet-Switched networks it gives the customer more flexibility when it comes to choosing the different subscription plans and features. Some of these features include: DID ranges for a minimum cost, LD calling, etc.

3.- Checking the Hardware

Service Provider’s equipment – The Service Provider installs the Network Device responsible for delivering the IP-Flex into the customer’s premises. A T1 Crossover is needed to swap the TX/RX unless there is an external CSU interfacing between the Avaya system and the Service Provider’s equipment (Router).

Exiting Avaya Voice Solution – The legacy Avaya system will remain the same, as you don’t need to purchase any hardware or licensing when connecting to the IP-Flex Router.

IP-Flex vs NIU / T1 Smart-Jack – A lot of the conventional T1s normally get their power from the Central Office allowing these circuits to stay up online even when power is lost in the customer’s premises. For IP-Flex there have to be a battery backup available in case of any power interruption.

4.- Verify system configuration

As far as testing, you need to ensure the clock synchronization and timing is coming from the Service Provider’s equipment. Remember the Avaya Systems are incapable of performing such tasks.

For those having issues with QoS, One-Way-Audio, etc, most likely it will be coming from the Router itself or WAN connectivity. We are very limited when it comes to troubleshooting these type of symptoms, unless the DS1 is taking slips and missed frames which are attributed to a clocking/timing sources.

Keeping the legacy hardware up-to-date. If implementing IP-Flex it might be a good idea to install the latest Firmware available. And as far of the rest of the DS1 Configuration the protocols, Framing, and Line Coding should remain the same. It is worth noting that in most cases NI2 it is used as the Line Protocol of choice, with B8ZS as the coding type, and Extended SuperFrame as the Framing type.

5.- Before going live

As a good practice schedule a call a week prior, to test the solution with the Service Provider. Normally they don’t like to leave their circuits active if these are not connected, as they will generate alarms. A good idea is to test after business hours to simulate real calls, and confirm that all the B-Channels come in service.

 

Question

Are you testing the new trunks before implementing them?

Please note: I reserve the right to delete comments that are offensive or off-topic.