Summary:	ASTERISK-00376: MusicOnHold stops when no RTP is going from remote party
Reporter:	Paul Cadach (pcadach)	Labels:
Date Opened:	2003-10-12 09:02:19	Date Closed:	2004-09-25 02:49:15
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) asterisk-0.5.0-nonstop.diff
Description:	OpenPhone (from www.openh323.org) and IAXComm have silence detection feature when they just eliminates transmitting RTP packets to Asterisk. When you (must) listen music-on-hold and have silence detection enabled MOH will be stopped when RTP transmission stops due to silence.
Comments:	By: Brian West (bkw918) 2003-10-12 15:29:48 silence detection ... didnt think that was something * supported. By: Paul Cadach (pcadach) 2003-10-13 05:10:21 Silence detection is supported by listed applications, not by Asterisk. Because MOH works as "tone" generator, it works when Asterisk receives any sort of RTP packets. When RTP transmission on client is disabled (due to silence), Asterisk stops MOH as it's not gets RTPs from client. I think it is not so good. By: Mark Spencer (markster) 2003-10-13 13:00:19 This really isn't a bug because we time the music or other "generators" based on received signal.  it might be possible (if a zaptel interface is available) to use zap timing for it. By: Paul Cadach (pcadach) 2003-10-14 05:27:39 ztdummy doesn't solves situation. May be for zap's interfaces all will work but for VoIP connections zaptel isn't available. I think generators (and MOH) must work independedly on which channel it goes (zaptel or VoIP). By: Mark Spencer (markster) 2003-10-14 06:35:35 ztdummy would solve it if it were tied to zap.  However, if we make generators run off zap instead of off receive traffic then the audio will no longer be synchronized to their own timing but will be synchronous only to our own. By: Mark Spencer (markster) 2003-10-14 06:36:40 if you want, you can place this as a feature request ("Run generators from zap when available instead of depending on received audio") By: Paul Cadach (pcadach) 2003-11-02 13:41:20.000-0600 Does ths patch looks like a solution? Still not clean, but mostly works (and must work when zaptel interface available). Also, includes more common scheduling based on ast_waitfor_nandfds() function (STILL UNCLEAN!!! Works to clean up) - I think it's more "legal" way to make scheduling work at channel's waits instead of placing schedulers at many pieces of code (at every channel ;-)' )... edited on: 11-02-03 13:39 By: Paul Cadach (pcadach) 2003-11-23 02:42:55.000-0600 Reminder sent to bkw918 Brian! This problem is still not solved - when you don't have incoming RTP traffic (when silence suppression turned on), Asterisk will stop transmitting any generator data to that channel because it sends only when some voice packet arrives from remote party. Silence suppression (by stopping RTP traffic) is commonly used feature and sometimes user cannot change it due to different reasons (for example, hardware doesn't support disabling silence suppression, or PSTN gateway located and maintained by other department/company and you cannot ask about disabling silence suppression, or PSTN gateway located too far from * and uses global network to connect to it, so silence suppression is good reason to save traffic and channel bandwidth usage). Attached patch (now its slightly modified to be more 'clean') used for me for about 1 or 2 monthes - works good (without any zaptel interface). Diffirent timing looks like slightly 'choppy' sound, but I think this is better than nothing. Also, if you have zaptel interface (or at least ztdummy) generators will be synchronized to it. Also, bug ASTERISK-459 relies on this issue too - ADSI programming interface is also realized as generator and depends on silence suppression (at least at Dlink DG104 it cannot be turned off). An idea lies in background of that patch - do generators scheduled as it works for playback/background tasks. But, to not modify sources too much and not to be dependent on zaptel interfaces, a place commonly used for any sort of waitings are found - this is the ast_waitfor_nandfds() function, which called for waiting events from channel(s). So, it you don't have zaptel interface, ast_waitfor_nandfds() is the best place to call scheduled tasks (and generators, of course). If someone interested in - I'll reopen bug and attach latest patch.