[asterisk-dev] Asterisk 11.9.0 Segmentation fault.
Hi,
My Asetrisk restarted after to output following warning message.
[Oct 16 15:59:58] WARNING[17102][C-8e34]: chan_sip.c:4696
update_provisional_keepalive: Unable to cancel schedule ID 738278. This is
probably a bug (chan_sip.c: update_provisional_keepalive, line 4696).
This message has been output after a timeout occurrs in the Dial()
application.
Then, the Hangup() application is run, and Asterisk is restarted as
following.
=== output of asterisk -r ===
-- Executing [67034@local:3] Dial(SIP/Other-b6ad, SIP/67034, 60)
in new stack
== Using SIP RTP CoS mark 5
-- Called SIP/67034
-- SIP/67034-b6b2 is ringing
waiting 60 secouns
-- SIP/67034-b6b2 is ringing
-- Nobody picked up in 6 ms
-- Executing [67034@local:4] Ringing(SIP/Other-b6ad, ) in new
stack
[Oct 16 15:59:58] WARNING[17102][C-8e34]: chan_sip.c:4696
update_provisional_keepalive: Unable to cancel schedule ID 738278. This is
probably a bug (chan_sip.c: update_provisional_keepalive, line 4696).
-- Executing [67034@local:5] Goto(SIP/Other-b6ad, error) in new
stack
-- Goto (local,67034,102)
-- Executing [67034@local:102] Busy(SIP/Other-b6ad, 3) in new
stack
== Spawn extension (local, 67034, 102) exited non-zero on
'SIP/Other-b6ad'
-- Executing [h@local:1] Hangup(SIP/Other-b6ad, ) in new stack
== Spawn extension (local, h, 1) exited non-zero on 'SIP/Other-b6ad'
Asterisk chrash and restart
=
I have installed Asterisk-11.9.0 a two month ago. Asterisk have be running
without restart for two month.
However, in this week, Asterisk has restarted three times.
In that time, an above message is appear always.
I am trying to reproduce with intention of this problem, but not able to
reproduce yet.
Could anybody tell me a cause or workaround of this problem?
The result of bt full for the core file is this.
(gdb) bt full
#0 0x003e94230265 in raise () from /lib64/libc.so.6
No symbol table info available.
#1 0x2aaab22946b2 in skgesigOSCrash () from
/usr/local/lib/libclntsh.so.11.1
No symbol table info available.
#2 0x2aaab2532705 in kpeDbgSignalHandler () from
/usr/local/lib/libclntsh.so.11.1
No symbol table info available.
#3 0x2aaab22948c2 in skgesig_sigactionHandler () from
/usr/local/lib/libclntsh.so.11.1
No symbol table info available.
#4 signal handler called
No symbol table info available.
#5 0x2aaaceab8af1 in stop_session_timer (p=0x2aab18b892d8) at
chan_sip.c:29206
__PRETTY_FUNCTION__ = stop_session_timer
#6 0x2aaaceac23f1 in dialog_unlink_all (dialog=0x2aab18b892d8) at
chan_sip.c:3462
cp = (struct sip_pkt *) 0x0
owner = value optimized out
__PRETTY_FUNCTION__ = dialog_unlink_all
#7 0x2aaaceac2f5a in dialog_needdestroy (dialogobj=value optimized
out, arg=value optimized out, flags=value optimized out)
at chan_sip.c:19564
dialog = (struct sip_pvt *) 0x2aab18b892d8
__PRETTY_FUNCTION__ = dialog_needdestroy
#8 0x0044736e in internal_ao2_callback (c=0x1346c4c8, flags=6,
cb_fn=0x2aaaceac2d70, arg=0x0, data=0x0, type=DEFAULT, tag=0x0,
file=0x0, line=0, func=0x0) at astobj2.c:1102
match = -827576976
__list_head = (struct bucket *) 0x1346c4e8
__list_next = (struct bucket_entry *) 0x0
__list_prev = (struct bucket_entry *) 0x0
__list_current = value optimized out
cur = (struct bucket_entry *) 0x2aab1c912ad0
i = value optimized out
start = 0
last = 1
orig_lock = AO2_LOCK_REQ_MUTEX
ret = (void *) 0x0
cb_default = (ao2_callback_fn *) 0x2aaaceac2d70 dialog_needdestroy
cb_withdata = (ao2_callback_data_fn *) 0
multi_container = (struct ao2_container *) 0x0
multi_iterator = (struct ao2_iterator *) 0x0
__PRETTY_FUNCTION__ = internal_ao2_callback
#9 0x00447a11 in __ao2_callback (c=0x2aab1800,
flags=OBJ_UNLINK, cb_fn=0, arg=0x0) at astobj2.c:1207
No locals.
#10 0x2aaaceb26069 in do_monitor (data=value optimized out) at
chan_sip.c:29102
res = value optimized out
t = 1413442798
reloading = 0
__PRETTY_FUNCTION__ = do_monitor
---Type return to continue, or q return to quit---
#11 0x0056a03c in dummy_start (data=value optimized out) at
utils.c:1162
__cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {46912524978576,
-6422456248918885333, 0, 1106210816, 0, 4096,
-6422456247867614133, -6422456248915649527}, __mask_was_saved =
0}}, __pad = {0x41ef61a0, 0x0, 0x0, 0x0}}
__cancel_arg = (void *) 0x41ef6940
not_first_call = value optimized out
ret = value optimized out
#12 0x003e94e064a7 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#13 0x003e942d3c2d in clone () from /lib64/libc.so.6
No symbol table info available.
(gdb)
Best Regards
Yoshi.Tame
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
Re: [asterisk-dev] Asterisk 11.9.0 Segmentation fault.
On Tue, Oct 21, 2014 at 3:17 AM, 為近 吉摩（情報システム本部）- Tamechika Yoshikiyo - yoshikiyo.tamech...@g.softbank.co.jp wrote: (gdb) bt full #0 0x003e94230265 in raise () from /lib64/libc.so.6 No symbol table info available. #1 0x2aaab22946b2 in skgesigOSCrash () from /usr/local/lib/libclntsh.so.11.1 No symbol table info available. #2 0x2aaab2532705 in kpeDbgSignalHandler () from /usr/local/lib/libclntsh.so.11.1 No symbol table info available. #3 0x2aaab22948c2 in skgesig_sigactionHandler () from /usr/local/lib/libclntsh.so.11.1 No symbol table info available. #4 signal handler called No symbol table info available. #5 0x2aaaceab8af1 in stop_session_timer (p=0x2aab18b892d8) at chan_sip.c:29206 __PRETTY_FUNCTION__ = stop_session_timer Based on this backtrace: 1) It looks like the crash is down in an oracle client library (libclntsh) and not in Asterisk itself. 2) Based on this backtrace, it shows chan_sip calling into this client library, which doesn't exist in Asterisk code, so it could be a problem specific to modifications made in your version. -- Russell Bryant -- Russell Bryant -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 3992: res_pjsip_sdp_rtp: Add optimistic SRTP support.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3992/ --- (Updated Oct. 21, 2014, 12:30 p.m.) Review request for Asterisk Developers. Repository: Asterisk Description --- When enabling SRTP support in PJSIP it is either forced on or disabled. This means that if you specify SRTP but the client does not support it the session will fail. For situations where this guarantee is not required this new functionality can be used to optimistically use SRTP if possible. This has the added benefit of encrypting the media when possible but does not guarantee it. This also fixes an issue where a client may offer SRTP using the normal transport but we reject it. Diffs (updated) - /trunk/res/res_pjsip_session.c 426078 /trunk/res/res_pjsip_sdp_rtp.c 426078 /trunk/res/res_pjsip/pjsip_configuration.c 426078 /trunk/res/res_pjsip.c 426078 /trunk/include/asterisk/res_pjsip_session.h 426078 /trunk/include/asterisk/res_pjsip.h 426078 /trunk/contrib/ast-db-manage/config/versions/1443687dda65_add_media_encryption_optimistic_to_pjsip.py PRE-CREATION /trunk/configs/samples/pjsip.conf.sample 426078 /trunk/CHANGES 426078 Diff: https://reviewboard.asterisk.org/r/3992/diff/ Testing --- Used Blink to place calls with optimistic enabled and disabled on the PJSIP side. In Blink I alternated between disabled/mandatory/optional. Confirmed that for each scenario the expected outcome occurred. Blink Asterisk Result Disabled Optimistic Off Failed Disabled Optimistic On Success (Not encrypted) Mandatory Optimistic Off Success (Encrypted) Mandatory Optimistic On Success (Encrypted) Optional Optimistic Off Success (Encrypted) Optional Optimistic On Success (Encrypted) 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] 3992: res_pjsip_sdp_rtp: Add optimistic SRTP support.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3992/ --- (Updated Oct. 21, 2014, 1:36 p.m.) Review request for Asterisk Developers. Changes --- Fixed bug where an optimistic offer with encryption disabled would get a 488. Repository: Asterisk Description --- When enabling SRTP support in PJSIP it is either forced on or disabled. This means that if you specify SRTP but the client does not support it the session will fail. For situations where this guarantee is not required this new functionality can be used to optimistically use SRTP if possible. This has the added benefit of encrypting the media when possible but does not guarantee it. This also fixes an issue where a client may offer SRTP using the normal transport but we reject it. Diffs (updated) - /trunk/res/res_pjsip_session.c 426078 /trunk/res/res_pjsip_sdp_rtp.c 426078 /trunk/res/res_pjsip/pjsip_configuration.c 426078 /trunk/res/res_pjsip.c 426078 /trunk/include/asterisk/res_pjsip_session.h 426078 /trunk/include/asterisk/res_pjsip.h 426078 /trunk/contrib/ast-db-manage/config/versions/1443687dda65_add_media_encryption_optimistic_to_pjsip.py PRE-CREATION /trunk/configs/samples/pjsip.conf.sample 426078 /trunk/CHANGES 426078 Diff: https://reviewboard.asterisk.org/r/3992/diff/ Testing --- Used Blink to place calls with optimistic enabled and disabled on the PJSIP side. In Blink I alternated between disabled/mandatory/optional. Confirmed that for each scenario the expected outcome occurred. Blink Asterisk Result Disabled Optimistic Off Failed Disabled Optimistic On Success (Not encrypted) Mandatory Optimistic Off Success (Encrypted) Mandatory Optimistic On Success (Encrypted) Optional Optimistic Off Success (Encrypted) Optional Optimistic On Success (Encrypted) 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] 4099: Optimistic SRTP Tests.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4099/ --- 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] 4080: Test Suite: Fix the 'expected-result' YAML property for test configuration
On Oct. 16, 2014, 5:29 p.m., Scott Griepentrog wrote: /asterisk/trunk/runtests.py, line 75 https://reviewboard.asterisk.org/r/4080/diff/2/?file=68354#file68354line75 This should include a + \n like line 59 does. jbigelow wrote: Line 59 adds a newline to visually separate the test that was run from the tests output. Line 67 doesn't add a new line to the tests output and I don't believe I should just for this message that I'm appending to the output either. My concern is that another function executing later could (optionally, on some error) write to self.stdout. If there is zero possibility of that, then omitting the \n is not an issue. - Scott --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4080/#review13558 --- On Oct. 20, 2014, 11:38 a.m., jbigelow wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4080/ --- (Updated Oct. 20, 2014, 11:38 a.m.) Review request for Asterisk Developers. Repository: testsuite Description --- When the 'expected-result' (or 'expectedResult') YAML property for test configuration is set to False and the test fails, the test should be marked as passed. However it is marked as failed. This patch should fix the issue so that tests are marked as passed in this scenario. Additionally: * Check if p.returncode is not zero so self.passed is a boolean rather than an int in some cases. * Added some print statements to make it clear why a test was marked as passed or failed when the 'expected-result' YAML property is set to False. * Added text to the failure message so it's easily known when looking at the results file that the test was expected to fail but passed and therefore marked as failed. Diffs - /asterisk/trunk/runtests.py 5726 /asterisk/trunk/lib/python/asterisk/test_config.py 5726 Diff: https://reviewboard.asterisk.org/r/4080/diff/ Testing --- Tested the various scenarios and they all seem to properly work as expected now. 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] 4080: Test Suite: Fix the 'expected-result' YAML property for test configuration
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4080/ --- (Updated Oct. 21, 2014, 9:57 a.m.) Review request for Asterisk Developers. Changes --- Added a new line. Repository: testsuite Description --- When the 'expected-result' (or 'expectedResult') YAML property for test configuration is set to False and the test fails, the test should be marked as passed. However it is marked as failed. This patch should fix the issue so that tests are marked as passed in this scenario. Additionally: * Check if p.returncode is not zero so self.passed is a boolean rather than an int in some cases. * Added some print statements to make it clear why a test was marked as passed or failed when the 'expected-result' YAML property is set to False. * Added text to the failure message so it's easily known when looking at the results file that the test was expected to fail but passed and therefore marked as failed. Diffs (updated) - /asterisk/trunk/runtests.py 5766 /asterisk/trunk/lib/python/asterisk/test_config.py 5766 Diff: https://reviewboard.asterisk.org/r/4080/diff/ Testing --- Tested the various scenarios and they all seem to properly work as expected now. 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] 4080: Test Suite: Fix the 'expected-result' YAML property for test configuration
On Oct. 16, 2014, 5:29 p.m., Scott Griepentrog wrote: /asterisk/trunk/runtests.py, line 75 https://reviewboard.asterisk.org/r/4080/diff/2/?file=68354#file68354line75 This should include a + \n like line 59 does. jbigelow wrote: Line 59 adds a newline to visually separate the test that was run from the tests output. Line 67 doesn't add a new line to the tests output and I don't believe I should just for this message that I'm appending to the output either. Scott Griepentrog wrote: My concern is that another function executing later could (optionally, on some error) write to self.stdout. If there is zero possibility of that, then omitting the \n is not an issue. I don't see anything else being concatenated to self.stdout but can't guarantee some code will be added in the future that does so I've added the new line. - jbigelow --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4080/#review13558 --- On Oct. 20, 2014, 11:38 a.m., jbigelow wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4080/ --- (Updated Oct. 20, 2014, 11:38 a.m.) Review request for Asterisk Developers. Repository: testsuite Description --- When the 'expected-result' (or 'expectedResult') YAML property for test configuration is set to False and the test fails, the test should be marked as passed. However it is marked as failed. This patch should fix the issue so that tests are marked as passed in this scenario. Additionally: * Check if p.returncode is not zero so self.passed is a boolean rather than an int in some cases. * Added some print statements to make it clear why a test was marked as passed or failed when the 'expected-result' YAML property is set to False. * Added text to the failure message so it's easily known when looking at the results file that the test was expected to fail but passed and therefore marked as failed. Diffs - /asterisk/trunk/runtests.py 5726 /asterisk/trunk/lib/python/asterisk/test_config.py 5726 Diff: https://reviewboard.asterisk.org/r/4080/diff/ Testing --- Tested the various scenarios and they all seem to properly work as expected now. 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
[asterisk-dev] open appliance platform
Anyone looking to develop an IP-PBX appliance with a built-in VoIP gateway for 2 to 160 calls should check out Patton's new hardware platform. The product announcement headline reads: Patton Opens SmartNode VoIP CPE to VoIP UC Appliance Developers. Go to http://www.patton.com/company/newsrelease.asp?id=2592 W. Glendon Flowers, BSCS Product Marketing Manager Patton Electronics Co. 7622 Rickenbacker Drive Gaithersburg, MD 20879, USA tel: +1 301-975-1000 fax: +1 301-869-9293 http://www.patton.com/ cid:image002.png@01CDD49C.1D9800A0 http://marketing.patton.com/email/images/glen.jpg http://www.patton.com/info/index.asp?t=27 cid:7EB40FE5-7BEF-4BF4-97EA-1D4C4D835857@patton.intranet -- _ -- 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] open appliance platform
On Tue, Oct 21, 2014 at 11:36 AM, Glen Flowers gflow...@patton.com wrote: Anyone looking to develop an IP-PBX appliance with a built-in VoIP gateway for 2 to 160 calls should check out Patton’s new hardware platform. The product announcement headline reads: “Patton Opens SmartNode VoIP CPE to VoIP UC Appliance Developers.” Go to http://www.patton.com/company/newsrelease.asp?id=2592 Can I get one for free? -- Paul Belanger | PolyBeacon, Inc. Jabber: paul.belan...@polybeacon.com | IRC: pabelanger (Freenode) Github: https://github.com/pabelanger | Twitter: https://twitter.com/pabelanger -- _ -- 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] 4100: codec_dahdi: Fix crash on load of codec_dahdi.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4100/ --- Review request for Asterisk Developers. Bugs: ASTERISK-24435 https://issues.asterisk.org/jira/browse/ASTERISK-24435 Repository: Asterisk Description --- Codec_dahdi is the only translator that uses the struct ast_translator-core_src_codec and struct ast_translator-core_dst_codec pointers. Unfortunately, nothing ever initialized the pointers. Diffs - /branches/13/main/translate.c 426078 /branches/13/include/asterisk/translate.h 426078 /branches/13/codecs/codec_dahdi.c 426078 Diff: https://reviewboard.asterisk.org/r/4100/diff/ Testing --- Made some calls that perform translation. No crashes happened. 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] open appliance platform
Glenn, You are misusing this list - this is not for commercial information, it's for discussions about asterisk development. By doing this you are hurting your company as well as your own reputation. IN the future, please be a bit more careful before sending out to mailing lists and posting in open forums. Check the rules, verify what's allowed, especially when doing sales. For this kind of information, we have the asterisk-biz mailing list, where you are more than welcome to post. Thank you, /Olle Glen Flowers skrev 2014-10-21 17:36: --deleted-- -- _ -- 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] 4101: Channel Originate 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/ --- 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 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 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] 4101: Channel Originate 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/ --- (Updated Oct. 21, 2014, 5:27 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 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 (updated) --- 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] 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/ --- (Updated Oct. 21, 2014, 5:27 p.m.) Review request for Asterisk Developers. Bugs: ASTERISK-24412 https://issues.asterisk.org/jira/browse/ASTERISK-24412 Repository: Asterisk Description (updated) --- 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] 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/ --- (Updated Oct. 21, 2014, 5:27 p.m.) Review request for Asterisk Developers. Summary (updated) - Channel Originate/Continue via ARI support for labels in dialplan is incomplete 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 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] 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/ --- (Updated Oct. 21, 2014, 5:47 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 (updated) - /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] 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/ --- (Updated Oct. 21, 2014, 5: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 (updated) - /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
[asterisk-dev] [Code Review] 4102: testsuite: add secure websocket test
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4102/ --- Review request for Asterisk Developers. Repository: testsuite Description --- Borrowed basic playback test and modified it to use the wss: protocol instead of ws: protocol. This presumes that Autobahn supports wss: prefix as a method of triggering usage of a secure websocket. Diffs - /asterisk/trunk/tests/rest_api/tests.yaml 5766 /asterisk/trunk/tests/rest_api/secure-websocket/test-config.yaml PRE-CREATION /asterisk/trunk/tests/rest_api/secure-websocket/configs/ast1/extensions.conf PRE-CREATION /asterisk/trunk/lib/python/asterisk/ari.py 5766 Diff: https://reviewboard.asterisk.org/r/4102/diff/ Testing --- Test fails. Haven't determined why as yet. 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
[asterisk-dev] Dockerfile for Asterisk testsuite
Hello Astridevcon, This is an example for a dockerfile to run asterisk testsuite in a docker. https://github.com/sboily/asterisk-testsuite Suggestion/test are welcome ;-). Maybe it will be interesting to use it with jenkins to getting test in continue. There is also an image in the docker the hub. https://registry.hub.docker.com/u/quintana/asterisk-testsuite/ Have a good Astricon ! Sylvain -- _ -- 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] Asterisk 11.9.0 Segmentation fault.
Thank you for your response. 2) Based on this backtrace, it shows chan_sip calling into this client library, which doesn't exist in Asterisk code, so it could be a problem specific to modifications made in your version. I did not modify Asterisk code, but I am using the oracle libraly for realtime database. I check the library. Best Regards yoshikiyo.tamechika -- _ -- 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
