CM, SBC: Outbound calls rejected with 1183.


Doc ID    SOLN300530
Version:    1.0
Status:    Published
Published date:    25 Nov 2016
Author:   
Josh Coughlan
 

Details

We are not able to make outbound calls over our AT&T SIP trunk. We are hearing turkey tony/fast busy when making outbound local calls and/or outbound toll free number calls.

Operating system: Linux 2.6.18-348.AV04xen i686 i686
Built: Jan 18 17:44 2013

Contains: 03.0.124.0
CM Reports as: R016x.03.0.124.0
CM Release String: vcm-016-03.0.124.0
Publication Date: 04 October 2012

UPDATES:
Update ID Status Type Update description
------------------------------- ------------ ------- ---------------------------
03.0.124.0-20850 activated cold patch 20850 for 03.0.124.0



Platform/Security ID Status Type Update description
------------------------------- ------------ ------- ---------------------------

Messaging ID Status Type Update description
------------------------------- ------------ ------- ---------------------------


CM Translation Saved: 2016-11-07 22:00:21

local calls and outbound toll free number calls are all routed over our AT&T SIP trunks. These AT&T SIP trunks are trunk group #900 and #901.Nothings changed on the Avaya platform.

Problem Clarification

All outbound calls over the IPFLEX SIP trunks fail with denial event 1183 call rejected. Traces from the SBC show that the messages are being sent to the provider, but a 403 forbidden is returned. The message packet contains "incoming call barred within CUG". CUG is "Closed User Group". Not sure what this means, but I am guessing it means the call is not allowed through. The customer did not change anything on the Avaya side, and could not find any changes in list history other than station changes. This has been working for years. The only change the customer could think of, is that they had some numbers removed on the provider side. There were multiple people involved from the provider side that said this would not be an issue.

Cause

This issue was caused by the changes made on the provider side. I am not sure how this happened, but the signaling IP address used on the Cisco router was the same as some Hotel in Florida. This was not the IP address the provider was expecting to see traffic coming from so it was denying the call. This is a router managed by the provider.

Solution

The IP address issue was corrected on the providers cisco router. The IP addresses and routes were adjusted on the SBC and Firewall as well. Issue resolved.


Avaya -- Proprietary. Use pursuant to the terms of your signed agreement or Avaya policy