Summary:	ASTERISK-09244: Polycom phones calling out on a TDM04B have a long delay before the called party can hear audio
Reporter:	xmarksthespot (xmarksthespot)	Labels:
Date Opened:	2007-04-11 10:12:42	Date Closed:	2011-06-07 14:07:48
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/Configuration
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) verbosedebug2.txt ( 1) verbosedebugfull.txt ( 2) verbosedebugsiphistory.txt ( 3) zapata.conf
Description:	I have now two machines producing this exact problem. The phones work fine on 1.2. Here's how it goes: 1. Make outbound phone call on the TDM04B 2. Wait for the called party to answer 3. Upon answering, there is a 5-10 seconds delay during which the called party cannot hear the caller, while the caller can hear. 4. After this delay has elapsed, audio is restored both ways. I have tried and replicated this problem with 100% reproductibility on asterisk 1.4.0, 1.4.1, 1.4.2 and SVN branch 1.4 revision 60137. So far it's 100% reproductibility on two different machines. ****** ADDITIONAL INFORMATION ****** The polycom phones are running the latest firmware 2.1.0.2708 It's my first bug report and I'm very nervous, please be gentle! I have a test machine here to test stuff, so fire away. Don't pay attention to the various database requests, the machine had IMAP support enabled before, which I disabled during compilation this time around. I blanked the phone number I was dialing for privacy purposes, is that a problem? The phone number I called is XXXXXXXXXX in the file. Since I do 9 before dialing, it appears as "9XXXXXXXXXX" in the verbosedebug2.txt file. The problem does not happen on internal calls. If a sip extension calls another sip extension, it works fine. The sip peer used for the test is named 2400, and is defined in an sql database. The problem does not happen with grandstream phones. I tried to clean up the file, if it's too cleaned up, please tell me I will submit the original.
Comments:	By: xmarksthespot (xmarksthespot) 2007-04-11 10:45:59 Forgot to mention, the machines are both running on Debian Etch RC1. I may have mischosen the category for this bug report, if that is the case, forgiveness please. NEW INFO: Just discovered that when the call is made, the polycom does not recognize the call as being in progress until audio is restored both ways. The polycom does not count the time until the sound is heard by the called party! NEW FILE ADDED: I added the file verbosedebugfull.txt... it's a correct verbose debug (in compliance with what is requested). I left the other one there for the sake of not falling into revisionism. NEW FILE ADDED: I had forgotten the sip history. It's in the last file. All files are different tests and represent the same issue. It's not like I'm having a hard time replicating it. PHONE INFO: The phones are Polycom 501s. I have not tried with different Polycom phones. I can supply my polycom config files as needed. By: xmarksthespot (xmarksthespot) 2007-04-18 09:37:13 This is actually a lot more serious than I had thought. The phones actually stay in the "communication" state even when the remote party has hungup! This is starting to be pretty important! By: Joshua C. Colp (jcolp) 2007-04-22 20:21:40 Please provide your zapata.conf file from /etc/asterisk. I suspect your problem is two fold: 1. You have callprogress set to yes so that chan_zap is trying to guess the progress of the phone call out the FXO port. Per the note this is HIGHLY experimental and can cause issues, if you disable it and this issue goes away - then that is it. 2. If a hangup notification is not provided by the telco on an analog line then chan_zap has to guess. Tweaking busydetect may allow hangup detection to work. By: xmarksthespot (xmarksthespot) 2007-04-23 15:55:44 1. Replacing the zapata.conf file with the one from samples cures the delay problem on outgoing calls on the polycom phones. I have no idea why it does this only on polycom and not on grandstream phones. I can provide you with both zapata.conf files soon. Something is in my file which causes this, but I don't know what. 2. The problem about not hanging up is still there and I have more information. If an outgoing call is made from a polycom, and the outgoing call is hungup by the remote party, everything gets closed normally, but the phone stays stuck in a weird state. (Asterisk produces "deferred dialing", and the messages "Something is weird, backing out" appear a number of times). I'll provide with a logfile of this during the week. Recap of #2: Sequence is: 1 - Outgoing call made from polycom on zap (TDM04B) 2 - Outgoing call is answered by remote party 3 - Outgoing call is hungup by remote party 4 - Zap channel gets closed properly 5 - Sip channel gets closed properly 6 - Polycom phone remains in a strange state, as if still in communication. 7 - Pressing "hold" in that state yields a deferred dialing. 8 - Pressing "transfer" yields some "Something is weird, backing out" messages. The same phones are on another asterisk 1.2 machine with a TDM04B, the calls are hung up properly if made on that server. Is this another bug report or does it go here? By: sturm (sturm) 2007-04-30 06:12:32 I have a very similar problem with Snom phones (300 and 320) and asterisk 1.2.14 (this is a production setup, so I cannot test with any other version). In our case, when dialing out, the caller does not hear the first few seconds of the callee saying 'hello'. I append my zapata.conf, which does not set callprogress. By: Joshua C. Colp (jcolp) 2007-06-27 18:02:10 Since this was a configuration issue I'm closing this out. If you are still having issues not related to this please open a new bug. Thanks.