Summary:	ASTERISK-08478: MusicOnHold application drops call after exactly one minute
Reporter:	Peter Zieba (pzieba)	Labels:
Date Opened:	2007-01-03 22:36:25.000-0600	Date Closed:	2011-06-07 14:07:45
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Resources/res_musiconhold
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	extensions.conf: 6778 => MusicOnHold(default); in dialplan. musiconhold.conf [default] mode=files directory=/var/lib/asterisk/moh random=yes Calling 6778 results in exactly one minute of smooth on-hold music listening. Files were transcoded from mp3 into native format Problem was not present in Asterisk 1.2.10 Not sure if this is affecting anything else other than just the MusicOnHold() application. ****** ADDITIONAL INFORMATION ****** Polycom IP430 phones. Poweredge 2850 2.8GHz 2GB RAM
Comments:	By: Russell Bryant (russell) 2007-01-04 00:37:05.000-0600 Just to satisfy my curiosity, could you modify your extension to include an explicit Answer? exten => 6778,1,Answer exten => 6778,2,MusicOnHold(default) My initial guess here is that since the call is not actually ever answered, the phone never starts sending RTP to Asterisk.  Then, when Asterisk doesn't see RTP for a minute, it is determining that the peer is gone, since Asterisk never specifically said not to send RTP. Anyway, I'm not a chan_sip expert ... :) By: Peter Zieba (pzieba) 2007-01-04 14:27:26.000-0600 Thanks Russell! Answering the call before playing onhold music solves the issue. In fact, there is a call timer that is not present on the screen of the Polycom phone without doing an "Answer" first. I wonder if this could be causing other potentially evil things to happen in my dialplan. By: Joshua C. Colp (jcolp) 2007-01-04 15:03:26.000-0600 I think Russell was talking about chan_sip's RTP timeout but I believe the Polycom also has a timeout setting that if a call does not receive the up state within a certain amount of time it cancels. By: Serge Vecher (serge-v) 2007-01-05 08:06:51.000-0600 ok, thanks for answering. Closing the report as this is a configuration issue.