Re: [asterisk-dev] res_fax_spandsp segfaults during fax detection - FIXED?
Hi All, Could this backtrace possibly be related? #0 process_rx_data (t=0x7fae54c698a8, user_data=0x2, data_type=1, field_type=optimized out, buf=0x7fae11c58cda "cng", len=0) at t38_terminal.c:314 #1 0x7fae11c22c7d in t38_core_rx_ifp_packet (s=0x7fae54c698a8, buf=0x7fae54c8475b "\002", len=1, seq_no=optimized out) at t38_core.c:459 #2 0x7fae50ea96c5 in generic_fax_exec (chan=chan@entry=0x7fadc4548c18, details=details@entry=0x7fad50602c28, reserved=reserved@entry=0x7fad50155478, token=optimized out) at res_fax.c:1498 #3 0x7fae50eaea9e in receivefax_exec (chan=0x7fadc4548c18, data="" out) at res_fax.c:1932 #4 0x00530fdd in pbx_exec (c=c@entry=0x7fadc4548c18, app=app@entry=0x2ddca60, data="" "/tmp/morpheus-1391681512.850.tiff") at pbx.c:1622 #5 0x0053656f in pbx_extension_helper (c=c@entry=0x7fadc4548c18, context=optimized out, exten=exten@entry=0x7fadc4549ab8 "0123489251", priority=priority@entry=6, label=label@entry=0x0, callerid=callerid@entry=0x7fadc44757b0 "0126413300", action="" found=found@entry=0x7fad838bad60, combined_find_spawn=combined_find_spawn@entry=1, con=0x0) at pbx.c:4922 #6 0x005404a4 in ast_spawn_extension (found=0x7fad838bad60, callerid=0x7fadc44757b0 "0126413300", priority=6, exten=0x7fadc4549ab8 "0123489251", context=optimized out, c=0x7fadc4548c18, combined_find_spawn=optimized out) at pbx.c:6038 #7 __ast_pbx_run (c=c@entry=0x7fadc4548c18, args=args@entry=0x0) at pbx.c:6513 #8 0x00541c0b in pbx_thread (data="" at pbx.c:6843 #9 0x00587c5a in dummy_start (data="" out) at utils.c:1162 #10 0x7fae530f2f3a in start_thread (arg=0x7fad838bb700) at pthread_create.c:308 #11 0x7fae54754dad in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 Had about 11 of those this morning on asterisk 11.7.0. Codec's that's allowed on SIP though is g729 and gsm only, so no ulaw/alaw allowed. Actually, just double checked, ulaw/alaw is (was now) allowed, so someone is possibly trying to run in bypass mode, resulting in the t38 gateway instead of t38 pass through. I downgraded to 11.6.0 and hadn't had a crash since but I opted to disable ulaw+alaw in any case, just to be on the safer side. Kind Regards, Jaco Kroon On 01/02/2014 06:49, Michal Rybrik wrote: Hello Pavel, On 01/31/2014 07:59 AM, Pavel Troller wrote: This code will translate non-slinear frames to slinear, just before they are sent to libspandsp for v21detection. With this patch applied, v21 detection is done also for RTP (SIP) alaw/ulaw frames, so maybe SIP/G711 - SIP/T38 gateway will work too. I tested DAHDI- SIP/T38, gateway works both ways, voice calls too. Is it better now? :o) I fully understand the code, but I'm not trained enough in the Asterisk internals to respond to questions, which immediately appeared in my head: 1) In the original code, the result from fax_gateway_detect_v21() is returned. Now, you are returning the original frame. I quickly looked at the above routine and it in turn calls fax_gateway_request_t38() and returns its result (but not always), and in the fax_gateway_request_t38() function they are also returning different things according to results of the program flow. So, is it really safe to do this ? Are you sure, that the real result is really unneccessary ? 2) Are you sure, that ast_translate() will always allocate a new buffer for tmpframe ? Is it written somewhere ? Isn't it possible that it will just reallocate the buffer for the original frame to increase its size and return its pointer, so by doing ast_frfree() you would just deallocate the same buffer, thus making big troubles ? You would find it by checking that tmpframe != f... As you can see, I'm very careful, or maybe even a bit conservative, with patching things, unless I really DEEPLY understand, how they are going... So, I believe, that you really studied the code
Re: [asterisk-dev] res_fax_spandsp segfaults during fax detection - FIXED?
Hi Jaco, if I understand correctly, your segfault did not happen during in T38gateway, but while receiving fax to tiff file (ReceiveFax), am I right? I haven't checked neither patched this (because my Asterisks are only relaying faxes, not terminating/originating to/from tiff file), but if your segfault happen when data are passed to libspandsp, it should be the same situation as mine was. Code in res_fax allows slinear/alaw/ulaw frames to be passed to res_fax_spandsp and then to libspandsp, but libspandsp accepts only slinear. When ulaw/alaw frames are passed here, bad things can happen. -- Regards, Michal Rybarik Da 6. 2. 2014 12:07, Jaco Kroon wrote / napsal(a): Hi All, Could this backtrace possibly be related? #0 process_rx_data (t=0x7fae54c698a8, user_data=0x2, data_type=1, field_type=optimized out, buf=0x7fae11c58cda "cng", len=0) at t38_terminal.c:314 #1 0x7fae11c22c7d in t38_core_rx_ifp_packet (s=0x7fae54c698a8, buf=0x7fae54c8475b "\002", len=1, seq_no=optimized out) at t38_core.c:459 #2 0x7fae50ea96c5 in generic_fax_exec (chan=chan@entry=0x7fadc4548c18, details=details@entry=0x7fad50602c28, reserved=reserved@entry=0x7fad50155478, token=optimized out) at res_fax.c:1498 #3 0x7fae50eaea9e in receivefax_exec (chan=0x7fadc4548c18, data="" out) at res_fax.c:1932 #4 0x00530fdd in pbx_exec (c=c@entry=0x7fadc4548c18, app=app@entry=0x2ddca60, data="" "/tmp/morpheus-1391681512.850.tiff") at pbx.c:1622 #5 0x0053656f in pbx_extension_helper (c=c@entry=0x7fadc4548c18, context=optimized out, exten=exten@entry=0x7fadc4549ab8 "0123489251", priority=priority@entry=6, label=label@entry=0x0, callerid=callerid@entry=0x7fadc44757b0 "0126413300", action="" found=found@entry=0x7fad838bad60, combined_find_spawn=combined_find_spawn@entry=1, con=0x0) at pbx.c:4922 #6 0x005404a4 in ast_spawn_extension (found=0x7fad838bad60, callerid=0x7fadc44757b0 "0126413300", priority=6, exten=0x7fadc4549ab8 "0123489251", context=optimized out, c=0x7fadc4548c18, combined_find_spawn=optimized out) at pbx.c:6038 #7 __ast_pbx_run (c=c@entry=0x7fadc4548c18, args=args@entry=0x0) at pbx.c:6513 #8 0x00541c0b in pbx_thread (data="" at pbx.c:6843 #9 0x00587c5a in dummy_start (data="" out) at utils.c:1162 #10 0x7fae530f2f3a in start_thread (arg=0x7fad838bb700) at pthread_create.c:308 #11 0x7fae54754dad in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 Had about 11 of those this morning on asterisk 11.7.0. Codec's that's allowed on SIP though is g729 and gsm only, so no ulaw/alaw allowed. Actually, just double checked, ulaw/alaw is (was now) allowed, so someone is possibly trying to run in bypass mode, resulting in the t38 gateway instead of t38 pass through. I downgraded to 11.6.0 and hadn't had a crash since but I opted to disable ulaw+alaw in any case, just to be on the safer side. Kind Regards, Jaco Kroon On 01/02/2014 06:49, Michal Rybrik wrote: Hello Pavel, On 01/31/2014 07:59 AM, Pavel Troller wrote: This code will translate non-slinear frames to slinear, just before they are sent to libspandsp for v21detection. With this patch applied, v21 detection is done also for RTP (SIP) alaw/ulaw frames, so maybe SIP/G711 - SIP/T38 gateway will work too. I tested DAHDI- SIP/T38, gateway works both ways, voice calls too. Is it better now? :o) I fully understand the code, but I'm not trained enough in the Asterisk internals to respond to questions, which immediately appeared in my head: 1) In the original code, the result from fax_gateway_detect_v21() is returned. Now, you are returning the original frame. I quickly looked at the above routine and it in turn calls fax_gateway_request_t38() and returns its result (but not always), and in the fax_gateway_request_t38() function they are also returning different things according to results of the program flow. So, is it really safe to do this ? Are you sure, that the
Re: [asterisk-dev] res_fax_spandsp segfaults during fax detection - FIXED?
Hi Jaco, I reviewed spandsp sources at the places where your segfaults happened, and this is very different situation than mine. But I see that span_log function (spandsp logging) is called frequently from this code, you should find some more information in spandsp log probably, to discover what happened before your segfault. Regards, Michal Rybarik On 02/06/2014 06:53 PM, Michal Rybarik wrote: Hi Jaco, if I understand correctly, your segfault did not happen during in T38gateway, but while receiving fax to tiff file (ReceiveFax), am I right? I haven't checked neither patched this (because my Asterisks are only relaying faxes, not terminating/originating to/from tiff file), but if your segfault happen when data are passed to libspandsp, it should be the same situation as mine was. Code in res_fax allows slinear/alaw/ulaw frames to be passed to res_fax_spandsp and then to libspandsp, but libspandsp accepts only slinear. When ulaw/alaw frames are passed here, bad things can happen. -- Regards, Michal Rybarik Da 6. 2. 2014 12:07, Jaco Kroon wrote / napsal(a): Hi All, Could this backtrace possibly be related? #0 process_rx_data (t=0x7fae54c698a8, user_data=0x2, data_type=1, field_type=optimized out, buf=0x7fae11c58cda "cng", len=0) at t38_terminal.c:314 #1 0x7fae11c22c7d in t38_core_rx_ifp_packet (s=0x7fae54c698a8, buf=0x7fae54c8475b "\002", len=1, seq_no=optimized out) at t38_core.c:459 #2 0x7fae50ea96c5 in generic_fax_exec (chan=chan@entry=0x7fadc4548c18, details=details@entry=0x7fad50602c28, reserved=reserved@entry=0x7fad50155478, token=optimized out) at res_fax.c:1498 #3 0x7fae50eaea9e in receivefax_exec (chan=0x7fadc4548c18, data="" out) at res_fax.c:1932 #4 0x00530fdd in pbx_exec (c=c@entry=0x7fadc4548c18, app=app@entry=0x2ddca60, data="" "/tmp/morpheus-1391681512.850.tiff") at pbx.c:1622 #5 0x0053656f in pbx_extension_helper (c=c@entry=0x7fadc4548c18, context=optimized out, exten=exten@entry=0x7fadc4549ab8 "0123489251", priority=priority@entry=6, label=label@entry=0x0, callerid=callerid@entry=0x7fadc44757b0 "0126413300", action="" found=found@entry=0x7fad838bad60, combined_find_spawn=combined_find_spawn@entry=1, con=0x0) at pbx.c:4922 #6 0x005404a4 in ast_spawn_extension (found=0x7fad838bad60, callerid=0x7fadc44757b0 "0126413300", priority=6, exten=0x7fadc4549ab8 "0123489251", context=optimized out, c=0x7fadc4548c18, combined_find_spawn=optimized out) at pbx.c:6038 #7 __ast_pbx_run (c=c@entry=0x7fadc4548c18, args=args@entry=0x0) at pbx.c:6513 #8 0x00541c0b in pbx_thread (data="" at pbx.c:6843 #9 0x00587c5a in dummy_start (data="" out) at utils.c:1162 #10 0x7fae530f2f3a in start_thread (arg=0x7fad838bb700) at pthread_create.c:308 #11 0x7fae54754dad in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 Had about 11 of those this morning on asterisk 11.7.0. Codec's that's allowed on SIP though is g729 and gsm only, so no ulaw/alaw allowed. Actually, just double checked, ulaw/alaw is (was now) allowed, so someone is possibly trying to run in bypass mode, resulting in the t38 gateway instead of t38 pass through. I downgraded to 11.6.0 and hadn't had a crash since but I opted to disable ulaw+alaw in any case, just to be on the safer side. Kind Regards, Jaco Kroon On 01/02/2014 06:49, Michal Rybrik wrote: Hello Pavel, On 01/31/2014 07:59 AM, Pavel Troller wrote: This code will translate non-slinear frames to slinear, just before they are sent to libspandsp for v21detection. With this patch applied, v21 detection is done also for RTP (SIP) alaw/ulaw frames, so maybe SIP/G711 - SIP/T38 gateway will work too. I tested DAHDI- SIP/T38, gateway works both ways, voice calls too. Is it better now? :o) I fully understand the code, but I'm not trained enough in
Re: [asterisk-dev] res_fax_spandsp segfaults during fax detection - FIXED?
Hello Pavel, On 01/31/2014 07:59 AM, Pavel Troller wrote: This code will translate non-slinear frames to slinear, just before they are sent to libspandsp for v21detection. With this patch applied, v21 detection is done also for RTP (SIP) alaw/ulaw frames, so maybe SIP/G711 - SIP/T38 gateway will work too. I tested DAHDI- SIP/T38, gateway works both ways, voice calls too. Is it better now? :o) I fully understand the code, but I'm not trained enough in the Asterisk internals to respond to questions, which immediately appeared in my head: 1) In the original code, the result from fax_gateway_detect_v21() is returned. Now, you are returning the original frame. I quickly looked at the above routine and it in turn calls fax_gateway_request_t38() and returns its result (but not always), and in the fax_gateway_request_t38() function they are also returning different things according to results of the program flow. So, is it really safe to do this ? Are you sure, that the real result is really unneccessary ? 2) Are you sure, that ast_translate() will always allocate a new buffer for tmpframe ? Is it written somewhere ? Isn't it possible that it will just reallocate the buffer for the original frame to increase its size and return its pointer, so by doing ast_frfree() you would just deallocate the same buffer, thus making big troubles ? You would find it by checking that tmpframe != f... As you can see, I'm very careful, or maybe even a bit conservative, with patching things, unless I really DEEPLY understand, how they are going... So, I believe, that you really studied the code enough to be sure, that you can really clear my doubts by your deep knowledge... I didn't have time to study the code to such extent... Answering these questions is not easy for me too, there are some parts of res_fax code which I don't fully understand. So I rather reworked the patch and moved it to another place, where functionality is easier to understand, and when it shouldn't harm anything. I uploaded diff to JIRA - https://issues.asterisk.org/jira/browse/ASTERISK-20149 Regards, Michal Rybarik -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] res_fax_spandsp segfaults during fax detection - FIXED?
Dear Pavel,
On 01/30/2014 06:55 AM, Pavel Troller wrote:
I probably found what causes random segfaults during fax detection with
spandsp... Many thanks for your contributions and brainstorming about this,
it helped a lot. If you have such issue, please test this possible fix and
let me know...
At res_fax.c, somewhere around line 3070, you'll find (at least for
Asterisk 11)
case AST_FORMAT_ALAW:
case AST_FORMAT_ULAW:
Comment out these two lines, recompile, reload and test.
As I understand the code, by commenting out these lines, we'll just abandon
the frame hook for A/ULAW samples, so we'll never gateway them then... Yes,
it will probabaly stop segfaulting, but as a side-effect, it will stop
gatewaying as well :-). Of course I may be wrong, I just had a little look
there...
I tested this fix before posting to the list, and T38 gatewaying is
working with it, at least in my setup (between DAHDI and SIP). I tested
both ways (SIP-DAHDI, DAHDI-SIP) and fax receipt was successful.
Gateway is enabled in sip.conf, in peer section:
setvar=FAXOPT(t38gateway)=yes,20
However, it seems that there is really a bug in the hook.
- On line 3130, we are attempting to translate the frames before we write
them to the faxing engine (on line 3141). It's OK.
- BUT: On line 3122, we are calling fax_gateway_detect_v21() with
UNTRANSLATED frames, which is FATAL - this detection can handle only linear
format similarly as real faxing, so we have to translate non-linear formats
(A/ULAW) for it as well! By not doing this, we probably
1) prevent successful detection of V.21, so it doesn't work either
2) In rare cases, crash the whole thing, because the detection code always
tries to read 320 bytes from 160byte buffer (as Michal pointed out below).
Once again, I may be wrong, but I think it's in accordance with all the
symptoms we have already collected.
it seems that you really don't like my quick fix :o)) OK, then
forget it, and try this instead:
# diff res/res_fax.c.orig res/res_fax.c
2963a2964
struct ast_frame *tmpframe = ast_null_frame;
3117a3119,3131
if (f-subclass.format.id != AST_FORMAT_SLINEAR) {
if (ast_channel_readtrans(active) (tmpframe
= ast_translate(ast_channel_readtrans(active), f, 0)) == NULL) {
ast_debug(5, frame translation to
slinear failed, v21 detection skipped\n);
return f; // translation unsuccessful,
dont start v21 detection
}
ast_debug(5, frame translated to slinear for
v21 detection\n);
fax_gateway_detect_v21(gateway, chan, peer,
active, tmpframe);
ast_frfree(tmpframe);
return f;
}
This code will translate non-slinear frames to slinear, just before they
are sent to libspandsp for v21detection. With this patch applied, v21
detection is done also for RTP (SIP) alaw/ulaw frames, so maybe SIP/G711
- SIP/T38 gateway will work too. I tested DAHDI - SIP/T38, gateway
works both ways, voice calls too. Is it better now? :o)
--
Michal Rybarik
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] res_fax_spandsp segfaults during fax detection - FIXED?
Hello Michal,
Dear Pavel,
On 01/30/2014 06:55 AM, Pavel Troller wrote:
I probably found what causes random segfaults during fax detection with
spandsp... Many thanks for your contributions and brainstorming about this,
it helped a lot. If you have such issue, please test this possible fix and
let me know...
At res_fax.c, somewhere around line 3070, you'll find (at least for
Asterisk 11)
case AST_FORMAT_ALAW:
case AST_FORMAT_ULAW:
Comment out these two lines, recompile, reload and test.
As I understand the code, by commenting out these lines, we'll just abandon
the frame hook for A/ULAW samples, so we'll never gateway them then... Yes,
it will probabaly stop segfaulting, but as a side-effect, it will stop
gatewaying as well :-). Of course I may be wrong, I just had a little look
there...
I tested this fix before posting to the list, and T38 gatewaying is working
with it, at least in my setup (between DAHDI and SIP). I tested both ways
(SIP-DAHDI, DAHDI-SIP) and fax receipt was successful. Gateway is enabled
in sip.conf, in peer section:
setvar=FAXOPT(t38gateway)=yes,20
OK, but it's really strange, because by omitting these codecs from the switch
the code will return from the audiohook, doing nothing more.
However, it seems that there is really a bug in the hook.
- On line 3130, we are attempting to translate the frames before we write
them to the faxing engine (on line 3141). It's OK.
- BUT: On line 3122, we are calling fax_gateway_detect_v21() with
UNTRANSLATED frames, which is FATAL - this detection can handle only linear
format similarly as real faxing, so we have to translate non-linear formats
(A/ULAW) for it as well! By not doing this, we probably
1) prevent successful detection of V.21, so it doesn't work either
2) In rare cases, crash the whole thing, because the detection code always
tries to read 320 bytes from 160byte buffer (as Michal pointed out below).
Once again, I may be wrong, but I think it's in accordance with all the
symptoms we have already collected.
it seems that you really don't like my quick fix :o)) OK, then forget
it, and try this instead:
It's not that I don't like your quick fix, I would just like to have a regular
solution :-).
# diff res/res_fax.c.orig res/res_fax.c
2963a2964
struct ast_frame *tmpframe = ast_null_frame;
3117a3119,3131
if (f-subclass.format.id != AST_FORMAT_SLINEAR) {
if (ast_channel_readtrans(active) (tmpframe =
ast_translate(ast_channel_readtrans(active), f, 0)) == NULL) {
ast_debug(5, frame translation to slinear
failed, v21 detection skipped\n);
return f; // translation unsuccessful, dont
start v21 detection
}
ast_debug(5, frame translated to slinear for v21
detection\n);
fax_gateway_detect_v21(gateway, chan, peer, active,
tmpframe);
ast_frfree(tmpframe);
return f;
}
Just two small technical notes:
1) It's more common to use diff -u (unified format is more readable)
2) Please prevent your mail client to wrap the lines around, or attach the
patch as a standalone attachment, the way how it's presented in your
e-mail renders it just very hardly usable.
This code will translate non-slinear frames to slinear, just before they
are sent to libspandsp for v21detection. With this patch applied, v21
detection is done also for RTP (SIP) alaw/ulaw frames, so maybe SIP/G711
- SIP/T38 gateway will work too. I tested DAHDI - SIP/T38, gateway
works both ways, voice calls too. Is it better now? :o)
I fully understand the code, but I'm not trained enough in the Asterisk
internals to respond to questions, which immediately appeared in my head:
1) In the original code, the result from fax_gateway_detect_v21() is returned.
Now, you are returning the original frame. I quickly looked at the above
routine and it in turn calls fax_gateway_request_t38() and returns its
result (but not always), and in the fax_gateway_request_t38() function
they are also returning different things according to results of the
program flow. So, is it really safe to do this ? Are you sure, that the
real result is really unneccessary ?
2) Are you sure, that ast_translate() will always allocate a new buffer for
tmpframe ? Is it written somewhere ? Isn't it possible that it will just
reallocate the buffer for the original frame to increase its size and return
its pointer, so by doing ast_frfree() you would just deallocate the same
buffer, thus making big troubles ? You would find it by checking that
tmpframe != f...
As you can see, I'm very careful, or maybe even a bit conservative, with
patching things, unless I really DEEPLY understand, how they are going...
So, I believe, that you really studied the code enough to be sure, that
you can
Re: [asterisk-dev] res_fax_spandsp segfaults during fax detection - FIXED?
Hi folks, I probably found what causes random segfaults during fax detection with spandsp... Many thanks for your contributions and brainstorming about this, it helped a lot. If you have such issue, please test this possible fix and let me know... At res_fax.c, somewhere around line 3070, you'll find (at least for Asterisk 11) case AST_FORMAT_ALAW: case AST_FORMAT_ULAW: Comment out these two lines, recompile, reload and test. These two lines are in framehook code, which is responsible for fax detection for T38gateway. These lines are causing, that ALAW and ULAW audio samples are not transcoded to slinear before they are passed to res_fax_spandsp function spandsp_v21_detect(), and later to libspandsp function modem_connect_tones_rx(). But this libspandsp function doesn't expect ulaw or alaw (8bit) samples, it will read and process samples as they are 16bit slinear. If we received 160 alaw/ulaw samples (typical 20ms frame) from network, each sample is 1 byte long (sorry for my disinformation about this topic in previous email). So res_rtp_asterisk allocated 160bytes in the memory for storing this frame (its data part) and gave us a pointer to this memory. If we pass this pointer to function modem_connect_tones_rx() (its second argument) along with information that 160 samples are stored from this position (its third argument), this function is going to read 320 bytes of memory (160 * 16bit) and analyze, if 1100 Hz fax tone is there. But if we allocated and stored 160 bytes in memory, and we are now reading 320bytes, we will get at least bad data or even a segfault too - it depends on position of these data in the memory, which is quite unpredictable, or one may say - random.. Exactly as these segfaults. Elementary my dear Watson :o)) -- Michal Rybarik -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] res_fax_spandsp segfaults during fax detection - FIXED?
Hi! Hi folks, I probably found what causes random segfaults during fax detection with spandsp... Many thanks for your contributions and brainstorming about this, it helped a lot. If you have such issue, please test this possible fix and let me know... At res_fax.c, somewhere around line 3070, you'll find (at least for Asterisk 11) case AST_FORMAT_ALAW: case AST_FORMAT_ULAW: Comment out these two lines, recompile, reload and test. As I understand the code, by commenting out these lines, we'll just abandon the frame hook for A/ULAW samples, so we'll never gateway them then... Yes, it will probabaly stop segfaulting, but as a side-effect, it will stop gatewaying as well :-). Of course I may be wrong, I just had a little look there... However, it seems that there is really a bug in the hook. - On line 3130, we are attempting to translate the frames before we write them to the faxing engine (on line 3141). It's OK. - BUT: On line 3122, we are calling fax_gateway_detect_v21() with UNTRANSLATED frames, which is FATAL - this detection can handle only linear format similarly as real faxing, so we have to translate non-linear formats (A/ULAW) for it as well! By not doing this, we probably 1) prevent successful detection of V.21, so it doesn't work either 2) In rare cases, crash the whole thing, because the detection code always tries to read 320 bytes from 160byte buffer (as Michal pointed out below). Once again, I may be wrong, but I think it's in accordance with all the symptoms we have already collected. With regards, Pavel These two lines are in framehook code, which is responsible for fax detection for T38gateway. These lines are causing, that ALAW and ULAW audio samples are not transcoded to slinear before they are passed to res_fax_spandsp function spandsp_v21_detect(), and later to libspandsp function modem_connect_tones_rx(). But this libspandsp function doesn't expect ulaw or alaw (8bit) samples, it will read and process samples as they are 16bit slinear. If we received 160 alaw/ulaw samples (typical 20ms frame) from network, each sample is 1 byte long (sorry for my disinformation about this topic in previous email). So res_rtp_asterisk allocated 160bytes in the memory for storing this frame (its data part) and gave us a pointer to this memory. If we pass this pointer to function modem_connect_tones_rx() (its second argument) along with information that 160 samples are stored from this position (its third argument), this function is going to read 320 bytes of memory (160 * 16bit) and analyze, if 1100 Hz fax tone is there. But if we allocated and stored 160 bytes in memory, and we are now reading 320bytes, we will get at least bad data or even a segfault too - it depends on position of these data in the memory, which is quite unpredictable, or one may say - random.. Exactly as these segfaults. Elementary my dear Watson :o)) -- Michal Rybarik -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
