Summary:	ASTERISK-18937: CLONE - Read factory 0xb6d0acb8 was pretty quick last time, waiting for them
Reporter:	David O Reilly (trendboy)	Labels:
Date Opened:	2011-11-29 16:45:43.000-0600	Date Closed:	2011-12-20 08:58:52.000-0600
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:	1.8.7.1	Frequency of Occurrence	Frequent
Related Issues:	is a clone of ASTERISK-15743 Read factory 0xb6d0acb8 was pretty quick last time, waiting for them
Environment:		Attachments:
Description:	Update: I called Digium support and reinstalled the G729 codec to see if that was the issue. Still the same except worse with a new issue - Failed to get 160 samples from read factory 0xb6e0d5f0 The calls continue to drop also. Thanks David ----- [2011-12-01 14:04:27] DEBUG[9008] audiohook.c: Read factory 0xb6e0d5f0 and write factory 0xb6e0e018 both fail to provide 160 samples [2011-12-01 14:04:27] DEBUG[9008] audiohook.c: Failed to get 160 samples from read factory 0xb6e0d5f0 [2011-12-01 14:04:27] DEBUG[9008] audiohook.c: Read factory 0xb6e0d5f0 and write factory 0xb6e0e018 both fail to provide 160 samples [2011-12-01 14:04:27] DEBUG[9008] audiohook.c: Failed to get 160 samples from read factory 0xb6e0d5f0 [2011-12-01 14:04:27] DEBUG[9008] audiohook.c: Read factory 0xb6e0d5f0 and write factory 0xb6e0e018 both fail to provide 160 samples [2011-12-01 14:04:27] DEBUG[9008] audiohook.c: Failed to get 160 samples from read factory 0xb6e0d5f0 [2011-12-01 14:04:27] DEBUG[9008] audiohook.c: Read factory 0xb6e0d5f0 and write factory 0xb6e0e018 both fail to provide 160 samples [2011-12-01 14:04:27] DEBUG[9008] audiohook.c: Failed to get 160 samples from read factory 0xb6e0d5f0 [2011-12-01 14:04:27] DEBUG[9008] audiohook.c: Read factory 0xb6e0d5f0 and I upgraded to the latest release but the problem persists. All calls are being dropped after a few minutes. The log shows a flood of this now: [2011-11-30 13:39:22] DEBUG[14760] audiohook.c: Read factory 0xb741d048 and write factory 0xb741da70 both fail to provide 160 samples [2011-11-30 13:39:22] DEBUG[14760] audiohook.c: Read factory 0xb741d048 was pretty quick last time, waiting for them. [2011-11-30 13:39:22] DEBUG[14760] audiohook.c: Read factory 0xb741d048 and write factory 0xb741da70 both fail to provide 160 samples [2011-11-30 13:39:22] DEBUG[14760] audiohook.c: Read factory 0xb741d048 was pretty quick last time, waiting for them. [2011-11-30 13:39:22] DEBUG[14760] audiohook.c: Read factory 0xb741d048 and write factory 0xb741da70 both fail to provide 160 samples [2011-11-30 13:39:22] DEBUG[14760] audiohook.c: Read factory 0xb741d048 was pretty quick last time, waiting for them. [2011-11-30 13:39:22] DEBUG[14760] audiohook.c: Read factory 0xb741d048 and write factory 0xb741da70 both fail to provide 160 samples [2011-11-30 13:39:22] DEBUG[14760] audiohook.c: Read factory 0xb741d048 was pretty quick last time, waiting for them. [2011-11-30 13:39:22] DEBUG[14760] audiohook.c: Read factory 0xb741d048 and write factory 0xb741da70 both fail to provide 160 samples [2011-11-30 13:39:22] DEBUG[14760] audiohook.c: Read factory 0xb741d048 was pretty quick last time, waiting for them. and the call drops with: ------ Based on a previous bug report that was never fixed but the same as mine. Calls are beging dropped for no reason and it starts with the sound quality dropping and then the caller unable to hear our call centre agents. Then the call drops or the caller hangs up unable to hear. To investigate I checked bandwidth with the hosting center - made sure all codecs between the telcos I use are the same to be G729 and I turned on debug mode. I get repeated flooding in debug mode of: [2011-11-29 20:59:08] DEBUG[19276] audiohook.c: Read factory 0x8bdfca0 was pretty quick last time, waiting for them. [2011-11-29 20:59:08] DEBUG[19276] audiohook.c: Read factory 0x8bdfca0 was pretty quick last time, waiting for them. [2011-11-29 20:59:08] DEBUG[19276] audiohook.c: Read factory 0x8bdfca0 was pretty quick last time, waiting for them. [2011-11-29 20:59:08] DEBUG[19276] audiohook.c: Read factory 0x8bdfca0 was pretty quick last time, waiting for them. [2011-11-29 20:59:08] DEBUG[19276] audiohook.c: Read factory 0x8bdfca0 was pretty quick last time, waiting for them. [2011-11-29 20:59:08] DEBUG[19276] audiohook.c: Read factory 0x8bdfca0 was pretty quick last time, waiting for them. [2011-11-29 20:59:08] DEBUG[19276] audiohook.c: Read factory 0x8bdfca0 was pretty quick last time, waiting for them. [2011-11-29 20:59:08] DEBUG[19276] audiohook.c: Read factory 0x8bdfca0 was pretty quick last time, waiting for them. [2011-11-29 20:59:08] DEBUG[19276] audiohook.c: Read factory 0x8bdfca0 was pretty quick last time, waiting for them. [2011-11-29 20:59:08] DEBUG[19276] audiohook.c: Read factory 0x8bdfca0 was pretty quick last time, waiting for them. [2011-11-29 20:59:08] DEBUG[19276] audiohook.c: Read factory 0x8bdfca0 was pretty quick last time, waiting for them. [2011-11-29 20:59:08] DEBUG[19276] audiohook.c: Read factory 0x8bdfca0 was pretty quick last time, waiting for them. I am using Asterisk 1.8.6.0 but your bug report doesn't appear to have this version? I will upgrade to the latest to see if this bug still exists if I am requested to but I would prefer not to if possible as this is a mission critical system. Also mixmonitor is on to record all calls. About 40% of calls are being dropped. The issue only started last week - it was perfect for months.
Comments:	By: Leif Madsen (lmadsen) 2011-12-01 14:24:08.284-0600 You should probably also provide information from the system just leading up to when you start to get this. This would include console debug information and SIP debug information. I'm not sure there is enough information for a developer to do anything with this. By: Leif Madsen (lmadsen) 2011-12-20 08:58:41.514-0600 Suspended due to lack of activity. Please request a bug marshal in #asterisk-bugs on the IRC network irc.freenode.net to reopen the issue should you have the additional information requested.  Further information can be found at http://www.asterisk.org/developers/bug-guidelines