Summary:	ASTERISK-09085: Choppy MOH from SIP trunk
Reporter:	Giovanni (mindthegap)	Labels:
Date Opened:	2007-03-23 09:25:14	Date Closed:	2011-06-07 14:07:50
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Resources/res_musiconhold
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	I have a time condition which sends to a queue with a MOH. Now, if I dial the queue from an internal SIP phone, it sounds OK. If I dial in from the VoIP trunk, MOH is choppy. It is not bandwith/provider issue since I tested with an old * machine (1.2) on the same LAN and no issues are there.
Comments:	By: Joshua C. Colp (jcolp) 2007-03-23 10:40:47 sip debug and rtp debug is needed to diagnose this. By: tdavis (tdavis) 2007-05-08 15:14:00 I am experiencing this problem as well.  I am using Asterisk 1.4.4, but I saw the same behavior under 1.4.3 before upgrading.  It is happening with both the default voice mail (the free WAVs provided in the distribution) and when I try to use a sound card's line-in as a source of music. However, it behaves a little different in each case.  The music from WAV files works fine for many minutes (sometimes up to 10), then suddenly drops out completely.  The music from line-in starts off fine, then after a few minutes starts to get choppy.  As minutes pass, the audio gets progressively choppier, and eventually the audio drops out completely. If I take the call off hold then immediately put it back on hold, the music on hold returns to normal, but the afore-mentioned failure eventually repeats. Outgoing calls are to a SIP provider.  We're using the ulaw codec.  I do not have this problem with long calls (tested up to an hour) over the SIP trunk to one of my SIP phones, so the problem seems quite localized to music on hold. Please tell me what precisely you need me to do to give you the debug info you need and I will be happy to provide. By: mhardeman (mhardeman) 2007-05-08 15:41:40 I've seen the described problem in other SIP<->SIP scenarios also using ulaw.  Including bridged calls (non p2p bridged) between two sip phones... rtp flow capture continues normally but one side gets silence (one-way audio).  Only happens on calls that last past a few minutes. By: Konstantin Prokazoff (oryx) 2007-05-09 05:21:28 2 tdavis: are you using zaptel drivers? By: tdavis (tdavis) 2007-05-09 11:15:36 No, no Zaptel drivers.  SIP phones and a SIP provider only. By: tdavis (tdavis) 2007-05-09 11:16:33 I should clarify again that the SIP phones are not a problem here.  It's just music on hold, over the trunk to the SIP provider, that's the problem. By: Giovanni (mindthegap) 2007-05-09 11:34:43 We are in same configuration: no zaptel drivers, only sip phones and sip provider. I read in the internet a similar issue in Trixbox: that issue seems to be that if the sip provider has silence suppression enabled (and our has), moh does not work if silence is detected. Try do do this test: diali in and while listening to MOH speak on the phone. In my case, if I speak, moh gets better. This seems to be related to an issue in sip trunk what relies in receiving packets for sending them out: no received packets (due to silence suppression) no outgoing packets (for moh). This would also explain why, dialing a moh queue from internal sip phones, does not give any problems. Can anybody at digium have a look into this possibile "bug" ? By: Andrey Solovyev (corruptor) 2007-05-09 16:22:51 I confirm for 1.4.4. I have Background before call goes to queue. Background sounds ok but moh from queue is very choppy. I tried with and without ztdummy. Version 1.2 sounds ok. I will try to provide sip and rtp debug. By: Giovanni (mindthegap) 2007-05-12 11:18:00 Maybe I found a solution Try to put internal_timing = yes in the [options] section in asterisk.conf Attention! Read all this thread depending on the 1.4.x version you have: http://forums.digium.com/viewtopic.php?p=50753&sid=521b797880d02619d6091477cd90dd76 By: Joshua C. Colp (jcolp) 2007-06-11 09:57:27 Since this issue now seems to be solved using an alternate timing source I'm closing this out.