Call Transfer

A call transfer can also happen after a call is established. For example, endpoint UA-B can transfer UA-A to another endpoint, UA-C. UA-B can make a blind transfer or an attended transfer. The following diagram describes a blind call transfer with SRTP Pass-through enabled. Note it does not show the SIP message exchange between UA-B and the Application Server to facilitate the call transfer (i.e. the INVITE from UA-B to put the call on hold and the REFER/NOTIFY message exchange between UA-B and the Application Server). After UA-A is put on hold and the transfer target (that is, UA-C) is received from UA-B, the Application Server attempts to establish a call to UA-C. After the call to UA-C is established, the Application Server takes UA-A off hold and connects its media session to that of UA-C.

A: SBC-B receives an INVITE (from the Application Server to invite UA-C) without an offer SDP.

B: SBC-B sends an INVITE without an offer SDP to UA-C.

C: SBC-B receives a 200 OK response with an offer SDP that has a SDES crypto attribute on the SRTP media line from UA-C.

D: Since Multi-system Selective SRTP Pass-through is enabled within the ingress realm, SBC-B adds a cookie to the egress offer SDP that is sent to the core realm.

E: SBC-A receives a re-INVITE to UA-A with the offer SDP that has the cookie sent by SBC-B.

F: Since Multi-system Selective SRTP Pass-through is enabled within the ingress realm, SBC-A adds the SDES crypto attribute retrieved from the cookie to the offer SDP sent to UA-A.

G: SBC-A receives an answer SDP that has a SDES crypto attribute on the SRTP media line from UA-A.

H: SBC-A checks if it has a cookie in the offer SDP and adds the cookie to the answer SDP that is sent to the core realm. The cookie contains an encryption of the SDES crypto attribute received in the answer SDP from UA-B. SBC-A stops the encryption of any SRTP packets going to UA-B (set up for MoH) so that SRTP packets from/to UA-B can now pass through SBC-A without any decryption/encryption.

I: SBC-B receives the answer SDP that has the cookie sent by SBC-A.

H: SBC-B decrypts the cookie using the shared secret to retrieve the SDES crypto attribute. SBC-B adds the SDES crypto attribute retrieved from the cookie to the answer SDP.

After the call to UA-C is established and the call to UA-A is resumed (with the resulted media going between UA-A and UA-C) the Application Server disconnects the call with UA-A. Note that steps C-J are essentially the same steps as steps A-H in the Call Setup example. The difference is that the offer SDP from C comes to SD-B in a 200 OK response and the answer SDP sent by SBC-B to C is in the ACK.