"Not Authorized" Failed Calls

This document provides general guidelines to troubleshoot calls rejected with “Not Authorized” release cause. Unauthorized calls are generated by unknown sources sending traffic, or known sources sending traffic but failing due to a configuration error. This article focuses on troubleshooting the latter.

CDRs are an invaluable source of information troubleshooting call admission, such as authorization failed calls. A sample Not Authorized call CDR is shown below: 

For peering resources, the VSXi authenticates calls based on the Service Port where traffic is arriving, IP layer source address, Tech Prefix, SIP Profile and Direction. These five elements, in that order, help determine the origination trunk ID or resource when the VSXi is processing an inbound request. Let's take a look at each item in detail: 

Service Port.

The SP is the combination of signaling protocol, transport protocol, port, IP address and service port type. If the VSXi receives a call on a wrong or nonexistent service port the call will not be authorized. In this context, a wrong service port is one that has not been provisioned on the intended inbound Trunk ID. A nonexistent service port is when the incoming packet combination of transport protocol, port, IP address, signaling protocol has not been provisioned. 

IP Layer Source Address.

If the request arrived at a valid Service Port, the VSXi will look for resources containing the source IP address. The originating IP address must be listed or fall under a range of IPs (i.e. netmask broader than /32) under a resource. If it is not listed, or the IP or 'NetMask' is wrong the system will ignore the attempt(s) and write a ‘999’ coded CDR record. 

Tech Prefix (TP).

The Tech Prefix is an optional method to authorize/process a call through the system. The VSXi will take the subset of resources with matching IP address and service port and based on the DNIS/ingress digits look for a TID. Traffic with leading digits matching a TID will be admitted; calls with DNISs that do not match the Tech Prefix will fail. Please note that if a resource (or resources) have 'default' Tech Prefix, TP authentication will not be enforced on that trunk. If more than one trunk exist in the subset of SP + IP Address, the VSXi will look in ascending order of Trunk ID until finding a match, if any. If more than one exists, the trunk with lower ID will be chosen. 

SIP Profile.

A SIP Profile specifies the customized or specific inbound and outbound handling of SIP parameters used in the course of a SIPbased call. The matched Trunk ID must have a SIP Profile that exists, otherwise the call will fail. When deleting a SIP Profile, make sure that no resources are attached to it. Starting on VSXi8.3.2.67, at the moment of deleting a SIP Profile, the GUI checks for resources tied it and displays a warning message displaying the affected trunks before allowing the SIP Profile to be deleted. 

Direction.

Lastly, after an incoming call has been matched with a Trunk ID (valid Service Port, IP Address, Tech Prefix and SIP Profile) its Direction needs to be 'in' or 'both'. If the matched Trunk ID is 'out' the call will fail. Have in mind that resource matching is primarily based on Service Port, IP Address and Tech Prefix. If more than one resource exist with this combination, the trunk with lower ID will be matched.

From GUI>Resources: Resource Edit