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.<\/p>\n
At the heart of CUCM\u2019s 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.<\/p>\n
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.<\/p>\n
To the casual user, pressing the \u201chold\u201d 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.<\/p>\n
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<\/em>: This delicate negotiation ensures that the call\u2019s 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.<\/p>\n 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.<\/p>\n 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 When Savannah resumes the call, another Re-INVITE reverses the hold parameters, restoring the session to \u201csendrecv,\u201d 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.<\/p>\n This sequence illustrates the elegance of SIP\u2019s design\u2014enabling real-time media negotiation without breaking the session or requiring new call setups, contributing to a seamless communication experience.<\/p>\n 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 \u201cone-way audio\u201d or call drops.<\/p>\n Interoperability among diverse devices, codecs, and network conditions demands meticulous configuration and continuous validation. The dynamic nature of IP networks\u2014with jitter, latency, and packet loss\u2014further complicates the reliable transmission of signaling messages and media.<\/p>\n Understanding these challenges cultivates an appreciation for the sophistication embedded within CUCM\u2019s call hold features. It underscores the need for proactive monitoring and adaptive troubleshooting strategies to maintain robust communication infrastructures.<\/p>\n Hold commonly involves SIP re-INVITE offer\/answer negotiation with SDP media attributes such as Compatibility check:<\/i> 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.<\/p>\na=sendonly<\/code> means that party is offering to send but not receive on the stream; the corresponding answer is normally a=recvonly<\/code> or a=inactive<\/code>. An a=inactive<\/code> 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.<\/p>\na=sendonly<\/code>, that describes Savannah’s offered stream direction; Mariah’s matching answer may be a=recvonly<\/code> 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.<\/p>\nRead a re-INVITE correctly<\/h3>\n
a=sendonly<\/code>, a=recvonly<\/code> or a=inactive<\/code>, 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.<\/p>\nMusic on hold in CUCM<\/h3>\n