In SIP-based telephony, a call is commonly placed on hold through a new session-description negotiation, with direction attributes such as sendonly, recvonly or inactive. Music on hold requires an available media source and working routing/codec negotiation; a healthy SIP dialog alone does not establish that RTP audio is flowing.
SIP hold and session negotiation
At the heart of CUCM’s call management lies the Session Initiation Protocol (SIP), a flexible and ubiquitous signaling protocol designed to initiate, modify, and terminate multimedia sessions. Unlike traditional telephony signaling, SIP operates with a text-based messaging format that grants transparency and adaptability, making it a favored choice in IP telephony systems.
SIP is a signaling protocol, not an inherently half-duplex audio channel. A call may carry bidirectional RTP media while SIP negotiates its session description. Hold and resume are commonly represented by changes to SDP media-direction attributes such as sendonly, recvonly, inactive, and sendrecv, exchanged in an offer-answer transaction. The receiving endpoint and any intermediate border element must apply those attributes correctly; a completed SIP transaction does not itself prove that music-on-hold RTP packets can reach the held participant.
To the casual user, pressing the “hold” button on a phone seems straightforward: the call pauses, and the remote party hears music or silence. However, the underlying mechanism involves a sophisticated sequence of SIP messaging, primarily leveraging the Re-INVITE method to modify session parameters without tearing down the entire call.
On a SIP hold request, an endpoint, CUCM or an intermediary may initiate session renegotiation depending on the call path and supported device profiles. The new SDP carries media-direction attributes from the perspective of the party offering or answering: a=sendonly means that party is offering to send but not receive on the stream; the corresponding answer is normally a=recvonly or a=inactive. An a=inactive offer proposes neither sending nor receiving. These direction attributes negotiate media; they do not by themselves prove that Cisco Unified Communications Manager has connected a working Music on Hold source.
This delicate negotiation ensures that the call’s logical continuity remains intact while allowing media streams to be paused or rerouted. In practice, the endpoint placing the call on hold typically stops sending media and instead plays Music On Hold (MOH) locally or streams it to the remote party, depending on configuration.
For a simplified hypothetical call flow, consider two endpoints, Savannah and Mariah. Savannah initiates a call to Mariah, and the session is established through an exchange of SIP INVITE and ACK messages.
In this hypothetical call, Savannah presses Hold while speaking to Mariah. The endpoint or CUCM, according to the configured signaling path, negotiates new SDP using a re-INVITE or other supported session update. If Savannah’s side offers a=sendonly, that describes Savannah’s offered stream direction; Mariah’s matching answer may be a=recvonly or inactive. CUCM can separately route a configured music-on-hold media resource to the held party if the codec, media-resource group, device and trunk policies allow it. SIP signaling success is not proof that Mariah actually hears RTP music.
When Savannah resumes the call, another Re-INVITE reverses the hold parameters, restoring the session to “sendrecv,” resuming two-way media flow. Eventually, when the conversation ends, either party sends a BYE request, signaling call termination, which is acknowledged by the other side.
This sequence illustrates the elegance of SIP’s design—enabling real-time media negotiation without breaking the session or requiring new call setups, contributing to a seamless communication experience.
Read a re-INVITE correctly
Although the SIP Re-INVITE method elegantly supports hold and resume, it is not without pitfalls. Network engineers often confront issues where endpoints do not correctly interpret SDP changes, leading to “one-way audio” or call drops.
Interoperability among diverse devices, codecs, and network conditions demands meticulous configuration and continuous validation. The dynamic nature of IP networks—with jitter, latency, and packet loss—further complicates the reliable transmission of signaling messages and media.
Understanding these challenges cultivates an appreciation for the sophistication embedded within CUCM’s call hold features. It underscores the need for proactive monitoring and adaptive troubleshooting strategies to maintain robust communication infrastructures.
Hold commonly involves SIP re-INVITE offer/answer negotiation with SDP media attributes such as a=sendonly, a=recvonly or a=inactive, but the effective direction always depends on which party sent the offer and what the peer answered. A direction attribute does not universally instruct the far end to start a particular Music on Hold stream. When troubleshooting, compare both SDP bodies, address/port changes, RTP counters and the selected CUCM media-resource path; mistimed or incompatible renegotiation can otherwise cause one-way audio or silence.
Compatibility check: Review Cisco’s documented SIP trunk profile and media-resource settings for the exact CUCM release and carrier/SBC combination. Do not rewrite SDP direction attributes or assume a vendor-agnostic ‘normalization’ fix merely because a held call is silent. Reproduce the failure in a supported test call, compare the inbound/outbound offer and answer, verify codec and Music on Hold selection, and apply profile adjustments only when the platform’s interoperability guidance supports them.
Music on hold in CUCM
Cisco Unified Communications Manager acts as the nerve center for IP telephony, yet the end-user experience depends heavily on the capabilities of Cisco endpoints—such as Cisco IP Phones, Cisco Jabber clients, and third-party SIP devices. These devices interpret SIP signaling and SDP session modifications to enact call hold states accurately.
Endpoints must faithfully implement SIP standards to recognize Re-INVITE messages that indicate hold or resume states. Discrepancies or firmware incompatibilities can lead to erratic behaviors, including improper media muting or failed hold activation. Therefore, CUCM administrators often collaborate closely with endpoint teams to ensure firmware versions align with supported features and call flow expectations.
An integral component of the hold experience is Music On Hold (MOH), which serves as a sonic placeholder that informs the held party the call is temporarily suspended yet still active. CUCM supports diverse MOH configurations, including local audio files, centralized MOH servers, and streaming audio from external sources.
In geographically distributed deployments, managing MOH becomes increasingly intricate. Network latency, bandwidth limitations, and routing configurations can affect how MOH streams reach endpoints. CUCM uses media resources like Media Termination Points (MTPs) and MOH servers to facilitate consistent audio delivery, even across different network segments or VPNs.
Additionally, MOH playlists and messaging can be tailored to reinforce corporate branding or compliance messages, embedding a subtle yet strategic layer into the hold process that enhances caller engagement during otherwise passive wait times.
Music on Hold (MOH) isn’t just about tunes—it’s about media control and psychological continuity. Proper MOH architecture must account for:
- Codec Match: Ensure that MOH audio files are available in G.711 and G.729 formats.
- Redundancy: Deploy multiple MOH servers to reduce single points of failure.
- Multicast Strategy: In large campuses, multicast MOH conserves bandwidth, but must be supported by the endpoint and routed appropriately by Layer 3 infrastructure.
Advanced Technique: Use Unicast MOH fallback for endpoints traversing non-multicast-aware firewalls or tunnels. This avoids dead air even in constrained topologies.
SIP trunks and border elements
When calls traverse SIP trunks to external carriers or interconnected PBX systems, CUCM’s hold handling extends beyond internal signaling. Proper SIP trunk configuration is vital to ensure hold requests propagate correctly across network boundaries.
Some carriers handle call hold signaling differently or may require specific SIP headers to be present or suppressed. Misalignment between CUCM’s signaling and the carrier’s interpretation can result in calls being dropped or parties hearing silence rather than MOH.
To mitigate these challenges, administrators often negotiate detailed session parameter agreements with carriers, monitor SIP traces meticulously, and employ SIP normalization scripts or route pattern manipulation to harmonize signaling flows.
Cisco Unified Border Element acts as a session border controller (SBC) between CUCM and external networks, mediating signaling and media streams. CUBE plays a critical role in transforming SIP messages, codec negotiation, and enforcing security policies.
When a call is placed on hold, CUBE must preserve SDP session modifications intact to prevent call disruption. Its ability to adapt and translate signaling ensures interoperability between disparate systems, especially in multi-vendor or hybrid cloud environments.
Moreover, CUBE’s logging and diagnostic features empower network engineers to trace hold-related signaling exchanges, detect anomalies, and fine-tune session parameters, thereby enhancing overall call reliability.
Call hold behavior is especially fragile across federated networks, where CUCM interacts with third-party SIP servers, carriers, or SBCs (Session Border Controllers). In such cases, hold and resume behavior hinges on how well SIP signaling and media expectations are synchronized.
- SIP ALG (Application Layer Gateway) rewriting c=IN IP4 0.0.0.0, causing media blackholes
- Misinterpretation of inactive by the remote PBX leading to call teardown
- Delayed ACK responses after Re-INVITE are causing timeout-based disconnection
- Disable SIP ALG on intermediate firewalls
- Use test labs to verify call flows with new carrier services.
- Monitor CUBE debug logs (debug ccsip all) for misaligned attributes.s
Follow the real media path
Effective call management is impossible without a robust toolkit for monitoring and troubleshooting. Cisco’s Real-Time Monitoring Tool (RTMT) serves as an indispensable asset in this regard, enabling network administrators to capture and analyze SIP traces in real time.
By reviewing SIP transactions, engineers can observe the detailed flow of INVITE, ACK, BYE, and SUBSCRIBE messages that underpin call state changes. This granular insight reveals when Re-INVITEs are sent to initiate holds, when acknowledgments confirm session modifications, and how call termination signals propagate.
Such deep analysis fosters a profound understanding of call behavior, uncovering anomalies such as missed ACKs or improper SDP attributes that could impair call stability or user experience. RTMT’s role transcends troubleshooting; it becomes a lens through which the invisible choreography of call signaling is made visible.
Despite CUCM’s robust design, call hold issues inevitably arise in complex deployments. Common symptoms include one-way audio, calls dropping upon hold or resume, or callers hearing silence instead of MOH.
- Capture SIP Traces: Using Cisco RTMT or Wireshark to record SIP message flows provides visibility into INVITE, Re-INVITE, ACK, and BYE transactions.
- Verify SDP Attributes: Checking the session description payload for correct “sendonly,” “recvonly,” or “inactive” flags clarifies if endpoints are properly instructed.
- Inspect Codec Compatibility: Mismatched codecs during session renegotiation can prevent media streams from resuming correctly.
- Evaluate Network Conditions: Latency, jitter, or packet loss can impair SIP message delivery or RTP media streams critical for MOH and call audio.
- Check Endpoint Firmware and Configurations: Incompatibilities or misconfigurations on phones or soft clients may cause improper handling of hold signals.
Through persistent analysis of these factors, network teams can isolate root causes and implement targeted remediation strategies, such as firmware upgrades, SIP normalization rules, or media resource adjustments.
Every device in CUCM belongs to a Device Pool, which links it to media resources like MOH servers, MTPs, and Transcoders. When a user places a call on hold, CUCM chooses the MOH server based on region settings and bandwidth thresholds. Misconfigured region settings often lead to latency, jitter, or complete failure to stream MOH.
Strategic Tip: Define intra-region bandwidths with foresight. A low-bandwidth setting (e.g., 8 kbps) between regions can disable MOH altogether, causing silence or triggering resource reservation errors.
Diagnose silence on hold
Scenario: In a simulated hybrid Cisco deployment, suppose users report callers placed on hold would intermittently experience complete silence, rather than hearing Music On Hold (MOH). The issue was geographically sporadic and affected only SIP trunk-connected endpoints.
Hypothetical diagnostic scenario: Suppose a CUCM-managed SIP trunk sends an a=inactive re-INVITE during hold and a third-party gateway fails to reestablish the expected media path. That would require examining the offer and answer, SIP responses, trunk-profile interoperability, media addresses and the subsequent RTP packets. An inactive stream is not inherently a ‘full call disconnection’; the cause must be demonstrated rather than assumed from a single attribute.
Additionally, the MOH server located in a different region was attempting to stream across a WAN link experiencing jitter above acceptable thresholds. This caused RTP packets to arrive too late, or be dropped altogether, leading to a perceived silence.
- SIP normalization rules were deployed to modify the SDP attributes to “a=sendonly,” which preserved MOH transmission across all endpoints.
- A secondary, localized MOH server was configured within each regional CUCM cluster to serve media without latency-induced dropout.
- Network QoS policies were enforced to prioritize RTP traffic between CUCM and MOH servers.
This case illustrated how small misalignments in protocol expectations, especially between CUCM and non-Cisco systems,—can produce disproportionately confusing outcomes.
Every hold event alters the media path. Is RTP correctly rerouted to MOH servers or silenced as per endpoint expectations?
- Use the show call active voice brief on CUBE or debug ccsip messages to monitor media transformations.
- Implement Cisco IOS-based IP SLA for real-time RTP stream testing.
- Employ transcoding or MTPs when codec mismatches are expected.
Diagnose a resume failure
Scenario: A simulated centralized CUCM deployment could exhibit a sporadic problem where calls placed on hold could not be resumed. End users reported “Resume Failed” errors, and the only resolution was to disconnect and redial.
Hypothetical diagnostic scenario: Suppose hold succeeds but resume yields silence after a re-INVITE changes SDP direction and transport parameters. A phone, SBC or firewall may not handle the negotiated address/port transition as expected, but a firmware bug is only one possibility. Compare both SDP bodies and media flows, check actual endpoint release notes and supported settings, then validate a platform-supported corrective change before assigning the failure to a known device defect.
Furthermore, the endpoint had temporarily lost access to the Device Pool’s Media Termination Point, due to a failed failover during a maintenance event.
- The endpoint firmware was updated to the latest stable release, fixing the SDP misinterpretation.
- The MTP failover group was restructured for resilience using redundant fallback resources.
- An automated RTMT alert system was configured to detect failed resume attempts and trigger diagnostic log collection.
This scenario highlights how even routine events like hold and resume can become fraught with complexity when compounded by firmware inconsistencies and media resource instability.
- Monitor resource utilization via CUCM’s Real-Time Monitoring Tool (RTMT).
- Set thresholds and generate automated alarms for under-provisioned media resources.
- Ensure every region has localized media servers to mitigate WAN delay.
Codecs, regions and transcoding
Hold behavior may demand transcoding when the calling and called parties support dissimilar codecs. For instance, a G.729 endpoint calling a G.711 MOH server needs an intermediary transcoder. CUCM allocates a transcoder based on device pool association and available DSP resources.
Architectural Insight: Centralize transcoding resources only if low WAN latency is guaranteed. In distributed deployments, local transcoders ensure lower packet loss and decreased MOS (Mean Opinion Score) variance.
- Standardize firmware across all phone models.
- Regularly test hold/resume with newly introduced device types or third-party SIP clients.
- Check device-specific logs to catch configuration anomalies.
Log events and validate the fix
Beyond reactive troubleshooting, modern communication ecosystems leverage analytics to anticipate and prevent call hold issues. CUCM’s integration with Cisco Prime Collaboration or third-party monitoring tools enables the collection of call quality metrics, signaling error rates, and MOH stream performance data.
Analyzing trends such as frequent hold-related call drops or prolonged MOH durations can inform proactive interventions, ranging from network optimization to endpoint configuration tuning. This data-driven approach aligns with the enterprise’s strategic goals of delivering reliable, high-quality communications that foster productivity and satisfaction.
No elegant architecture is complete without observability. CUCM offers native logging and monitoring via RTMT and syslog integration. However, deeper insights emerge when coupled with:
Suggested derived KPI: Track a locally defined ‘hold or resume failures by device pool’ rate from reproducible call-event, SIP-trace and incident data. This is an analyst-defined metric, not a verified native RTMT counter named ‘Call Hold Failures per Device Pool.’ Document the numerator, denominator, collection window and device-pool association before comparing trends. An increase can prompt investigation of firmware interoperability, SIP trunk handling, codec negotiation, Music on Hold resources or MTP allocation; it is not by itself proof of any one cause.
