Polycom Phones support DTMF inbound as a standard.
- SIP 3.2.0 changed the DTMF Payload Type from 101 into 127
- SIP 3.2.2 added SIP Info DTMF.
If you are unable to send DTMF Signals to an IVR or Voice Mail System you may need to change the method or the payload type.
Please liaise with your SIP Platform Support in order to gather this Information.
Changing from SIP Inbound (RFC2833) to SIP INFO (RFC2976) must be done with a Configuration File loaded from a Provisioning Server.
You archive this by adding:
<dtmf> <voIpProt voIpProt.SIP.dtmfViaSignaling.rfc2976="1" tone.dtmf.viaRtp="0"/> </dtmf>
Above will enable RFC2976 DTMF Support and disable inbound DTMF.
NOTE: A SIP_INFO_DTMF.zip example file is attached
The attached file within the above .ZIP file dtmf_sip_info.cfg can either be imported via the => Web Interface <= or loaded via a => provisioning server <=.
When using OutBound DTMF the Star * and Hash # character is usually encoded as 10 or 11.
If this should be sent as * and # instead please add the following parameter:
voIpProt.SIP.dtmfViaSignaling.rfc2976.nonLegacyEncoding="1"
Payload Type:
Another solution is to change the Payload Type via:
<tone tone.dtmf.rfc2833Payload="101"/>
Usually Payload Type 101 or 127 is supported by the SIP Switch.
Above will change the SIP Inbound Payload from 127 ( pre SIP 3.2.2 / UCS 3.3.x / UCS 4.0.x) into 101.
NOTE: A dtmf_payload_101.zip dtmf_payload_127.zip and example file is attached
The attached files can either be imported via the => Web Interface <= or loaded via a => provisioning server <=.
NOTE: Please check your Admin Guide and the Release Notes if your SIP / UC Software Version supports this functionality.
Changing Inbound DTMF signalling:
Using the parameter tone.dtmf.rfc2833Control="0" we can allow INBOUND sending of DTMF.
- Specify if the phone uses RFC 2833 to encode DTMF tones.
1 (default) - The phone indicates a preference for encoding DTMF through RFC 2833 format in its Session Description Protocol (SDP) offers by showing support for the phone-event payload type. This does not affect SDP answers and always honour the DTMF
format present in the offer.
0 - For deployments requiring in-band DTMF
Changing of the tone duration:
In some circumstances, it may be required to change the tone duration from the standard 50 Milliseconds to something longer.
<test tone.dtmf.onTime="100" />
Download and unzip the attached DTMF_Tone_Duration.zip and modify it for your needs and then import via the Web Interface.
Wireshark troubleshooting Payload Type:
Above shows the phone using Payload type 127 in the SIP INVITE.
- If Payload Type 127 is being used please filter as rtp.p_type == 127:
- If Payload Type 101 is being used please filter as rtp.p_type == 101 or simply rtpevent
above will also show the digits pressed. - If Payload Type 97 is being used please filter as rtp.p_type == 97:
Wireshark troubleshooting SIP Info method:
Above shows the phone advertising in the Message Header that it supports the SIP INFO method within the SIP INVITE.
Above shows the phone sending the DTMF digit 1 via the SIP INFO method.
Using Polycom Logs to check for the DTMF Digits being sent:
Changing the pps logging module to Event 2 via the Web Interface Settings > Logging > Module Log Level Limits >
or via a configuration file:
log.level.change.pps="2"
035555.330|pps |2|00|[PpsHybridC]: mediaSess2PpsCallInBandData NetCall(0x110f448) UsrCall(0x1580778) Type(0) Size(1) Data(3)
035556.293|pps |2|00|[PpsHybridC]: mediaSess2PpsCallInBandData NetCall(0x110f448) UsrCall(0x1580778) Type(0) Size(1) Data(6)
035557.783|pps |2|00|[PpsHybridC]: mediaSess2PpsCallInBandData NetCall(0x110f448) UsrCall(0x1580778) Type(0) Size(1) Data(9)Above shows, the digits 3, 6 and 9 have been sent via DTMF.
G.729
Due to G.729 being an extremely compressed Codec DTMF will more likely fail. Source => here <=