Issue with joining conference (MCA) while calling in via SIP trunk

[petr.necas]

Hi all, we have an issue with MCA while somebody needs to call into a conference via DID number (via SIP trunk) and is asked for the access code to join the conference "Enter an access code and then press pound". When the external caller calls in via a SIP trunk and enters the access code and waits (does not enter # at the end) the caller is connected, but when the caller presses # after he enters the access code the caller is not connected to conference but hears a busy tone.

I investigated it a little bit and it seems the SIP trunk is set to send DTMF codes using RFC 2833. I believe if I call the SIP trunk provider and ask them to set the SIP trunk to use inbound DTMF codes it will fix the problem, but does anybody know why would pressing # be causing these problems? Is RFC 2833 fully supported by MCA?

We use ICP 3300 MCD 5.0 + MAS 4.0 (MCA V4.0.2.14).

[martyn]

If you can find a quiet time (eg after hours) to test, I would set up a TCPdump from the maintenance command and then ring in and reproduce the problem. Turn the tcpdump off, and then you should be able to analyse it to see what is happening.

You should also be able to run a tcpdump from the MCA box, and compare to see what the MCD is receiving vs what is being passed to the MCA server.

I only suggest doing this out of hours so that you only have a minimal amount of calls on the system, which makes it easier to track in wire shark when looking at the output.

[petr.necas]

I analyzed the SIP traffic and found out that DTMF code # was not simply sent to us over the SIP trunk on incoming calls, because the # was used for some call redirection feature ( I wrongly thought that I was getting busy tone, but it was a dial tone) somewhere on the way between the mobile service provider and our SIP trunk provider. I contacted the SIP trunk provider, finally they understood the issue and realized the issue was somewhere between the O2 Telefonica and them. They are now working on it.

[martyn]

Good to hear that you managed to track it down. It's always handy to be able to provide the tcpdump to a provider and show them what is happening, as usually then they will actually listen to what your saying, not just dismiss it!

[petr.necas]

Yep, they were trying to convince me that the problem is on my side, it took me several calls and several e-mails with wireshark files until they changed their mind :-)

[LoopyLou]

Not surprising.