Table Of Contents

SIP Call Flows

Call Flow Scenarios for Successful Calls

Gateway to Cisco SIP IP Phone in a SIP Network

Call Setup and Disconnect

Call Setup and Hold

Call to a Gateway Acting As an Emergency Proxy from a Cisco SIP IP Phone

Cisco SIP IP Phone to Cisco SIP IP Phone

Simple Call Hold

Call Hold with Consultation

Call Waiting

Call Transfer Without Consultation

Call Transfer Without Consultation Using Failover

Call Transfer with Consultation

Call Transfer with Consultation Using Failover

Network Call Forwarding (Unconditional)

Network Call Forwarding (Busy)

Network Call Forwarding (No Answer)

Three-Way Calling

Call from a Cisco SIP IP Phone to a Gateway Acting As a Backup Proxy in a SIP Network

Call from a Cisco SIP IP Phone to a Cisco SIP IP Phone Using a SIP Backup Proxy

Call from a Cisco SIP IP Phone to a Cisco SIP IP Phone Using a SIP Emergency Proxy

Call Flow Scenarios for Failed Calls

Gateway to Cisco SIP IP Phone in a SIP Network

Called Number Is Busy

Called Number Does Not Answer

Client, Server, or Global Error

Cisco SIP IP Phone to Cisco SIP IP Phone in a SIP Network

Called Number Is Busy

Called Number Does Not Answer

Authentication Error

SIP Call Flows

---

This appendix includes the following sections:

•Call Flow Scenarios for Successful Calls

•Call Flow Scenarios for Failed Calls

SIP uses the following request methods:

•INVITE—Indicates that a user or service is being invited to participate in a call session.

•ACK—Confirms that the client has received a final response to an INVITE request.

•BYE—Terminates a call and can be sent by either the caller or the called party.

•CANCEL—Cancels any pending searches but does not terminate a call that has already been accepted.

•OPTIONS—Queries the capabilities of servers.

•REGISTER—Registers the address listed in the To header field with a SIP server.

•REFER—Indicates that the user (recipient) should contact a third party for use in transferring parties.

•NOTIFY—Notifies the user of the status of a transfer using REFER. Also used for remote reboot and message waiting indication (MWI).

The following types of responses are used by SIP and generated by the Cisco SIP gateway:

•SIP 1xx—Informational Responses

•SIP 2xx—Successful Responses

•SIP 3xx—Redirection Responses

•SIP 4xx—Client Failure Responses

•SIP 5xx—Server Failure Responses

•SIP 6xx—Global Failure Responses

Call Flow Scenarios for Successful Calls

This section describes successful call flow scenarios, which are as follows:

•Gateway to Cisco SIP IP Phone in a SIP Network

•Cisco SIP IP Phone to Cisco SIP IP Phone

Gateway to Cisco SIP IP Phone in a SIP Network

The following scenarios describe and illustrate successful calls in a gateway to a Cisco SIP IP phone:

•Call Setup and Disconnect

•Call Setup and Hold

•Call to a Gateway Acting As an Emergency Proxy from a Cisco SIP IP Phone

Call Setup and Disconnect

Figure B-1 illustrates a successful phone-call setup and disconnect. In this scenario, the two end users are User A and User B. User A is located at PBX A. PBX A is connected to Gateway 1 (SIP gateway) via a T1/E1. User B is located at a Cisco SIP IP phone. Gateway 1 is connected to the Cisco SIP IP phone over an IP network.

The call flow is as follows:

1. User A calls User B.

2. User B answers the call.

3. User B hangs up.

Figure B-1 Successful Setup and Disconnect

Step	Action	Description
1.	Setup—PBX A to Gateway 1	Call setup is initiated between PBX A and Gateway 1. Setup includes the standard transactions that take place as User A attempts to call User B.
2.	INVITE—Gateway 1 to Cisco SIP IP phone	Gateway 1 maps the SIP URL phone number to a dial peer. The dial peer includes the IP address and the port number of the SIP-enabled entity to contact. Gateway 1 sends a SIP INVITE request to the address it receives as the dial peer, which, in this scenario, is the IP phone. In the INVITE request: •The IP address of the phone is inserted in the Request-URI field. •PBX A is identified as the call session initiator in the From field. •A unique numeric identifier is assigned to the call and is inserted in the Call-ID field. •The transaction number within a single call leg is identified in the CSeq field. •The media capability that User A is ready to receive is specified. •The port on which the gateway is prepared to receive the RTP data is specified.
3.	Call Proceeding—Gateway 1 to PBX A	Gateway 1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
4.	100 Trying—Cisco SIP IP phone to Gateway 1	The phone sends a SIP 100 Trying response to Gateway 1. The response indicates that the INVITE request has been received.
5.	180 Ringing—Cisco SIP IP phone to Gateway 1	The phone sends a SIP 180 Ringing response to Gateway 1. The response indicates that the user is being alerted.
6.	Alerting—Gateway 1 to PBX A	Gateway 1 sends an Alert message to User A. The message indicates that Gateway 1 has received a 180 Ringing response from the phone. User A hears the ringback tone that indicates that User B is being alerted.
7.	200 OK—Cisco SIP IP phone to Gateway 1	The phone sends a SIP 200 OK response to Gateway 1. The response notifies Gateway 1 that the connection has been made.
8.	Connect—Gateway 1 to PBX A	Gateway 1 sends a Connect message to the PBX A. The message notifies PBX A that the connection has been made.
9.	Connect ACK—PBX A to Gateway 1	PBX A acknowledges Gateway 1's Connect message.
10.	ACK—Gateway 1 to Cisco SIP IP phone	Gateway 1 sends a SIP ACK to the phone. The ACK confirms that Gateway 1 has received the 200 OK response. The call session is now active.
11.	BYE—Cisco SIP IP phone to Gateway 1	User B terminates the call session. The phone sends a SIP BYE request to Gateway 1. The request indicates that User B wants to release the call.
12.	Disconnect—Gateway 1 to PBX A	Gateway 1 sends a Disconnect message to PBX A.
13.	Release—PBX A to Gateway 1	PBX A sends a Release message to Gateway 1.
14.	200 OK—Gateway 1 to Cisco SIP IP phone	Gateway 1 sends a SIP 200 OK response to the phone. The response notifies the phone that Gateway 1 has received the BYE request.
15.	Release Complete—Gateway 1 to PBX A	Gateway 1 sends a Release Complete message to PBX A, and the call session terminates.

Call Setup and Hold

Figure B-2 illustrates a successful phone-call setup and call hold. In this scenario, the two end users are User A and User B. User A is located at PBX A. PBX A is connected to Gateway 1 (SIP gateway) via a T1/E1. User B is located at a Cisco SIP IP phone. Gateway 1 is connected to the Cisco SIP IP phone over an IP network.

The call flow is as follows:

1. User A calls User B.

2. User B answers the call.

3. User B puts User A on hold.

4. User B takes User A off hold.

Figure B-2 Successful Call Setup and Hold

Step	Action	Description
1.	Setup—PBX A to Gateway 1	Call setup is initiated between PBX A and Gateway 1. Setup includes the standard transactions that take place as User A attempts to call User B.
2.	INVITE—Gateway 1 to Cisco SIP IP phone	Gateway 1 maps the SIP URL phone number to a dial peer. The dial peer includes the IP address and the port number of the SIP-enabled entity to contact. Gateway 1 sends a SIP INVITE request to the address it receives as the dial peer, which, in this scenario, is the IP phone. In the INVITE request: •The IP address of the phone is inserted in the Request-URI field. •PBX A is identified as the call session initiator in the From field. •A unique numeric identifier is assigned to the call and is inserted in the Call-ID field. •The transaction number within a single call leg is identified in the CSeq field. •The media capability that User A is ready to receive is specified. •The port on which the gateway is prepared to receive the RTP data is specified.
3.	Call Proceeding—Gateway 1 to PBX A	Gateway 1 sends a Call Proceeding message to the PBX A to acknowledge the Call Setup request.
4.	100 Trying—Cisco IP 7960G/7940G phone to Gateway 1	The phone sends a SIP 100 Trying response to Gateway 1. The response indicates that the INVITE request has been received.
5.	180 Ringing—Cisco SIP IP phone to Gateway 1	The phone sends a SIP 180 Ringing response to Gateway 1. The response indicates that the user is being alerted.
6.	Alerting—Gateway 1 to the PBX A	Gateway 1 sends an Alert message to User A. The message indicates that Gateway 1 has received a 180 Ringing response from the phone. User A hears the ringback tone that indicates that User B is being alerted.
7.	200 OK—Cisco SIP IP phone to Gateway 1	The phone sends a SIP 200 OK response to Gateway 1. The response notifies Gateway 1 that the connection has been made.
8.	Connect—Gateway 1 to PBX A	Gateway 1 sends a Connect message to PBX A. The message notifies PBX A that the connection has been made.
9.	ACK—Gateway 1 to Cisco SIP IP phone	Gateway 1 sends a SIP ACK to the phone. The ACK confirms that User A has received the 200 OK response. The call session is now active.
10.	Connect ACK—PBX A to Gateway 1	PBX A acknowledges Gateway 1's Connect message.
11.	INVITE—Cisco SIP IP phone to Gateway 1	User B puts User A on hold. The phone sends a SIP INVITE request to Gateway 1.
12.	200 OK—Gateway 1 to Cisco SIP IP phone	Gateway 1 sends a SIP 200 OK response to the phone. The response notifies the phone that the INVITE was successfully processed.
13.	ACK—Cisco SIP IP phone to Gateway 1	The phone sends a SIP ACK to Gateway 1. The ACK confirms that the phone has received the 200 OK response. The call session is now temporarily inactive. No RTP packets are being sent.
14.	INVITE—Cisco SIP IP phone to Gateway 1	User B takes User A off hold. The phone sends a SIP INVITE request to Gateway 1.
15.	200 OK—Gateway 1 to Cisco SIP IP phone	Gateway 1 sends a SIP 200 OK response to the phone. The response notifies the phone that the INVITE was successfully processed.
16.	ACK—Cisco SIP IP phone to Gateway 1	The phone sends a SIP ACK to Gateway 1. The ACK confirms that the phone has received the 200 OK response. The call session is now active.

Call to a Gateway Acting As an Emergency Proxy from a Cisco SIP IP Phone

Figure B-3 illustrates a successful call from a Cisco SIP IP phone to a gateway acting as an emergency proxy.

Figure B-3 Successful Call from Cisco SIP IP Phone to SIP Gateway (Emergency Proxy)

Step	Action	Description
1.	INVITE—Cisco SIP IP phone to the gateway (emergency proxy)	The phone tries to connect to the gateway (emergency proxy) by sending out the INVITE message. The dial template for the emergency route is matched.
2.	Setup—Gateway to the PBX	Call setup is initiated between the gateway and the PBX. Setup includes the standard transactions that take place as User A attempts to call User B.
3.	Call Proceeding—PBX to the gateway	The PBX sends a Call Proceeding message to the gateway to acknowledge the Call Setup request.
4.	100 Trying—Gateway to Cisco SIP IP phone (User A)	The gateway sends a SIP 100 Trying response to User A. The response indicates that the INVITE request has been received.
5.	Alerting—PBX to the gateway	The PBX sends an Alert message to the gateway. The message indicates that the PBX has received a 100 Trying Ringing response from the gateway.
6.	180 Ringing—Gateway to Cisco SIP IP phone (User A)	The gateway sends a SIP 180 Ringing response to User A. The response indicates that the gateway is being alerted.
7.	Connect—PBX to the gateway	The PBX sends a Connect message to the gateway. The message notifies the gateway that the connection has been made.
8.	200 OK—Gateway to Cisco SIP IP phone (User A)	The gateway sends a SIP 200 OK response to User A. The response notifies User A that the connection has been made.
9.	ACK—Cisco SIP IP phone (User A) to the gateway	User A sends a SIP ACK to the gateway. The ACK confirms that User A has received the 200 OK response. The call session is now active.
10.	Connect ACK—Gateway to the PBX	The gateway acknowledges PBX's Connect message.
11.	BYE—Cisco SIP IP phone (User A) to the gateway	User A terminates the call session and sends a SIP BYE request to the gateway. The request indicates that User A wants to release the call.
12.	Disconnect—Gateway to the PBX	The gateway sends a Disconnect message to the PBX.
13.	Release—PBX to the gateway	The PBX sends a Release message to the gateway.
14.	200 OK—Gateway to Cisco SIP IP phone (User A)	The gateway sends a SIP 200 OK response to User A. The response notifies User A that the gateway has received the BYE request.
15.	Release Complete—Gateway to the PBX	The gateway sends a Release Complete message to the PBX and the call session terminates.

Cisco SIP IP Phone to Cisco SIP IP Phone

The following sections describe and illustrate successful calls from a Cisco SIP IP phone to another Cisco SIP IP phone:

•Simple Call Hold

•Call Hold with Consultation

•Call Waiting

•Call Transfer Without Consultation

•Call Transfer Without Consultation Using Failover

•Call Transfer with Consultation

•Call Transfer with Consultation Using Failover

•Network Call Forwarding (Unconditional)

•Network Call Forwarding (Busy)

•Network Call Forwarding (No Answer)

•Three-Way Calling

•Call from a Cisco SIP IP Phone to a Gateway Acting As a Backup Proxy in a SIP Network

•Call from a Cisco SIP IP Phone to a Cisco SIP IP Phone Using a SIP Backup Proxy

•Call from a Cisco SIP IP Phone to a Cisco SIP IP Phone Using a SIP Emergency Proxy

Simple Call Hold

Figure B-4 illustrates a successful call between Cisco SIP IP phones in which one of the participants places the other on hold and then returns to the call. In this call flow scenario, the two end users are User A and User B. User A and User B are both using Cisco SIP IP phones, which are connected via an IP network.

The call flow scenario is as follows:

1. User A calls User B.

2. User B answers the call.

3. User B places User A on hold.

4. User B takes User A off hold.

5. The call continues.

Figure B-4 Simple Call Hold

Step	Action	Description
1.	INVITE—Phone A to Phone B	Phone A sends a SIP INVITE request to Phone B. The request is an invitation to User B to participate in a call session. In the INVITE request: •The phone number of User B is inserted in the Request-URI field in the form of a SIP URL. The SIP URL identifies the address of User B and takes a form similar to an e-mail address (user@host, where user is the telephone number and host is either a domain name or a numeric network address). For example, the Request-URI field in the INVITE request to User B appears as "INVITE sip:555-0199@companyb.com; user=phone." The "user=phone" parameter distinquishes that the Request-URI address is a telephone number rather than a username. •Phone A is identified as the call session initiator in the From field. •A unique numeric identifier is assigned to the call and is inserted in the Call-ID field. •The transaction number within a single call leg is identified in the CSeq field. •The media capability User A is ready to receive is specified.
2.	180 Ringing—Phone B to Phone A	Phone B sends a SIP 180 Ringing response to Phone A.
3.	200 OK—Phone B to Phone A	Phone B sends a SIP 200 OK response to Phone A. The response notifies Phone A that the connection has been made. If Phone B supports the media capability advertised in the INVITE message sent by Phone A, it advertises the intersection of its own and Phone A's media capability in the 200 OK response. If Phone B does not support the media capability advertised by Phone A, it sends back a 400 Bad Request response with a 304 Warning header field.
4.	ACK—Phone A to Phone B	Phone A sends a SIP ACK to Phone B. The ACK confirms that Phone A has received the 200 OK response from Phone B. The ACK might contain a message body with the final session description to be used by Phone B. If the message body of the ACK is empty, Phone B uses the session description in the INVITE request.
A two-way RTP channel is established between Phone A and Phone B.
5.	INVITE—Phone B to Phone A	Phone B sends a midcall INVITE to Phone A with new Session Description Protocol (SDP) session parameters (IP address), which are used to place the call on hold. Call_ID=1 SDP: c=IN IP4 0.0.0.0 The c= SDP field of the SIP INVITE contains an 0.0.0.0. This places the call in hold.
6.	200 OK—Phone A to Phone B	Phone A sends a SIP 200 OK response to Phone B.
7.	ACK—Phone B to Phone A	Phone B sends a SIP ACK to Phone A. The ACK confirms that Phone B has received the 200 OK response from Phone A.
The RTP channel between Phone A and Phone B is torn down.
8.	INVITE—Phone B to Phone A	Phone B sends a midcall INVITE to Phone A with the same call ID as the previous INVITE and new SDP session parameters (IP address), which are used to reestablish the call. Call_ID=1 SDP: c=IN IP4 10.10.10.0 To reestablish the call between Phone A and Phone B, the IP address of Phone B is inserted into the c= SDP field.
9.	200 OK—Phone A to Phone B	Phone A sends a SIP 200 OK response to Phone B.
10.	ACK—Phone B to Phone A	Phone B sends a SIP ACK to Phone A. The ACK confirms that Phone B has received the 200 OK response from Phone A.
A two-way RTP channel is reestablished between Phone A and Phone B.

Call Hold with Consultation

Figure B-5 illustrates a successful call between Cisco SIP IP phones in which one of the participants places the other on hold, calls a third party (consultation), and then returns to the original call. In this call flow scenario, the end users are User A, User B, and User C. They are all using Cisco SIP IP phones, which are connected via an IP network.

The call flow scenario is as follows:

1. User A calls User B.

2. User B answers the call.

3. User B places User A on hold.

4. User B calls User C.

5. User B disconnects from User C.

6. User B takes User A off hold.

7. The original call continues.

Figure B-5 Call Hold with Consultation

Step	Action	Description
1.	INVITE—Phone A to Phone B	Phone A sends a SIP INVITE request to Phone B. The request is an invitation to User B to participate in a call session. In the INVITE request: •The phone number of User B is inserted in the Request-URI field in the form of a SIP URL. The SIP URL identifies the address of User B and takes a form similar to an e-mail address (user@host, where user is the telephone number and host is either a domain name or a numeric network address). For example, the Request-URI field in the INVITE request to User B appears as "INVITE sip:555-0199@companyb.com; user=phone." The "user=phone" parameter distinquishes that the Request-URI address is a telephone number rather than a username. •Phone A is identified as the call session initiator in the From field. •A unique numeric identifier is assigned to the call and is inserted in the Call-ID field. •The transaction number within a single call leg is identified in the CSeq field. •The media capability User A is ready to receive is specified.
2.	180 Ringing—Phone B to Phone A	Phone B sends a SIP 180 Ringing response to Phone A.
3.	200 OK—Phone B to Phone A	Phone B sends a SIP 200 OK response to Phone A. The response notifies Phone A that the connection has been made. If Phone B supports the media capability advertised in the INVITE message sent by Phone A, it advertises the intersection of its own and Phone A's media capability in the 200 OK response. If Phone B does not support the media capability advertised by Phone A, it sends back a 400 Bad Request response with a 304 Warning header field.
4.	ACK—Phone A to Phone B	Phone A sends a SIP ACK to Phone B. The ACK confirms that Phone A has received the 200 OK response from Phone B. The ACK might contain a message body with the final session description to be used by Phone B. If the message body of the ACK is empty, Phone B uses the session description in the INVITE request.
A two-way RTP channel is established between Phone A and Phone B.
5.	INVITE—Phone B to Phone A	Phone B sends a midcall INVITE to Phone A with new SDP session parameters (IP address), which are used to place the call on hold. Call_ID=1 SDP: c=IN IP4 0.0.0.0 The c= SDP field of the SIP INVITE contains 0.0.0.0. This places the call in hold.
6.	200 OK—Phone A to Phone B	Phone A sends a SIP 200 OK response to Phone B.
7.	ACK—Phone B to Phone A	Phone B sends a SIP ACK to Phone A. The ACK confirms that Phone B has received the 200 OK response from Phone A.
The RTP channel between Phone A and Phone B is torn down.
8.	INVITE—Phone B to Phone C	Phone B sends a SIP INVITE request to Phone C. The request is an invitation to User C to participate in a call session.
9.	180 Ringing—Phone C to Phone B	Phone C sends a SIP 180 Ringing response to Phone B.
10.	200 OK—Phone C to Phone B	Phone C sends a SIP 200 OK response to Phone B. The response notifies Phone B that the connection has been made. If Phone B supports the media capability advertised in the INVITE message sent by Phone A, it advertises the intersection of its own and Phone A's media capability in the 200 OK response. If Phone B does not support the media capability advertised by Phone A, it sends back a 400 Bad Request response with a 304 Warning header field.
11.	ACK—Phone B to Phone C	Phone B sends a SIP ACK to Phone C. The ACK confirms that Phone B has received the 200 OK response from Phone C. The ACK might contain a message body with the final session description to be used by Phone C. If the message body of the ACK is empty, Phone C uses the session description in the INVITE request.
A two-way RTP channel is established between Phone B and Phone C.
12.	BYE—Phone B to Phone C	The call continues and then User B hangs up. Phone B sends a SIP BYE request to Phone C. The request indicates that User B wants to release the call.
13.	200 OK—Phone C to Phone B	Phone C sends a SIP 200 OK response to Phone B. The response notifies Phone B that the BYE request has been received. The call session between User A and User B terminates.
The RTP channel between Phone B and Phone C is torn down.
14.	INVITE—Phone B to Phone A	Phone B sends a midcall INVITE to Phone A with the same call ID as the previous INVITE and new SDP session parameters (IP address), which are used to reestablish the call. Call_ID=1 SDP: c=IN IP4 10.10.10.0 To reestablish the call between Phone A and Phone B, the IP address of Phone B is inserted into the c= SDP field.
15.	200 OK—Phone A to Phone B	Phone A sends a SIP 200 OK response to Phone B.
16.	ACK—Phone B to Phone A	Phone B sends a SIP ACK to Phone A. The ACK confirms that Phone B has received the 200 OK response from Phone A.
A two-way RTP channel is reestablished between Phone A and Phone B.

Call Waiting

Figure B-6 illustrates a successful call between Cisco SIP IP phones in which two parties are in a call, and one of the participants receives a call from a third party and then returns to the original call. In this call flow scenario, the end users are User A, User B, and User C. They are all using Cisco IP 7960G/7940G phones, which are connected using an IP network.

The call flow scenario is as follows:

1. User A calls User B.

2. User B answers the call.

3. User C calls User B.

4. User B accepts the call from User C.

5. User B switches back to User A.

6. User B hangs up, ending the call with User A.

7. User B is notified of the remaining call with User C.

8. User B answers the notification and continues the call with User C.

Figure B-6 Call Waiting

Step	Action	Description
1.	INVITE—Phone A to Phone B	Phone A sends a SIP INVITE request to Phone B. The request is an invitation to User B to participate in a call session. In the INVITE request: •The phone number of User B is inserted in the Request-URI field in the form of a SIP URL. The SIP URL identifies the address of User B and takes a form similar to an e-mail address (user@host, where user is the telephone number and host is either a domain name or a numeric network address). For example, the Request-URI field in the INVITE request to User B appears as "INVITE sip:555-0199@companyb.com; user=phone." The "user=phone" parameter distinquishes that the Request-URI address is a telephone number rather than a username. •Phone A is identified as the call session initiator in the From field. •A unique numeric identifier is assigned to the call and is inserted in the Call-ID field. •The transaction number within a single call leg is identified in the CSeq field. •The media capability User A is ready to receive is specified.
2.	180 Ringing—Phone B to Phone A	Phone B sends a SIP 180 Ringing response to Phone A.
3.	200 OK—Phone B to Phone A	Phone B sends a SIP 200 OK response to Phone A. The response notifies Phone A that the connection has been made. If Phone B supports the media capability advertised in the INVITE message sent by Phone A, it advertises the intersection of its own and Phone A media capability in the 200 OK response. If Phone B does not support the media capability advertised by Phone A, it sends back a 400 Bad Request response with a 304 Warning header field.
4.	ACK—Phone A to Phone B	Phone A sends a SIP ACK to Phone B. The ACK confirms that Phone A has received the 200 OK response from Phone B. The ACK might contain a message body with the final session description to be used by Phone B. If the message body of the ACK is empty, Phone B uses the session description in the INVITE request.
A two-way RTP channel is established between Phone A and Phone B.
5.	INVITE—Phone C to Phone B	Phone C sends a SIP INVITE request to Phone B. The request is an invitation to User B to participate in a call session.
6.	180 Ringing—Phone B to Phone C	Phone B sends a SIP 180 Ringing response to Phone C.
7.	INVITE—Phone B to Phone A	Phone B sends a midcall INVITE to Phone A with new SDP session parameters (IP address), which are used to place the call on hold. Call_ID=1 SDP: c=IN IP4 0.0.0.0 The c= SDP field of the SIP INVITE contains 0.0.0.0. This places the call in hold.
8.	200 OK—Phone A to Phone B	Phone A sends a SIP 200 OK response to Phone B.
9.	ACK—Phone B to Phone A	Phone B sends a SIP ACK to Phone A. The ACK confirms that Phone B has received the 200 OK response from Phone A.
The RTP channel between Phone A and Phone B is torn down.
10.	200 OK—Phone B to Phone C	Phone B sends a SIP 200 OK response to Phone C. The response notifies Phone C that the connection has been made.
11.	ACK—Phone C to Phone B	Phone C sends a SIP ACK to Phone B. The ACK confirms that Phone C has received the 200 OK response from Phone B. The ACK might contain a message body with the final session description to be used by Phone B. If the message body of the ACK is empty, Phone B uses the session description in the INVITE request.
A two-way RTP channel is established between Phone B and Phone C.
12.	INVITE—Phone B to Phone C	Phone B sends a midcall INVITE to Phone C with new SDP session parameters (IP address), which are used to place the call on hold. Call_ID=2 SDP: c=IN IP4 0.0.0.0 To establish the call between Phone B and Phone C, the IP address of Phone B is inserted into the c= SDP field.
13.	200 OK—Phone C to Phone B	Phone C sends a SIP 200 OK response to Phone B.
14.	ACK—Phone B to Phone C	Phone B sends a SIP ACK to Phone C. The ACK confirms that Phone B has received the 200 OK response from Phone C.
The RTP channel between Phone B and Phone C is torn down.
15.	INVITE—Phone B to Phone A	Phone B sends a midcall INVITE to Phone A with the same call ID as the previous INVITE (sent to Phone A) and new SDP session parameters (IP address), which are used to reestablish the call. Call_ID=1 SDP: c=IN IP4 10.10.10.0
16.	200 OK—Phone A to Phone B	Phone A sends a SIP 200 OK response to Phone B.
17.	ACK—Phone B to Phone A	Phone B sends a SIP ACK to Phone A. The ACK confirms that Phone B has received the 200 OK response from Phone A.
A two-way RTP channel is reestablished between Phone A and Phone B.
18.	BYE—Phone B to Phone A	The call continues and then User B hangs up. Phone B sends a SIP BYE request to Phone A. The request indicates that User B wants to release the call.
19.	200 OK—Phone A to Phone B	Phone A sends a SIP 200 OK response to Phone B. The response notifies Phone B that the BYE request has been received. The call session between User A and User B terminates.
The RTP channel between Phone A and Phone B is torn down.
20.	INVITE—Phone B to Phone C	Phone B sends a midcall INVITE to Phone C with the same call ID as the previous INVITE (sent to Phone C) and new SDP session parameters (IP address), which are used to reestablish the call. Call_ID=2 SDP: c=IN IP4 10.10.10.0
21.	200 OK—Phone C to Phone B	Phone C sends a SIP 200 OK response to Phone B.
22.	ACK—Phone B to Phone C	Phone B sends a SIP ACK to Phone C. The ACK confirms that Phone B has received the 200 OK response from Phone A.
A two-way RTP channel is reestablished between Phone B and Phone C.

Call Transfer Without Consultation

Figure B-7 illustrates a successful call between Cisco SIP IP phones in which two parties are in a call and then one of the participants transfers the call to a third party without first contacting the third party. This is called a blind or unattended transfer. In this call flow scenario, the end users are User A, User B, and User C. They are all using Cisco SIP IP phones, which are connected via an IP network.

The call flow scenario is as follows:

1. User A calls User B.

2. User B answers the call.

3. User B transfers the call to User C.

Figure B-7 Call Transfer Without Consultation

Step	Action	Description
1.	INVITE—Phone A to Phone B	Phone A sends a SIP INVITE request to Phone B. The request is an invitation to User B to participate in a call session. In the INVITE request: •The phone number of User B is inserted in the Request-URI field in the form of a SIP URL. The SIP URL identifies the address of User B and takes a form similar to an e-mail address (user@host, where user is the telephone number and host is either a domain name or a numeric network address). For example, the Request-URI field in the INVITE request to User B appears as "INVITE sip:555-0199@companyb.com; user=phone." The "user=phone" parameter distinquishes that the Request-URI address is a telephone number rather than a username. •Phone A is identified as the call session initiator in the From field. •A unique numeric identifier is assigned to the call and is inserted in the Call-ID field. •The transaction number within a single call leg is identified in the CSeq field. •The media capability that User A is ready to receive is specified.
2.	100 Trying—Phone B to Phone A	Phone B sends a SIP 100 Trying response to Phone A. The response indicates that the INVITE request has been received.
3.	180 Ringing—Phone B to Phone A	Phone B sends a SIP 180 Ringing response to Phone A.
4.	200 OK—Phone B to Phone A	Phone B sends a SIP 200 OK response to Phone A. The response notifies Phone A that the connection has been made. If Phone B supports the media capability advertised in the INVITE message sent by Phone A, it advertises the intersection of its own and Phone A's media capability in the 200 OK response. If Phone B does not support the media capability advertised by Phone A, it sends back a 400 Bad Request response with a 304 Warning header field.
5.	ACK—Phone A to Phone B	Phone A sends a SIP ACK to Phone B. The ACK confirms that Phone A has received the 200 OK response from Phone B. The ACK might contain a message body with the final session description to be used by Phone B. If the message body of the ACK is empty, Phone B uses the session description in the INVITE request.
A two-way RTP channel is established between Phone A and Phone B. User B then selects the option to blind transfer the call to User C.
6.	INVITE—Phone B to Phone A	Phone B sends a midcall INVITE to Phone A with new SDP session parameters (IP address), which are used to place the call on hold. Call_ID=1 SDP: c=IN IP4 0.0.0.0 The c= SDP field of the SIP INVITE contains 0.0.0.0. This places the call on hold.
7.	200 OK—Phone A to Phone B	Phone A sends a SIP 200 OK response to Phone B.
8.	ACK—Phone B to Phone A	Phone B sends a SIP ACK to Phone A. The ACK confirms that Phone B has received the 200 OK response from Phone A.
User B dials User C.
9.	REFER—Phone B to Phone A	Phone B sends a REFER message to Phone A. The message contains the following information: •Refer-To: C •Referred-By: B The message indicates that Phone A should send an INVITE request to Phone C.
10.	202 ACCEPTED—Phone A to Phone B	Phone A sends a SIP 202 ACCEPTED message to Phone B. The message confirms that the REFER message has been received.
11.	BYE—Phone B to Phone A	Phone B sends a BYE message to Phone A. The message indicates that Phone B will disconnect from the call.
12.	200 OK—Phone A to Phone B	Phone A sends a SIP 200 OK response to Phone B. The response notifies Phone B that the BYE message was received.
13.	INVITE—Phone A to Phone C	Because of the REFER message from Phone B, Phone A sends a SIP INVITE request to Phone C. The request is an invitation to User C to participate in a call session. The request contains the following information: •Referred-By: B The message indicates that the INVITE was referred by Phone B.
14.	100 Trying—Phone C to Phone A	Phone C sends a SIP 100 Trying response to Phone A. The response indicates that the INVITE request has been received.
15.	180 Ringing—Phone C to Phone A	Phone C sends a SIP 180 Ringing response to Phone A.
16.	200 OK—Phone C to Phone A	Phone C sends a SIP 200 OK response to Phone A. The response notifies Phone A that the connection has been made.
17.	ACK—Phone A to Phone C	Phone A sends a SIP ACK to Phone C. The ACK confirms that Phone A has received the 200 OK response from Phone C.
18.	NOTIFY—Phone A to Phone B	Phone A sends a NOTIFY message to Phone B. The message notifies Phone C of the REFER event.
19.	200 OK—Phone B to Phone A	Phone B sends a SIP 200 OK response to Phone A. The response notifies Phone A that the NOTIFY message was received.
A two-way RTP channel is established between Phone A and Phone C.

Call Transfer Without Consultation Using Failover

Figure B-8 illustrates a successful call between Cisco SIP IP phones in which two parties are in a call and then one of the participants transfers the call to a third party without first contacting the third party. This is called a blind or unattended transfer. In this call flow scenario, the end users are User A, User B, and User C. They are all using Cisco SIP IP phones, which are connected using an IP network.

The call flow scenario is as follows:

1. User A calls User B.

2. User B answers the call.

3. User B transfers the call to User C.

Figure B-8 Call Transfer Without Consultation Using Failover

Step	Action	Description
1.	INVITE—Phone A to Phone B	Phone A sends a SIP INVITE request to Phone B. The request is an invitation to User B to participate in a call session. In the INVITE request: •The phone number of User B is inserted in the Request-URI field in the form of a SIP URL. The SIP URL identifies the address of User B and takes a form similar to an e-mail address (user@host, where user is the telephone number and host is either a domain name or a numeric network address). For example, the Request-URI field in the INVITE request to User B appears as "INVITE sip:555-0199@companyb.com; user=phone." The "user=phone" parameter distinquishes that the Request-URI address is a telephone number rather than a username. •Phone A is identified as the call session initiator in the From field. •A unique numeric identifier is assigned to the call and is inserted in the Call-ID field. •The transaction number within a single call leg is identified in the CSeq field. •The media capability User A is ready to receive is specified.
2.	100 Trying—Phone B to Phone A	Phone B sends a SIP 100 Trying response to Phone A. The response indicates that the INVITE request has been received.
3.	180 Ringing—Phone B to Phone A	Phone B sends a SIP 180 Ringing response to Phone A.
4.	200 OK—Phone B to Phone A	Phone B sends a SIP 200 OK response to Phone A. The response notifies Phone A that the connection has been made. If Phone B supports the media capability advertised in the INVITE message sent by Phone A, it advertises the intersection of its own and Phone A's media capability in the 200 OK response. If Phone B does not support the media capability advertised by Phone A, it sends back a 400 Bad Request response with a 304 Warning header field.
5.	ACK—Phone A to Phone B	Phone A sends a SIP ACK to Phone B. The ACK confirms that Phone A has received the 200 OK response from Phone B. The ACK might contain a message body with the final session description to be used by Phone B. If the message body of the ACK is empty, Phone B uses the session description in the INVITE request.
A two-way RTP channel is established between Phone A and Phone B. User B then selects the option to blind transfer the call to User C.
6.	INVITE—Phone B to Phone A	Phone B sends a midcall INVITE to Phone A with new SDP session parameters (IP address), which are used to place the call on hold. Call_ID=1 SDP: c=IN IP4 0.0.0.0 The c= SDP field of the SIP INVITE contains an 0.0.0.0. This places the call in hold.
7.	200 OK—Phone A to Phone B	<