Hearing Own Music on Hold When Remote Party Places Call on Hold

Asterisk Asterisk SIP
1

In my Asterisk-based telephone system, my own Music on Hold (MOH) is played when the remote party places the call on hold.

Question:

Which file should I modify to change this behavior? Should I make changes in pjsip.conf or extensions.conf, and if so, which specific sections?

I would appreciate any assistance or guidance to resolve this issue.
I have found information related to this issue, but I’m unsure if it’s the correct solution and how to implement it: https://community.freepbx.org/t/hearing-own-music-on-hold-when-call-on-hold-in-foreign-pbx/72417/20

Thank you in advance!

2

The message you are quoting says source code changes would be needed to pass media from an a=sendonly status stream, through, instead of generating AST_CONTROL_HOLD, and the associated internal generation of the hold music by Asterisk. I haven’t heard of anyone submitting such a change, although I have been caught out on other ones.

3

We did actually make a change[1] to add an option to ignore these MOH requests, which is in the latest releases. It can be set on the PJSIP endpoint of the upstream.

[1] res_pjsip - Asterisk Documentation

2 Likes
4

Thank you for your responses on this topic. How can I implement this here?

https://docs.asterisk.org/Asterisk_22_Documentation/API_Documentation/Module_Configuration/res_pjsip/#suppress_moh_on_sendonly

Do I need to do this in the pjsip.conf or in the extensions.conf, and what should I enter? Is that right on pjsip.conf?

suppress_moh_on_sendonly=yes

EDIT: I have now used suppress_moh_on_sendonly=yes in pjsip.conf , but now the other party does not hear my MOH anymore. However, my goal is that the other party hears my MOH, but if the other party puts me on hold in their own queue, I should not hear my MOH but the MOH from the other party instead. Does that means that I have to use “no” instead of “yes” or maybe it’s a problem that I use moh_suggest=MyOwnMOH for the phone endpoint? So maybe it’s moh_passthrough=yes that I want?

So my pjsip.conf looks like this:

[MySIPTrunk]
…
moh_passthrough=yes
…

and

[MyPhoneEndpoint]
…
moh_suggest=MyOwnMOH_2
…

Ok, moh_passthrough=yes doesn’t work, because the callee hears either my MOH or their own provider’s MOH. I’m not sure at this point, but I think I’ve found the problem in my musiconhold.conf :

[default]
mode=files
directory=/etc/asterisk/sounds/MOH/MyOwnMOH_1

[MyOwnMOH]
mode=files
directory=/etc/asterisk/sounds/MOH/MyOwnMOH_2

In pjsip.conf , I use moh_suggest=MyOwnMOH_2 for the phone endpoint, and I think that the provider endpoint, which does not include a moh_suggest , will use the default section from musiconhold.conf and plays MyOwnMOH_2. So, should I remove the default section in musiconhold.conf?

5

If something at the provider puts you on hold, then you shouldn’t even receive a hold request at all. They should just send you audio. If they do send a hold request the option is meant to stop local music on hold from playing, as it can confuse people and cause other issues.

This option should have no effect on them hearing your music on hold.

I’m not sure if you’re going to be able to get the remote side to play their music on hold.

6

That’s not my interpretation of the use of sendonly. I think its use as a trigger for music on hold has been bolted on, by the specifiers, resulting in an ambiguity between literally just meaning they will send media but not accept media, and they will not send or receive, and the downstream may inset MoH.

7

@david551 Yes, it’s a mess.

8

I have two Asterisk systems, each on different servers and with different providers, so I can test this myself. With the option “moh_passthrough=yes,” I hear an unfamiliar MOH. I can’t determine whether it’s coming from the provider of PBX A or PBX B. In any case, I have removed this option from my pjsip.conf, as well as the default context from musiconhold.conf. I’m curious to see if it will happen again when I call the other party, where I heard my own MOH two days ago.

9

Today, I can definitely say that it helped to remove the default context from musiconhold.conf
I just had a call with the same remote party where their MOH was played when they put me on hold. Therefore, it is strongly advised not to use this context default in musiconhold.conf

10

Is the incoming MoH direct media? I’d forgotten that I used that tactic to deal with the destination receiving both a direct media stream and the MoH stream. That was about 10 years ago, so may or may not be necessary with current Asterisks.

11

Do you mean my pjsip config? My setting is direct_media=no

12

But doesn’t removing the default context mean that I would have to set musiconhold class in every occasion in the dialplan by myself?

13

Or on the endpoint.

The alternatives also have to be selectively set on endpoints. Phones don’t generally source MoH, so you do want to a=sendonly from a phone to trigger music on hold.

14

If you delete the default context from musiconhold.conf, you must define a context for each MOH in musiconhold.conf.

Example:

musiconhold.conf:

[Music1]
mode=files
directory=/etc/asterisk/sounds/MOH/Soundfile1

[Music2]
mode=files
directory=/etc/asterisk/sounds/MOH/Soundfile2

pjsip.conf:

[Endpoint1]
moh_suggest=Music1
…

[Endpoint2]
moh_suggest=Music2

And if you need to use MOH in extensions.conf:

[MyContext1]
exten => _X.,1,Answer()
same => n,StartMusicOnHold(Music1)

[MyContext2]
exten => _X.,1,Answer()
same => n,StartMusicOnHold(Music2)
…

I do see error messages in the CLI indicating that the default context for MOH no longer exists, but that is irrelevant for me in this case!

I can only strongly recommend not using a default context in musiconhold.conf. This way, you won’t need any additional parameters that don’t work anyway, because suppress_moh_on_sendonly is not what we need in this scenario. The value no disables MOH entirely, and yes sends the other party the MOH of your provider. Who would want that…

1 Like
15

I thought that was what you were trying to achieve!

16

No, I said that when the other party puts me on hold, I want to hear their MOH, and when I put the other party on hold, they should hear my MOH. However, I had the issue that when the other party put me on hold, I was hearing my own MOH because the default context from my own musiconhold.conf was used. This happens automatically because it is the default context!

17

Thank you for pointing out @DHT768

I am having this “hearing own moh” issue from time to time already since asterisk 1.2
I never digged deeper into that as I always thought it could be some kind of codec problem, at least another forum gave me that hint one time. Also it was always quite difficult for me to reproduce the issue as people often could not remember with whom it happened and I didn’t want to bother other people with test calls.

However, the last years I managed to make my users aware that this can happen once in a while and that it’s not harmful :joy:
So I am not sure if I will change something, but still good to know, thank you.

18

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.