Page 1 of 1

Extra Codec information on recordings

PostPosted: Tue May 13, 2014 4:10 pm
by Leon van Heerden
The AmtMitelCRE and the VOIP Sweeper (version 1.6.4.36+) extract information from the recordings while processing them and it is added to the database with the recording information.

Here is an example of the output as seen on the Amethyst Supervisor Screen.
Code: Select all
Extra information
    Signal codecs   
    RTP codecs   G.729, Unknown codec (13)
    Mixed codecs   False
    Total packets   29,357
    Lost packets   0
    Delayed packets   222


The RTP Codecs lists all the codecs that were used during this recording. We have found cases where the agent's side and client side, are using 2 different codecs. E.g. the system has a licensed G.729 processor and the licenses has been exceeded. The fall back codec is the used on the PBX side. The recording is still made an properly mixed. This is useful in tracking when bandwidth heavy codecs were used over remote links.
If an Unknown codec is listed, and the recording sounds incorrect, please report this to Datatex Support.
Unknown Codec (13) can occur if comfort noise is being injected by the PBX. This can usually be ignored.

Mixed Code will be true if more than one codec was detected on this recording.

Total Packet lists the number of valid packets that were supposed to be received. Since this packets are numbered with sequence numbers, it is possible to also report missing and delayed packets.

Lost Packets are calculated by checking for missing sequence numbers and usually indicates a network problem that caused the packets not to arrive at the recording interface. This is usually also an indication that there is some network issue that could cause issues with the quality of the phone calls. Large percentage of packet loss will be audible on the phone calls and the recordings.

Delayed Packets are reported when packets are received out of sequence. If there is no packet loss, this will not be audible on the recordings since the packets are sorted into the correct order before processing. On the live call though, you may have stuttering or silents during parts of the calls. This is usually an indication of some network issue that will cause speech quality loss.

Re: Extra Codec information on recordings

PostPosted: Fri Oct 28, 2016 2:56 pm
by Belinda Frick
Extra information
    Signal codecs
    RTP codecs G.729, Unknown codec (96)
    Mixed codecs False
    Total packets 1,679
    Lost packets 0
    Delayed packets 2

Payload types from 96 to 127 (inclusive) are dynamic payload types – this means there is no specific codec associated with those numbers – it can be anything. SIP has to negotiate what payload types will be used for what codec, other PABX protocols (Avaya, Siemens, etc.) can have hard-coded payload types.

If they are using SIP, the SDP section of the SIP will show what each payload type is used for.

It looks something like this:

    v=0
    o=MxSIP 0 1 IN IP4 192.168.15.195
    s=SIP Call
    c=IN IP4 192.168.15.195
    t=0 0
    m=audio 3000 RTP/SAVP 0 8 9 115 18 96 97 98 112 113 101
    a=rtpmap:0 PCMU/8000
    a=rtpmap:8 PCMA/8000
    a=rtpmap:9 G722/8000
    a=rtpmap:115 G726-32/8000
    a=rtpmap:18 G729/8000
    a=rtpmap:96 G726-40/8000
    a=rtpmap:97 G726-24/8000
    a=rtpmap:98 G726-16/8000
    a=rtpmap:112 L16/8000
    a=rtpmap:113 L16/16000
    a=rtpmap:101 telephone-event/8000
    a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:a1RLZE10UHQvQHF3QiVXSVJAdUVWaEo9JTMoPyhW
    a=fmtp:18 annexb=no
    a=fmtp:101 0-15
    a=ptime:30
    a=sendrecv


    In this case:
    0 = PCMU/8000 – uLaw
    8 = PCMA/8000 – Alaw
    9 = G.722
    18 = G.729
    Those are all standard and fixed. SIP supplies them regardless

    96=G.726
    97=G.726
    98=G.726
    112=linear 16-bit 8000Hz
    113=linear 16-bit 16000Hz
    115=G.726

    101=DTMF