How to put the call on hold, and take off from hold?

In this method, we are checking first, if we have an active communication or not (is the call object "null" or not), then we can start to handle the "holding"/"unholding" process. If there is an active call and we call this method, there can be two cases: if the call is in not in "LocalHeld" state, that means we haven't put the call on hold yet, then we put the call on hold. If the call is in the "LocalHeld" state, then it indicates that we are already holding the call, so we take the call off hold. We can do it with checking the call's state and using the commands , introduced below:

call.Hold();
call.Unhold();

But the simplest way to do this:

if (call != null)
{
	call.ToggleHold();
}

As we can see, with the ToggleHold() method we do not even need to check the call's state, or store/check if the call is held or not. This method does the work for us.

Call flow diagram

The diagram below illustrates a full SIP Hold/Unhold call flow.

sequenceDiagram participant Softphone as Softphone Application participant Endpoint as Remote SIP Endpoint/PBX Softphone->>Softphone: User presses **Hold** (ToggleHold) Softphone->>Endpoint: SIP Hold re-INVITE (SDP a=sendonly) Endpoint-->>Softphone: 100 Trying (Hold Trying PDU) Endpoint-->>Softphone: 200 OK (Hold OK PDU, SDP a=inactive/sendonly) Softphone->>Endpoint: ACK (Hold ACK PDU) Softphone->>Softphone: Stop local media devices (mic/speaker) Softphone->>Softphone: User presses **Unhold** (ToggleHold) Softphone->>Endpoint: SIP Unhold re-INVITE (SDP a=sendrecv) Endpoint-->>Softphone: 100 Trying (Unhold Trying PDU) Endpoint-->>Softphone: 200 OK (Unhold OK PDU, SDP a=sendrecv) Softphone->>Endpoint: ACK (Unhold ACK PDU) Softphone->>Softphone: Restart local media devices, call active again

Capture SIP hold/unhold traffic with Wireshark

SIP Hold Invite PDU

A SIP Hold Invite PDU is the re-INVITE message a SIP endpoint sends to place an active call on hold, updating the session description to stop media from the local side. Key fields include the SDP body with a modified media direction attribute (such as a=sendonly), which tells the remote party to stop sending audio, and the Contact header, which still identifies where the held endpoint is reachable. The CSeq header increases its sequence number to differentiate this hold request from previous SIP transactions within the same dialog.

SIP Hold Trying PDU

A SIP Hold Trying PDU is the provisional 100 Trying response the remote endpoint or PBX sends after receiving the hold re-INVITE, indicating that it is processing the request. It reuses the same Call-ID and From/To tags to stay within the existing dialog, and echoes the CSeq number to confirm which specific hold transaction is being handled. This PDU does not change the media parameters yet; it simply acknowledges that the hold operation is underway at the signaling level.

SIP Hold OK PDU

A SIP Hold OK PDU is the 200 OK response confirming that the hold re-INVITE has been accepted and that the call is now logically on hold from the remote party’s perspective. Its SDP body reflects the agreed media direction for the hold state, for example a=inactive or a=sendonly, ensuring both ends apply consistent media behavior. The response also carries the updated Contact and CSeq headers, allowing further mid‑call control messages to build on this successful hold transaction.

SIP Hold ACK PDU

A SIP Hold ACK PDU is the final acknowledgment the holding endpoint sends after receiving the 200 OK to the hold re-INVITE, completing the three‑way handshake for the hold operation. It contains no SDP by default but preserves the dialog identifiers (Call-ID, From/To tags, and CSeq) so that the call remains established while media is suspended. Once this ACK is sent, both sides treat the call as held, and the softphone can safely stop local devices like microphone and speaker as shown in the example code.

SIP Unhold Invite PDU

A SIP Unhold Invite PDU is a re-INVITE message the endpoint sends to take a held call off hold, restoring normal bidirectional media flow. Its SDP body switches the media direction back to active, for example using a=sendrecv, which signals that both parties may resume talking. The Call-ID and dialog tags remain unchanged, while the CSeq number is incremented again to represent this new unhold transaction within the established session.

SIP Unhold Trying PDU

A SIP Unhold Trying PDU is the provisional response indicating that the remote endpoint or PBX has received the unhold re-INVITE and is processing the transition back to an active call. It references the same dialog identifiers and echoes the CSeq of the unhold request to ensure correct correlation between request and response. At this stage media is not yet fully restored; the PDU simply confirms progress of the unhold operation at the signaling layer.

SIP Unhold OK PDU

A SIP Unhold OK PDU is the 200 OK response confirming that the unhold re-INVITE has been accepted and that the call has returned to normal in‑call state. The SDP in this PDU advertises active media parameters, such as a=sendrecv, re-enabling two‑way audio between the participants. With Contact and CSeq fields aligned to this successful unhold transaction, further control actions like transfer or hangup can proceed seamlessly.

SIP Unhold ACK PDU

A SIP Unhold ACK PDU is the acknowledgment sent by the endpoint after receiving the 200 OK to the unhold re-INVITE, finalizing the transition back from hold to active media. It confirms that the offer/answer exchange for the unhold operation is complete while keeping the existing dialog intact through unchanged Call-ID and tag values. After this ACK, the softphone can restart local media devices and treat the call as fully in‑call again, allowing features like transfer and redial to operate on the restored session.