Complete Communications Engineering

What is SIP Call Transferring?

SIP Call Transferring provides a mechanism for transferring calls from one User Agent (UA) to another. The IETF “Session Initiation Protocol Call Control – Transfer” describes methods by which SIP UAs can provide call transfer services using such SIP extensions as REFER (RFC 3515), Replaces (RFC 3891), Referred-By (RFC 3892), and sipfrag (RFC 3420). Some examples of these services include blind transfer and attended transfer.

Brochure for SIP Call Transferring

SIP Blind Call Transfer

The most basic form of SIP Call Transferring is known as a blind call transfer. An example call flow for a blind call transfer can be seen below.

SIP Call Transferring - SIP Blind Call Transfer Flow

In this example, UA1 establishes a session with UA2. UA1(the transferor)wants to transfer UA2(the transferee) to UA3(the transfer target). First UA1 places UA2 on hold. UA1 attempts the transfer by sending a REFER request to UA2 with the URI of UA3 in the Refer-To header field.

UA2 responds to the REFER with a 202 response indicating that the request was acceptable. UA2 also updates UA1 on the status of the transfer by sending a NOTIFY message to UA1 with a sipfrag message body which consists of only the start line of a ‘100 Trying’ provisional response. UA2 then sends an INVITE to UA3 using the URI that it learned in the Refer-To header field of the REFER message.

When UA3 accepts the INVITE, UA2 alerts UA1 that the transfer was successful by sending a NOTIFY message to UA1 with a sipfrag message body with the start line of a ‘200 OK’ final response. Once UA1 knows that the transfer has succeeded, it ends the session with UA2 by sending it a BYE.

SIP Attended Call Transfer

A second, more complicated form of SIP Call Transferring is known as an attended transfer. An example call flow for an attended call transfer can be seen below.

SIP Call Transferring - SIP Attended Call Transfer Flow

In this example, UA1 establishes a session with UA2. UA1(the transferor) wants to transfer UA2(the transferee) to UA3(the transfer target). First UA1 places UA2 on hold. UA1 then establishes another session with UA3 to alert UA3 of the impending transfer. UA1 then places UA3 on hold. UA1 attempts the transfer by sending a REFER request to UA2 with the URI of UA3 in the Refer-To header field. The Refer-To header field also contains an escaped Replaces header field containing the dialog identifiers (call-ID, From tag, and To tag) for the dialog between UA1 and UA3.

UA2 responds to the REFER with a 202 response indicating that the request was acceptable. UA2 also updates UA1 on the status of the transfer by sending a NOTIFY message to UA1 with a sipfrag message body which consists of only the start line of a ‘100 Trying’ provisional response. UA2 then sends an INVITE to UA3 using the URI that it learned in the Refer-To header field of the REFER message. This INVITE also contains a Replaces header field with the dialog identifiers from the Refer-To field of the REFER message.

When UA3 receives the INVITE, it examines the Replaces header field and finds a dialog that matches the identifiers. UA3 now knows that this new INVITE should establish a new dialog that replaces the previous one it had with UA1. UA3 then accepts the INVITE from UA2 and sends a BYE to UA1 to end that dialog.

UA2 then alerts UA1 that the tranfer was successful by sending a NOTIFY message to UA1 with a sipfrag message body with the start line of a ‘200 OK’ final response. Once UA1 knows that the transfer has succeeded, it ends the session with UA2 by sending it a BYE.

More Information

Related SIP Call Transferring References

supported platforms for SIP Call Transferring

VOCAL Technologies has been in business for over 30 years and is an engineering design house that can provide a custom solution that meets your unique communication requirements.

Please contact us to discuss your communication application requirements.