Resolving DTMF Mismatch Between SCCP and SIP Endpoints

Call Control / Media Resources

Refer to the exhibit. An administrator is attempting to resolve a DTMF issue to a specific IVR and has supplied logs from the most recent issue. What is the cause and solution of the issue? - image

  1. The local endpoint supports RFC2833, and the IVR supports only KPML. Configure an MTP to resolve the DTMF mismatch.
  2. The local endpoint does not support RFC2833, and the IVR supports only RFC2833. Configure a transcoder to resolve the DTMF mismatch.
  3. The local endpoint does not support RFC2833, and the IVR supports only RFC 2833. Configure an MTP to resolve the DTMF mismatch. Source Reference Answer
  4. The local endpoint supports RFC2833, and the IVR supports only KPML. Configure a transcoder to resolve the DTMF mismatch.

Community Votes

C
57%
A
43%

57% of anonymous learners picked answer C. Votes are pick records left by other test-takers — they are not the verified answer.

Community Insight

The core trap is confusing which log field represents the local device versus the remote peer, and incorrectly selecting a transcoder instead of an MTP for DTMF translation.

This question tests the ability to diagnose DTMF signaling mismatches by interpreting CUCM debug logs for local versus remote endpoint capabilities. The community consensus identifies that an MTP is required when one side uses Out-of-Band (RFC2833) and the other uses In-band or KPML without RFC2833 support.

Candidates often choose Option A because they misinterpret 'mLocalDtmfCaps' as belonging to the IVR rather than the calling endpoint (CUCM/Phone), leading to incorrect capability assessment.

Community Discussion (4 comments)

G0y0 👍 1 Selected: C
By endpoints here I mean a Phone/IVR/voicemail application and the gateway/trunk. The "mLocalDtmfCaps" refers to the dtmf methods supported by CUCM. Then: A. and D are incorrect.The local endpoint (CUCM in behalf of the phone) does not support RFC2833 here.
61d0d9d 👍 1 Selected: A
mLocalDtmfCaps = IVR
decdca7 👍 2 Selected: A
IVR is the local device and endpoint cannot access it.
TheBabu 👍 3 Selected: C
I would say it's C. mLocalDtmfCaps has KPML=1, Inband=0, so that means the local endpoint does not support RFC2833. mEndpointsDtmfCaps would be the IVR and it has the opposite (KPML=0, Inband=1). For that scenario I think an MTP would be the way to go, not an transcoder: "C. Need MTP In this scenario, SCCP EP supports OOB only, and SIP EP supports RFC2833 only. Therefore an MTP is needed. MTP will send\receive RFC2833 packets to\from the SIP EP and will send\receive OOB DTMF packets to\from CCM. CCM will send\receive OOB DTMF packets to\from MTP and the SCCP phone." https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/118708-technote-dtmf-00.html

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Expert Analysis

Why the Answer Is Correct

Option C is correct because the log shows mLocalDtmfCaps with KPML=1 and Inband=0, indicating the local endpoint (SCCP phone/CUCM) does not support RFC2833. Conversely, mEndpointsDtmfCaps shows the remote IVR supports RFC2833 (Inband=1 in this context implies RFC2833 capability in some logs, or explicitly stated in options). When an SCCP endpoint (OOB/KPML only) communicates with a SIP endpoint (RFC2833 only), an MTP is required to translate the DTMF signals. As noted in Comment [1], MTP handles the conversion between RFC2833 and KPML/In-band.

Why the Other Options Are Wrong

Options B and D suggest configuring a transcoder, which is incorrect because transcoders are used for audio codec conversion (e.g., G.711 to G.729), not DTMF signaling protocol translation. Option A is incorrect because it misidentifies the local endpoint's capabilities; the local endpoint does not support RFC2833 based on the log analysis provided in Comment [3].

Community Comment Notes

Comment [1] provides the most accurate technical breakdown, distinguishing between SCCP EP supporting OOB only and SIP EP supporting RFC2833 only. Comment [3] clarifies that 'mLocalDtmfCaps' refers to CUCM's view of the local phone, helping candidates avoid the common interpretation error.

Official Reference

Exam Strategy

Always map 'mLocalDtmfCaps' to the device initiating the call from the perspective of the CUCM server, and 'mEndpointsDtmfCaps' to the remote peer. Remember that MTPs handle DTMF/fax tone translation between different protocols, while Transcoders handle media payload codec differences.

Related Analysis

← Back to 350-801 Study Guide