Submit a ticketCall us

Training ClassThe Orion® Platform Instructor-led Classes

Provided by SolarWinds® Academy, these trainings will introduce users to the Orion Platform and its features, management, and navigation. These courses are suitable for users looking to discover new tips, tricks, and ways to adapt their Orion products to better suit their monitoring needs:
Deploying the Orion Platform
Configuring Orion views, maps, and accounts
Configuring Orion alerts and reports

Reserve your seat.

Home > Success Center > VoIP & Network Quality Manager (VNQM) > VNQM - Knowledgebase Articles > Call data unavailable in VNQM from Avaya CM in a VIP configuration

Call data unavailable in VNQM from Avaya CM in a VIP configuration

Created by Matthew Lamb, last modified by Ricardo.Morais on Sep 12, 2018

Views: 1,294 Votes: 2 Revisions: 6


This article provides brief information and a  workaround to find missing call records from Avaya call managers when the customer is using a VIP configuration. An Avaya CM build using a VIP is generally for load balancing purposes to free the interface IP from having to send the bulk of it's traffic. In such a configuration, VNQM will not recognize that the CDR data it is receiving is actually from the Avaya call manager.

The warning typically apppears in the IPSLA Business layer logs pertaining to this:

WARN  BusinessLayer.TcpServer (null) - Dropping connection with device, that has no monitoring enabled. IP Address: X.X.X.X


In the above error, the IP it states it is receiving data from is not the actual IP of the Avaya call manager, but something else. This is a general indication that it's coming from another avaya call manager that needs to be added in, or in the most likely case, it's being issued from a VIP.


To confirm this, you can also run a PCAP and set the Capture Filter to TCP port 50000 or the capture filter to tcp.port == 50000 and see where the traffic is coming from to the VNQM server.


  • VNQM version 4.2
  • All Avaya versions
  • ACM configured with VIP (Virtual IP)


VNQM listens for the CDR data through TCP port 50000 and collects the data based off the sender's IP. If the sender's IP matches the IP of the nodeid in the voipccmmonitoring table in VNQM, then it accepts it as a monitored call manager. However, in a VIP configured environment, the CDR data is actually being issued by the VIP (virtual IP) rather than from the polling IP or interface IP.

Because of this, VNQM sees the traffic arrive, but finds no record of it in the database. All of these packets are then dropped because it is not a recognized IP.


Note: This is not a resolution, but a workaround. Currently VNQM does not have the ability to relate VIP issued data to the nodeid of the call manager. You must insure that the customer has had sufficient time to poll the actual Avaya call manager in VNQM for all the phone and gateway related information. Once the workaround is conducted, the phone and gateway related information will no longer be gathered.


  1. Verify that the CDR data is coming from an IP other than the IP of the monitored NodeID in VNQM. There should not be another call manager. 
  2. Add the IP into Orion as an ICMP only node.
  3. Get the NodeID for that IP from the Nodes or NodesData table.
  4. In the VoipCcmMonitoring table, replace the NodeID of the Avaya Call manager with the NodeID of the recently added IP.
  5. Restart the Orion Module Engine Service.



We have checked the resolution above with Development and it should be noted that this workaround will case the following issues:
1.    Newly added Phones, Gateways, etc. or changed CDR configuration on Primary Avaya will NOT be polled by VNQM once NodeID of Primary Avaya is changed with NodeID of VIP Avaya in VNQM
2.    If we want to poll new data from Primary Avaya then NodeID of VIP Avaya must be changed back with NodeID of Primary Avaya in VNQM, but then completed calls will NOT be grabbed by VNQM from VIP Avaya


Thus, if customer want to be up-to-date with Avaya data (completed calls, phones, gateways, etc.) in VNQM then this ‘workaround’ is NOT applicable for them. 


VNQM does NOT support VIP Avaya in parallel with Primary Avaya.


Last modified



Internal Use Only