MOH Gamma SIP Trunks

[floppy1]

3300 VMCD on 5.0 SP1

Hi

We have only SIP Trunks from Gamma. MOH cannot be heard on either incoming or outgoing calls. Works ok internally. SIP is set up as per Mitel knowledge base doc “configure Gamma SIP on 4.2 " as this is the most recent doc I can find. The exception is that we have set avoid signalling hold to peer to yes.

COS options for SIP Trunks and users set to use local music source and hold on transfer. I have seen the other posts relating to this issue but have not really helped to address our issue.

Got this back from Gamma. Any thoughts ? I don’t think that we can filter G711 a

Upon investigation this issue further we have spotted that when placing the call on hold you are changing the codec from U-Law to A-Law.

As this Endpoint is configured for U-Law we basically ignore the media you send to us, you will need to ensure when placing the call on hold you set this to U-Law or transcode the A-law before sending it to us.

Apologies for the delay in getting back to you, after looking into the issue in detail we missed the most basic part of the problem in the codec switch

 

[IrwinMFletcher]

Maybe I missed the context switch in the wording, but are you saying that when you have a call up to Gamma, and you put them on hold, the music source from the MCD streams A-law to Gamma and they are saying that they don't support it?

If so, then my first take is you must be in the UK to have your music as A-law, correct?

Do you see a renegotiation of the media when you press hold (SIP re-invite)? If so, what does it say?

If you are signalling the change in codec, and they OK it, then it's their problem.

 

[floppy1]

Hi Irwin

Thanks for the quick reply. Yes we are in the UK. It seems what Gamma are saying is that when we place a call on hold the Mitel is changing the codec from G711 u law to G711 a law and as there endpoint is configured for u law that the a law is ignored ?

Not sure how to ensure that when we place a call on hold that only u law is used or how to transcode the A-law before sending as Gamma have suggested.

We have many 3300's running MCD 5.0 using Gamma SIP Trunks and we have no issues with MOH not working. The only difference is that this one is VMCD

 

[IrwinMFletcher]

If the MCD is changing the streaming codec mid-call without notifying Gamma through a SIP message, then yes, MCD is in the wrong. But I doubt this is what is happening. A tcpdump/tcpdump of the call would verify the behaviour.

Unless, are you sure they said that the RTP codec had changed to A-law, or the underlying data was A-law? Hmmm, no, can't be that, I don't see them detecting that, it would work, just sound crappy.

The vMCD difference could be the source of the problem since it uses the Media Server to supply the MOH versus the standard MOH source on the physical (CX, MXe, etc) boxes.

I still think it's a Gamma issue, depending on what they respond to the re-invite with. Any chance you can get a trace of the call? (SIP messages and streaming)

 

[floppy1]

Hi Irwin

I will ask our network guy to get some traces and post them up. I have turned on TCPDUMP in maint but not sure how to retrieve the files fro the VM directory >

 

[IrwinMFletcher]

Just log into the machine and enter:

tcpdump -i any -s 0 -w name_of_capture_file.cap

make the call, then ctrl-C when you're done. Ftp the name_of_capture_file.cap off the machine.