Re: [asterisk-dev] [Code Review] 1392: Fix app_sms regression
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/1392/#review11597 --- Ship it! /trunk/apps/app_sms.c https://reviewboard.asterisk.org/r/1392/#comment21361 This NOTICE could probably be a bit clearer, but that can be cleaned up on commit. - Matt Jordan On Aug. 26, 2011, 10:16 p.m., dwmw2 wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/1392/ --- (Updated Aug. 26, 2011, 10:16 p.m.) Review request for Asterisk Developers. Bugs: ASTERISK-18331 https://issues.asterisk.org/jira/browse/ASTERISK-18331 Repository: Asterisk Description --- Fix two problems with app_sms. Firstly, the 'flags' field on the stack in sms_exec() is uninitialised, causing it to use the wrong protocol in some cases. Secondly, when disconnect supervision is not working or inbanddisconnect=yes is set in chan_dahdi.conf, app_sms was failing to terminate the call after it sent the REL(ease) message and the peer stopped talking to it. This patch fixes the code to handle the 'bad stop bit' message more gracefully in that case, and hang up the call. Diffs - /trunk/apps/app_sms.c 333428 Diff: https://reviewboard.asterisk.org/r/1392/diff/ Testing --- Sending and receiving protocol 1 messages to/from British Telecom over ISDN BRI (with chan_dahdi), both with and without inbanddisconnect=yes. Thanks, dwmw2 -- _ -- 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] cross compile asterisk for openrisc 1200
hello, I want to cross compile asterisk to work on embedded linux running on the openrisc 1200 cpu from opencores.org. I found the cpu is recognized and his name is listed in the cases in configure.sub but after trying to cross compile him in encountered these problems: the configure file stops in ncurses (so I cross compile ncurses and mentioned the directory by using --with-ncurses). after that the configuration stopped in libxml ( so I disabled this feature explicitly using --disable-xmldoc), after this change the configure file complete with success. but after trying to execute make stopped by ascanary.c - ascanary.o and says : utime.h no such file or directory) so I followed the way of a blind and went to this file changed the utime.h by utime.h but the problem still. so after looking deeply and make some test I figure out the problem but I don't know how to fix it: I found that the toolchain after compilation split this manner: the root file or the top directory of the toolchain in my case /opt/openrisc/ under this directory there is a bin, include, lib and the commons directories in all toolchains, but also there are an or32-elf and or32-linux directories. the problems is here: these two directories contain the bin, include, lib and all the directories in the parent one and after comparing between the include of or32-linux and the include of the parent I found that the first one contain most of the headers and files that asterisk use. after changing the ascanary.c by replacing include utime.h by include /opt/openrisc/or32-linux/include/linux/utime.h the make continue but stopped in undeclared function first use in this file and this function is one of sys/types and time.h some other files included in ascanary.c so the conclusion I have made from all this that make and configure can't find these headers and to be aware the checking action for utime.h in configure gives the result no and the same thing with some other one which are not in the include of the parent directory but they are in or32-linux's include. I wonder if someone can help me out from this problem. I used this to configure: ./configure --host=or32-linux CC=or32-linux-gcc CXX=or32-linux-g++ AR=or32-linux-ar AS=or32-linux-as --with-ncurses=/home/ncursess --disable-xmldoc and I tried to used CLAGS='-I /opt/openrisc/or32-linux/include' but no progress. and something else the difference the utils from or32-elf are used to compile bare metal applications for the processor and or32-linux to compile applications for embedded linux. you can find all the information in opencores.org hope you can help me. thank you -- _ -- 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] 3405: Add ast_spinlock capability
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3405/ --- (Updated April 14, 2014, 1:27 p.m.) Review request for Asterisk Developers. Summary (updated) - Add ast_spinlock capability Bugs: ASTERISK-23553 https://issues.asterisk.org/jira/browse/ASTERISK-23553 Repository: Asterisk Description (updated) --- Now ready for prime time... This patch adds support for spinlocks in Asterisk. There are cases in Asterisk where it might be desirable to lock a short critical code section but not incur the context switch and yield penalty of a mutex or rwlock. The primary spinlock implementations execute exclusively in userspace and therefore don't incur those penalties. Spinlocks are NOT meant to be a general replacement for mutexes. They should be used only for protecting short blocks of critical code such as simple compares and assignments. Operations that may block, hold a lock, or cause the thread to give up it's timeslice should NEVER be attempted in a spinlock. 7 implementations were tested on various i366, x86_64, ARM and Sparc platforms running Linux, FreeBSD, OSX and Solaris. The test suite and results can be found here... https://github.com/gtjoseph/spintest Summary... Tested various spinlock implementations. + GCC Atomics gcc_atomics + x86 assembly gas_x86 + ARM assembly gas_arm + Sparc assemblygas_sparc + OSX Atomics osx_atomics + pthreads spinlock pthread_spinlock + pthreads mutexpthread_mutex + pthreads adaptive mutex pthread_mutex_adaptive_np Not all implementations were available on all platforms. For instance, the gas_x86 implementation won't be available on an arm or sparc platform. Each implementation was tested with the same locking scenario which is a short block of compares and assignments representing the most anticipated Asterisk use cases. The test case was run in a tight loop of 25,000,000 iterations executed in parallel by 1..5 simultaneous threads. The test suite was run on the following platforms: + Darwin-OSX-x86_64-2core + FreeBSD-BSD-amd64-4core + FreeBSD-BSD-i386-1core + Linux-CentOS-i686-1core + Linux-Debian-i686-4core + Linux-Debian-x86_64-4core + Linux-Fedora-armv7l-1core + Linux-Fedora-i686-1core + Linux-Fedora-x86_64-12core + Linux-Fedora-x86_64-1core + Linux-Fedora-x86_64-2core + Linux-Fedora-x86_64-4core + Linux-Fedora-x86_64-8core + Linux-Gentoo-sparc64-32core + SunOS-Solaris-i86pc-4core For each platform tested, the real, user and system times were captured in csv form and the final real and system times graphed. Observations: + The GCC Atomics implementation was available on all platforms and generally had the best performance. + The native assembly implementations generally performed on par with the GCC Atomics implementation. + The pthread_spinlock implementation was not available on Darwin but performed well on the other platforms. + The OSX Atomics implementation performed well on Darwin. + The pthread_mutex_adaptive implementation was not available on all platforms and it's performance was noticeably worse on the supported platforms. + The pthread_mutex implementation was available on all platforms but clearly showed the effects of context switching (high sys time) as lock contention grew. Conclusions: + GCC Atomics should be the first implementation choice. + The native assembly implementations should be the second choices. + The pthread_spinlock implementation should be the third choice on non-Darwin platforms. + OSX Atomics should be the third choice on Darwin. + The pthread_mutex_adaptive implementation should be eliminated. + The pthread_mutex implementation should be the implementation of last resort. + If none of the implementations are available, a compilation #error will be raised. Diffs (updated) - branches/12/include/asterisk/spinlock.h PRE-CREATION branches/12/include/asterisk/autoconfig.h.in 412327 branches/12/configure.ac 412327 branches/12/configure UNKNOWN Diff: https://reviewboard.asterisk.org/r/3405/diff/ Testing (updated) --- See above. Thanks, George Joseph -- _ -- 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] 3434: libpri: Make TE-PTP mode respond to MDL TEI check requests.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3434/#review11602 --- /branches/1.4/q921.c https://reviewboard.asterisk.org/r/3434/#comment21369 Given that you now repeat this pattern of memset/init, you should probably just define a macro that memsets the q921_h struct and then calls Q921_INIT itself. - Matt Jordan On April 10, 2014, 3:28 p.m., rmudgett wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3434/ --- (Updated April 10, 2014, 3:28 p.m.) Review request for Asterisk Developers. Bugs: PRI-165 https://issues.asterisk.org/jira/browse/PRI-165 Repository: LibPRI Description --- Some BRI devices in France insist on checking TEI's when in point-to-point mode. If they don't get a response for TEI 0 they drop layer 1 even though libpri keeps trying to bring layer 2 up. * Made q921_mdl_receive() handle TEI check request messages in TE-PTP mode. Had to change q921_mdl_send()/Q921_INIT() because the PTP modes do not setup a link structure specifically for MDL as the PTMP modes do. * Fixed q921_tei_check()/t201_expire() to check TEI's even if the network side doesn't have any assigned. This should make TE's that request the TEI verify procedure (Q.921 Section 5.3.5) happy when the network side doesn't have any TEI's allocated. Diffs - /branches/1.4/q921.c 2317 Diff: https://reviewboard.asterisk.org/r/3434/diff/ Testing --- Setup a BRI connection where the network side is NT-PTMP mode and the CPE side is TE-PTP mode. Also made a temporary change to cause the NT-PTMP side to initiate the TEI check request procedure on start up. Saw that the TE-PTP side responded with the permanently assigned TEI 0. Saw that the NT-PTMP side handled the unknown TEI by removing it. (TEI 0 is unknown by that side.) 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] Asterisk 11.9.0-rc2 Now Available
The Asterisk Development Team has announced the second release candidate of Asterisk 11.9.0. This release candidate is available for immediate download at http://downloads.asterisk.org/pub/telephony/asterisk The release of Asterisk 11.9.0-rc2 resolves several issues reported by the community and would have not been possible without your participation. Thank you! The following are the issues resolved in this release candidate: * --- app_voicemail: fix missing symbol (Closes issue ASTERISK-23559. Reported by Corey Farrell) * --- autoservice: fix reference leak of logger callid. (Closes issue ASTERISK-23616. Reported by ibercom) For a full list of changes in this release candidate, please see the ChangeLog: http://downloads.asterisk.org/pub/telephony/asterisk/ChangeLog-11.9.0-rc2 Thank you for your continued support of Asterisk! -- _ -- 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] Asterisk 12.2.0-rc2 Now Available
The Asterisk Development Team has announced the second release candidate of Asterisk 12.2.0. This release candidate is available for immediate download at http://downloads.asterisk.org/pub/telephony/asterisk The release of Asterisk 12.2.0-rc2 resolves an issue reported by the community and would have not been possible without your participation. Thank you! The following is the issue resolved in this release candidate: * --- autoservice: fix reference leak of logger callid. (Closes issue ASTERISK-23616. Reported by ibercom) For a full list of changes in this release candidate, please see the ChangeLog: http://downloads.asterisk.org/pub/telephony/asterisk/ChangeLog-12.2.0-rc2 Thank you for your continued support of Asterisk! -- _ -- 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] 3444: Testsuite: PJSIP Callee Initiated Nominal Blind Transfers
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3444/ --- Review request for Asterisk Developers. Bugs: ASTERISK-23447 https://issues.asterisk.org/jira/browse/ASTERISK-23447 Repository: testsuite Description --- These three tests involve using PJSIP in order to execute callee initiated blind transfers. Also all three of these tests fail due to the unresolved issues ASTERISK-23501 and ASTERISK-23502. These tests required a few aspects in each test such as the SIPREFERTOHDR, SIPREFERREDBYHDR, SIPTRANSFER, SIPREFERRINGCONTEXT, BLINDTRANSFER Event, TRANSFER_CONTEXT that comes into play in the second iterations, and Referred-By header. MusicOnHOldStart and MusicOnHoldStop were only required for the callee_hold test. The three tests were: 1) Callee initiated transfer with direct media (callee_direct_media) - This consists of direct media being initiated between the endpoints before and after the transfer. 2) Callee initiated transfer with hold (callee_hold) - This consists of a blind transfer that puts the caller on hold before they are transferred. 3) Callee initiated transfer with REFER only (callee_only_refer) - This consists of no hold or media just a basic REFER. Also John Bigelow made changes to the pjsua_mod.py to be able to associate pjsua accounts with a specific pjsua transport. Diffs - ./asterisk/trunk/tests/channels/pjsip/transfers/tests.yaml PRE-CREATION ./asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/tests.yaml PRE-CREATION ./asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/callee_only_refer/transfer.py PRE-CREATION ./asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/callee_only_refer/test-config.yaml PRE-CREATION ./asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/callee_only_refer/configs/ast1/pjsip.conf PRE-CREATION ./asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/callee_only_refer/configs/ast1/extensions.conf PRE-CREATION ./asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/callee_hold/test-config.yaml PRE-CREATION ./asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/callee_hold/sipp/charlie.xml PRE-CREATION ./asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/callee_hold/sipp/bob.xml PRE-CREATION ./asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/callee_hold/sipp/alice.xml PRE-CREATION ./asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/callee_hold/configs/ast1/pjsip.conf PRE-CREATION ./asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/callee_hold/configs/ast1/extensions.conf PRE-CREATION ./asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/callee_direct_media/test-config.yaml PRE-CREATION ./asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/callee_direct_media/sipp/charlie.xml PRE-CREATION ./asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/callee_direct_media/sipp/bob.xml PRE-CREATION ./asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/callee_direct_media/sipp/alice.xml PRE-CREATION ./asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/callee_direct_media/configs/ast1/pjsip.conf PRE-CREATION ./asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/callee_direct_media/configs/ast1/extensions.conf PRE-CREATION ./asterisk/trunk/tests/channels/pjsip/tests.yaml 4957 ./asterisk/trunk/lib/python/asterisk/pjsua_mod.py 4957 Diff: https://reviewboard.asterisk.org/r/3444/diff/ Testing --- Thanks, Scott Emidy -- _ -- 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] 3445: res_pjsip_refer: Channel variable SIPREFERTOHDR not being set during blind transfer
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3445/ --- Review request for Asterisk Developers and Joshua Colp. Bugs: ASTERISK-23502 https://issues.asterisk.org/jira/browse/ASTERISK-23502 Repository: Asterisk Description --- The SIPREFERTOHDR channel variable is not being set on any channel when performing a blind transfer using PJSIP. The 'refer-refer_to' was not being set during a blind transfer. Updated so the 'refer_to' is set to the target uri on a blind transfer. Diffs - branches/12/res/res_pjsip_refer.c 412327 Diff: https://reviewboard.asterisk.org/r/3445/diff/ Testing --- Manually executed a blind transfer and made sure the SIPREFERTOHDR variable contained the sip URI. 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] 3444: Testsuite: PJSIP Callee Initiated Nominal Blind Transfers
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3444/ --- (Updated April 14, 2014, 9:17 p.m.) Review request for Asterisk Developers. Changes --- fixed some spacing errors. Bugs: ASTERISK-23447 https://issues.asterisk.org/jira/browse/ASTERISK-23447 Repository: testsuite Description --- These three tests involve using PJSIP in order to execute callee initiated blind transfers. Also all three of these tests fail due to the unresolved issues ASTERISK-23501 and ASTERISK-23502. These tests required a few aspects in each test such as the SIPREFERTOHDR, SIPREFERREDBYHDR, SIPTRANSFER, SIPREFERRINGCONTEXT, BLINDTRANSFER Event, TRANSFER_CONTEXT that comes into play in the second iterations, and Referred-By header. MusicOnHOldStart and MusicOnHoldStop were only required for the callee_hold test. The three tests were: 1) Callee initiated transfer with direct media (callee_direct_media) - This consists of direct media being initiated between the endpoints before and after the transfer. 2) Callee initiated transfer with hold (callee_hold) - This consists of a blind transfer that puts the caller on hold before they are transferred. 3) Callee initiated transfer with REFER only (callee_only_refer) - This consists of no hold or media just a basic REFER. Also John Bigelow made changes to the pjsua_mod.py to be able to associate pjsua accounts with a specific pjsua transport. Diffs (updated) - ./asterisk/trunk/tests/channels/pjsip/transfers/tests.yaml PRE-CREATION ./asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/tests.yaml PRE-CREATION ./asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/callee_only_refer/transfer.py PRE-CREATION ./asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/callee_only_refer/test-config.yaml PRE-CREATION ./asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/callee_only_refer/configs/ast1/pjsip.conf PRE-CREATION ./asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/callee_only_refer/configs/ast1/extensions.conf PRE-CREATION ./asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/callee_hold/test-config.yaml PRE-CREATION ./asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/callee_hold/sipp/charlie.xml PRE-CREATION ./asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/callee_hold/sipp/bob.xml PRE-CREATION ./asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/callee_hold/sipp/alice.xml PRE-CREATION ./asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/callee_hold/configs/ast1/pjsip.conf PRE-CREATION ./asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/callee_hold/configs/ast1/extensions.conf PRE-CREATION ./asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/callee_direct_media/test-config.yaml PRE-CREATION ./asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/callee_direct_media/sipp/charlie.xml PRE-CREATION ./asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/callee_direct_media/sipp/bob.xml PRE-CREATION ./asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/callee_direct_media/sipp/alice.xml PRE-CREATION ./asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/callee_direct_media/configs/ast1/pjsip.conf PRE-CREATION ./asterisk/trunk/tests/channels/pjsip/transfers/blind_transfer/callee_direct_media/configs/ast1/extensions.conf PRE-CREATION ./asterisk/trunk/tests/channels/pjsip/tests.yaml 4957 ./asterisk/trunk/lib/python/asterisk/pjsua_mod.py 4957 Diff: https://reviewboard.asterisk.org/r/3444/diff/ Testing --- Thanks, Scott Emidy -- _ -- 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] 3446: Parking: Add 'AnnounceChannel' to Park manager action. Change some announcement behavior for Park manager action.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3446/ --- Review request for Asterisk Developers, Matt Jordan and rmudgett. Bugs: ASTERISK-23397 https://issues.asterisk.org/jira/browse/ASTERISK-23397 Repository: Asterisk Description --- r334840 removed announcements from Park manager actions back in 2011 from all of the actively supported Asterisk versions. Asterisk 12 has provided an opportunity to bring this functionality back. TimeoutChannel will now receive announcements under the strict condition that it is in a one to one bridge with Channel (the channel being parked) at the time the Park action was invoked. In this case, TimeoutChannel will be treated more or less entirely as the channel responsible for parking the call instead of just as a return point for when the call times out. Parking behavior in cases where TimeoutChannel isn't directly bridged with Channel remains mostly unchanged. The channel being parked will no longer receive announcements, but it will still be treated as having more or less self-parked. Timeout Channel will still work just as a comeback override at that point (Will be used to dial when the call times out if it's specified). AnnounceChannel field has been added to the Park action. If the AnnounceChannel field is specified and maps to an active channel, a parking announcement listener stasis subscription will be applied to that channel. When Channel is parked, that listener will trip and apply the announcement bridge feature to the AnnounceChannel. Provided that AnnounceChannel is in some kind of bridge that can use features at that point (tested with two party bridges and holding bridges), the AnnounceChannel will receive the parking announcement while staying on the bridge. If AnnounceChannel and TimeoutChannel are the same channel and that channel is bridged with Channel, a safeguard is in place to make sure multiple announcements aren't queued. In that case, AnnounceChannel is just ignored. Diffs - /branches/12/res/parking/res_parking.h 412320 /branches/12/res/parking/parking_manager.c 412320 /branches/12/res/parking/parking_bridge_features.c 412320 Diff: https://reviewboard.asterisk.org/r/3446/diff/ Testing --- Tested Parking with the park action using different parking lot and timeout settings under the following scenarios: ___ Channel: SIP channel in a holding bridge TimeoutChannel: SIP channel in another holding bridge AnnounceChannel: same as TimeoutChannel Results: Timeout Channel received announcements, remained in holding bridge, and was set as the comeback dial channel. Channel gets dialed upon timeout. --- Channel: SIP channel talking to TimeoutChannel TimeoutChannel: SIP channel talking to Channel AnnounceChannel: both unspecified and the same as TimeoutChannel Results: TimeoutChannel received announcements and then hung up... treated as the Parker of the call. Gets dialed after timeout. --- Channel: Local channel in a Holding Bridge TimeoutChannel: SIP channel talking to another, unrelated SIP channel AnnounceChannel: Same as TimeoutChannel Results: TimeoutChannel receives announcements, acts as comeback dial channel. --- Channel: Local channel in a Holding Bridge TimeoutChannel: SIP channel talking to another, unrelated SIP channel AnnounceChannel: Unspecified Results: SIP channel acts as comeback dial channel, but does not receive announcements Thanks, Jonathan Rose -- _ -- 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] 3446: Parking: Add 'AnnounceChannel' to Park manager action. Change some announcement behavior for Park manager action.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3446/ --- (Updated April 14, 2014, 5:08 p.m.) Review request for Asterisk Developers, Matt Jordan and rmudgett. Changes --- Add CHANGES entry. Bugs: ASTERISK-23397 https://issues.asterisk.org/jira/browse/ASTERISK-23397 Repository: Asterisk Description --- r334840 removed announcements from Park manager actions back in 2011 from all of the actively supported Asterisk versions. Asterisk 12 has provided an opportunity to bring this functionality back. TimeoutChannel will now receive announcements under the strict condition that it is in a one to one bridge with Channel (the channel being parked) at the time the Park action was invoked. In this case, TimeoutChannel will be treated more or less entirely as the channel responsible for parking the call instead of just as a return point for when the call times out. Parking behavior in cases where TimeoutChannel isn't directly bridged with Channel remains mostly unchanged. The channel being parked will no longer receive announcements, but it will still be treated as having more or less self-parked. Timeout Channel will still work just as a comeback override at that point (Will be used to dial when the call times out if it's specified). AnnounceChannel field has been added to the Park action. If the AnnounceChannel field is specified and maps to an active channel, a parking announcement listener stasis subscription will be applied to that channel. When Channel is parked, that listener will trip and apply the announcement bridge feature to the AnnounceChannel. Provided that AnnounceChannel is in some kind of bridge that can use features at that point (tested with two party bridges and holding bridges), the AnnounceChannel will receive the parking announcement while staying on the bridge. If AnnounceChannel and TimeoutChannel are the same channel and that channel is bridged with Channel, a safeguard is in place to make sure multiple announcements aren't queued. In that case, AnnounceChannel is just ignored. Diffs (updated) - /branches/12/res/parking/res_parking.h 412320 /branches/12/res/parking/parking_manager.c 412320 /branches/12/res/parking/parking_bridge_features.c 412320 /branches/12/CHANGES 412320 Diff: https://reviewboard.asterisk.org/r/3446/diff/ Testing --- Tested Parking with the park action using different parking lot and timeout settings under the following scenarios: ___ Channel: SIP channel in a holding bridge TimeoutChannel: SIP channel in another holding bridge AnnounceChannel: same as TimeoutChannel Results: Timeout Channel received announcements, remained in holding bridge, and was set as the comeback dial channel. Channel gets dialed upon timeout. --- Channel: SIP channel talking to TimeoutChannel TimeoutChannel: SIP channel talking to Channel AnnounceChannel: both unspecified and the same as TimeoutChannel Results: TimeoutChannel received announcements and then hung up... treated as the Parker of the call. Gets dialed after timeout. --- Channel: Local channel in a Holding Bridge TimeoutChannel: SIP channel talking to another, unrelated SIP channel AnnounceChannel: Same as TimeoutChannel Results: TimeoutChannel receives announcements, acts as comeback dial channel. --- Channel: Local channel in a Holding Bridge TimeoutChannel: SIP channel talking to another, unrelated SIP channel AnnounceChannel: Unspecified Results: SIP channel acts as comeback dial channel, but does not receive announcements Thanks, Jonathan Rose -- _ -- 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] 3424: (mix)monitor: Add options to enable a periodic beep
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3424/ --- (Updated April 14, 2014, 7:51 p.m.) Review request for Asterisk Developers. Changes --- Included changes for adding the option to Monitor() as well (was originally just MixMonitor()) Summary (updated) - (mix)monitor: Add options to enable a periodic beep Repository: Asterisk Description (updated) --- Add an option to enable a periodic beep to be played into a call if it is being recorded. If enabled, it uses the PERIODIC_HOOK() function internally to play the 'beep' prompt into the call at a specified interval. The option is provided for both Monitor() and MixMonitor(). Diffs (updated) - /trunk/res/res_monitor.c 412327 /trunk/include/asterisk/monitor.h 412327 /trunk/include/asterisk/beep.h PRE-CREATION /trunk/funcs/func_periodic_hook.c 412327 /trunk/bridges/bridge_builtin_features.c 412327 /trunk/apps/app_queue.c 412327 /trunk/apps/app_mixmonitor.c 412327 /trunk/CHANGES 412327 Diff: https://reviewboard.asterisk.org/r/3424/diff/ Testing --- exten = 103,1,Answer() same = n,MixMonitor(test.gsm,B(5)) same = n,MusicOnHold() exten = 104,1,Answer() same = n,MixMonitor(test.gsm,B) same = n,MusicOnHold() exten = 105,1,Answer() same = n,MixMonitor(test.gsm,B(3)) same = n,StartMusicOnHold() same = n,Wait(15) same = n,StopMusicOnHold() same = n,StopMixMonitor() same = n,Wait(5) same = n,Hangup() Thanks, Russell Bryant -- _ -- 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
