Re: [asterisk-dev] [Code Review] 4463: core: Introduce chaos into memory allocations
On March 9, 2015, 1:19 p.m., Corey Farrell wrote: /branches/13/main/utils.c, line 614 https://reviewboard.asterisk.org/r/4463/diff/2/?file=71877#file71877line614 This looks like it should be applied to 11 as well. I'd go so far as to say that bug fixes as a result of this should be a separate review. - Joshua --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4463/#review14613 --- On March 7, 2015, 6:01 a.m., Scott Griepentrog wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4463/ --- (Updated March 7, 2015, 6:01 a.m.) Review request for Asterisk Developers. Repository: Asterisk Description --- Introduce chaotic (random) failures into certain critical operations to force improvements to error handling. This patch introduces the DEBUG_CHAOS random failure mechanism and adds it to memory allocation wrappers in utils.h. To be activated, DEBUG_CHAOS must be enabled in menuselect. The failure rate (1 in X) is controlled by changing the define DEBUG_CHAOS_CHANCES_1IN in utils.h. Diffs - /branches/13/main/xmldoc.c 432613 /branches/13/main/utils.c 432613 /branches/13/main/endpoints.c 432613 /branches/13/main/config.c 432613 /branches/13/main/codec_builtin.c 432613 /branches/13/main/asterisk.c 432613 /branches/13/include/asterisk/utils.h 432613 /branches/13/build_tools/cflags.xml 432613 Diff: https://reviewboard.asterisk.org/r/4463/diff/ Testing --- I'm unable to get Asterisk to actually start with 1 in 100,000 failure rate. Thanks, Scott Griepentrog -- _ -- 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] 4463: core: Introduce chaos into memory allocations
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4463/#review14610 --- Do you plan on other chaotic things? As it is the chaos is really just memory allocation failures, nothing outside the scope of that. - Joshua Colp On March 7, 2015, 6:01 a.m., Scott Griepentrog wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4463/ --- (Updated March 7, 2015, 6:01 a.m.) Review request for Asterisk Developers. Repository: Asterisk Description --- Introduce chaotic (random) failures into certain critical operations to force improvements to error handling. This patch introduces the DEBUG_CHAOS random failure mechanism and adds it to memory allocation wrappers in utils.h. To be activated, DEBUG_CHAOS must be enabled in menuselect. The failure rate (1 in X) is controlled by changing the define DEBUG_CHAOS_CHANCES_1IN in utils.h. Diffs - /branches/13/main/xmldoc.c 432613 /branches/13/main/utils.c 432613 /branches/13/main/endpoints.c 432613 /branches/13/main/config.c 432613 /branches/13/main/codec_builtin.c 432613 /branches/13/main/asterisk.c 432613 /branches/13/include/asterisk/utils.h 432613 /branches/13/build_tools/cflags.xml 432613 Diff: https://reviewboard.asterisk.org/r/4463/diff/ Testing --- I'm unable to get Asterisk to actually start with 1 in 100,000 failure rate. Thanks, Scott Griepentrog -- _ -- 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] 4438: add auto-dtmf mode for pjsip
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4438/ --- (Updated March 9, 2015, 2:12 p.m.) Review request for Asterisk Developers. Changes --- According to Joshua's remarks I made some changes in the following places: - res_pjsip_sdp_rtp.c - get_codecs: Set rtp dtmf mode to AST_RTP_DTMF_MODE_INBAND only if the endpoint dtmf mode is AUTO. - res_pjsip_sdp_rtp.c - set_caps: If the rtp dtmf mode is AST_RTP_DTMF_MODE_RFC_2833 deactivate dsp if it is activated. - dsp.c / dsp.h - Added ast_dsp_get_features function required for the above functionality in order to retrieve current dsp features and deactivate dsp only if no other feature is activated. Bugs: ASTERISK-24706 https://issues.asterisk.org/jira/browse/ASTERISK-24706 Repository: Asterisk Description --- add auto-dtmf mode for pjsip Diffs (updated) - /trunk/res/res_pjsip_session.c 431537 /trunk/res/res_pjsip_sdp_rtp.c 431537 /trunk/res/res_pjsip/pjsip_configuration.c 431537 /trunk/res/res_pjsip.c 431537 /trunk/main/dsp.c 431537 /trunk/include/asterisk/res_pjsip.h 431537 /trunk/include/asterisk/dsp.h 431537 /trunk/channels/chan_pjsip.c 431537 Diff: https://reviewboard.asterisk.org/r/4438/diff/ Testing --- Thanks, yaron nahum -- _ -- 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] 4460: res_pjsip_refer: Fix occasional unexpected BYE sent after receiving a REFER.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4460/#review14611 --- Ship it! Ship It! - Joshua Colp On March 6, 2015, 11:27 p.m., rmudgett wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4460/ --- (Updated March 6, 2015, 11:27 p.m.) Review request for Asterisk Developers. Bugs: ASTERISK-24755 https://issues.asterisk.org/jira/browse/ASTERISK-24755 Repository: Asterisk Description --- A race condition happened between initiating a transfer and requesting that a dialog termination be delayed. Occasionally, the transferrer channels would exit the bridge and hangup before the dialog termination was requested. * Made request dialog termination delay before initiating the transfer action. If the transfer fails then cancel the delayed dialog termination request. Diffs - /branches/13/res/res_pjsip_session.exports.in 432595 /branches/13/res/res_pjsip_session.c 432595 /branches/13/res/res_pjsip_refer.c 432595 /branches/13/include/asterisk/res_pjsip_session.h 432595 Diff: https://reviewboard.asterisk.org/r/4460/diff/ Testing --- The testsuite tests/channels/pjsip/ tests still pass with the patch. Thanks, rmudgett -- _ -- 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] 4463: core: Introduce chaos into memory allocations
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4463/#review14613
---
/branches/13/include/asterisk/utils.h
https://reviewboard.asterisk.org/r/4463/#comment25168
Should protect with #ifndef DEBUG_CHAOS_ALLOC_CHANGE. This way 10 is
the default unless it was already set by command-line CFLAGS.
/branches/13/include/asterisk/utils.h
https://reviewboard.asterisk.org/r/4463/#comment25169
Can we make this:
if (DEBUG_CHAOS_ENABLED (ast_random() % CHANGE == 0)) { \
And above this macro we can have:
#ifndef DEBUG_CHAOS_ENABLED
#define DEBUG_CHAOS_ENABLED 1
#endif
This way it can be overridden with CFLAGS
-DDEBUG_CHAOS_ENABLED=ast_fully_booted to delay chaos until initialization is
completed. Would be nice so we can run tests with chaos against a
correctly/fully initialized system.
/branches/13/main/utils.c
https://reviewboard.asterisk.org/r/4463/#comment25170
This looks like it should be applied to 11 as well.
/branches/13/main/xmldoc.c
https://reviewboard.asterisk.org/r/4463/#comment25171
Applies to 11.
/branches/13/main/xmldoc.c
https://reviewboard.asterisk.org/r/4463/#comment25172
Applies to 11.
- Corey Farrell
On March 7, 2015, 1:01 a.m., Scott Griepentrog wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4463/
---
(Updated March 7, 2015, 1:01 a.m.)
Review request for Asterisk Developers.
Repository: Asterisk
Description
---
Introduce chaotic (random) failures into certain critical operations to force
improvements to error handling.
This patch introduces the DEBUG_CHAOS random failure mechanism and adds it to
memory allocation wrappers in utils.h. To be activated, DEBUG_CHAOS must be
enabled in menuselect.
The failure rate (1 in X) is controlled by changing the define
DEBUG_CHAOS_CHANCES_1IN in utils.h.
Diffs
-
/branches/13/main/xmldoc.c 432613
/branches/13/main/utils.c 432613
/branches/13/main/endpoints.c 432613
/branches/13/main/config.c 432613
/branches/13/main/codec_builtin.c 432613
/branches/13/main/asterisk.c 432613
/branches/13/include/asterisk/utils.h 432613
/branches/13/build_tools/cflags.xml 432613
Diff: https://reviewboard.asterisk.org/r/4463/diff/
Testing
---
I'm unable to get Asterisk to actually start with 1 in 100,000 failure rate.
Thanks,
Scott Griepentrog
--
_
-- 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] 4456: testsuite: res_pjsip - conflicting endpoint identifiers test
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4456/#review14612 --- Ship it! Ship It! - Joshua Colp On March 5, 2015, 11:34 p.m., Kevin Harwell wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4456/ --- (Updated March 5, 2015, 11:34 p.m.) Review request for Asterisk Developers. Bugs: ASTERISK-24840 https://issues.asterisk.org/jira/browse/ASTERISK-24840 Repository: testsuite Description --- It is possible that two or more endpoint identifiers could match against an incoming call. This test makes sure that no matter what order the endpoint identifier modules were loaded priority is given based on the ones specified in the global 'endpoint_identifier_order' option. See more details see https://reviewboard.asterisk.org/r/4455/ Diffs - /asterisk/trunk/tests/channels/pjsip/tests.yaml 6482 /asterisk/trunk/tests/channels/pjsip/endpoint_identify/test-config.yaml PRE-CREATION /asterisk/trunk/tests/channels/pjsip/endpoint_identify/configs/ast2/pjsip.conf PRE-CREATION /asterisk/trunk/tests/channels/pjsip/endpoint_identify/configs/ast2/extensions.conf PRE-CREATION /asterisk/trunk/tests/channels/pjsip/endpoint_identify/configs/ast1/pjsip.conf PRE-CREATION /asterisk/trunk/tests/channels/pjsip/endpoint_identify/configs/ast1/extensions.conf PRE-CREATION Diff: https://reviewboard.asterisk.org/r/4456/diff/ Testing --- Ran the test without the code fix in and it would fail. Patched the code and it passed. Also modified the identify order and re-ran the test and it would fail as expected. 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] 4455: res_pjsip: conflicting endpoint identifiers
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4455/ --- (Updated March 9, 2015, 11:12 a.m.) Status -- This change has been marked as submitted. Review request for Asterisk Developers. Changes --- Committed in revision 432638 Bugs: ASTERISK-24840 https://issues.asterisk.org/jira/browse/ASTERISK-24840 Repository: Asterisk Description --- It's possible to have a scenario that will create a conflict between endpoint identifiers. For instance an incoming call could be identified by two different endpoint identifiers and the one chosen depended upon which identifier module loaded first. This of course causes problems when, for example, the incoming call is expected to be identified by username, but instead is identified by ip. This patch adds a new 'global' option to res_pjsip called 'endpoint_identifier_order'. It is a comma separated list of endpoint identifier names that specifies the order by which identifiers are processed and checked. Diffs - branches/13/res/res_pjsip_endpoint_identifier_user.c 432482 branches/13/res/res_pjsip_endpoint_identifier_ip.c 432482 branches/13/res/res_pjsip_endpoint_identifier_anonymous.c 432482 branches/13/res/res_pjsip/config_global.c 432482 branches/13/res/res_pjsip.c 432482 branches/13/include/asterisk/res_pjsip.h 432482 branches/13/contrib/ast-db-manage/config/versions/45e3f47c6c44_add_pjsip_endpoint_identifier_order.py PRE-CREATION branches/13/configs/samples/pjsip.conf.sample 432482 branches/13/CHANGES 432482 Diff: https://reviewboard.asterisk.org/r/4455/diff/ Testing --- Added a testsuite test: https://reviewboard.asterisk.org/r/4456/ 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
[asterisk-dev] Clustering the Asterisk Database (for fun and profit)
Hey all -
So, this last week I was travelling, and since flights are always a
good time to write some code, I decided to play around with an idea
that had been sitting in the back of my head for a little bit:
clustering the Asterisk Database. I got the notion after looking at
Kamailio's htable implementation, and the clustering that it can do
using SIP DMQ messages. A similar mechanism in Asterisk felt rather
doable, since we have:
(1) the ability to pub/sub internally the state of some object
(2) various clustering engines that make use of that internal pub/sub bus
(3) the ability to PUBLISH state between Asterisk instances
I initially debated whether it was appropriate to do in the AstDB or
in Sorcery (which would be a more generic way of clustering
information). In the end, I decided on the AstDB, for a few reasons:
(1) Local information is already stored in there from a variety of
places, while not everything uses Sorcery
(2) Putting it into Sorcery would make an already complex framework more complex
(3) I suspected it would be easier to 'control' the sharing of
information in the AstDB - which is a specific implementation - than
in a generic DAL like Sorcery
The actual implementation I went with works as follows:
* Any family in the AstDB can be marked as shared using a new
function - DB_SHARED().
- Sharing family 'foo': DB_SHARED(put,global)=foo
- Deleting the shared status of 'foo': DB_SHARED(delete)=foo
* The 'shared' status of a database family is independent of the
actual data stored in the AstDB. Thus you can change whether or not a
family is shared without impacting the underlying data.
* Updating/deleting a key in a shared family causes a Stasis message
to be fired off to consumers letting them know that the key was
updated/deleted. The consumers choose how to send that information to
other Asterisk instances in a cluster. Non-shared families are not
shared (which seems obvious...) - this minimizes the traffic on Stasis
to only the entries that should be propagated.
* Families in the AstDB can be shared in one of two ways - 'global' or 'unique'.
- A 'global' shared family shares the family/key space with all
other Asterisk instances. For example, if in a local Asterisk instance
family 'foo' with key 'bar' has value '1', then a separate Asterisk
instance that publishes state for 'foo/bar' with value '2' will
overwrite the local copy of 'foo/bar'. This is useful when you want
the same data replicated across all Asterisk instances.
- A 'unique' shared family replicates its state across other
Asterisk instances, but does *not* overwrite the local copy of the
families. Instead, remote versions of a particular family/key are
placed into a new family on the local Asterisk instance, determined by
the EID of the remote Asterisk instance. Using the same example, if in
a local Asterisk instance (with EID 11:11) the family 'foo' is shared
with key 'bar' and value '1', and a remote Asterisk instance (with EID
ff:ff) publishes state for 'foo/bar' with value '2', then in the local
Asterisk instance this does not overwrite the local copy. Instead, the
remote key/value pair is stored in 'ff:ff/foo/bar' with value '2'.
Likewise, since the local family 'foo' is shared 'uniquely, on the
remote instance, the local copy is stored in '11:11/foo/bar' with
value '1'. This is useful for families that may have conflicting data
keys that need additional context dependent processing to aggregate,
such as SIP registrations.
Some possible uses:
* Global shared blacklists
[globals]
SHARED_DB(put,global)=blacklist
[default]
exten = add_to_blacklist,1,NoOp()
; bad caller!
same = Set(DB(blacklist/${CALLERID(name)})=)
* Shared SIP registries
[globals]
SHARED_DB(put,unique)=registrar
Or, really, just share any data you want between Asterisk servers. I
suspect there's a lot of interesting ways to use this.
After a bit of tweaking on the return flight, I'm fairly sure the
concept works [1]. Before I go much further on it (that is, make it
actually usable, clean up CLI commands, write a *lot* of tests, finish
up the PJSIP/Corosync/etc. implementations, etc.) - does this sound
like something that would be generally useful? Are the mechanisms for
marking a family as being shared logical? Is there a better way to
handle the different use cases for shared data?
[1] http://svn.asterisk.org/svn/asterisk/team/mjordan/trunk-astdb-cluster/
--
Matthew Jordan
Digium, Inc. | Director of Technology
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com http://asterisk.org
--
_
-- 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] 4463: core: Introduce chaos into memory allocations
On March 9, 2015, 8:19 a.m., Corey Farrell wrote: /branches/13/main/utils.c, line 614 https://reviewboard.asterisk.org/r/4463/diff/2/?file=71877#file71877line614 This looks like it should be applied to 11 as well. Joshua Colp wrote: I'd go so far as to say that bug fixes as a result of this should be a separate review. I'll split out the bug fixes as a separate review. - Scott --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4463/#review14613 --- On March 7, 2015, 12:01 a.m., Scott Griepentrog wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4463/ --- (Updated March 7, 2015, 12:01 a.m.) Review request for Asterisk Developers. Repository: Asterisk Description --- Introduce chaotic (random) failures into certain critical operations to force improvements to error handling. This patch introduces the DEBUG_CHAOS random failure mechanism and adds it to memory allocation wrappers in utils.h. To be activated, DEBUG_CHAOS must be enabled in menuselect. The failure rate (1 in X) is controlled by changing the define DEBUG_CHAOS_CHANCES_1IN in utils.h. Diffs - /branches/13/main/xmldoc.c 432613 /branches/13/main/utils.c 432613 /branches/13/main/endpoints.c 432613 /branches/13/main/config.c 432613 /branches/13/main/codec_builtin.c 432613 /branches/13/main/asterisk.c 432613 /branches/13/include/asterisk/utils.h 432613 /branches/13/build_tools/cflags.xml 432613 Diff: https://reviewboard.asterisk.org/r/4463/diff/ Testing --- I'm unable to get Asterisk to actually start with 1 in 100,000 failure rate. Thanks, Scott Griepentrog -- _ -- 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] [Code Review] 4465: Update the kqueue timing module to conform to current timer API.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4465/ --- Review request for Asterisk Developers. Repository: Asterisk Description --- Update the kqueue timing module to conform to current timer API. This fixes issues with using the kqueue timing source on Asterisk 13 on FreeBSD 10. res_timing_kqueue.c: Remove support for kevent64(). The values used to support Asterisk timers fit within 32bits and so can be handled on all platforms via kevent(). Provide debug logging for, but do not track, unacked events. This matches the behavior of all other timer implementations. Implement continuous mode by triggering and leaving active, a user event. This ensures that the file descriptor for the timer returns immediately from poll(), without placing the load of a high speed timer on the kernel. In kqueue_timer_get_max_rate(), don't overstate the capability of the timer. On some platforms, UINT_MAX is greater than INTPTR_MAX, the largest integer type kqueue supports for timers. In kqueue_timer_get_event(), assume the caller woke up from poll() and just return the mode the timer is currently in. This matches all other timer implementations. Adjust the test code now that unacked events are not tracked. Diffs - /trunk/res/res_timing_kqueue.c 432637 Diff: https://reviewboard.asterisk.org/r/4465/diff/ Testing --- Asterisk 13.2.0 on FreeBSD 10-stable: timing test, pjsip incoming/outgoing calls, voicemail prompts and recordings. All of the above failed without these changes. Thanks, Justin T. Gibbs -- _ -- 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] 4456: testsuite: res_pjsip - conflicting endpoint identifiers test
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4456/ --- (Updated March 9, 2015, 11:47 a.m.) Status -- This change has been marked as submitted. Review request for Asterisk Developers. Changes --- Committed in revision 6499 Bugs: ASTERISK-24840 https://issues.asterisk.org/jira/browse/ASTERISK-24840 Repository: testsuite Description --- It is possible that two or more endpoint identifiers could match against an incoming call. This test makes sure that no matter what order the endpoint identifier modules were loaded priority is given based on the ones specified in the global 'endpoint_identifier_order' option. See more details see https://reviewboard.asterisk.org/r/4455/ Diffs - /asterisk/trunk/tests/channels/pjsip/tests.yaml 6482 /asterisk/trunk/tests/channels/pjsip/endpoint_identify/test-config.yaml PRE-CREATION /asterisk/trunk/tests/channels/pjsip/endpoint_identify/configs/ast2/pjsip.conf PRE-CREATION /asterisk/trunk/tests/channels/pjsip/endpoint_identify/configs/ast2/extensions.conf PRE-CREATION /asterisk/trunk/tests/channels/pjsip/endpoint_identify/configs/ast1/pjsip.conf PRE-CREATION /asterisk/trunk/tests/channels/pjsip/endpoint_identify/configs/ast1/extensions.conf PRE-CREATION Diff: https://reviewboard.asterisk.org/r/4456/diff/ Testing --- Ran the test without the code fix in and it would fail. Patched the code and it passed. Also modified the identify order and re-ran the test and it would fail as expected. 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] 4463: core: Introduce chaos into memory allocations
On March 9, 2015, 7:41 a.m., Joshua Colp wrote: Do you plan on other chaotic things? As it is the chaos is really just memory allocation failures, nothing outside the scope of that. Yes -- the idea is that chaos could be easily inserted into any function that has a specific failure return value. The purpose being to expose extremely uncommon code paths, by introducing a higher chance of execution than practically zero. The memory allocation functions are the easiest and first target for this. However, use of chaos elsewhere could end up being more of a personal development testing feature than something that is checked into the official code. - Scott --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4463/#review14610 --- On March 7, 2015, 12:01 a.m., Scott Griepentrog wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4463/ --- (Updated March 7, 2015, 12:01 a.m.) Review request for Asterisk Developers. Repository: Asterisk Description --- Introduce chaotic (random) failures into certain critical operations to force improvements to error handling. This patch introduces the DEBUG_CHAOS random failure mechanism and adds it to memory allocation wrappers in utils.h. To be activated, DEBUG_CHAOS must be enabled in menuselect. The failure rate (1 in X) is controlled by changing the define DEBUG_CHAOS_CHANCES_1IN in utils.h. Diffs - /branches/13/main/xmldoc.c 432613 /branches/13/main/utils.c 432613 /branches/13/main/endpoints.c 432613 /branches/13/main/config.c 432613 /branches/13/main/codec_builtin.c 432613 /branches/13/main/asterisk.c 432613 /branches/13/include/asterisk/utils.h 432613 /branches/13/build_tools/cflags.xml 432613 Diff: https://reviewboard.asterisk.org/r/4463/diff/ Testing --- I'm unable to get Asterisk to actually start with 1 in 100,000 failure rate. Thanks, Scott Griepentrog -- _ -- 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] [Code Review] 4464: testsuite: Increase timeout for Asterisk shutdown
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4464/ --- Review request for Asterisk Developers. Repository: testsuite Description --- I've run into issues lately in Asterisk 13+ where 5 seconds is not long enough to complete the Asterisk shutdown, causing it to be killed. This results in many false failures with REF_DEBUG enabled. I feel the best way to handle this is to always increase the timeout to 10 seconds. I realize that REF_DEBUG is the reason it's taking longer, but it's also the reason that dozens of these timeouts have been resolved. If needed I can find a way to check for the existance of a refs log and double the timeout if found, but I don't think 10 seconds is an unreasonable. It's tough to tell but I think this issue effects around 30 tests in 13/trunk (approximate number of tests with unstable results). Once this is committed it'll be easier to identify and resolve real shutdown timeouts - where Asterisk wouldn't shutdown no matter how long you wait. Diffs - /asterisk/trunk/lib/python/asterisk/asterisk.py 6482 Diff: https://reviewboard.asterisk.org/r/4464/diff/ Testing --- No more shutdown timeouts from tests capable of graceful shutdown. Thanks, Corey Farrell -- _ -- 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] 4468: Various: bugfixes discovered through use of chaos
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4468/ --- (Updated March 9, 2015, 3:50 p.m.) Review request for Asterisk Developers. Repository: Asterisk Description (updated) --- Using the CHAOS random failure mechanism (https://reviewboard.asterisk.org/r/4463/) I uncovered several possibilities of a crash on null pointer, and one uninitialized variable that allowed ast_random to lock up if used before utils init. Additionally, extra output to determine why Asterisk failed to initialize has been added. Diffs - /branches/13/main/xmldoc.c 432661 /branches/13/main/utils.c 432661 /branches/13/main/endpoints.c 432661 /branches/13/main/config.c 432661 /branches/13/main/codec_builtin.c 432661 /branches/13/main/asterisk.c 432661 Diff: https://reviewboard.asterisk.org/r/4468/diff/ Testing --- Thanks, Scott Griepentrog -- _ -- 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] [IAX] Need for LAGRQ and LAGRP
While browsing some pcap captures of IAX channel, I found many LAGRQ and LAGRP packets (once per 10 seconds for each call). So, I traced LAGRQ and LAGRP use in code and found that it is almost useless; it sets iaxs[fr-callno]-lag which is not used anywhere else. Almost same functionality (calculate lag) can be achieved using PING/PONG. Is it left for RFC-compatability only? Or there something I didn't notice? -- Yousf Ateya, -- This e-mail message is intended only for the use of the intended recipient(s). The information contained therein may be confidential or privileged, and its disclosure or reproduction is strictly prohibited. If you are not the intended recipient, please return it immediately to its sender at the above address and destroy it. -- _ -- 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] [Code Review] 4468: Various: bugfixes discovered through use of chaos
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4468/ --- Review request for Asterisk Developers. Repository: Asterisk Description --- Using the CHAOS random failure mechanism (https://reviewboard.asterisk.org/r/4463/) I uncovered several possibilities of a crash on null pointer, and one uninitialized variable that allowed ast_random to lock up if used before utils init. Diffs - /branches/13/main/xmldoc.c 432661 /branches/13/main/utils.c 432661 /branches/13/main/endpoints.c 432661 /branches/13/main/config.c 432661 /branches/13/main/codec_builtin.c 432661 /branches/13/main/asterisk.c 432661 Diff: https://reviewboard.asterisk.org/r/4468/diff/ Testing --- Thanks, Scott Griepentrog -- _ -- 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] 4460: res_pjsip_refer: Fix occasional unexpected BYE sent after receiving a REFER.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4460/#review14617 --- Ship it! Ship It! - Ashley Sanders On March 6, 2015, 5:27 p.m., rmudgett wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4460/ --- (Updated March 6, 2015, 5:27 p.m.) Review request for Asterisk Developers. Bugs: ASTERISK-24755 https://issues.asterisk.org/jira/browse/ASTERISK-24755 Repository: Asterisk Description --- A race condition happened between initiating a transfer and requesting that a dialog termination be delayed. Occasionally, the transferrer channels would exit the bridge and hangup before the dialog termination was requested. * Made request dialog termination delay before initiating the transfer action. If the transfer fails then cancel the delayed dialog termination request. Diffs - /branches/13/res/res_pjsip_session.exports.in 432595 /branches/13/res/res_pjsip_session.c 432595 /branches/13/res/res_pjsip_refer.c 432595 /branches/13/include/asterisk/res_pjsip_session.h 432595 Diff: https://reviewboard.asterisk.org/r/4460/diff/ Testing --- The testsuite tests/channels/pjsip/ tests still pass with the patch. Thanks, rmudgett -- _ -- 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] [Code Review] 4467: res_pjsip: Fix pjsip.conf type=global object default value handling.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4467/ --- Review request for Asterisk Developers. Bugs: ASTERISK-24807 https://issues.asterisk.org/jira/browse/ASTERISK-24807 Repository: Asterisk Description --- When a type=global section is not defined in pjsip.conf the global defaults are not applied. As a result the mandatory Max-Forwards header is not added to SIP messages for res_pjsip/chan_pjsip. The handling of pjsip.conf type=global objects has several problems: 1) If the global object is missing the defaults are not applied. 2) If the global object is missing the default_outbound_endpoint's default value is not returned by ast_sip_global_default_outbound_endpoint(). 3) Defines are needed so default values only need to be changed in one place. * Added a sorcery instance observer callback to check if there were any type=global sections loaded. If there were more than one then issue an error message. If there were none then apply the global defaults. * Fixed ast_sip_global_default_outbound_endpoint() to return the documented default when no type=global object is defined. * Made defines for the global default values. * Increased the default_useragent[] size because SVN version strings can get lengthy and 128 characters may not be enough. * Fixed an off-nominal code path ref leak in global_alloc() if the string fields fail to initialize. * Eliminated RAII_VAR in get_global_cfg() and ast_sip_global_default_outbound_endpoint(). The changes to res/res_pjsip/pjsip_global_headers.c are for the independent but related global options issue. These changes will be committed separately. res_pjsip: Fixed invalid empty Server and User-Agent SIP headers. Setting pjsip.conf useragent to an empty string results in an empty SIP header being sent. * Made not add an empty SIP header item to the global SIP headers list. Diffs - /branches/13/res/res_pjsip/pjsip_global_headers.c 432661 /branches/13/res/res_pjsip/pjsip_configuration.c 432661 /branches/13/res/res_pjsip/config_global.c 432661 /branches/13/include/asterisk/res_pjsip.h 432661 Diff: https://reviewboard.asterisk.org/r/4467/diff/ Testing --- Ran through the following pjsip.conf type=global permutations: 1) No global object defined. The defaults are applied with the patch and the Max-Forwards header goes out when it did not before. 2) Two global objects defined. An error message is now output complaining of the multiple global objects. 3) One global object defined with custom user_agent value set. The User-Agent and Server headers have the custom value. 4) One global object defined with user_agent value set to an empty string. The User-Agent and Server headers do not go out when they would go out without a value before. Thanks, rmudgett -- _ -- 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] 4463: core: Introduce chaos into memory allocations
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4463/#review14619 --- /branches/13/include/asterisk/utils.h https://reviewboard.asterisk.org/r/4463/#comment25176 DEBUG_CHAOS_ENABLE is misspelled here. - Mark Michelson On March 9, 2015, 8:49 p.m., Scott Griepentrog wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4463/ --- (Updated March 9, 2015, 8:49 p.m.) Review request for Asterisk Developers. Repository: Asterisk Description --- Introduce chaotic (random) failures into certain critical operations to force improvements to error handling. This patch introduces the DEBUG_CHAOS random failure mechanism and adds it to memory allocation wrappers in utils.h. To be activated, DEBUG_CHAOS must be enabled in menuselect. The failure rate (1 in X) is controlled by changing the define DEBUG_CHAOS_CHANCES_1IN in utils.h. Diffs - /branches/13/include/asterisk/utils.h 432661 /branches/13/build_tools/cflags.xml 432661 Diff: https://reviewboard.asterisk.org/r/4463/diff/ Testing --- I'm unable to get Asterisk to actually start with 1 in 100,000 failure rate. Thanks, Scott Griepentrog -- _ -- 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] 4468: Various: bugfixes discovered through use of chaos
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4468/#review14618 --- /branches/13/main/config.c https://reviewboard.asterisk.org/r/4468/#comment25175 Handling the possibility of cloned being NULL is necessary, but the problem with just returning here is that it leaves new in a half-altered state. I think the way to do this is to perform all necessary allocations up front and then perform the necessary changes to new once they have all succeeded. - Mark Michelson On March 9, 2015, 8:50 p.m., Scott Griepentrog wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4468/ --- (Updated March 9, 2015, 8:50 p.m.) Review request for Asterisk Developers. Repository: Asterisk Description --- Using the CHAOS random failure mechanism (https://reviewboard.asterisk.org/r/4463/) I uncovered several possibilities of a crash on null pointer, and one uninitialized variable that allowed ast_random to lock up if used before utils init. Additionally, extra output to determine why Asterisk failed to initialize has been added. Diffs - /branches/13/main/xmldoc.c 432661 /branches/13/main/utils.c 432661 /branches/13/main/endpoints.c 432661 /branches/13/main/config.c 432661 /branches/13/main/codec_builtin.c 432661 /branches/13/main/asterisk.c 432661 Diff: https://reviewboard.asterisk.org/r/4468/diff/ Testing --- Thanks, Scott Griepentrog -- _ -- 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] ARI - Add Support for custom SIP Headers with Originate
Cool, too bad it isn't documented. I'll add it into PHPARI as well. On Mar 8, 2015 6:18 PM, Matthew Jordan mjor...@digium.com wrote: On Sun, Mar 8, 2015 at 10:51 AM, Nir Simionovich nir.simionov...@gmail.com wrote: Ok, I'll have a look into that one. On Sun, Mar 8, 2015 at 1:03 PM, Olle E. Johansson o...@edvina.net wrote: On 08 Mar 2015, at 09:52, Nir Simionovich nir.simionov...@gmail.com wrote: Hi All, So, I've been banging my head against an issue with ARI. While Channel Originate enables you to originate channels, you can't really do a SIPAddHeader type functionality in there. Originally, I was under impression that endpoints/message should be able to give me the functionality I wanted, but it didn't. So, I realized that the functionality I'm looking for doesn't really exist. Question, are we missing a feature here? or is there an alternative method of achieving the same functionality? If you can add channel variables, you can add SIP headers. Look at a dump of the channel after you executed SIPaddheader to figure out how it works. Add two headers, and run dumpchan(). You should be able to do it with just the channel variable SIPADDHEADER, that is: SIPADDHEADER=X-CustomHeader-1: foo SIPADDHEADER=X-CustomHeader-2: bar These can be specified in the /channels operation's JSON body. WIth chan_pjsip, headers are manipulated using a dialplan function, so there shouldn't be any issue there. -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com http://asterisk.org -- _ -- 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 -- _ -- 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] ARI - Add Support for custom SIP Headers with Originate
On 09 Mar 2015, at 08:54, Nir Simionovich nir.simionov...@gmail.com wrote: Cool, too bad it isn't documented. I'll add it into PHPARI as well. I believe that this was one of the reasons we created the support for _VARIABLE and __VARIABLE in Asterisk. The ability to reach over to the new channel from the old channel was required for a number of things we wanted to do. The code is very old and at the time it was seem as a bad hack to use the channel variables for this. The decision was not to expose this part while trying to figure out a better way to do it. It's still around, about ten years later. :-) I have mentioned this a number of times on various mailing lists, so it should be known, even though it is not documented. Make sure that if you add variables not using the dialplan function, you must use high numbers and decrement so the risk of a collision is lower. /O On Mar 8, 2015 6:18 PM, Matthew Jordan mjor...@digium.com wrote: On Sun, Mar 8, 2015 at 10:51 AM, Nir Simionovich nir.simionov...@gmail.com wrote: Ok, I'll have a look into that one. On Sun, Mar 8, 2015 at 1:03 PM, Olle E. Johansson o...@edvina.net wrote: On 08 Mar 2015, at 09:52, Nir Simionovich nir.simionov...@gmail.com wrote: Hi All, So, I've been banging my head against an issue with ARI. While Channel Originate enables you to originate channels, you can't really do a SIPAddHeader type functionality in there. Originally, I was under impression that endpoints/message should be able to give me the functionality I wanted, but it didn't. So, I realized that the functionality I'm looking for doesn't really exist. Question, are we missing a feature here? or is there an alternative method of achieving the same functionality? If you can add channel variables, you can add SIP headers. Look at a dump of the channel after you executed SIPaddheader to figure out how it works. Add two headers, and run dumpchan(). You should be able to do it with just the channel variable SIPADDHEADER, that is: SIPADDHEADER=X-CustomHeader-1: foo SIPADDHEADER=X-CustomHeader-2: bar These can be specified in the /channels operation's JSON body. WIth chan_pjsip, headers are manipulated using a dialplan function, so there shouldn't be any issue there. -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com http://asterisk.org -- _ -- 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 -- _ -- 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 -- _ -- 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] ARI - Add Support for custom SIP Headers with Originate
On 08 Mar 2015, at 17:17, Matthew Jordan mjor...@digium.com wrote: You should be able to do it with just the channel variable SIPADDHEADER, that is: SIPADDHEADER=X-CustomHeader-1: foo SIPADDHEADER=X-CustomHeader-2: bar I think there's a serial number in the name of the variable. /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
