Service Concept



  • Transferee - The party being transferred to the Transfer Target. (Part B) (It is also called recipient in cisco documents.)
  • Transfer Target - The new party being introduced to the Transferee. (Part C) (It is also called final-recipient in cisco documents.)
  • Transferor - The party initiating the transfer of the Transferee to the Transfer target. This is not supported on the IMG. The transferor is usually an application written on a separate server (Part A). It is also called originator in cisco documents.

transfer types

  • Blind Transfer - Its implemented using REFER method. Here there is no voice path or sip signaling between the transferor party and transferred-to party. The Transferee attempts to establish a session using that contact and reports the results of that attempt to the Transferor. (note, after the first NOTIFY received, only RTP will be terminated, SIP dialog still active)
  • Attended(Consulation) Transfer - The transferor places the transferee on hold, establishes a call with the transfer target to alert them to the impending transfer, places the target on hold, then proceeds with transfer using an escaped Replaces header field in the Refer-To header. This is another common service expected by current PBX and Centrex users. In some instances, the Transferee and Transfer target can be the same IMG.

Replaces functionality enables developers to implement features like Attended Call Transfer or Call Pickup. one party is replaced by another in a call. RFC 3891 specifies Replaces SIP header, that help SIP applications implement this capability.

Let's take a simple example. Bob is in his office and he received a call from a partner named Alice. While talking to her, he find out that, Alice is actually trying to reach a colleague (Carol) in Bob's organization. Now, Bob want the colleague to replace him in the call (in other words, transfer the call to Carol).

  • Attended Transfer with Early Completion - Lets say that next day, Bob again get a call from Alice. Now, he knows that the call is for Carol. This time he decides just ring Carol to let her know and DOES NOT WAIT Carol to answer the call prior to finish transfer. In this case everything remains the same, except that the Replaces header in the message from Carol will contain a flag-parameter called "early-only".

red|originator = transfor = who kicks the transfer action= secretary

Attended transfers allow the originator to have a call established between both the recipient and the final-recipient. Prior to attended transfer with early completion implementation, the call between the originator and the final-recipient has to be active, or in the talking state, before the originator can transfer it to the recipient.

However, in attended transfers with early completion, the originator establishes a call with the recipient and only needs to be in the process of setting up a call with the final-recipient. The final-recipient may be ringing, but has not answered the call from the originator.

REFER method , join header, replace header

REFER: (B sends REFR to A and A invites C)

  1. A calls B
  2. B sends REFER method to A with refer-to: C, referered-by B.
  4. A invites C with referered-by header
  5. A NOTIFY B again of success

join: ( B passes information to 3rd party and 3rd party sends invite to B join current call of of B)

  1. A calls B
  2. B tell C to join the call via non-sip mechanism (I guess refer can be used here)
  3. C sends invite to B with join header : join: ab-cid;from-tag=a-tag;to-tag=b-tag
  4. B puts A in focus mode
  5. B answers C
  6. now in conf mode

In a typical customer support scenario, a customer support executive (E) might want his manager (M) to join his call with a customer (C). How to achieve that? In SIP world, Join header specified by RFC 3911 helps in handling this situation. It defines a new header named Join, which holds the call-information. I.e the SIP message from the person Joining the call will contain a Join header with the call-information of the call he wish to join.

replace: ( 3rd party receives refer from B and sends invite to A replace current call of A-B)

  1. A calls B;
  2. B send refer to C
  3. C sends invite to A with replace header. replaces: a-b; from-tag=b-tag;to-tag=a-tag
  4. now A and C in RTP media communication
  5. A sends BYE to B
  6. B receives notify from C


On the surface, REFER looks like a simple Re-INVITE, but it differs in the fact that all the SIP messaging is
transferred to the new SIP endpoint in a REFER method, instead of simply redirecting the audio portion of the call. for Re-INVITE, the originator (user agent that initiates the transfer or Refer request) still sits in the middle and pass through SIP information.

REFER is used for transfering a call. it can be used in simple blind transfer case. in Consulation Transfer or attended transfer, then Refer needs to have one (Refer-To: … Replaces=..) header and Must be then followed by Invite with header (Replaces : …)

SIP RFC3261 specifies that a SIP UA may change CODECs, RTP ports, put cal in hold, etc during mid-call with Re-Invite.

RFC3311 defines the new UPDATE method for the Session Initiation Protocol (SIP). UPDATE allows a client to update parameters of a session (such as the set of media streams and their codecs) but has no impact on the state of a dialog. In that sense, it is like a re-INVITE, but unlike re-INVITE, it can be sent before the initial INVITE has been completed. This makes it very useful for updating session parameters within early dialogs.


good article about blind transfer vs attended transfer

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License