Enable DTMF Detection in BroadWorks 3-way/N-way Conferencing

Introduction

This document describes how you config Cisco BroadWorks AS system level conferencing service to detect a joiner key in DTMF tone then send to other joiners.  

Prerequisites

Cisco recommends that you have knowledge of these topics:

• Cisco BroadWorks System Administrator privilege
• SIP protocol and RTP protocol terminology

Requirements

The are no specific requirements for this document.

Components Used

This document is not restricted to specific software and hardware versions.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.

Background Information

Historically on one hand, it seems that clamp tones can be omitted from those join requests sent to the MS that are sent on behalf of those services that were transitioned from RFC-4240 to the Cr interface in R20.0; in order to maintain DTMF pass-through parity for those services in previous releases (detailed in legacy Cisco BroadWorks document BW-ReleaseNotes-R200.pdf - section 2.18). On the other hand  allowing DTMF to pass through the bridge can sometimes result in random/spurious DTMF digits being heard on N-way / bridge calls as a result of some SIP GWs inadvertently producing RFC2833 packets from short periods of DTMF frequencies in human speech. Ultimately it seems there can be some way for the user to control whether tones are clamped on their bridge calls or not. 

Symptoms to DTMF Detection Disable in BroadWorks 3-way/N-way Conferencing

• All 3 or N parties have negotiated with the same telephone event in the SIP negotiation yet certain party could not detect and  receive one other participant key in DTMF tone.

  2026.10.01 11:08:20:813 AEST | Info       | Sip | Sip EncodeQ 0 | 1845022 | +12409709002 | callhalf-399213:8 | 143c5db2-2993-4a7c-b99b-13009

  f0216b5

  udp 842 SIP Bytes OUT to 10.137.49.188:54609

  INVITE sip:2409709002a@10.137.49.188:54609;ob SIP/2.0

  Via:SIP/2.0/UDP 10.66.82.111;branch=z9hG4bKBroadWorks.1ecf9ns-10.137.49.188V54609-0-981507103-891032902-1790816892984-

  From:<sip:9008@syd.cisco.com;user=phone>;tag=891032902-1790816892984-

  To:<sip:2409709002a@syd.cisco.com;ob>;tag=tSGqysh9viBbdtxcSozvVuhz8pzwAQbI

  Call-ID:BW110812984011026-1311916429@10.66.82.111

  CSeq:981507103 INVITE

  Contact:<sip:10.66.82.111:5060>

  Allow:ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY,UPDATE

  Supported:

  Accept:application/media_control+xml,application/sdp,multipart/mixed

  Max-Forwards:10

  Content-Type:application/sdp

  Content-Length:194

  v=0

  o=BroadWorks 6577 2 IN IP4 10.66.82.92

  s=-

  c=IN IP4 10.66.82.92

  t=0 0

  m=audio 10938 RTP/AVP 0 101

  a=rtpmap:0 PCMU/8000

  a=rtpmap:101 telephone-event/8000

  a=fmtp:101 0-15

  a=ptime:20

  
  
  2026.10.01 11:08:20:849 AEST | Info       | Sip | Call Half Input Adapter 4 | 1845325 | +12409709002 | callhalf-399213:8 | 143c5db2-2993-4a7

  c-b99b-13009f0216b5

  udp 980 SIP Bytes IN from 10.137.49.188:54609

  SIP/2.0 200 OK

  Via: SIP/2.0/UDP 10.66.82.111;received=10.66.82.111;branch=z9hG4bKBroadWorks.1ecf9ns-10.137.49.188V54609-0-981507103-891032902-1790816892984

  -

  Call-ID: BW110812984011026-1311916429@10.66.82.111

  From: <sip:9008@syd.cisco.com;user=phone>;tag=891032902-1790816892984-

  To: <sip:2409709002a@syd.cisco.com;ob>;tag=tSGqysh9viBbdtxcSozvVuhz8pzwAQbI

  CSeq: 981507103 INVITE

  Contact: "jianlianEntGrp1User2" <sip:2409709002a@10.137.49.188:54609;ob>

  Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS

  Supported: replaces, 100rel, timer, norefersub

  Content-Type: application/sdp

  Content-Length:   320

  v=0

  o=- 3999805696 3999805698 IN IP4 10.137.49.188

  s=pjmedia

  b=AS:117

  t=0 0

  a=X-nat:0

  m=audio 4030 RTP/AVP 0 101

  c=IN IP4 10.137.49.188

  b=TIAS:96000

  a=rtcp:4031 IN IP4 10.137.49.188

  a=sendrecv

  a=rtpmap:0 PCMU/8000

  a=ssrc:1396647929 cname:01981b15291a0084

  a=rtpmap:101 telephone-event/8000

  a=fmtp:101 0-16

  
  
  

• There is not packet loss, nor SRTP encrypt/decrypt discrepancy, yet certain party could not detect and receive another participant key in DTMF tone.
  
  
  

• Identify the CFW Control clamp tone "1 2 3 4 5 6 7 8 9 0 # *" in AS XSLog

  2026.10.01 11:08:20:850 AEST | Info       | Sip | Sip EncodeQ 0 | 1845348 | +12409709002 | callhalf-399213:8 | 143c5db2-2993-4a7c-b99b-13009

  f0216b5

  udp 460 SIP Bytes OUT to 10.137.49.188:54609

  ACK sip:2409709002a@10.137.49.188:54609;ob SIP/2.0

  Via:SIP/2.0/UDP 10.66.82.111;branch=z9hG4bKBroadWorks.1ecf9ns-10.137.49.188V54609-0-981507103A891032902-1790816892984-

  From:<sip:9008@syd.cisco.com;user=phone>;tag=891032902-1790816892984-

  To:<sip:2409709002a@syd.cisco.com;ob>;tag=tSGqysh9viBbdtxcSozvVuhz8pzwAQbI

  Call-ID:BW110812984011026-1311916429@10.66.82.111

  CSeq:981507103 ACK

  Contact:<sip:10.66.82.111:5060>

  Max-Forwards:10

  Content-Length:0

  2026.10.01 11:08:20:850 AEST | Info       | MediaCr | MediaCrInputAdapter 0 | 1845349 | cfw-control@10.66.82.92 | localHost75850 | 143c5db2-

  2993-4a7c-b99b-13009f0216b5

  Processing Event: com.broadsoft.io.mediacr.events.MediaCrJoinEvent (participant - 0) {CHCallManagerService.callhalf-399213,SessionKe

  y.localHost75850}

  2026.10.01 11:08:20:850 AEST | Info       | MediaCr | MediaCrInputAdapter 0 | 1845350 | cfw-control@10.66.82.92 | localHost75850 | 143c5db2-

  2993-4a7c-b99b-13009f0216b5

  409 CFW Bytes OUT to 10.66.82.92:7575

  CFW 230 CONTROL

  Content-Type: application/msc-mixer/1.0+xml

  Control-Package: msc-mixer/1.0

  Content-Length: 292

  <mscmixer version="1.0" xmlns="urn:ietf:params:xml:ns:msc-mixer">

  <join id1="1999115148-1790816900797-:359393922" id2="1_51a417e0-a6c8-4fd9-b285-a7b496773709_1@10.66.82.111">

  <stream media="audio" direction="sendrecv">

  <clamp tones="0 1 2 3 4 5 6 7 8 9 # *"/>

  </stream>

  </join>

  </mscmixer>
  
  

  2026.10.01 11:08:20:850 AEST | Info       | CallP | Call Half Input Adapter 4 | 1845351 | Media Manager | Media Conference | +12409709002 |

  jianlianEntGrp1 | callhalf-399213 | 143c5db2-2993-4a7c-b99b-13009f0216b5

  com.broadsoft.events.media.ConferenceParticipantAddedEvent(callhalf-399213:8)

  processed by - com.broadsoft.services.conference.ConferenceServiceInstance

  2026.10.01 11:08:20:850 AEST | Info       | Sip | Call Half Input Adapter 4 | 1845352 | +12409709002 | callhalf-399213:8 | 143c5db2-2993-4a7

  c-b99b-13009f0216b5

  udp 428 SIP Bytes IN from 10.137.49.188:54609

  SIP/2.0 500 Unhandled by dialog usages

  Via: SIP/2.0/UDP 10.66.82.111;received=10.66.82.111;branch=z9hG4bKBroadWorks.1ecf9ns-10.137.49.188V54609-0-981507104-891032902-1790816892984

  -

  Call-ID: BW110812984011026-1311916429@10.66.82.111
  

  -

  Call-ID: BW110812984011026-1311916429@10.66.82.111

  From: <sip:9008@syd.cisco.com;user=phone>;tag=891032902-1790816892984-

  To: <sip:2409709002a@syd.cisco.com;ob>;tag=tSGqysh9viBbdtxcSozvVuhz8pzwAQbI

  CSeq: 981507104 INFO

  Content-Length:  0

Information TAC Needs for Initial Triage

• XSLog analyse of the AS XSLog to verify all participants have negotiated with the same telephone-event.
  
  
• Network topology.
• Packet capture of that DTMF pressing participant phone device.
• Output of these commands when the 3-way/N-way conferencing DTMF undetect from one or more of the other parties when a participant has pressed in the DTMF tone.
       

  AS_CLI/System/CallP/DTMFTransmission> get

    transmissionMethod = signaling

    signalingContentType = application/dtmf-relay
  
  

  MS_CLI/Applications/MediaStreaming/Interfaces/SIP> get

    listeningPort = 5060

    listeningPortTLS = 5061

    retransmissionDelay200OKInMilliseconds = 500

    maxRetransmission200OK = 3

    t1 = 500

    t2 = 4000

    supportTCP = false

    supportUDP = true

    supportTLS = false

    tlsClientAuthenticationRequired = false

    tlsHandshakeTimeoutInMilliseconds = 1000

    acceptDTMFRelay = true

    routeAdvanceTimeoutInSeconds = 5

    sessionAuditIntervalInSeconds = 1200

    enableStrictSdpValidation = false

  
    

  AS_CLI/SubscriberMgmt/Policy/CallProcessing/Conferencing> get

    maxConferenceParties = 6

    conferenceURI = labconfAS@syd.cisco.com

    conferenceDisableClampTones = false

  
  
  

Configuration Step

Post troubleshooting to rule out other factors like SIP negotiation and packet drop, and other misconfigurations to accept DTMF Relay in the 3-way/N-way conferencing bridge, you check AS systme level paramter conferenceDisableClampTones has been set to false.  Change this System level parameter conferenceDisableClapTones to true then the DTMF detection can be enabled in 3-way/N-way conferencing.

Related Information

Cisco BroadWorks CR Interface Enhancements DTMF Relay Support

Revision History

Revision	Publish Date	Comments
1.0	22-Oct-2026	Initial Release