Solved MOH not working for remote devices

[smpltech]

Deploying a new system, V16 in the cloud (no SBC), Yealink T46S, latest firmware 66.85.0.5. I would expect MOH to work at all times, any time a transfer or call is placed on hold, but it does not. Just pressing the hold button, no music is played, transferring, sometimes music is played, when switching back and forth between 2 calls, just silence... When I resume a held call, the music plays for 1 second before connecting me back. Parking a call MOH is heard. I get the feeling we are hitting some sort of NAT RTP issue. I tested from 3cx softphone and had same experience.

The firewall is pfsense, I have followed guides to set Conservative Firewall Optimization, and set Static port on Outbound UDP traffic to my pbx. I also toggled "PBX Delivers Audio" both ways with no change.

 

[cobaltit]

Change that no SBC to a yes SBC

 

[smpltech]

really ... xyz cloud solution does this without an sbc

 

[cobaltit]

Well you don't say whether internal to internal has MOH but the other option could be from not using a certified SIP trunking provider if you are talking about external callers not hearing it. You'd have to play with trunk options then.

 

[cobaltit]

really ... xyz cloud solution does this without an sbc

Please name one (here's a hint, they all do. They just don't have the SBC on the client side)

As you specifically put no SBC clearly you know that it exists (and does so for a reason) as 3CX recommends a SBC for multiple phones or specific port forwarding and unique ports for each phone. So setting up an unsupported configuration and then asking for support is a bit silly.

 

[smpltech]

Naming some- I have several PBX on EC2, GCP, and dozens of pbx with offsite extensions, any asterisk flavor, Wave, Freeswitch, Ring Central ... the whole point of voip is to "break free", I get the "supported provider" thing *kind of*, but that is a shot in the dark as far as affecting MOH, it dont make sense when the media is held at the pbx (park) it *can* provide moh, but held at the endpoint it cannot, the trunk is functioning the same in both situations there.

Station to station on the same LAN MOH works, but when an extenion is talking to a PSTN caller it does not. Resuming a held call from an outside caller gives them 1 second of moh before reconnecting the call. I dont think this is trunk related since it can almost do it.

Yes my old school local cable operator puts an Edgemark B2BUA and probably an SBC onsite to hook up to their Broadworks switch- because they went to voip school in 2000, and someone told them VOIP cant transverse NAT, things have changed - SIP re-invites allow RTP to stay at the PBX when it doesnt need to be onsite ie call on hold. This kind of complexity is what drives their costs up and makes them loose to dozens of cloud voip providers.

For giggles I deployed an Asterisk system and it works flawless at the same site, same trunk. I could try Vitelity also, but I am pretty sure the trunk wont fix the pbx.

I am hoping the below is true and I dont need any proprietary hardware to make this work-

 

[cobaltit]

So you are kinda of muddying the waters so lets clear up a few points. First point, cloud solution vs putting something in the cloud. All native cloud phone systems (Ring Central, 8x8, etc) use a SBC. While not only used for NAT traversal it's an important piece. And pretty much any provider that does bundled data/voice use some sort of SBC or edge device. Old school or not, the point is it works and is what is supported. Second, open standards and vendor supported are two different things. You are not required to use a SBC, it's just recommended. If one prefers to go against recommendations and bang their head against the wall, by all means go ahead.

Now for your particular issue, if local MOH works then it's likely an issue with your trunk and the SBC recommendation isn't going to solve that. You haven't named the provider and leads me to believe it's not a supported provider. As such, you are subject to trial an error with the trunk settings. This again, when used with 3CX supported trunking providers works as expected. All the listed trunk providers have templates already configured and tested to work in the various scenarios covered in the SIP trunk test plan, and one of those scenarios is the MoH (3.4 and 3.5):

https://www.3cx.com/docs/sip-trunk-test-plan/

That doesn't mean that it won't work with your trunk, nor does it mean 3CX isn't open-standards or standards compliant. It simply there is no tested template included in 3CX and that they will not provide support when things like this don't work. As it seems you have experience in VoIP it shouldn't be too much trouble to figure out which knobs in the trunk settings need to be adjusted to get your MoH issues resolved.

 

[smpltech]

Well you got me there, MOH works fine on Vitelity. I think something is wonky with reinvites, I noticed the default Vitelity config has it off. So ... for giggles I disabled reinvites on this trunk (which is enabled on Asterisk system and works)...now MOH works properly.

 

[JohnS_3CX]

Well you got me there, MOH works fine on Vitelity. I think something is wonky with reinvites, I noticed the default Vitelity config has it off. So ... for giggles I disabled reinvites on this trunk (which is enabled on Asterisk system and works)...now MOH works properly.

Hi @smpltech

There's a few similar posts around the forum, you will notice that's the usual culprit.

Not all providers will handle it right so MOH or IVRs may be affected.

Best leave it off by default on trunks