[Home]

Summary:ASTERISK-17263: [patch] No MOH on Call Park and Exceptionally long voice queue length ...
Reporter:Joel Vandal (jvandal)Labels:
Date Opened:2011-01-18 08:58:15.000-0600Date Closed:2011-02-03 14:51:10.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Resources/res_features
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 6002_to_6010_and_6002_SIP_park_transfer_MOH_mp3.txt
( 1) 6002_to_6010_and_6002_SIP_park_transfer_MOH_WAV.txt
( 2) 6002_to_6010_and_6010_SIP_park_transfer_MOH_mp3.txt
( 3) 6002_to_6010_and_6010_SIP_park_transfer_MOH_WAV.txt
( 4) attached_pid_asterisk_gdb_thread_apply_all_bt.txt
( 5) attended_SIP_park_transfer_with_native_MOH_CLI.txt
( 6) attended_SIP_park_transfer_with_native_MOH_CLI_debug_enabled.txt
( 7) attended_SIP_park_transfer_with_native_MOH_exceptionally_long_warning_debug_with_park_callback.txt
( 8) attended_SIP_park_transfer_with_native_MOH_exceptionally_long_warnings.txt
( 9) attended_SIP_park_transfer_with_native_MOH_segfault.txt
(10) attended_SIP_park_transfer_with_native_MOH_segfault_2_debug.txt
(11) bug18637.patch
(12) bug18637.patch.debugoutput.txt
(13) core_show_channels_parked_and_after_h.txt
(14) exceptionallylong1.txt
(15) exceptionally_long_not_optimized_with_core_show_locks.txt
(16) gdb_core_jan_19_2011_non_optimized.txt
(17) malloc_debug.txt
(18) park_segfault_optimized_bt.txt
(19) valgrind.txt
Description:I have 2 extensions :

- SIP 250
- IAX2 251

When both 250 / 251 are on a call and that an 250 (SIP) press ASTERISK-68 (one touch park) then no MOH is played on 251 and have this warning message displayed every seconds :

[2011-01-18 09:28:21] WARNING[18208]: channel.c:985 __ast_queue_frame: Exceptionally long voice queue length queuing to IAX2/251-6506

On same setup, if 251 do the parking (ASTERISK-68) then MOH is played correctly on 250.

Any ideas where to look in order to debug ?



****** ADDITIONAL INFORMATION ******

[2011-01-18 09:27:57]     -- Executing [250@default-admin:1] Set("IAX2/251-6506", "LOCAL_EXTEN=250") in new stack
[2011-01-18 09:27:57]     -- Executing [250@default-admin:2] Gosub("IAX2/251-6506", "all-local-extension|s|1") in new stack
[2011-01-18 09:27:57]     -- Executing [s@all-local-extension:1] Set("IAX2/251-6506", "__PICKUPMARK=250") in new stack
[2011-01-18 09:27:57]     -- Executing [s@all-local-extension:2] GotoIf("IAX2/251-6506", "0?4") in new stack
[2011-01-18 09:27:57]     -- Executing [s@all-local-extension:3] Set("IAX2/251-6506", "GROUP(OUTGOING)=251") in new stack
[2011-01-18 09:27:57]     -- Executing [s@all-local-extension:4] Set("IAX2/251-6506", "OUTBOUND_GROUP_ONCE=250@INCOMING") in new stack
[2011-01-18 09:27:57]     -- Executing [s@all-local-extension:5] GotoIf("IAX2/251-6506", "1?8") in new stack
[2011-01-18 09:27:57]     -- Goto (all-local-extension,s,8)
[2011-01-18 09:27:57]     -- Executing [s@all-local-extension:8] Return("IAX2/251-6506", "") in new stack
[2011-01-18 09:27:57]     -- Executing [250@default-admin:3] Set("IAX2/251-6506", "SCOPSERV_DBPUT(default/wrapup/250/lastcall)=1295360877.14") in new stack
[2011-01-18 09:27:57]     -- Executing [250@default-admin:4] Macro("IAX2/251-6506", "default-dial|SIP/250|250|default|20|fr||mtkK||default||Local/250@default-local-voicemail|vm") in new stack
[2011-01-18 09:27:57]     -- Executing [s@macro-default-dial:1] NoOp("IAX2/251-6506", ""CALL TO LOCAL EXTENSION FROM 251(Joel)"") in new stack
[2011-01-18 09:27:57] DEBUG[30050]: app_macro.c:379 _macro_exec: Executed application: NoOp
[2011-01-18 09:27:57]     -- Executing [s@macro-default-dial:2] Set("IAX2/251-6506", "__PICKUPMARK=250") in new stack
[2011-01-18 09:27:57] DEBUG[30050]: app_macro.c:379 _macro_exec: Executed application: Set
[2011-01-18 09:27:57]     -- Executing [s@macro-default-dial:3] AGI("IAX2/251-6506", "agi://127.0.0.1:4573/dial") in new stack
[2011-01-18 09:27:57]     -- AGI Script Executing Application: (NoOp) Options: (STATUS:)
[2011-01-18 09:27:57]     -- AGI Script Executing Application: (Dial) Options: (SIP/250|20|mtkKT|)
[2011-01-18 09:27:57]     -- Called 250
[2011-01-18 09:27:57]     -- Started music on hold, class 'default', on IAX2/251-6506
[2011-01-18 09:27:57]     -- SIP/250-00000006 is ringing
[2011-01-18 09:27:57]     -- SIP/250-00000006 is ringing
[2011-01-18 09:27:58]     -- SIP/250-00000006 is ringing
[2011-01-18 09:28:00]     -- SIP/250-00000006 is ringing
[2011-01-18 09:28:02]     -- SIP/250-00000006 answered IAX2/251-6506
[2011-01-18 09:28:02]     -- Stopped music on hold on IAX2/251-6506
[2011-01-18 09:28:03]   == Parsing '/etc/asterisk/manager.conf': [2011-01-18 09:28:03] Found
[2011-01-18 09:28:06] DTMF[30050]: channel.c:2520 __ast_read: DTMF begin '#' received on SIP/250-00000006
[2011-01-18 09:28:06] DTMF[30050]: channel.c:2530 __ast_read: DTMF begin passthrough '#' on SIP/250-00000006
[2011-01-18 09:28:06] DTMF[30050]: channel.c:2438 __ast_read: DTMF end '#' received on SIP/250-00000006, duration 140 ms
[2011-01-18 09:28:06] DTMF[30050]: channel.c:2475 __ast_read: DTMF end accepted with begin '#' on SIP/250-00000006
[2011-01-18 09:28:06] DTMF[30050]: channel.c:2504 __ast_read: DTMF end passthrough '#' on SIP/250-00000006
[2011-01-18 09:28:06] DTMF[30050]: channel.c:2520 __ast_read: DTMF begin '7' received on SIP/250-00000006
[2011-01-18 09:28:06] DTMF[30050]: channel.c:2530 __ast_read: DTMF begin passthrough '7' on SIP/250-00000006
[2011-01-18 09:28:06] DTMF[30050]: channel.c:2438 __ast_read: DTMF end '7' received on SIP/250-00000006, duration 80 ms
[2011-01-18 09:28:06] DTMF[30050]: channel.c:2475 __ast_read: DTMF end accepted with begin '7' on SIP/250-00000006
[2011-01-18 09:28:06] DTMF[30050]: channel.c:2490 __ast_read: DTMF end '7' detected to have actual duration 59 on the wire, emulation will be triggered on SIP/250-00000006
[2011-01-18 09:28:06] DTMF[30050]: channel.c:2497 __ast_read: DTMF end '7' has duration 59 but want minimum 80, emulating on SIP/250-00000006
[2011-01-18 09:28:06] DTMF[30050]: channel.c:2553 __ast_read: DTMF end emulation of '7' queued on SIP/250-00000006
[2011-01-18 09:28:06] DTMF[30050]: channel.c:2520 __ast_read: DTMF begin '2' received on SIP/250-00000006
[2011-01-18 09:28:06] DTMF[30050]: channel.c:2530 __ast_read: DTMF begin passthrough '2' on SIP/250-00000006
[2011-01-18 09:28:07] DTMF[30050]: channel.c:2438 __ast_read: DTMF end '2' received on SIP/250-00000006, duration 140 ms
[2011-01-18 09:28:07] DTMF[30050]: channel.c:2475 __ast_read: DTMF end accepted with begin '2' on SIP/250-00000006
[2011-01-18 09:28:07] DTMF[30050]: channel.c:2504 __ast_read: DTMF end passthrough '2' on SIP/250-00000006
[2011-01-18 09:28:08]     -- Started music on hold, class 'default', on IAX2/251-6506
[2011-01-18 09:28:08]   == Parked IAX2/251-6506 on 701@parkedcalls. Will timeout back to extension [default-admin] 250, 4 in 99999 seconds
[2011-01-18 09:28:08]     -- Added extension '701' priority 1 to parkedcalls
[2011-01-18 09:28:08]     -- <SIP/250-00000006> Playing 'digits/7' (language 'fr')
[2011-01-18 09:28:08]     -- <SIP/250-00000006> Playing 'digits/0' (language 'fr')
[2011-01-18 09:28:09]     -- <SIP/250-00000006> Playing 'digits/1' (language 'fr')
[2011-01-18 09:28:10] WARNING[18211]: channel.c:985 __ast_queue_frame: Exceptionally long voice queue length queuing to IAX2/251-6506
[2011-01-18 09:28:10]     -- Executing [h@macro-default-dial:1] ResetCDR("Parked/IAX2/251-6506<ZOMBIE>", "w") in new stack
[2011-01-18 09:28:10]     -- Executing [h@macro-default-dial:2] NoCDR("Parked/IAX2/251-6506<ZOMBIE>", "") in new stack
[2011-01-18 09:28:10] DEBUG[30050]: res_agi.c:1925 run_agi: Parked/IAX2/251-6506<ZOMBIE> hungup
[2011-01-18 09:28:10]   == Spawn extension (macro-default-dial, s, 3) exited non-zero on 'Parked/IAX2/251-6506<ZOMBIE>' in macro 'default-dial'
[2011-01-18 09:28:10]   == Spawn extension (default-admin, 250, 4) exited non-zero on 'Parked/IAX2/251-6506<ZOMBIE>'
[2011-01-18 09:28:11] WARNING[18209]: channel.c:985 __ast_queue_frame: Exceptionally long voice queue length queuing to IAX2/251-6506
[2011-01-18 09:28:12] WARNING[18204]: channel.c:985 __ast_queue_frame: Exceptionally long voice queue length queuing to IAX2/251-6506
[2011-01-18 09:28:13] WARNING[18205]: channel.c:985 __ast_queue_frame: Exceptionally long voice queue length queuing to IAX2/251-6506
[2011-01-18 09:28:15] WARNING[18204]: channel.c:985 __ast_queue_frame: Exceptionally long voice queue length queuing to IAX2/251-6506
[2011-01-18 09:28:16] WARNING[18209]: channel.c:985 __ast_queue_frame: Exceptionally long voice queue length queuing to IAX2/251-6506
[2011-01-18 09:28:17] WARNING[18211]: channel.c:985 __ast_queue_frame: Exceptionally long voice queue length queuing to IAX2/251-6506
[2011-01-18 09:28:19] WARNING[18210]: channel.c:985 __ast_queue_frame: Exceptionally long voice queue length queuing to IAX2/251-6506
[2011-01-18 09:28:20] WARNING[18204]: channel.c:985 __ast_queue_frame: Exceptionally long voice queue length queuing to IAX2/251-6506
[2011-01-18 09:28:21] WARNING[18208]: channel.c:985 __ast_queue_frame: Exceptionally long voice queue length queuing to IAX2/251-6506
[2011-01-18 09:28:22] WARNING[18207]: channel.c:985 __ast_queue_frame: Exceptionally long voice queue length queuing to IAX2/251-6506
[2011-01-18 09:28:24] WARNING[18212]: channel.c:985 __ast_queue_frame: Exceptionally long voice queue length queuing to IAX2/251-6506
[2011-01-18 09:28:24]     -- Executing [701@default-admin:1] ParkedCall("SIP/250-00000007", "701") in new stack
[2011-01-18 09:28:24]     -- Stopped music on hold on IAX2/251-6506
[2011-01-18 09:28:24]     -- Channel SIP/250-00000007 connected to parked call 701
[2011-01-18 09:28:29]     -- Hungup 'IAX2/251-6506'
[2011-01-18 09:28:29]   == Spawn extension (default-admin, 701, 1) exited non-zero on 'SIP/250-00000007'
Comments:By: David Brillert (aragon) 2011-01-18 09:35:17.000-0600

I have also seen this issue and when the issue appears the CPU load gets high.
By: David Brillert (aragon) 2011-01-18 09:48:41.000-0600

Actually I can reproduce at will with one touch park feature code.
1.4.39

It's worse than I originally thought since the remote caller can hang up and the channel remains parked while this debug message spams the console.  Spamming continues until I dial the parking extension to retrieve the parked call and hangup to end the spam.
[2011-01-18 10:44:14] DEBUG[30542]: res_musiconhold.c:613 monmp3thread: Only wrote -1 of 640 bytes to pipe
[2011-01-18 10:44:14] DEBUG[30542]: res_musiconhold.c:613 monmp3thread: Only wrote -1 of 640 bytes to pipe
[2011-01-18 10:44:14] DEBUG[30542]: res_musiconhold.c:613 monmp3thread: Only wrote -1 of 640 bytes to pipe

I'm doing more testing and will attach some debug files.
By: David Brillert (aragon) 2011-01-18 09:56:42.000-0600

Same nasty stuff happens when I do an attended SIP transfer to park extension.
By: David Brillert (aragon) 2011-01-18 09:58:06.000-0600

Also produced a segfault during SIP parking tests.
Tested 3 calls and 1 call caused segfault.
Sorry to say that BT is from optimized Asterisk build but supplying BT anyway.
By: David Brillert (aragon) 2011-01-18 10:00:21.000-0600

Program terminated with signal 11, Segmentation fault.
#0  0x008d33b4 in local_fixup (oldchan=0x8645268, newchan=0x85e3ad8) at chan_local.c:433
433     chan_local.c: No such file or directory.
in chan_local.c
By: David Brillert (aragon) 2011-01-18 10:08:11.000-0600

Also during both attended and blind SIP parking tests the calling party went on hold and could not hear any moh after transfer completion.
100% reproducible on each call.
Caller dialed through on PRI channel to SIP extension and SIP extension did the parking on each test.

IMHO parking appears badly broken and this looks like a really bad regression.
By: David Brillert (aragon) 2011-01-19 13:02:40.000-0600

Today I have tested the problem on a non optimized build of Asterisk 1.4.39
Debug option enabled.
Ran through SIP attended transfer test and uploading:
exceptionally long not optimized with core show locks.txt

Nothing appears locked at core show locks

Attaching gdb to pid of Asterisk and attaching:
pid asterisk gdb thread apply all bt.txt

Ran Asterisk under Valgrind attaching:
malloc_debug.txt
valgrind.txt

Now I will attempt to get Asterisk to segfault and if I can I will attach gdb backtrace of non optimized build.
By: David Brillert (aragon) 2011-01-19 13:10:11.000-0600

Didn't take very long to crash Asterisk with SIP attended transfer to park extension.
Attaching bt:
gdb core jan 19 2011 non optimized.txt
By: David Brillert (aragon) 2011-01-19 13:17:15.000-0600

Note that there are orphaned channels every time I park a call coming from the inbound PRI and the PRI caller channel hangs up.
The parking extensions continue to increment with orphaned channels until the park timeout callback to test extension 6010 which IMHO causes the crash since the PRI channel no longer exists.
There was so much CLI spam that I was not able to get output of core show channels
By: David Brillert (aragon) 2011-01-20 08:51:48.000-0600

I cannot reproduce a crash on each failed park callback.  The segfault is intermittent however the callback always fails.  I guess that is a separate bug and probably another regression in the park code.
By: David Brillert (aragon) 2011-01-20 09:19:24.000-0600

PRI incoming call to 6010

lab*CLI> core show channels
Channel              Location             State   Application(Data)
SIP/6010-00000016    (None)               Up      AppDial((Outgoing Line))
Local/6010@default-l s@macro-default-dial Up      Dial(SIP/6010|20|tkKT|)
Local/6010@default-l (None)               Up      AppDial((Outgoing Line))
Zap/23-1             6010@zap-incoming:26 Up      Dial(Local/6010@default-local/
4 active channels
2 of 460 max active calls ( 0.43% of capacity)

6010 transfer to park extension 7000
Call is parked on first available parking orbit 7001 using attended SIP transfer.

lab*CLI> core show channels
Channel              Location             State   Application(Data)
Local/6010@default-l s@default-super:1    Up      Parked Call()
Local/6010@default-l (None)               Up      AppDial((Outgoing Line))
Zap/23-1             6010@zap-incoming:26 Up      Dial(Local/6010@default-local/
3 active channels
1 of 460 max active call ( 0.22% of capacity)

Caller on PRI channel channel hangs up

lab*CLI> core show channels
Channel              Location             State   Application(Data)
Local/6010@default-l s@default-super:1    Up      Parked Call()
1 active channel
0 of 460 max active calls ( 0.00% of capacity)

6010 is still bridged with the park extension although the park extension 7001 is no longer bridged with the incoming PRI channel.  Some intelligence is needed to drop the local channel bridged with the park extension if the incoming channel is hung up.

I have attached the full CLI to this ticket:
core show channels parked and after h.txt

Of course this does not explain the exceptionally long... but I still see that warning even after the incoming channel disappears as long as 6010 is bridged with the park extension.  Possibly caused by the MOH RTP bridging.  I'll re-test using native .WAV MOH
By: David Brillert (aragon) 2011-01-20 09:25:02.000-0600

On my first test of SIP attended transfer using native .WAV MOH Asterisk segfaulted.
Attaching:
attended SIP park transfer with native MOH segfault.txt
By: David Brillert (aragon) 2011-01-20 09:27:51.000-0600

attachment = attended SIP park transfer with native MOH CLI.txt is corresponding CLI output during segfault.
By: David Brillert (aragon) 2011-01-20 09:35:41.000-0600

Another segfault with native MOH.
This time I had debug enabled to console in CLI.
Fresh backtraces attached:
attended SIP park transfer with native MOH segfault 2 debug.txt
is associated with
attended SIP park transfer with native MOH CLI debug enabled.txt
By: David Brillert (aragon) 2011-01-20 09:44:53.000-0600

In  order to see if exceptionally long warning were still logged during native MOH park I noticed the following:
-If I waited for the parking extension to play back to 6010 in entirety Asterisk would segfault every time.
-If I transferred before parking extension play back to 6010 completed I could complete the park transfer and generate the warnings.
So I have attached another file which is CLI output of SIP park transfer prior to play back completion:
attended SIP park transfer with native MOH exceptionally long warnings.txt
By: David Brillert (aragon) 2011-01-20 09:53:26.000-0600

I noticed that config for 6010 allowed g722 and I had some g722 WAV files in MOH directory.  So I removed g722 codec support from 6010.
This allowed me to complete a park transfer with a successful park call back after timeout which I could not do with file based mp3 MOH.
Attaching CLI with debug enabled:
attended SIP park transfer with native MOH exceptionally long warning debug with park callback.txt
By: David Brillert (aragon) 2011-01-20 10:31:01.000-0600

I ran similar tests on SIP parking on SIP local channels but could not reproduce exceptionally long warnings on local SIP channels.
I also heard MOH regardless of which extension would park the call.  However in each scenario I was left with a hung SIP channel bridged with a parking extension even after one of the two SIP extensions hung up their channel.
I did not attempt to park a call twice after the same initial call setup.
I tested both native WAV MOH and mp3 MOH.
Attaching debugs:
6002 calls 6010 and 6002 parks 6010 WAV MOH = 6002 to 6010 and 6002 SIP park transfer MOH WAV.txt

6002 calls 6010 and 6010  parks 6002 WAV MOH = 6002 to 6010 and 6010 SIP park transfer MOH WAV.txt

6002 calls 6010 and 6002 parks 6010 mp3 MOH = 6002 to 6010 and 6002 SIP park transfer MOH mp3.txt

6002 calls 6010 and 6010  parks 6002 mp3 MOH = 6002 to 6010 and 6010 SIP park transfer MOH mp3.txt

I will re-test these scenarios using DTMF one touch  park code to see if I can reproduce jvandal's original bug report on local SIP channels.


By: David Brillert (aragon) 2011-01-20 10:38:38.000-0600

Same results with DTMF park code.
By: Jeff Peeler (jpeeler) 2011-02-02 17:55:27.000-0600

The attached patch fixes the no MOH and hung channels on hangup. I assume that it will fix the other problems as well.
By: David Brillert (aragon) 2011-02-03 09:41:45.000-0600

jpeeler:  Just tested your patch.
Seems like there is excessive locking with this patch.
But at least the MOH hung channels problem is gone away with this patch.
Also could you shed some light on the spaminess of these messages once MOH kicks in?
audiohook.c:224 audiohook_read_frame_both: Read factory 0x8da2960 and write factory 0x8da337c both fail to provide 160 samples

CLI output uploaded as bug18637.patch.debugoutput.txt
By: David Brillert (aragon) 2011-02-03 10:06:51.000-0600

jpeeler: I should have mentioned the version number I tested your patch with:
Asterisk SVN-branch-1.4-r305888
By: David Brillert (aragon) 2011-02-03 10:08:10.000-0600

jpeeler:  another bonus of your patch is that the "Exceptionally long voice queue length queuing" messages seem to have disappeared during the park.
By: Jeff Peeler (jpeeler) 2011-02-03 10:10:12.000-0600

Aragon: Is MOH also playing with the patch?
By: David Brillert (aragon) 2011-02-03 10:11:12.000-0600

Yes I do hear MOH
By: Jeff Peeler (jpeeler) 2011-02-03 10:28:46.000-0600

Thanks for testing. The goal of the patch was to solve the reporter's problem of no MOH and the frame queue problem which you said is fixed now. All of these locking problems and crashes should have been reported on another bug, so I guess I'll leave this issue open as I do not think I'll be able to fix those issues right now.
By: David Brillert (aragon) 2011-02-03 10:34:08.000-0600

jpeeler: I did open separate bug reports for the other issues:

0018684: [REGRESSION]: Transfer to park extension leaves zombie channels if incoming PRI channel disconnects and sometimes segfaults *

0018683: [REGRESSION]: Attended SIP transfer to park extension segfaults Asterisk

I agree that MOH can now be heard and that the Exceptionally long... warnings are gone so this bug report could probably be closed out.
But what to do about the new locking issues I just found during recent testing?
How can I open a new bug report on code (your patch) if it has not been committed?

I have no problem opening a separate issue for the audiohooks warnings...
By: Jeff Peeler (jpeeler) 2011-02-03 10:38:19.000-0600

Ok glad the issues are separated. Is this output after the parking has occurred?
By: David Brillert (aragon) 2011-02-03 10:54:44.000-0600

jpeeler: Yes this output shows the output during park.
I did not include the parking callback after timeout or hangup.

Also I have updated the notes in ASTERISK-17291 ASTERISK-17290

How do you want to handle the locking issues?  Do you want me to create a new bug report?
I would like to delay opening a bug report on the audiohooks issues until the locking issues get sorted out.
By: Jeff Peeler (jpeeler) 2011-02-03 11:06:52.000-0600

I can't see how my patch would affect locking. Open a separate bug report and make sure to include a reproducible dialplan example with the local channels involved.
By: David Brillert (aragon) 2011-02-03 11:16:10.000-0600

OK perhaps the locking was introduced between my/jvandal's reported version and the SVN Version I checked out to test your patch today.

I guess that means you could commit your code and close out the following reports:
ASTERISK-17291 ASTERISK-17290 ASTERISK-17263

I'll open new reports on the locking and the audiohooks warnings
By: David Brillert (aragon) 2011-02-03 11:32:11.000-0600

jpeeler: ASTERISK-17347 is now open to document locking issues.
By: David Brillert (aragon) 2011-02-03 11:35:14.000-0600

I'll try to reproduce the locking without your patch on same subversion
By: David Brillert (aragon) 2011-02-03 12:13:33.000-0600

jpeeler:  I confirmed locking is caused by your patch by checking out fresh version of 305888 without your patch.
By: David Brillert (aragon) 2011-02-03 12:14:50.000-0600

jpeeler: good news is that now I can open a new report for the  audiohook.c:278 audiohook_read_frame_both issues since the locking is no longer making the CLI useless.
By: David Brillert (aragon) 2011-02-03 12:27:12.000-0600

jpeeler: the audiohook messages are coming from mixmonitor so I have opened a separate report for that also ASTERISK-17348
By: David Brillert (aragon) 2011-02-03 12:28:58.000-0600

jpeeler:  r305888 still exhibits exceptionally long messages and hung channels without patch.
By: Jeff Peeler (jpeeler) 2011-02-03 13:28:36.000-0600

Any chance you can get on IRC? I'm so confused right now. Your ASTERISK-17347 states that my patch caused the locking issue, but doesn't mention parking. Was a parking occurring or not?
By: David Brillert (aragon) 2011-02-03 13:40:41.000-0600

Earliest I could get on IRC is tomorrow morning.
The locking occurs with or without park.
Lock occurs SIP to SIP during active call or PRI to SIP
By: Jeff Peeler (jpeeler) 2011-02-03 13:42:09.000-0600

That's what I was trying to get at. If the locking issue occurs without a park then it is a separate issue not affected by my patch.
By: David Brillert (aragon) 2011-02-03 13:59:48.000-0600

Except I opened ASTERISK-17347 with your patch installed.
The locking disappears if I use a stock r305888 svn checkout (no patch)
By: Jeff Peeler (jpeeler) 2011-02-03 14:04:32.000-0600

Ok well if that's the case then I won't commit it until it's ready and it doesn't need to be separated out from this issue.
By: Jeff Peeler (jpeeler) 2011-02-03 14:16:47.000-0600

Why did you say "The locking occurs with or without park"? I'm still at a loss here.
By: Jeff Peeler (jpeeler) 2011-02-03 14:43:33.000-0600

I think you should retest and report the results on 18743 after I commit here, it really shouldn't affect locking...
By: Digium Subversion (svnbot) 2011-02-03 14:44:00.000-0600

Repository: asterisk
Revision: 306120

U   branches/1.4/res/res_features.c

------------------------------------------------------------------------
r306120 | jpeeler | 2011-02-03 14:44:00 -0600 (Thu, 03 Feb 2011) | 9 lines

Fix no MOH and frame queueing problem for parked calls.

This was a regression introduced when select was changed to poll and was
just a conversion error: POLLPRI detects OOB data, not POLLERR.

(closes issue ASTERISK-17263)
Reported by: jvandal


------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=306120
By: Digium Subversion (svnbot) 2011-02-03 14:49:49.000-0600

Repository: asterisk
Revision: 306123

U   branches/1.6.2/main/features.c

------------------------------------------------------------------------
r306123 | jpeeler | 2011-02-03 14:49:49 -0600 (Thu, 03 Feb 2011) | 10 lines

Set exception on channel in parking thread when POLLPRI event detected.

This is done just to make the code be equivalent to the old select code. As
noted in 303106 the same issue was already fixed in this branch, but the
exception was not set on the channel in the case of POLLPRI. The reason that
this did not cause a problem here is because in 122923 the check in __ast_read
to check the exception flag was removed.

(related to ASTERISK-17263)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=306123
By: Digium Subversion (svnbot) 2011-02-03 14:50:49.000-0600

Repository: asterisk
Revision: 306124

_U  branches/1.8/
U   branches/1.8/main/features.c

------------------------------------------------------------------------
r306124 | jpeeler | 2011-02-03 14:50:48 -0600 (Thu, 03 Feb 2011) | 17 lines

Merged revisions 306123 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2

........
 r306123 | jpeeler | 2011-02-03 14:49:48 -0600 (Thu, 03 Feb 2011) | 10 lines
 
 Set exception on channel in parking thread when POLLPRI event detected.
 
 This is done just to make the code be equivalent to the old select code. As
 noted in 303106 the same issue was already fixed in this branch, but the
 exception was not set on the channel in the case of POLLPRI. The reason that
 this did not cause a problem here is because in 122923 the check in __ast_read
 to check the exception flag was removed.
 
 (related to ASTERISK-17263)
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=306124
By: Digium Subversion (svnbot) 2011-02-03 14:51:10.000-0600

Repository: asterisk
Revision: 306125

_U  trunk/
U   trunk/main/features.c

------------------------------------------------------------------------
r306125 | jpeeler | 2011-02-03 14:51:09 -0600 (Thu, 03 Feb 2011) | 24 lines

Merged revisions 306124 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8

................
 r306124 | jpeeler | 2011-02-03 14:50:48 -0600 (Thu, 03 Feb 2011) | 17 lines
 
 Merged revisions 306123 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.6.2
 
 ........
   r306123 | jpeeler | 2011-02-03 14:49:48 -0600 (Thu, 03 Feb 2011) | 10 lines
   
   Set exception on channel in parking thread when POLLPRI event detected.
   
   This is done just to make the code be equivalent to the old select code. As
   noted in 303106 the same issue was already fixed in this branch, but the
   exception was not set on the channel in the case of POLLPRI. The reason that
   this did not cause a problem here is because in 122923 the check in __ast_read
   to check the exception flag was removed.
   
   (related to ASTERISK-17263)
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=306125