[Asterisk-Users] Help Debugging Dropped Call Audio

[Matt Roth]

List users,

Below is a bug report documenting Asterisk dropping call audio at very 
low loads (1 call).  I have personally reproduced it on three separate 
machines, multiple network architectures (including a 48-port Cisco 
Catalyst 3560 POE switch dedicated to an Asterisk server and two Snom 
320 VoIP phones), and three versions of Asterisk.

Despite this effort, I would still like to insure that I am not 
experiencing an isolated problem.  That is where I need your help.  If 
you could follow the steps in the bug report and post your results to 
the list, it would be greatly appreciated.

Thank you,

Matthew Roth
InterMedia Marketing Solutions
Software Engineer and Systems Developer

================================================================================

Description of problem:
Dropped audio during SIP to SIP, u-Law calls manifesting itself as 
clicks/pops in PCM format recordings.

Version-Release number of selected component (if applicable):
A.2-beta, A.2-1, SVN-branch-1.2-r7231

How reproducible:
Always

Steps to Reproduce:
1. Setup SIP to SIP calls to use the u-Law codec
2. Setup SIP to SIP calls to be recorded in PCM format via the Monitor 
application
3. Conduct a 5 to 10 minute SIP to SIP call
4. Mix the leg files with soxmix (soxmix -v 1.0 -t ul LEG-IN.PCM -t ul 
LEG-OUT.PCM -g -b MIXED.WAV)
5. Listen to the mixed file

Actual Results:
Periods of dropped audio in the call can be heard as clicks/pops in the 
recording.

Expected Results:
Clear call audio and recording.

Additional info:
The format that the call is recorded in is relevant.  The PCM format 
accentuates the dropped audio as a click/pop, while the GSM format masks 
it as periods of (sometimes imperceptible) silence.  Therefore, it is 
extremely important to record in PCM format to diagnose the problem.

Adding an ast_log() call to the ast_read() and ast_write() functions in 
channel.c that logs calls to the ast_seekstream() function can be 
helpful in debugging the problem.

For example:

    /* From ast_read() */
    int jump = chan->outsmpl - chan->insmpl - 2 * f->samples;
    if (jump >= 0) {
        if (ast_seekstream(chan->monitor->read_stream, jump + 
f->samples, SEEK_FORCECUR) == -1)
            ast_log(LOG_WARNING, "Failed to perform seek in monitoring 
read stream, synchronization between the files may be broken\n");
        chan->insmpl += jump + 2 * f->samples;
        /* Log calls to ast_seekstream */
        ast_log(LOG_WARNING, "Performed %d sample jump in monitoring 
read stream to synchronize the leg files\n", jump + f->samples);
    } else
        chan->insmpl+= f->samples;
        
All dropped call audio will now be accompanied by the "Warning" 
statement that has been added.  Note these as they appear in the console 
(or messages log) then listen to the recording.  You will see that the 
drops in call audio, the
clicks/pops in the recording, and the warnings are occurring at 
precisely the same moment.