SIP Diversion Field – Avaya SBC – 603 Decline

4 steps to correct and update your SBC server to allow calls through

By the end of this post, “SIP Diversion Field – Avaya SBC – 603 Decline”, you get to understand why a particular number is rejected from the Service Provider or ITSP with a 603 Decline response when they have screened implement.

Learn what to do to avoid or fix these type of errors by following these four steps listed below.

As I was helping a client fix uncompleted calls when made from a branch location to a particular number that worked from the Main site, I noticed the ITSP was receiving the wrong information in the SIP Header, especially the Diversion field, causing the calls to be rejected. In this post, I explain how to fix and help you avoid similar problems.

• 1.- Identify and Document
• 2.- Configure a temp solution
• 3.- Trace and escalate
• 4.- Correct and test
• 1.- Identify and Document

1.- Identify and Document

Identify – Never overcomplicate your troubleshooting methodology when working with SIP or any other type of trunking. Always start by recording the numbers dialed from the person complaining, then work your way back to the demarcation point.

To start, identify which elements are responsible for handling the call routing. In my case, I had a user dialing a particular number from the Branch location through the main location’s SBC. The SBC was out-pulsing the Branch’s main number instead of the Main-Location’s number, configured in the ITSP or Service Provider’s system, causing the call to disconnect.

Why do the ITSP Block certain calls? – Some Service Provider use the Diversion Header Screened feature to help them see a bogus number in the From, PAI or in this case in the Diversion field, it automatically thinks that someone is trying to commit toll fraud or forking.

EC500, Mobile-Twinned, and Forwarded calls are also blocked when calls are presented with a different BTN (Billing Telephone Number) in the same fields listed above. This happens when the ITSP removes the first number, but fails to remove the second number from the Diversion field.

Document – When using multiple route patterns (Avaya Aura), or ARS Entries (IP Office), you should be able to create a single route for the number in question, to help you see where the number is failing. The trace below shows it=

Diversion: <sip:3015551212@voip.net>;reason=“unknown”

The ITSP does not know what is 301-555-1212. As a quick fix=

First – You can create a new ARS Entry for that particular location= 301-555-1212 digits= 11 type= PubUnk

Second – Modify Route Pattern= 100

Third – Fill the NPA field with a bogus number. I used 200 instead of 301. This allows the Diversion Header to be presented as=

Diversion: <sip:3015551211@voip.net>

The above number is the number presented whenever calls are made from the Main site. The ITSP owns this number; therefore calls are allowed. The Public-Unknown flags the call as “anonymous” instead of inserting the Branch’s location BTN of 301-555-1212. This allows the call to complete when presented to the ITSP. You can confirm this by running a TraceSBC. It should display=

T:3015551211 F: anonymous@anonymous U: 3015551211

2.- Configure a temp solution

As already mentioned, create a temporary ARS-ANA or ARS Entry related to the affected location. Flag the call as PUB-UKN, then populate a Route Pattern with the SIP Trunk, and a bogus NPA.

3.- Trace and escalate

Trace using one of the following methods=

• Communications Manager – Run a list trace station, then a list trace tac.
• Session Manager and SBC – run a traceSM and traceSBC to capture both calls.
• IP Office SSA and SysMon – To capture the shortcodes and trunk SIP Trunk messages.

Escalate – If possible, have the service provider testing with you from the beginning to speed up your troubleshooting process. If you cannot, then open a trouble-ticket with them and schedule a conference call to further discuss.

4.- Correct and test

Under= SBC/Global Policies/Signaling Manipulation/Signaling Manipulation Scripts. The SIP Header was updated to remove the Diversion field by inserting the following line of code = remove(%HEADERS[“Diversion”][1];

One last thing before I let you go. tell me, what is the most common sip messages that you find yourself troubleshooting?