Telephony

Avaya

The Telephony plugin for Avaya uses RTCP (Real Time Control Protocol) and works with RTP (Real time Transport Protocol) to deliver both the call payload and management information. RTP is a framing protocol for real time applications that provides content labels and time functions for inter-media and intra-media synchronization. RTCP is a periodic control packet that provides a feedback mechanism for the media flow. Both are carried over UDP. This is useful as a management interface because the devices involved in a call can send the control packets to multiple destinations. Management applications can observe the results of a call without the need to actively participate in the control of the device.

RTCP has five basic packet types:

• SR - Sender Reports (basic tx and rx statistics from senders) In telephony, all ends of the call are senders

• RR - Receiver Reports (rx statistics from other participants or from active senders if > 31 sources)

• SDES - Source description, including CNAME

• BYE - explicit leave

• APP - application specific extensions

Avaya call process code is an RTCP listener that lives in following files:

• listener.rtcp.cpp

• listener.rtcp.hpp

These use functions from:

• ListenerUtil.cpp

• ListenerUtil.hpp

The call process code parses the four basic types and does not support APP (application specific extensions). It is a generic RTCP listener that is tied to Avaya devices. The primary data source is the Sender Report which provides the following information:

• SSRC (identification of the source)

• NTP data (time stamp when the report was sent)

• RTP data (corresponding RTP time)

• packet count

• octet count

• Jitter

• time stamp of last SR

• delay since last SR

• cumulative number of packets lost

• fraction of packets lost since last report

Because RTCP packets are periodically sent, the data from all of the packets for a given conversation are summed together to provide data representative of a call via the following processing logic:

• Obtain port, threads, device_id, and domain from the list of passed arguments

• Obtain the value of "synced" from the row

• Initialize the listener

• Create a thread pool of the size specified that call parse_packet() method

• Create a epoll fd with the following three fds:

  • The socket listening to the port specified

  • A timerfd to send periodic updates

  • Listener.pipe_read for communication with the calling process

• Use epoll_wait to absorb multiple events

  • If the event came from pipe_read, assume it was a thread aborting and remove it from the pool

  • If the event came from the socket

    • call recv_packet()

      • calloc for the size of the buffer

      • calloc for a SevonePacketData pointer

      • add length, timestamp, and point SevonePacketData->buffer to buf

      • dispatch a thread to process the data

  • If the event came from the timerfd

    • complete_timedout_calls() for anything that last had an update > 300 seconds ago

    • reset the timerfd

• parse_packet()

  • Make and verify a local DB connection to use within the specific parsing functions

  • Specific Parsing for the various types to return MetricData

    • SR - pull pertinent metrics, normalize time values, and call mergeCallDataPacket()

    • RR - functionally empty

    • SDES - pull CNAME, NAME, EMAIL, PHONE, LOC, TOOL, NOTE, and call mergeCallDataPacket()

    • BYE - call report_completed_call()

  • Immediately free MetricData without examination

    • MetricData is handled within each packet type parser

• mergeCallDataPacket()

  • Data primarily keyed on "cname" which is the SSRC

Cisco Unified Communications Manager (CUCM) a.k.a. CCM a.k.a. CM

Cisco CallManager has a different interface even though the handsets may support SIP and/or RTCP. Cisco expects the poller to use the CDROnDemand service to reverse SFTP files that describe each discrete call from the CallManager. Each call is described by a CDR (Call Detail Record) and may be accompanied by zero or multiple CMRs (Call Management Records). CMRs are generated for each endpoint that participates in a call, but in certain situations (encoding changes, conference calls, etc.) there may be multiple records issued. In order to fit those records within the database structure, the Telephony plugin makes one entry in telephony.legs and one entry in telephony.cmcdrlegs for each CDR.

The Telephony plugin uses the following for CDR call collection:

• Periodically wake and ask the CM for the list of files that have been generated since the last successful import. This builds the list of call records to be fetched.

• For each file, bring it over to the current system (done via CM SFTPing the file to SevOne NMS)

  • drop the files into /cmcdr

  • Call Processing (see below)

    • If a file was not received or had general parsing errors, attempt to retransmit the file from the source

    • If the file was processed successfully, move it to the processed files section

  • Identify that the call processing for this time block has been successful and move the import time forward in the database

• Periodically remove older files from the system.

The Telephony plugin uses the following for CDR call processing when the file comes in:

• Check the field cdrRecordType to determine it is a CDR or CMR, 1 is CDR, 2 is CMR

• If CDR, for each line of records:

  • Insert into telephony.calls with the domain name and get the insert ID to use as the call_id for telephony.legs.

  • Parse and add CDR record to the database

  • Check telephony.cmcdrlegs, which contains CMR records, to see if any CMR records for this CDR arrived earlier than this record. If so, update the cmcdrlegs.leg_id with leg.id

• If CMR, for each line of records:

  • Check if a CDR record arrived earlier, if so, grab the leg.id and use it for cmcdrlegs.leg_id.

  • Update telephony.cmcdrlegs with this CMR record

• Matching CDR and CMR records

  • Use source_callId which is the combination of globalCallID_callManagerId and globalCallId_callId

  • This ID loops back every 7 days (extremely worst case) to match the CDR and CMR records and checks for the file arrival time. If the time difference is within 1 day, the records are paired.

The Telephony plugin uses the following for CDR statistical analysis

• Jitter and Latency are the MAX value across all CMR files for a particular leg_id

• Loss is calculated (in percentage) by the sum(packet_lost)/sum(packets_sent+packets_recv)

• MOS for each leg is the average value of MLQK, which is MLQKav

• R is calculated by using MIN(mos)

SIP

Session Initiation Protocol (SIP) is a communications protocol that signals and controls multimedia communication sessions. The most common applications of SIP are in Internet telephony for voice and video calls, as well as instant messaging all over Internet Protocol (IP) networks. The protocol defines the messages that are sent between endpoints, which govern establishment, termination and other essential elements of a call. SIP is an application layer protocol designed to be independent of the underlying transport layer.

The SIP processing logic is similar to the RTCP handling code except that:

• There is only a single message type

• Calls are terminated when the Telephony plugin stops getting messages

Telephony Reports

Telephony reports take data from two principle tables and one vendor specific table that describe each call. All data for Telephony Report comes from telephony.legs table unless otherwise noted.

• telephony.calls

• telephony.legs

• telephony.cmcdrlegs

Basic Report Fields