Summary:	ASTERISK-02390: calls and audio recorded from GS phone plays back at double speed
Reporter:	ipdeman (ipdeman)	Labels:
Date Opened:	2004-09-12 00:01:29	Date Closed:	2004-09-25 02:04:41
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/CodecHandling
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	Can anyone confirm this. 1 out of every 5 or so calls and recordings from a GS phone result in audio being played at double speed. Pitch is not changed but.  This just seen to start happening in the last day or so. Easiest way to test is make a test recording form the handset and play it back. Takes about 5 ot 6 times before you can get a file that plays back about double speed. ****** ADDITIONAL INFORMATION ****** Slackware 10, 2.4.26 and 2.4.27 kernels (tried both since I had upgraded), gcc 3.3.4, Celeron with Intel chipset motherboard, CVS-HEAD-09/10/04-15:19:47
Comments:	By: Mark Spencer (markster) 2004-09-12 00:57:58 This bug sounds so bogus that I cannot in good faith even leave this open in its current condition. Most likely it sounds like you have the grandstream misconfigured for the wrong number of ms per packet (you should have it set to 20ms per packet).  This is almost certainly not an Asterisk bug, and I would strongly encourage you to come up with something a bit more concrete (e.g. a packet trace from ethereal showing too many packets going to the phone per unit time or a much more specific bug description) if you want to reopen this one out of confidence that it really is an asterisk bug. By: ipdeman (ipdeman) 2004-09-12 09:14:57 This is absoulutely not bogus. Phone is set at 20ms per packet. Asolutely nothing has bee changed on the phone since it was was first set up months ago. Audio is recorded at double or so speed and I have downloaded the gsm files back to my workstation to confirm. Audio sent back to the GS is not relavant in this case. It is how the audio is received and processsed on *. Calls terminated at PSTN users hear the same corrupted audio as is recorded. I have example gsm files I can send. I cannot run ethereal on the * server, since I don't have X installed and it is on a switch. I will however do a lot more test to try and find out what has changed. By: Mark Spencer (markster) 2004-09-12 09:53:09 Thank you for the clarification of the direction of the problem, but we will obviously still need to see the traffic on wire to be able to determine the source of the problem and possibly what else may have triggered it, and to see why you seem to be the only person to have seen this bug.   You do not need to run X to run ethereal to capture -- you can either use tcpdump to capture the initial data and save it to a file for processing with ethereal or you can use the text mode ethereal (tethereal) to capture. It may also be helpful to see your extension logic to do the recording but I imagine it's very simple. By: ipdeman (ipdeman) 2004-09-12 10:18:57 If I am the only person to have seen this bug, then obviously it is my problem. This is why I asked if anyone could confirm this report. I am in the process of backing up to where I don't have a problem. Keep in mind it is just not recordings but also outgoing audio routed to PSTN calls through the X100P card. The recording was just a way I could see how * was getting the audio. My record extension is very simple.  ;  ; Record voice file to /tmp directory  ;  exten => 205,1,Wait(1) ; Call 205 to Record new Sound Files  exten => 205,2,Record(/tmp/asterisk-recording:gsm)  exten => 205,3,Wait(1)  exten => 205,4,Playback(/tmp/asterisk-recording)  exten => 205,5,wait(1) edited on: 09-12-04 10:20 By: ipdeman (ipdeman) 2004-09-12 18:37:36 marster, You can close this bug report. Fianlly traced the problem down to a cisco 3640 router policy-map for voip. Don't really know what is causing the policy map to screw up the stream coming in, but I suspect I don't have all the siganling, ports, or protocals in the access list. For one thing SIP on UDP port 5060 was surely not there. I have just got to figure out which protocols and ports I should give priority to. Some I don't know liske the * IAX protocol. By: Mark Spencer (markster) 2004-09-12 18:43:40 Just because you are the only person seeing a bug does not mean by itself that it isn't a bug.  Often times, users have unusual configurations or combinations of options which cause bugs to show up for them that don't show up for other people.  However, it is imperative in these cases to get as much information as possible, typically looking on the wire, to be able to decide just what is causing the bug or in some cases such as this one, why the behavior happened at all. Please feel free to place bugs in the future, even if they're for unusual problems, but also, please try to provide as much debugging information as is reasonably possible right at the outset so that the bug can be handled as quickly and efficiently as possible.