Learn 3 strategies to help you find ways and understand the 480 SIP Responses
By the end of this post “480 Temporarily Unavailable – No inbound/outbound calls.”, you have learned one of the probable causes to why some Service Providers reply with a “480 Temporarily Unavailable” to any incoming calls or with a “480 SIPS Not Allowed” for outbound calls. These messages can be found in CM/SM/SBC sip traces.
As you may know the Avaya Core of servers will always insist in keeping the SIP Session up until it receives a BYE / CANCEL or times out following the Session Max time.
My problem came as the Call Center Agents experienced a high volume of lost calls. But for some odd reason mainly the people calling into the office were affected the most.
As any troubleshooter I started by looking at measurements, trunk group capacity and finally licensing. All of which seemed to be okay.
These are the 3 strategies to help you understand issues related to “480 Temporarily Unavailable ”.
- Review and assess
- Collaborate
- Develop and apply fixes
Review and assess
Here you are evaluating each components participating in the SIP Flows. Some of these components are=
-
- Licensing = Depending in how the servers are routing these sessions, it is important to have an idea in how many are active based on components establishing these sessions and locations.
- Components = A defective server can cause load balancing issues where it can exceed the capacity of sessions permitted.
- Location= When having sessions distributed between locations it is another element to consider, where there should be enough licenses and available channels to allow the SIP Sessions.
Collaborate
In this stage you are collecting data such as call traces from those affected users. Analyzing them and reviewing from where the “480 Temporarily Unavailable /480 SIPS Not Allowed” is coming from.
The idea is to start in CM and move upstream troubleshooting through SM and finally the SBCE.
Once you have confirmed that your equipment is healthy and not exceeding its resources. It is time to engage your SIP Service Provider or vendor handling the other side of the SIP Sessions.
Start by conducting a conference call preferably a screen share where you can demonstrate the SIP Flows and Sessions affected with the “480 Temporarily Unavailable” SIP Responses for the inbound traffic.
In my case I had traces running in CM/SM/SBCE to follow the SIP Flow from cradle to grave. And had the Service Provider pull traces to compare them with mine’s.
During a conference call we concluded the issue was coming from the Service Provider’s end as they also noticed the same SIP Responses within their equipment.
Two redundant SIP Routers were use for redundancy. We found the second SIP Router was never giving us an issue, so we decided to move the outbound traffic over to the second SIP Router. The Provider directed the inbound accordingly.
The next day the Service Provider confirmed they were using 20% of the licensed channels in the primary SIP Router and to fix it a software update war required.
Develop and apply fixes
In this case we created a temporary solution by routing the outbound calls over the secondary SIP Router until the vendor updated and corrected the license issue.
Keep in mind that when troubleshooting SIP Flows there are SIP Request and a Response. It could be at times confusing as the messages may not flow in sequence, a good rule of thumb is to follow the cseq number to give you an idea if those sessions are part of the same SIP Sequence.
Please note: I reserve the right to delete comments that are offensive or off-topic.