Re: [asterisk-dev] DTLS setting impacts encryption setting
On 28 Jan 2014, at 21:25, Daniel Pocock dan...@pocock.com.au wrote: This was on -users, but it appears all the DTLS discussion is on -dev so I'm reposting it... If I understand correctly, setting encryption=no means that Asterisk will make outgoing calls without encryption, but will be happy to accept incoming calls regardless of whether the caller wants encryption or not (that is how it has been working for me anyway) If encryption=yes, then Asterisk not only uses encryption for the outgoing calls but it will refuse to accept incoming calls unless they use encryption too. If I have encryption=no dtlsenable=yes the DTLS support works but Asterisk will no longer accept incoming calls using regular RTP/AVP. These messages appear in the console and the call is rejected with code 488: [Jan 28 11:08:42] WARNING[24673][C-0009]: chan_sip.c:10496 process_sdp: Processed DTLS [FALSE] [Jan 28 11:08:42] WARNING[24673][C-0009]: chan_sip.c:10529 process_sdp: We are requesting SRTP for audio, but they responded without it! I realise not everybody would set encryption=no in this situation, I'm simply trying to make it work for all possible callers to the SIP5060.net test numbers at http://www.sip5060.net/test-calls Is this a bug or is there some reason that DTLS-SRTP can't allow the older behavior to continue? That seems to me like a bug. Please file a bug report in the issue tracker. On the same note, I think in the light of the security discussions going on related to pervasive monitoring we need to rethink a lot of the security concepts. Previously I would say that we should not set up TLS connections without being able to verify the certificate. That's no longer the way I think - but we need to clearly separate verified sessions where we can trust the identity of the other part with sessions where we just encrypt without having a verified identity. This will propably affect dialplans and configurations in new ways. We need to encourage more encryption of media and signalling and separate that issue from authentication. Now - my favorite question - what's a secure call? /O -- _ -- 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] DTLS setting impacts encryption setting
On 28 Jan 2014, at 22:53, Joshua Colp jc...@digium.com wrote: On 14-01-28 04:25 PM, Daniel Pocock wrote: This was on -users, but it appears all the DTLS discussion is on -dev so I'm reposting it... If I understand correctly, setting encryption=no means that Asterisk will make outgoing calls without encryption, but will be happy to accept incoming calls regardless of whether the caller wants encryption or not (that is how it has been working for me anyway) What you are referring to is optional encryption which should not be working. The code was originally written with only SDES in mind so it may be possible that the DTLS code isn't taking things into account correctly. Personally I am against optional encryption. Best effort encryption just does not make sense to me. A year ago I would agree with you. Not any more. Encrypt wherever possible. We just need to separate this from secure media. If you really want a confidential call, force encryption. If you really want a call with an authenticated endpoint/user, force strong authentication. For the rest of the calls, if we can encrypt media and/or signalling, just do it. /O -- _ -- 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] [HELP]: Auto-answering calls placed from call files
Pass it via a Local/ channel that does the setup. Think this really belongs on the users list though, not the dev list. Kind Regards, Jaco Kroon On 28/01/2014 18:41, Steve McCann wrote: Hello All, I'm trying to have an automated call to an Aastra SIP phone and have the call auto-answeredby the phone. I know that a SIP call placed to the phone can be auto-answered if a certain SIP header is added to the call. I am able to apply the SIP headers manually and get that working (using SIPAddHeader(Alert-Info: info=alert-autoanswer) in the dialplan, but for call files, I dont seem to be able to edit any of the sip headers - there is only basic customizations allowed to setup the calls. Does anyone know how I could place automated outgoing calls that would have the proper sip headers added to it that would allow the call to be auto-answered? I've also posted this question to the forums here:http://forums.asterisk.org/viewtopic.php?f=1t=89190 Many thanks, Steve http://www.stevemccann.net attachment: jaco.vcf-- _ -- 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
[asterisk-dev] Possible crash-scenario? Asterisk scheduler.
Hi, I've been looking at ASTERISK-22079, and what might have caused it. The comment I added to the bottom of that ticket does not explain the segfault/backtrace that is attached to that ticket, so I have kept digging. Fundamentally, I would like to know what stops a scheduled event from being cancelled while it is already running (eg. if the running event is waiting on a lock)? The problem being that both the thread that cancels the event, and the running event are both likely to call an unref(). Even worse, I believe that it is possible as a result of the above that while a thread is waiting on a lock, the data-structure it is waiting for is unref'ed to the point of being destroyed, so it ends up with a lock on a freed address. To try and explain what I mean, -/-- represent different threads. The following is probably a worst-case scenario: - thread1 started -- scheduler thread started - ao2_obj created (ref = 1) - ast_sched_add() called with ref increment (ref = 2) - locks ao2_obj (ref = 2, locked) -- sched fires event - waiting on lock - ast_sched_del_unref() called (ref = 1) -- sched event gets lock (ref = 1, locked) -- unrefs obj, unlocks and returns 0 to destroy sched. (ref = 0, destroyed) - any operation on ao2_obj is now illegal. Am I missing something obvious? Is there a defence mechanism I am not seeing? Thanks, Steve -- _ -- 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] DTLS setting impacts encryption setting
On 29/01/14 09:36, Olle E. Johansson wrote: On 28 Jan 2014, at 22:53, Joshua Colp jc...@digium.com wrote: On 14-01-28 04:25 PM, Daniel Pocock wrote: This was on -users, but it appears all the DTLS discussion is on -dev so I'm reposting it... If I understand correctly, setting encryption=no means that Asterisk will make outgoing calls without encryption, but will be happy to accept incoming calls regardless of whether the caller wants encryption or not (that is how it has been working for me anyway) What you are referring to is optional encryption which should not be working. The code was originally written with only SDES in mind so it may be possible that the DTLS code isn't taking things into account correctly. Personally I am against optional encryption. Best effort encryption just does not make sense to me. A year ago I would agree with you. Not any more. Encrypt wherever possible. We just need to separate this from secure media. If you really want a confidential call, force encryption. If you really want a call with an authenticated endpoint/user, force strong authentication. For the rest of the calls, if we can encrypt media and/or signalling, just do it. There are a lot of valid issues to discuss about this However, the core thing for me is that the encryption=no setting behaves in a certain way, and DTLS causes that to change. For consistency, I think that in the current major version (Asterisk 11.x) encryption=no should continue to mean optional encryption, based on the expectations of the peer If somebody wants to change that more dramatically (e.g. because they disapprove of opportunistic encryption or want to implement some other criteria) then that would probably be better to change in Asterisk 12.x While it may not be recommended as a normal configuration, I think there are valid use cases, like my test numbers or relaying ZRTP media streams -- _ -- 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] [Code Review] 3155: ConfBridge: Correct prompt playback target
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3155/ --- (Updated Jan. 29, 2014, 8:26 a.m.) Review request for Asterisk Developers. Changes --- Addressed Mark's and Richard's comments. Bugs: PQ-1396 https://issues.asterisk.org/jira/browse/PQ-1396 Repository: Asterisk Description --- Currently, when the first marked user enters the conference that contains waitmarked users, a prompt is played indicating that the user is being placed into the conference. Unfortunately, this prompt is played to the marked user and not the waitmarked users which is not very helpful. This patch changes that behavior to play a prompt stating The conference will now begin to the entire conference after adding and unmuting the waitmarked users since the design of confbridge is not conducive to playing a prompt to a subset of users in a conference in an asynchronous manner. Diffs (updated) - branches/11/configs/confbridge.conf.sample 406774 branches/11/apps/confbridge/include/confbridge.h 406774 branches/11/apps/confbridge/conf_state_multi_marked.c 406774 branches/11/apps/confbridge/conf_config_parser.c 406774 branches/11/apps/app_confbridge.c 406774 Diff: https://reviewboard.asterisk.org/r/3155/diff/ Testing (updated) --- Verified that the prompt is heard by users already in the conference when a marked user enters and that ConfBridge tests pass with modified event expectations. Thanks, opticron -- _ -- 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] [Code Review] 3155: ConfBridge: Correct prompt playback target
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3155/#review10713 --- branches/11/apps/confbridge/conf_state_multi_marked.c https://reviewboard.asterisk.org/r/3155/#comment20214 I don't think this is the right sound file. Whey aren't we playing CONF_SOUND_PLACE_IN_CONF to all of the users? The point of this is that the person being notified that they are being placed into the conference is the marked user, and not all other users who might be waiting. Why would we need a new sound prompt for this when we have one that says You are now being placed into the conference? Note that the documentation for this sound already says when it should be played: ;sound_place_into_conference ; The sound played when someone is placed into the conference ; after waiting for a marked user. Also: this code change should take into account the EMPTY state. Currently, that plays the prompt to the marked user as well, which is wrong. - Matt Jordan On Jan. 29, 2014, 8:26 a.m., opticron wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3155/ --- (Updated Jan. 29, 2014, 8:26 a.m.) Review request for Asterisk Developers. Bugs: PQ-1396 https://issues.asterisk.org/jira/browse/PQ-1396 Repository: Asterisk Description --- Currently, when the first marked user enters the conference that contains waitmarked users, a prompt is played indicating that the user is being placed into the conference. Unfortunately, this prompt is played to the marked user and not the waitmarked users which is not very helpful. This patch changes that behavior to play a prompt stating The conference will now begin to the entire conference after adding and unmuting the waitmarked users since the design of confbridge is not conducive to playing a prompt to a subset of users in a conference in an asynchronous manner. Diffs - branches/11/configs/confbridge.conf.sample 406774 branches/11/apps/confbridge/include/confbridge.h 406774 branches/11/apps/confbridge/conf_state_multi_marked.c 406774 branches/11/apps/confbridge/conf_config_parser.c 406774 branches/11/apps/app_confbridge.c 406774 Diff: https://reviewboard.asterisk.org/r/3155/diff/ Testing --- Verified that the prompt is heard by users already in the conference when a marked user enters and that ConfBridge tests pass with modified event expectations. Thanks, opticron -- _ -- 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] [Code Review] 3051: TestSuite: Add chan_pjsip path support tests
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3051/#review10714 --- Ship it! Ship It! - Matt Jordan On Jan. 21, 2014, 11:21 a.m., opticron wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3051/ --- (Updated Jan. 21, 2014, 11:21 a.m.) Review request for Asterisk Developers. Bugs: ASTERISK-21084 https://issues.asterisk.org/jira/browse/ASTERISK-21084 Repository: testsuite Description --- This adds a test which covers path support for outbound registrations, inbound registrations, and outbound requests following an inbound registration. Diffs - asterisk/trunk/tests/channels/pjsip/registration/inbound/nominal/tests.yaml 4541 asterisk/trunk/tests/channels/pjsip/registration/inbound/nominal/path/test-config.yaml PRE-CREATION asterisk/trunk/tests/channels/pjsip/registration/inbound/nominal/path/sipp/ua1_register.xml PRE-CREATION asterisk/trunk/tests/channels/pjsip/registration/inbound/nominal/path/sipp/ua1_invite_recv.xml PRE-CREATION asterisk/trunk/tests/channels/pjsip/registration/inbound/nominal/path/sipp/registrar.xml PRE-CREATION asterisk/trunk/tests/channels/pjsip/registration/inbound/nominal/path/configs/ast1/pjsip.conf PRE-CREATION asterisk/trunk/tests/channels/pjsip/registration/inbound/nominal/path/configs/ast1/extensions.conf PRE-CREATION Diff: https://reviewboard.asterisk.org/r/3051/diff/ Testing --- Ensured the tests behaved as expected. Thanks, opticron -- _ -- 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] [Code Review] 3148: res_pjsip: Config option to enable PJSIP logger at load time
On Jan. 24, 2014, 12:46 p.m., Paul Belanger wrote: Okay, so I see what you are saying. I just ran the scripts and they are broken. So, with that in mind I think we need two changesets, one that fixes the current alembic migration paths. And the seconds which adds your logic. Lastly, this we need an automate testcase for this, as it is obvious this code was checked in broken from the start. Lastly, this we need an automate testcase for this, as it is obvious this code was checked in broken from the start. That'd be nice, but it's a bit more work than I'm going to sign up for at this point. If someone would like to contribute that as an automated test, however, it would be hugely appreciated. - Matt --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3148/#review10685 --- On Jan. 24, 2014, 11:46 a.m., Kevin Harwell wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3148/ --- (Updated Jan. 24, 2014, 11:46 a.m.) Review request for Asterisk Developers. Bugs: ASTERISK-23038 https://issues.asterisk.org/jira/browse/ASTERISK-23038 Repository: Asterisk Description --- Added a debug configuration option for res_pjsip that when set to yes enables SIP messages to be logged. It is specified under the system type. Also updated the alembic 12.1 script to include this option as well as a few others that were missing. Also updated the _adding_extensions script in order to make the id column on the table a primary key because mysql needed it to be as such. Diffs - branches/12/res/res_pjsip_logger.c 406340 branches/12/res/res_pjsip/config_global.c 406340 branches/12/res/res_pjsip.c 406340 branches/12/include/asterisk/res_pjsip.h 406340 branches/12/contrib/ast-db-manage/config/versions/581a4264e537_adding_extensions.py 406340 branches/12/contrib/ast-db-manage/config/versions/2fc7930b41b3_add_pjsip_endpoint_options_for_12_1.py 406340 branches/12/configs/pjsip.conf.sample 406340 Diff: https://reviewboard.asterisk.org/r/3148/diff/ Testing --- Set the debug option in the pjsip.conf file and observed SIP debug messages on the console. Also, tested the modified alembic scripts against postgres and mysql database servers. Thanks, Kevin Harwell -- _ -- 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] [Code Review] 3151: res_pjsip: PJSUA pluggable module and subscription tests
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3151/ --- (Updated Jan. 29, 2014, 8:31 p.m.) Review request for Asterisk Developers. Changes --- Take care of Matt and Kevin's comments. Repository: testsuite Description --- When creating the changes on https://reviewboard.asterisk.org/r/3150/, I realized that there were no subscription tests in the testsuite for res_pjsip yet. In order to properly test subscriptions, I could not use SIPp, since removing the subscription requires the ability to handle two active transactions, and SIPp chokes when that happens. Since PJSUA is smarter and has python bindings, I decided to use that instead for the tests. In oder to do things the right way(tm), I decided to create a pluggable module for the testsuite that allows for PJSUA transports, accounts, and buddies to be created using yaml. Once all PJSUA accounts are registered, then a specified callback can be called to continue the test. As far as actual tests are concerned, I've added three tests that use the new PJSUA plugin. There are two presence tests that test PIDF and XPIDF, and there is an MWI test. I was forced to use unsolicited MWI for the MWI test since the PJSUA python bindings do not have the ability to convey that an account should subscribe for MWI. Diffs (updated) - /asterisk/trunk/tests/channels/pjsip/tests.yaml 4618 /asterisk/trunk/tests/channels/pjsip/presence_xpidf/test-config.yaml PRE-CREATION /asterisk/trunk/tests/channels/pjsip/presence_xpidf/state_check.py PRE-CREATION /asterisk/trunk/tests/channels/pjsip/presence_xpidf/configs/ast1/pjsip.conf PRE-CREATION /asterisk/trunk/tests/channels/pjsip/presence_xpidf/configs/ast1/modules.conf PRE-CREATION /asterisk/trunk/tests/channels/pjsip/presence_xpidf/configs/ast1/extensions.conf PRE-CREATION /asterisk/trunk/tests/channels/pjsip/presence_pidf/test-config.yaml PRE-CREATION /asterisk/trunk/tests/channels/pjsip/presence_pidf/state_check.py PRE-CREATION /asterisk/trunk/tests/channels/pjsip/presence_pidf/configs/ast1/pjsip.conf PRE-CREATION /asterisk/trunk/tests/channels/pjsip/presence_pidf/configs/ast1/modules.conf PRE-CREATION /asterisk/trunk/tests/channels/pjsip/presence_pidf/configs/ast1/extensions.conf PRE-CREATION /asterisk/trunk/tests/channels/pjsip/mwi/test-config.yaml PRE-CREATION /asterisk/trunk/tests/channels/pjsip/mwi/mwi_check.py PRE-CREATION /asterisk/trunk/tests/channels/pjsip/mwi/configs/ast1/pjsip.conf PRE-CREATION /asterisk/trunk/tests/channels/pjsip/mwi/configs/ast1/modules.conf PRE-CREATION /asterisk/trunk/lib/python/asterisk/pluggable_modules.py 4618 Diff: https://reviewboard.asterisk.org/r/3151/diff/ Testing --- The tests pass. Thanks, Mark Michelson -- _ -- 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] Possible crash-scenario? Asterisk scheduler.
Hi, Thanks for looking at this. On 29 January 2014 16:34, Matthew Jordan mjor...@digium.com wrote: [snip] You'll note that the refcall is only called if ast_sched_del (eventually) returns a valid ID that it deleted. Agreed. In my proposed failure example, ast_sched_del is called first, and is called in many places in chan_sip with an unref function provided. As a result, ast_sched_del will indeed decrease the refcount. The ASTERISK-22079 backtrace refers to a keepalive timer that will be cancelled more often than it is needed in most environments, so this cancel code should execute regularly. In general, chan_sip doesn't let the scheduler re-schedule events itself, which means that if the scheduler fires the event, then only the event callback should un-ref the object (thus consuming the reference of the ao2 object when it was put on the scheduler). If the scheduler doesn't fire the event and the delete call wins the lock contention, then the delete call should unref the object, and the event should never fire. If the scheduler wins, it does not know whether to delete the scheduled job from the queue until execution ends because the re-scheduling is determined by the return value from the event-call. If the event call is blocked waiting for a lock, then there could be plenty of time for ast_sched_del to get called from elsewhere between the start and end of the event execution. The specific example in ASTERISK-22079 might be fixed by checking whether the pvt-keepaliveschedid (variable name is from memory) has changed either side of grabbing the pvt and chan locks in the event. If it has changed, bail. If that change is right, it should also allow for the big #if 0 ..TODO block in the keepalive code to be reactivated. Perhaps I'll try that and put some highly verbose logging in there to indicate what is happening in real life? Thanks again, Steve -- _ -- 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 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
