Outbound SIP Calls Ring Once Then Go Silent
Acme's CUCM cluster connects to an ITSP through a CUBE. Inbound calls work. Outbound calls reach the ITSP, but the caller hears one ring and then silence until the called party answers; some calls drop at 30 seconds. A CUBE trace shows: CUCM sends an INVITE with SDP to CUBE (early offer). CUBE sends an INVITE without SDP to the ITSP. The ITSP returns 100 Trying, then 183 Session Progress with SDP, then 180 Ringing without SDP. CUBE forwards the 183 and 180 to CUCM. The ITSP requires reliable provisional responses and early media. DTMF also fails: callers press digits but the IVR does not respond. The CUCM SIP trunk uses SIP Profile STANDARD, which has early offer disabled and no MTP. The CUBE dial peer toward the ITSP is configured with dtmf-relay rtp-nte, but the CUCM-side dial peer has no dtmf-relay.
1. Interpret the trace and explain why the caller hears one ring and then silence, and why some calls drop at 30 seconds.
Read the worked answer
The 183 with SDP is early media, and the subsequent 180 without SDP can cause CUCM to stop treating the session as early media. The caller hears the local ringback generated for the first moments, then the media path is not established or is torn down, so silence follows. The 30-second drop is consistent with a provisional-response or media timeout: if the ITSP requires PRACK and the reliable provisional response is not acknowledged, the carrier eventually clears the call. The trace also shows CUBE sending a delayed-offer INVITE to the ITSP even though CUCM sent an early offer, so CUBE is not preserving the early-media negotiation end to end. The fix is to make the offer/answer direction consistent and to enable 100rel/PRACK where required, or to force early offer on the CUBE toward the ITSP so SDP is present before the first provisional response.
2. What is the role of an MTP in this scenario, and would an MTP fix the one-way or no-audio problem?
Read the worked answer
An MTP is needed when two legs cannot negotiate a common media format or when CUCM must generate SDP on behalf of an endpoint that cannot do early offer. It relays RTP and can translate codecs, and it is also used to interwork DTMF methods when the two sides differ. In this trace, CUCM is already sending SDP, so the first question is whether the MTP would be inserted on the CUCM side or the CUBE side. An MTP could fix DTMF if one side uses RFC 2833 and the other uses SIP INFO or in-band, and it can fix codec mismatch. It will not by itself fix a missing PRACK/100rel exchange or a carrier that rejects the offer/answer direction. Check the SIP profiles for 100rel and PRACK first, then insert an MTP only if codec or DTMF interworking requires it.
3. How would you correct the DTMF failure, and what would you check on both call legs?
Read the worked answer
Trace DTMF end to end. On the CUCM side, the phone or gateway must use a method the SIP trunk can carry, usually RFC 2833 (rtp-nte). If the CUCM dial peer has no dtmf-relay, CUBE cannot forward the events. On the ITSP side, the carrier may expect rtp-nte, SIP INFO, or in-band. Configure the same method on both CUBE dial peers, or use an MTP to interwork. Verify with 'show call active voice brief' or the CUBE trace that RTP events are present in both directions. Also check that the codec negotiated is not a low-bitrate codec that cannot carry named telephone events, and that no SIP normalization profile strips the telephone-event payload from SDP.