G.729 PLC Messages

[Dayton]

I notice from time to time i get a ton of G.729 PLC messages in a row
(sometimes a constant flood for 5-10 seconds)

I'm curious of a couple things:
- Is this indicative of a larger problem or just a troubled g729 peer
on a latent or lossy link?
- Is there a way I can modify the code to output the channel that was
affected (e.g. -- G729 PLC (SIP/peer-123) )

Thanks in advance!

[Arkadi Shishlov]

On 2010-06-30 04:50, Dayton wrote:
> I notice from time to time i get a ton of G.729 PLC messages in a row
> (sometimes a constant flood for 5-10 seconds)
>
> I'm curious of a couple things:
> - Is this indicative of a larger problem or just a troubled g729 peer
> on a latent or lossy link?

Most likely it is lost RTP frames that results in PLC - unstable
connection between you and your peer.

> - Is there a way I can modify the code to output the channel that was
> affected (e.g. -- G729 PLC (SIP/peer-123) )

The translator receives ast_frame to decode, ie. pure data. I think
there is no sane way you can get to ast_channel from inside of the codec.
1. You can hack Asterisk sources and insert printf() there, when its
about to invoke the translator with frame->datalen == 0.
2. If you enable "g729 debug", then at translator shutdown you'll get
the statistics of received frames sizes. You can correlate that with SIP
channel shutdown debug message. Not convinient, but with a bit of Perl
you'll get channel<->frames stats.

[Dayton]

>
> Most likely it is lost RTP frames that results in PLC - unstable
> connection between you and your peer.
>

Is there any way then currently to identify which peer this is
happening to without modifying the code?

> > - Is there a way I can modify the code to output the channel that was
> > affected (e.g. -- G729 PLC (SIP/peer-123) )
>
> The translator receives ast_frame to decode, ie. pure data. I think
> there is no sane way you can get to ast_channel from inside of the codec.
> 1. You can hack Asterisk sources and insert printf() there, when its
> about to invoke the translator with frame->datalen == 0.

That might be a challenge. I'm not overly adept in the asterisk
codebase.

> 2. If you enable "g729 debug", then at translator shutdown you'll get
> the statistics of received frames sizes. You can correlate that with SIP
> channel shutdown debug message. Not convinient, but with a bit of Perl
> you'll get channel<->frames stats.

So g729 debug will tell me when a channel shuts itself down about what
happened? Is there a readability guide for that output?


-- g729 frames
-- length: count
-- 0: 9
-- 20: 18937

I presume this means there were 9 0-lengthed frames, although with
~120 calls set up at any given time on this server, its near
impossible to correlate which channel this was for. If i could get
this info after the channel is shut down thats fine with me too.

[Arkadi Shishlov]

On 2010-07-01 00:05, Dayton wrote:
>> Most likely it is lost RTP frames that results in PLC - unstable
>> connection between you and your peer.
>
> Is there any way then currently to identify which peer this is
> happening to without modifying the code?

I think no.

>>> - Is there a way I can modify the code to output the channel that was
>>> affected (e.g. -- G729 PLC (SIP/peer-123) )
>

>> 2. If you enable "g729 debug", then at translator shutdown you'll get
>> the statistics of received frames sizes. You can correlate that with SIP
>> channel shutdown debug message. Not convinient, but with a bit of Perl
>> you'll get channel<->frames stats.
>
> So g729 debug will tell me when a channel shuts itself down about what
> happened? Is there a readability guide for that output?
>
> -- g729 frames
> -- length: count
> -- 0: 9
> -- 20: 18937
>
> I presume this means there were 9 0-lengthed frames, although with
> ~120 calls set up at any given time on this server, its near
> impossible to correlate which channel this was for. If i could get
> this info after the channel is shut down thats fine with me too.

Yes, the particular translator instance received 9 zero-lenth PLC frames.
The translator is shut down at channel hangup. There are other places
too that can provoke debug message, because some applications, like
Playback, would get its own translator (if necessary). So, in general:
one call - one translator per direction, only receiving side prints the
debug message.
I assume, if you follow console messages, then "g729 frames" debug
message will be near corresponding SIP Hangup message. You can parse the
output and get the stats. Translator deallocation and channel hangup
should happen on the same thread, so until call rate is insane you'll
get non-interleaved output most of the time.