I have something strange that happens sometimes, but not every time. When a cell phone caller places me on hold while they take another call with their call-waiting, I sometimes have my own hold music that starts playing in my ear. It even has my marketing blips that come on every now and then so there’s no question that it’s coming from my system.
It only seems to happen randomly, less than 10% of the time I’d guess. I’ve quizzed a few of the callers, one in particular as he’s also a good friend. He’s doing nothing differently in those times when I get my hold music and those times when I just get dead air.
Is this a setting somewhere? A glitch? He’s on a priority inbound route so his calls come directly to my extension. He’s not going into an IVR or pressing any keys to get to my extension. And again, it only happens once in a while.
How is the cellular network connected to the PABX. You will get music on hold if the trunk receives a hold indication. In the case of SIP, that is a Re-INVITE, with a=sendonly (recvonly, etc.), or with c=0.0.0.0. That will depend on what the cellular network sends to the provider, and how the provider deals with it.
Are you setting Music on Hold in the inbound route? When that is set to something it triggers a Gosub that sets the MoH to that channel with CHANNEL(musicclass)=myholdmusic so now when that channel sees that it is on hold, it will play the assigned music on hold. It doesn’t matter which side put the call on hold, when it is in a hold state the set MoH is used on by the channel.
Hi Tom,
Yes I do have Music on Hold set for that inbound route. It’s been that way for many years. This situation with my own hold music playing when he switches to call waiting however is something that’s only happened in about the past six months or so, and only once in a while.
I talk to this guy every day, sometimes a few times a day, and he has to switch to his call waiting almost every day and sometimes multiple times during our conversation (he’s a business owner too). The MOH thing is just so random and rare. It’s not a common event.
Will the debug show something from the past? In other words, since it seldom happens, how am I supposed to predict when it’s going to happen so I can start the logger? If I start it after it happens haven’t I already missed it?
If you can show something from the logs that would be fine too. Since this is your friend, if they put you on hold and you hear your own music you could get into the system and wait…then have them try to hold you again to capture it.
I can get past info from the logs? In other words the last call that came in had this happen. I can pull log files that show it even though I hadn’t turned logging on in the cli? Or did I misunderstand?
It happens so rarely I don’t know how long it would be before I can capture it. And given how random it is I can’t even say it would happen a second time on the same phone call.
Asterisk’s PJSIP has an endpoint setting moh_passthrough . When false (default), if a hold indication (a=sendonly) is received, it plays music on hold to the “held” side. Since you are getting a SIP hold indication from your trunk, Asterisk is doing the right thing–it’s playing the configured music on hold to the “held” party (you).
Changing the setting of moh_passthrough to true would stop the playing of music and instead relay the hold indication to the “held” channel.
However I don’t think setting moh_passthrough=true on the trunk endpoint will work, because then your callers would not hear MOH when you put them on hold.
In short, I think you will have to accept this behavior.
suppress_moh_on_sendonly=yes might do the trick on the trunk endpoint.
Normally, when one party in a call sends Asterisk an SDP with a “sendonly” or “inactive” attribute it means “hold” and causes Asterisk to start playing MOH back to the other party.
This can be problematic if it happens at certain times, such as in a 183 Progress message, because the MOH will replace any early media you may be playing to the calling party. If you set this option to “yes” on an endpoint and the endpoint receives an SDP with “sendonly” or “inactive”, Asterisk will NOT play MOH back to the other party.
NOTE: This doesn’t just apply to 183 responses. MOH will be suppressed when the attribute appears in any SDP received including INVITEs, re-INVITES, and other responses. (default: no)
Do be aware the option is somewhat new, so it’s only available in somewhat recent versions[1]. (The docs site now shows the version when stuff was added)
Just to clarify, calls going out that same route don’t always play your MoH? If someone makes an outbound call and the callee places them on hold…they hear the callee’s music?
There aren’t many of us here any more as the business is dying… but normally if a callee places us on hold, we hear THEIR hold music, not ours. If we place them on hold then they hear OUR hold music.
But in the case of the cell phone if they put us on hold (ie switch to another incoming call on their cell phone) we hear our own hold music. And it only happens once in a while, not every time.
I’d suggest the difference is that the cell phone is sending a CLEAR indication when it goes on hold, whereas, when the call ends at PABX, no signalling event is generated (particularly true for analogue lines, and simple digital lines emulating analogue signalling).
Many ISDN to SIP gateways interpret CLEAR as hold, and will send a=sendonly. The mobile network will not be sending media, in this state.
I’d expect the mobile network to either re-use, or temporarily discard, the speech channel, on the air interface.