Solved Hearing our own MoH

[deathonredbull]

We have some Music on Hold files set up, which work as expect when people call us, inbound. What's strange is, our users are saying that when they call out, and the external organisation puts them on hold, they're hearing our hold music, not the external organisation's.

This can't be right, can it? I can't figure out what could be causing it. Does anyone have any suggestions?

 

[Evolute IT]

Your trunk probably has "Support Re-Invite" enabled, which is rarely enabled and supported but it can.

 

[deathonredbull]

Your trunk probably has "Support Re-Invite" enabled, which is rarely enabled and supported but it can.

Hi - thanks for that. I just checked, and 'Support Reinvite' isn't enabled on any of our SIP trunks. For all users it seems to be enabled by default, but I'm guessing this will be doing nothing, since it's not enabled on the trunk.
Just as a weird test, we disabled it for a given user (just to make sure), and made a call to another organisation we know well, and asked them to put us on hold - but this of course made no difference - still got our own MoH.
Do you have any further thoughts or suggestions?

 

[Evolute IT]

Re-Invite and Replaces are usually the two options that can cause this. Otherwise, no ideas.

 

[deathonredbull]

Re-Invite and Replaces are usually the two options that can cause this. Otherwise, no ideas.

Yep, Replaces is off for all trunks too, so that eliminates that. Thanks for the suggestions, anyway.

 

[SweetAction]

I'd recommend a packet capture and see the call flow / what's triggering what. Or at the very least it could confirm that Re-Invites / Replaces are actually not being sent.

 

[deathonredbull]

I'd recommend a packet capture and see the call flow / what's triggering what. Or at the very least it could confirm that Re-Invites / Replaces are actually not being sent.

Thanks for the suggestion. I found this thread from 2016 that seems to indicate that the problem is indeed related to 'Re-invite' being on, but it seems that it can happen if it's on at the other organisation's end: https://www.3cx.com/community/threa...-hold-when-call-on-hold-in-foreign-pbx.57705/
From what's being said in that thread, it seems that 3CX (unlike other PBXs) can't be configured to filter/ignore incoming re-invites. So it looks like this is the issue.

 

[cobaltit]

I'm guessing this is using an unsupported SIP trunk? This is one of the test parameters when going through interop testing.

 

[deathonredbull]

I'm guessing this is using an unsupported SIP trunk? This is one of the test parameters when going through interop testing.

It is, technically, although the whole shebang was handed to us as is, by a 3rd party IT company - we didn't set it up, SIP trunks, or 3CX.

I spoke to tech support at the the SIP provider (VoIP Unlimited, in the UK), and they ran a trace on an affected call. They had this to say (I'd directed them to one of the other threads above to take a look):

"I can see that the destination is sending a re-invite with the sendonly media attribute in the SDP. Subsequently the 3cx sends a 200OK with recvonly as I would expect.

All of the messaging appears to be present and correct according to RFC, the re-invite is passed on to the 3cx and it's then up to the 3cx what it does with it.

The forum post, however, mentions that the problem occurs when recvonly is in the re-invite, which is not the case here and would certainly be an issue with the destination phone system.

I presume that the 3cx has the latest and greatest version installed etc? If you have the 'Support Re-invites' option enabled, does that make a difference?

The only other thing I can think to check is to see if the PBX recieving any RTP after the re-invite, is it possible to get a trace from the PBX of an affected call?"

We are on the latest version of 3CX, btw.

 

[cloidhamer]

I would test another SIP provider. Pick one from the supported list and see if it still occurs. There are many providers that are simple pay as you go so not much invested. Also I have multiple providers in case one is out for some reason.