MCD Sip MOH issue with Codec

[MitelEngineering]

We have a vMCD running MCD 5.0, which is connected to SIP trunks. It's currently working well, but we have one issue with uncompressed calls and music on hold. Compressed calls with music on hold work fine (we have compression licenses), but as one of the controllers in the cluster is a contact centre, they do not wish to compress calls so would need to be g711. Basically I can see the incoming call from the provider, with the SDP from the mitel offering G711u only. The call is answered and works fine, but if the caller is put on hold the mitel starts to stream RTP at G711a, which the sip provider say is an issue as the call was negotiated as ulaw... I've tried changing the force symmetric codec option in the SIP SDP...but no change. It does look like g711 codecs cannot be filtered on the 3300, as this is their default. So I'm currently out of ideas on this one. It's worth reiterating that MOH works fine on g729, so this looks like a codec issue over an SDP configuration setting, but open to suggestions... Many thanks.

 

[caknfd]

I don'y remember the exact details but had a similar issue and used the option below in the SIP PEER PRIFILE.

Avoid Signaling Hold to the Peer

If this option is enabled, when a user places a call on hold the 3300 ICP suspends the call but does not send a Hold indication to the peer. SIP-SDP renegotiation is performed using "sendrecv" attributes, and services such as Music on Hold are provided by the 3300 ICP itself.

If this option is disabled, when a user places a call on hold the 3300 ICP suspends the call and sends a Hold indication to the peer. SIP-SDP renegotiation is performed using "sendonly" attributes. If the service provider acts upon the Hold indication that it receives from the 3300 ICP, it will suspend the call a second time and be in charge of providing services such as Music on Hold.

Craig

 

[MitelEngineering]

Thanks Craig, this option is required and is already enabled on the peer. Without this the MOH is provided by the SIP provider. The MOH works fine if G729 but not G711.

 

[bobcheese]

i know this is a long shot but, was he MoH source encoded to A Law or U Law? Could it be the file dictating the codec?

 

[danramirez]

Bobcheese, that's a good point to try. Great idea

http://www.hatkana.com

http://www.wtelecom.com

 

[MitelEngineering]

Thanks Bobcheese, that a great idea!! I'll check this out today. I suspect it will be a-law, which could explain the issue. I've noticed from looking at old pcaps that during the interop testing with the SIP provider, they offered a-law in the invite SDP...but in the now 'live' environment, they are only offering u-law. In the test phase, a-law was negotiated and everything worked fine with MOH RTP (even G.711). I have asked the SIP provider to check this out. Thanks again.

 

[bobcheese]

Any joy with this?

 

[MitelEngineering]

This is now resolved... I got the SIP provider to add G.711A to the codec set and the uncompressed music now plays as it should.

Thanks for all the replies.