asterisk users - Aug 2008 - cmdRecord issue related to "iax2 received mini frame before first full voice frame"?

Hi,
  I tried sending this message a few months back but never lucked into
a response.  I thought I'd try one more time, juicing up the subject
heading a bit, as I am still seeing this behavior intermittently.

  I'm running several asterisk servers in combination with dundi.  The
servers are in different data centers, but other than that they are
running identical copies of the same os image, asterisk configuration,
etc.  One server acts as the trunk and is used to terminate pstn
calls, and pass them on to another server via dundi, which then
answers the call.
  I recently noticed that one of the call-answering servers was
responding and playing back voice prompts fine, but was failing to
record any user generated audio.  After opening up the CLI on this
server and running a test call through it, I noticed reams of the
following warning message any time audio was being played or recorded:
[May 21 20:31:52] WARNING[27346]: chan_iax2.c:8020 socket_process:
Received mini frame before first full voice frame
[May 21 20:31:52] WARNING[27346]: chan_iax2.c:8020 socket_process:
Received mini frame before first full voice frame
[May 21 20:31:52] WARNING[27346]: chan_iax2.c:8020 socket_process:
Received mini frame before first full voice frame
[May 21 20:31:52] WARNING[27346]: chan_iax2.c:8020 socket_process:
Received mini frame before first full voice frame
[May 21 20:31:52] WARNING[27346]: chan_iax2.c:8020 socket_process:
Received mini frame before first full voice frame
[May 21 20:31:52] WARNING[27346]: chan_iax2.c:8020 socket_process:
Received mini frame before first full voice frame
[May 21 20:31:52] WARNING[27346]: chan_iax2.c:8020 socket_process:
Received mini frame before first full voice frame

  I found the following related post:
http://lists.digium.com/pipermail/asterisk-users/2006-January/136982.html

  However this doesn't explain why I should be unable to record
anything.  The issue seems to be related to network activity, and I'm
not seeing it on any other servers.

  A more detailed explanation of what the above warning means/implies,
and how or why it might be preventing recordings would be greatly
appreciated.

  I'm running Asterisk 1.4.11 on debian Etch.

  Cheers

I am trying to look for a software (open source or proprietory) that could do
reporting on both queue and CDR in Asterisk 1.4.*

Could someone give me some suggestions?

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

queuemetrics

Lee, John (Sydney) wrote:
> I am trying to look for a software (open source or proprietory) that 
> could do reporting on both queue and CDR in Asterisk 1.4.*
> 
> Could someone give me some suggestions?
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> 
> AstriCon 2008 - September 22 - 25 Phoenix, Arizona
> Register Now: http://www.astricon.net
> 
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
-- 
Faraz R Khan
Chief Architect
Emergen Consulting Pvt Ltd
+92.21.529.0381 x200
www.emergen.biz

On Wednesday 13 August 2008 04:50:24 Novak Joe wrote:
> [May 21 20:31:52] WARNING[27346]: chan_iax2.c:8020 socket_process:
> Received mini frame before first full voice frame
>
>   A more detailed explanation of what the above warning means/implies,
> and how or why it might be preventing recordings would be greatly
> appreciated.
A mini frame is simply a frame containing minimal information about the
call itself (the meta data), and a full frame contains all of the meta-data
information.  Sending mini-frames is part of the IAX protocol, as a way of
saving significant bandwidth over the course of a call.  However, a mini frame
cannot be interpreted correctly independently of a full frame.  In every media
stream, a full frame is send approximately once every 60 seconds, to sync the
timestamps.

You could think about it in a different way, by considering a video encoding
method, whereby the full image is sent every once in a while, but only the
differences (which are much smaller) are sent most of the time.  If you have
only a frame containing the differences to an image that you never got in the
first place, then it's very difficult to know what to do with that.
>   I'm running Asterisk 1.4.11 on debian Etch.
There have been many changes, bug fixes, and even security issues fixed since
1.4.11.  I'd really recommend that you try something more recent (and even
the
latest, because we fixed 2 security issues in the latest release, 1.4.21.2).

-- 
Tilghman

>>   A more detailed explanation of what the above warning means/implies,
>> and how or why it might be preventing recordings would be greatly
>> appreciated.
>A mini frame is simply a frame containing minimal information about the
>call itself (the meta data), and a full frame contains all of the meta-data
>information.  Sending mini-frames is part of the IAX protocol, as a way of
>saving significant bandwidth over the course of a call.  However, a mini
frame
>cannot be interpreted correctly independently of a full frame.  In every
media
>stream, a full frame is send approximately once every 60 seconds, to sync
the
>timestamps.
>>   I'm running Asterisk 1.4.11 on debian Etch.
>There have been many changes, bug fixes, and even security issues fixed
since
>1.4.11.  I'd really recommend that you try something more recent (and
even the
>latest, because we fixed 2 security issues in the latest release, 1.4.21.2).
Thank you very much for this clear explanation of what is going on.
The implication then is that this issue could indeed be having a
significant impact on whether calls are eventually recorded?  I plan
to look into upgrading our distribution, but this appears to be
impacting 1/10 calls coming through our system at the moment so I
wonder if there is some/any way to help make sure that that first full
voice frame gets sent before the miniframes get pushed through?  I
also wonder if there is a point after which the call is lost,
regardless of whether the first full voice frame comes through?  could
other issues like mismatches between the system clocks on the
respective machines also be impacting performance?

thanks a bunch!



--
Tilghman