Summary:	ASTERISK-01266: codec_g729b.so needs to be rebuilt to handle new frame format
Reporter:	Paul Cadach (pcadach)	Labels:
Date Opened:	2004-03-22 08:48:13.000-0600	Date Closed:	2011-06-07 14:10:44
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	Due to changes in ast_frame structure codec_g729b.so needs to be rebuilt.
Comments:	By: zoa (zoa) 2004-03-22 09:28:11.000-0600 hmmz, codec_g729b is closed source, so that might not be possible. There is no workaround possible ? By: Paul Cadach (pcadach) 2004-03-22 12:01:35.000-0600 Possible workaround is to clone output frame *before* returning it from ast_translate() and *before* assigning values for newly added members (delivery, for example). Other way (which is more right for me) is to change codec's API and pass empty frame structure to ...tolin_frameout() function as second argument and ask Voiceage to update codec_g729b. This way will be never make dependencies on actual ast_frame structure except for N leading fields. By: James Golovich (jamesgolovich) 2004-03-22 12:40:23.000-0600 Digium can rebuild the codec_g729b.c file, which is where the problem would be.  I believe voiceage provides them with a library that codec_g729b is linked against.  So I don't believe this should be a problem By: James Golovich (jamesgolovich) 2004-03-23 13:51:01.000-0600 Maybe I can throw another request in here with this one.  If digium rebuilds codec_g729b.c maybe they could add in some code to check if option_nofork and option_console are set and if not bomb out with an error message instead of whatever happens now when you try to use g729 without a console By: Paul Cadach (pcadach) 2004-03-23 14:00:16.000-0600 James, do you mean leaving shared memory segments by G729 codec when asterisk stops? By: Brian West (bkw918) 2004-03-23 14:21:03.000-0600 Pcadach what is the problem you are seeing? By: Paul Cadach (pcadach) 2004-03-23 14:37:58.000-0600 See bug ASTERISK-1212 which is closed by Mark as "not fixable". The problem is when you do "stop now" Voiceage's codec_g729b.so leaves shared memory segments and at next start it tries to allocate the same segments (when opens codec). There are three solutions: 1) patch safe_asterisk to remove all free shm segments; 2) patch codec_g729b.c to do the same; 3) (which is more powerful for other situation too) - just unload any loaded modules when Asterisk stops. But some bugs at unloading G.729 co-exists - you can't do unload codec_g729b.so load codec_g729b.so without totally freezing Asterisk. By: James Golovich (jamesgolovich) 2004-03-23 14:46:30.000-0600 PCadach: I dont have any g729 license, thus I don't use it.  but I know that you must have a real console running for g729 to work, so to limit the number of bugs/list posts regarding this if codec_g729 would exit gracefully with an error message when it detects no master console then it would save a ton of problems that newbies have By: Mark Spencer (markster) 2004-04-15 17:43:04 As it turns out, code analysis suggests that the codec should not have to be recompiled to work with CVS head, although i'd be happy to hear from someone who could tell me if that is in fact the case.  Are you actually, really, seeing the problem, or just theorizing it should be there? By: chrisorme (chrisorme) 2004-04-15 18:59:45 I use g729 a lot and rely on it working very much, I know what you think about g729 but I'm afraid I have no real commercial choice as I know of no ATA has GSM and the IAXYs adpcm was objected to heavily in customer trials on grounds of voice quality.  (sorry) G729 is a good quality low bandwidth codec and when you haven't bandwidth to burn or it's nearly $60,000 for an E1 like here then it's a valuble thing to have believe me. I have bravely just updated to most recent CVS to address ASTERISK-1323.   I will see if my world falls apart.  Any pointers as to what (according to theory) I should see going wrong if something is going wrong here (I run safe_asterisk)... I've read this bug and I haven't seem anyone report a definite 'if I do this then,' sort of problem... If everything does fall apart can anyone suggest the most recent version of code with the old frames in that I could fall back to. I have been running 31/3 stable CVS for two weeks now with g729 without any g729 related problems or complaints.  Perhaps it has the old frame code though? Re: safe_asterisk I patched (I think) safe_asterisk to run asterisk from /usr/src/asterisk and not /tmp (I think) so asterisk would start ok with the g729 library in.  Maybe that's an idea for others or CVS ?  Seemed to work for me. I also added more v's and a -d for good measure in there. By: chrisorme (chrisorme) 2004-04-15 19:29:11 I've just trialled latest CVS with G729 and ATA186 w/SIP 3.1 firmware then on to a provider via IAX2/alaw. My test isn't ideal as it's a bit obscured by the fact that. provider 1: bug ASTERISK-1323 applies to this connection, clicks that mute output heard in earpiece by person making the call resulting I think from timestamp issues in their asterisk ???? provider 2: 250ms latency doesn't help - perhaps I need to increase a value in rtp.c above 670 or post timestamp info ? but bug ASTERISK-1323 dropouts on side of person making the call doesnt obscure the connection so it's basically better and seems functional enough So basically it seems ok, or same as my stable version, for me anyway... I'll see what feedback I get from those in the field as it those guys that use it all day every day .. By: chrisorme (chrisorme) 2004-04-16 04:27:40 I get loads of these. Apr 16 09:19:04 NOTICE[229390]: frame.c:120 ast_smoother_feed: Dropping extra frame of G.729 since we already have a VAD frame at the end and bizarrely.. Apr 16 06:26:06 WARNING[458765]: codec_ilbc.c:141 ilbctolin_framein: Huh? An ilbc frame that isn't a multiple of 50 bytes long from RTP (4)? when ilbc isn't 'allowed' in my conf and none of the devices used to connect to it as far as I know have ilbc capability anyway.  Can someone shout as to what is the most recent version that has the old frames code in incase the phone starts ringing with complaints - ta? By: chrisorme (chrisorme) 2004-04-16 05:31:12 the ilbc error was a false alarm due to a customers SIP client firmware not understanding how to negoiate codec with asterisk. By: chrisorme (chrisorme) 2004-04-17 08:50:19 I've been using G729 with CVS build 15/4 to ATA186s (3.1 f/w) since 15/4 and have had several long >1hr conversations on it and have not experienced problems theorised above.  Warnings generated and noted above have been my completely my fault arising from incompatible configuration of devices above such as silence suppression on the 186 or in a device not knowing what to do when an incompatible codec (ilbc) was thrown at it in first place by * in the SIP dialog (fuller info in my post on asterisk-dev). I am curious as to the load that G729A puts on a box compared to other codecs though and have been thinking about why transcoding is 17ms one way and something like 1ms the other in 'show translation'.  I guess it's just down to either the algorithm or the way it was done by voiceage? Is this right ? But basically I have not been able to experience, confirm or reproduce any of the problems theorised by the reporter.  What exactly should go wrong?  None of our field testers (all whom use G729) reported any problems and it looks stable.  Sorry, or congratulations! Chris By: Mark Spencer (markster) 2004-04-17 22:11:51 Turns out this was just a theoretical.