Re: [asterisk-dev] [Regression issue] Garbage RTP data with Asterisk
On 02/08/15 11:24, Hans Petter Selasky wrote: On 02/08/15 08:45, Hans Petter Selasky wrote: On 02/08/15 08:44, Hans Petter Selasky wrote: Hi, From time to time the Asterisk RTP engine outputs some 4-byte ULAW packets (even when the data stream is ALAW), making me believe that the packets don't come from the source channel driver. The content of the packets is constant: 0x02 0x8A 0x02 0x80 These cause pops/clicks at the receiver. How can the source of these packets be found? Is there perhaps a race in Asterisk? Has anyone seen this issue before. I have a very old installation of Asterisk ~v1.6 which does not exhibit this issue. --HPS Forgot to mention: Seen with Asterisk 1.8 and 11 --HPS Hi, Some further investigation reveals that the payload type is 0 instead of 101 for DTMF. The 4 bytes are a DMTF packet and apparently this function has failed: /* Grab the payload that they expect the RFC2833 packet to be received in */ payload = ast_rtp_codecs_payload_code(ast_rtp_instance_get_codecs(instance), 0, AST_RTP_DTMF); --HPS Hi Matthew, Sorry for late reply, there was a problem with my list subscription. What is the DTMF payload code negotiated by both sides? How can I find this out using the asterisk cli? --HPS -- _ -- 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] 4442: chan_sip: Asterisk fails to re-activate an inactive media session when an offer does not contain a=sendrecv
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4442/
---
(Updated Feb. 26, 2015, 11:35 a.m.)
Review request for Asterisk Developers.
Changes
---
Applied the changes as suggested by Mark Michelson; made an adjustment (as
suggested by file and mjordan on #asterisk-dev) to make the origin session id
and version id different for re-invites.
{quote}
(2015-02-26 09:45:12) mjordan: essentially, when you modify a session, you have
to increase the version of the session you are modifying, otherwise we have to
assume that it is a 'stale' (or repeated) offer for an existing session
(2015-02-26 09:45:26) file: which becomes a no-op
(2015-02-26 09:45:46) mjordan: so, in your INVITE request that sends an SDP
that takes the call off hold, the o= line should have the version number
bumped by at least one
{quote}
Bugs: ASTERISK-24824
https://issues.asterisk.org/jira/browse/ASTERISK-24824
Repository: testsuite
Description
---
This test is to ensure that Asterisk correctly applies the direction of the
media stream when a=sendonly|recvonly|inactive|sendrecv is missing from the
offer's SDP. The expected behavior is for Asterisk to apply sendrecv as the
direction of the media stream when no direction attribute is present in an
offer's SDP. According to RFC 4566 (Section 6. SDP Attributes): If none of the
attributes sendonly, recvonly, inactive, and sendrecv is present,
sendrecv SHOULD be assumed as the default for sessions that are not of the
conference type broadcast or H332 [...]
The test scenario:
1. From Phone A, send an offer to Phone B to establish a call
2. From Phone B, send an offer to Phone A to put the call on hold.
3. Observe that the MOH start event occurs.
4. From Phone B, send an offer to Phone A to 'un-hold' the call (ensure that
the direction attribute from the offer's SDP is omitted)
5. Observe that the MOH stop event occurs.
Presently, this test fails for certain versions of Asterisk. From what I can
tell, it is present from (at least) 1.8.21 up to the 11 branch.
***Note*** This is the test. It is only the test. The update to the Asterisk
source is coming soon to a review board near you (well, this review board).
Diffs (updated)
-
./asterisk/trunk/tests/channels/SIP/sip_hold/sipp/phone_B_no_direction.xml
PRE-CREATION
./asterisk/trunk/tests/channels/SIP/sip_hold/sipp/phone_B_media_restrict.xml
6458
./asterisk/trunk/tests/channels/SIP/sip_hold/sipp/phone_B_IP_restrict.xml
6458
./asterisk/trunk/tests/channels/SIP/sip_hold/sipp/phone_B_IP_media_restrict.xml
6458
./asterisk/trunk/tests/channels/SIP/sip_hold/sipp/phone_A_no_direction.xml
PRE-CREATION
./asterisk/trunk/tests/channels/SIP/sip_hold/run-test 6458
Diff: https://reviewboard.asterisk.org/r/4442/diff/
Testing
---
Thanks,
Ashley Sanders
--
_
-- 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] 4445: app_chanspy, channel: fix frame leaks
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4445/ --- (Updated Feb. 26, 2015, 11:06 a.m.) Status -- This change has been marked as submitted. Review request for Asterisk Developers. Changes --- Committed in revision 432362 Bugs: ASTERISK-24828 https://issues.asterisk.org/jira/browse/ASTERISK-24828 Repository: Asterisk Description --- During testing it was noticed that Asterisk was leaking frames. After doing some digging a couple spots where a frame leak could occur were found. This patch plugs those leaks. Diffs - branches/11/main/channel.c 432173 branches/11/apps/app_chanspy.c 432173 Diff: https://reviewboard.asterisk.org/r/4445/diff/ Testing --- After applying the patch testing was done again to make sure the leaks no longer occurred. 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] 4442: chan_sip: Asterisk fails to re-activate an inactive media session when an offer does not contain a=sendrecv
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4442/ --- (Updated Feb. 26, 2015, 11:37 a.m.) Review request for Asterisk Developers. Bugs: ASTERISK-24824 https://issues.asterisk.org/jira/browse/ASTERISK-24824 Repository: testsuite Description (updated) --- This test is to ensure that Asterisk correctly applies the direction of the media stream when a=sendonly|recvonly|inactive|sendrecv is missing from the offer's SDP. The expected behavior is for Asterisk to apply sendrecv as the direction of the media stream when no direction attribute is present in an offer's SDP. According to RFC 4566 (Section 6. SDP Attributes): If none of the attributes sendonly, recvonly, inactive, and sendrecv is present, sendrecv SHOULD be assumed as the default for sessions that are not of the conference type broadcast or H332 [...] The test scenario: 1. From Phone A, send an offer to Phone B to establish a call 2. From Phone B, send an offer to Phone A to put the call on hold. 3. Observe that the MOH start event occurs. 4. From Phone B, send an offer to Phone A to 'un-hold' the call (ensure that the direction attribute from the offer's SDP is omitted) 5. Observe that the MOH stop event occurs. ***Note*** This is a test. It is only a test. Diffs - ./asterisk/trunk/tests/channels/SIP/sip_hold/sipp/phone_B_no_direction.xml PRE-CREATION ./asterisk/trunk/tests/channels/SIP/sip_hold/sipp/phone_B_media_restrict.xml 6458 ./asterisk/trunk/tests/channels/SIP/sip_hold/sipp/phone_B_IP_restrict.xml 6458 ./asterisk/trunk/tests/channels/SIP/sip_hold/sipp/phone_B_IP_media_restrict.xml 6458 ./asterisk/trunk/tests/channels/SIP/sip_hold/sipp/phone_A_no_direction.xml PRE-CREATION ./asterisk/trunk/tests/channels/SIP/sip_hold/run-test 6458 Diff: https://reviewboard.asterisk.org/r/4442/diff/ Testing --- Thanks, Ashley Sanders -- _ -- 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] 4437: dns: Define a core DNS API with examples.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4437/#review14558 --- mjordan file: for the proposed DNS API, are you envisioning having it act as a facade over a particular library? Or having a separate file/module register to the core? file register file the end result will be the same but it keeps the two boundaries more separate mjordan the only problem I see with that is we'll have yet another loadable module that can't be unloaded file we can either have it as a loadable module, or still an internal file that just registers with the core still mjordan I kind of lack the latter mjordan I doubt we'll be looking to hotswap DNS libraries file I'm not so much looking at hot swapping - just swapping if something nicer comes along mjordan true mjordan You may want to think about adding a unit test enabled API only that allows us to add a test resolver * oej has quit (Quit: Leaving.) mjordan that way you can test out the threading mechanisms/callbacks from unit tests * file nods - Joshua Colp On Feb. 23, 2015, 12:25 a.m., Joshua Colp wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4437/ --- (Updated Feb. 23, 2015, 12:25 a.m.) Review request for Asterisk Developers. Repository: Asterisk Description --- A wiki page is present at: https://wiki.asterisk.org/wiki/display/~jcolp/Asterisk+DNS+API Which details a new DNS API for Asterisk. This exists as a thin wrapper over other resolver libraries. The core part provides a common interface and some additional features, such as NAPTR/SRV parsing and recurring lookups. Examples are provided which cover the common use cases for the API. Some stuff to think about: 1. Does this encompass everything we think a low level API should? 2. Are there any higher level APIs that would be useful to have? 3. Is the usage intuitive and easy? 4. Are there other examples which would help? 5. Do we want resolvers to be actual modules or keep them in-core? 6. Anything else you think of Have at it! Diffs - Diff: https://reviewboard.asterisk.org/r/4437/diff/ Testing --- I've logically run through the API and examples to ensure they provide what is needed for the future, to make them as easy as possible to use, and to ensure higher level APIs can be created. Thanks, Joshua Colp -- _ -- 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] 4437: dns: Define a core DNS API with examples.
On Feb. 26, 2015, 10:46 a.m., Joshua Colp wrote: mjordan file: for the proposed DNS API, are you envisioning having it act as a facade over a particular library? Or having a separate file/module register to the core? file register file the end result will be the same but it keeps the two boundaries more separate mjordan the only problem I see with that is we'll have yet another loadable module that can't be unloaded file we can either have it as a loadable module, or still an internal file that just registers with the core still mjordan I kind of lack the latter mjordan I doubt we'll be looking to hotswap DNS libraries file I'm not so much looking at hot swapping - just swapping if something nicer comes along mjordan true mjordan You may want to think about adding a unit test enabled API only that allows us to add a test resolver * oej has quit (Quit: Leaving.) mjordan that way you can test out the threading mechanisms/callbacks from unit tests * file nods Last night, it was not immediately obvious that you meant, this is intended to be a façade around third-party resolver implementation(s). The way I read it was, I intend for this API to be a thin wrapper around resolver implementations (that I intend to implement). Perhaps it wouldn't be a bad idea to outright state this in the wiki overview section such that no one else gets confused like I apparently was. :p - Ashley --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4437/#review14558 --- On Feb. 22, 2015, 6:25 p.m., Joshua Colp wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4437/ --- (Updated Feb. 22, 2015, 6:25 p.m.) Review request for Asterisk Developers. Repository: Asterisk Description --- A wiki page is present at: https://wiki.asterisk.org/wiki/display/~jcolp/Asterisk+DNS+API Which details a new DNS API for Asterisk. This exists as a thin wrapper over other resolver libraries. The core part provides a common interface and some additional features, such as NAPTR/SRV parsing and recurring lookups. Examples are provided which cover the common use cases for the API. Some stuff to think about: 1. Does this encompass everything we think a low level API should? 2. Are there any higher level APIs that would be useful to have? 3. Is the usage intuitive and easy? 4. Are there other examples which would help? 5. Do we want resolvers to be actual modules or keep them in-core? 6. Anything else you think of Have at it! Diffs - Diff: https://reviewboard.asterisk.org/r/4437/diff/ Testing --- I've logically run through the API and examples to ensure they provide what is needed for the future, to make them as easy as possible to use, and to ensure higher level APIs can be created. Thanks, Joshua Colp -- _ -- 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] 4443: dial api: add self destruction option
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4443/ --- (Updated Feb. 26, 2015, 12:53 p.m.) Status -- This change has been marked as submitted. Review request for Asterisk Developers. Changes --- Committed in revision 432385 Repository: Asterisk Description --- This adds a self-destruction ability to the dial api. The usefulness of this is mostly when using async mode to spawn a separate thread to handle the new call, while the calling thread is allowed to go on about other business. The alternative of this option is that the calling thread must either hang around for the duration or spawn it's own thread in order to create and then later destroy the dial structure after the call completes. Example (minus error checking): struct ast_dial *dial = ast_dial_create(); ast_dial_append(dial, PJSIP, 200, NULL); ast_dial_option_global_enable(dial, AST_DIAL_OPTION_ANSWER_EXEC, Echo); ast_dial_option_global_enable(dial, AST_DIAL_OPTION_SELF_DESTROY, NULL); ast_dial_run(dial, NULL, 1); The dial_run call returns almost immediately after spawning a new thread to complete and monitor the dial. If the call is answered, it is put into echo. When completed, ast_dial_destroy() will be called on the dial structure. Note that any allocations made to pass values to ast_dial_set_user_data() or other dial options will need to be free'd in a state callback function on any of AST_DIAL_RESULT_UNASWERED, AST_DIAL_RESULT_ANSWERED, AST_DIAL_RESULT_HANGUP, or AST_DIAL_RESULT_TIMEOUT. Diffs - /branches/13/main/dial.c 432173 /branches/13/include/asterisk/dial.h 432173 Diff: https://reviewboard.asterisk.org/r/4443/diff/ Testing --- Correct operation confirmed with a temporary test function running under valgrind to insure there are no invalid references or leaks. 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] How to catch the source of a deadlock?
Asterisk loaded the default timing modules (timerfd and pthreaf), but only
res_timing_timerfd is used.
On Tue, Jan 27, 2015 at 7:45 PM, Matthew Jordan mjor...@digium.com wrote:
On Tue, Jan 27, 2015 at 11:04 AM, Yousf Ateya y.at...@starkbits.com
wrote:
Yes, and I supplied the debug logs in the issue ASTERISK-24478 . I was
trying to find a solution to this bug.
What I am doing now is to run asterisk in debugger (gdb); but it prints
TONs of debug message.
That is why I am looking fot any way to catch the cause of dead locks.
I don't think you actually have a deadlock here.
First, the DETECT_DEADLOCKS option is going to spam you. I'd expect
that when it finds something holding onto a lock for a long period of
time, which is what your debug log shows. That being said, the
DETECT_DEADLOCKS option - once it starts telling you something - isn't
all that useful. Generally, I'd just run with DEBUG_THREADS when
debugging these kinds of things.
Looking at your 'core show locks' output, you don't actually have
circular waiting. You have a thread that is holding onto an IAX call
number lock (iaxsl[fr-callno]), and a thread that wants it. However,
the thread holding onto the call number lock isn't waiting for another
lock: it's just holding it in transmit_frame.
Looking at the transmit_frame function:
static int transmit_frame(void *data)
{
struct iax_frame *fr = data;
ast_mutex_lock(iaxsl[fr-callno]);
fr-sentyet = 1;
if (iaxs[fr-callno]) {
send_packet(fr);
}
if (fr-retries 0) {
ast_mutex_unlock(iaxsl[fr-callno]);
/* No retransmit requested */
iax_frame_free(fr);
} else {
/* We need reliable delivery. Schedule a retransmission */
AST_LIST_INSERT_TAIL(frame_queue[fr-callno], fr, list);
fr-retries++;
fr-retrans = iax2_sched_add(sched, fr-retrytime,
attempt_transmit, fr);
ast_mutex_unlock(iaxsl[fr-callno]);
}
return 0;
}
We can see that all paths should be unlocking iaxsl[fr-callno],
assuming we move through the function. My guess is that we're stuck on
iax2_sched_add, but a gdb backtrace would show for sure where that
thread is.
However, I'll say this - when Corey found a similar problem in
ASTERISK-24451, I wasn't able to reproduce the leak in the IAX usage
of the scheduler. So your problem may not be easily solved unless you
can figure out why the scheduler is misbehaving.
As a side note: do you have a timing module loaded?
Matt
--
Matthew Jordan
Digium, Inc. | Engineering Manager
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
--
Yousf Ateya,
StarkBits
www.starkbits.com
--
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
Re: [asterisk-dev] [Code Review] 4451: testsuite: Add DNS server pluggable module.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4451/ --- (Updated Feb. 26, 2015, 6:23 a.m.) Status -- This change has been marked as submitted. Review request for Asterisk Developers. Changes --- Committed in revision 6467 Repository: testsuite Description --- This change adds a pluggable module to the testsuite which runs a DNS server using twisted-names. This is an authoritative DNS server that responds with records which are specified in a Python style zone file or a BIND style zone file. The DNS server lives for the lifetime of the test. This is useful since it removes any reliance on an external DNS server and reduces the work required to test DNS. Diffs - /asterisk/trunk/sample-yaml/dns-server-config.yaml PRE-CREATION /asterisk/trunk/lib/python/asterisk/dns_server.py PRE-CREATION Diff: https://reviewboard.asterisk.org/r/4451/diff/ Testing --- Hacked up a quick test which used the pluggable module to start a DNS server for a domain. Used dig to contact the DNS server and confirm records. Thanks, Joshua Colp -- _ -- 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] DNS Support in Asterisk
On Thu, Feb 12, 2015 at 10:31 AM, Bruce Ferrell bferr...@baywinds.org wrote: I agree... DNSSEC... big deal. DNS cache? what?! Let the system do that and keep the bloat out of asterisk On 02/12/2015 07:37 AM, Olle E. Johansson wrote: There is one version of c-ares in resiprocate as well. C-ares has been in use for a long time and is in use every single day for you as part of most curl installs. I am not sure there is much to do there. Libunbound adds a lot if that is what we want. Why is a cache a good thing? You surely have a caching resolver running on your system, right? DNSsec is a huge deal - and the foundation for a lot of security things coming up. Someone wrote an IETF draft about that and SIP. https://tools.ietf.org/html/draft-johansson-sipcore-dane-sip-00 I got a patch sent to me that implements that in Asterisk with unbound, but haven't gotten time to go through it and test it. /O On 12 Feb 2015, at 16:25, Brad Watkins marqui...@gmail.com wrote: Looking at this, I'm inclined to say that libunbound is the better of the two options in spite of it being somewhat more difficult to consume DNS records than it would be with c-ares. In my estimation a (seemingly?) more-active community and the inclusion of a cache are more important. DNSSEC isn't a huge deal, at least not for me at this time, but is a nice bonus as well. - Brad On Thu, Feb 12, 2015 at 10:01 AM, Joshua Colp jc...@digium.com wrote: Greetings all, I've extended the sections of my wiki page for c-ares[1] and libunbound[2] to include further information about documentation, general usage experience, and other aspects. Personally I lean towards libunbound because it was straight forward to experiment with, supports DNSSEC, and has a cache. Cheers, [1] https://wiki.asterisk.org/wiki/display/~jcolp/DNS+Support+in+Asterisk#DNSSupportinAsterisk-c-ares [2] https://wiki.asterisk.org/wiki/display/~jcolp/DNS+Support+in+Asterisk#DNSSupportinAsterisk-libunbound After reading through the posts to this list, looking at Josh's analysis on the aforementioned wiki pages, and looking at the libraries themselves, I'm inclined to think that both of these are good libraries, would be perfectly acceptable to use in Asterisk, and would be better than our current functionality. There are certainly some finer points for one over the other. In the interest of moving forward, I'm going to propose that we choose libunbound for the following reasons: (1) It does support DNSSEC already, which would obviously be nice to have available. (2) Examples on the website are quite nice, which makes it a bit easier to implement and get going. A hard part of this project is going to be actually using the library in Asterisk, and the more time and energy we can throw at that as opposed to getting the shim between Asterisk and the library working, the better. Keep in mind that Josh's proposed API ( https://wiki.asterisk.org/wiki/display/~jcolp/Asterisk+DNS+API) allows for a resolver library to be changed behind the facade that the rest of Asterisk will use - so if libunbound proves to be a poor choice, we are not stuck with it. Despite my motion for a resolution, if anyone has any objections, please feel free to reply. I don't want to cut off discussion by any means, but I think we're getting close to a point where we could start the implementation of this, and knowing which resolver we're going to use will be important in the next few weeks. Thanks - Matt -- 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
[asterisk-dev] [Code Review] 4452: Testsuite: ARI channel subscription tests
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4452/ --- Review request for Asterisk Developers. Bugs: ASTERISK-24586 https://issues.asterisk.org/jira/browse/ASTERISK-24586 Repository: testsuite Description --- This adds some local and non-local channel subscription tests for ARI. These tests ensure ARI events occur and/or don't occur for the appropriate stasis app(s). Due to the variations and small differences of these, the test-config.yaml descriptions of each is the best way to describe what they do. Four tests have been added under 'tests/rest_api/applications/channel-subscriptions/'. : * originate_to_dialplan/non_local_channels - Similiar to the existing test that this patch modifies as mentioned below. This required modifying pjsua_mod.py to allow more calls. * originate_to_other_stasis_app/local_channels - Creates two websockets, one for for each stasis app. Originates a local channel from AppA where half is sent into AppB and the other half send into the dialplan. * originate_to_other_stasis_app/non_local_channels - Creates two websockets, one for for each stasis app. Originates a PJSIP channel from AppA to a pjsua phone where is is placed into AppB. * originate_to_stasis_app/local_channels Note: The test 'tests/rest_api/applications/subscribe-channel' test has been renamed to 'basic-subscribe' under the same location as the new tests. The following test has been modified to ensure no ARI events are received: * tests/rest_api/channels/originate_to_dialplan Diffs - /asterisk/trunk/tests/rest_api/channels/originate_to_dialplan/test-config.yaml 6475 /asterisk/trunk/tests/rest_api/applications/tests.yaml 6475 /asterisk/trunk/tests/rest_api/applications/subscribe-channel/test-config.yaml 6475 /asterisk/trunk/tests/rest_api/applications/subscribe-channel/subscribe_channel.py 6475 /asterisk/trunk/tests/rest_api/applications/subscribe-channel/configs/ast1/extensions.conf 6475 /asterisk/trunk/tests/rest_api/applications/channel-subscriptions/tests.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/applications/channel-subscriptions/originate_to_stasis_app/tests.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/applications/channel-subscriptions/originate_to_stasis_app/local_channels/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/applications/channel-subscriptions/originate_to_stasis_app/local_channels/configs/ast1/extensions.conf PRE-CREATION /asterisk/trunk/tests/rest_api/applications/channel-subscriptions/originate_to_other_stasis_app/tests.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/applications/channel-subscriptions/originate_to_other_stasis_app/non_local_channels/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/applications/channel-subscriptions/originate_to_other_stasis_app/non_local_channels/run-test PRE-CREATION /asterisk/trunk/tests/rest_api/applications/channel-subscriptions/originate_to_other_stasis_app/non_local_channels/configs/ast1/pjsip.conf PRE-CREATION /asterisk/trunk/tests/rest_api/applications/channel-subscriptions/originate_to_other_stasis_app/non_local_channels/configs/ast1/http.conf PRE-CREATION /asterisk/trunk/tests/rest_api/applications/channel-subscriptions/originate_to_other_stasis_app/local_channels/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/applications/channel-subscriptions/originate_to_other_stasis_app/local_channels/run-test PRE-CREATION /asterisk/trunk/tests/rest_api/applications/channel-subscriptions/originate_to_other_stasis_app/local_channels/configs/ast1/http.conf PRE-CREATION /asterisk/trunk/tests/rest_api/applications/channel-subscriptions/originate_to_other_stasis_app/local_channels/configs/ast1/extensions.conf PRE-CREATION /asterisk/trunk/tests/rest_api/applications/channel-subscriptions/originate_to_dialplan/tests.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/applications/channel-subscriptions/originate_to_dialplan/non_local_channels/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/applications/channel-subscriptions/originate_to_dialplan/non_local_channels/configs/ast1/pjsip.conf PRE-CREATION /asterisk/trunk/tests/rest_api/applications/channel-subscriptions/originate_to_dialplan/non_local_channels/configs/ast1/extensions.conf PRE-CREATION /asterisk/trunk/lib/python/asterisk/pjsua_mod.py 6475 Diff: https://reviewboard.asterisk.org/r/4452/diff/ Testing --- * Executed each test successfully 30+ times. * Changed the code to force a failure to ensure tests properly failed. * Review logs to ensure operation is as expected. Thanks, jbigelow -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com --
