Jump to: navigation, search

DTMF Clamping in a Conference

This feature guards a customer's sensitive credit card information from an agent and from call recording. DTMF clamping is supported in single-site and multi-site deployments. Here is how it works when activated and enabled:

  1. The customer needs to enter a credit card number.
  2. The agent adds IVR to the call, which bridges the customer, agent, and IVR.
  3. The customer enters the requested credit card digits, but they are not recorded and the agent hears only silence.
  4. The credit card number is passed to the IVR, securely.

This behavior is called DTMF clamping, and SIP Server supports it to comply with the Payment Card Industry Data Security Standard (PCI DSS). MCP performs DTMF clamping for selected parties in a conference, for the following DTMF transmission modes:

  • RTP packets with a Named Telephone Event (NTE) payload as specified by RFC 2833
  • In-band audio tones (encoded using a regular audio codec, such as G.711)
  • SIP INFO packets with the content-type application/dtmf-relay

SIP Server uses MSML messages to inform MCP about which legs of the conference should reveal DTMF tones and which legs should suppress DTMF tones. Each leg is controlled individually. SIP Server defines the DTMF mode for each leg based on the DN type or DN-level configuration option.

In multi-site deployments, SIP Server uses the same mechanism as for Call Participant Info notifications (NOTIFY requests) to provide information about multi-site call participants. Routing Point parties are now included in these NOTIFY requests when DTMF clamping is enabled.

Activating DTMF Clamping

  1. Activate DTMF clamping by setting the Application-level option clamp-dtmf-allowed to true.
  2. When activated, you can enable the feature on a DN object that is configured as IVR. For this purpose, IVR can be configured as DNs of type Voice Treatment Port, Trunk, or Trunk Group:
    • If IVR is configured as a DN of the type Voice Treatment Port is added to the conference, then DTMF tones are clamped for all parties in the conference except for the Voice Treatment Port DN. No DN-level configuration is required.
    • If IVR is configured as a Trunk or Trunk Group DN, then activate DTMF clamping by setting the clamp-dtmf-enabled option to true on the corresponding Trunk or Trunk Group DN.
  3. In multi-site deployments, set the Application-level option sip-enable-call-info option to true.

On Routing Points

SIP Server automatically activates DTMF clamping in any conference where a Routing Point is invited. No DN-level configuration is required, and only a party represented by the Routing Point is allowed to receive DTMF digits. DTMF clamping is activated regardless of the type of treatment applied at the Routing Point, and it remains active as long as the Routing Point stays in the conference.

DTMF Clamping in Recordings

PCI compliance requires that DTMF tones are not recorded when clamping is enabled. To satisfy this requirement, recording must be disabled on the caller's leg. Otherwise, DTMF digits dialed by a caller could be recorded.

Genesys recommends that you enable recording on the agent's leg as shown on the diagram below.


Configuration Options


Setting: Application level
Section: TServer
Default Value: false
Valid Values: true, false
Changes Take Effect: For the next call

  • When set to true, enables the DTMF Clamping feature.
  • When set to false, disables this feature. This setting also preserves backward compatibility.


Setting: DN level
Section: TServer
Default Value: false
Valid Values: true, false
Changes Take Effect: For the next call

  • When set to true on a Trunk or Trunk Group DN that is added to a conference, enables DTMF clamping for all parties except the DN where this option is configured.
  • When set to false, disables DTMF clamping.

This option applies only to Trunk and Trunk Group DNs.

Feature Limitations

DTMF Clamping requires the Application-level option ringing-on-route-point to be set to true (the default value) when DTMF digits are collected via a treatment applied at the Routing Point.

This page was last edited on May 12, 2016, at 22:47.
Comments or questions about this documentation? Contact us for support!