Inbound DTMF Detection Issue

[newtomitel]

Hi All

I am not a Mitel guy but need assistance on the below issue.

Here is a case,

we have a client with Mitel 3300 ICP. When ever some dial in from outside from tradistional PSTN phone auto attendant works fine. User can get all the option and user can select number based on the option and call can be completed.

But if the out side user dial from his IP Phone (Supported by SIP Provider) he can not choose option. Means DTMF won't work. But if same user dial to other company AA it works.

Can some advice is there any setting on Mitel side which can accomodate inbound dtmf for calls originated from IP or SIP provider.

Thanks

[ralph]

What device are you dialing into?
Embedded VM?
NuPoint?
6510?
Something Else?

How are the trunks coming in?  SIP?  PRI?  POTS?

What type of SIP phone is being used?  Softphone?  Mitel Phone?  Third Party?

Ralph

[newtomitel]

Thanks Ralph

I just confirmed that they its terminated on Nupoint.

And Trunks are terminated as PRI.


And user from outside dial from Cisco Call Manager from where the call is being routed SIP .

Cisco IP Phone---->Cisco Call Manager---->Sip Server (Provider)----->PSTN---->PRI---->Mitel

[Chakara]

  As a Cisco guy as well I ran into something similar.  We installed a Cisco IP phone system wtih an analog conference phone.  When that analog phone would call a particular conference bridge service the DTMF was unreliable at best.  Seemed to be sending double digits but not 100% on that.  The trunks on the call manager were PRI.

  Much troubleshooting, debugs, etc later - we ended up giving them an IP conference phone.  Solved the issue.  Meaning whatever the problem was it was somewhere in the TDM to TDM bus.  Perhaps Cisco was doing TDM - IP - TDM and it was just too much.  Whatever it was, we were just happy to have the issue resolved.

  Not exactly what you are asking, but I learned a lot in troubleshooting this from the Cisco side and there is a lot more to it that appears on the surface!

  In your case, if nobody else reports the problem and uses the attendant fine I would push it back to the source system as the problem.  If it was a VERY important client of mine I might consider giving them a special DID that routes the call right where they need to go.  You could also try setting up an attendant on the embedded VM and see if the issue follows.

-Chak


 

[newtomitel]

Thanks for reply

I just want to resolve the issue. if dial as below it work fine..

Cisco IP Phone---->Cisco Call Manager---->Sip Server (Provider)----->PSTN---->PRI---->Any Other PBX
Cisco IP Phone---->Cisco Call Manager---->Sip Server (Provider)----->PSTN---->Sip Server---->Any Other PBX

Cisco IP Phone---->Cisco Call Manager---->Sip Server (Provider)----->PSTN---->Sip Server---->Cisco Contact Center
Cisco IP Phone---->Cisco Call Manager---->Sip Server (Provider)----->PSTN---->PRI---->Cisco Contact Center

But only it wont work as below ..

Cisco IP Phone---->Cisco Call Manager---->Sip Server (Provider)----->PSTN---->PRI---->Mitel

Can be a reason I have to make some changes on CISCO side.. what how could I know.. or what should ask Mitel side how they can check..

[bluewhite4]

Here's a really simplisitc test we've done in the past. Have the Cisco user call a Mitel phone direct, no auto-attendant. With the Mitel user listening, have the Cisco user press 1-9 on their phone. If the Mitel user hears the tones, then it should be working correctly.

It sounds like the SIP trunk provider is having an issue with your local PSTN provider. Since all your calls come in PSTN, they should all be treated the same. I would have the Cisco user have their SIP provider do an active trace, and look at the SIP messages that should contain the DTMF, as their transmitted to the PSTN.

[wiseguy]

Other test would be to dial from a Mitel phone to the external DID number that the Nupoint has. This will then be routed in to the Mitel to the E2T channel and from there to the Nupoint. The same route as any other external call to Nupoint.

[Chakara]

  In addition to the SIP provider (and I suspect them just on gut feeling) - Cisco has a lot of options as to how to handle DTMF.  There are a lot of variables on the Cisco side not defined in the post.

  It's a classic case of finger pointing.  They work fine to other auto-attendants - and you work fine from other phone systems. 

 I love BlueWhite suggestion - knowing if you at least get audible DTMF would be useful.

  Does the 3300 do any type of DTMF inspection during a call?  On a Cisco router, configured right, I can see the DTMF from trace logs and know at least what it thinks it sees.  At least in some scenarios.

  DTMF becomes odd over IP due to latency/jitter.  DTMF expects a clean analog audio signal at specific frequencies - latency and jitter warp the sound to much for DTMF detectors to get it right.

-Chak

[bluewhite4]

  Does the 3300 do any type of DTMF inspection during a call?  On a Cisco router, configured right, I can see the DTMF from trace logs and know at least what it thinks it sees.  At least in some scenarios.

To do this, I think all you would need to do is run CCS Trace from within Maintance. If you did it while the Cisco user was making the inbound call you could definitely see what DMTF if any is being seen by the Mitel. Although its been my experience that CCS Trace show so much info, you often need a Mitel helpdesk person to interpret it.

[ralph]

I'm suspicious of MaTai in this case.
Do you have any embedded VM mail boxes so that your embedd AA will work.   I'd like to see a test against that.
It that works then I'd have you Nupoint tech talk to Mitel.  There may be a patch..

Ralph

[newtomitel]

Thanks for all you guys

I have control over Cisco gears not on Mitel. If some one can give me any number where I can make a call and see if DTMF is working on that.. Just to make sure that DTMF from my side is working fine..

I can not make any change on Mitel Side nor I could request a customer to do so.. he is not our client..

So what I can do is make a test call if you guys can setup any VM or AA.

Regards

[Chakara]

  So in that scenario I'd first sniff my WAN and confirm that I'm sending the SIP message for the DTMF tones - then working with my SIP provider to confirm they get all the way off to the PSTN.  At that point you've CYA'd and I'd make myself available to work wth the far end PSTN/PBX.

  From the Mitel side, on ISDN - they can do Q.931 (EDT) traces and see if the DTMF tones are coming in....

-Chak