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

Tags: #<Tag:0x00007f24c5a18060> #<Tag:0x00007f24c5a1fdb0> #<Tag:0x00007f24c5a1f9c8>

(Katie) #1

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.

(Lorne Gaetz) #2

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

(Katie) #3

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

(Katie) #4

I found the settings in the trunk-

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

(John Jarrett) #5

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

(Dirk2358) #6

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

(Simon Telephonics) #7

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.

(John Jarrett) #8

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

(Itzik) #9

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…

(Simon Telephonics) #10

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.

(John Jarrett) #11

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.

(Simon Telephonics) #12

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)

(Dirk2358) #13

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.

(Joshua C. Colp) #14

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 “” 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.

(Dirk2358) #15

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.

(Joshua C. Colp) #16

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.

(system) closed #17

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