DTMF, fax and media resources at a hotel after a firewall refresh
A 180-room hotel runs CUCM 14 in a nearby data center. Guest-room analog phones terminate on two VG450 gateways running MGCP on site; the front desk and back office use 40 third-party SIP endpoints registered natively to CUCM. The WAN is 30 Mbps with a 1 Mbps EF queue, and the region between the hotel and the data center forces G.729 because the same circuit carries the property management system. Staff report three things: digits entered into the off-site reservations IVR are sometimes duplicated or dropped; faxes from the business center to the corporate fax server arrive half-rendered or fail outright; and after a firewall refresh that opened only UDP 5060 and 10000–20000, blind transfers from a third-party SIP phone complete but the transferred party hears silence while the other two talk. Plain point-to-point calls between hotel phones are unaffected.
1. Explain the IVR digit symptom and the fix, naming the specific settings on the gateway, the trunk and the endpoints.
Read the worked answer
Duplicated and dropped digits are the signature of in-band DTMF crossing a low-bit-rate codec. G.729 is a parametric codec; it does not reproduce DTMF tones faithfully, and the voice-activity-detection and echo-cancellation stages on the analog gateway clip the leading edge of each tone. The IVR hears a mangled, sometimes repeated, tone burst.
Fix: carry DTMF as RFC 2833 (named telephone events) end to end.
- SIP trunk / SIP profile: DTMF signaling method = RFC 2833. Confirm the provider's IVR accepts NTE; if it insists on in-band, the CUCM side must convert, which requires an MTP.
- MGCP gateway:
mgcp dtmf-relay voip codec all mode out-of-band, or on a SIP/H.323 dial peerdtmf-relay rtp-nte. If the gateway must be in-band toward the analog side, terminate the tones on the gateway instead of passing them through the codec. - Third-party SIP endpoints: confirm they emit RFC 2833 and not SIP INFO or in-band; a mismatch here breaks only that class of device, which matches the reported scope.
- If any hop requires in-band, insert an MTP with DTMF relay into the MRG so the conversion happens once, at a known point, rather than in the codec path.
Verify with a SIP ladder capture that the INVITE SDP advertises telephone-event/8000 and that the RTP stream carries the event packets.
2. The faxes fail over the same link. What must change, and what does it cost in bandwidth compared with the voice calls?
Read the worked answer
G.729 cannot carry a fax - the modulation is destroyed by the codec. Two viable designs:
T.38 relay (preferred). Configure fax protocol t38 with fallback cisco (or pass-through) and NSE-based switchover on both CUBE dial peers, and permit the T.38 UDPTL traffic through the firewall. Disable VAD and echo cancellation on the voice ports (no vad, negotiation of ECM per the far end's support). T.38 uses only a few kbps, so it is kind on the 1 Mbps EF queue.
G.711 fax pass-through (fallback). Force the fax calls to G.711 on the switch legs - typical approach is a dedicated 'fax' CSS and translation pattern so the call bypasses the G.729 region, with codec g711ulaw on the dial peers and fax-relay disabled. Each fax then costs ~80 kbps instead of 24 kbps.
The region must allow G.711 for the fax path, either via a separate region between the VG450 and CUBE with a higher max audio bit rate, or by using the region's dedicated fax bit-rate setting (which defaults to follow the audio rate).
Bandwidth consequence: one G.711 fax session (~80 kbps) occupies the EF queue like 3+ G.729 calls. With 1 Mbps EF, a handful of concurrent faxes plus the hotel's voice load is fine, but do not size the link assuming faxes ride in the G.729 budget - a 30 Mbps link with 1 Mbps EF is the constraint, not the circuit.
3. Why do blind transfers from third-party SIP phones complete but deliver one-way silence, while simple calls are fine? What exactly needs to change?
Read the worked answer
Simple calls between two hotel phones never cross the firewall, and CUCM stays out of the media path - the endpoints negotiate RTP peer-to-peer inside the hotel LAN.
Supplementary services on third-party SIP devices are different. These devices typically need a media termination point in the path to handle hold, transfer and re-INVITE behaviour they do not negotiate natively. CUCM inserts the MTP from the device's MRGL, and the MTP lives in the data center. Its RTP is sourced from CUCM's media port range (default 24576–32767, and Cisco gateways 16384–32767) - none of which is inside the 10000–20000 range the firewall team opened. Signalling for the transfer completes over TCP/TLS 5061 or UDP 5060, the two legs are connected, and the audio for the anchored leg is dropped by the firewall: exactly the 'two can talk, one hears silence' pattern.
Changes:
- Replace the 10000–20000 rule with the real ranges in both directions - CUCM media (24576–32767) and the gateway range (16384–32767) - or at minimum the subnet-to-subnet ranges between the hotel and the cluster/media resources.
- Confirm the MRG assigned to the third-party devices actually contains a registered MTP or transcoder; if it does not, the transfer would fail outright rather than silently.
- Keep SIP 5060/5061 open as-is, and pin the range in the CUCM service parameters so the firewall rule and CUCM never drift apart again.
Confirm with RTMT perfmon on the MTP (packets in vs. out) - a large asymmetry during the transfer proves the firewall is dropping the return path.