Outbound DTMF from Z station

This is the main discussion forum, if the subject that you want to talk about is not listed around here.
Post Reply
RonSmits
Member
Posts: 12
Joined: 14 Sep 2008 15:13

Outbound DTMF from Z station

Post by RonSmits » 14 May 2018 14:03

Outbound DTMF to a conference service, from a Z station port connected to a Polycom Soundstation 2 is either not receiving digits or hearing double digits. In tests to cellphone, it appears to be sending two digits. It is as if the Enterprise system is hearing the DTMF and sending its own digit, as well as passing the DTMF from the Polycom too.
I have tried setting Analog type to Modem or Fax, VSI Transparency, and Z IVR requires a license.
Any thoughts guys???

jazzepat
Member
Posts: 19
Joined: 23 Oct 2007 13:53

Re: Outbound DTMF from Z station

Post by jazzepat » 08 Jan 2019 09:01

Hi RonSmits

Did you end up with a resolution to this issue? I have a client where we have the exact same issue is occurring.

They are running release R12.0-m1.403-15-h-as-c82 and "all of a sudden" their analogue Z station ports (which also are Polycomms) are sending double digits when attempting to send DTMF during a call (ie to join a conference).

This is happening on SLI and MIX boards, so it seems it's not a specific hardware problem, but I am considering backplane. The call establishes, so the tone detection on the analogue port works fine.

As another test because of the SIP trunk and direct RTP, I created a loopback trunk using 2 e1 ports (there are 2 PRA cards in the system) and moved their analogue Polycomm onto a Cisco/Linksys SPA112. The call flow is


Polycomm -> SIP ATA -> OXE (GD board / ARMADA3) -> E1 Loop Out -> e1 Loop In -> SIP Call to Network (GD board / ARMADA3)

and even in this setup, the establishment of the call and all RTP/voice works fine. When the conference phone then tries to enter DTMF to join a bridge, random digits are doubled, meaning this issue isn't just impacting the analogue ports but also the OXE's detection (or perhaps generation) of DTMF on a digital circuit also.

This is still strange as most sets on this system are still digital and they are able to send DTMF fine.

The problem seems to have appeared since we have had to migrate from ISDN to SIP trunking.

We haven't rebooted the PABX yet and its due for a maintenance upgrade to the latest version of 12.0, so I'm going to try that but I'm running out of ideas. I honestly don't think its software related as there have been no software changes to the system (aside from commissioning the SIP trunk and changing ARS etc. . ie no changes relating to DTMF) which would point back to hardware but I don't know how to prove it.

Any thoughts would be welcome

Thanks

Post Reply

Return to “MAIN”