[Asterisk-Users] Help Debugging Dropped Call Audio - Add'l Info

Wed Dec 21 15:52:49 MST 2005

On 21 Dec 2005, at 22:31, Matt Roth wrote:

> List users,
>
> I have some additional information related to the dropped audio.   
> As always, I'd appreciate any help interpreting it.
>
> I set up an extension that calls the Milliwatt() application and is  
> digitally recorded by the Monitor() application.  Calls placed to  
> it don't result in any of the custom warning messages and produce  
> recordings free of skips/pops.  I know that the same code is being  
> executed, because it is also where the digital recordings are  
> streamed to file.
>
> Therefore, it can be concluded that the problem lies somewhere in  
> the differences between a SIP to SIP call and a SIP to Asterisk (in  
> this case, the Milliwatt() application) call.  The most obvious of  
> the differences is that a SIP to SIP call involves two active SIP  
> channels that are bridged together.  A SIP to Asterisk call only  
> involves one active SIP channel.  I confirmed this by placing calls  
> of both types and observing the output of the "sip show channels"  
> command in the CLI.
>
> To confirm that it is not simply a matter of the number of active  
> SIP channels on the Asterisk server, I placed two simultaneous SIP  
> to Asterisk calls and observed that no custom warning messages were  
> generated.
>
> On a SIP to SIP call, a custom warning message is almost always  
> generated from the ast_read() function as soon as the callee picks  
> up the phone and the SIP channels are bridged.  The messages then  
> appear sporadically throughout the call, and there is often a final  
> message generated when the call is terminated.  Keep in mind, each  
> of these messages is indicative of a short drop in the call audio  
> which can be heard as a pop/click on the PCM format recording.
>
> All of this leads me to believe that the problem dwells somewhere  
> in the code responsible for bridging the channels.  Does anyone  
> have any ideas as to the specific cause or the direction that I  
> should go to further pursue it?  I've heard that Asterisk's locking  
> scheme is questionable, but I don't know if that would apply to  
> this scenario.
>
> I'd still like to hear if anyone else has replicated the problem,  
> as well.

I have no experience of your problem, and I have never delved into  
the SIP code, but I think
I have come across a problem with a similar cause.

I was working on an IAX client, and experiencing increasing latency,  
such that one speech
was delayed by several seconds from one end to the other.
It turned out that the clock in one of my endpoints (an old laptop)
was running 2% slower than the other one (a new SNOM phone). The code  
in my laptop was using
the built-in clock to decide when to play received data. So it wasn't  
reading data quite as fast as it arrived,
slowly more and more data got buffered, and the audio got behind the  
other end.

I fixed this by getting the code to notice that the clocks were  
skewed, and then dropping
a few samples in an effort to catch up, which results in a click  
(sometimes).

I think that the problem you are hearing is related to this, i.e. if  
the clocks are skewed, then
* has to drop some of the data from the faster source to keep them in  
sync, or make up
some data from the slower!

The other strategy * tries to adopt is to time an entire call from  
the clock at one end, and have
the other end use that timing (your milliwatt case), but where there  
are 2 external parties involved
this isn't an option.

The WARNING in the code you cite does give a hint as to what the  
programmer is attempting.

I'd say your best bet for a fix would be to try and get the gaps less  
perceptible by some
sort of linear interpolation.

Tim.

>
> Thanks,
>
> Matthew Roth
> InterMedia Marketing Solutions
> Software Engineer and Systems Developer
>
> Matt Roth wrote:
>
>> 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.
>> _______________________________________________
>> --Bandwidth and Colocation provided by Easynews.com --
>>
>> Asterisk-Users mailing list
>> To UNSUBSCRIBE or update options visit:
>>   http://lists.digium.com/mailman/listinfo/asterisk-users
>>
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
>
> Asterisk-Users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users

http://www.westhawk.co.uk/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20051221/edf4bda1/attachment.htm