Re: [asterisk-dev] Re: Help with 240 samples on frames readfromchan_iax
On Mon, Nov 06, 2006 at 06:59:44PM -0600, Moises Silva wrote: MS Hum, it seems to work with slinear, ulaw, alaw and gsm, but not with MS iLBC, it complains about ilbc frame not being multiple of 50, so i MS tried to make it happy, but still misses some translations from MS slinear to iLBC and the sound is choppy. What makes iLBC so special MS any way? Are you get app_conference work with 1.4? -- JID: [EMAIL PROTECTED] ICQ: 58417635 (please, use jabber, if you can) http://freesource.info/ signature.asc Description: Digital signature ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
RE: [asterisk-dev] Re: Help with 240 samples on frames readfromchan_iax
Tilghman wrote: On Monday 06 November 2006 12:36, Dan Austin wrote: 'Fixing' app_conference is a worthy endevour, but convincing chan_iax to honor framing limits on both the send and receive legs of a channel would be a big win. Even better would be the addition of an IE to convey the desired framing/payload would allow Asterisk and endpoints to 'negotiate' symmetric packetization. Chan_skinny has that feature, and it greatly reduces the amount of effort to make sure all devices are using identical values for framing. But it still is an issue. If a malicious attacker finds that you crash when a 50ms frame is submitted to your system, then you might be crashing all day. Sending someone a packet larger than they are expecting should never cause their system to crash. If it does, that's a bug on the receiving system. I agree completely with your point of view, I am just saying that more could be done. In the scenario that Moises described, it sounds like he might managed the server that the SPA is registered to. If he had the ability to force the framing between the two servers to 20ms, it would have helped. It would not help if an endpoint that uses a payload other than 20ms was register to the same server that hosts app_conference, so making app_conference more resilient is a valid goal. IAX is a great concept, but it is lacking when it comes to media control, specifically framing, which limits the sysadmins ability to control his (or her) environment. I have a few ideas on how to improve the situation, but implimentation would require more intimate knowledge of IAX2 than I posess Dan ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Re: Help with 240 samples on frames readfromchan_iax
On 11/6/06, Dan Austin [EMAIL PROTECTED] wrote: In the scenario that Moises described, it sounds like he might managed the server that the SPA is registered to. If he had the ability to force the framing between the two servers to 20ms, it would have helped. It would not help if an endpoint that uses a payload other than 20ms was register to the same server that hosts app_conference, so making app_conference more resilient is a valid goal. Sure, I think it would be great to have that control over our network. By the way, I have fixed app_conference, smoothers rules!, do you know if iaxclient-dev maling list the correct place to post my patch that fixes the framing issue? I sent an email saturday without response, but may be with a patch included some one will get interested. Best Regards -- Su nombre es GNU/Linux, no solamente Linux, mas info en http://www.gnu.org; ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Re: Help with 240 samples on frames readfromchan_iax
Hum, it seems to work with slinear, ulaw, alaw and gsm, but not with
iLBC, it complains about ilbc frame not being multiple of 50, so i
tried to make it happy, but still misses some translations from
slinear to iLBC and the sound is choppy. What makes iLBC so special
any way?
I just did this to fix the app_conference issue:
/* create the smoother if were receiving more samples than needed */
if ( AST_CONF_BLOCK_SAMPLES fr-samples ) {
if ( member-inSmoother == NULL ) {
/* calculate bytes per sample */
ast_log(LOG_DEBUG, %s frame has %d samples in %d
bytes\n, member-channel_name, fr-samples, fr-datalen);
float bytes_per_sample = ( (float)fr-datalen /
(float)fr-samples );
ast_log(LOG_DEBUG, %s frame has %f bytes per sample\n,
member-channel_name, bytes_per_sample);
float new_frame_len= ( AST_CONF_BLOCK_SAMPLES *
bytes_per_sample );
if ( fr-subclass == AST_FORMAT_ILBC ) {
ast_log(LOG_DEBUG, ILBC format only accepts datalen
multiple of 50, so make it happy\n);
if ( new_frame_len 50 ) {
new_frame_len = 50;
}
}
ast_log(LOG_DEBUG, %s new frame size is %f\n,
member-channel_name, new_frame_len);
member-inSmoother = ast_smoother_new(new_frame_len);
That is, I have fixed the samples on any frame to
AST_CONF_BLOCK_SAMPLES, that is 160 samples ( calculated from slinear
at 20ms with 8000 samples per second ), this is needed because the
mix_slinear_frames function in app_conference requires that maximum
number of samples. Any ideas, again to make it work with iLBC or any
other frame size dependant codec?
Thanks.
On 11/6/06, Moises Silva [EMAIL PROTECTED] wrote:
On 11/6/06, Dan Austin [EMAIL PROTECTED] wrote:
In the scenario that Moises described, it sounds
like he might managed the server that the SPA is registered to. If
he had the ability to force the framing between the two servers to
20ms, it would have helped. It would not help if an endpoint that
uses a payload other than 20ms was register to the same server that
hosts app_conference, so making app_conference more resilient is a
valid goal.
Sure, I think it would be great to have that control over our
network. By the way, I have fixed app_conference, smoothers rules!,
do you know if iaxclient-dev maling list the correct place to post my
patch that fixes the framing issue?
I sent an email saturday without response, but may be with a patch
included some one will get interested.
Best Regards
--
Su nombre es GNU/Linux, no solamente Linux, mas info en http://www.gnu.org;
--
Su nombre es GNU/Linux, no solamente Linux, mas info en http://www.gnu.org;
___
--Bandwidth and Colocation provided by Easynews.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
