CUBE to ITSP: Codec, DTMF and Early-Offer Mismatch
A distributor keeps CUCM 14 at headquarters and reaches the PSTN through a CUBE (ISR 4331) with no PVDM installed, using a SIP trunk to an ITSP. Headquarters phones are 8845s; internal calls negotiate G.722. The ITSP supports G.729 only, requires SDP in our initial INVITE, and sends DTMF as RFC 2833. The SIP trunk's device pool sits in region TRUNK-REG, and the region between TRUNK-REG and the HQ phone region currently allows G.722 only. The trunk is configured for delayed offer with MTP Required unchecked. Symptom: every external call fails with 488 Not Acceptable Here, while internal calls work normally. The carrier portal shows our INVITEs arriving with only G.722 in the SDP.
1. Explain the 488 and state the exact configuration change that fixes it, including whether you also need a transcoder.
Read the worked answer
CUCM builds the offer for the trunk from the intersection of the endpoints' capabilities and the region linking the two device pools - here the TRUNK-REG to HQ-phone region, which permits only G.722. The INVITE therefore carries G.722 and nothing else. The ITSP supports only G.729, so there is no common codec and the far end returns 488. The SDP captured on the carrier portal is the proof; do not chase SIP profiles or CUBE dial peers.
Fix: change that region to allow G.729 (G.729a is enough; the 8845 supports it). Once the region permits G.729, CUCM offers G.729 on the trunk leg, and because the region also governs the phone side of the call, the phone leg is G.729 as well. No transcoder is required - a transcoder is only needed when the two legs genuinely must run different codecs, which is not the case here.
Only if the business insists on G.722 between the phone and CUCM while the trunk stays G.729 would you need a transcoder, and with no PVDM on the CUBE you would have to provide it from CUCM or another router with DSPs. That is a capacity purchase, not a fix for the 488.
2. After the codec change, external calls connect, but callers pressing 1 in the Unity Connection auto attendant get no response and the call times out. The ITSP dial peer on CUBE has no dtmf-relay configured. Trace the DTMF path and give the fix and verification.
Read the worked answer
Trace the media path in both directions of the call:
- PSTN caller presses 1 -> ITSP sends RFC 2833 (telephone-event) toward CUBE.
- CUBE receives it on the ITSP dial peer and must re-emit it on the CUCM-facing dial peer. With no
dtmf-relayon the dial peer, the event is not relayed in a form CUCM/Unity understands, so the digit is lost even though audio is fine. - CUCM's SIP profile DTMF Signaling Method must match (RFC 2833 is the default) and the INVITE SDP must contain
telephone-eventwith a payload type the far side accepts.
Fix: apply dtmf-relay rtp-nte on both CUBE dial peers in the path (ITSP-facing and CUCM-facing), keep the CUCM SIP profile on RFC 2833, and confirm in show sip-ua calls / SDP captures that telephone-event appears on both legs.
If the ITSP ever insists on inband DTMF instead, RFC 2833 relay no longer helps: the SCCP/SIP phones signal digits out-of-band (KPML/RFC 2833), so CUCM must insert an MTP to convert. That is the scenario to size DSP for - and the reason not to uncheck MTP capability globally just because this carrier does not need it today.
3. The ITSP now rejects calls that do not carry SDP in the first INVITE. The trunk is set to delayed offer. What are the options on CUCM and what is the operational cost of each?
Read the worked answer
Two settings interact: MTP Required and the SIP trunk's Early Offer behavior.
- Best Effort (no MTP inserted): CUCM offers early SDP when the calling device itself can supply it. Free of DSP, but not universal - delayed-offer sources (some gateways, voicemail ports, certain transfers) still produce an INVITE without SDP, and those calls keep failing.
- Force (insert MTP when needed): guarantees SDP in the first INVITE for every call on the trunk by anchoring media through an MTP. This is the reliable answer, and the cost is that an MTP session is consumed per call on that trunk, plus media hairpins through the MTP's location.
Since CUBE has no PVDM, the MTP must come from CUCM: the software (IPVMS) MTP on a node, or a DSP-bearing router elsewhere. The software MTP has a modest documented session ceiling per node, so size it against peak PSTN concurrency, register it in a Media Resource Group, and put that MRG in the MRGL used by the SIP trunk's device pool. If peak concurrency approaches the software bridge ceiling, buy DSPs - a failed MTP allocation returns fast busy on every external call, which is a worse outage than the codec problem you just fixed.