Re: [asterisk-dev] [Code Review] 3349: Implement RFC-3966 TEL URI incoming INVITE
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3349/ --- (Updated March 15, 2014, 1:12 p.m.) Review request for Asterisk Developers, Corey Farrell, lmadensen, Matt Jordan, and wdoekes. Changes --- Implemented remarks from Corey and Jonathan. How to ship it? Bugs: ASTERISK-17179 https://issues.asterisk.org/jira/browse/ASTERISK-17179 Repository: Asterisk Description --- Implements RFC-3966 TEL URI incoming INVITE. See https://issues.asterisk.org/jira/browse/ASTERISK-17179 for a description of the original isssue. I have been patching all versions since Asterisk 1.6. I would like to include the code into the main trunk for version 13. Previously Asterisk was failing with error on incoming IMS call: Nov 13 17:52:05 NOTICE[27459]: chan_sip.c:6973 check_user_full: From address missing 'sip:', using it anyway Nov 13 17:52:05 WARNING[27459]: chan_sip.c:6525 get_destination: Huh? Not a SIP header (tel:0987654321;phone-context=+32987654321)? Reason: tel: protocol was not recognized. Diffs (updated) - /trunk/channels/sip/reqresp_parser.c 410429 /trunk/channels/chan_sip.c 410429 Diff: https://reviewboard.asterisk.org/r/3349/diff/ Testing --- Executed an incoming TEL URI INVITE connection. CLI was present on the display and in the CDR file. No errors on SIP debug output. File Attachments RFC-3966 tel URI patch https://reviewboard.asterisk.org/media/uploaded/files/2014/03/13/cad7a996-88c1-47fe-a2a9-cc6987af3b75__rfc-3966-tel-uri-patch-diff.txt Thanks, Geert Van Pamel -- _ -- 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] 3349: Implement RFC-3966 TEL URI incoming INVITE
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3349/ --- (Updated March 15, 2014, 1:42 p.m.) Review request for Asterisk Developers, Corey Farrell, lmadensen, Matt Jordan, and wdoekes. Changes --- Typing error in error message Bugs: ASTERISK-17179 https://issues.asterisk.org/jira/browse/ASTERISK-17179 Repository: Asterisk Description --- Implements RFC-3966 TEL URI incoming INVITE. See https://issues.asterisk.org/jira/browse/ASTERISK-17179 for a description of the original isssue. I have been patching all versions since Asterisk 1.6. I would like to include the code into the main trunk for version 13. Previously Asterisk was failing with error on incoming IMS call: Nov 13 17:52:05 NOTICE[27459]: chan_sip.c:6973 check_user_full: From address missing 'sip:', using it anyway Nov 13 17:52:05 WARNING[27459]: chan_sip.c:6525 get_destination: Huh? Not a SIP header (tel:0987654321;phone-context=+32987654321)? Reason: tel: protocol was not recognized. Diffs (updated) - /trunk/channels/sip/reqresp_parser.c 410429 /trunk/channels/chan_sip.c 410429 Diff: https://reviewboard.asterisk.org/r/3349/diff/ Testing --- Executed an incoming TEL URI INVITE connection. CLI was present on the display and in the CDR file. No errors on SIP debug output. File Attachments RFC-3966 tel URI patch https://reviewboard.asterisk.org/media/uploaded/files/2014/03/13/cad7a996-88c1-47fe-a2a9-cc6987af3b75__rfc-3966-tel-uri-patch-diff.txt Thanks, Geert Van Pamel -- _ -- 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] 3326: Sorcery: Do not apply the same wizard to an object type twice; Automatically apply sorcery configuration when sorcery is opened.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3326/ --- (Updated March 15, 2014, 5:29 p.m.) Review request for Asterisk Developers. Changes --- One final change. I was having trouble from a test because res_mwi_external was failing to load because ast_sorcery_apply_default() was returning an error. This is because for my test, I had a sorcery.conf that had a res_mwi_external section. The default astdb wizard could not be applied because the object type the wizard was being applied to had already been added to sorcery when the config had been applied. I've adjusted the return type of ast_sorcery_apply_config and ast_sorcery_apply_default to return an enum that indicates more accurately what happened. The return values are backwards compatible with old code that may have been checking for success or failure, but it also now can return more specific values for cases where success and failure are not as well defined. All unit tests still pass. Repository: Asterisk Description --- When performing some realtime tests, I noticed that the AMI command PJSIPShowEndpoints was listing all of my endpoints twice. This is because ast_sorcery_apply_config() was being called twice from res_pjsip code, once when initializing system configuration, and once again when initializing the rest of the configuration data. This patch aims to fix the problem on two fronts: 1) Remove the ast_sorcery_apply_config() calls from the PJSIP code entirely in favor of having sorcery automatically apply configuration for the module when sorcery is opened. This reduces the chance of accidentally attempting to apply the same configuration twice. I also removed the call to ast_sorcery_apply_config from res_mwi_external since it is no longer necessary either. 2) Adjust sorcery_apply_wizard_mapping() not to apply the same wizard to an object type more than once, just in case someone does make the error of calling ast_sorcery_apply_config() multiple times for the same object type. Diffs (updated) - /branches/12/tests/test_sorcery_realtime.c 410625 /branches/12/tests/test_sorcery_astdb.c 410606 /branches/12/tests/test_sorcery.c 410606 /branches/12/res/res_pjsip/pjsip_configuration.c 410606 /branches/12/res/res_pjsip/config_system.c 410606 /branches/12/res/res_mwi_external.c 410606 /branches/12/main/sorcery.c 410606 /branches/12/include/asterisk/sorcery.h 410606 /branches/12/configs/sorcery.conf.sample 410606 Diff: https://reviewboard.asterisk.org/r/3326/diff/ Testing --- My tests of retrieving data from realtime now get the expected objects. I don't have any automated tests to post yet because the realtime testsuite is a work in progress. Thanks, Mark Michelson -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 3349: Implement RFC-3966 TEL URI incoming INVITE
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3349/#review11228 --- /trunk/channels/chan_sip.c https://reviewboard.asterisk.org/r/3349/#comment20860 space between t and + since you are here. /trunk/channels/sip/reqresp_parser.c https://reviewboard.asterisk.org/r/3349/#comment20861 might be worth adding a unit test for this code path. Something like tel:911 - Paul Belanger On March 15, 2014, 12:42 p.m., Geert Van Pamel wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3349/ --- (Updated March 15, 2014, 12:42 p.m.) Review request for Asterisk Developers, Corey Farrell, lmadensen, Matt Jordan, and wdoekes. Bugs: ASTERISK-17179 https://issues.asterisk.org/jira/browse/ASTERISK-17179 Repository: Asterisk Description --- Implements RFC-3966 TEL URI incoming INVITE. See https://issues.asterisk.org/jira/browse/ASTERISK-17179 for a description of the original isssue. I have been patching all versions since Asterisk 1.6. I would like to include the code into the main trunk for version 13. Previously Asterisk was failing with error on incoming IMS call: Nov 13 17:52:05 NOTICE[27459]: chan_sip.c:6973 check_user_full: From address missing 'sip:', using it anyway Nov 13 17:52:05 WARNING[27459]: chan_sip.c:6525 get_destination: Huh? Not a SIP header (tel:0987654321;phone-context=+32987654321)? Reason: tel: protocol was not recognized. Diffs - /trunk/channels/sip/reqresp_parser.c 410429 /trunk/channels/chan_sip.c 410429 Diff: https://reviewboard.asterisk.org/r/3349/diff/ Testing --- Executed an incoming TEL URI INVITE connection. CLI was present on the display and in the CDR file. No errors on SIP debug output. File Attachments RFC-3966 tel URI patch https://reviewboard.asterisk.org/media/uploaded/files/2014/03/13/cad7a996-88c1-47fe-a2a9-cc6987af3b75__rfc-3966-tel-uri-patch-diff.txt Thanks, Geert Van Pamel -- _ -- 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] 3349: Implement RFC-3966 TEL URI incoming INVITE
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3349/#review11227 --- Ship it! One very minor tweak, this looks good. Geert you had asked about how to ship it. The general agreement is we wait atleast 24 hours to commit after Ship It. So if nobody objects by Monday afternoon I will commit this to trunk. I know 24 hours would be this afternoon but this is chan_sip, so I'm giving it longer. /trunk/channels/sip/reqresp_parser.c https://reviewboard.asterisk.org/r/3349/#comment20859 scheme is the input parameter listing acceptable schemes, we don't need to see it here. The other ast_debug included scheme since the problem was a failure to match the uri with any scheme. - Corey Farrell On March 15, 2014, 8:42 a.m., Geert Van Pamel wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3349/ --- (Updated March 15, 2014, 8:42 a.m.) Review request for Asterisk Developers, Corey Farrell, lmadensen, Matt Jordan, and wdoekes. Bugs: ASTERISK-17179 https://issues.asterisk.org/jira/browse/ASTERISK-17179 Repository: Asterisk Description --- Implements RFC-3966 TEL URI incoming INVITE. See https://issues.asterisk.org/jira/browse/ASTERISK-17179 for a description of the original isssue. I have been patching all versions since Asterisk 1.6. I would like to include the code into the main trunk for version 13. Previously Asterisk was failing with error on incoming IMS call: Nov 13 17:52:05 NOTICE[27459]: chan_sip.c:6973 check_user_full: From address missing 'sip:', using it anyway Nov 13 17:52:05 WARNING[27459]: chan_sip.c:6525 get_destination: Huh? Not a SIP header (tel:0987654321;phone-context=+32987654321)? Reason: tel: protocol was not recognized. Diffs - /trunk/channels/sip/reqresp_parser.c 410429 /trunk/channels/chan_sip.c 410429 Diff: https://reviewboard.asterisk.org/r/3349/diff/ Testing --- Executed an incoming TEL URI INVITE connection. CLI was present on the display and in the CDR file. No errors on SIP debug output. File Attachments RFC-3966 tel URI patch https://reviewboard.asterisk.org/media/uploaded/files/2014/03/13/cad7a996-88c1-47fe-a2a9-cc6987af3b75__rfc-3966-tel-uri-patch-diff.txt Thanks, Geert Van Pamel -- _ -- 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] 3362: func_beep: New function for periodic beeps.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3362/ --- Review request for Asterisk Developers. Repository: Asterisk Description --- This commit introduces a new dialplan function, BEEP(). It allows you to enable playing a beep tone at a regular interval into a call. The most common use case for this is to use during call recording to notify and remind the callers that the call is being recorded. A future commit will update the call recording applications in Asterisk to use this automatically if an option is specified for convenience. The implementation makes heavy use of existing Asterisk components. Instead of replicating logic required to load a sound file, transcode it if necessary, and do audio mixing, it makes use of Playback+ChanSpy to accomplish the task. The other important bit of the implementation is how it figures out when to trigger the beep playback. This implementation uses the audiohook API, even though it's not actually touching the audio in any way. It's a convenient way to get a callback and check if it's time to kick off another beep. It would be nice if this was timer event based instead of polling based, but unfortunately I don't see a way to do it that won't interfere with other things. Diffs - /trunk/funcs/func_beep.c PRE-CREATION /trunk/CHANGES 410649 Diff: https://reviewboard.asterisk.org/r/3362/diff/ Testing --- Called the following extension, both letting it run all the way through, as well as hanging up at various points in the middle. [test] exten = 100,1,Answer() same = n,Set(BEEP(5)=on) same = n,Wait(20) same = n,Set(BEEP()=off) same = n,Wait(20) 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
[asterisk-dev] [Code Review] 3363: Testsuite: Pluggable module for testing realtime
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3363/ --- Review request for Asterisk Developers. Repository: testsuite Description --- This introduces a new pluggable module to the Asterisk testsuite intended to assist in testing using realtime storage. The test module sets up an HTTP server on port 8000 and services requests Asterisk makes using its res_config_curl realtime backend. The actual data is stored in memory in python using simple dictionaries and lists. The test module configuration allows for data to be preloaded into python before Asterisk is started so that Asterisk may retrieve realtime data during startup. Once AMI is connected to Asterisk, the realtime test module hands over control to a python module so that the test may be further controlled by the test writer. Along with the module are six realtime tests, each designed to test an operation that Asterisk can attempt. The require operation is not tested since we currently always claim to have the proper items stored in the expected way. There are potential improvements that could be made, such as: * Memoization of HTTP resources served by the test module. * yaml-driven test development beyond the initial population of realtime data. * Potentially allow for the realtime test module to be run stand-alone so that developers can have an easy realtime store to use for testing. None of these are enough to prevent inclusion into the test suite though. Diffs - /asterisk/trunk/tests/tests.yaml 4836 /asterisk/trunk/tests/realtime/update/update.py PRE-CREATION /asterisk/trunk/tests/realtime/update/test-config.yaml PRE-CREATION /asterisk/trunk/tests/realtime/update/configs/ast1/sorcery.conf PRE-CREATION /asterisk/trunk/tests/realtime/update/configs/ast1/extconfig.conf PRE-CREATION /asterisk/trunk/tests/realtime/tests.yaml PRE-CREATION /asterisk/trunk/tests/realtime/store/test-config.yaml PRE-CREATION /asterisk/trunk/tests/realtime/store/store.py PRE-CREATION /asterisk/trunk/tests/realtime/store/configs/ast1/sorcery.conf PRE-CREATION /asterisk/trunk/tests/realtime/store/configs/ast1/extconfig.conf PRE-CREATION /asterisk/trunk/tests/realtime/static/test-config.yaml PRE-CREATION /asterisk/trunk/tests/realtime/static/static.py PRE-CREATION /asterisk/trunk/tests/realtime/static/configs/ast1/modules.conf PRE-CREATION /asterisk/trunk/tests/realtime/static/configs/ast1/extconfig.conf PRE-CREATION /asterisk/trunk/tests/realtime/single/test-config.yaml PRE-CREATION /asterisk/trunk/tests/realtime/single/single.py PRE-CREATION /asterisk/trunk/tests/realtime/single/configs/ast1/sorcery.conf PRE-CREATION /asterisk/trunk/tests/realtime/single/configs/ast1/extconfig.conf PRE-CREATION /asterisk/trunk/tests/realtime/multi/test-config.yaml PRE-CREATION /asterisk/trunk/tests/realtime/multi/multi.py PRE-CREATION /asterisk/trunk/tests/realtime/multi/configs/ast1/sorcery.conf PRE-CREATION /asterisk/trunk/tests/realtime/multi/configs/ast1/extconfig.conf PRE-CREATION /asterisk/trunk/tests/realtime/destroy/test-config.yaml PRE-CREATION /asterisk/trunk/tests/realtime/destroy/destroy.py PRE-CREATION /asterisk/trunk/tests/realtime/destroy/configs/ast1/sorcery.conf PRE-CREATION /asterisk/trunk/tests/realtime/destroy/configs/ast1/extconfig.conf PRE-CREATION /asterisk/trunk/lib/python/asterisk/realtime_test_module.py PRE-CREATION Diff: https://reviewboard.asterisk.org/r/3363/diff/ Testing --- Thanks, Mark Michelson -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 3362: func_beep: New function for periodic beeps.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3362/#review11230 --- So, after talking to pabelanger about it, this could be a bit more generic without a lot of effort. Right now it's hard coded to do a Playback(beep) into the call. It could pretty easily changed to just be a periodic dialplan hook. So you could have: [dialplan_hooks] exten = beep,1,Playback(beep) [something] ; Run the beep hook for this call every 30 seconds exten = foo,1,Set(PERIODIC_HOOK(30,beep@dialplan_hooks) Does that sound better than the current BEEP()? - Russell Bryant On March 15, 2014, 6:15 p.m., Russell Bryant wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3362/ --- (Updated March 15, 2014, 6:15 p.m.) Review request for Asterisk Developers. Repository: Asterisk Description --- This commit introduces a new dialplan function, BEEP(). It allows you to enable playing a beep tone at a regular interval into a call. The most common use case for this is to use during call recording to notify and remind the callers that the call is being recorded. A future commit will update the call recording applications in Asterisk to use this automatically if an option is specified for convenience. The implementation makes heavy use of existing Asterisk components. Instead of replicating logic required to load a sound file, transcode it if necessary, and do audio mixing, it makes use of Playback+ChanSpy to accomplish the task. The other important bit of the implementation is how it figures out when to trigger the beep playback. This implementation uses the audiohook API, even though it's not actually touching the audio in any way. It's a convenient way to get a callback and check if it's time to kick off another beep. It would be nice if this was timer event based instead of polling based, but unfortunately I don't see a way to do it that won't interfere with other things. Diffs - /trunk/funcs/func_beep.c PRE-CREATION /trunk/CHANGES 410649 Diff: https://reviewboard.asterisk.org/r/3362/diff/ Testing --- Called the following extension, both letting it run all the way through, as well as hanging up at various points in the middle. [test] exten = 100,1,Answer() same = n,Set(BEEP(5)=on) same = n,Wait(20) same = n,Set(BEEP()=off) same = n,Wait(20) 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
Re: [asterisk-dev] [Code Review] 3362: func_beep: New function for periodic beeps.
On March 15, 2014, 2:46 p.m., Russell Bryant wrote: So, after talking to pabelanger about it, this could be a bit more generic without a lot of effort. Right now it's hard coded to do a Playback(beep) into the call. It could pretty easily changed to just be a periodic dialplan hook. So you could have: [dialplan_hooks] exten = beep,1,Playback(beep) [something] ; Run the beep hook for this call every 30 seconds exten = foo,1,Set(PERIODIC_HOOK(30,beep@dialplan_hooks) Does that sound better than the current BEEP()? I like the idea. Do you plan to make it so only one PERIODIC_HOOK is allowed per channel or multiple? - Corey --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3362/#review11230 --- On March 15, 2014, 2:15 p.m., Russell Bryant wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3362/ --- (Updated March 15, 2014, 2:15 p.m.) Review request for Asterisk Developers. Repository: Asterisk Description --- This commit introduces a new dialplan function, BEEP(). It allows you to enable playing a beep tone at a regular interval into a call. The most common use case for this is to use during call recording to notify and remind the callers that the call is being recorded. A future commit will update the call recording applications in Asterisk to use this automatically if an option is specified for convenience. The implementation makes heavy use of existing Asterisk components. Instead of replicating logic required to load a sound file, transcode it if necessary, and do audio mixing, it makes use of Playback+ChanSpy to accomplish the task. The other important bit of the implementation is how it figures out when to trigger the beep playback. This implementation uses the audiohook API, even though it's not actually touching the audio in any way. It's a convenient way to get a callback and check if it's time to kick off another beep. It would be nice if this was timer event based instead of polling based, but unfortunately I don't see a way to do it that won't interfere with other things. Diffs - /trunk/funcs/func_beep.c PRE-CREATION /trunk/CHANGES 410649 Diff: https://reviewboard.asterisk.org/r/3362/diff/ Testing --- Called the following extension, both letting it run all the way through, as well as hanging up at various points in the middle. [test] exten = 100,1,Answer() same = n,Set(BEEP(5)=on) same = n,Wait(20) same = n,Set(BEEP()=off) same = n,Wait(20) 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
Re: [asterisk-dev] [Code Review] 3362: func_beep: New function for periodic beeps.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3362/#review11229 --- Some things I found before I saw your comment about making this more generic. /trunk/funcs/func_beep.c https://reviewboard.asterisk.org/r/3362/#comment20862 exten never changes so it should be declared next to CONTEXT_NAME, either another const or calculated by module_load. /trunk/funcs/func_beep.c https://reviewboard.asterisk.org/r/3362/#comment20864 This is essentially a clean looking but inefficient way to do: state = (struct beep_state *)audiohook; Or the more correct method: state = (struct beep_state *)(((char*)audiohook) - offsetof(struct beep_state, audiohook)); I raise this point since more than 99% of the calls to beep_callback will take no action. - Corey Farrell On March 15, 2014, 2:15 p.m., Russell Bryant wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3362/ --- (Updated March 15, 2014, 2:15 p.m.) Review request for Asterisk Developers. Repository: Asterisk Description --- This commit introduces a new dialplan function, BEEP(). It allows you to enable playing a beep tone at a regular interval into a call. The most common use case for this is to use during call recording to notify and remind the callers that the call is being recorded. A future commit will update the call recording applications in Asterisk to use this automatically if an option is specified for convenience. The implementation makes heavy use of existing Asterisk components. Instead of replicating logic required to load a sound file, transcode it if necessary, and do audio mixing, it makes use of Playback+ChanSpy to accomplish the task. The other important bit of the implementation is how it figures out when to trigger the beep playback. This implementation uses the audiohook API, even though it's not actually touching the audio in any way. It's a convenient way to get a callback and check if it's time to kick off another beep. It would be nice if this was timer event based instead of polling based, but unfortunately I don't see a way to do it that won't interfere with other things. Diffs - /trunk/funcs/func_beep.c PRE-CREATION /trunk/CHANGES 410649 Diff: https://reviewboard.asterisk.org/r/3362/diff/ Testing --- Called the following extension, both letting it run all the way through, as well as hanging up at various points in the middle. [test] exten = 100,1,Answer() same = n,Set(BEEP(5)=on) same = n,Wait(20) same = n,Set(BEEP()=off) same = n,Wait(20) 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
Re: [asterisk-dev] [Code Review] 3362: func_beep: New function for periodic beeps.
On March 15, 2014, 6:46 p.m., Russell Bryant wrote: So, after talking to pabelanger about it, this could be a bit more generic without a lot of effort. Right now it's hard coded to do a Playback(beep) into the call. It could pretty easily changed to just be a periodic dialplan hook. So you could have: [dialplan_hooks] exten = beep,1,Playback(beep) [something] ; Run the beep hook for this call every 30 seconds exten = foo,1,Set(PERIODIC_HOOK(30,beep@dialplan_hooks) Does that sound better than the current BEEP()? Corey Farrell wrote: I like the idea. Do you plan to make it so only one PERIODIC_HOOK is allowed per channel or multiple? +1 I've often thought about how to implement something like a tick option on a channel. I _know_ you can do it, but not currently within Asterisk. For me, I can see using it for a conference user before I'm about to kick them. But ya, func_tick is where it is at! - Paul --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3362/#review11230 --- On March 15, 2014, 6:15 p.m., Russell Bryant wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3362/ --- (Updated March 15, 2014, 6:15 p.m.) Review request for Asterisk Developers. Repository: Asterisk Description --- This commit introduces a new dialplan function, BEEP(). It allows you to enable playing a beep tone at a regular interval into a call. The most common use case for this is to use during call recording to notify and remind the callers that the call is being recorded. A future commit will update the call recording applications in Asterisk to use this automatically if an option is specified for convenience. The implementation makes heavy use of existing Asterisk components. Instead of replicating logic required to load a sound file, transcode it if necessary, and do audio mixing, it makes use of Playback+ChanSpy to accomplish the task. The other important bit of the implementation is how it figures out when to trigger the beep playback. This implementation uses the audiohook API, even though it's not actually touching the audio in any way. It's a convenient way to get a callback and check if it's time to kick off another beep. It would be nice if this was timer event based instead of polling based, but unfortunately I don't see a way to do it that won't interfere with other things. Diffs - /trunk/funcs/func_beep.c PRE-CREATION /trunk/CHANGES 410649 Diff: https://reviewboard.asterisk.org/r/3362/diff/ Testing --- Called the following extension, both letting it run all the way through, as well as hanging up at various points in the middle. [test] exten = 100,1,Answer() same = n,Set(BEEP(5)=on) same = n,Wait(20) same = n,Set(BEEP()=off) same = n,Wait(20) 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
Re: [asterisk-dev] [Code Review] 3349: Implement RFC-3966 TEL URI incoming INVITE
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3349/ --- (Updated March 15, 2014, 11:02 p.m.) Review request for Asterisk Developers, Corey Farrell, lmadensen, Matt Jordan, and wdoekes. Changes --- Corrected remarks from Paul and Corey Bugs: ASTERISK-17179 https://issues.asterisk.org/jira/browse/ASTERISK-17179 Repository: Asterisk Description --- Implements RFC-3966 TEL URI incoming INVITE. See https://issues.asterisk.org/jira/browse/ASTERISK-17179 for a description of the original isssue. I have been patching all versions since Asterisk 1.6. I would like to include the code into the main trunk for version 13. Previously Asterisk was failing with error on incoming IMS call: Nov 13 17:52:05 NOTICE[27459]: chan_sip.c:6973 check_user_full: From address missing 'sip:', using it anyway Nov 13 17:52:05 WARNING[27459]: chan_sip.c:6525 get_destination: Huh? Not a SIP header (tel:0987654321;phone-context=+32987654321)? Reason: tel: protocol was not recognized. Diffs (updated) - /trunk/channels/sip/reqresp_parser.c 410429 /trunk/channels/chan_sip.c 410429 Diff: https://reviewboard.asterisk.org/r/3349/diff/ Testing --- Executed an incoming TEL URI INVITE connection. CLI was present on the display and in the CDR file. No errors on SIP debug output. File Attachments RFC-3966 tel URI patch https://reviewboard.asterisk.org/media/uploaded/files/2014/03/13/cad7a996-88c1-47fe-a2a9-cc6987af3b75__rfc-3966-tel-uri-patch-diff.txt Thanks, Geert Van Pamel -- _ -- 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
