SIP Call Transferring
SIP 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.
SIP Blind Call Transfer
The most basic form of call transfer is known as blind call transfer. An example call flow for a blind call transfer can be seen below.
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 accepted. 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 is 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 call transfer is known as an attended transfer. An example call flow for an attended call transfer can be seen below.
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 accepted. 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 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.
This article was copied from
