Re: [asterisk-dev] [Code Review] 4330: Testsuite: Add external bridging tests for Stasis bridge (one channel) interactions
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4330/#review14188 --- /asterisk/trunk/tests/rest_api/external_interaction/ami_bridge/stasis_bridge/tests.yaml <https://reviewboard.asterisk.org/r/4330/#comment24649> The files for this test seem to be missing. - opticron On Jan. 12, 2015, 5:52 p.m., jbigelow wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4330/ > --- > > (Updated Jan. 12, 2015, 5:52 p.m.) > > > Review request for Asterisk Developers, kmoore and Mark Michelson. > > > Bugs: ASTERISK-24610 > https://issues.asterisk.org/jira/browse/ASTERISK-24610 > > > Repository: testsuite > > > Description > --- > > This adds the remaining external bridging tests for Stasis bridge (one > channel) interactions as defined on the StasisStart/StasisEnd Test Plan > (tests 2.2, 2.3, and 2.4) at: > https://wiki.asterisk.org/wiki/pages/viewpage.action?pageId=30279826#StasisStart/StasisEndTestplan-ExternalBridging > > This also renames the test > 'tests/rest_api/external_interaction/ami_bridge/stasis_bridge/' to > 'tests/rest_api/external_interaction/ami_bridge/stasis_bridge/non_stasis_app' > and adds these new tests under > 'tests/rest_api/external_interaction/ami_bridge/stasis_bridge/'. > > > Diffs > - > > /asterisk/trunk/tests/rest_api/external_interaction/ami_bridge/tests.yaml > 6226 > > /asterisk/trunk/tests/rest_api/external_interaction/ami_bridge/stasis_bridge/tests.yaml > PRE-CREATION > > /asterisk/trunk/tests/rest_api/external_interaction/ami_bridge/stasis_bridge/test-config.yaml > 6226 > > /asterisk/trunk/tests/rest_api/external_interaction/ami_bridge/stasis_bridge/same_stasis_app/test-config.yaml > PRE-CREATION > > /asterisk/trunk/tests/rest_api/external_interaction/ami_bridge/stasis_bridge/same_stasis_app/configs/ast1/extensions.conf > PRE-CREATION > > /asterisk/trunk/tests/rest_api/external_interaction/ami_bridge/stasis_bridge/non_stasis_bridge/test-config.yaml > PRE-CREATION > > /asterisk/trunk/tests/rest_api/external_interaction/ami_bridge/stasis_bridge/non_stasis_bridge/configs/ast1/extensions.conf > PRE-CREATION > > /asterisk/trunk/tests/rest_api/external_interaction/ami_bridge/stasis_bridge/different_stasis_app/test-config.yaml > PRE-CREATION > > /asterisk/trunk/tests/rest_api/external_interaction/ami_bridge/stasis_bridge/different_stasis_app/configs/ast1/extensions.conf > PRE-CREATION > > /asterisk/trunk/tests/rest_api/external_interaction/ami_bridge/stasis_bridge/configs/ast1/extensions.conf > 6226 > > Diff: https://reviewboard.asterisk.org/r/4330/diff/ > > > Testing > --- > > * Executed each test in a loop of 100 iterations with no failures. > * Reviewed logs to ensure the tests were executing as expected. > > > Thanks, > > jbigelow > > -- _ -- 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] 4321: Testsuite: Test T.38 negotiation timeout
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4321/ --- (Updated Jan. 9, 2015, 9:01 a.m.) Status -- This change has been marked as submitted. Review request for Asterisk Developers. Changes --- Committed in revision 6213 Repository: testsuite Description --- This test exercises the T.38 negotiation timeout and the options used to configure it. Diffs - asterisk/trunk/tests/fax/sip/tests.yaml 6191 asterisk/trunk/tests/fax/sip/t38_negotiation_timeout/test-config.yaml PRE-CREATION asterisk/trunk/tests/fax/sip/t38_negotiation_timeout/sipp/t38timeout.xml PRE-CREATION asterisk/trunk/tests/fax/sip/t38_negotiation_timeout/configs/ast1/sip.conf PRE-CREATION asterisk/trunk/tests/fax/sip/t38_negotiation_timeout/configs/ast1/res_fax.conf PRE-CREATION asterisk/trunk/tests/fax/sip/t38_negotiation_timeout/configs/ast1/extensions.conf PRE-CREATION Diff: https://reviewboard.asterisk.org/r/4321/diff/ Testing --- Verified that the test performed as expected. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4320: res_fax: Make T.38 negotiation timeout configurable and handle T.38 switch failure
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4320/ --- (Updated Jan. 9, 2015, 8:40 a.m.) Status -- This change has been marked as submitted. Review request for Asterisk Developers. Changes --- Committed in revision 430415 Repository: Asterisk Description --- This change makes the T.38 negotiation timeout configurable via res_fax.conf or the FAXOPT() dialplan function. It was previously hard coded to be 5 seconds. This change also handles T.38 switch failures by aborting the fax since in the case where this can happen, both sides have agreed to switch to T.38 and Asterisk is unable to do so. Diffs - branches/11/res/res_fax.c 430372 branches/11/include/asterisk/res_fax.h 430372 branches/11/configs/res_fax.conf.sample 430372 Diff: https://reviewboard.asterisk.org/r/4320/diff/ Testing --- Manual testing and the test in review 4321. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4311: res_pjsip: make it unloadable
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4311/#review14125 --- branches/13/res/res_pjsip.c <https://reviewboard.asterisk.org/r/4311/#comment24620> The curly brace should remain on its own line. - opticron On Jan. 6, 2015, 3:30 p.m., Kevin Harwell wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4311/ > --- > > (Updated Jan. 6, 2015, 3:30 p.m.) > > > Review request for Asterisk Developers. > > > Bugs: ASTERISK-24485 > https://issues.asterisk.org/jira/browse/ASTERISK-24485 > > > Repository: Asterisk > > > Description > --- > > The res_pjsip module was previously unloadable. With this patch it can now be > unloaded. > > This patch is based off the original patch on the issue by Corey Farrell with > a few modifications. Removed a few changes not required to make the module > unloadable and also fixed a bug that would cause asterisk to crash on > unloading. > > > Diffs > - > > branches/13/res/res_pjsip/pjsip_outbound_auth.c 430244 > branches/13/res/res_pjsip/pjsip_options.c 430244 > branches/13/res/res_pjsip/pjsip_global_headers.c 430244 > branches/13/res/res_pjsip/pjsip_distributor.c 430244 > branches/13/res/res_pjsip/pjsip_configuration.c 430244 > branches/13/res/res_pjsip/location.c 430244 > branches/13/res/res_pjsip/include/res_pjsip_private.h 430244 > branches/13/res/res_pjsip/config_transport.c 430244 > branches/13/res/res_pjsip/config_auth.c 430244 > branches/13/res/res_pjsip.c 430244 > branches/13/main/stasis_message_router.c 430244 > > Diff: https://reviewboard.asterisk.org/r/4311/diff/ > > > Testing > --- > > Made it so res_pjsip was the only pjsip module loaded and then issued an > unload and noted it unloaded successfully (also loaded/unloaded it several > times from the CLI). Also when loaded and with REF_DEBUG enabled issued a > "core stop gracefully" and made sure there were no ref leaks for the module. > > Also tested unloading with other dependent pjsip modules loaded and noted > that the module would not unload (as it should since dependencies are > currently loaded). And then shutdown asterisk and made sure it did not crash > or anything. > > Started asterisk with nominal and off nominal module and pjsip configurations > to make sure things behaved appropriately (no crashes and such) and then > attempted to, or successfully unload the res_pjsip module. Also made sure > Asterisk continued to shutdown without incident. > > > 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] 4267: Testsuite: Add blind transfer tests for Stasis application interaction.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4267/#review14123 --- Ship it! Fix up the missing docstrings before you commit, but otherwise this looks good to go. - opticron On Dec. 30, 2014, 6:15 p.m., jbigelow wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4267/ > --- > > (Updated Dec. 30, 2014, 6:15 p.m.) > > > Review request for Asterisk Developers and Mark Michelson. > > > Bugs: ASTERISK-24581 and ASTERISK-24649 > https://issues.asterisk.org/jira/browse/ASTERISK-24581 > https://issues.asterisk.org/jira/browse/ASTERISK-24649 > > > Repository: testsuite > > > Description > --- > > This adds the remaining blind transfer tests 1.9 & 1.10 as described on the > StasisStart/StasisEnd Test Plan at: > https://wiki.asterisk.org/wiki/pages/viewpage.action?pageId=30279826 > > This additionally updates the existing test 'stasis_bridge_to_non_stasis_app' > (1.8) to verify the StasisEnd events of the channels per the test plan. An > additional (dummy) channel was added for the test to prevent the test from > ending when the channels involved in the test are hung up. This allows the > StasisEnd events of all the other channels to be verified before the test has > ended. The test description has also been updated to include more details > about the test. > > The two new tests use the 'call_transfer.py' module which is a modified copy > of > tests/channels/pjsip/transfers/blind_transfer/caller_refer_only/transfer.py > for these two new tests. The module uses the pjsua python library to place > calls into Asterisk and perform the blind transfer. > > Notes: > * Due to the architecture of pjsua_mod.py, the call_transfer.py module is > used as both a pluggable module and a callback module. With a little more > work the module could be made to handle other common variations (ex. who > places calls, who receives a call, who performs the transfer, handle a > transfer target that is another pjsua endpoint like the original module) with > everything configurable via YAML. I imagine it would be useful for future > tests. Any takers? :) > * The bug ASTERISK-24649 was found during the development of the new tests > here and will likely cause them to fail every so often. > > > Diffs > - > > > /asterisk/trunk/tests/rest_api/external_interaction/blind_transfer/tests.yaml > 6155 > > /asterisk/trunk/tests/rest_api/external_interaction/blind_transfer/stasis_bridge_to_same_stasis_app/test-config.yaml > PRE-CREATION > > /asterisk/trunk/tests/rest_api/external_interaction/blind_transfer/stasis_bridge_to_same_stasis_app/configs/ast1/pjsip.conf > PRE-CREATION > > /asterisk/trunk/tests/rest_api/external_interaction/blind_transfer/stasis_bridge_to_same_stasis_app/configs/ast1/extensions.conf > PRE-CREATION > > /asterisk/trunk/tests/rest_api/external_interaction/blind_transfer/stasis_bridge_to_non_stasis_app/test-config.yaml > 6155 > > /asterisk/trunk/tests/rest_api/external_interaction/blind_transfer/stasis_bridge_to_non_stasis_app/configs/ast1/extensions.conf > 6155 > > /asterisk/trunk/tests/rest_api/external_interaction/blind_transfer/stasis_bridge_to_non_stasis_app/blind_transfer.py > 6155 > > /asterisk/trunk/tests/rest_api/external_interaction/blind_transfer/stasis_bridge_to_different_stasis_app/test-config.yaml > PRE-CREATION > > /asterisk/trunk/tests/rest_api/external_interaction/blind_transfer/stasis_bridge_to_different_stasis_app/configs/ast1/pjsip.conf > PRE-CREATION > > /asterisk/trunk/tests/rest_api/external_interaction/blind_transfer/stasis_bridge_to_different_stasis_app/configs/ast1/extensions.conf > PRE-CREATION > > /asterisk/trunk/tests/rest_api/external_interaction/blind_transfer/call_transfer.py > PRE-CREATION > > Diff: https://reviewboard.asterisk.org/r/4267/diff/ > > > Testing > --- > > * Executed tests multiple times > * Reviewed logs to manually verify StasisStart/StasisEnd events occurred. > > > Thanks, > > jbigelow > > -- _ -- 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] 4272: Testsuite: Verify that bridged channels originated into Stasis and AMI Redirect interoperate properly
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4272/ --- (Updated Jan. 8, 2015, 7:57 a.m.) Status -- This change has been marked as submitted. Review request for Asterisk Developers. Changes --- Committed in revision 6199 Bugs: ASTERISK-24591 https://issues.asterisk.org/jira/browse/ASTERISK-24591 Repository: testsuite Description --- This adds a test to verify that the AMI Redirect action can be used in conjunction with channels that have been originated directly into a Stasis() application and are bridged when the Redirect takes place. Diffs - asterisk/trunk/tests/rest_api/external_interaction/ami_redirect/tests.yaml 6148 asterisk/trunk/tests/rest_api/external_interaction/ami_redirect/stasis_bridge_direct_originate/test-config.yaml PRE-CREATION asterisk/trunk/tests/rest_api/external_interaction/ami_redirect/stasis_bridge_direct_originate/configs/ast1/extensions.conf PRE-CREATION asterisk/trunk/tests/rest_api/external_interaction/ami_redirect/stasis_bridge/test-config.yaml 6148 Diff: https://reviewboard.asterisk.org/r/4272/diff/ Testing --- Verified that the test operated properly when 4271 was applied and failed when it was not applied. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4320: res_fax: Make T.38 negotiation timeout configurable and handle T.38 switch failure
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4320/ --- (Updated Jan. 7, 2015, 7:25 p.m.) Review request for Asterisk Developers. Changes --- Address Richard's comments. Repository: Asterisk Description --- This change makes the T.38 negotiation timeout configurable via res_fax.conf or the FAXOPT() dialplan function. It was previously hard coded to be 5 seconds. This change also handles T.38 switch failures by aborting the fax since in the case where this can happen, both sides have agreed to switch to T.38 and Asterisk is unable to do so. Diffs (updated) - branches/11/res/res_fax.c 430372 branches/11/include/asterisk/res_fax.h 430372 branches/11/configs/res_fax.conf.sample 430372 Diff: https://reviewboard.asterisk.org/r/4320/diff/ Testing --- Manual testing and the test in review 4321. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4320: res_fax: Make T.38 negotiation timeout configurable and handle T.38 switch failure
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4320/ --- (Updated Jan. 7, 2015, 5:29 p.m.) Review request for Asterisk Developers. Changes --- Address Richard's comments. Repository: Asterisk Description --- This change makes the T.38 negotiation timeout configurable via res_fax.conf or the FAXOPT() dialplan function. It was previously hard coded to be 5 seconds. This change also handles T.38 switch failures by aborting the fax since in the case where this can happen, both sides have agreed to switch to T.38 and Asterisk is unable to do so. Diffs (updated) - branches/11/res/res_fax.c 430372 branches/11/include/asterisk/res_fax.h 430372 branches/11/configs/res_fax.conf.sample 430372 Diff: https://reviewboard.asterisk.org/r/4320/diff/ Testing --- Manual testing and the test in review 4321. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4271: ARI: Allow interoperation of ASYNCGOTO and channels originated to Stasis()
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4271/ --- (Updated Jan. 7, 2015, 3:26 p.m.) Status -- This change has been marked as submitted. Review request for Asterisk Developers and Joshua Colp. Changes --- Committed in revision 430355 Bugs: ASTERISK-24591 https://issues.asterisk.org/jira/browse/ASTERISK-24591 Repository: Asterisk Description --- When the AMI Redirect action is used with a channel bridged inside Stasis() and not running a pbx, the channel is hung up instead of proceeding to the desired location in dialplan. This change allows such channels to be Redirected properly by detecting the operation used by Redirect (ASYNCGOTO) and using the code already established for functionality of the ARI channel continue operation. Diffs - branches/13/res/res_stasis.c 429611 Diff: https://reviewboard.asterisk.org/r/4271/diff/ Testing --- Ran the test that found this bug and verified that it passed with the expected events. See review 4272 for the test in question. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4321: Testsuite: Test T.38 negotiation timeout
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4321/ --- (Updated Jan. 7, 2015, 3:21 p.m.) Review request for Asterisk Developers. Changes --- Fix red blobs. Repository: testsuite Description --- This test exercises the T.38 negotiation timeout and the options used to configure it. Diffs (updated) - asterisk/trunk/tests/fax/sip/tests.yaml 6191 asterisk/trunk/tests/fax/sip/t38_negotiation_timeout/test-config.yaml PRE-CREATION asterisk/trunk/tests/fax/sip/t38_negotiation_timeout/sipp/t38timeout.xml PRE-CREATION asterisk/trunk/tests/fax/sip/t38_negotiation_timeout/configs/ast1/sip.conf PRE-CREATION asterisk/trunk/tests/fax/sip/t38_negotiation_timeout/configs/ast1/res_fax.conf PRE-CREATION asterisk/trunk/tests/fax/sip/t38_negotiation_timeout/configs/ast1/extensions.conf PRE-CREATION Diff: https://reviewboard.asterisk.org/r/4321/diff/ Testing --- Verified that the test performed as expected. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] [Code Review] 4321: Testsuite: Test T.38 negotiation timeout
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4321/ --- Review request for Asterisk Developers. Repository: testsuite Description --- This test exercises the T.38 negotiation timeout and the options used to configure it. Diffs - asterisk/trunk/tests/fax/sip/tests.yaml 6191 asterisk/trunk/tests/fax/sip/t38_negotiation_timeout/test-config.yaml PRE-CREATION asterisk/trunk/tests/fax/sip/t38_negotiation_timeout/sipp/t38timeout.xml PRE-CREATION asterisk/trunk/tests/fax/sip/t38_negotiation_timeout/configs/ast1/sip.conf PRE-CREATION asterisk/trunk/tests/fax/sip/t38_negotiation_timeout/configs/ast1/res_fax.conf PRE-CREATION asterisk/trunk/tests/fax/sip/t38_negotiation_timeout/configs/ast1/extensions.conf PRE-CREATION Diff: https://reviewboard.asterisk.org/r/4321/diff/ Testing --- Verified that the test performed as expected. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] [Code Review] 4320: res_fax: Make T.38 negotiation timeout configurable and handle T.38 switch failure
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4320/ --- Review request for Asterisk Developers. Repository: Asterisk Description --- This change makes the T.38 negotiation timeout configurable via res_fax.conf or the FAXOPT() dialplan function. It was previously hard coded to be 5 seconds. This change also handles T.38 switch failures by aborting the fax since in the case where this can happen, both sides have agreed to switch to T.38 and Asterisk is unable to do so. Diffs - branches/11/res/res_fax.c 430338 branches/11/include/asterisk/res_fax.h 430338 branches/11/configs/res_fax.conf.sample 430338 Diff: https://reviewboard.asterisk.org/r/4320/diff/ Testing --- Manual testing and the test in review 4321. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4272: Testsuite: Verify that bridged channels originated into Stasis and AMI Redirect interoperate properly
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4272/ --- (Updated Dec. 29, 2014, 10:17 a.m.) Review request for Asterisk Developers. Changes --- Update test according to Matt's comments and fix a bridge leak in a similar test. Bugs: ASTERISK-24591 https://issues.asterisk.org/jira/browse/ASTERISK-24591 Repository: testsuite Description --- This adds a test to verify that the AMI Redirect action can be used in conjunction with channels that have been originated directly into a Stasis() application and are bridged when the Redirect takes place. Diffs (updated) - asterisk/trunk/tests/rest_api/external_interaction/ami_redirect/tests.yaml 6148 asterisk/trunk/tests/rest_api/external_interaction/ami_redirect/stasis_bridge_direct_originate/test-config.yaml PRE-CREATION asterisk/trunk/tests/rest_api/external_interaction/ami_redirect/stasis_bridge_direct_originate/configs/ast1/extensions.conf PRE-CREATION asterisk/trunk/tests/rest_api/external_interaction/ami_redirect/stasis_bridge/test-config.yaml 6148 Diff: https://reviewboard.asterisk.org/r/4272/diff/ Testing --- Verified that the test operated properly when 4271 was applied and failed when it was not applied. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4264: PJSIP: Update transport method documentation
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4264/ --- (Updated Dec. 29, 2014, 7:11 a.m.) Status -- This change has been marked as submitted. Review request for Asterisk Developers. Changes --- Committed in revision 430145 Repository: Asterisk Description --- This updates the documentation for the 'method' configuration option to be more verbose about the behaviors of values 'unspecified' and 'default'. They do exactly the same thing which is to select the default as defined by PJSIP which is currently TLSv1. Diffs - branches/13/res/res_pjsip.c 429431 Diff: https://reviewboard.asterisk.org/r/4264/diff/ Testing --- Ensured that Asterisk compiled and that the XML schema verification passed and that the new documentation was visible on the CLI. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4267: Testsuite: Add blind transfer tests for Stasis application interaction.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4267/#review13997 --- /asterisk/trunk/tests/rest_api/external_interaction/blind_transfer/stasis_bridge_to_non_stasis_app/test-config.yaml <https://reviewboard.asterisk.org/r/4267/#comment24515> You can assign the channel's uniqueid here so you don't need to store it elsewhere using the key "channelId" and "otherChannelId" if you need it. Doing this will significantly simplify the remainder of the test. - opticron On Dec. 15, 2014, 11:55 p.m., jbigelow wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4267/ > --- > > (Updated Dec. 15, 2014, 11:55 p.m.) > > > Review request for Asterisk Developers and Mark Michelson. > > > Bugs: ASTERISK-24581 > https://issues.asterisk.org/jira/browse/ASTERISK-24581 > > > Repository: testsuite > > > Description > --- > > This adds the remaining blind transfer tests 1.9 & 1.10 as described on the > StasisStart/StasisEnd Test Plan at: > https://wiki.asterisk.org/wiki/pages/viewpage.action?pageId=30279826 > > This additionally updates the existing test 'stasis_bridge_to_non_stasis_app' > (1.8) to verify the StasisEnd events of the channels per the test plan. An > additional (dummy) channel was added for the test to prevent the test from > ending when the channels involved in the test are hung up. This allows the > StasisEnd events of all the other channels to be verified before the test has > ended. The test description has also been updated to include more details > about the test. > > > Diffs > - > > > /asterisk/trunk/tests/rest_api/external_interaction/blind_transfer/tests.yaml > 6105 > > /asterisk/trunk/tests/rest_api/external_interaction/blind_transfer/stasis_bridge_to_same_stasis_app/test-config.yaml > PRE-CREATION > > /asterisk/trunk/tests/rest_api/external_interaction/blind_transfer/stasis_bridge_to_same_stasis_app/sipp/referer.xml > PRE-CREATION > > /asterisk/trunk/tests/rest_api/external_interaction/blind_transfer/stasis_bridge_to_same_stasis_app/sipp/referee.xml > PRE-CREATION > > /asterisk/trunk/tests/rest_api/external_interaction/blind_transfer/stasis_bridge_to_same_stasis_app/configs/ast1/pjsip.conf > PRE-CREATION > > /asterisk/trunk/tests/rest_api/external_interaction/blind_transfer/stasis_bridge_to_same_stasis_app/configs/ast1/extensions.conf > PRE-CREATION > > /asterisk/trunk/tests/rest_api/external_interaction/blind_transfer/stasis_bridge_to_non_stasis_app/test-config.yaml > 6105 > > /asterisk/trunk/tests/rest_api/external_interaction/blind_transfer/stasis_bridge_to_non_stasis_app/configs/ast1/extensions.conf > 6105 > > /asterisk/trunk/tests/rest_api/external_interaction/blind_transfer/stasis_bridge_to_non_stasis_app/blind_transfer.py > 6105 > > /asterisk/trunk/tests/rest_api/external_interaction/blind_transfer/stasis_bridge_to_different_stasis_app/test-config.yaml > PRE-CREATION > > /asterisk/trunk/tests/rest_api/external_interaction/blind_transfer/stasis_bridge_to_different_stasis_app/sipp/referer.xml > PRE-CREATION > > /asterisk/trunk/tests/rest_api/external_interaction/blind_transfer/stasis_bridge_to_different_stasis_app/sipp/referee.xml > PRE-CREATION > > /asterisk/trunk/tests/rest_api/external_interaction/blind_transfer/stasis_bridge_to_different_stasis_app/configs/ast1/pjsip.conf > PRE-CREATION > > /asterisk/trunk/tests/rest_api/external_interaction/blind_transfer/stasis_bridge_to_different_stasis_app/configs/ast1/extensions.conf > PRE-CREATION > > /asterisk/trunk/tests/rest_api/external_interaction/blind_transfer/blind_transfer.py > PRE-CREATION > > Diff: https://reviewboard.asterisk.org/r/4267/diff/ > > > Testing > --- > > * Executed tests multiple times > * Reviewed logs to manually verify StasisStart/StasisEnd events occurred. > > > Thanks, > > jbigelow > > -- _ -- 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] 4271: ARI: Allow interoperation of ASYNCGOTO and channels originated to Stasis()
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4271/ --- (Updated Dec. 17, 2014, 1:52 p.m.) Review request for Asterisk Developers and Joshua Colp. Changes --- Address Richard's comments. Bugs: ASTERISK-24591 https://issues.asterisk.org/jira/browse/ASTERISK-24591 Repository: Asterisk Description --- When the AMI Redirect action is used with a channel bridged inside Stasis() and not running a pbx, the channel is hung up instead of proceeding to the desired location in dialplan. This change allows such channels to be Redirected properly by detecting the operation used by Redirect (ASYNCGOTO) and using the code already established for functionality of the ARI channel continue operation. Diffs (updated) - branches/13/res/res_stasis.c 429611 Diff: https://reviewboard.asterisk.org/r/4271/diff/ Testing --- Ran the test that found this bug and verified that it passed with the expected events. See review 4272 for the test in question. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4271: ARI: Allow interoperation of ASYNCGOTO and channels originated to Stasis()
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4271/ --- (Updated Dec. 17, 2014, 12:30 p.m.) Review request for Asterisk Developers and Joshua Colp. Changes --- Address Joshua's and Richard's comments. Bugs: ASTERISK-24591 https://issues.asterisk.org/jira/browse/ASTERISK-24591 Repository: Asterisk Description --- When the AMI Redirect action is used with a channel bridged inside Stasis() and not running a pbx, the channel is hung up instead of proceeding to the desired location in dialplan. This change allows such channels to be Redirected properly by detecting the operation used by Redirect (ASYNCGOTO) and using the code already established for functionality of the ARI channel continue operation. Diffs (updated) - branches/13/res/res_stasis.c 429611 Diff: https://reviewboard.asterisk.org/r/4271/diff/ Testing --- Ran the test that found this bug and verified that it passed with the expected events. See review 4272 for the test in question. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4271: ARI: Allow interoperation of ASYNCGOTO and channels originated to Stasis()
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4271/ --- (Updated Dec. 17, 2014, 11:54 a.m.) Review request for Asterisk Developers and Joshua Colp. Changes --- Use the existing pbx code at the end of Stasis() to accomplish this fix. Bugs: ASTERISK-24591 https://issues.asterisk.org/jira/browse/ASTERISK-24591 Repository: Asterisk Description (updated) --- When the AMI Redirect action is used with a channel bridged inside Stasis() and not running a pbx, the channel is hung up instead of proceeding to the desired location in dialplan. This change allows such channels to be Redirected properly by detecting the operation used by Redirect (ASYNCGOTO) and using the code already established for functionality of the ARI channel continue operation. Diffs (updated) - branches/13/res/res_stasis.c 429611 Diff: https://reviewboard.asterisk.org/r/4271/diff/ Testing --- Ran the test that found this bug and verified that it passed with the expected events. See review 4272 for the test in question. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4271: ARI: Allow interoperation of ASYNCGOTO and channels originated to Stasis()
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4271/ --- (Updated Dec. 16, 2014, 2:41 p.m.) Review request for Asterisk Developers and Joshua Colp. Bugs: ASTERISK-24591 https://issues.asterisk.org/jira/browse/ASTERISK-24591 Repository: Asterisk Description --- When the AMI Redirect action is used with a channel bridged inside Stasis() and not running a pbx, the channel is hung up instead of proceeding to the desired location in dialplan. This change allows such channels to be Redirected properly by detecting the operation used by Redirect (ASYNCGOTO) and starting a pbx if necessary to allow the channel to execute dialplan at the desired location. Diffs - branches/13/res/ari/resource_channels.c 429611 branches/13/main/pbx.c 429611 Diff: https://reviewboard.asterisk.org/r/4271/diff/ Testing (updated) --- Ran the test that found this bug and verified that it passed with the expected events. See review 4272 for the test in question. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] [Code Review] 4271: ARI: Allow interoperation of ASYNCGOTO and channels originated to Stasis()
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4271/ --- Review request for Asterisk Developers and Joshua Colp. Bugs: ASTERISK-24591 https://issues.asterisk.org/jira/browse/ASTERISK-24591 Repository: Asterisk Description --- When the AMI Redirect action is used with a channel bridged inside Stasis() and not running a pbx, the channel is hung up instead of proceeding to the desired location in dialplan. This change allows such channels to be Redirected properly by detecting the operation used by Redirect (ASYNCGOTO) and starting a pbx if necessary to allow the channel to execute dialplan at the desired location. Diffs - branches/13/res/ari/resource_channels.c 429611 branches/13/main/pbx.c 429611 Diff: https://reviewboard.asterisk.org/r/4271/diff/ Testing --- Ran the test that found this bug and verified that it passed with the expected events. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] [Code Review] 4272: Testsuite: Verify that bridged channels originated into Stasis and AMI Redirect interoperate properly
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4272/ --- Review request for Asterisk Developers. Bugs: ASTERISK-24591 https://issues.asterisk.org/jira/browse/ASTERISK-24591 Repository: testsuite Description --- This adds a test to verify that the AMI Redirect action can be used in conjunction with channels that have been originated directly into a Stasis() application and are bridged when the Redirect takes place. Diffs - asterisk/trunk/tests/rest_api/external_interaction/ami_redirect/tests.yaml 6119 asterisk/trunk/tests/rest_api/external_interaction/ami_redirect/stasis_bridge_direct_originate/test-config.yaml PRE-CREATION asterisk/trunk/tests/rest_api/external_interaction/ami_redirect/stasis_bridge_direct_originate/configs/ast1/extensions.conf PRE-CREATION Diff: https://reviewboard.asterisk.org/r/4272/diff/ Testing --- Verified that the test operated properly when 4271 was applied and failed when it was not applied. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4265: res_pjsip_sdp_rtp: Native RTP bridging is chosen for RTP compatible channels when the DTMF mode is not compatible
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4265/#review13967 --- Ship it! branches/13/res/res_pjsip_sdp_rtp.c <https://reviewboard.asterisk.org/r/4265/#comment24486> Might as well drop this since it's duplicated just below your addition. - opticron On Dec. 15, 2014, 11:59 a.m., Kevin Harwell wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4265/ > --- > > (Updated Dec. 15, 2014, 11:59 a.m.) > > > Review request for Asterisk Developers. > > > Bugs: ASTERISK-24459 > https://issues.asterisk.org/jira/browse/ASTERISK-24459 > > > Repository: Asterisk > > > Description > --- > > A native rtp bridge was being chosen (it shouldn't have been) when using two > pjsip channels with incompatible DTMF modes. This patch sets the rtp > instance property, AST_RTP_PROPERTY_DTMF, for the appropriate DTMF mode(s) > for pjsip. It was not being set before, meaning all DTMF modes for pjsip > were being treated as compatible, thus native bridging would be chosen as the > bridge type when it shouldn't have been. > > > Diffs > - > > branches/13/res/res_pjsip_sdp_rtp.c 429572 > > Diff: https://reviewboard.asterisk.org/r/4265/diff/ > > > Testing > --- > > Using pjsip, set up two endpoints with incompatible DTMF modes. After > establishing a call between noted, using the CLI, that that a native_rtp > bridge was being chosen. After the patch noted the channels were now in a > simple bridge. > > > 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] 4266: Testsuite - res_pjsip_sdp_rtp: Incompatible DTMF mode test
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4266/#review13965 --- Ship it! Minor comments below. ./tests/channels/pjsip/dtmf_incompatible/configs/ast1/extensions.conf <https://reviewboard.asterisk.org/r/4266/#comment24485> This shouldn't be necessary. ./tests/channels/pjsip/dtmf_incompatible/configs/ast1/extensions.conf <https://reviewboard.asterisk.org/r/4266/#comment24484> Add empty parens at the end of the line. - opticron On Dec. 15, 2014, 4:56 p.m., Kevin Harwell wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4266/ > --- > > (Updated Dec. 15, 2014, 4:56 p.m.) > > > Review request for Asterisk Developers. > > > Bugs: ASTERISK-24459 > https://issues.asterisk.org/jira/browse/ASTERISK-24459 > > > Repository: testsuite > > > Description > --- > > Checks to make sure that if two pjsip endpoints with incompatible DTMF modes > are connected the appropriate bridge type is chosen. > > Note: the parent directory's tests.yaml has been modified to include this > test, but for some reason reviewboard "couldn't find the revision" or > something so it has not been included here, but will be committed. > > > Diffs > - > > ./tests/channels/pjsip/dtmf_incompatible/test-config.yaml PRE-CREATION > ./tests/channels/pjsip/dtmf_incompatible/sipp/invite_recv.xml PRE-CREATION > ./tests/channels/pjsip/dtmf_incompatible/sipp/invite.xml PRE-CREATION > ./tests/channels/pjsip/dtmf_incompatible/configs/ast1/pjsip.conf > PRE-CREATION > ./tests/channels/pjsip/dtmf_incompatible/configs/ast1/extensions.conf > PRE-CREATION > > Diff: https://reviewboard.asterisk.org/r/4266/diff/ > > > Testing > --- > > Ran test without patch it failed, ran with patch it passed. > > > 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] 4155: PJSIP: Allow contact rewriting to fall back for reliable transports
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4155/ --- (Updated Dec. 16, 2014, 10:40 a.m.) Status -- This change has been discarded. Review request for Asterisk Developers and Joshua Colp. Bugs: ASTERISK-24486 https://issues.asterisk.org/jira/browse/ASTERISK-24486 Repository: Asterisk Description --- This modifies contact rewriting to revert to the original contact URI for a dialog when persistent transports shut down. Some calls can enter a condition where their contact URI from the initial incoming invite was rewritten for a reliable transport, but that transport has been shut down due to inactivity. Such reliable transports can not be re-established since the remote host was never listening on the associated port. In cases such as these, it is useful to be able to fall back to the original contact URI since it might be accessible and allow the call to continue normally. Diffs - branches/12/res/res_pjsip_nat.c 428116 Diff: https://reviewboard.asterisk.org/r/4155/diff/ Testing --- Verified that this allowed the call to operate normally despite the original reliable connection being torn down where this situation was experienced. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] [Code Review] 4264: PJSIP: Update transport method documentation
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4264/ --- Review request for Asterisk Developers. Repository: Asterisk Description --- This updates the documentation for the 'method' configuration option to be more verbose about the behaviors of values 'unspecified' and 'default'. They do exactly the same thing which is to select the default as defined by PJSIP which is currently TLSv1. Diffs - branches/13/res/res_pjsip.c 429431 Diff: https://reviewboard.asterisk.org/r/4264/diff/ Testing --- Ensured that Asterisk compiled and that the XML schema verification passed and that the new documentation was visible on the CLI. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4263: Fix characters unjustly cast to unsigned int before printf formatting
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4263/#review13961
---
Ship it!
I verified that this compiles properly with gcc 4.10.
- opticron
On Dec. 15, 2014, 8:09 a.m., wdoekes wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4263/
> ---
>
> (Updated Dec. 15, 2014, 8:09 a.m.)
>
>
> Review request for Asterisk Developers and kmoore.
>
>
> Bugs: ASTERISK-24619
> https://issues.asterisk.org/jira/browse/ASTERISK-24619
>
>
> Repository: Asterisk
>
>
> Description
> ---
>
> r413586 introduced changes (amongst others) like:
>
> - out += sprintf(out, "%%%02X", (unsigned char) *ptr);
> + out += sprintf(out, "%%%02X", (unsigned) *ptr);
>
> But for high-ascii, that results in lots of FF's, for example:
>
> printf("%02X\n", (unsigned)("å"[0])); /* "FFC3" */
>
> This changeset attempt to rectify those by using the 'hh' modifier:
>
> $ man sprintf | grep hh -A4 | head -n4
>hh A following integer conversion corresponds to a
> signed char or unsigned char argument, or a follow‐
> ing n conversion corresponds to a pointer to a
> signed char argument.
>
> I also replaced occurrences of 2.2x with 02x. They appear to be equal.
>
>
> This issue was reported by Stefan27 on IRC.
>
>
> Diffs
> -
>
> /branches/1.8/utils/astman.c 429562
> /branches/1.8/res/res_pktccops.c 429562
> /branches/1.8/res/res_crypto.c 429562
> /branches/1.8/pbx/dundi-parser.c 429562
> /branches/1.8/main/utils.c 429562
> /branches/1.8/main/netsock.c 429562
> /branches/1.8/main/manager.c 429562
> /branches/1.8/main/loader.c 429562
> /branches/1.8/channels/sig_pri.c 429562
> /branches/1.8/channels/iax2-parser.c 429562
> /branches/1.8/channels/chan_sip.c 429562
> /branches/1.8/channels/chan_misdn.c 429562
> /branches/1.8/channels/chan_iax2.c 429562
> /branches/1.8/apps/app_sms.c 429562
> /branches/1.8/apps/app_getcpeid.c 429562
>
> Diff: https://reviewboard.asterisk.org/r/4263/diff/
>
>
> Testing
> ---
>
> It compiles with gcc 4.8. Did not test with gcc 4.10 which was
> the cause for the r413586 fixes.
>
>
> Thanks,
>
> wdoekes
>
>
--
_
-- 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] 4253: Testsuite: Add tests for use of 'inactive' stream direction for hold
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4253/ --- (Updated Dec. 12, 2014, 8:16 a.m.) Status -- This change has been marked as submitted. Review request for Asterisk Developers. Changes --- Committed in revision 6091 Repository: testsuite Description --- This adds tests checking the use of the 'inactive' stream direction for setting hold. This is used by some Seimens phones. This is primarily a copy of the existing hold tests for 'sendonly' streams with a little cleanup. Diffs - asterisk/trunk/tests/channels/pjsip/tests.yaml 6082 asterisk/trunk/tests/channels/pjsip/hold_inactive/test-config.yaml PRE-CREATION asterisk/trunk/tests/channels/pjsip/hold_inactive/sipp/phone_B_unhold_sans_sdp.xml PRE-CREATION asterisk/trunk/tests/channels/pjsip/hold_inactive/sipp/phone_B_media_restrict.xml PRE-CREATION asterisk/trunk/tests/channels/pjsip/hold_inactive/sipp/phone_B_hold_update.xml PRE-CREATION asterisk/trunk/tests/channels/pjsip/hold_inactive/sipp/phone_B_duplicate_hold.xml PRE-CREATION asterisk/trunk/tests/channels/pjsip/hold_inactive/sipp/phone_B_IP_media_restrict.xml PRE-CREATION asterisk/trunk/tests/channels/pjsip/hold_inactive/sipp/phone_A.xml PRE-CREATION asterisk/trunk/tests/channels/pjsip/hold_inactive/sipp/inject.csv PRE-CREATION asterisk/trunk/tests/channels/pjsip/hold_inactive/run-test PRE-CREATION asterisk/trunk/tests/channels/pjsip/hold_inactive/configs/ast1/pjsip.conf PRE-CREATION asterisk/trunk/tests/channels/pjsip/hold_inactive/configs/ast1/extensions.conf PRE-CREATION Diff: https://reviewboard.asterisk.org/r/4253/diff/ Testing --- Ensured that the tests functioned as expected. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4252: PJSIP: Allow use of 'inactive' stream types for hold
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4252/ --- (Updated Dec. 12, 2014, 8:11 a.m.) Status -- This change has been marked as submitted. Review request for Asterisk Developers. Changes --- Committed in revision 429432 Repository: Asterisk Description --- This allows use of the 'inactive' stream direction identifier to be used for hold where 'sendonly' is normally used. Some seimens phones use 'inactive' and this change allows music on hold to operate properly. Diffs - branches/12/res/res_pjsip_sdp_rtp.c 429324 Diff: https://reviewboard.asterisk.org/r/4252/diff/ Testing --- Ran existing pjsip tests in the testsuite and created new tests for checking functionality of the 'inactive' stream direction. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4250: Sorcery: Log when a stale configuration remains in use
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4250/ --- (Updated Dec. 12, 2014, 8:02 a.m.) Status -- This change has been marked as submitted. Review request for Asterisk Developers. Changes --- Committed in revision 429429 Repository: Asterisk Description --- This adds a log message notifying the user that a stale configuration is in place upon reload when a config object fails to load. This situation can end up causing confusion when the object failed to load but exists from a previous config load especially when the old config is significantly different from the new config. Diffs - branches/12/res/res_sorcery_config.c 429244 Diff: https://reviewboard.asterisk.org/r/4250/diff/ Testing --- Made sure that the message was printed upon reload with a bad object config. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4253: Testsuite: Add tests for use of 'inactive' stream direction for hold
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4253/ --- (Updated Dec. 11, 2014, 2:15 p.m.) Review request for Asterisk Developers. Changes --- Address Mark's comments. Repository: testsuite Description --- This adds tests checking the use of the 'inactive' stream direction for setting hold. This is used by some Seimens phones. This is primarily a copy of the existing hold tests for 'sendonly' streams with a little cleanup. Diffs (updated) - asterisk/trunk/tests/channels/pjsip/tests.yaml 6082 asterisk/trunk/tests/channels/pjsip/hold_inactive/test-config.yaml PRE-CREATION asterisk/trunk/tests/channels/pjsip/hold_inactive/sipp/phone_B_unhold_sans_sdp.xml PRE-CREATION asterisk/trunk/tests/channels/pjsip/hold_inactive/sipp/phone_B_media_restrict.xml PRE-CREATION asterisk/trunk/tests/channels/pjsip/hold_inactive/sipp/phone_B_hold_update.xml PRE-CREATION asterisk/trunk/tests/channels/pjsip/hold_inactive/sipp/phone_B_duplicate_hold.xml PRE-CREATION asterisk/trunk/tests/channels/pjsip/hold_inactive/sipp/phone_B_IP_media_restrict.xml PRE-CREATION asterisk/trunk/tests/channels/pjsip/hold_inactive/sipp/phone_A.xml PRE-CREATION asterisk/trunk/tests/channels/pjsip/hold_inactive/sipp/inject.csv PRE-CREATION asterisk/trunk/tests/channels/pjsip/hold_inactive/run-test PRE-CREATION asterisk/trunk/tests/channels/pjsip/hold_inactive/configs/ast1/pjsip.conf PRE-CREATION asterisk/trunk/tests/channels/pjsip/hold_inactive/configs/ast1/extensions.conf PRE-CREATION Diff: https://reviewboard.asterisk.org/r/4253/diff/ Testing --- Ensured that the tests functioned as expected. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4255: Testsuite: Add test for SDP offer/answer during hold with a declined stream
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4255/#review13940 --- Ship it! /asterisk/trunk/tests/channels/pjsip/sdp_offer_answer/incoming/off-nominal/multiple-media-stream/audio-video/hold-declined/test-config.yaml <https://reviewboard.asterisk.org/r/4255/#comment24473> Will this feature go in before 12.8.0 is released? - opticron On Dec. 11, 2014, 11:01 a.m., Joshua Colp wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4255/ > --- > > (Updated Dec. 11, 2014, 11:01 a.m.) > > > Review request for Asterisk Developers. > > > Bugs: ASTERISK-24607 > https://issues.asterisk.org/jira/browse/ASTERISK-24607 > > > Repository: testsuite > > > Description > --- > > This is a test which sets up a session with Asterisk. Once set up a hold is > done with a declined video stream. Asterisk should respond with a 200 OK > instead of a 488. > > > Diffs > - > > > /asterisk/trunk/tests/channels/pjsip/sdp_offer_answer/incoming/off-nominal/multiple-media-stream/audio-video/tests.yaml > 6082 > > /asterisk/trunk/tests/channels/pjsip/sdp_offer_answer/incoming/off-nominal/multiple-media-stream/audio-video/hold-declined/test-config.yaml > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/sdp_offer_answer/incoming/off-nominal/multiple-media-stream/audio-video/hold-declined/sipp/uac-hold.xml > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/sdp_offer_answer/incoming/off-nominal/multiple-media-stream/audio-video/hold-declined/configs/ast1/pjsip.conf > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/sdp_offer_answer/incoming/off-nominal/multiple-media-stream/audio-video/hold-declined/configs/ast1/extensions.conf > PRE-CREATION > > Diff: https://reviewboard.asterisk.org/r/4255/diff/ > > > Testing > --- > > Ran test, it lives! > > > 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] 4254: res_pjsip_session: Don't allow declined media streams to fail SDP negotiation on re-INVITE
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4254/#review13939 --- Ship it! Other than adjusting the comment below, this looks good to go. /branches/12/res/res_pjsip_session.c <https://reviewboard.asterisk.org/r/4254/#comment24472> This comment needs tweaking. - opticron On Dec. 11, 2014, 11:01 a.m., Joshua Colp wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4254/ > --- > > (Updated Dec. 11, 2014, 11:01 a.m.) > > > Review request for Asterisk Developers. > > > Bugs: ASTERISK-24607 > https://issues.asterisk.org/jira/browse/ASTERISK-24607 > > > Repository: Asterisk > > > Description > --- > > On an initial incoming INVITE declined streams are not treated as a fatal SDP > negotiation error. On a re-INVITE, however, they are treated as fatal. The > behavior should be the same between the two of them. > > This change makes it so the behavior is. > > > Diffs > - > > /branches/12/res/res_pjsip_session.c 429377 > > Diff: https://reviewboard.asterisk.org/r/4254/diff/ > > > Testing > --- > > Ran test. Before patch it failed, with patch it worked. I also ran the > existing SDP offer/answer tests to make sure they continued to work as > expected. > > > 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
[asterisk-dev] [Code Review] 4253: Testsuite: Add tests for use of 'inactive' stream direction for hold
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4253/ --- Review request for Asterisk Developers. Repository: testsuite Description --- This adds tests checking the use of the 'inactive' stream direction for setting hold. This is used by some Seimens phones. This is primarily a copy of the existing hold tests for 'sendonly' streams with a little cleanup. Diffs - asterisk/trunk/tests/channels/pjsip/tests.yaml 6082 asterisk/trunk/tests/channels/pjsip/hold_inactive/test-config.yaml PRE-CREATION asterisk/trunk/tests/channels/pjsip/hold_inactive/sipp/phone_B_unhold_sans_sdp.xml PRE-CREATION asterisk/trunk/tests/channels/pjsip/hold_inactive/sipp/phone_B_media_restrict.xml PRE-CREATION asterisk/trunk/tests/channels/pjsip/hold_inactive/sipp/phone_B_hold_update.xml PRE-CREATION asterisk/trunk/tests/channels/pjsip/hold_inactive/sipp/phone_B_duplicate_hold.xml PRE-CREATION asterisk/trunk/tests/channels/pjsip/hold_inactive/sipp/phone_B_IP_media_restrict.xml PRE-CREATION asterisk/trunk/tests/channels/pjsip/hold_inactive/sipp/phone_A.xml PRE-CREATION asterisk/trunk/tests/channels/pjsip/hold_inactive/sipp/inject.csv PRE-CREATION asterisk/trunk/tests/channels/pjsip/hold_inactive/run-test PRE-CREATION asterisk/trunk/tests/channels/pjsip/hold_inactive/configs/ast1/pjsip.conf PRE-CREATION asterisk/trunk/tests/channels/pjsip/hold_inactive/configs/ast1/extensions.conf PRE-CREATION Diff: https://reviewboard.asterisk.org/r/4253/diff/ Testing --- Ensured that the tests functioned as expected. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] [Code Review] 4252: PJSIP: Allow use of 'inactive' stream types for hold
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4252/ --- Review request for Asterisk Developers. Repository: Asterisk Description --- This allows use of the 'inactive' stream direction identifier to be used for hold where 'sendonly' is normally used. Some seimens phones use 'inactive' and this change allows music on hold to operate properly. Diffs - branches/12/res/res_pjsip_sdp_rtp.c 429324 Diff: https://reviewboard.asterisk.org/r/4252/diff/ Testing --- Ran existing pjsip tests in the testsuite and created new tests for checking functionality of the 'inactive' stream direction. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] [Code Review] 4250: Sorcery: Log when a stale configuration remains in use
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4250/ --- Review request for Asterisk Developers. Repository: Asterisk Description --- This adds a log message notifying the user that a stale configuration is in place upon reload when a config object fails to load. This situation can end up causing confusion when the object failed to load but exists from a previous config load especially when the old config is significantly different from the new config. Diffs - branches/12/res/res_sorcery_config.c 429244 Diff: https://reviewboard.asterisk.org/r/4250/diff/ Testing --- Made sure that the message was printed upon reload with a bad object config. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4182: core: avoid rasterisk crash due to long identifier
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4182/#review13932 --- Ship it! Ship It! - opticron On Nov. 14, 2014, 5:03 p.m., Scott Griepentrog wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4182/ > --- > > (Updated Nov. 14, 2014, 5:03 p.m.) > > > Review request for Asterisk Developers. > > > Repository: Asterisk > > > Description > --- > > When connecting to the remote console, an identifier string is first provided > that consists of hostname/pid/version. This is parsed by the remote instance > in a buffer allocated to only 80 bytes. It is possible for a combination of > very long hostname and very long asterisk version number to be greater than > 80 characters, causing the parsing to fall off the end of the allocated > memory buffer and potentially crash. > > This change increases the buffer from 80 to 256 to significantly reduce that > possibility. > > > Diffs > - > > /branches/13/main/asterisk.c 427948 > > Diff: https://reviewboard.asterisk.org/r/4182/diff/ > > > Testing > --- > > It stopped crashing on a repeated test I was running where the atoi of the > version # happen to hit the end of the buffer. > > > 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] 4246: PJSIP: Stagger outbound qualifies
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4246/ --- (Updated Dec. 9, 2014, 7:59 a.m.) Status -- This change has been marked as submitted. Review request for Asterisk Developers. Changes --- Committed in revision 429127 Bugs: ASTERISK-24342 https://issues.asterisk.org/jira/browse/ASTERISK-24342 Repository: Asterisk Description --- This change staggers initiation of outbound qualify (OPTIONS) attempts to reduce instantaneous server load and prevent network congestion. Diffs - branches/12/res/res_pjsip/pjsip_options.c 429060 branches/12/CHANGES 429060 Diff: https://reviewboard.asterisk.org/r/4246/diff/ Testing --- Verified that this did not break the existing qualify test and used wireshark to verify that the OPTIONS messages were being sent at staggered intervals with the patch and all at once without the patch. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4246: PJSIP: Stagger outbound qualifies
> On Dec. 8, 2014, 1:47 p.m., rmudgett wrote: > > branches/12/res/res_pjsip/pjsip_options.c, lines 416-421 > > <https://reviewboard.asterisk.org/r/4246/diff/2/?file=69600#file69600line416> > > > > You need to check that the returned value is never zero. > > qualify_frequency could become zero if the user disables qualify on a > > config reload. The config reload can't affect the contact object stored in the data blob held by the scheduler since the contact object is an immutable sorcery object. The scheduler callback would have to request a new snapshot to get the new config value. A config change that disables qualification on the given contact would remove the scheduler entry and then not start a new one since qualify_frequency would be 0 (see qualify_and_schedule()). - opticron --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4246/#review13924 --- On Dec. 8, 2014, 1:16 p.m., opticron wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4246/ > --- > > (Updated Dec. 8, 2014, 1:16 p.m.) > > > Review request for Asterisk Developers. > > > Bugs: ASTERISK-24342 > https://issues.asterisk.org/jira/browse/ASTERISK-24342 > > > Repository: Asterisk > > > Description > --- > > This change staggers initiation of outbound qualify (OPTIONS) attempts to > reduce instantaneous server load and prevent network congestion. > > > Diffs > - > > branches/12/res/res_pjsip/pjsip_options.c 429060 > branches/12/CHANGES 429060 > > Diff: https://reviewboard.asterisk.org/r/4246/diff/ > > > Testing > --- > > Verified that this did not break the existing qualify test and used wireshark > to verify that the OPTIONS messages were being sent at staggered intervals > with the patch and all at once without the patch. > > > Thanks, > > opticron > > -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4232: Testsuite: Tests for AMI NewConnectedLine and ARI ChannelConnectedLine events
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4232/#review13925 --- Ship it! Ship It! - opticron On Dec. 8, 2014, 9:38 a.m., Mark Michelson wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4232/ > --- > > (Updated Dec. 8, 2014, 9:38 a.m.) > > > Review request for Asterisk Developers. > > > Bugs: ASTERISK-24554 > https://issues.asterisk.org/jira/browse/ASTERISK-24554 > > > Repository: testsuite > > > Description > --- > > This adds two tests to the testsuite to ensure that connected line events are > emitted when the connected line on the channel changes. > > In tests/manager/connected_line, a channel places a call to an extension that > uses the CONNECTEDLINE() dialplan function to change connected line > information. We ensure that an AMI NewConnectedLine event is emitted and that > it has the expected values for connected line name and number. > > In tests/rest_api/channels/connected_line, a channel calls a Stasis > application. When the channel enters Stasis, the Stasis application updates > the connected line on the channel using the CONNECTEDLINE() dialplan > function. We ensure that a ChannelConnectedLine event is emitted and that the > connected line name and number have the expected values. > > > Diffs > - > > /asterisk/trunk/tests/rest_api/channels/tests.yaml 5983 > > /asterisk/trunk/tests/rest_api/channels/connected_line_update/test-config.yaml > PRE-CREATION > > /asterisk/trunk/tests/rest_api/channels/connected_line_update/configs/ast1/extensions.conf > PRE-CREATION > /asterisk/trunk/tests/manager/tests.yaml 5983 > /asterisk/trunk/tests/manager/connected_line/test-config.yaml PRE-CREATION > /asterisk/trunk/tests/manager/connected_line/configs/ast1/extensions.conf > PRE-CREATION > > Diff: https://reviewboard.asterisk.org/r/4232/diff/ > > > Testing > --- > > The tests pass. In addition, I tested for false positives by removing the > calls to the CONNECTEDLINE() dialplan function and ensuring that the tests > fail due to the events not being emitted. > > > 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
[asterisk-dev] [Code Review] 4246: PJSIP: Stagger outbound qualifies
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4246/ --- Review request for Asterisk Developers. Bugs: ASTERISK-24342 https://issues.asterisk.org/jira/browse/ASTERISK-24342 Repository: Asterisk Description --- This change staggers initiation of outbound qualify (OPTIONS) attempts to reduce instantaneous server load and prevent network congestion. Diffs - branches/12/res/res_pjsip/pjsip_options.c 429060 branches/12/CHANGES 429060 Diff: https://reviewboard.asterisk.org/r/4246/diff/ Testing --- Verified that this did not break the existing qualify test and used wireshark to verify that the OPTIONS messages were being sent at staggered intervals with the patch and all at once without the patch. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4226: Testsuite: Add tests for external interactions with ARI/Stasis
/rest_api/bridges/blind_transfer/configs/ast1/pjsip.conf 6018 asterisk/trunk/tests/rest_api/bridges/blind_transfer/configs/ast1/extensions.conf 6018 asterisk/trunk/tests/rest_api/bridges/blind_transfer/blind_transfer.py 6018 asterisk/trunk/tests/rest_api/bridges/attended_transfer/test-config.yaml 6018 asterisk/trunk/tests/rest_api/bridges/attended_transfer/sipp/referer.xml 6018 asterisk/trunk/tests/rest_api/bridges/attended_transfer/sipp/referee.xml 6018 asterisk/trunk/tests/rest_api/bridges/attended_transfer/configs/ast1/pjsip.conf 6018 asterisk/trunk/tests/rest_api/bridges/attended_transfer/configs/ast1/extensions.conf 6018 asterisk/trunk/tests/rest_api/bridges/attended_transfer/attended_transfer.py 6018 asterisk/trunk/lib/python/asterisk/ari.py 6018 Diff: https://reviewboard.asterisk.org/r/4226/diff/ Testing --- Ran the tests and verified they passed with the expected events when the fix in 4213 is applied. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4213: Stasis: Fix StasisStart and StasisEnd ordering and missing events
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4213/ --- (Updated Dec. 8, 2014, 9:41 a.m.) Status -- This change has been marked as submitted. Review request for Asterisk Developers and Mark Michelson. Changes --- Committed in revision 429061 Bugs: ASTERISK-24537 https://issues.asterisk.org/jira/browse/ASTERISK-24537 Repository: Asterisk Description --- This corrects several bugs that currently exist in the 12/13/trunk stasis application code. * After a masquerade, the resulting channels have channel topics that do not match their uniqueids ** Masquerades now swap channel topics appropriately * StasisStart and StasisEnd messages are leaked to observer applications due to being published on channel topics ** StasisStart and StasisEnd publishing is now properly restricted to controlling apps via app topics * Race conditions exist where StasisStart and StasisEnd messages due to a masquerade may be received out of order due to being published on different topics ** These messages are now published directly on the app topic so this is now a non-issue * StasisEnds are sometimes missing when sent due to masquerades and bridge swaps into and out of Stasis() ** This was due to StasisEnd processing adjusting message-sent flags after Stasis() had already exited and Stasis() had been re-entered ** This was corrected by adjusting these flags prior to sending the message while the initial Stasis() application was still shutting down Diffs - branches/12/res/stasis/stasis_bridge.c 428504 branches/12/res/stasis/app.c 428504 branches/12/res/stasis/app.h 428504 branches/12/res/res_stasis.c 428504 branches/12/main/channel_internal_api.c 428504 branches/12/main/channel.c 428504 branches/12/include/asterisk/channel.h 428504 Diff: https://reviewboard.asterisk.org/r/4213/diff/ Testing --- Ran existing ARI tests and a few new ones that are in-progress along with the scenarios that originally found these issues. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4232: Testsuite: Tests for AMI NewConnectedLine and ARI ChannelConnectedLine events
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4232/#review13900 --- The current patch is missing the second test for the AMI event. /asterisk/trunk/tests/rest_api/channels/connected_line_update/test-config.yaml <https://reviewboard.asterisk.org/r/4232/#comment24411> This minversion seems a bit low. - opticron On Dec. 4, 2014, 3:59 p.m., Mark Michelson wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4232/ > --- > > (Updated Dec. 4, 2014, 3:59 p.m.) > > > Review request for Asterisk Developers. > > > Bugs: ASTERISK-24554 > https://issues.asterisk.org/jira/browse/ASTERISK-24554 > > > Repository: testsuite > > > Description > --- > > This adds two tests to the testsuite to ensure that connected line events are > emitted when the connected line on the channel changes. > > In tests/manager/connected_line, a channel places a call to an extension that > uses the CONNECTEDLINE() dialplan function to change connected line > information. We ensure that an AMI NewConnectedLine event is emitted and that > it has the expected values for connected line name and number. > > In tests/rest_api/channels/connected_line, a channel calls a Stasis > application. When the channel enters Stasis, the Stasis application updates > the connected line on the channel using the CONNECTEDLINE() dialplan > function. We ensure that a ChannelConnectedLine event is emitted and that the > connected line name and number have the expected values. > > > Diffs > - > > /asterisk/trunk/tests/rest_api/channels/tests.yaml 5983 > > /asterisk/trunk/tests/rest_api/channels/connected_line_update/test-config.yaml > PRE-CREATION > > /asterisk/trunk/tests/rest_api/channels/connected_line_update/configs/ast1/extensions.conf > PRE-CREATION > > Diff: https://reviewboard.asterisk.org/r/4232/diff/ > > > Testing > --- > > The tests pass. In addition, I tested for false positives by removing the > calls to the CONNECTEDLINE() dialplan function and ensuring that the tests > fail due to the events not being emitted. > > > 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] 4231: New AMI/ARI events for connected line updates on a channel
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4231/#review13888 --- Ship it! Ship It! - opticron On Dec. 4, 2014, 11:07 a.m., Mark Michelson wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4231/ > --- > > (Updated Dec. 4, 2014, 11:07 a.m.) > > > Review request for Asterisk Developers. > > > Bugs: ASTERISK-24554 > https://issues.asterisk.org/jira/browse/ASTERISK-24554 > > > Repository: Asterisk > > > Description > --- > > Currently, there is an event that occurs when Caller ID on a channel changes > (NewCallerid for AMI, ChannelCallerId for ARI). This change implements a > similar event when a channel's connected line changes (NewConnectedLine for > AMI, ChannelConnectedLine for ARI). > > This change is proposed for Asterisk 13 since it is not very invasive and has > accompanying tests. > > > Diffs > - > > /branches/13/rest-api/api-docs/events.json 428835 > /branches/13/res/stasis/app.c 428835 > /branches/13/res/ari/ari_model_validators.c 428835 > /branches/13/res/ari/ari_model_validators.h 428835 > /branches/13/main/stasis_channels.c 428835 > /branches/13/main/manager_channels.c 428835 > /branches/13/main/channel.c 428835 > /branches/13/include/asterisk/stasis_channels.h 428835 > /branches/13/CHANGES 428835 > > Diff: https://reviewboard.asterisk.org/r/4231/diff/ > > > Testing > --- > > See /r/4232 for some automated tests. > > I also performed calls between multiple parties to ensure that in typical > bridging scenarios, the events were emitted. > > > 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] 4232: Testsuite: Tests for AMI NewConnectedLine and ARI ChannelConnectedLine events
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4232/#review13887
---
/asterisk/trunk/tests/rest_api/channels/connected_line_update/connected_line.py
<https://reviewboard.asterisk.org/r/4232/#comment24401>
This can be done in YAML with:
requests:
method: 'delete'
uri: 'channels/{channel.id}'
/asterisk/trunk/tests/rest_api/channels/connected_line_update/connected_line.py
<https://reviewboard.asterisk.org/r/4232/#comment24400>
This can be more easily checked in the matching section in the YAML
configuration.
/asterisk/trunk/tests/rest_api/channels/connected_line_update/test-config.yaml
<https://reviewboard.asterisk.org/r/4232/#comment24399>
This can be replaced with:
requests:
method: 'post'
uri: 'channels/{channel.id}/variable'
params:
variable: 'CONNECTEDLINE(all)'
value: 'TEST <1234>'
- opticron
On Dec. 4, 2014, 11:07 a.m., Mark Michelson wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4232/
> ---
>
> (Updated Dec. 4, 2014, 11:07 a.m.)
>
>
> Review request for Asterisk Developers.
>
>
> Bugs: ASTERISK-24554
> https://issues.asterisk.org/jira/browse/ASTERISK-24554
>
>
> Repository: testsuite
>
>
> Description
> ---
>
> This adds two tests to the testsuite to ensure that connected line events are
> emitted when the connected line on the channel changes.
>
> In tests/manager/connected_line, a channel places a call to an extension that
> uses the CONNECTEDLINE() dialplan function to change connected line
> information. We ensure that an AMI NewConnectedLine event is emitted and that
> it has the expected values for connected line name and number.
>
> In tests/rest_api/channels/connected_line, a channel calls a Stasis
> application. When the channel enters Stasis, the Stasis application updates
> the connected line on the channel using the CONNECTEDLINE() dialplan
> function. We ensure that a ChannelConnectedLine event is emitted and that the
> connected line name and number have the expected values.
>
>
> Diffs
> -
>
> /asterisk/trunk/tests/rest_api/channels/tests.yaml 5983
>
> /asterisk/trunk/tests/rest_api/channels/connected_line_update/test-config.yaml
> PRE-CREATION
>
> /asterisk/trunk/tests/rest_api/channels/connected_line_update/connected_line.py
> PRE-CREATION
>
> /asterisk/trunk/tests/rest_api/channels/connected_line_update/configs/ast1/extensions.conf
> PRE-CREATION
> /asterisk/trunk/tests/manager/tests.yaml 5983
> /asterisk/trunk/tests/manager/connected_line/test-config.yaml PRE-CREATION
> /asterisk/trunk/tests/manager/connected_line/configs/ast1/extensions.conf
> PRE-CREATION
>
> Diff: https://reviewboard.asterisk.org/r/4232/diff/
>
>
> Testing
> ---
>
> The tests pass. In addition, I tested for false positives by removing the
> calls to the CONNECTEDLINE() dialplan function and ensuring that the tests
> fail due to the events not being emitted.
>
>
> 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] 4226: Testsuite: Add tests for external interactions with ARI/Stasis
/ast1/pjsip.conf 6018 asterisk/trunk/tests/rest_api/bridges/blind_transfer/configs/ast1/extensions.conf 6018 asterisk/trunk/tests/rest_api/bridges/blind_transfer/blind_transfer.py 6018 asterisk/trunk/tests/rest_api/bridges/attended_transfer/test-config.yaml 6018 asterisk/trunk/tests/rest_api/bridges/attended_transfer/sipp/referer.xml 6018 asterisk/trunk/tests/rest_api/bridges/attended_transfer/sipp/referee.xml 6018 asterisk/trunk/tests/rest_api/bridges/attended_transfer/configs/ast1/pjsip.conf 6018 asterisk/trunk/tests/rest_api/bridges/attended_transfer/configs/ast1/extensions.conf 6018 asterisk/trunk/tests/rest_api/bridges/attended_transfer/attended_transfer.py 6018 asterisk/trunk/lib/python/asterisk/ari.py 6018 Diff: https://reviewboard.asterisk.org/r/4226/diff/ Testing --- Ran the tests and verified they passed with the expected events when the fix in 4213 is applied. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4226: Testsuite: Add tests for external interactions with ARI/Stasis
/referer.xml 6018 asterisk/trunk/tests/rest_api/bridges/attended_transfer/sipp/referee.xml 6018 asterisk/trunk/tests/rest_api/bridges/attended_transfer/configs/ast1/pjsip.conf 6018 asterisk/trunk/tests/rest_api/bridges/attended_transfer/configs/ast1/extensions.conf 6018 asterisk/trunk/tests/rest_api/bridges/attended_transfer/attended_transfer.py 6018 asterisk/trunk/lib/python/asterisk/ari.py 6018 Diff: https://reviewboard.asterisk.org/r/4226/diff/ Testing --- Ran the tests and verified they passed with the expected events when the fix in 4213 is applied. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4230: add capath support to res_pjsip
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4230/#review13882 --- The alembic scripts should get an update for this. - opticron On Dec. 3, 2014, 8:11 p.m., cloos wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4230/ > --- > > (Updated Dec. 3, 2014, 8:11 p.m.) > > > Review request for Asterisk Developers. > > > Bugs: 24575 > https://issues.asterisk.org/jira/browse/24575 > > > Repository: Asterisk > > > Description > --- > > Building on the pjproject patch also on bug 24575, support capath for > res_pjsip, in parallel to cafile, just like for every other tls subsystem. > > > Diffs > - > > trunk/res/res_pjsip/config_transport.c 428862 > trunk/res/res_pjsip.c 428862 > trunk/include/asterisk/res_pjsip.h 428862 > trunk/configs/samples/pjsip.conf.sample 428862 > > Diff: https://reviewboard.asterisk.org/r/4230/diff/ > > > Testing > --- > > > Thanks, > > cloos > > -- _ -- 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] 4226: Testsuite: Add tests for external interactions with ARI/Stasis
/configs/ast1/extensions.conf 6018 asterisk/trunk/tests/rest_api/bridges/attended_transfer/attended_transfer.py 6018 asterisk/trunk/lib/python/asterisk/ari.py 6018 Diff: https://reviewboard.asterisk.org/r/4226/diff/ Testing --- Ran the tests and verified they passed with the expected events when the fix in 4213 is applied. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] [Code Review] 4226: Testsuite: Add tests for external interactions with ARI/Stasis
/diff/ Testing --- Ran the tests and verified they passed with the expected events when the fix in 4213 is applied. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4213: Stasis: Fix StasisStart and StasisEnd ordering and missing events
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4213/ --- (Updated Dec. 2, 2014, 1:34 p.m.) Review request for Asterisk Developers and Mark Michelson. Changes --- Update description and address Matt's comments with some simplification of the patch. Bugs: ASTERISK-24537 https://issues.asterisk.org/jira/browse/ASTERISK-24537 Repository: Asterisk Description (updated) --- This corrects several bugs that currently exist in the 12/13/trunk stasis application code. * After a masquerade, the resulting channels have channel topics that do not match their uniqueids ** Masquerades now swap channel topics appropriately * StasisStart and StasisEnd messages are leaked to observer applications due to being published on channel topics ** StasisStart and StasisEnd publishing is now properly restricted to controlling apps via app topics * Race conditions exist where StasisStart and StasisEnd messages due to a masquerade may be received out of order due to being published on different topics ** These messages are now published directly on the app topic so this is now a non-issue * StasisEnds are sometimes missing when sent due to masquerades and bridge swaps into and out of Stasis() ** This was due to StasisEnd processing adjusting message-sent flags after Stasis() had already exited and Stasis() had been re-entered ** This was corrected by adjusting these flags prior to sending the message while the initial Stasis() application was still shutting down Diffs (updated) - branches/12/res/stasis/stasis_bridge.c 428504 branches/12/res/stasis/app.c 428504 branches/12/res/stasis/app.h 428504 branches/12/res/res_stasis.c 428504 branches/12/main/channel_internal_api.c 428504 branches/12/main/channel.c 428504 branches/12/include/asterisk/channel.h 428504 Diff: https://reviewboard.asterisk.org/r/4213/diff/ Testing --- Ran existing ARI tests and a few new ones that are in-progress along with the scenarios that originally found these issues. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4197: testsuite: Update cleanup-test-remnants to clean /var/tmp/asterisk-testsuite and ./logs/*
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4197/#review13864 --- Ship it! Ship It! - opticron On Nov. 19, 2014, 12:15 p.m., George Joseph wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4197/ > --- > > (Updated Nov. 19, 2014, 12:15 p.m.) > > > Review request for Asterisk Developers. > > > Repository: testsuite > > > Description > --- > > My root filesystem ran out of inodes last night while running the testsuite. > Turns out that cleanup-test-remnants doesn't clean out > /var/tmp/asterisk-testsuite which is where the output (40G and 20k files for > 524 tests) goes. It does now as well as cleaning out ./logs/*. > > > Diffs > - > > asterisk/trunk/cleanup-test-remnants.sh 5956 > > Diff: https://reviewboard.asterisk.org/r/4197/diff/ > > > Testing > --- > > > 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] 4213: Stasis: Fix StasisStart and StasisEnd ordering and missing events
> On Dec. 2, 2014, 7:23 a.m., Matt Jordan wrote: > > branches/12/res/res_stasis.c, lines 1069-1075 > > <https://reviewboard.asterisk.org/r/4213/diff/1/?file=69250#file69250line1069> > > > > I think we have an error here, in that we don't clean up the implicit > > application subscription to the channel here. The subscription is dropped inside of app_send_end_msg(). > On Dec. 2, 2014, 7:23 a.m., Matt Jordan wrote: > > branches/12/res/res_stasis.c, lines 1112-1114 > > <https://reviewboard.asterisk.org/r/4213/diff/1/?file=69250#file69250line1112> > > > > I'm confused about where the channel being masqueraded out has its > > StasisEnd raised. Are you guaranteed that the stolen callback will be > > raised for the channel being replaced? If not, where does the replaced > > channel get its StasisEnd and its subscription modified? It was being generated based on the StasisStart with replace_channel, but this has been reverted to a simpler mechanism in the new patch. > On Dec. 2, 2014, 7:23 a.m., Matt Jordan wrote: > > branches/12/res/stasis/app.c, lines 1165-1190 > > <https://reviewboard.asterisk.org/r/4213/diff/1/?file=69252#file69252line1165> > > > > I'm not sure why this entire block was removed. It still feels like we > > would need to clean up the implicit application subscriptions on > > replacement. If not, the review summary does not explain why this code was > > no longer necessary. The subscription swap is still happening, it's just partially integrated with the start and end message sending routines. I'll finish that integration in the next patch. - opticron --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4213/#review13859 --- On Nov. 25, 2014, 2:29 p.m., opticron wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4213/ > --- > > (Updated Nov. 25, 2014, 2:29 p.m.) > > > Review request for Asterisk Developers and Mark Michelson. > > > Bugs: ASTERISK-24537 > https://issues.asterisk.org/jira/browse/ASTERISK-24537 > > > Repository: Asterisk > > > Description > --- > > This corrects several bugs that currently exist in the 12/13/trunk stasis > application code. > > * Masquerades now swap channel topics appropriately > * StasisStart and StasisEnd publishing is now properly restricted to > controlling apps via app topics > * StasisEnd published because of replacement via masquerade-in is now > published as a byproduct of the associated StasisStart to avoid race > conditions > * StasisEnds now appear in some cases in which they were missing involving > masquerades and bridge swaps into and out of Stasis() > > > Diffs > - > > branches/12/res/stasis/app.c 428504 > branches/12/res/stasis/app.h 428504 > branches/12/res/res_stasis.c 428504 > branches/12/main/channel_internal_api.c 428504 > branches/12/main/channel.c 428504 > branches/12/include/asterisk/channel.h 428504 > > Diff: https://reviewboard.asterisk.org/r/4213/diff/ > > > Testing > --- > > Ran existing ARI tests and a few new ones that are in-progress along with the > scenarios that originally found these issues. > > > Thanks, > > opticron > > -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4141: Enable REF_DEBUG for ast_module_ref / ast_module_unref
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4141/#review13861 --- /branches/11/include/asterisk/module.h <https://reviewboard.asterisk.org/r/4141/#comment24344> These could use a bit of documentation. /branches/11/main/loader.c <https://reviewboard.asterisk.org/r/4141/#comment24345> Bump the indentation here. - opticron On Nov. 2, 2014, 1:13 a.m., Corey Farrell wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4141/ > --- > > (Updated Nov. 2, 2014, 1:13 a.m.) > > > Review request for Asterisk Developers. > > > Bugs: ASTERISK-24479 > https://issues.asterisk.org/jira/browse/ASTERISK-24479 > > > Repository: Asterisk > > > Description > --- > > This change includes an ABI change with compatibility stubs for 11, 12 and > 13. The compatibility stubs will not be included in trunk. The point of > this change is to have each module create an AO2 object on load, and > hopefully destroy it on unload. This allows module reference count errors to > be debugged through REF_DEBUG. > > When REF_DEBUG is enabled: > * adds an empty ao2 object to 'struct ast_module' > * Allocate ao2 when the module is loaded > * Perform an ao2_ref in each place where mod->usecount is manipulated. > * ao2_cleanup on module unload. > > > The passthrough of file, line and func is needed for the REF_DEBUG to be of > any use, so without the ABI changes this is not useful. > > The change to bridge_builtin_features.c ensures that the module cannot be > manually unloaded, but is able to be unloaded during ast_module_shutdown. > Note ast_module_shutdown only happens during clean shutdown and does not > actually run dlclose so this is safe. > > > Diffs > - > > /branches/11/main/loader.c 426830 > /branches/11/include/asterisk/module.h 426830 > /branches/11/bridges/bridge_builtin_features.c 426830 > > Diff: https://reviewboard.asterisk.org/r/4141/diff/ > > > Testing > --- > > Using tests/manager/originate with REF_DEBUG enabled. When the change to > bridge_builtin_features.c is omitted the test fails due to that one reference > leak. > > > 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
[asterisk-dev] [Code Review] 4213: Stasis: Fix StasisStart and StasisEnd ordering and missing events
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4213/ --- Review request for Asterisk Developers and Mark Michelson. Bugs: ASTERISK-24537 https://issues.asterisk.org/jira/browse/ASTERISK-24537 Repository: Asterisk Description --- This corrects several bugs that currently exist in the 12/13/trunk stasis application code. * Masquerades now swap channel topics appropriately * StasisStart and StasisEnd publishing is now properly restricted to controlling apps via app topics * StasisEnd published because of replacement via masquerade-in is now published as a byproduct of the associated StasisStart to avoid race conditions * StasisEnds now appear in some cases in which they were missing involving masquerades and bridge swaps into and out of Stasis() Diffs - branches/12/res/stasis/app.c 428504 branches/12/res/stasis/app.h 428504 branches/12/res/res_stasis.c 428504 branches/12/main/channel_internal_api.c 428504 branches/12/main/channel.c 428504 branches/12/include/asterisk/channel.h 428504 Diff: https://reviewboard.asterisk.org/r/4213/diff/ Testing --- Ran existing ARI tests and a few new ones that are in-progress along with the scenarios that originally found these issues. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 3603: func_jitterbuffer: fix audio failure caused by certain masquerade's
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3603/#review13807 --- /branches/11/funcs/func_jitterbuffer.c <https://reviewboard.asterisk.org/r/3603/#comment24287> These should use ast_strdup and should be checked for failure. - opticron On Oct. 30, 2014, 7:06 p.m., Corey Farrell wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3603/ > --- > > (Updated Oct. 30, 2014, 7:06 p.m.) > > > Review request for Asterisk Developers, Joshua Colp and Matt Jordan. > > > Bugs: ASTERISK-22409 > https://issues.asterisk.org/jira/browse/ASTERISK-22409 > > > Repository: Asterisk > > > Description > --- > > During masquerade it is possible for the AST_JITTERBUFFER_FD to be cleared > (set to -1). This change adds a check when copying channel fd's to prevent > clearing an FD with -1. This seems to resolve the bad audio quality > experienced after the masquerade. When AST_JITTERBUFFER_FD was set to -1, > this prevented the channel from polling that timer. This caused RTP packets > to be received late, and discarded. > > > Diffs > - > > /branches/11/main/channel.c 426593 > /branches/11/funcs/func_jitterbuffer.c 426593 > > Diff: https://reviewboard.asterisk.org/r/3603/diff/ > > > Testing > --- > > Verified the scenario outlined in ASTERISK-22409 no longer experiences audio > quality loss. > > > 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] 4155: PJSIP: Allow contact rewriting to fall back for reliable transports
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4155/ --- (Updated Nov. 17, 2014, 2:46 p.m.) Review request for Asterisk Developers and Joshua Colp. Changes --- Addressed Joshua's comments and added locking to mod data accesses and modifications. Bugs: ASTERISK-24486 https://issues.asterisk.org/jira/browse/ASTERISK-24486 Repository: Asterisk Description --- This modifies contact rewriting to revert to the original contact URI for a dialog when persistent transports shut down. Some calls can enter a condition where their contact URI from the initial incoming invite was rewritten for a reliable transport, but that transport has been shut down due to inactivity. Such reliable transports can not be re-established since the remote host was never listening on the associated port. In cases such as these, it is useful to be able to fall back to the original contact URI since it might be accessible and allow the call to continue normally. Diffs (updated) - branches/12/res/res_pjsip_nat.c 428116 Diff: https://reviewboard.asterisk.org/r/4155/diff/ Testing --- Verified that this allowed the call to operate normally despite the original reliable connection being torn down where this situation was experienced. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4155: PJSIP: Allow contact rewriting to fall back for reliable transports
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4155/ --- (Updated Nov. 13, 2014, 10:53 a.m.) Review request for Asterisk Developers and Joshua Colp. Changes --- Address Joshua's comments with a partial rewrite. Bugs: ASTERISK-24486 https://issues.asterisk.org/jira/browse/ASTERISK-24486 Repository: Asterisk Description --- This modifies contact rewriting to revert to the original contact URI for a dialog when persistent transports shut down. Some calls can enter a condition where their contact URI from the initial incoming invite was rewritten for a reliable transport, but that transport has been shut down due to inactivity. Such reliable transports can not be re-established since the remote host was never listening on the associated port. In cases such as these, it is useful to be able to fall back to the original contact URI since it might be accessible and allow the call to continue normally. Diffs (updated) - branches/12/res/res_pjsip_nat.c 427735 Diff: https://reviewboard.asterisk.org/r/4155/diff/ Testing --- Verified that this allowed the call to operate normally despite the original reliable connection being torn down where this situation was experienced. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4163: Stasis: Fix StasisEnd message ordering
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4163/ --- (Updated Nov. 13, 2014, 9:42 a.m.) Status -- This change has been marked as submitted. Review request for Asterisk Developers. Changes --- Committed in revision 427788 Bugs: ASTERISK-24501 https://issues.asterisk.org/jira/browse/ASTERISK-24501 Repository: Asterisk Description --- This change corrects message ordering in cases where a channel-related message can be received after a Stasis/ARI application has received the StasisEnd message. The StasisEnd message was being passed to applications directly without waiting for the channel topic to empty. As a result of this fix, other bugs were also identified and fixed: * StasisStart messages were also being sent directly to apps and are now routed through the stasis message bus properly * Masquerade monitor datastores were being removed at the incorrect time in some cases and were causing StasisEnd messages to not be sent * General refactoring where necessary for the above * Unsubscription on StasisEnd timing changes to prevent additional messages from following the StasisEnd when they shouldn't A channel sanitization function pointer was added to reduce processing and AO2 lookups This also required minor changes to tests using AriTestObject or its subclasses since StasisEnd is no longer reliably received before the test shuts the websocket down. This is due to the AriTestObject relying on AMI events to decide when the test is over which won't necessarily come in at the same time as the corresponding ARI events since they arrive via two different transports. Diffs - branches/12/res/stasis/stasis_bridge.c 427539 branches/12/res/stasis/app.c 427539 branches/12/res/stasis/app.h 427539 branches/12/res/res_stasis.c 427539 branches/12/include/asterisk/stasis_app.h 427539 branches/12/include/asterisk/stasis.h 427539 Diff: https://reviewboard.asterisk.org/r/4163/diff/ Testing --- Ran all the REST API tests to verify that they passed. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4163: Stasis: Fix StasisEnd message ordering
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4163/ --- (Updated Nov. 12, 2014, 12:56 p.m.) Review request for Asterisk Developers. Changes --- Added some error messages for critical failure paths. Bugs: ASTERISK-24501 https://issues.asterisk.org/jira/browse/ASTERISK-24501 Repository: Asterisk Description --- This change corrects message ordering in cases where a channel-related message can be received after a Stasis/ARI application has received the StasisEnd message. The StasisEnd message was being passed to applications directly without waiting for the channel topic to empty. As a result of this fix, other bugs were also identified and fixed: * StasisStart messages were also being sent directly to apps and are now routed through the stasis message bus properly * Masquerade monitor datastores were being removed at the incorrect time in some cases and were causing StasisEnd messages to not be sent * General refactoring where necessary for the above * Unsubscription on StasisEnd timing changes to prevent additional messages from following the StasisEnd when they shouldn't A channel sanitization function pointer was added to reduce processing and AO2 lookups This also required minor changes to tests using AriTestObject or its subclasses since StasisEnd is no longer reliably received before the test shuts the websocket down. This is due to the AriTestObject relying on AMI events to decide when the test is over which won't necessarily come in at the same time as the corresponding ARI events since they arrive via two different transports. Diffs (updated) - branches/12/res/stasis/stasis_bridge.c 427539 branches/12/res/stasis/app.c 427539 branches/12/res/stasis/app.h 427539 branches/12/res/res_stasis.c 427539 branches/12/include/asterisk/stasis_app.h 427539 branches/12/include/asterisk/stasis.h 427539 Diff: https://reviewboard.asterisk.org/r/4163/diff/ Testing --- Ran all the REST API tests to verify that they passed. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4155: PJSIP: Allow contact rewriting to fall back for reliable transports
> On Nov. 10, 2014, 8:24 a.m., Joshua Colp wrote: > > branches/12/res/res_pjsip_nat.c, line 230 > > <https://reviewboard.asterisk.org/r/4155/diff/1/?file=68767#file68767line230> > > > > Just a question - is this already on the dialog? (Do you need to clone > > it?) > > Joshua Colp wrote: > Or can you steal it like a thief. The uri is allocated on the rdata and not on the dialog, so the clone is necessary. - opticron --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4155/#review13717 --- On Nov. 6, 2014, 9:49 a.m., opticron wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4155/ > --- > > (Updated Nov. 6, 2014, 9:49 a.m.) > > > Review request for Asterisk Developers and Joshua Colp. > > > Bugs: ASTERISK-24486 > https://issues.asterisk.org/jira/browse/ASTERISK-24486 > > > Repository: Asterisk > > > Description > --- > > This modifies contact rewriting to revert to the original contact URI for a > dialog when persistent transports shut down. > > Some calls can enter a condition where their contact URI from the initial > incoming invite was rewritten for a reliable transport, but that transport > has been shut down due to inactivity. Such reliable transports can not be > re-established since the remote host was never listening on the associated > port. In cases such as these, it is useful to be able to fall back to the > original contact URI since it might be accessible and allow the call to > continue normally. > > > Diffs > - > > branches/12/res/res_pjsip_nat.c 425222 > > Diff: https://reviewboard.asterisk.org/r/4155/diff/ > > > Testing > --- > > Verified that this allowed the call to operate normally despite the original > reliable connection being torn down where this situation was experienced. > > > Thanks, > > opticron > > -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] [Code Review] 4163: Stasis: Fix StasisEnd message ordering
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4163/ --- Review request for Asterisk Developers. Bugs: ASTERISK-24501 https://issues.asterisk.org/jira/browse/ASTERISK-24501 Repository: Asterisk Description --- This change corrects message ordering in cases where a channel-related message can be received after a Stasis/ARI application has received the StasisEnd message. The StasisEnd message was being passed to applications directly without waiting for the channel topic to empty. As a result of this fix, other bugs were also identified and fixed: * StasisStart messages were also being sent directly to apps and are now routed through the stasis message bus properly * Masquerade monitor datastores were being removed at the incorrect time in some cases and were causing StasisEnd messages to not be sent * General refactoring where necessary for the above * Unsubscription on StasisEnd timing changes to prevent additional messages from following the StasisEnd when they shouldn't A channel sanitization function pointer was added to reduce processing and AO2 lookups This also required minor changes to tests using AriTestObject or its subclasses since StasisEnd is no longer reliably received before the test shuts the websocket down. This is due to the AriTestObject relying on AMI events to decide when the test is over which won't necessarily come in at the same time as the corresponding ARI events since they arrive via two different transports. Diffs - branches/12/res/stasis/stasis_bridge.c 427539 branches/12/res/stasis/app.c 427539 branches/12/res/stasis/app.h 427539 branches/12/res/res_stasis.c 427539 branches/12/include/asterisk/stasis_app.h 427539 branches/12/include/asterisk/stasis.h 427539 Diff: https://reviewboard.asterisk.org/r/4163/diff/ Testing --- Ran all the REST API tests to verify that they passed. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4135: Resolve race condition that can result in ARI apps not being notified of transfers
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4135/#review13703 --- /branches/12/include/asterisk/stasis_bridges.h <https://reviewboard.asterisk.org/r/4135/#comment24197> This is missing documentation on the return value as are other documentation blocks. /branches/12/main/bridge.c <https://reviewboard.asterisk.org/r/4135/#comment24198> Ahem. /branches/12/main/bridge.c <https://reviewboard.asterisk.org/r/4135/#comment24199> This message needs to be removed. /branches/12/main/stasis_bridges.c <https://reviewboard.asterisk.org/r/4135/#comment24200> This function only eats the transfer_message ref on failure. Callers don't appear to expect their reference to be consumed. /branches/12/main/stasis_bridges.c <https://reviewboard.asterisk.org/r/4135/#comment24201> Using RAII_VAR here would be appropriate since the 5 applicable return paths require its cleanup. - opticron On Nov. 4, 2014, 3:44 p.m., Mark Michelson wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4135/ > --- > > (Updated Nov. 4, 2014, 3:44 p.m.) > > > Review request for Asterisk Developers. > > > Repository: Asterisk > > > Description > --- > > During blind transfer testing, it was noticed that tests were failing > occasionally because the ARI blind transfer event was not being sent. After > investigating, I detected a race condition in the blind transfer code. When > blind transferring a single channel, the actual transfer operation (i.e. > removing the transferee from the bridge and directing them to the proper > dialplan location) is queued onto the transferee bridge channel. After > queuing the transfer operation, the blind transfer Stasis message is > published. At the time of publication, snapshots of the channels and bridge > involved are created. The ARI subscriber to the blind transfer Stasis message > then attempts to determine if the bridge or any of the involved channels are > subscribed to by ARI applications. If so, then the blind transfer message is > sent to the applications. The way that the ARI blind transfer message handler > works is to first see if the transferer channel is subscribed to. If not, > then iterate over all the ch annel IDs in the bridge snapshot and determine if any of those are subscribed to. In the test we were running, the lone transferee channel was subscribed to, so an ARI event should have been sent to our application. Occasionally, though, the bridge snapshot did not have any channels IDs on it at all. Why? > > The problem is that since the blind transfer operation is handled by a > separate thread, it is possible that the transfer will have completed and the > channels removed from the bridge before we publish the blind transfer Stasis > message. Since the blind transfer has completed, the bridge on which the > transfer occurred no longer has any channels on it, so the resulting bridge > snapshot has no channels on it. Through investigation of the code, I found > that attended transfers can have this issue too for the case where a > transferee is transferred to an application. > > To fix this problem, I thought of four possible fixes: > 1) Let the thread that actually performs the blind transfer publish the > Stasis message. > 2) Get the bridge snapshot before queuing the blind transfer operation. > 3) Publish the blind transfer Stasis message before queuing the blind > transfer operation. > 4) Hold the bridge lock while queuing the blind transfer operation and > publishing the blind transfer Stasis message. > > Option 1 is clearly the "best" option, but it also is made nearly impossible > due to the way that bridge channel operations are queued. Bridge channel > operations use frames, which require that their payload be copyable using > memcpy(). Including any sort of pointer is a no-no. So I would be forced to > come up with some inane method of representing multiple channels and bridges > in a frame in order to do this. > > Option 2 is slightly more workable. Currently, there are functions to publish > blind and attended transfers that require bridges and channels, not > snapshots. Changing the API to accommodate snapshots is possible, but it is > more widespread than I would like, and it changes the API. It also runs the > slight risk of publishing "stale" data, though that is not likely. > > Option 3 is easiest to i
[asterisk-dev] [Code Review] 4155: PJSIP: Allow contact rewriting to fall back for reliable transports
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4155/ --- Review request for Asterisk Developers and Joshua Colp. Bugs: ASTERISK-24486 https://issues.asterisk.org/jira/browse/ASTERISK-24486 Repository: Asterisk Description --- This modifies contact rewriting to revert to the original contact URI for a dialog when persistent transports shut down. Some calls can enter a condition where their contact URI from the initial incoming invite was rewritten for a reliable transport, but that transport has been shut down due to inactivity. Such reliable transports can not be re-established since the remote host was never listening on the associated port. In cases such as these, it is useful to be able to fall back to the original contact URI since it might be accessible and allow the call to continue normally. Diffs - branches/12/res/res_pjsip_nat.c 425222 Diff: https://reviewboard.asterisk.org/r/4155/diff/ Testing --- Verified that this allowed the call to operate normally despite the original reliable connection being torn down where this situation was experienced. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4132: config: Make ast_config_text_file_save and 'dialplan save' escape semicolons in values.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4132/#review13670 --- Ship it! Ship It! - opticron On Oct. 30, 2014, 7:02 p.m., George Joseph wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4132/ > --- > > (Updated Oct. 30, 2014, 7:02 p.m.) > > > Review request for Asterisk Developers and Birger Harzenetter. > > > Bugs: ASTERISK-20127 > https://issues.asterisk.org/jira/browse/ASTERISK-20127 > > > Repository: Asterisk > > > Description > --- > > I've been locally patching for this issue for 2 years but now someone else > (WIMPy) has run into the same problem. > > When a config file is read, an unescaped semicolon signals comments which are > stripped from the value before it's stored. Escaped semicolons are then > unescaped and become part of the value. Both of these behaviors are normal > and expected. When the config is serialized either by 'dialplan save' or > AMI/UpdateConfig however, the now unescaped semicolons are written as-is. If > you actually reload the file just saved, the unescaped semicolons are now > treated as start of comments. > > Example: > > Lines such as > PAGING_HEADER = Call-Info: \;answer-after=0 > are being rewritten as > PAGING_HEADER = Call-Info: ;answer-after=0 > > On re-read, everything after the now-unescaped semicolon is read as a comment > with the result that the file is effectively corrupted. > > So... Since true comments are stripped on read, any semicolons in > ast_variable.value must have been escaped originally. This patch re-escapes > semicolons in ast_variable.values before they're written to file either by > 'dialplan save' or config/ast_config_text_file_save which is called by > AMI/UpdateConfig. I also fixed a few pre-existing formatting issues nearby in > pbx_config.c > > This patch is for 13 but it will be applied to 1.8 -> trunk. > > > Diffs > - > > branches/13/tests/test_strings.c 426808 > branches/13/pbx/pbx_config.c 426808 > branches/13/main/utils.c 426808 > branches/13/main/config.c 426808 > branches/13/include/asterisk/utils.h 426808 > > Diff: https://reviewboard.asterisk.org/r/4132/diff/ > > > Testing > --- > > Testsuite results before and after match. > tests/manager/config will be updated to test escaped semicolons. > A new testsuite test will be written to test dialplan save. > > > 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] 4099: Optimistic SRTP Tests.
> On Oct. 29, 2014, 1:26 p.m., opticron wrote: > > /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/optimistic_with_optimistic_offer/sipp/offer.xml, > > line 45 > > <https://reviewboard.asterisk.org/r/4099/diff/2/?file=68484#file68484line45> > > > > The other three new tests should have this type of check in the 200 > > response as well. > > Joshua Colp wrote: > They... do? optimistic_with_no_crypto/sipp/offer.xml is missing a test verifying lack of crypto. - opticron --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4099/#review13621 --- On Oct. 21, 2014, 8:49 a.m., Joshua Colp wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4099/ > --- > > (Updated Oct. 21, 2014, 8:49 a.m.) > > > Review request for Asterisk Developers. > > > Repository: testsuite > > > Description > --- > > This change removes 1 SIPP scenario from the old SRTP negotiation tests which > would fail (because optimistic is now supported) and adds 4 new tests to > cover the new optimistic support. These test do: > > 1. Asterisk is configured with mandatory encryption and receives an offer > with optimistic, it accepts the offer. > 2. Asterisk is configured with optimistic encryption and receives an offer > with optimistic, it accepts the offer. > 3. Asterisk is configured with optimistic encryption and receives an offer > with mandatory, it accepts the offer. > 4. Asterisk is configured with optimistic encryption and receives an offer > without any crypto, it accepts the offer. > > The other SRTP negotiation tests cover the mandatory situations and other > assorted crypto stuff. > > > Diffs > - > > /asterisk/trunk/tests/channels/pjsip/tests.yaml 5766 > /asterisk/trunk/tests/channels/pjsip/srtp_negotiation/test-config.yaml 5766 > > /asterisk/trunk/tests/channels/pjsip/srtp_negotiation/sipp/decline_not_enabled.xml > 5766 > /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/tests.yaml > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/optimistic_with_optimistic_offer/test-config.yaml > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/optimistic_with_optimistic_offer/sipp/offer.xml > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/optimistic_with_optimistic_offer/configs/ast1/pjsip.conf > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/optimistic_with_optimistic_offer/configs/ast1/extensions.conf > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/optimistic_with_no_crypto/test-config.yaml > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/optimistic_with_no_crypto/sipp/offer.xml > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/optimistic_with_no_crypto/configs/ast1/pjsip.conf > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/optimistic_with_no_crypto/configs/ast1/extensions.conf > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/optimistic_with_mandatory_offer/test-config.yaml > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/optimistic_with_mandatory_offer/sipp/offer.xml > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/optimistic_with_mandatory_offer/configs/ast1/pjsip.conf > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/optimistic_with_mandatory_offer/configs/ast1/extensions.conf > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/mandatory_with_optimistic_offer/test-config.yaml > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/mandatory_with_optimistic_offer/sipp/offer.xml > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/mandatory_with_optimistic_offer/configs/ast1/pjsip.conf > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/mandatory_with_optimistic_offer/configs/ast1/extensions.conf > PRE-CREATION > > Diff: https://reviewboard.asterisk.org/r/4099/diff/ > > > Testing > --- > > Ran tests, confirmed happy. > > > 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] 4132: config: Make ast_config_text_file_save and 'dialplan save' escape semicolons in values.
> On Oct. 30, 2014, 1:25 p.m., opticron wrote: > > branches/13/main/utils.c, line 494 > > <https://reviewboard.asterisk.org/r/4132/diff/3/?file=68631#file68631line494> > > > > This should be > instead of >= due to the need to write out a null > > terminator along with the escaped semicolon. > > > > Look at the degenerate case of input string ";" with an input buffer of > > length 2 (1 byte usable). Ignore this one, I read the line incorrectly. - opticron --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4132/#review13632 --- On Oct. 30, 2014, 12:09 p.m., George Joseph wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4132/ > --- > > (Updated Oct. 30, 2014, 12:09 p.m.) > > > Review request for Asterisk Developers and Birger Harzenetter. > > > Bugs: ASTERISK-20127 > https://issues.asterisk.org/jira/browse/ASTERISK-20127 > > > Repository: Asterisk > > > Description > --- > > I've been locally patching for this issue for 2 years but now someone else > (WIMPy) has run into the same problem. > > When a config file is read, an unescaped semicolon signals comments which are > stripped from the value before it's stored. Escaped semicolons are then > unescaped and become part of the value. Both of these behaviors are normal > and expected. When the config is serialized either by 'dialplan save' or > AMI/UpdateConfig however, the now unescaped semicolons are written as-is. If > you actually reload the file just saved, the unescaped semicolons are now > treated as start of comments. > > Example: > > Lines such as > PAGING_HEADER = Call-Info: \;answer-after=0 > are being rewritten as > PAGING_HEADER = Call-Info: ;answer-after=0 > > On re-read, everything after the now-unescaped semicolon is read as a comment > with the result that the file is effectively corrupted. > > So... Since true comments are stripped on read, any semicolons in > ast_variable.value must have been escaped originally. This patch re-escapes > semicolons in ast_variable.values before they're written to file either by > 'dialplan save' or config/ast_config_text_file_save which is called by > AMI/UpdateConfig. I also fixed a few pre-existing formatting issues nearby in > pbx_config.c > > This patch is for 13 but it will be applied to 1.8 -> trunk. > > > Diffs > - > > branches/13/pbx/pbx_config.c 426754 > branches/13/main/utils.c 426754 > branches/13/main/config.c 426754 > branches/13/include/asterisk/utils.h 426754 > > Diff: https://reviewboard.asterisk.org/r/4132/diff/ > > > Testing > --- > > Testsuite results before and after match. > tests/manager/config will be updated to test escaped semicolons. > A new testsuite test will be written to test dialplan save. > > > 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] 4132: config: Make ast_config_text_file_save and 'dialplan save' escape semicolons in values.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4132/#review13632 --- This new function could use some unit tests for nominal and edge cases given the off by one issue outlined below. branches/13/main/utils.c <https://reviewboard.asterisk.org/r/4132/#comment24144> Remove the extra space here. branches/13/main/utils.c <https://reviewboard.asterisk.org/r/4132/#comment24145> This should be > instead of >= due to the need to write out a null terminator along with the escaped semicolon. Look at the degenerate case of input string ";" with an input buffer of length 2 (1 byte usable). branches/13/pbx/pbx_config.c <https://reviewboard.asterisk.org/r/4132/#comment24143> Put an empty line after the declarations block. branches/13/pbx/pbx_config.c <https://reviewboard.asterisk.org/r/4132/#comment24142> escaped_len can be declared in the if block. - opticron On Oct. 30, 2014, 12:09 p.m., George Joseph wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4132/ > --- > > (Updated Oct. 30, 2014, 12:09 p.m.) > > > Review request for Asterisk Developers and Birger Harzenetter. > > > Bugs: ASTERISK-20127 > https://issues.asterisk.org/jira/browse/ASTERISK-20127 > > > Repository: Asterisk > > > Description > --- > > I've been locally patching for this issue for 2 years but now someone else > (WIMPy) has run into the same problem. > > When a config file is read, an unescaped semicolon signals comments which are > stripped from the value before it's stored. Escaped semicolons are then > unescaped and become part of the value. Both of these behaviors are normal > and expected. When the config is serialized either by 'dialplan save' or > AMI/UpdateConfig however, the now unescaped semicolons are written as-is. If > you actually reload the file just saved, the unescaped semicolons are now > treated as start of comments. > > Example: > > Lines such as > PAGING_HEADER = Call-Info: \;answer-after=0 > are being rewritten as > PAGING_HEADER = Call-Info: ;answer-after=0 > > On re-read, everything after the now-unescaped semicolon is read as a comment > with the result that the file is effectively corrupted. > > So... Since true comments are stripped on read, any semicolons in > ast_variable.value must have been escaped originally. This patch re-escapes > semicolons in ast_variable.values before they're written to file either by > 'dialplan save' or config/ast_config_text_file_save which is called by > AMI/UpdateConfig. I also fixed a few pre-existing formatting issues nearby in > pbx_config.c > > This patch is for 13 but it will be applied to 1.8 -> trunk. > > > Diffs > - > > branches/13/pbx/pbx_config.c 426754 > branches/13/main/utils.c 426754 > branches/13/main/config.c 426754 > branches/13/include/asterisk/utils.h 426754 > > Diff: https://reviewboard.asterisk.org/r/4132/diff/ > > > Testing > --- > > Testsuite results before and after match. > tests/manager/config will be updated to test escaped semicolons. > A new testsuite test will be written to test dialplan save. > > > 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] 4120: res_pjsip_acl: contact ACL permits are being interpreted incorrectly
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4120/#review13626 --- Ship it! Ship It! - opticron On Oct. 28, 2014, 2:45 p.m., Jonathan Rose wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4120/ > --- > > (Updated Oct. 28, 2014, 2:45 p.m.) > > > Review request for Asterisk Developers. > > > Repository: Asterisk > > > Description > --- > > In the attempt to skip past the 'contact' part of the variable name before > passing it into the acl handler, we have a momentary lapse of sanity and > forget that '_allow' isn't 'allow' and ast_append_acl interprets it as > another deny. > > > Diffs > - > > /branches/12/res/res_pjsip_acl.c 426232 > > Diff: https://reviewboard.asterisk.org/r/4120/diff/ > > > Testing > --- > > deny=0.0.0.0/24 > allow= > > Note that I have to reload pjsip after startup in order for the ACL to > work... that seems like a bug surely. In any event, with the patch the > device successfully registers. Without the patch, the registration is > blocked by the ACL. > > > 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] 4116: res_pjsip: incorrect qualify statistics after disabling for contact
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4116/#review13625 --- Ship it! Ship It! - opticron On Oct. 27, 2014, 4:43 p.m., Kevin Harwell wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4116/ > --- > > (Updated Oct. 27, 2014, 4:43 p.m.) > > > Review request for Asterisk Developers and Mark Michelson. > > > Bugs: ASTERISK-24462 > https://issues.asterisk.org/jira/browse/ASTERISK-24462 > > > Repository: Asterisk > > > Description > --- > > When removing the qualify_frequency from an AoR or a contact the statistics > shown when issuing "pjsip show aors" from the CLI are incorrect. This patch > deletes the contact's status object from sorcery, disassociating it from the > contact, if the qualify_freqency is removed from configuration. > > > Diffs > - > > branches/12/res/res_pjsip/pjsip_options.c 426251 > > Diff: https://reviewboard.asterisk.org/r/4116/diff/ > > > Testing > --- > > Using static and dynamic contacts and various combinations of adding, > removing, and reloading the configuration for both AoR and contact level > qualify_freqency options noted that the qualify statistics are now correctly > reflected. > > > 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] 4101: Channel Originate/Continue via ARI support for labels in dialplan is incomplete
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4101/#review13624 --- /trunk/res/ari/resource_channels.c <https://reviewboard.asterisk.org/r/4101/#comment24137> This should be defined within the scope of the if block below. /trunk/res/ari/resource_channels.c <https://reviewboard.asterisk.org/r/4101/#comment24138> This needs a ast_channel_unref after finding the label. /trunk/res/ari/resource_channels.c <https://reviewboard.asterisk.org/r/4101/#comment24135> This debug message should be removed in the final version of this patch. /trunk/res/ari/resource_channels.c <https://reviewboard.asterisk.org/r/4101/#comment24134> This should check for a return of -1 and emit the appropriate error message if the priority of the label can not be found. /trunk/res/ari/resource_channels.c <https://reviewboard.asterisk.org/r/4101/#comment24136> Same comment about this debug message. /trunk/res/ari/resource_channels.c <https://reviewboard.asterisk.org/r/4101/#comment24139> Same comment on the debug statements here. - opticron On Oct. 21, 2014, 12:50 p.m., greenfieldtech wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4101/ > --- > > (Updated Oct. 21, 2014, 12:50 p.m.) > > > Review request for Asterisk Developers. > > > Bugs: ASTERISK-24412 > https://issues.asterisk.org/jira/browse/ASTERISK-24412 > > > Repository: Asterisk > > > Description > --- > > This patch changes the current behavior of ARI, to allow channel > originate/continue requests to be performed with labels as the priority, not > only integer values. > > > Diffs > - > > /trunk/rest-api/api-docs/channels.json 425359 > /trunk/res/res_ari_channels.c 425359 > /trunk/res/ari/resource_channels.c 425359 > /trunk/res/ari/resource_channels.h 425359 > > Diff: https://reviewboard.asterisk.org/r/4101/diff/ > > > Testing > --- > > Testing was performed by testing the following scenarios: > 1. Originating a call to a numeric priority - works > 2. Originating a call to a null priority - works > 3. Originating a call to a label - works > 4. Continue a call to a label - not tested yet > > > Thanks, > > greenfieldtech > > -- _ -- 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] 4099: Optimistic SRTP Tests.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4099/#review13621 --- /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/optimistic_with_optimistic_offer/sipp/offer.xml <https://reviewboard.asterisk.org/r/4099/#comment24131> The other three new tests should have this type of check in the 200 response as well. - opticron On Oct. 21, 2014, 8:49 a.m., Joshua Colp wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4099/ > --- > > (Updated Oct. 21, 2014, 8:49 a.m.) > > > Review request for Asterisk Developers. > > > Repository: testsuite > > > Description > --- > > This change removes 1 SIPP scenario from the old SRTP negotiation tests which > would fail (because optimistic is now supported) and adds 4 new tests to > cover the new optimistic support. These test do: > > 1. Asterisk is configured with mandatory encryption and receives an offer > with optimistic, it accepts the offer. > 2. Asterisk is configured with optimistic encryption and receives an offer > with optimistic, it accepts the offer. > 3. Asterisk is configured with optimistic encryption and receives an offer > with mandatory, it accepts the offer. > 4. Asterisk is configured with optimistic encryption and receives an offer > without any crypto, it accepts the offer. > > The other SRTP negotiation tests cover the mandatory situations and other > assorted crypto stuff. > > > Diffs > - > > /asterisk/trunk/tests/channels/pjsip/tests.yaml 5766 > /asterisk/trunk/tests/channels/pjsip/srtp_negotiation/test-config.yaml 5766 > > /asterisk/trunk/tests/channels/pjsip/srtp_negotiation/sipp/decline_not_enabled.xml > 5766 > /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/tests.yaml > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/optimistic_with_optimistic_offer/test-config.yaml > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/optimistic_with_optimistic_offer/sipp/offer.xml > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/optimistic_with_optimistic_offer/configs/ast1/pjsip.conf > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/optimistic_with_optimistic_offer/configs/ast1/extensions.conf > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/optimistic_with_no_crypto/test-config.yaml > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/optimistic_with_no_crypto/sipp/offer.xml > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/optimistic_with_no_crypto/configs/ast1/pjsip.conf > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/optimistic_with_no_crypto/configs/ast1/extensions.conf > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/optimistic_with_mandatory_offer/test-config.yaml > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/optimistic_with_mandatory_offer/sipp/offer.xml > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/optimistic_with_mandatory_offer/configs/ast1/pjsip.conf > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/optimistic_with_mandatory_offer/configs/ast1/extensions.conf > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/mandatory_with_optimistic_offer/test-config.yaml > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/mandatory_with_optimistic_offer/sipp/offer.xml > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/mandatory_with_optimistic_offer/configs/ast1/pjsip.conf > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/mandatory_with_optimistic_offer/configs/ast1/extensions.conf > PRE-CREATION > > Diff: https://reviewboard.asterisk.org/r/4099/diff/ > > > Testing > --- > > Ran tests, confirmed happy. > > > 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] 2964: res_pjsip_outbound_registration: Add "virtual line" support for automatic inbound matching
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/2964/#review13620 --- Ship it! Ship It! - opticron On Oct. 10, 2014, 8:18 a.m., Joshua Colp wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/2964/ > --- > > (Updated Oct. 10, 2014, 8:18 a.m.) > > > Review request for Asterisk Developers. > > > Repository: Asterisk > > > Description > --- > > This patch adds "virtual line" support to the res_pjsip_outbound_registration > module. This is an optional feature and simply adds a "line" URI parameter to > the Contact we place in the outbound registration. If this line parameter is > present on incoming requests we use it to establish a relationship to the > outbound registration and match it to a user configured endpoint. This has > the benefit that when registering to another server where it is supported you > no longer have to do IP based matching for all of their potential servers. > The downside (and why this is optional) is that if a third party got the line > parameter they could send you calls as if they were the legit remote server. > > > Diffs > - > > /trunk/res/res_pjsip_outbound_registration.c 425156 > /trunk/configs/samples/pjsip.conf.sample 425156 > > Diff: https://reviewboard.asterisk.org/r/2964/diff/ > > > Testing > --- > > Registered to an ITSP, placed an inbound call from them, confirmed matched > using line parameter. > > Registered to a chan_sip instance, placed an inbound call from it, confirmed > matched using line parameter. > > > 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] 4085: ExtensionStatus: Add additional documentation describing the ExtensionStatus event
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4085/#review13592 --- Ship it! Ship It! - opticron On Oct. 16, 2014, 2:06 p.m., Jonathan Rose wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4085/ > --- > > (Updated Oct. 16, 2014, 2:06 p.m.) > > > Review request for Asterisk Developers, Matt Jordan and Mark Michelson. > > > Repository: Asterisk > > > Description > --- > > Some internals developers pointed out that this event was poorly documented, > particularly when it comes to Status and StatusText which really need to be > explained in order to be useful. > > > Diffs > - > > /branches/13/main/manager.c 425546 > > Diff: https://reviewboard.asterisk.org/r/4085/diff/ > > > Testing > --- > > Checked the output of > > > manager show event ExtensionStatus > > Exten > Name of the extension. > Context > Context that owns the extension. > Hint > Devices mapped to the extension which determine the extension status > Status > Numerical data indicating the status of the extension based on its > devices. Negative values indicate that the extension was removed (-2) > or deactivated (-1). Zero indicates that the extension is idle. Positive > values work as bitflags and may combine to indicate different things. > For example 1 would mean inuse, 2 would mean busy, and the two can add > together additively into 3 to mean that a line is both inuse and busy. > Each of the major classifications is a power of two and they can > potentailly be added in any combination. > -2 - Removed - The extension was removed. Not additive. > -1 - Deactivated - The extension's hit was removed. Not additive. > 0 - Idle - No device INUSE or BUSY. Not additive. > 1 - In Use - one or more devices INUSE. Additive. > 2 - Busy - All devices are BUSY. Additive. > 4 - Unavailable - All devices are UNAVAILABLE and/or UNREGISTERED. > Additive. > 8 - Ringing - All devices are RINGING. Additive. > 16 - Onhold - All devices are ONHOLD. Additive. > StatusText > Human readable representation of the status. The options are also > more strictly defined and may only be one thing from the following > enumerator. > Idle - No device INUSE or BUSY. > InUse - One or more devices are INUSE. > Busy - All devices are BUSY. > Unavailable - All devices are UNAVAILABLE and/or UNREGISTERED > Ringing - All devices are RINGING > InUse&Ringing - All devices are RINGING and one or more devices are > INUSE > Hold - All devices are ONHOLD. > InUse&Hold - All devices are ONHOLD and one or more devices are INUSE > Unknown - None of the above descriptions matched the status > value > > > 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] 4062: PJSIP: Enforce module load dependencies
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4062/ --- (Updated Oct. 16, 2014, 9:25 a.m.) Status -- This change has been marked as submitted. Review request for Asterisk Developers. Changes --- Committed in revision 425690 Bugs: ASTERISK-24312 https://issues.asterisk.org/jira/browse/ASTERISK-24312 Repository: Asterisk Description --- This enforces that res_pjsip, res_pjsip_session, and res_pjsip_pubsub have loaded properly before attempting to load any modules that depend on them since the module loader system is not currently capable of resolving module dependencies on its own. Diffs - branches/12/res/res_pjsip_xpidf_body_generator.c 424849 branches/12/res/res_pjsip_transport_websocket.c 424849 branches/12/res/res_pjsip_t38.c 424849 branches/12/res/res_pjsip_session.c 424849 branches/12/res/res_pjsip_send_to_voicemail.c 424849 branches/12/res/res_pjsip_sdp_rtp.c 424849 branches/12/res/res_pjsip_rfc3326.c 424849 branches/12/res/res_pjsip_registrar_expire.c 424849 branches/12/res/res_pjsip_registrar.c 424849 branches/12/res/res_pjsip_refer.c 424849 branches/12/res/res_pjsip_pubsub.c 424849 branches/12/res/res_pjsip_pidf_eyebeam_body_supplement.c 424849 branches/12/res/res_pjsip_pidf_digium_body_supplement.c 424849 branches/12/res/res_pjsip_pidf_body_generator.c 424849 branches/12/res/res_pjsip_path.c 424849 branches/12/res/res_pjsip_outbound_registration.c 424849 branches/12/res/res_pjsip_outbound_authenticator_digest.c 424849 branches/12/res/res_pjsip_one_touch_record_info.c 424849 branches/12/res/res_pjsip_notify.c 424849 branches/12/res/res_pjsip_nat.c 424849 branches/12/res/res_pjsip_mwi_body_generator.c 424849 branches/12/res/res_pjsip_mwi.c 424849 branches/12/res/res_pjsip_multihomed.c 424849 branches/12/res/res_pjsip_messaging.c 424849 branches/12/res/res_pjsip_logger.c 424849 branches/12/res/res_pjsip_header_funcs.c 424849 branches/12/res/res_pjsip_exten_state.c 424849 branches/12/res/res_pjsip_endpoint_identifier_user.c 424849 branches/12/res/res_pjsip_endpoint_identifier_ip.c 424849 branches/12/res/res_pjsip_endpoint_identifier_anonymous.c 424849 branches/12/res/res_pjsip_dtmf_info.c 424849 branches/12/res/res_pjsip_diversion.c 424849 branches/12/res/res_pjsip_dialog_info_body_generator.c 424849 branches/12/res/res_pjsip_caller_id.c 424849 branches/12/res/res_pjsip_authenticator_digest.c 424849 branches/12/res/res_pjsip_acl.c 424849 branches/12/res/res_hep_pjsip.c 424849 branches/12/include/asterisk/res_pjsip_session.h 424849 branches/12/include/asterisk/res_pjsip_pubsub.h 424849 branches/12/include/asterisk/res_pjsip.h 424849 branches/12/channels/chan_pjsip.c 424849 Diff: https://reviewboard.asterisk.org/r/4062/diff/ Testing --- Verified that this fixed the bug presented in ASTERISK-24312. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4062: PJSIP: Enforce module load dependencies
> On Oct. 15, 2014, 5:38 p.m., George Joseph wrote: > > Can you make the change in res_pjsip_phoneprov_provider while you're there? > > It was just committed. It'd need CHECK_PJSIP_MODULE_LOADED(). I can take care of that. - opticron --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4062/#review13536 --- On Oct. 9, 2014, 9:30 a.m., opticron wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4062/ > --- > > (Updated Oct. 9, 2014, 9:30 a.m.) > > > Review request for Asterisk Developers. > > > Bugs: ASTERISK-24312 > https://issues.asterisk.org/jira/browse/ASTERISK-24312 > > > Repository: Asterisk > > > Description > --- > > This enforces that res_pjsip, res_pjsip_session, and res_pjsip_pubsub have > loaded properly before attempting to load any modules that depend on them > since the module loader system is not currently capable of resolving module > dependencies on its own. > > > Diffs > - > > branches/12/res/res_pjsip_xpidf_body_generator.c 424849 > branches/12/res/res_pjsip_transport_websocket.c 424849 > branches/12/res/res_pjsip_t38.c 424849 > branches/12/res/res_pjsip_session.c 424849 > branches/12/res/res_pjsip_send_to_voicemail.c 424849 > branches/12/res/res_pjsip_sdp_rtp.c 424849 > branches/12/res/res_pjsip_rfc3326.c 424849 > branches/12/res/res_pjsip_registrar_expire.c 424849 > branches/12/res/res_pjsip_registrar.c 424849 > branches/12/res/res_pjsip_refer.c 424849 > branches/12/res/res_pjsip_pubsub.c 424849 > branches/12/res/res_pjsip_pidf_eyebeam_body_supplement.c 424849 > branches/12/res/res_pjsip_pidf_digium_body_supplement.c 424849 > branches/12/res/res_pjsip_pidf_body_generator.c 424849 > branches/12/res/res_pjsip_path.c 424849 > branches/12/res/res_pjsip_outbound_registration.c 424849 > branches/12/res/res_pjsip_outbound_authenticator_digest.c 424849 > branches/12/res/res_pjsip_one_touch_record_info.c 424849 > branches/12/res/res_pjsip_notify.c 424849 > branches/12/res/res_pjsip_nat.c 424849 > branches/12/res/res_pjsip_mwi_body_generator.c 424849 > branches/12/res/res_pjsip_mwi.c 424849 > branches/12/res/res_pjsip_multihomed.c 424849 > branches/12/res/res_pjsip_messaging.c 424849 > branches/12/res/res_pjsip_logger.c 424849 > branches/12/res/res_pjsip_header_funcs.c 424849 > branches/12/res/res_pjsip_exten_state.c 424849 > branches/12/res/res_pjsip_endpoint_identifier_user.c 424849 > branches/12/res/res_pjsip_endpoint_identifier_ip.c 424849 > branches/12/res/res_pjsip_endpoint_identifier_anonymous.c 424849 > branches/12/res/res_pjsip_dtmf_info.c 424849 > branches/12/res/res_pjsip_diversion.c 424849 > branches/12/res/res_pjsip_dialog_info_body_generator.c 424849 > branches/12/res/res_pjsip_caller_id.c 424849 > branches/12/res/res_pjsip_authenticator_digest.c 424849 > branches/12/res/res_pjsip_acl.c 424849 > branches/12/res/res_hep_pjsip.c 424849 > branches/12/include/asterisk/res_pjsip_session.h 424849 > branches/12/include/asterisk/res_pjsip_pubsub.h 424849 > branches/12/include/asterisk/res_pjsip.h 424849 > branches/12/channels/chan_pjsip.c 424849 > > Diff: https://reviewboard.asterisk.org/r/4062/diff/ > > > Testing > --- > > Verified that this fixed the bug presented in ASTERISK-24312. > > > Thanks, > > opticron > > -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4053: res_pjsip_history: A debugging module for busy systems
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4053/#review13516
---
/trunk/res/res_pjsip_history.c
<https://reviewboard.asterisk.org/r/4053/#comment24036>
Shouldn't ">" be ">=" instead?
- opticron
On Oct. 8, 2014, 8:55 a.m., Matt Jordan wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4053/
> ---
>
> (Updated Oct. 8, 2014, 8:55 a.m.)
>
>
> Review request for Asterisk Developers.
>
>
> Repository: Asterisk
>
>
> Description
> ---
>
> While debugging things at SIPit, I found that the capabilities afforded by
> res_pjsip_logger to be inadequate for tracing SIP messages on the CLI. Often,
> so many requests/responses were received -- often with very large SDPs -- in
> a short period of time that after a single call scenario, the initial
> requests/responses had already been expunged from the CLI buffer.
> Furthermore, displaying every single SIP request/response was often
> counterproductive - OPTIONS, SUBSCRIBE, and even REGISTER requests were often
> interleaved in the call scenarios, making it difficult to find or trace
> portions of a call.
>
> This isn't the fault of res_pjsip_logger: it was doing exactly what it was
> designed to do. And res_pjsip_logger is absolutely necessary for getting full
> logs when a problem occurs. However, it isn't designed for debugging things
> on the CLI. Hence, this module.
>
> res_pjsip_history records every request/response received/transmitted through
> the PJSIP stack, but does not bother dumping them to the CLI. Instead, it
> provides a few CLI comamnds to access the recorded messages:
>
> * pjsip set history {on|off} - enable/disable the history
> * pjsip show history [min [max]] - display the entire history, or segments of
> the history.
> * pjsip show entry {num} - display a particular history entry
>
> Because we store all received/transmitted requests/responses, the module is
> only suitable for debugging purposes. Leaving it permanently odd is a bad
> idea, for obvious reasons. When the history is turned off, all messages are
> purged and the history reset.
>
> As an example, we can record some history and display all of the messages:
>
> *CLI> pjsip show history
> No. Timestamp Rx/Tx AddressCall-ID SIP Message
> ==
> 1412775534.791 RX: 127.0.0.1:22428 d56324c8f042034aae29 OPTIONS
> sip:127.0.0.1 SIP/2.0
> 0001 1412775534.792 TX: 127.0.0.1:22428 d56324c8f042034aae29 SIP/2.0 200 OK
> 0002 1412775540.277 RX: 127.0.0.1:22428 86cd74e458e76b79e267 OPTIONS
> sip:127.0.0.1 SIP/2.0
> 0003 1412775540.277 TX: 127.0.0.1:22428 86cd74e458e76b79e267 SIP/2.0 200 OK
> 0004 1412775541.763 RX: 127.0.0.1:22428 f4c0050f5b604fc52ecc INVITE
> sip:200@127.0.0.1 SIP/2.0
> 0005 1412775541.765 TX: 127.0.0.1:22428 f4c0050f5b604fc52ecc SIP/2.0 200 OK
> 0006 1412775541.766 TX: 127.0.0.1:22428 f4c0050f5b604fc52ecc SIP/2.0 200 OK
> 0007 1412775541.780 RX: 127.0.0.1:22428 f4c0050f5b604fc52ecc ACK
> sip:127.0.0.1:5060 SIP/2.0
> 0008 1412775543.767 RX: 127.0.0.1:22428 f4c0050f5b604fc52ecc BYE
> sip:127.0.0.1:5060 SIP/2.0
> 0009 1412775543.768 TX: 127.0.0.1:22428 f4c0050f5b604fc52ecc SIP/2.0 200 OK
> 0010 1412775547.823 RX: 127.0.0.1:22428 ab6fc9f37aa1dc5ed038 SUBSCRIBE
> sip:1000@127.0.0.1 SIP/2.0
> 0011 1412775547.824 TX: 127.0.0.1:22428 ab6fc9f37aa1dc5ed038 SIP/2.0 481
> Call/Transaction Does Not Exist
> 0012 1412775547.826 RX: 127.0.0.1:22428 ba4ed4625cbb3282b34c REGISTER
> sip:127.0.0.1 SIP/2.0
> 0013 1412775547.841 TX: 127.0.0.1:22428 ba4ed4625cbb3282b34c SIP/2.0 200 OK
> 0014 1412775549.854 RX: 127.0.0.1:34899 ca022bf6e5a31b306bfd REGISTER
> sip:127.0.0.1 SIP/2.0
> 0015 1412775549.870 TX: 127.0.0.1:34899 ca022bf6e5a31b306bfd SIP/2.0 200 OK
> 0016 1412775549.876 RX: 127.0.0.1:34899 d92c91d540a36d2cbca1 SUBSCRIBE
> sip:1000@127.0.0.1 SIP/2.0
> 0017 1412775549.876 TX: 127.0.0.1:34899 d92c91d540a36d2cbca1 SIP/2.0 200 OK
> 0018 1412775549.877 TX: 127.0.0.1:34899 d92c91d540a36d2cbca1 NOTIFY
> sip:1000@127.0.0.1:34899;transport=udp;registering_acc=127_0_0_1 SIP/2.0
> 0019 1412775549.877 RX: 127.0.0.1:34899 32cca4f61cbba6cbe47f OPTIONS
> sip:127.0.0.1 SIP/2.0
> 0020 1412775549.877 TX: 127.0.0.1:34899 32cca4f61cbba6cbe47f SIP/2.0 200 OK
> 0021 1412775549.889 RX: 127.0.0.1:3489
Re: [asterisk-dev] [Code Review] 4067: CallerID: Fix parsing regression
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4067/ --- (Updated Oct. 10, 2014, 7:55 a.m.) Status -- This change has been marked as submitted. Review request for Asterisk Developers. Changes --- Committed in revision 425152 Bugs: ASTERISK-24406 https://issues.asterisk.org/jira/browse/ASTERISK-24406 Repository: Asterisk Description --- This fixes a regression in callerid parsing introduced when another bug was fixed. This bug occurred when the name was composed entirely of DTMF keys and quoted without a number section (<>). Diffs - branches/1.8/tests/test_callerid.c 424965 branches/1.8/main/callerid.c 424965 Diff: https://reviewboard.asterisk.org/r/4067/diff/ Testing --- Verified that the patch fixed the reporter's reproduction and verified that the new unit test passes with the patch and fails without it. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4038: Testsuite: Process REF_DEBUG logs, fail any test that leaks
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4038/#review13484 --- /asterisk/trunk/runtests.py <https://reviewboard.asterisk.org/r/4038/#comment24006> This doesn't appear to be used at all. /asterisk/trunk/runtests.py <https://reviewboard.asterisk.org/r/4038/#comment24008> These should use os.path.join. /asterisk/trunk/runtests.py <https://reviewboard.asterisk.org/r/4038/#comment24007> These should use os.path.join. - opticron On Oct. 1, 2014, 5:29 p.m., Corey Farrell wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4038/ > --- > > (Updated Oct. 1, 2014, 5:29 p.m.) > > > Review request for Asterisk Developers. > > > Bugs: ASTERISK-24379 > https://issues.asterisk.org/jira/browse/ASTERISK-24379 > > > Repository: testsuite > > > Description > --- > > This causes any test that leaks references to fail if REF_DEBUG is enabled. > > Additionally run-local is modified to allow REF_DEBUG to be enabled through > setup: > MENUSELECT_OPTIONS='--enable REF_DEBUG' ./run-local setup > > Note if this option is used with Asterisk 1.8 all tests will fail due to > manager.c leaking the sessions container. > > > Diffs > - > > /asterisk/trunk/runtests.py 5655 > /asterisk/trunk/run-local 5655 > > Diff: https://reviewboard.asterisk.org/r/4038/diff/ > > > Testing > --- > > Ran against tests/channels/SIP/route on Asterisk 11 with and without r4037 > applied. Test fails without, passes with. > > > 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] 4067: CallerID: Fix parsing regression
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4067/ --- (Updated Oct. 9, 2014, 2:37 p.m.) Review request for Asterisk Developers. Changes --- Address Richard's comments. Bugs: ASTERISK-24406 https://issues.asterisk.org/jira/browse/ASTERISK-24406 Repository: Asterisk Description --- This fixes a regression in callerid parsing introduced when another bug was fixed. This bug occurred when the name was composed entirely of DTMF keys and quoted without a number section (<>). Diffs (updated) - branches/1.8/tests/test_callerid.c 424965 branches/1.8/main/callerid.c 424965 Diff: https://reviewboard.asterisk.org/r/4067/diff/ Testing --- Verified that the patch fixed the reporter's reproduction and verified that the new unit test passes with the patch and fails without it. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] [Code Review] 4067: CallerID: Fix parsing regression
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4067/ --- Review request for Asterisk Developers. Bugs: ASTERISK-24406 https://issues.asterisk.org/jira/browse/ASTERISK-24406 Repository: Asterisk Description --- This fixes a regression in callerid parsing introduced when another bug was fixed. This bug occurred when the name was composed entirely of DTMF keys and quoted without a number section (<>). Diffs - branches/1.8/tests/test_callerid.c 424965 branches/1.8/main/callerid.c 424965 Diff: https://reviewboard.asterisk.org/r/4067/diff/ Testing --- Verified that the patch fixed the reporter's reproduction and verified that the new unit test passes with the patch and fails without it. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4049: res_fax: Fix reference leak caused by gateway sessions being added to faxregistry.container twice
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4049/#review13482 --- Ship it! Ship It! - opticron On Oct. 7, 2014, 2:04 p.m., Corey Farrell wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4049/ > --- > > (Updated Oct. 7, 2014, 2:04 p.m.) > > > Review request for Asterisk Developers. > > > Bugs: ASTERISK-24392 > https://issues.asterisk.org/jira/browse/ASTERISK-24392 > > > Repository: Asterisk > > > Description > --- > > Reserved fax gateway sessions are added to faxregistry.container, then added > again when the session is 'really' created. It seems that when it is > re-added it adds a second reference into the container due to the id being > different. Removal of the original list entry is not successful. This > prevents the session from ever being unallocated. > > > Diffs > - > > /branches/1.8/res/res_fax.c 424175 > > Diff: https://reviewboard.asterisk.org/r/4049/diff/ > > > Testing > --- > > Verified this resolves the leak in 11 and 12. > > > 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
[asterisk-dev] [Code Review] 4062: PJSIP: Enforce module load dependencies
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4062/ --- Review request for Asterisk Developers. Bugs: ASTERISK-24312 https://issues.asterisk.org/jira/browse/ASTERISK-24312 Repository: Asterisk Description --- This enforces that res_pjsip, res_pjsip_session, and res_pjsip_pubsub have loaded properly before attempting to load any modules that depend on them since the module loader system is not currently capable of resolving module dependencies on its own. Diffs - branches/12/res/res_pjsip_xpidf_body_generator.c 424849 branches/12/res/res_pjsip_transport_websocket.c 424849 branches/12/res/res_pjsip_t38.c 424849 branches/12/res/res_pjsip_session.c 424849 branches/12/res/res_pjsip_send_to_voicemail.c 424849 branches/12/res/res_pjsip_sdp_rtp.c 424849 branches/12/res/res_pjsip_rfc3326.c 424849 branches/12/res/res_pjsip_registrar_expire.c 424849 branches/12/res/res_pjsip_registrar.c 424849 branches/12/res/res_pjsip_refer.c 424849 branches/12/res/res_pjsip_pubsub.c 424849 branches/12/res/res_pjsip_pidf_eyebeam_body_supplement.c 424849 branches/12/res/res_pjsip_pidf_digium_body_supplement.c 424849 branches/12/res/res_pjsip_pidf_body_generator.c 424849 branches/12/res/res_pjsip_path.c 424849 branches/12/res/res_pjsip_outbound_registration.c 424849 branches/12/res/res_pjsip_outbound_authenticator_digest.c 424849 branches/12/res/res_pjsip_one_touch_record_info.c 424849 branches/12/res/res_pjsip_notify.c 424849 branches/12/res/res_pjsip_nat.c 424849 branches/12/res/res_pjsip_mwi_body_generator.c 424849 branches/12/res/res_pjsip_mwi.c 424849 branches/12/res/res_pjsip_multihomed.c 424849 branches/12/res/res_pjsip_messaging.c 424849 branches/12/res/res_pjsip_logger.c 424849 branches/12/res/res_pjsip_header_funcs.c 424849 branches/12/res/res_pjsip_exten_state.c 424849 branches/12/res/res_pjsip_endpoint_identifier_user.c 424849 branches/12/res/res_pjsip_endpoint_identifier_ip.c 424849 branches/12/res/res_pjsip_endpoint_identifier_anonymous.c 424849 branches/12/res/res_pjsip_dtmf_info.c 424849 branches/12/res/res_pjsip_diversion.c 424849 branches/12/res/res_pjsip_dialog_info_body_generator.c 424849 branches/12/res/res_pjsip_caller_id.c 424849 branches/12/res/res_pjsip_authenticator_digest.c 424849 branches/12/res/res_pjsip_acl.c 424849 branches/12/res/res_hep_pjsip.c 424849 branches/12/include/asterisk/res_pjsip_session.h 424849 branches/12/include/asterisk/res_pjsip_pubsub.h 424849 branches/12/include/asterisk/res_pjsip.h 424849 branches/12/channels/chan_pjsip.c 424849 Diff: https://reviewboard.asterisk.org/r/4062/diff/ Testing --- Verified that this fixed the bug presented in ASTERISK-24312. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4054: Stasis: Reduce processing for declined message types
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4054/ --- (Updated Oct. 8, 2014, 1:11 p.m.) Status -- This change has been discarded. Review request for Asterisk Developers. Repository: Asterisk Description --- This change reduces the processing required (an AO2 lookup) for determining when an error message should be emitted if a Stasis message type is missing. Diffs - branches/13/main/stasis.c 424769 branches/13/include/asterisk/stasis.h 424425 Diff: https://reviewboard.asterisk.org/r/4054/diff/ Testing --- Verified that the media indexer could be disabled without error messages showing up incorrectly. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] [Code Review] 4054: Stasis: Reduce processing for declined message types
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4054/ --- Review request for Asterisk Developers. Repository: Asterisk Description --- This change reduces the processing required (an AO2 lookup) for determining when an error message should be emitted if a Stasis message type is missing. Diffs - branches/13/main/stasis.c 424769 branches/13/include/asterisk/stasis.h 424425 Diff: https://reviewboard.asterisk.org/r/4054/diff/ Testing --- Verified that the media indexer could be disabled without error messages showing up incorrectly. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4049: res_fax: Fix reference leak caused by gateway sessions being added to faxregistry.container twice
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4049/#review13461 --- /branches/1.8/res/res_fax.c <https://reviewboard.asterisk.org/r/4049/#comment23986> I can't seem to find where the reserved session is actually linked into the faxregistry container. Have you verified that everything is properly balanced in the ref logs with this patch? - opticron On Oct. 5, 2014, 10:10 p.m., Corey Farrell wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4049/ > --- > > (Updated Oct. 5, 2014, 10:10 p.m.) > > > Review request for Asterisk Developers. > > > Bugs: ASTERISK-24392 > https://issues.asterisk.org/jira/browse/ASTERISK-24392 > > > Repository: Asterisk > > > Description > --- > > Reserved fax gateway sessions are added to faxregistry.container, then added > again when the session is 'really' created. It seems that when it is > re-added it adds a second reference into the container due to the id being > different. Removal of the original list entry is not successful. This > prevents the session from ever being unallocated. > > > Diffs > - > > /branches/1.8/res/res_fax.c 424175 > > Diff: https://reviewboard.asterisk.org/r/4049/diff/ > > > Testing > --- > > Verified this resolves the leak in 11 and 12. > > > 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] 4033: manager/config: Enhancements to support templates and non-unique category names via AMI
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4033/#review13460 --- Ship it! Ship It! - opticron On Oct. 2, 2014, 3:33 p.m., George Joseph wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4033/ > --- > > (Updated Oct. 2, 2014, 3:33 p.m.) > > > Review request for Asterisk Developers. > > > Repository: Asterisk > > > Description > --- > > This patch provides the capability to manipulate templates and categories > with non-unique names via AMI. > > Summary of changes: > > GetConfig and GetConfigJSON: > Added "Filter" parameter: A comma separated list of name_regex=value_regex > expressions which will cause only categories whose variables match all > expressions to be considered. The special variable name TEMPLATES can be > used to control whether templates are included. Passing 'include' as the > value will include templates along with normal categories. Passing 'restrict' > as the value will restrict the operation to ONLY templates. Not specifying a > TEMPLATES expression results in the current default behavior which is to not > include templates. > > Examples: > "GetConfig?Filename=pjsip.conf&Category=myitsp&Filter=type=aor" would return > only 'myitsp' categories with a type of 'aor'. > > "GetConfig?Filename=pjsip.conf&Category=itsp-template&Filter=TEMPLATES=restrict,type=aor" > would return only 'itsp-template' categories that are actually templates > with a type of 'aor'. > > "GetConfig?Filename=pjsip.conf&Filter=type=registration,endpoint=myitsp" > would return only registrations whose corresponding endpoint is 'myitsp'. > > The output from GetConfig and GetConfigJSON also includes variables > indicating if the returned category is a template and the template names a > category inherits from if any. > > UpdateConfig: > NewCat now includes options for allowing duplicate category names, indicating > if the category should be created as a template, and specifying templates the > category should inherit from. The rest of the actions now accept a filter > string as defined above. If there are non-unique category names, you can now > update specific ones based on variable values. > > To facilitate the new capabilities in manager, corresponding changes had to > be made to config, most notably the addition of filter criteria to many of > the APIs. In some cases it was easy to change the references to use the new > prototype but others would have required touching too many files for this > patch so a wrapper with the original prototype was created. Macros couldn't > be used in this case because it would break binary compatibility with modules > such as res_digium_phone that are linked to real symbols. > > > Diffs > - > > branches/12/tests/test_sorcery_realtime.c 424332 > branches/12/tests/test_sorcery.c 424332 > branches/12/tests/test_config.c 424332 > branches/12/res/res_sorcery_realtime.c 424332 > branches/12/res/res_sorcery_config.c 424332 > branches/12/pbx/pbx_realtime.c 424332 > branches/12/main/manager.c 424332 > branches/12/main/config.c 424332 > branches/12/include/asterisk/config.h 424332 > branches/12/apps/app_voicemail.c 424332 > branches/12/apps/app_directory.c 424332 > > Diff: https://reviewboard.asterisk.org/r/4033/diff/ > > > Testing > --- > > Testsuite before and after runs gave the same results. > A set of unit tests for config was added to test_config. They test basic, > filtered and template operations. > > > 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] 4040: Manager: Add missing fields and documentation for CoreShowChannels
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4040/ --- (Updated Oct. 3, 2014, 8:24 a.m.) Status -- This change has been marked as submitted. Review request for Asterisk Developers. Changes --- Committed in revision 424423 Bugs: ASTERISK-24262 https://issues.asterisk.org/jira/browse/ASTERISK-24262 Repository: Asterisk Description --- This corrects some issues introduced in the responses to the CoreShowChannels AMI command as well as adding documentation for the responses. The command in Asterisk 12 was missing the following fields: Duration, Application, ApplicationData, and BridgedChannel and BridgedUniqueID (replaced with BridgeId). Diffs - branches/12/main/manager.c 424263 Diff: https://reviewboard.asterisk.org/r/4040/diff/ Testing --- Verified that the missing functionality was restored. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4033: manager/config: Enhancements to support templates and non-unique category names via AMI
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4033/#review13441 --- branches/12/main/config.c <https://reviewboard.asterisk.org/r/4033/#comment23973> These changes alter the behavior of ast_variable_retrieve slightly when parameter "category" is NULL. Previously, it would search through all categories in order looking for the first instance of the specified variable. Now, it looks at the first category for the specified variable but not subsequent categories. branches/12/main/manager.c <https://reviewboard.asterisk.org/r/4033/#comment23975> This needs a bit of cleanup in a few areas. The tabbing is in need of repair and there are empty para tags. branches/12/main/manager.c <https://reviewboard.asterisk.org/r/4033/#comment23976> This appears to be debugging and should go away. - opticron On Sept. 30, 2014, 4:24 p.m., George Joseph wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4033/ > --- > > (Updated Sept. 30, 2014, 4:24 p.m.) > > > Review request for Asterisk Developers. > > > Repository: Asterisk > > > Description > --- > > This patch provides the capability to manipulate templates and categories > with non-unique names via AMI. > > Summary of changes: > > GetConfig and GetConfigJSON: > Added "Filter" parameter: A comma separated list of name_regex=value_regex > expressions which will cause only categories whose variables match all > expressions to be considered. The special variable name TEMPLATES can be > used to control whether templates are included. Passing 'include' as the > value will include templates along with normal categories. Passing 'restrict' > as the value will restrict the operation to ONLY templates. Not specifying a > TEMPLATES expression results in the current default behavior which is to not > include templates. > > Examples: > "GetConfig?Filename=pjsip.conf&Category=myitsp&Filter=type=aor" would return > only 'myitsp' categories with a type of 'aor'. > > "GetConfig?Filename=pjsip.conf&Category=itsp-template&Filter=TEMPLATES=restrict,type=aor" > would return only 'itsp-template' categories that are actually templates > with a type of 'aor'. > > "GetConfig?Filename=pjsip.conf&Filter=type=registration,endpoint=myitsp" > would return only registrations whose corresponding endpoint is 'myitsp'. > > The output from GetConfig and GetConfigJSON also includes variables > indicating if the returned category is a template and the template names a > category inherits from if any. > > UpdateConfig: > NewCat now includes options for allowing duplicate category names, indicating > if the category should be created as a template, and specifying templates the > category should inherit from. The rest of the actions now accept a filter > string as defined above. If there are non-unique category names, you can now > update specific ones based on variable values. > > To facilitate the new capabilities in manager, corresponding changes had to > be made to config, most notably the addition of filter criteria to many of > the APIs. In some cases it was easy to change the references to use the new > prototype but others would have required touching too many files for this > patch so a wrapper with the original prototype was created. Macros couldn't > be used in this case because it would break binary compatibility with modules > such as res_digium_phone that are linked to real symbols. > > > Diffs > - > > branches/12/tests/test_sorcery_realtime.c 424175 > branches/12/tests/test_sorcery.c 424175 > branches/12/tests/test_config.c 424175 > branches/12/res/res_sorcery_realtime.c 424175 > branches/12/res/res_sorcery_config.c 424175 > branches/12/pbx/pbx_realtime.c 424175 > branches/12/main/manager.c 424175 > branches/12/main/config.c 424175 > branches/12/include/asterisk/config.h 424175 > branches/12/apps/app_voicemail.c 424175 > branches/12/apps/app_directory.c 424175 > > Diff: https://reviewboard.asterisk.org/r/4033/diff/ > > > Testing > --- > > Testsuite before and after runs gave the same results. > A set of unit tests for config was added to test_config. They test basic, > filtered and template operations. > > > 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] 4020: RLS Tests: off nominal tests for lists of lists (MWI and presence)
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4020/#review13437 --- Ship it! This set of tests looks good to go. Minor nitpick below. /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/shared_name_wo_list_support/test-config.yaml <https://reviewboard.asterisk.org/r/4020/#comment23968> This is unnecessary for this test. - opticron On Sept. 30, 2014, 3:54 p.m., Jonathan Rose wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4020/ > --- > > (Updated Sept. 30, 2014, 3:54 p.m.) > > > Review request for Asterisk Developers and Mark Michelson. > > > Bugs: ASTERISK-23873 > https://issues.asterisk.org/jira/browse/ASTERISK-23873 > > > Repository: testsuite > > > Description > --- > > A series tests meant to cover the off-nominal test descriptions for lists of > lists described on this wiki page: > https://wiki.asterisk.org/wiki/display/AST/Resource+List+Subscription+Test+Plan > > > Diffs > - > > > /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/tests.yaml > 5643 > > /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/tests.yaml > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/tests.yaml > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/shared_name_wo_list_support/test-config.yaml > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/shared_name_wo_list_support/sipp/presence_subscription.xml > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/shared_name_wo_list_support/configs/ast1/pjsip.conf > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/shared_name_wo_list_support/configs/ast1/extensions.conf > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/shared_name_w_list_support/test-config.yaml > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/shared_name_w_list_support/sipp/list_subscribe.xml > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/shared_name_w_list_support/configs/ast1/pjsip.conf > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/shared_name_w_list_support/configs/ast1/extensions.conf > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/resource_duplication/test-config.yaml > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/resource_duplication/sipp/list_subscribe.xml > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/resource_duplication/configs/ast1/pjsip.conf > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/resource_duplication/configs/ast1/extensions.conf > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/mwi/tests.yaml > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/mwi/shared_name_wo_list_support/test-config.yaml > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/mwi/shared_name_wo_list_support/sipp/mwi_subscription.xml > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/mwi/shared_name_wo_list_support/configs/ast1/pjsip.conf > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/mwi/shared_name_w_list_support/test-config.yaml > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/mwi/shared_name_w_list_support/sipp/list_subscribe.xml > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/mwi/shared_name_w_list_support/configs/ast1/pjsip.conf > PRE-C
[asterisk-dev] [Code Review] 4040: Manager: Add missing fields and documentation for CoreShowChannels
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4040/ --- Review request for Asterisk Developers. Bugs: ASTERISK-24262 https://issues.asterisk.org/jira/browse/ASTERISK-24262 Repository: Asterisk Description --- This corrects some issues introduced in the responses to the CoreShowChannels AMI command as well as adding documentation for the responses. The command in Asterisk 12 was missing the following fields: Duration, Application, ApplicationData, and BridgedChannel and BridgedUniqueID (replaced with BridgeId). Diffs - branches/12/main/manager.c 424263 Diff: https://reviewboard.asterisk.org/r/4040/diff/ Testing --- Verified that the missing functionality was restored. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4019: PJSIP: Handle defaults properly
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4019/ --- (Updated Oct. 1, 2014, 7:24 a.m.) Status -- This change has been marked as submitted. Review request for Asterisk Developers. Changes --- Committed in revision 424263 Repository: Asterisk Description --- This updates the code behind PJSIP configuration options with custom handlers to deal with the assigned default values properly where it makes sense and adjusting the default value where it doesn't. Before applying this patch, there were several cases where the default value for an option would prevent that config section from loading properly. Diffs - branches/12/res/res_pjsip_endpoint_identifier_ip.c 423656 branches/12/res/res_pjsip/pjsip_configuration.c 423656 branches/12/res/res_pjsip/location.c 423656 branches/12/res/res_pjsip/config_transport.c 423656 branches/12/configs/pjsip.conf.sample 423656 Diff: https://reviewboard.asterisk.org/r/4019/diff/ Testing --- Ensured that default values for config options were accepted. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4032: PJSIP: Force transport on contact rewrite
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4032/ --- (Updated Oct. 1, 2014, 7:13 a.m.) Status -- This change has been marked as submitted. Review request for Asterisk Developers. Changes --- Committed in revision 424244 Repository: Asterisk Description --- If contact rewriting is enabled but the contact differs in transport from what is actually being used, messages after the initial INVITE transaction can be sent to an incorrect transport/port combination. In the case where this bug occurred the remote party never received a BYE since it was sent to the remote party's TCP port over UDP. Diffs - branches/12/res/res_pjsip_nat.c 424094 Diff: https://reviewboard.asterisk.org/r/4032/diff/ Testing --- Ensured that this patch allowed the BYE to be sent properly. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 2964: res_pjsip_outbound_registration: Add "virtual line" support for automatic inbound matching
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/2964/#review13418 --- /trunk/res/res_pjsip_outbound_registration.c <https://reviewboard.asterisk.org/r/2964/#comment23942> pj_create_random_string() does not NULL-terminate the buffer when generating the string. This should be taken care of manually and space allotted for the NULL terminator. - opticron On Sept. 13, 2014, 5:44 a.m., Joshua Colp wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/2964/ > --- > > (Updated Sept. 13, 2014, 5:44 a.m.) > > > Review request for Asterisk Developers. > > > Repository: Asterisk > > > Description > --- > > This patch adds "virtual line" support to the res_pjsip_outbound_registration > module. This is an optional feature and simply adds a "line" URI parameter to > the Contact we place in the outbound registration. If this line parameter is > present on incoming requests we use it to establish a relationship to the > outbound registration and match it to a user configured endpoint. This has > the benefit that when registering to another server where it is supported you > no longer have to do IP based matching for all of their potential servers. > The downside (and why this is optional) is that if a third party got the line > parameter they could send you calls as if they were the legit remote server. > > > Diffs > - > > /trunk/res/res_pjsip_outbound_registration.c 423063 > /trunk/configs/samples/pjsip.conf.sample 423063 > > Diff: https://reviewboard.asterisk.org/r/2964/diff/ > > > Testing > --- > > Registered to an ITSP, placed an inbound call from them, confirmed matched > using line parameter. > > Registered to a chan_sip instance, placed an inbound call from it, confirmed > matched using line parameter. > > > 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] 4020: RLS Tests: off nominal tests for lists of lists (MWI and presence)
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4020/#review13407 --- /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/mwi/resource_duplication/sipp/list_subscribe.xml <https://reviewboard.asterisk.org/r/4020/#comment23897> Do not reuse variables for regex matching. /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/mwi/resource_duplication/test-config.yaml <https://reviewboard.asterisk.org/r/4020/#comment23896> s/lsited/listed/ /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/mwi/shared_name_w_list_support/sipp/list_subscribe.xml <https://reviewboard.asterisk.org/r/4020/#comment23898> Idem. /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/resource_duplication/sipp/list_subscribe.xml <https://reviewboard.asterisk.org/r/4020/#comment23899> Idem. /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/shared_name_w_list_support/sipp/list_subscribe.xml <https://reviewboard.asterisk.org/r/4020/#comment23900> Idem. - opticron On Sept. 24, 2014, 5:28 p.m., Jonathan Rose wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4020/ > --- > > (Updated Sept. 24, 2014, 5:28 p.m.) > > > Review request for Asterisk Developers and Mark Michelson. > > > Bugs: ASTERISK-23873 > https://issues.asterisk.org/jira/browse/ASTERISK-23873 > > > Repository: testsuite > > > Description > --- > > A series tests meant to cover the off-nominal test descriptions for lists of > lists described on this wiki page: > https://wiki.asterisk.org/wiki/display/AST/Resource+List+Subscription+Test+Plan > > > Diffs > - > > > /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/tests.yaml > 5643 > > /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/tests.yaml > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/tests.yaml > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/shared_name_wo_list_support/test-config.yaml > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/shared_name_wo_list_support/sipp/presence_subscription.xml > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/shared_name_wo_list_support/configs/ast1/pjsip.conf > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/shared_name_wo_list_support/configs/ast1/extensions.conf > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/shared_name_w_list_support/test-config.yaml > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/shared_name_w_list_support/sipp/list_subscribe.xml > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/shared_name_w_list_support/configs/ast1/pjsip.conf > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/shared_name_w_list_support/configs/ast1/extensions.conf > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/resource_duplication/test-config.yaml > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/resource_duplication/sipp/list_subscribe.xml > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/resource_duplication/configs/ast1/pjsip.conf > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/presence/resource_duplication/configs/ast1/extensions.conf > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/mwi/tests.yaml > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/off_nominal/mwi/shared_name_wo_list_support/test-config.yaml > PRE-CREATION > > /asterisk/trunk/tests/channels/pjsip/s
Re: [asterisk-dev] [Code Review] 3970: res_phoneprov: Refactor phoneprov to allow pluggable config providers.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3970/#review13404 --- branches/12/include/asterisk/phoneprov.h <https://reviewboard.asterisk.org/r/3970/#comment23888> Document the return value for this typedef. branches/12/include/asterisk/phoneprov.h <https://reviewboard.asterisk.org/r/3970/#comment23889> This documentation conflicts with the prototype. branches/12/main/chanvars.c <https://reviewboard.asterisk.org/r/3970/#comment23890> Note that there should be an empty line after declarations. Apply this below as well. branches/12/res/res_phoneprov.c <https://reviewboard.asterisk.org/r/3970/#comment23891> s/whi/who/ branches/12/res/res_phoneprov.exports.in <https://reviewboard.asterisk.org/r/3970/#comment23893> This is unnecessary since there are no symbols that match it. - opticron On Sept. 18, 2014, 7:01 p.m., George Joseph wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3970/ > --- > > (Updated Sept. 18, 2014, 7:01 p.m.) > > > Review request for Asterisk Developers. > > > Repository: Asterisk > > > Description > --- > > The big piece missing for me to finally transition to pjsip was the ability > to mirror the auto provisioning features of res_phoneprov. The first step > (this patch) is to make res_phoneprov more modular so other modules (like > pjsip) can provide configuration information instead of res_phoneprov relying > solely on users.conf and sip.conf. To accomplish this a new ast_phoneprov > public API is now exposed which allows config providers to register > themselves, set defaults (server profile, etc) and add user extensions. > > ast_phoneprov_provider_register registers the provider and provides callbacks > for loading default settings and loading users. > ast_phoneprov_provider_unregister clears the defaults and users. > ast_phoneprov_add_extension should be called once for each user/extension by > the provider's load_users callback to add them. > ast_phoneprov_delete_extension deletes one extension. > ast_phoneprov_delete_extensions deletes all extensions for the provider. > > res_phoneprov actually registers itself as the provider for sip/users and is > always available and is the default. > > Writing a new provider... > Since res_phoneprov is also it's own provider, examples of what a new > provider would have to do are in load_users() in res_phoneprov.c. Those > functions gather the information from users.conf and sip.conf and call the > ast_provider_register and ast_phoneprov_add_extension apis. > > So... > The provider creates a callback function which calls the > ast_phoneprov_add_extension api for each user. > It then calls ast_phoneprov_provider_register with the callback. > res_phoneprov then calls the callback to cause the actual load. > During normal http server ops, all work is done by res_phoneprov and the > provider is never called again unless a reload is needed. > If the provider wants to reload it can simply unregister and reregister or it > can call its own load_users callback. > If res_phoneprov wants to reload, it iterates over its registry and calls the > providers callback. > > NOTE: If res_phoneprov is actually unloaded, it has no way to know what > providers were registered (other than itself) so a subsequent load will have > nothing but it's own users. > > Additional changes... > I added a few convenience functions to chanvars for creating lists and > finding and deleting entries. No existing code was touched. > > Next steps... > A provider for res_pjsip. > > > Diffs > - > > branches/12/res/res_phoneprov.exports.in PRE-CREATION > branches/12/res/res_phoneprov.c 423501 > branches/12/main/chanvars.c 423501 > branches/12/include/asterisk/phoneprov.h PRE-CREATION > branches/12/include/asterisk/chanvars.h 423501 > branches/12/configs/phoneprov.conf.sample 423501 > > Diff: https://reviewboard.asterisk.org/r/3970/diff/ > > > Testing > --- > > I ran through several scenarios including the use of PP_EACH_USER and > PP_EACH_EXTENSION to make sure that all existing functionality was preserved. > I actually use it with Grandstream phones and everything worked exactly as > expected. > > > 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] 4032: PJSIP: Force transport on contact rewrite
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4032/ --- (Updated Sept. 30, 2014, 7:19 a.m.) Review request for Asterisk Developers. Changes --- Correct inverted logic. Repository: Asterisk Description --- If contact rewriting is enabled but the contact differs in transport from what is actually being used, messages after the initial INVITE transaction can be sent to an incorrect transport/port combination. In the case where this bug occurred the remote party never received a BYE since it was sent to the remote party's TCP port over UDP. Diffs (updated) - branches/12/res/res_pjsip_nat.c 424094 Diff: https://reviewboard.asterisk.org/r/4032/diff/ Testing --- Ensured that this patch allowed the BYE to be sent properly. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4032: PJSIP: Force transport on contact rewrite
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4032/ --- (Updated Sept. 29, 2014, 6:53 p.m.) Review request for Asterisk Developers. Changes --- Address Josh's comment. Repository: Asterisk Description --- If contact rewriting is enabled but the contact differs in transport from what is actually being used, messages after the initial INVITE transaction can be sent to an incorrect transport/port combination. In the case where this bug occurred the remote party never received a BYE since it was sent to the remote party's TCP port over UDP. Diffs (updated) - branches/12/res/res_pjsip_nat.c 424094 Diff: https://reviewboard.asterisk.org/r/4032/diff/ Testing --- Ensured that this patch allowed the BYE to be sent properly. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4032: PJSIP: Force transport on contact rewrite
> On Sept. 29, 2014, 2:47 p.m., Joshua Colp wrote: > > branches/12/res/res_pjsip_nat.c, line 49 > > <https://reviewboard.asterisk.org/r/4032/diff/1/?file=67680#file67680line49> > > > > What will this do for UDP transport? For those the transport should be > > empty. "udp" is also a valid transport along with "tls", "ws", and others. Is there a benefit to leaving it blank if the transport is UDP? - opticron --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4032/#review13400 --- On Sept. 29, 2014, 2:25 p.m., opticron wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4032/ > --- > > (Updated Sept. 29, 2014, 2:25 p.m.) > > > Review request for Asterisk Developers. > > > Repository: Asterisk > > > Description > --- > > If contact rewriting is enabled but the contact differs in transport from > what is actually being used, messages after the initial INVITE transaction > can be sent to an incorrect transport/port combination. In the case where > this bug occurred the remote party never received a BYE since it was sent to > the remote party's TCP port over UDP. > > > Diffs > - > > branches/12/res/res_pjsip_nat.c 424094 > > Diff: https://reviewboard.asterisk.org/r/4032/diff/ > > > Testing > --- > > Ensured that this patch allowed the BYE to be sent properly. > > > Thanks, > > opticron > > -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] [Code Review] 4032: PJSIP: Force transport on contact rewrite
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4032/ --- Review request for Asterisk Developers. Repository: Asterisk Description --- If contact rewriting is enabled but the contact differs in transport from what is actually being used, messages after the initial INVITE transaction can be sent to an incorrect transport/port combination. In the case where this bug occurred the remote party never received a BYE since it was sent to the remote party's TCP port over UDP. Diffs - branches/12/res/res_pjsip_nat.c 424094 Diff: https://reviewboard.asterisk.org/r/4032/diff/ Testing --- Ensured that this patch allowed the BYE to be sent properly. Thanks, opticron -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
