[asterisk-dev] [Code Review] 4003: 503 incorrectly sent to rentransmitted invites
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4003/ --- Review request for Asterisk Developers. Repository: Asterisk Description --- Scenario INVITE arrives to asterisk, asterisk responds Busy() If the INVITE is retransmitted, asterisk will generate a 503 in addition to the 486. Patch ensures a 2nd response isn't generated to an already responded INVITE Diffs - http://svn.asterisk.org/svn/asterisk/branches/11/channels/chan_sip.c 423250 Diff: https://reviewboard.asterisk.org/r/4003/diff/ Testing --- Asterisk testsuite test has been created to reproduce this error Thanks, Torrey Searle -- _ -- 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] 4003: 503 incorrectly sent to rentransmitted invites
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4003/ --- (Updated Sept. 19, 2014, 6:52 a.m.) Review request for Asterisk Developers. Bugs: ASTERISK-24335 https://issues.asterisk.org/jira/browse/ASTERISK-24335 Repository: Asterisk Description --- Scenario INVITE arrives to asterisk, asterisk responds Busy() If the INVITE is retransmitted, asterisk will generate a 503 in addition to the 486. Patch ensures a 2nd response isn't generated to an already responded INVITE Diffs - http://svn.asterisk.org/svn/asterisk/branches/11/channels/chan_sip.c 423250 Diff: https://reviewboard.asterisk.org/r/4003/diff/ Testing --- Asterisk testsuite test has been created to reproduce this error Thanks, Torrey Searle -- _ -- 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] 4003: 503 incorrectly sent to rentransmitted invites
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4003/#review13363 --- Ship it! LGTM. Please commit it against 1.8. - wdoekes On Sept. 19, 2014, 6:52 a.m., Torrey Searle wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4003/ --- (Updated Sept. 19, 2014, 6:52 a.m.) Review request for Asterisk Developers. Bugs: ASTERISK-24335 https://issues.asterisk.org/jira/browse/ASTERISK-24335 Repository: Asterisk Description --- Scenario INVITE arrives to asterisk, asterisk responds Busy() If the INVITE is retransmitted, asterisk will generate a 503 in addition to the 486. Patch ensures a 2nd response isn't generated to an already responded INVITE Diffs - http://svn.asterisk.org/svn/asterisk/branches/11/channels/chan_sip.c 423250 Diff: https://reviewboard.asterisk.org/r/4003/diff/ Testing --- Asterisk testsuite test has been created to reproduce this error Thanks, Torrey Searle -- _ -- 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] 4003: 503 incorrectly sent to rentransmitted invites
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4003/ --- (Updated Sept. 19, 2014, 7:25 a.m.) Review request for Asterisk Developers. Changes --- Test case attached Bugs: ASTERISK-24335 https://issues.asterisk.org/jira/browse/ASTERISK-24335 Repository: Asterisk Description --- Scenario INVITE arrives to asterisk, asterisk responds Busy() If the INVITE is retransmitted, asterisk will generate a 503 in addition to the 486. Patch ensures a 2nd response isn't generated to an already responded INVITE Diffs - http://svn.asterisk.org/svn/asterisk/branches/11/channels/chan_sip.c 423250 Diff: https://reviewboard.asterisk.org/r/4003/diff/ Testing --- Asterisk testsuite test has been created to reproduce this error File Attachments (updated) test case https://reviewboard.asterisk.org/media/uploaded/files/2014/09/19/ec4a3ce5-8148-4b03-830e-299572f2fb3e__invite_retransmit.tgz Thanks, Torrey Searle -- _ -- 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] 4003: 503 incorrectly sent to rentransmitted invites
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4003/#review13364 --- If it's not too much trouble, don't attach the test case as tgz, but create a separate review for it. Patch http://svn.asterisk.org/svn/testsuite/asterisk/trunk with it and create a review from that. - wdoekes On Sept. 19, 2014, 7:25 a.m., Torrey Searle wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4003/ --- (Updated Sept. 19, 2014, 7:25 a.m.) Review request for Asterisk Developers. Bugs: ASTERISK-24335 https://issues.asterisk.org/jira/browse/ASTERISK-24335 Repository: Asterisk Description --- Scenario INVITE arrives to asterisk, asterisk responds Busy() If the INVITE is retransmitted, asterisk will generate a 503 in addition to the 486. Patch ensures a 2nd response isn't generated to an already responded INVITE Diffs - http://svn.asterisk.org/svn/asterisk/branches/11/channels/chan_sip.c 423250 Diff: https://reviewboard.asterisk.org/r/4003/diff/ Testing --- Asterisk testsuite test has been created to reproduce this error File Attachments test case https://reviewboard.asterisk.org/media/uploaded/files/2014/09/19/ec4a3ce5-8148-4b03-830e-299572f2fb3e__invite_retransmit.tgz Thanks, Torrey Searle -- _ -- 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] 4006: Test to validate 503 not generated on INVITE retransmissions
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4006/ --- Review request for Asterisk Developers. Bugs: ASTERISK-24335 https://issues.asterisk.org/jira/browse/ASTERISK-24335 Repository: testsuite Description --- This is a test for the test suite to reproduce the issue described in ASTERISK-24335 Diffs - /asterisk/trunk/tests/channels/SIP/tests.yaml 5608 /asterisk/trunk/tests/channels/SIP/invite_retransmit/test-config.yaml PRE-CREATION /asterisk/trunk/tests/channels/SIP/invite_retransmit/sipp/A_PARTY.xml PRE-CREATION /asterisk/trunk/tests/channels/SIP/invite_retransmit/run-test PRE-CREATION /asterisk/trunk/tests/channels/SIP/invite_retransmit/configs/ast1/sip.conf PRE-CREATION /asterisk/trunk/tests/channels/SIP/invite_retransmit/configs/ast1/extensions.conf PRE-CREATION Diff: https://reviewboard.asterisk.org/r/4006/diff/ Testing --- test passes when 4003 patch applied, fails when patch not applied Thanks, Torrey Searle -- _ -- 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] 4003: 503 incorrectly sent to rentransmitted invites
On Sept. 19, 2014, 7:48 a.m., wdoekes wrote: If it's not too much trouble, don't attach the test case as tgz, but create a separate review for it. Patch http://svn.asterisk.org/svn/testsuite/asterisk/trunk with it and create a review from that. https://reviewboard.asterisk.org/r/4006/ - Torrey --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4003/#review13364 --- On Sept. 19, 2014, 7:25 a.m., Torrey Searle wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4003/ --- (Updated Sept. 19, 2014, 7:25 a.m.) Review request for Asterisk Developers. Bugs: ASTERISK-24335 https://issues.asterisk.org/jira/browse/ASTERISK-24335 Repository: Asterisk Description --- Scenario INVITE arrives to asterisk, asterisk responds Busy() If the INVITE is retransmitted, asterisk will generate a 503 in addition to the 486. Patch ensures a 2nd response isn't generated to an already responded INVITE Diffs - http://svn.asterisk.org/svn/asterisk/branches/11/channels/chan_sip.c 423250 Diff: https://reviewboard.asterisk.org/r/4003/diff/ Testing --- Asterisk testsuite test has been created to reproduce this error File Attachments test case https://reviewboard.asterisk.org/media/uploaded/files/2014/09/19/ec4a3ce5-8148-4b03-830e-299572f2fb3e__invite_retransmit.tgz Thanks, Torrey Searle -- _ -- 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] 3924: Testsuite: Add modular event action framework
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3924/ --- (Updated Sept. 19, 2014, 7:50 a.m.) Status -- This change has been marked as submitted. Review request for Asterisk Developers. Changes --- Committed in revision 5609 Repository: testsuite Description --- This adds a modular event/action system that can handle routing from arbitrary events to arbitrary actions allowing creation of more flexible tests. This includes event modules for AMI and ARI actions as well as action modules for AMI, ARI, callbacks, and more. This also converts three tests as a proof of concept. Diffs - asterisk/trunk/tests/rest_api/bridges/bridge_by_id/test-config.yaml 5568 asterisk/trunk/tests/rest_api/bridges/attended_transfer/test-config.yaml 5568 asterisk/trunk/tests/rest_api/bridges/attended_transfer/attended_transfer.py 5568 asterisk/trunk/tests/asyncagi/asyncagi_break/test-config.yaml 5568 asterisk/trunk/tests/asyncagi/asyncagi_break/asyncagi_break.py 5568 asterisk/trunk/lib/python/asterisk/pluggable_registry.py PRE-CREATION asterisk/trunk/lib/python/asterisk/pluggable_modules.py 5568 asterisk/trunk/lib/python/asterisk/ari.py 5568 asterisk/trunk/lib/python/asterisk/ami.py 5568 Diff: https://reviewboard.asterisk.org/r/3924/diff/ Testing --- Ran the tests and verified that events and actions were triggering 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] 4007: testsuite: pick test suite temp dir based on free space
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4007/ --- Review request for Asterisk Developers. Repository: testsuite Description --- On CentOS 7, the /tmp path is now a ramdisk which doesn't have enough space for a full Asterisk testsuite run. This change allows causes the testsuite to switch to using /var/tmp/asterisk-testsuite in the case where the free space is larger there. Diffs - /asterisk/trunk/lib/python/asterisk/asterisk.py 5608 Diff: https://reviewboard.asterisk.org/r/4007/diff/ Testing --- Checked operation on C7 and C6 and the correct directory was used on both. 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] 4007: testsuite: pick test suite temp dir based on free space
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4007/#review13366 --- Ship it! Blech. Thanks CentOS 7. :-( This patch will work just fine for the most of the testsuite, but there will be some tests that still try to stick themselves in /tmp/asterisk-testsuite (namely, the Lua ones). That shouldn't prevent this patch from going in, as we're slowly converting those over to Python anyway. - Matt Jordan On Sept. 19, 2014, 8:23 a.m., Scott Griepentrog wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4007/ --- (Updated Sept. 19, 2014, 8:23 a.m.) Review request for Asterisk Developers. Repository: testsuite Description --- On CentOS 7, the /tmp path is now a ramdisk which doesn't have enough space for a full Asterisk testsuite run. This change allows causes the testsuite to switch to using /var/tmp/asterisk-testsuite in the case where the free space is larger there. Diffs - /asterisk/trunk/lib/python/asterisk/asterisk.py 5608 Diff: https://reviewboard.asterisk.org/r/4007/diff/ Testing --- Checked operation on C7 and C6 and the correct directory was used on both. 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] 4007: testsuite: pick test suite temp dir based on free space
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4007/ --- (Updated Sept. 19, 2014, 8:54 a.m.) Status -- This change has been marked as submitted. Review request for Asterisk Developers. Changes --- Committed in revision 5615 Repository: testsuite Description --- On CentOS 7, the /tmp path is now a ramdisk which doesn't have enough space for a full Asterisk testsuite run. This change allows causes the testsuite to switch to using /var/tmp/asterisk-testsuite in the case where the free space is larger there. Diffs - /asterisk/trunk/lib/python/asterisk/asterisk.py 5608 Diff: https://reviewboard.asterisk.org/r/4007/diff/ Testing --- Checked operation on C7 and C6 and the correct directory was used on both. 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] 4006: Test to validate 503 not generated on INVITE retransmissions
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4006/#review13368 --- There are a couple of problems with this test: 1) It's quite a bit more complicated than it needs to be. What's actually being tested here is that Asterisk does not send a 503 in addition to a 486 on an INVITE retransmission. This only requires a UA to send and retransmit the INVITE and Asterisk. This should be doable entirely within a SIPp scenario and does not need voxcallcontrol, a Perl AGI load balancer, or grepping any logs. 2) The included sip.conf file is about 95% comments. This makes reviewing the config file much more difficult than it needs to be. I think this test can be accomplished using the SIPpTestCase and defining the test details entirely within test-config.yaml, with no run-test file necessary. If you're unfamiliar with how this is done, there are several examples of this in the testsuite. A simple example can be found at tests/channels/SIP/directrtpsetup/test-config.yaml. In that test, there is a test-modules section that tells the testsuite to use sipp.SIPpTestCase as the main test object for the test (it also has an unnecessary add-test-to-search-path option set. You can ignore that). The corresponding test-object-config provides details about the SIPp scenarios to run. In that test, there are two scenarios run, but I suspect that for your test, you would only need a single scenario to run. If you're curious about what options are available for configuring the SIPpTestCase, you can look in sample-yaml/sipptestcase-config.yaml.sample for some more details. Your test can pass or fail based on whether the SIPp scenario succeeds or fails. - Mark Michelson On Sept. 19, 2014, 8:09 a.m., Torrey Searle wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4006/ --- (Updated Sept. 19, 2014, 8:09 a.m.) Review request for Asterisk Developers. Bugs: ASTERISK-24335 https://issues.asterisk.org/jira/browse/ASTERISK-24335 Repository: testsuite Description --- This is a test for the test suite to reproduce the issue described in ASTERISK-24335 Diffs - /asterisk/trunk/tests/channels/SIP/tests.yaml 5608 /asterisk/trunk/tests/channels/SIP/invite_retransmit/test-config.yaml PRE-CREATION /asterisk/trunk/tests/channels/SIP/invite_retransmit/sipp/A_PARTY.xml PRE-CREATION /asterisk/trunk/tests/channels/SIP/invite_retransmit/run-test PRE-CREATION /asterisk/trunk/tests/channels/SIP/invite_retransmit/configs/ast1/sip.conf PRE-CREATION /asterisk/trunk/tests/channels/SIP/invite_retransmit/configs/ast1/extensions.conf PRE-CREATION Diff: https://reviewboard.asterisk.org/r/4006/diff/ Testing --- test passes when 4003 patch applied, fails when patch not applied Thanks, Torrey Searle -- _ -- 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] 3999: chan_iax2: Jitterbuffer causes crash in Asterisk 13 on account of format changes
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3999/ --- (Updated Sept. 19, 2014, 9:56 a.m.) Status -- This change has been marked as submitted. Review request for Asterisk Developers, Matt Jordan and rmudgett. Changes --- Committed in revision 423524 Bugs: ASTERISK-24265 https://issues.asterisk.org/jira/browse/ASTERISK-24265 Repository: Asterisk Description --- This only occurs when the chan_iax jitterbuffer options are set and no when setting jitterbuffers via diaplan or anything like that. The first time __get_from_jb is called, voiceformat has not been set on the IAX pvt. Trying to call ast_format_get_default_ms on a NULL pointer fails. This worked previously because Asterisk 12 and prior simply modified an ast_format on the stack, so when it used ast_codec_interp_len on that format pointer there was no possibility for it to be a NULL pointer... just one that doesn't have a real format associated with it. One thing I might not be doing right here is that I'm using an interpolation value of 0 for a NULL format. Previously Asterisk would just check to see if the format was ILBC and if it was, return 30 and otherwise return 20... so it might be more appropriate to use 20 instead of 0. It doesn't appear to make a difference for the sake of behavior. Diffs - /branches/13/channels/chan_iax2.c 423149 Diff: https://reviewboard.asterisk.org/r/3999/diff/ Testing --- Ran basic call from a PJSIP peer to an IAX peer with the following: [general] ; The important parts jitterbuffer=yes forcejitterbuffer=yes [deskbox] type=friend requirecalltoken = no username = deskbox secret = secret host = dynamic transfer = no dtmfmode = auto encryption = no qualify = 300 context = default disallow=all allow=ulaw allow=alaw ; Most of this is probably unnecessary for reproduction Without the patch this would crash in 13 but work fine in 12. With the patch, behavior strongly resembles 12 with the initial call into __get_from_jb attempting to jb_get and getting JB_OK back and then later, when the call was actually answered, the voice format would change and the function would call again with the proper format and the jitterbuffer would get started properly. 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] 4006: Test to validate 503 not generated on INVITE retransmissions
On Sept. 19, 2014, 2:34 p.m., Mark Michelson wrote: There are a couple of problems with this test: 1) It's quite a bit more complicated than it needs to be. What's actually being tested here is that Asterisk does not send a 503 in addition to a 486 on an INVITE retransmission. This only requires a UA to send and retransmit the INVITE and Asterisk. This should be doable entirely within a SIPp scenario and does not need voxcallcontrol, a Perl AGI load balancer, or grepping any logs. 2) The included sip.conf file is about 95% comments. This makes reviewing the config file much more difficult than it needs to be. I think this test can be accomplished using the SIPpTestCase and defining the test details entirely within test-config.yaml, with no run-test file necessary. If you're unfamiliar with how this is done, there are several examples of this in the testsuite. A simple example can be found at tests/channels/SIP/directrtpsetup/test-config.yaml. In that test, there is a test-modules section that tells the testsuite to use sipp.SIPpTestCase as the main test object for the test (it also has an unnecessary add-test-to-search-path option set. You can ignore that). The corresponding test-object-config provides details about the SIPp scenarios to run. In that test, there are two scenarios run, but I suspect that for your test, you would only need a single scenario to run. If you're curious about what options are available for configuring the SIPpTestCase, you can look in sample-yaml/sipptestcase-config.yaml.sample for some more details. Your test can pass or fail based on whether the SIPp scen ario succeeds or fails. The problem is that I have to ignore INVITES for awhile by using a pause block. The 503 happens during that ignoring time after loosing a day and a half I couldn't find a better way then to pause then grep the log to see what happened. If you can make a version that can work entirely in sipp let me know :-) agiload balancer and voxcallcontrol is there by mistake, (thought I had removed all references to them already) I'll check again and remove the references and post the new patch - Torrey --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4006/#review13368 --- On Sept. 19, 2014, 8:09 a.m., Torrey Searle wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4006/ --- (Updated Sept. 19, 2014, 8:09 a.m.) Review request for Asterisk Developers. Bugs: ASTERISK-24335 https://issues.asterisk.org/jira/browse/ASTERISK-24335 Repository: testsuite Description --- This is a test for the test suite to reproduce the issue described in ASTERISK-24335 Diffs - /asterisk/trunk/tests/channels/SIP/tests.yaml 5608 /asterisk/trunk/tests/channels/SIP/invite_retransmit/test-config.yaml PRE-CREATION /asterisk/trunk/tests/channels/SIP/invite_retransmit/sipp/A_PARTY.xml PRE-CREATION /asterisk/trunk/tests/channels/SIP/invite_retransmit/run-test PRE-CREATION /asterisk/trunk/tests/channels/SIP/invite_retransmit/configs/ast1/sip.conf PRE-CREATION /asterisk/trunk/tests/channels/SIP/invite_retransmit/configs/ast1/extensions.conf PRE-CREATION Diff: https://reviewboard.asterisk.org/r/4006/diff/ Testing --- test passes when 4003 patch applied, fails when patch not applied Thanks, Torrey Searle -- _ -- 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] 3990: CDRs/Dial: Fix an assertion caused by advancing a neutral state channel straight into dial pending without going through dial
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3990/ --- (Updated Sept. 19, 2014, 10:10 a.m.) Status -- This change has been marked as submitted. Review request for Asterisk Developers, Matt Jordan and rmudgett. Changes --- Committed in revision 423525 Bugs: ASTERISK-24237 https://issues.asterisk.org/jira/browse/ASTERISK-24237 Repository: Asterisk Description --- Reproduction: pj123 calls 1601 pj123 does a SIP blonde transfer to 1603 1603 answers FRACK occurs all are PJSIP endpoints. Basically what happens is there is a second outbound dial from another pj123 channel. Before the dial is answered, the pj123 gets masqueraded out of the picture and replaced with a channel that isn't in the dial state. This patch fixes that by advancing the incoming channel to the dial state in the channel breakdown function of a datastore on the pj123 channel. Honestly, I'm not sure this is entirely adequate, but it seems to work in all of the conditions I've tried so far and it doesn't impede normal attended transfers. I might need to try and figure out what happens if I masquerade in a channel that is already dialing though. I'm not sure if that's something we can really expect to happen under normal conditions, but that seems like something that would screw up this approach. Note that I think this patch is the right idea, I just don't know if I need to account for the possibility that the channel that masquerades into pj123's dialing channel might not be in the neutral state. Diffs - /branches/12/main/stasis_channels.c 422882 Diff: https://reviewboard.asterisk.org/r/3990/diff/ Testing --- Ran against reproduction of the above scenario. Assertion was gone and the CDR results were as follows: ,123,1601,default, 123,PJSIP/pj123-,PJSIP/1601-0001,Dial,PJSIP/1601,,tT,2014-09-11 21:48:51,2014-09-11 21:48:53,2014-09-11 21:48:57,5,4,ANSWERED,DOCUMENTATION,1410472131.0, ,123,,default, 123,PJSIP/pj123-0002,PJSIP/1603-0003,Dial,PJSIP/1603,2014-09-11 21:48:55,,2014-09-11 21:48:57,2,0,NO ANSWER,DOCUMENTATION,1410472135.6, ,1601,1603,default, 1601,PJSIP/1601-0001,PJSIP/1603-0003,AppDial,(Outgoing Line),2014-09-11 21:48:57,2014-09-11 21:48:57,2014-09-11 21:49:04,6,6,ANSWERED,DOCUMENTATION,1410472131.1, And dial events reported by AMI: http://pastebin.com/tWuwL7xa (note that there is a mismatch between the number of dial end and dial begin events... not sure if this is a problem, but I might be able to fix it just by updating the old chan, not sure what status code to use though). Ran against normal attended transfer, feature attended transfers, and blind transfers with no noticeable effect. Ran against testsuite blonde transfer tests, some attended transfer tests, some blind transfer tests, and all pjsip transfer tests (at least ones that will run on my box... a few won't due to sipp version requirements that I really need to get around to fixing eventually) for comparison purposes. All passed exhibiting the same behavior as before as far as warning messages and such go. 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] 4006: Test to validate 503 not generated on INVITE retransmissions
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4006/ --- (Updated Sept. 19, 2014, 3:19 p.m.) Review request for Asterisk Developers. Changes --- references to agi load balancer and vcc removed comments from sip.conf removed Bugs: ASTERISK-24335 https://issues.asterisk.org/jira/browse/ASTERISK-24335 Repository: testsuite Description --- This is a test for the test suite to reproduce the issue described in ASTERISK-24335 Diffs (updated) - /asterisk/trunk/tests/channels/SIP/tests.yaml 5608 /asterisk/trunk/tests/channels/SIP/invite_retransmit/test-config.yaml PRE-CREATION /asterisk/trunk/tests/channels/SIP/invite_retransmit/sipp/A_PARTY.xml PRE-CREATION /asterisk/trunk/tests/channels/SIP/invite_retransmit/run-test PRE-CREATION /asterisk/trunk/tests/channels/SIP/invite_retransmit/configs/ast1/sip.conf PRE-CREATION /asterisk/trunk/tests/channels/SIP/invite_retransmit/configs/ast1/extensions.conf PRE-CREATION Diff: https://reviewboard.asterisk.org/r/4006/diff/ Testing --- test passes when 4003 patch applied, fails when patch not applied Thanks, Torrey Searle -- _ -- 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] 4006: Test to validate 503 not generated on INVITE retransmissions
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4006/ --- (Updated Sept. 19, 2014, 3:51 p.m.) Review request for Asterisk Developers. Changes --- removed unused peer [SBC] Bugs: ASTERISK-24335 https://issues.asterisk.org/jira/browse/ASTERISK-24335 Repository: testsuite Description --- This is a test for the test suite to reproduce the issue described in ASTERISK-24335 Diffs (updated) - /asterisk/trunk/tests/channels/SIP/tests.yaml 5608 /asterisk/trunk/tests/channels/SIP/invite_retransmit/test-config.yaml PRE-CREATION /asterisk/trunk/tests/channels/SIP/invite_retransmit/sipp/A_PARTY.xml PRE-CREATION /asterisk/trunk/tests/channels/SIP/invite_retransmit/run-test PRE-CREATION /asterisk/trunk/tests/channels/SIP/invite_retransmit/configs/ast1/sip.conf PRE-CREATION /asterisk/trunk/tests/channels/SIP/invite_retransmit/configs/ast1/extensions.conf PRE-CREATION Diff: https://reviewboard.asterisk.org/r/4006/diff/ Testing --- test passes when 4003 patch applied, fails when patch not applied Thanks, Torrey Searle -- _ -- 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] 4008: res_pjsip_session: Add additional checks to prevent session refresh in unpossible states.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4008/ --- Review request for Asterisk Developers and Mark Michelson. Repository: Asterisk Description --- Currently it is possible for ast_sip_session_refresh to be called at times where the state of the dialog and INVITE session does not allow it to send a request. Trying to send a request actually results in an assertion within PJSIP. This change adds additional checks for deferral of these, stops generating new SDP on COLP UPDATEs, makes it so deferral does not always result in SDP generation, and ensures that after a provisional response that any pending UPDATE occurs. * Note: Currently there is still a bug within pjproject which causes an UPDATE without SDP sent after a provisional response to cancel the pending SDP negotiation when it should not. This has been reported to Teluu and a fix is being worked on. Diffs - /branches/12/res/res_pjsip_session.c 423546 /branches/12/channels/chan_pjsip.c 423546 Diff: https://reviewboard.asterisk.org/r/4008/diff/ Testing --- Modified the dialing API to change callerID at certain points (after call but before handling responses, after handling responses). Confirmed that new code correctly defers sending COLP updates. 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] 4000: res_pjsip_sdp_rtp.c: Fix native formats containing formats that were not negotiated.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4000/ --- (Updated Sept. 19, 2014, 12:08 p.m.) Status -- This change has been marked as submitted. Review request for Asterisk Developers. Changes --- Committed in revision 423561 Bugs: AFS-162 https://issues.asterisk.org/jira/browse/AFS-162 Repository: Asterisk Description --- Outgoing PJSIP calls can result in non-negotiated formats listed in the channel's native formats if video formats are listed in the endpoint's configuration. The resulting call could then use a non-negotiated format resulting in one way audio. * Simplified the update of session-req_caps in set_caps(). Why do something in five steps when only one is needed? Diffs - /branches/13/res/res_pjsip_sdp_rtp.c 423446 /branches/13/channels/chan_pjsip.c 423446 Diff: https://reviewboard.asterisk.org/r/4000/diff/ Testing --- Configured PJSIP endpoints with: allow=!all,h264,g722,h263,ulaw,h263p,alaw Called from D40 with g722 among other formats enabled to a Polycom that negotiates ulaw. Before the patch, Asterisk would send g722 frames to the Polycom. The resulting call had one way audio because the Polycom does not understand g722. After the patch, Asterisk sends ulaw frames to the Polycom. Thanks, rmudgett -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] Asterisk 1.8.31.0-rc1 Now Available
The Asterisk Development Team has announced the first release candidate of Asterisk 1.8.31.0. This release candidate is available for immediate download at http://downloads.asterisk.org/pub/telephony/asterisk The release of Asterisk 1.8.31.0-rc1 resolves several issues reported by the community and would have not been possible without your participation. Thank you! The following are the issues resolved in this release candidate: Bugs fixed in this release: --- * ASTERISK-24032 - Gentoo compilation emits warning: _FORTIFY_SOURCE redefined (Reported by Kilburn) * ASTERISK-24225 - Dial option z is broken (Reported by dimitripietro) * ASTERISK-24178 - [patch]fromdomainport used even if not set (Reported by Elazar Broad) * ASTERISK-24019 - When a Music On Hold stream starts it restarts at beginning of file. (Reported by Jason Richards) * ASTERISK-24211 - testsuite: Fix the dial_LS_options test (Reported by Matt Jordan) * ASTERISK-24249 - SIP debugs do not stop (Reported by Avinash Mohod) Improvements made in this release: --- * ASTERISK-24171 - [patch] Provide a manpage for the aelparse utility (Reported by Jeremy Lainé) For a full list of changes in this release candidate, please see the ChangeLog: http://downloads.asterisk.org/pub/telephony/asterisk/ChangeLog-1.8.31.0-rc1 Thank you for your continued support of Asterisk! -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] Asterisk 11.13.0-rc1 Now Available
The Asterisk Development Team has announced the first release candidate of Asterisk 11.13.0. This release candidate is available for immediate download at http://downloads.asterisk.org/pub/telephony/asterisk The release of Asterisk 11.13.0-rc1 resolves several issues reported by the community and would have not been possible without your participation. Thank you! The following are the issues resolved in this release candidate: Bugs fixed in this release: --- * ASTERISK-24032 - Gentoo compilation emits warning: _FORTIFY_SOURCE redefined (Reported by Kilburn) * ASTERISK-24225 - Dial option z is broken (Reported by dimitripietro) * ASTERISK-24178 - [patch]fromdomainport used even if not set (Reported by Elazar Broad) * ASTERISK-22252 - res_musiconhold cleanup - REF_DEBUG reload warnings and ref leaks (Reported by Walter Doekes) * ASTERISK-23997 - chan_sip: port incorrectly incremented for RTCP ICE candidates in SDP answer (Reported by Badalian Vyacheslav) * ASTERISK-24019 - When a Music On Hold stream starts it restarts at beginning of file. (Reported by Jason Richards) * ASTERISK-23767 - [patch] Dynamic IAX2 registration stops trying if ever not able to resolve (Reported by David Herselman) * ASTERISK-24211 - testsuite: Fix the dial_LS_options test (Reported by Matt Jordan) * ASTERISK-24249 - SIP debugs do not stop (Reported by Avinash Mohod) * ASTERISK-23577 - res_rtp_asterisk: Crash in ast_rtp_on_turn_rtp_state when RTP instance is NULL (Reported by Jay Jideliov) * ASTERISK-23634 - With TURN Asterisk crashes on multiple (7-10) concurrent WebRTC (avpg/encryption/icesupport) calls (Reported by Roman Skvirsky) * ASTERISK-24301 - Security: Out of call MESSAGE requests processed via Message channel driver can crash Asterisk (Reported by Matt Jordan) Improvements made in this release: --- * ASTERISK-24171 - [patch] Provide a manpage for the aelparse utility (Reported by Jeremy Lainé) For a full list of changes in this release candidate, please see the ChangeLog: http://downloads.asterisk.org/pub/telephony/asterisk/ChangeLog-11.13.0-rc1 Thank you for your continued support of Asterisk! -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] Asterisk 13.0.0-beta2 Now Available!
The Asterisk Development Team is pleased to announce the second beta release of Asterisk 13.0.0. This release is available for immediate download at http://downloads.asterisk.org/pub/telephony/asterisk/releases All interested users of Asterisk are encouraged to participate in the Asterisk 13 testing process. Please report any issues found to the issue tracker, https://issues.asterisk.org/jira. All Asterisk users are invited to participate in the #asterisk-bugs channel to help communicate issues found to the Asterisk developers. It is also very useful to see successful test reports. Please post those to the asterisk-dev mailing list (http://lists.digium.com). Asterisk 13 is the next major release series of Asterisk. It will be a Long Term Support (LTS) release, similar to Asterisk 11. For more information about support time lines for Asterisk releases, see the Asterisk versions page: https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions For important information regarding upgrading to Asterisk 13, please see the Asterisk wiki: https://wiki.asterisk.org/wiki/display/AST/Upgrading+to+Asterisk+13 A short list of new features includes: * Asterisk security events are now provided via AMI, allowing end users to monitor their Asterisk system in real time for security related issues. * Both AMI and ARI now allow external systems to control the state of a mailbox. Using AMI actions or ARI resources, external systems can programmatically trigger Message Waiting Indicators (MWI) on subscribed phones. This is of particular use to those who want to build their own VoiceMail application using ARI. * ARI now supports the reception/transmission of out of call text messages using any supported channel driver/protocol stack through ARI. Users receive out of call text messages as JSON events over the ARI websocket connection, and can send out of call text messages using HTTP requests. * The PJSIP stack now supports RFC 4662 Resource Lists, allowing Asterisk to act as a Resource List Server. This includes defining lists of presence state, mailbox state, or lists of presence state/mailbox state; managing subscriptions to lists; and batched delivery of NOTIFY requests to subscribers. * The PJSIP stack can now be used as a means of distributing device state or mailbox state via PUBLISH requests to other Asterisk instances. This is analogous to Asterisk's clustering support using XMPP or Corosync; unlike existing clustering mechanisms, using the PJSIP stack to perform the distribution of state does not rely on another daemon or server to perform the work. And much more! More information about the new features can be found on the Asterisk wiki: https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+Documentation A full list of all new features can also be found in the CHANGES file: http://svnview.digium.com/svn/asterisk/branches/13/CHANGES For a full list of changes in the current release, please see the ChangeLog: http://downloads.asterisk.org/pub/telephony/asterisk/releases/ChangeLog-13.0.0-beta2 Thank you for your continued support of Asterisk! -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] Asterisk 12.6.0-rc1 Now Available
The Asterisk Development Team has announced the first release candidate of Asterisk 12.6.0. This release candidate is available for immediate download at http://downloads.asterisk.org/pub/telephony/asterisk The release of Asterisk 12.6.0-rc1 resolves several issues reported by the community and would have not been possible without your participation. Thank you! The following are the issues resolved in this release candidate: Bugs fixed in this release: --- * ASTERISK-24027 - MixMonitor AMI action called during AGI execution from bridge feature causes channel to leave AGI has hung up (Reported by Matt Jordan) * ASTERISK-24236 - res_hep_rtcp: Module incorrectly depends on pjsip (Reported by Matt Jordan) * ASTERISK-24032 - Gentoo compilation emits warning: _FORTIFY_SOURCE redefined (Reported by Kilburn) * ASTERISK-24225 - Dial option z is broken (Reported by dimitripietro) * ASTERISK-24234 - app_meetme: Crash on conference shutdown due to NULL channel passed to meetme_stasis_generate_msg() (Reported by Shaun Ruffell) * ASTERISK-24043 - ARI /continue fails to actually continue into the dialplan (Reported by Krandon Bruse) * ASTERISK-24245 - gcc 4.1.2 complains of files that do not end with newlines (Reported by Shaun Ruffell) * ASTERISK-24229 - ARI: playback of sounds implicitly answers channel, preventing early media playback (Reported by Matt Jordan) * ASTERISK-24178 - [patch]fromdomainport used even if not set (Reported by Elazar Broad) * ASTERISK-22252 - res_musiconhold cleanup - REF_DEBUG reload warnings and ref leaks (Reported by Walter Doekes) * ASTERISK-23994 - res_pjsip_sdp_rtp: owner address in SDP may not be fully qualified domainname (Reported by Private Name) * ASTERISK-24147 - ARI: channel hangup crashes asterisk process (Reported by Edvin Vidmar) * ASTERISK-23997 - chan_sip: port incorrectly incremented for RTCP ICE candidates in SDP answer (Reported by Badalian Vyacheslav) * ASTERISK-24143 - pjsip: Outbound call to WebRTC UA fails to transmit ACK on received 200 OK (Reported by Aleksei Kulakov) * ASTERISK-24019 - When a Music On Hold stream starts it restarts at beginning of file. (Reported by Jason Richards) * ASTERISK-23767 - [patch] Dynamic IAX2 registration stops trying if ever not able to resolve (Reported by David Herselman) * ASTERISK-24264 - ARI: Adding a channel to a holding bridge automatically starts MOH (Reported by Samuel Galarneau) * ASTERISK-24212 - testsuite: Sporadic crash due to assert on stopping RTP engine (Reported by Matt Jordan) * ASTERISK-24241 - crash: CDRs recursively attempt to update Party B information in a multi-party bridge, overrunning the stack (Reported by Deepak Singh Rawat) * ASTERISK-24254 - CDRs: Application/args/dialplan CEP updated during dial operation (Reported by Matt Jordan) * ASTERISK-24231 - crash: CLI execution of realtime destroy sippeers id 1 causes crash due to NULL name provided to ast_variable (Reported by Niklas Larsson) * ASTERISK-24249 - SIP debugs do not stop (Reported by Avinash Mohod) * ASTERISK-23577 - res_rtp_asterisk: Crash in ast_rtp_on_turn_rtp_state when RTP instance is NULL (Reported by Jay Jideliov) * ASTERISK-23634 - With TURN Asterisk crashes on multiple (7-10) concurrent WebRTC (avpg/encryption/icesupport) calls (Reported by Roman Skvirsky) * ASTERISK-24161 - PJSIPShowEndpoint gives inaccurate count of list items (Reported by Mark Michelson) * ASTERISK-24331 - Unexpected Errors in Asterisk Manager Interface Output (Reported by xrobau) * ASTERISK-24136 - Security: Crash in Asterisk's PJSIP code when subscribing to an event with an unexpected body type (Reported by Mark Michelson) * ASTERISK-24301 - Security: Out of call MESSAGE requests processed via Message channel driver can crash Asterisk (Reported by Matt Jordan) * ASTERISK-24290 - Endpoint identifier match value fails to parse when CIDR network format is specified (Reported by Ray Crumrine) * ASTERISK-24237 - CDR: FRACK With PJSIP blonde transfer. (Reported by Richard Mudgett) Improvements made in this release: --- * ASTERISK-24171 - [patch] Provide a manpage for the aelparse utility (Reported by Jeremy Lainé) For a full list of changes in this release candidate, please see the ChangeLog: http://downloads.asterisk.org/pub/telephony/asterisk/ChangeLog-12.6.0-rc1 Thank you for your continued support of Asterisk! -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 3954: pjsip_options.c: Fix race condition stopping periodic out of dialog OPTIONS request.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3954/ --- (Updated Sept. 19, 2014, 4:52 p.m.) Review request for Asterisk Developers. Changes --- Implemented mmichelson's wrapper suggestion. Bugs: AFS-155 and ASTERISK-24295 https://issues.asterisk.org/jira/browse/AFS-155 https://issues.asterisk.org/jira/browse/ASTERISK-24295 Repository: Asterisk Description --- The crash on the issues is a result of an invalid transport configuration change when asterisk is restarted. The attempt to send the qualify request fails and we cleaned up. However, the callback is also called which results in a double unref of the objects involved. * Fixed send_request_cb() and qualify_contact_cb() to not cleanup the token when the PJSIP event is PJSIP_EVENT_TRANSPORT_ERROR since the initial function call will do the clean up. * Made send_request_cb() able to handle repeated challenges (Up to 10). * Fix periodic endpoint qualify OPTIONS sched deletion race by avoiding it. The sched entry will no longer self stop and must be externally stopped. * Added REF_DEBUG description tags to struct sched_data in pjsip_options.c. * Fix some off-nominal ref leaks in schedule_qualify(), qualify_and_schedule(). * Reordered pjsip_options.c module start/stop code to cleanup better on error. Diffs (updated) - /branches/13/res/res_pjsip/pjsip_options.c 423616 /branches/13/res/res_pjsip.c 423616 Diff: https://reviewboard.asterisk.org/r/3954/diff/ Testing --- * With the qualify_frequency option enabled, added and removed a local_net= line in the transport section and restarted asterisk via core restart now. Before the latest patch version, asterisk would crash. With the new patch, it keeps on going. * Set the qualify_frequency option to different values and reloaded res_pjsip each time. The OPTIONS poll frequency changed, started, and stopped according to the new qualify_frequency value. Thanks, rmudgett -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 3954: pjsip_options.c: Fix race condition stopping periodic out of dialog OPTIONS request.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3954/ --- (Updated Sept. 19, 2014, 4:54 p.m.) Review request for Asterisk Developers. Bugs: AFS-155, AST-1424 and ASTERISK-24295 https://issues.asterisk.org/jira/browse/AFS-155 https://issues.asterisk.org/jira/browse/AST-1424 https://issues.asterisk.org/jira/browse/ASTERISK-24295 Repository: Asterisk Description --- The crash on the issues is a result of an invalid transport configuration change when asterisk is restarted. The attempt to send the qualify request fails and we cleaned up. However, the callback is also called which results in a double unref of the objects involved. * Fixed send_request_cb() and qualify_contact_cb() to not cleanup the token when the PJSIP event is PJSIP_EVENT_TRANSPORT_ERROR since the initial function call will do the clean up. * Made send_request_cb() able to handle repeated challenges (Up to 10). * Fix periodic endpoint qualify OPTIONS sched deletion race by avoiding it. The sched entry will no longer self stop and must be externally stopped. * Added REF_DEBUG description tags to struct sched_data in pjsip_options.c. * Fix some off-nominal ref leaks in schedule_qualify(), qualify_and_schedule(). * Reordered pjsip_options.c module start/stop code to cleanup better on error. Diffs - /branches/13/res/res_pjsip/pjsip_options.c 423616 /branches/13/res/res_pjsip.c 423616 Diff: https://reviewboard.asterisk.org/r/3954/diff/ Testing --- * With the qualify_frequency option enabled, added and removed a local_net= line in the transport section and restarted asterisk via core restart now. Before the latest patch version, asterisk would crash. With the new patch, it keeps on going. * Set the qualify_frequency option to different values and reloaded res_pjsip each time. The OPTIONS poll frequency changed, started, and stopped according to the new qualify_frequency value. Thanks, rmudgett -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 3954: pjsip_options.c: Fix race condition stopping periodic out of dialog OPTIONS request.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3954/ --- (Updated Sept. 19, 2014, 4:55 p.m.) Review request for Asterisk Developers. Bugs: ASTERISK-24295 https://issues.asterisk.org/jira/browse/ASTERISK-24295 Repository: Asterisk Description --- The crash on the issues is a result of an invalid transport configuration change when asterisk is restarted. The attempt to send the qualify request fails and we cleaned up. However, the callback is also called which results in a double unref of the objects involved. * Fixed send_request_cb() and qualify_contact_cb() to not cleanup the token when the PJSIP event is PJSIP_EVENT_TRANSPORT_ERROR since the initial function call will do the clean up. * Made send_request_cb() able to handle repeated challenges (Up to 10). * Fix periodic endpoint qualify OPTIONS sched deletion race by avoiding it. The sched entry will no longer self stop and must be externally stopped. * Added REF_DEBUG description tags to struct sched_data in pjsip_options.c. * Fix some off-nominal ref leaks in schedule_qualify(), qualify_and_schedule(). * Reordered pjsip_options.c module start/stop code to cleanup better on error. Diffs - /branches/13/res/res_pjsip/pjsip_options.c 423616 /branches/13/res/res_pjsip.c 423616 Diff: https://reviewboard.asterisk.org/r/3954/diff/ Testing --- * With the qualify_frequency option enabled, added and removed a local_net= line in the transport section and restarted asterisk via core restart now. Before the latest patch version, asterisk would crash. With the new patch, it keeps on going. * Set the qualify_frequency option to different values and reloaded res_pjsip each time. The OPTIONS poll frequency changed, started, and stopped according to the new qualify_frequency value. Thanks, rmudgett -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 3954: pjsip_options.c: Fix race condition stopping periodic out of dialog OPTIONS request.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3954/ --- (Updated Sept. 19, 2014, 5:02 p.m.) Review request for Asterisk Developers. Bugs: ASTERISK-24295 https://issues.asterisk.org/jira/browse/ASTERISK-24295 Repository: Asterisk Description (updated) --- The crash on the issues is a result of an invalid transport configuration change when asterisk is restarted. The attempt to send the qualify request fails and we cleaned up. However, the callback is also called which results in a double unref of the objects involved. * Put a wrapper around pjsip_endpt_send_request() to detect when the passed in callback is called because of an error so callers can know to cleanup. * Made send_request_cb() able to handle repeated challenges (Up to 10). * Fix periodic endpoint qualify OPTIONS sched deletion race by avoiding it. The sched entry will no longer self stop and must be externally stopped. * Added REF_DEBUG description tags to struct sched_data in pjsip_options.c. * Fix some off-nominal ref leaks in schedule_qualify(), qualify_and_schedule(). * Reordered pjsip_options.c module start/stop code to cleanup better on error. Diffs - /branches/13/res/res_pjsip/pjsip_options.c 423616 /branches/13/res/res_pjsip.c 423616 Diff: https://reviewboard.asterisk.org/r/3954/diff/ Testing --- * With the qualify_frequency option enabled, added and removed a local_net= line in the transport section and restarted asterisk via core restart now. Before the latest patch version, asterisk would crash. With the new patch, it keeps on going. * Set the qualify_frequency option to different values and reloaded res_pjsip each time. The OPTIONS poll frequency changed, started, and stopped according to the new qualify_frequency value. Thanks, rmudgett -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] Opinions Needed: PJSIP Outboud Registration with multiple server_uris
In the process of getting my GUI and real customers up on PJSIP I've come across a few things that could work better for me. One of them is the configuration process for ITSP trunks, specifically those that require registration and have more than 1 server. In a simple single-server scenario, a trunk would need 1 endpoint, 1 aor, 1 outbound_auth, 1 identify and 1 registration. Leaving out variables not needed for the example... [mytrunk] type = endpoint aors = mytrunk outbound_auth = mytrunk [mytrunk] type = aor contact = sip:sip1.myitsp.com [mytrunk] type = auth username = myuser password = mypass [mytrunk] type = identify endpoint = mytrunk match = sip1.myitsp.com [mytrunk] type = registration endpoint = mytrunk outbound_auth = mytrunk server_uri = sip:sip1.myitsp.com A little more verbose than chan_sip but pretty straightforward. I used the same name for all category/context/sections on purpose. It makes grouping everything that makes up the trunk a lot easier especially if you're using scripts or the AMI*(1)* to retrieve or modify the config. Now add a backup server... [mytrunk] type = endpoint aors = mytrunk outbound_auth = mytrunk [mytrunk] type = aor contact = sip:sip1.myitsp.com,sip:sip2.myitsp.com [mytrunk] type = auth username = myuser password = mypass [mytrunk] type = identify endpoint = mytrunk match = sip1.myitsp.com,sip2.myitsp.com [mytrunk-reg1] type = registration endpoint = mytrunk outbound_auth = mytrunk server_uri = sip:sip1.myitsp.com [mytrunk-reg2] type = registration endpoint = mytrunk outbound_auth = mytrunk server_uri = sip:sip2.myitsp.com I still have 1 endpoint, 1 aor, 1 auth, 1 identify but now I need 2 registrations because you can only have 1 server_uri in a registration, and they need special names so they don't conflict. The only thing different is the server_uri and just like contact and match, they're interchangeable in this scenario. My proposal is to allow registration/server_uri to be specified as a comma separated list or to be specified multiple times just like aor/contact and identify/match. This would allow us to manage only 1 registration section in the same manner as aor and identify. A registration would be Registered if at least 1 server was registered or I can add a registration_state_registered_at variable similar to device_state_busy_at which would specify the minimum number of servers needed to be considered Registered. If you actually want 2 registrations, nothing stops you from creating them. It seems like a minor issue but for me (and other folks I'm betting) the transition from chan_sip to chan_pjsip rests on getting tools, GUIs, scripts, etc. migrated. That variable number of registrations is a pain to deal with. Josh had some issues with this approach on IRC and suggested bringing the proposal to the list for wider discussion. What do you think? --- (1): Today you can't use AMI GetConfig/GetConfigJSON and UpdateConfig with a config file with multiple contexts with the same name. I'll have patches for that shortly which eventually will also allow res_sorcery_config to write back to its files. -- _ -- 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
