Summary:	ASTERISK-15691: Asterisk 1.4.29 musiconhold of remote party doesnt work
Reporter:	Bastian Marmetschke (basty)	Labels:
Date Opened:	2010-02-25 04:36:28.000-0600	Date Closed:	2011-06-07 14:00:49
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Resources/res_musiconhold
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	"A" calls an external number (no asterisk pbx), "B" answers the call and puts "A" on hold. While "A" is on hold, his own asterisk moh is playing instead of the moh of the external pbx. ****** ADDITIONAL INFORMATION ****** If you remove everything out of the musiconhold.conf (so you dont have any musiconhold setup) - and "A" is calling out to "B" (external pbx) while "B" puts "A" on hold. Asterisk still requests the local moh. But you finally will hear the "right" moh of "B".
Comments:	By: Leif Madsen (lmadsen) 2010-02-25 09:58:26.000-0600 Any chance you could test this on the latest 1.4 branch? This sounds like something that may have been resolved recently. svn co http://svn.asterisk.org/svn/asterisk/branches/1.4 By: Bastian Marmetschke (basty) 2010-02-25 10:05:33.000-0600 Problem is that this one is running on a pbx with 130+ phones. Will it be save to test that in this situation ? ;-) Otherwise I will try to setup a small test system and let you know. By: David Woolley (davidw) 2010-02-26 06:03:22.000-0600 This has been discussed a bit on the asterisk support forum. http://forums.digium.com/viewtopic.php?f=1&t=73220&sid=231a59afe4981784353d0b661ce6b195 The problem he has is that he is unable to disable Asterisk's response to DAHDI hold events (he has SIP downstream). If this had been pure SIP, the only resolution would be a feature request, as the basic problem is that phones use SDP a=sendonly to request a hold, even though they are really doing the equivalent of a=inactive, and not sending any MOH or hold tone.  Some PABXes (Sopho is an example) won't actually recognize a hold for a=inactive, when going they are at the receiving end. Given that Asterisk probably gets more hold indications from phones than over a trunk (especially as it fails to set a=sendonly when it sources MOH, so Asterisk to Asterisk SIP trunks will never get a hold indication) and distinguishing between phones and trunks would be a feature request, sourcing MOH when it gets an inbound SIP hold is probably the only reasonable thing it can do at the moment. As this case actually applies to DAHDI receiving a hold indication, with SIP receiving MOH, I'm not sure whether or not this argument applies in this particular case. Incidentally, in the pure SIP to SIP case, this is related to ASTERISK-15258, where the existence of a re-invited upstream party results in the downstream party getting both sets of MOH thrown at them. By: David Woolley (davidw) 2010-02-26 06:13:30.000-0600 Actually, I think the argument does apply to DAHDI to SIP, as this issue isn't really to do with res_musiconhold.  The underlying problem is that Asterisk can only signal HOLD and UNHOLD events between the source and destination channel, so when chan_sip receives HOLD, it doesn't know whether it has come from a phone, which won't be providing any MOH, or from a PABX, which might.  The only way to stop it trying to source MOH, without a new features, is for the upstream channel not to generate AST_CONTROL_HOLD. By: Salim Chujfi (schujfi) 2010-02-26 07:33:57.000-0600 Having exactly the same issue even in 1.4.26.1. A (SIP Phone) B (Landline) By: Bastian Marmetschke (basty) 2010-03-01 08:29:43.000-0600 So - what else could I do to get that one solved ? Thanks much! By: subeclipse (subeclipse) 2010-03-02 09:36:55.000-0600 I tested this on my 1.4.22.2 server, and I *thought* all was well until I re-read the original post and saw that you stated phone B is not an Asterisk PBX. The only B phones I have access to for testing are other Asterisk PBXs or my cell phone, (which does not have moh). I'm guessing the Asterisk to Asterisk calls are not an issue, because my test worked where phone A was 1.4.29.1 and phone B was 1.4.22.2. If someone can provide me with a "B" phone to call, I can confirm or deny that the problem exists in 1.4.22.2 By: Bastian Marmetschke (basty) 2010-03-04 09:38:51.000-0600 Hi, thanks for testing. The weirdo thing is, that when we call out of our asterisk 1.4.29 with dahdi (pri) to a external asterisk 1.2.X on misdn - the moh works fine also. As soon as I try to call my mobile and put the call on hold - it doesnt (it plays my own - out of asterisk moh). By: Bastian Marmetschke (basty) 2010-03-29 07:53:44 Is there anything else I could do - to get that "problem" solved ? Thanks! By: benstook (benstook) 2010-04-30 02:53:30 We have the same fault on 1.4.25.1. Person A (A Snom IP phone with a SIP connection to Asterisk) calls Person B, Person B puts Person A on hold and Person A hears the on hold music of their local PBX. I have noticed that this only seems to happen on phone systems that have ISDN. A POTS line doesn't do this. We have some phone systems using an Epygi ISDN to SIP gateway and these don't do it either. My guess is that the ISDN at Person B's end is signalling to say the call is on hold and then Asterisk decides to play the local hold music. I've tested this on my mobile, when Person B puts me on hold the handset comes up and says "On hold" so there must be some signalling there in regards to placing a caller on hold. On my mobile I can hear the on hold music so it isn't a fault with the Person B's PBX. I control both PBXs, in the testing it was the Asterisk with an Alcatel OmniPCX. By: David Woolley (davidw) 2010-04-30 05:59:41 I believe this is a feature request, not a bug. I think any change here is dependent on a new feature to properly distinguish between extensions and trunks, as extensions, particularly SIP ones, going on hold do require that Asterisk generate MOH. Also it relates to the handling of AST_CONTROL_HOLD, and maybe to the specific handling of that in chan_sip.  It is not really related to Resources/res_musiconhold. By: Leif Madsen (lmadsen) 2010-04-30 13:55:44 I tend to agree with davidw here and am going to close this issue.