Hearing own Music on hold when call on hold in foreign pbx

On some outbound calls when getting put on hold by the “callee” we are hearing our own MOH.

Is there a way to disable the re-invite? I believe this is what is causing our MOH to start playing.

Somewhere in the dusty corner of my memory I’ve solved this before. Try disabling ‘trust rpid’ for the trunk maybe?

In the pjsip_endpoints.include ? Or are you meaning in a different location?

I found the settings in the trunk-

Trust RPID/PAI is disabled
SendRPID/PAI is also disabled.

Please let us know if you fix this. I have a similar issue on an inter-family IAX trunk. Thanks!!

Long time ago I asked for this problem, too (Nov 2016) - but no solution. I would be interested, too.

I’m curious, what do you want to hear when you are put on hold?

You can disable MOH on the outbound route and then you should not hear it. Neither will the remote party if you put them on hold.

My own opinion is that the feature is working as designed… the music is supposed to let you know the other person put you on hold.

But with their playlist Bill. Not mine. That’s what makes it weird. Not major but…

2 Likes

It depends on your provider and the remote party. This happens a lot with cellphones.

What happens is, that the remote party sends a re-invite and your provider passed it through to your PBX.

See example:

1 is when the remote party sent a re-invite with a=sendonly, to which the PBX replied 200 OK with a=recvonly, So the PBX will start playing MOH (or ringing, depending what you configured).

2 is when the remote party sent a re-invite with a=sendrecv to which the PBX replied 200 OK with a=sendrecv, the PBX stopped the MOH.

I think the only way to stop this is to disable reinvites on the trunk level, but I am not sure if that would be a good idea…

1 Like

If you are hearing your own MOH then they aren’t playing anything. They’re sending SIP signaling to indicate hold. So you’d either hear your own MOH or nothing.

Here’s an example on our IAX intra-network.

If I call my brother via extension, A to B and he puts me on hold, I hear my onhold music. If he calls me, B to A and he puts me on hold, I hear his music on hold. Both are different playlists.
If we do the same calling, but I put him on hold, he’ll hear my music on hold in one direction and his in another.
Again, not a major issue by any means but would love to understand it and solve it.

John, I don’t know about IAX but with PJSIP it should not pass hold indications across the trunk unless you have moh_passthrough enabled. (@jcolp hard facts reference: https://community.asterisk.org/t/hold-resume-asterisk-did-not-forward-the-call-hold-reinvite/77311/3)

1 Like

I had this situation yesterday exactly as you described it:
ReInvite w/ sendonly (and new codec in my case) with the 200 OK answer of asterisk with recvonly.
Now, own MOH starts up playing.

Why does Asterisk / FreePBX do that? The B-party told sendonly - that means, data has to be received and there mustn’t be added own MOH - even if the sender would send silence or nothing!

Disabling ReInvite would be a bad idea, because ReInvites are often necessary among others for session handling - if you like to have dropped calls after n minutes - go and disable ReInvites.

SIP doesn’t have a mechanism exactly to say “place this call on hold” as users know it. There’s various methods in the SDP that it is done: a connection address of “0.0.0.0” from old times, an audio stream set to sendonly, or an audio stream set to inactive. To that end for almost every case a user expects when they do this that the PBX places the call on hold and produces hold music - so we do. This is because it generally only comes from phones connected to the system itself. Upstreams (be it ITSPs or PBXes) generally take care of it themselves and don’t propagate it down. There’s no ability currently to change this behavior, as noone has done any work to add such configurability.

1 Like

Ok - the problem is, Asterisk (pjsip?) can’t (fully) distinguish between a “trunk” and an “extension” connection. But that’s really a big difference in handling (not only at this point).

Now I understand, why it is often emphasized, that Asterisk only knows extensions and that there exist no trunks at all. A “trunk” at the moment seems to me to be just a by-product, a “misused” extension, which is logically (or virtually) defined by FreePBX, to connect the PBX to the PSTN.

The only solution seems to be, to disable MOH at all.

SIP itself doesn’t have the concept of trunks, or extensions, or phones, or any of that. Asterisk itself also has no concept of extensions or trunks - an endpoint is an endpoint. There really is no difference except in how it is configured/used.

1 Like

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

Quick follow up here.

Does anyone know if anything new was implemented in Asterisk over the last 2 years that touches on this?

I see that there is moh_passthrough which is set to false on the endpoint, but Asterisk still starts MOH on the channel.

Thanks

The moh_passthrough option has nothing to do with accepting, it’s unrelated.

There is a HOLD_INTERCEPT dialplan function[1] which intercepts hold requests from a device.

[1] Asterisk 20 Function_HOLD_INTERCEPT - Asterisk Project - Asterisk Project Wiki

1 Like