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???
Outbound DTMF from Z station
Re: Outbound DTMF from Z station
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
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
