CM: Denial events 1191,1192, and 1012 on SIP trunks.

Doc ID    SOLN299335
Version:    1.0
Status:    Published
Published date:    03 Nov 2016
Author:   
Josh Coughlan
 

Details

2x Denial events on a SIP trunk.


Operating system: Linux 2.6.18-348.AV5xen i686 i686
Built: Aug 19 14:53 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-21172 activated cold patch 21172 for 03.0.124.0


KERNEL-2.6.18-348.AV5 activated cold kernel patch KERNEL-2.6.18-

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

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


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

CM License Installed: 2016-10-14 11:58:57

CM Memory Config: Large

Ingate SIParator -> Intelepeer phone number -> CMN/A

Problem Clarification

When making inbound or outbound calls through the INGATE SIParator they fail. When calling inbound there is a provider message stating the call can't be completed; this would indicate it is not even making it to the CM. CM does not play these messages, the service provider does.  On outbound calls there are 1191 (network failure) and 1012 (no channels available) denial events. It looks like an issue with either the INGATE box or the service provider.

Cause

Service Provider.

Solution

Engaged the Service Provider and an INGATE engineer. We went through the configuration and made some changes. The INGATE engineer fix some configuration issues on the box. The issue was still happening. He ran a sniffer and could see that handshake was failing on the service provider side. They changed some IP addresses and the calls went through. The issue changed to one way audio. This was because the service provider was sending audio to the wrong IP address. They worked on fixing this.


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