[Home]

Summary:ASTERISK-05886: Dropping extra frame of G.729 since we already have a VAD frame at the end
Reporter:Sergey Basmanov (sb)Labels:
Date Opened:2005-12-22 05:34:25.000-0600Date Closed:2007-06-29 12:24:37
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:This is realted to closed issue 5539 (but not duplicate).
This issue was fixed for SIP, but still in place with H.323
My setup:
SPA1001/G729/SIP--->*1.2.1/G729/SIP--->*1.2.1/G729/H.323--->VoIP provider
I don't know what equipment used at remote side.
I receive this errors only on * which is connected by H.323 to provider.
I can provide any additional information if needed.

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

This is parts of debug log:

Dec 22 07:15:27 VERBOSE[1082] logger.c: Allowed Codecs:
Dec 22 07:15:27 VERBOSE[1082] logger.c:          Table:
Dec 22 07:15:27 VERBOSE[1082] logger.c:    G.729A <1>
Dec 22 07:15:27 VERBOSE[1082] logger.c:    G.729 <2>

Dec 22 07:15:27 VERBOSE[1082] logger.c:         -- Sending SETUP message
Dec 22 07:15:33 VERBOSE[1082] logger.c:         -- Started logical channel: receiving G.729A

Dec 22 07:15:33 VERBOSE[1082] logger.c:         -- Started logical channel: sending G.729A
Dec 22 07:15:33 VERBOSE[1082] logger.c:                 -- channelsOpen = 2

Dec 22 07:15:37 VERBOSE[1080] logger.c:     -- H323/telenet-134 answered SIP/local-gw-05d3

Dec 22 07:15:38 NOTICE[1080] frame.c: Dropping extra frame of G.729 since we already have a VAD frame at the end

And so on...
Comments:By: Matthew Fredrickson (mattf) 2005-12-27 08:22:14.000-0600

Looks like your provider has VAD enabled...  currently in -HEAD we can't deal with VAD, however, I think that there's a patch somewhere here on the bugtracker that allows asterisk to work with this.
By: Sergey Basmanov (sb) 2005-12-28 14:38:57.000-0600

Yes. Looks like VAD. And I have no idea how to disable it from asterisk's side, because I have no control over provider's equipment. Well, on bugtracker I saw patches for SIP version of this issue.. But not for H.323.
According to disscussion for bug 5539 this issue related to G729B. Also, according to markster, if we passthrough - there must be no problem at all. So, both * in passthrough, and as I know, sipura can deal with G729A/B. So, why do I have this messages in logs and * drops frames? Looks like this is RTP issue, and it is not related directly to SIP/H.323. Am I right ? I think if * can't deal with VAD for now, it must passthrough such frames without any intervention.. And if I see this messages in logs, does it means that my * box doing transcoding and not in passthrough?
By: Matthew Fredrickson (mattf) 2005-12-29 07:14:07.000-0600

Ok, I may be showing my lack of SIP-esque, but are you sure that your RTP stream is reinvited?  (canreinvite=yes in sip.conf IIRC).
By: Matthew Fredrickson (mattf) 2005-12-29 07:18:50.000-0600

<smacks hand against head> Oh, wait, this is SIP->H.323, I'm not sure if that would work
By: Sergey Basmanov (sb) 2005-12-29 13:59:28.000-0600

Does SIP requires re-INVITE for passthrough?
As I know, there is no way to re-INVITE when SIP->H.323 call. Seems that H.323 have another way to change media path. Anyway, if * works in passthrough mode it should not care about such frames at all. And one thing still not clear to me (from bug 5539 discussion): if I comment out code that throws away this frames:
          ast_log(LOG_NOTICE, "Dropping extra frame of G.729 since we already have a VAD frame at the end\n");
          return 0;
will I have any other problems? Can I safely change s->len by this way:
s->len -= (s->len % 10); ?
By: Matthew Fredrickson (mattf) 2006-01-10 17:00:59.000-0600

RTP native bridging will only work on protocol stacks that utilize the asterisk rtp core.  Which h323 channel driver are you using?

The problem related with that message has to do with how you have to package rtp packets for g.729.  From my limited understanding of the way that rtp w/ g.729 works, this would not be a valid workaround.
By: Matthew Fredrickson (mattf) 2006-01-24 14:39:08.000-0600

No response
By: Sergey Basmanov (sb) 2006-01-27 08:55:34.000-0600

Sorry, was too busy be regular work.
Well, I'm using asterisk's native h.323 located at channels/h323
About RTP native bridge: in current h323 this feature is commented out in source, so no native bridge.
About VAD frames: I still have this issues with some peers, while anything fine with others. Even if I call SIP UA (g729) -> asterisk (passthrough) -> h323 peer. Allowed codecs - g729 only. I can't catch a moment in h.323 when I get this VAD errors. Possibly, this issue can be related to frame size. As I know, this is not adjustable in asterisk. Anyway, the problem still exists and we have to find a way to resolve it.
PS: who developing h323 now?
By: Matthew Fredrickson (mattf) 2006-01-27 14:59:56.000-0600

From the header of  the file: Jeremy McNamara.  I don't think that it's an issue for h.323 specifically, it's more of an RTP/frame size issue.  The current workaround available is to turn VAD off.  You can also look at the bug 5374 for preliminary VAD support.  However, it requires a zap timing device.
By: Sergey Basmanov (sb) 2006-01-28 03:57:39.000-0600

Same issue for SIP was fixed by adding line 'annexb=no' in SDP. I'm not familiar with h323, but I think there must be a way to tell remote not to use annexb. In my situation, I using voip exchange, so I don't know at which endpoint my traffic goes each time I call (even same number) and because of this, I can't ask remote to turn VAD off :)
By: Matthew Fredrickson (mattf) 2006-02-02 09:22:19.000-0600

I'm sorry, I don't have enough knowledge about codec negotiation (or the SDP equivalent thereof) in H.323 to know if that is possible.  It does not look like anybody monitoring this issue does either.  You can either find out yourself, or this probably will sit and rot.
By: Paul Cadach (pcadach) 2006-02-23 09:39:53.000-0600

The problem isn't for codec negotiation but for way of smoother handling G.729-coded packets.

20ms G.729 packet really contains two (!!!) frames (single G.729 frame is 10 ms), so VAD frame could be second frame in a packet, but also could be just single frame packet (this situation handled by smoother more-or-less correctly). So, the problem is smoother drops a packet contains one frame of G.729-coded data followed by VAD frame.

I had workaround for this situation about two years ago but I'm not sure I can locate the code.
By: Joshua C. Colp (jcolp) 2007-06-29 12:24:36

This issue should already be fixed, if not please reopen...