IPO SIP Trunking

The 4 troubleshooting and maintenance procedures.

In this post, ‘IPO SIP Trunking’ you will learn 4 troubleshooting and maintenance procedures when dealing with SIP Trunk. These 4 techniques helped me successfully fixed issues related to hardware implemented between the ITSP and the Avaya IP Office phone system, analyzing trunk activity and much more.

A couple of weeks ago I was helping a client to troubleshoot a SIP trunk. They were experiencing dropped-calls after the call was already in-progress. I personally installed this solution two years ago, and they never had experienced this issue until then. Utilizing the 9600s endpoints, Avaya 3500s Switches, on a multi-location deployment using the Avaya IP Office as the Call Server.

This is where I decided to write this post, to share my findings, and to add some best practices when troubleshooting SIP Trunking.

Keys to troubleshoot IPO SIP Trunking

• 1.- Inventory
• 2.- Preliminary test and tools
• 3.- Collaborate with teammates before escalating it
• 4.- Advanced troubleshooting techniques

1.- Inventory

List the equipment responsible of connecting, and providing SIP Trunk Services.

Which equipment should I look for?

In a normal SIP Trunk setup there are a couple of components that you should be interest in looking for.

ITSP Router (Integrated Access Device or IAD Router) this device is normally installed as an Edge Router connecting the outside world also known as the Cloud and the CPE (Customer-Premises-Equipment). It allows for Data and Voice transmission in a single trunk or pipe.

Firewall/VPN/Router Appliance – The customer has a Firewall/VPN/Router installed between the Service Provider and their Network topology.

Network Switch – In some cases the I-PBX or IP Office is connected to the customer’s LAN via a Network Switch.

IP Office – Visit the knowledge-base IP Office website, to look for known issues and caveats related to SIP Trunk issues. See if they have fixed related problems in newer IP Office versions.

In my case the IPO was in production for two straight years without issues. Letting me to believe that the IPO version loaded in the CU was good.

2.- Preliminary test and tools

When testing you have to follow a pattern and document your findings as you go checking each steps. I suggest developing a step by step checklist and share it with your site contact, and anybody responsible of each solution.

Connections – As a good rule of thumb, always start by tracing the connections coming out of the ITSP (Internet Telephony Service Provider), and work your way through back to the I-PBX or IP Office.

I-PBX – Start by testing TCP/IP connectivity between the IP Office and its Default Gateway, most likely this device is the Firewall/VPN/Router sitting before the Edge-Router or IAD. Here you are looking for very long TTL delays and timeouts.

Firewall/VPN/Router – Perform the same ping test from this device out to the IPO.

Network Switch – Duplex Settings and Port Speed – If these settings were change or manipulated by the IT Admin, it might cause data transmission issues. These network port setting should be configured the same across the board.

ITSP Router – Visit their website or call their NOC to see if there are known issues or outages in the area.

SSA (System Status Application) – Use this tool to status the IPO SIP Trunk. By tracing the calls you, can see whenever the SIP Channels are idle, or out-of-service. Also run a PING command from the SIP Trunk, out to the ITSP. it will determine if there are L2/L3 communication.

3.- Collaborate with teammates before escalating it

Avoid pointing fingers and blaming somebody else for existing issues. In my case I knew the problem wasn’t related to the IPO, but instead of passing the bucket, I took ownership of the issue and joined forces with the IT Admin team to help troubleshoot and find a solution.

After exhausting your resources, it is time to engage the ITSP and your next escalation point. I did contact my colleagues to review the configuration and settings. I needed some new fresh eyes to look over me. Unfortunately we couldn’t find nothing wrong.

4.- Advanced troubleshooting techniques

Before you start you need to work with other vendors to translate system logs and traces.

Firewall/VPN/Router – This device should be the first one in your list of troubleshooting procedures.

Access Rules and Port Forwarding – These two elements are crucial for a successful SIP implementation. Include port UPD-5060, 49152 through 65534 in the rules. Get these ranges from your ITSP. Also visit http://support.avaya.com, and review the white papers related to your specific implementation. 

Firmware version – In my case this customer had a Cisco RV320 VPN/Router running RV32X_FW_v1.1.1.06. This version is unstable when implementing IPO SIP Trunk, dropping the transmission 2 minutes into the conversation. To fix my issue, I ended replacing the VPN/Router with a different model.

Traces and Logs – Pull these from the VPN/Router and compare them to the IP Office Monitor traces. Here you are looking for dropped packets, denial events, and restricted policies, as well as 400 request messages.

To ALG or Not to ALG? – Application-Level Gateway

Turn this feature off

Provider must implement NAT. Must likely the IPO has a private IP Address assigned to the LAN or LAN2 interface.

Understand Full Cone NAT, and Open Internet.

Full Cone NAT – This enables public addresses (Provided by the ITSP) to be translated to private addresses through a single port. The IPO will utilize the ITSP Public traffic and translate it to the its LAN IP Address e.g 192.168.42.1

Open Internet – For most part this will be the setting that you will be using for the ITSP, whenever using the Private LAN IP Address in LAN1(2).

Send your own Caller ID.

Instead of sending the BTN you can send the user’s DID by configuring the SIP Line/SIP URI/Local URI, Contact, and Display Name. as well as configuring the User/SIP/SIP Name.

Question

When troubleshooting SIP on IP Office, which challenges do you frequently encounter?

Resources

SIP in a nutshell

IP Office Public SIP Trunks Overview and Specification