Call Features in SIP: Hold, Transfer, and Forwarding

SIP Signaling From the Wire Up: Part 9 of 12

Every phone has a hold button, a transfer button, and some kind of forwarding capability. These features feel simple when you're pressing buttons on a handset, but the SIP signaling that makes them work is more complex than the basic call setup we covered in earlier posts. This complexity is also where a lot of interoperability problems live. A transfer that works perfectly between two phones from the same manufacturer might fail when one side is a different brand, or when the call passes through certain PBX platforms or SBCs.

Understanding how these features work at the protocol level helps you diagnose why a hold is producing silence instead of music, why a transfer is dropping the call, or why forwarding isn't behaving as expected.

Hold

When you press the hold button on your phone, the phone needs to tell the other end to stop sending audio (or to expect that it will stop receiving audio, depending on the implementation). SIP handles this through a re-INVITE that modifies the media session.

Here's what happens. Alice and Bob are on an active call. The SDP on both sides has a=sendrecv, meaning both are sending and receiving audio. Alice presses hold. Her phone sends a re-INVITE with a modified SDP:

INVITE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.50:5060;branch=z9hG4bK8823
...
Call-ID: [email protected]
CSeq: 2 INVITE
Content-Type: application/sdp
Content-Length: 198

v=0
o=alice 2890844526 2890844527 IN IP4 10.0.0.50
s=Call
c=IN IP4 10.0.0.50
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=sendonly

The critical change is the last line: a=sendonly instead of a=sendrecv. This tells Bob's phone that Alice will still send audio (hold music, potentially) but will not be receiving audio. Bob's phone should stop sending its audio to Alice.

Notice that the session version in the o= line incremented from 2890844526 to 2890844527. This tells Bob's phone that the SDP has changed and the new parameters should be applied.

Bob's phone responds with a 200 OK and its own SDP, acknowledging the hold:

SIP/2.0 200 OK
...
Content-Type: application/sdp

v=0
o=bob 2808844564 2808844565 IN IP4 192.168.1.100
s=Call
c=IN IP4 192.168.1.100
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=recvonly

Bob's response says a=recvonly, which is the correct complement to Alice's sendonly. Bob will receive (Alice's hold music) but won't send.

When Alice takes the call off hold, she sends another re-INVITE with a=sendrecv, and the call returns to its normal two way state.

Hold variations

Not all implementations handle hold the same way. Some phones use a=inactive instead of a=sendonly, which produces complete silence in both directions. Some phones change the media destination in the c= line to 0.0.0.0, which is an older method of signaling hold that predates the direction attributes. Some phones do both. If you're troubleshooting a hold that isn't behaving as expected, check the SDP in the re-INVITE to see which method the phone is using.

The hold music question is also relevant. If Alice's phone sends a=sendonly and plays hold music, Bob hears the music because Alice is still sending. But the hold music might be generated by Alice's phone locally, or it might be generated by the PBX. If the PBX is supposed to provide hold music, the phone might need to signal hold differently, sometimes by sending the re-INVITE to the PBX rather than directly to Bob, so the PBX can insert itself into the media path. This varies by PBX platform.

Attended transfer

Attended transfer (sometimes called consultative transfer) is when Alice is on a call with Bob, puts Bob on hold, calls Charlie to make sure Charlie is available, and then connects Bob to Charlie while Alice drops out.

The SIP signaling for this involves the REFER method. Here's the sequence:

1. Alice is on a call with Bob (Call A)
2. Alice puts Bob on hold (re-INVITE with sendonly, as described above)
3. Alice calls Charlie (Call B, a completely separate SIP dialog with its own INVITE, 200 OK, ACK)
4. Alice talks to Charlie and confirms the transfer
5. Alice sends a REFER to Bob, telling him to establish a new call with Charlie:

REFER sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.50:5060;branch=z9hG4bK9921
...
Call-ID: [email protected]
CSeq: 4 REFER
Refer-To: <sip:[email protected]?Replaces=callid%40host
  %3Bto-tag%3Dxyz%3Bfrom-tag%3Dabc>
Referred-By: <sip:[email protected]>

The Refer-To header is the important one. It tells Bob's phone the address to connect to, and the Replaces parameter tells Charlie's phone which existing call to replace (Call B between Alice and Charlie). This allows Bob to seamlessly take over Alice's conversation with Charlie.

6. Bob's phone acknowledges the REFER with a 202 Accepted
7. Bob's phone sends an INVITE to Charlie with a Replaces header
8. Charlie's phone accepts, replacing Call B with a new call to Bob
9. Bob's phone sends NOTIFY messages back to Alice, reporting the progress:

NOTIFY sip:[email protected]:5060 SIP/2.0
...
Event: refer
Content-Type: message/sipfrag

SIP/2.0 200 OK

This NOTIFY tells Alice that the transfer succeeded (Bob got a 200 OK from Charlie). Alice can now tear down both of her original call legs.

Why transfers fail

Attended transfers are one of the most complex operations in SIP, and they're a common source of interoperability problems. Common failure points include:

REFER not supported. Some older devices or stripped down SIP implementations don't support the REFER method. They'll respond with a 405 Method Not Allowed.

Replaces header not supported. The Replaces mechanism is defined in a separate RFC (RFC 3891) and not all implementations handle it correctly. Without Replaces working properly, the transfer can't seamlessly take over the existing call leg, resulting in dropped audio or a second ringing phase that the transferred party doesn't expect.

Firewall blocking the new INVITE. The REFER tells Bob to send an INVITE to Charlie. If there's a firewall between Bob and Charlie that wasn't in the path of the original calls (which both went through Alice), the new INVITE might be blocked.

SBC complications. Session Border Controllers that are managing the signaling may not properly handle the REFER or may not relay the Replaces header correctly.

Blind transfer

Blind transfer (sometimes called unattended transfer) is simpler. Alice sends a REFER to Bob with Charlie's address, but Alice hasn't called Charlie first. Bob's phone sends an INVITE to Charlie. If Charlie answers, the transfer succeeds. If Charlie doesn't answer, the behavior depends on the implementation. Some phones reconnect Bob to Alice. Others drop the call entirely.

The REFER message looks similar to attended transfer but without the Replaces parameter:

REFER sip:[email protected]:5060 SIP/2.0
...
Refer-To: <sip:[email protected]>
Referred-By: <sip:[email protected]>

Blind transfer is less complex but has its own failure modes, particularly the "what happens when nobody answers" problem. Different phone platforms handle this differently, which is why blind transfers can behave inconsistently across mixed environments.

Transfer is the most involved of the call features and the one that breaks first in mixed-vendor environments. For the full message flow, the NOTIFY progress chain, how SBCs change what you see on the wire, and a fault-by-fault diagnostic table, see How Call Transfer Works in SIP.

Call forwarding

Call forwarding can be implemented in several ways in SIP, and the method used determines what the caller sees and experiences.

Server side forwarding (retargeting)

The most common approach is for the server (PBX or proxy) to handle forwarding internally. When a call arrives for Bob and Bob has forwarding enabled, the server simply redirects the INVITE to the forwarding destination without telling the caller. The caller's phone shows that it's calling Bob. Bob's phone never rings. The forwarding target answers, and the caller may not even know the call was forwarded.

In the trace, you'd see the INVITE arrive at the server for Bob, and then the server generating a new INVITE to the forwarding destination. The caller only sees normal call setup.

Redirect response (302)

The server can respond to the INVITE with a 302 Moved Temporarily, including the forwarding address in the Contact header:

SIP/2.0 302 Moved Temporarily
...
Contact: <sip:[email protected]>

This tells the caller's system to try the new address. The caller's phone or proxy then sends a new INVITE to Charlie. The caller might see a brief change on their display as the call is retargeted.

The advantage of 302 is that the server doesn't have to stay in the media path. The disadvantage is that not all caller devices handle 302 responses correctly, and some PBX platforms generate them in ways that confuse the receiving end.

SIP diversion header

When a call has been forwarded, the Diversion header records that fact:

Diversion: <sip:[email protected]>;reason=unconditional

This header is added to the INVITE by the forwarding server and tells the destination (and any intermediary) that this call was originally for Bob and was forwarded. The reason parameter indicates why: unconditional (always forward), no-answer (Bob didn't pick up), busy (Bob is on another call), or unavailable (Bob is offline).

Not all systems populate or read the Diversion header, but when it's present, it's useful for understanding call routing history.

Conference calls

SIP doesn't have a native conferencing mechanism. Three way calls and conference bridges are typically handled by the PBX or a dedicated media server that mixes the audio from multiple participants.

The SIP signaling for a conference usually involves the PBX creating multiple call legs, one to each participant, and mixing the audio from all legs together. Some implementations use REFER to move participants onto a conference bridge. Others have the PBX internally create the conference and bridge the existing call legs into it.

Because conferencing is implemented at the application level rather than in the protocol itself, the behavior varies significantly between PBX platforms. The underlying SIP is just normal call setup on each leg. The conferencing magic happens in the audio mixing, which is an RTP function, not a SIP function. If you are designing call flows that combine auto attendants, transfers, queues, and conferencing, an IVR planner can help you map the routing visually before you start configuring the PBX.

Next up: SIP Trunking: Connecting to the Outside World. We cover how your phone system connects to the public telephone network through SIP.