Home My Account My Shopping Cart

Codima autoVoIP™ FAQs

Following are some frequently asked questions specifically about autoVoIP™ VoIP Monitoring Software. Click each FAQ to view the answer.

autoVoIP™ Background Information:

  1. What is autoVoIP™, how does it fit in with other Tools in the Codima Toolbox? What is autoVoIP™, how does it fit in with other Tools in the Codima Toolbox?

    autoVoIP™ is a VoIP network monitor that gathers quality of service (QoS) parameters, including delay, lost packets and jitter, the state of the network, the VoIP server performance, its topology and potential problems on the communication.

    Analysis can be undertaken with a single autoVoIP™ system or the probes can be used in conjunction with a Remote Manager to extend the domain.

    • Provides a passive non-intrusive based VoIP analysis system
    • Can service multi-site installations via locally installed probes
    • Can present enterprise network overview for NOC
    • Requires RTP, RTCP and SIP on monitored phones

    It operates on Windows XP or Server 2003 Platforms, using standard NICs.

    Hide this FAQ
  2. What is the autoVoIP™ Consultancy Kit? What is the autoVoIP™ Consultancy Kit?

    The autoVoIP™ Consultancy Kit is a software bundle consisting of three tools: autoVoIP™, autoMap™, and autoAnalyzer™.

    It also provides access to:

    • Flow Analyzer:
      Facility to analyze the frame flow - breaking it down by Class, i.e., Media, Signalling and Reporting
    • FTP Analyzer:
      Facility to analyze the RTP payload
    Hide this FAQ
  3. What protocols does autoVoIP™ support? What protocols does autoVoIP™ support?
    autoVoIP™ analyses information held in SIP, SDP, RTP and RTCP
    • SIP (Session Initiation Protocol)
      Protocol associated with Call set up and clearance
    • SDP (Session Description Protocol)
      Protocol used to describe the details of the streaming media sessions and multicast transmissions
    • RTP (Real Time Transport Protocol)
      Protocol used for the transmission of video and audio files in real time for Internet applications such as IP telephony
    • RTCP (RTP Control Protocol)
      Protocol associated with QoS
    • RTCP-XR (RTP Control Protocol, Extended Reporting)
      Protocol associated with QoS
    Note: The autoVoIP™ Traffic Simulator can be used to simulate traffic on an H323 network and measure QoS.
    Hide this FAQ
  4. How fast can autoVoIP™ handle traffic? What line speeds will it support? How fast can autoVoIP™ handle traffic? What line speeds will it support?

    The line speed is handled by the NIC card used, i.e., if it is a 10Mb NIC it will monitor traffic at that rate, if it is 1Gb NIC it will monitor traffic at that rate.

    The performance will be subject to the capabilities of the NICs used by the autoVoIP™, dropped packet counts are logged.

    Hide this FAQ
  5. How many Phones/Calls can a single autoVoIP™ system process? How many Phones/Calls can a single autoVoIP™ system process?

    Using a standard NIC and a suitable PC platform , autoVoIP™ will be able to process many thousands of Phones/Calls at SIP Protocol Level. However if the autoVoIP™ system is also monitoring RTP then the count would be a lot less. The following provides a rough guide:

    • Monitoring SIP only - 10,000 simultaneous calls
    • SIP plus RTP - 1,000 simultaneous calls
    Signalling

    At SIP level - a call every 30 seconds with 8 frames per call = packet rate for 10,000 phones is 10,000/30x8 = 2,666 frames per second

    A single autoVoIP™ system should be able to handle around 100,000 frames per second, so would not have any problems with this level of traffic.

    Media

    Bottlenecks can occur when trying to process the MEDIA (RTP and RTCP stream) at large concurrent call rates.

    • RTP - Each Voice call runs at about 50 frames/second
    • RTP/RTCP combined media stream - 50x2x10000 (see note) = 1,000,000 frames per second. This would be too fast for a single autoVoIP™ system by a factor of 10, as a typical autoVoIP™ platform will handle around 100,000 frames second.

    Note: Calculation is being applied to an example situation where there are 50 frames per second x 2 (bothways) x 10,000 phones.

    In cases where bottlenecks are likely to occur, additional probes will be required. This makes the autoVoIP™ system scalable for use on large networks.

    Hide this FAQ
  6. Will autoVoIP™ phone tracking work if my phones/SIP Servers do not use the Registered SIP Port (5060)? Will autoVoIP™ phone tracking work if my phones/SIP Servers do not use the Registered SIP Port (5060)?
    autoVoIP™ tracks SIP Traffic. The following reports are populated with information obtained by the analysis of the SIP protocol:
    • Monitoring
    • Traffic Police
    • Troubleshooting

    To generate these reports it is important that the SIP Port is known to the system. The Registered Port for SIP is 5060, so the autoVoIP™ system defaults to analyze traffic on that port as SIP.

    However, autoVoIP™ can also be customized to decode SIP on other ports. Port 5061 for example has been added using the customization facility.

    Hide this FAQ
  7. What is the Flow Analyzer? What is the Flow Analyzer?

    The Flow Analyzer breaks down the call into dialogs, covering Signaling, Media and Reporting for both the incoming and outgoing flow. The Flow Analyzer operates post capture on frame files captured.

    The frame files should include RTP frames to make the most of the Flow Analyzer, as the RTP payload can be analyzed further using the following specialist facilities:

    Note: Frame files capture via the autoVoIP™ Call Analyzer are NOT suitable for RTP Analysis as they do not include the RTP payload.

    Hide this FAQ
  8. How is autoVoIP™ licensed? How is autoVoIP™ licensed?

    A standard autoVoIP™ license will control the number of Registered phones that the autoVoIP™ system is allowed to monitor. A subscription license will not set limits, but user will be charged for the number of Registered phones the Codima Discovery Engine discovers during each month.

    What is a subscription License?

    Subscription licenses are provided to users who are being charged by usage. Usage applies to the number of managed devices counted during the operation of the Codima Discovery Engine (autoMap™ and autoAsset™ users) and number of Registered Phones (autoVoIP™ users).

    Hide this FAQ

Scope / Applications:

  1. When would I use autoVoIP™? When would I use autoVoIP™?
    • Pre deployment – to check out network readiness
      For example, after adding a SIP Server and a couple of SIP Phones to your network, autoVoIP™ can be used to monitor the QoS levels of VoIP traffic so you can check how ready your network is for your VoIP implementation. With a few phones, you can establish if the QoS is acceptable - lost packets, jitter levels, R and MOS values etc.
    • During deployment of VoIP
      • To check VoIP traffic service level
      • To monitor Call set up
      • To Troubleshoot – i.e., establish if the network is suitable for VoIP
    • During daily operation
      • To monitor VoIP - Voice Quality is effected by other traffic so needs to be continually monitored
      • To provide remote access to VoIP analysis
    Hide this FAQ
  2. Can I integrate with SNMP Managers? Can I integrate with SNMP Managers?

    The Codima Toolbox includes tools which provide SNMP Manager Integration, e.g., autoAnalyzer™ Consultancy Kit, autoVoIP™ Consultancy Kit, Probes. This is done by accessing the fully integrated SNMP Module. This module can add value to an already installed SNMP Manager, in a number of ways. Including:

    EXTEND MANAGERS RANGE TO COVER NON-SNMP NODES/TRAFFIC

    • Issue Traps to the Manager in respect of problems associated with Non-SNMP Compliant Nodes, immediately extending the SNMP Managers range.
    • Issue Traps in respect of all the Traffic/Errors on a Segment. (i.e., monitoring actual real time loading and errors, not the loading/error information obtained from SNMP compliant nodes), providing the manager with a complete/impartial view of the segments traffic.

    This will use information obtained from Passive Analysis of the Network. The SNMP Manager must have compiled the Codima MIB. The MIB {Enterprise.226} is included in the file set installed with autoVoIP™. Traps can be issued to multiple SNMP Managements systems, for full information contact us.


    Hide this FAQ
  3. What Codec support is provided? What Codec support is provided?
    Codec Algorithm Bit Rate
    (Kbps)
    Notes
    G.711 PCM 64, 56

    A ITU (International Telecommunications Union) standard for a narrow-band audio codec that encodes speech into a stream of 8 bit samples (or less frequently 7 bit samples) at 8khz. This creates a data stream at either 64kbps or 56kbps. G.711 uses a logarithmic mapping that emphasizes the parts of the signal that the human ear is most sensitive to. Uses pulse code modulation

    There are two variants of G.711:

    • uLaw - Used with T1 and J1 connections
    • aLaw - used with E1 connections (Europe and Australia)
    High quality, high bandwidth
    G.722 ADPCM 48-64

    A ITU standard wideband speech codec.

    G.722.1 offers low bit-rate compressions.

    G.722.2, also known as AMR-WB (Adaptive Multirate Wideband), offers even lower bit-rate compressions and the the ability to vary compressions as the network topography changes. For example bandwidth is automatically conserved when network congestion is high. When congestion returns to a normal level, a lower-compression, higher-quality bit rate is restored.

    G.722 and its variants sample audio data at a rate of 16 kHz, double that of traditional telephony interfaces, which results in superior audio quality and clarity.

    G.722 patents have expired, so it is freely available.

    G.723.1 ACELP
    MP-MLQ
    5.3
    6.3

    A ITU standard for a narrow-band audio codec that encodes speech into a stream of data frames that each represents 30ms (240 samples) of speech data. Each frame can be either 24 or 20 bytes long, which makes the data stream either 6.4kbps or 5.3kbps.

    License fee to use this Codec commercially.

    Lower quality and < 10% of bandwidth used by G.711. (Less bandwidth = more delay)

    Uses MP-MLQ (Multi-Pulse Maximum Likelihood Quantization)

    G.726 ADPCM 40, 32,
    24, 16

    A ITU standard for a narrow-band audio codec that encodes speech into a stream of 2, 3, 4, or 5 bit samples - data stream = 16kbps, 24kbps, 32kbps, or 40kbps.

    Uses ADPCM (Adaptive differential pulse code modulation.

    G.728 LD-CELP 16

    A ITU standard for a narrow-band audio codec that encodes speech into a stream of 10 bit frames that each represent 5 samples - data stream = 16kbps. License fee to use this Codec commercially.

    Uses CS-ACELP (Conjugate-structure algebraic-code-excited linear prediction speech coder).

    G.729 CS-ACELP 8

    A ITU standard for a narrow-band audio codec that encodes speech into a stream of data frames that each represent 10ms (80 samples) of speech data. Each frame is 10 bytes - data stream = 8kbps. License fee to use this Codec commercially.

    Uses CS-ACELP (Conjugate-structure algebraic-code-excited linear prediction speech coder).

    GSM
    06.10
    PCM 13.2

    A narrow-band audio codec that encodes speech into a stream of data frames that each represent 20ms (160 samples) of speech data. Each frame is 264 bits, giving a data stream of 13.2kbps.

    Hide this FAQ
  4. How are phones Tracked? How are phones Tracked?

    To track phones the autoVoIP™ system needs to use a unique ID, the options available are:

    • By IP Address
    • By URI

    The URI method for example would apply in a situation where the traffic being monitored by the autoVoIP™ tool has already passed through a NAT firewall and no longer contains the IP addresses of the Phones. The tracking method used is controlled by the Toolbox License.

    At least one phone has to have been monitored by autoVoIP™ registering with the SIP Server to activate the phone tracking process. If the autoVoIP™ system is not seeing registrations it is also possible to by pass this stage by manually adding the SIP Servers IP address - contact us for more information.

    Hide this FAQ

VoIP Technology:

  1. What are MOS and R values? What are MOS and R values?

    MOS (Mean Opinion Score: standard - P80) is a Metric intended to convey User Experience of Phone Conversation in a single number

    R-value (standard – G107) is an objective measurement calculated directly from measurements of packet loss, jitter and delay. It also has a strong correlation with the MOS value.

    Hide this FAQ
  2. What is RTCP-XR? What is RTCP-XR?

    RTP Control Protocol Extended Reports, this is a new VoIP management protocol, it defines a set of metrics that contain information for assessing VoIP call quality and diagnosing problems. See RFC 3611 for detailed information. This protocol is not yet widely used commercially.

    RTCP-XR lets systems like autoVoIP™ obtain information on signal, noise and echo levels without having to decode the packet stream, which will be essential if payloads are encrypted using the new Secure RTP protocol from the IETF.


    Hide this FAQ
  3. Why is RTCP a more effective method of measuring QoS, than measuring Jitter/Lost Frames in RTP Directly? Why is RTCP a more effective method of measuring QoS, than measuring Jitter/Lost Frames in RTP Directly?
    1. RTCP reports the user experience because it alone (in general) experiences the final jitter and lost frames values at the end point phone as experienced by the user. §Measuring RTP at a SPAN port is susceptible to frame drops and queuing delays caused by the SPAN mechanism itself, there by potentially effecting the QoS results.
    2. In contrast RTCP, lost or delayed frames do not cause calculation errors, instead there are just blips in the QoS feed. There is a much smaller bandwidth required for monitoring RTCP, presenting a much lower load to the SPAN port.
    3. The phones are distributed throughout the Network, and each phone would need to be monitored locally to get an accurate RTP QoS calculation.
    4. RTCP reports the user Experience at Both Ends of the RTP path, which is not possible to determine when monitoring RTP at a single point.

    Hide this FAQ