[Home]

Summary:ASTERISK-05391: Dropping extra frame of G.729 since we already have a VAD frame at the end
Reporter:Abhay Gupta (agupta)Labels:
Date Opened:2005-10-29 06:25:40Date Closed:2008-01-15 15:56:13.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/RTP
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:whenever we call to the ITSP supporting SIP with g729 we get the above error.

1. The call is made from Audiocodes 108 FXS to ITSP via ASTERISK
2. This error comes and most of the voice is lost.
3. If we call from Audiocodes to voice providor directly there is no issue.



****** ADDITIONAL INFORMATION ******

We tried changing the frame.c file to remove this error
} else
s->optimizablestream = 0;
if (s->flags & AST_SMOOTHER_FLAG_G729) {
if (s->len % 10) {
// ast_log(LOG_NOTICE, "Dropping extra frame of G.729 since we already have a VAD frame at the end\n");
// return 0;
// ignore extra bytes, do not drop entire frame, it has our data..
                       s->len = (s->len / 10) * 10;
                      //ast_log(LOG_NOTICE, "Dropping frame of G.729 since we already have a VAD frame at the end (%d)\n", s->len);
                      //return 0;
}

There is a huge delay after that.
Comments:By: Abhay Gupta (agupta) 2005-10-29 06:29:28

the version is 1.0.7 and not 1.0.9
By: Olle Johansson (oej) 2005-10-29 07:38:12

Why did you mark this private? A lot of people can't help you solve the problem then. Maybe it was a mistake.
By: Mark Spencer (markster) 2005-10-29 13:02:29

What codec is being used talking to each side?  If it's G.729 on both sides then the problem is a mismatch between the size of RTP packets in both side.  Make sure they are both 20ms.
By: Abhay Gupta (agupta) 2005-10-30 00:13:37

It is G729 at both ends. The SIP phone supports G729a and the other end G729b and in SIP logs i do not see any annex b = no being sent from asterisk , so the packets must be coming in G729B format only with VAD .
By: Mark Spencer (markster) 2005-10-30 02:06:38.000-0600

The question is not the B vs. A, since Asterisk can pass through both.  The problem is the packetization size on both ends.
By: Abhay Gupta (agupta) 2005-11-02 00:49:02.000-0600

The packetisation size is 20ms at both ends.

Moreover my question is if , i modify the frame.c file so that it does not drop packets . ( i.e remove that return 0; line) will it have any impact on the other program files , or i can do that ??
By: Bluce Ree (tasker) 2005-11-02 11:08:32.000-0600

This is an old stupidity that's been lingering around for ages and brought up by several people with no fix ever being put into CVS.

Dropping frames is needless and causes severe voice quality issues with some equipment. The developers seem to think that the rest of the world will configure their equipment to our needs.

Here's how I, and most others, have fixed it:

if (s->flags & AST_SMOOTHER_FLAG_G729) {
       if (s->len % 10) {
             s->len -= (s->len % 10);
           // ast_log(LOG_NOTICE, "Dropping extra frame of G.729 since we already have a VAD frame at the end\n");
           // return 0;
       }
}


The fix above truncates any extra bytes past the voice frame. Your fix multiplies the remainder of (s->len / 10) by 10 times, thus your extra delay.

Though my fix works, the concern I have is whether 's' is freed according to 'len', in which case it would cause memory leaks. It might be prudent to store 'len' and set it back after the frame has been processed.

Can someone please correct me if I've overlooked something?
By: Mark Spencer (markster) 2005-11-02 21:37:16.000-0600

What' you're overlooking is that the RTP specification does not permit you to put anything after a VAD frame within a single packet and for good reason.  You can tell by the length whether there is or is not VAD there, but if you don't limit VAD to only being at the end of the frame and only having one of them, you would not be able to know what the format of the packet is.
By: Abhay Gupta (agupta) 2005-11-03 11:44:31.000-0600

Tried adding the parameter. There is no delay in voice , but the packets are dropped. When we speak for 4-5 seconds there is speech then complete silence for 3-4 secs and then speech.

We tried asking the other person to count numbers and lots were not heard. The same time when tried calling from devices directly like Audiocodes , Cisco ATA without asterisk in between there was no such problem . So is surely a problem with Asterisk code only.
By: ssa (serge) 2005-11-03 15:09:03.000-0600

I have too this problem with Grandstream phones. We try use 'UA' >>G729>> 'asterisk' >>G729>> 'sip prov'  or try to 'h323 prov' with and without codec_g729.so , all time for some ( not all ) destinations "one way sound" and this error. Now we use g723 and all work Ok with any configuration.
By: Sebastian Nocetti (snocetti) 2005-11-03 15:14:26.000-0600

Only solution I found about VAD on Asterisk is simply disabling it on both sides, I hope Asterisk's gurus and programmers can solve it soon, because when VAD packet's are present I can't hear on one side (most of cases)... :(

Thanks
By: Abhay Gupta (agupta) 2005-11-05 09:57:33.000-0600

It is strange that we are still not sending annexb=no on SIP with G729 codec
By: Mark Spencer (markster) 2005-11-05 23:55:29.000-0600

The codec does not officially support it, and VAD is not currently a feature of Asterisk, but in any case we should pass through fine if the configuration was actually correct.  It might be helpful to attach an ethereal capture of the traffic on both sides so we can see the difference between the RTP traffic on both sides.
By: Mark Spencer (markster) 2005-11-05 23:55:50.000-0600

Also, we need to test this with head, not 1.0, since 1.2 will be coming out soon and 1.0 will not continue to be maintained.
By: ssa (serge) 2005-11-07 11:24:20.000-0600

"but in any case we should pass through fine if the configuration was actually correct." ---------
As I have early posted, I delete file codec_g729.so - but no difference !. Due this passthrough not work too. I have actual CVS , but early I use 1.0.7 and all this whith same configurations work fine.
By: Kevin P. Fleming (kpfleming) 2005-11-07 22:09:45.000-0600

If removing codec_g729.so from your system is affecting passthrough mode, then you are not actually operating in passthrough mode.
By: Abhay Gupta (agupta) 2005-11-08 06:47:52.000-0600

Trying to upload ethreal dump . file size 1.8MB . gives the error for exceeding the limit. How to send the file?
By: Abhay Gupta (agupta) 2005-11-08 07:00:29.000-0600

I have inserted the line in SDP
a=fmtp:18 annexb=no

There is no error after that. Even the RFC says that if annexb=no is not mentioned than the default behaviour is to send G729B , and this is what was happening.

We need to add the same in the stable CVS
By: Mark Spencer (markster) 2005-11-09 09:30:01.000-0600

We shouldn't have an issue passing through G.729B though even if we can't interpret it.  I don't mind adding that setting but I"d really like to see what's happening.  You can make a much smaller snapshot of RTP, all we need is a couple of seconds of RTP activity at the most, bidirectionally on both legs of the call.
By: ssa (serge) 2005-11-15 14:50:06.000-0600

agupta, can you attach patch here? Thank's.
By: Kevin P. Fleming (kpfleming) 2005-11-15 18:04:18.000-0600

I've added this to CVS HEAD; we were clearly not operating in conformance with the RFC. Thanks for all the debugging work!
By: Digium Subversion (svnbot) 2008-01-15 15:56:13.000-0600

Repository: asterisk
Revision: 7107

U   trunk/ChangeLog
U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r7107 | kpfleming | 2008-01-15 15:56:13 -0600 (Tue, 15 Jan 2008) | 2 lines

issue ASTERISK-5391

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=7107