Table Of Contents
SIP Call Flows
Call Flow Scenarios for Successful Calls
Gateway-to Cisco SIP IP Phone—Successful Call Setup and Disconnect
Gateway-to-Cisco SIP IP Phone—Successful Call Setup and Call Hold
Gateway to-Cisco SIP IP Phone—Successful Call Setup and Call Transfer
Cisco SIP IP Phone-to-Cisco SIP IP Phone Simple Call Hold
Cisco SIP IP Phone-to-Cisco SIP IP Phone Call Hold with Consultation
Cisco SIP IP Phone-to-Cisco SIP IP Phone Call Waiting
Cisco SIP IP Phone-to-Cisco SIP IP Phone Call Transfer without Consultation
Cisco SIP IP Phone-to-Cisco SIP IP Phone Call Transfer with Consultation
Cisco SIP IP Phone-to-Cisco SIP IP Phone Network Call Forwarding (Unconditional)
Cisco SIP IP Phone-to-Cisco SIP IP Phone Network Call Forwarding (Busy)
Cisco SIP IP Phone-to-Cisco SIP IP Phone Network Call Forwarding (No Answer)
Call Flow Scenarios for Failed Calls
Gateway-to-Cisco SIP IP Phone—Called User is Busy
Gateway-to-Cisco SIP IP Phone—Called User Does Not Answer
Gateway-to-Cisco SIP IP Phone—Client, Server, or Global Error
Cisco SIP IP Phone-to-Cisco SIP IP Phone—Called User is Busy
Cisco SIP IP Phone-to-Cisco SIP IP Phone—Called User Does Not Answer
Cisco SIP IP Phone-to-Cisco SIP IP Phone—Authentication Error
SIP Call Flows
SIP uses six request methods:
•
INVITE—Indicates 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 callee.
•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.
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 call flows for the following scenarios, which illustrate successful calls:
•Gateway-to Cisco SIP IP Phone—Successful Call Setup and Disconnect
•Gateway-to-Cisco SIP IP Phone—Successful Call Setup and Call Hold
•Gateway to-Cisco SIP IP Phone—Successful Call Setup and Call Transfer
•Cisco SIP IP Phone-to-Cisco SIP IP Phone Simple Call Hold
•Cisco SIP IP Phone-to-Cisco SIP IP Phone Call Hold with Consultation
•Cisco SIP IP Phone-to-Cisco SIP IP Phone Call Waiting
•Cisco SIP IP Phone-to-Cisco SIP IP Phone Call Transfer without Consultation
•Cisco SIP IP Phone-to-Cisco SIP IP Phone Call Transfer with Consultation
•Cisco SIP IP Phone-to-Cisco SIP IP Phone Network Call Forwarding (Unconditional)
•Cisco SIP IP Phone-to-Cisco SIP IP Phone Network Call Forwarding (Busy)
•Cisco SIP IP Phone-to-Cisco SIP IP Phone Network Call Forwarding (No Answer)
Gateway-to Cisco SIP IP Phone—Successful Call Setup and Disconnect
Figure B-1 illustrates a successful gateway-to-Cisco SIP IP 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 Gateway-to-Cisco SIP IP Phone—Successful Setup and Disconnect
Step
|
Action
|
Description
|
1
|
Setup—PBX A to Gateway 1
|
Call Setup is initiated between PBX A and Gateway 1. The Call 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 Cisco SIP IP phone.
In the INVITE request:
•The IP address of the Cisco SIP IP 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 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 Cisco SIP IP phone sends a SIP 100 Trying response to Gateway 1. The 100 Trying response indicates that the INVITE request has been received by the Cisco SIP IP phone.
|
5
|
180 Ringing—Cisco SIP IP phone to Gateway 1
|
The Cisco SIP IP phone sends a SIP 180 Ringing response to Gateway 1. The 180 Ringing 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 Alert message indicates that Gateway 1 has received a 180 Ringing response from the Cisco SIP IP 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 Cisco SIP IP phone sends a SIP 200 OK response to Gateway 1. The 200 OK 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 Connect 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 Cisco SIP IP 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 at his Cisco SIP IP phone and the phone sends a SIP BYE request to Gateway 1. The BYE 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 Cisco SIP IP phone. The 200 OK 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 is terminated.
|
Gateway-to-Cisco SIP IP Phone—Successful Call Setup and Call Hold
Figure B-2 illustrates a successful gateway-to-Cisco SIP IP 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 Gateway-to-Cisco SIP IP Phone Call—Successful Call Setup and Call Hold
Step
|
Action
|
Description
|
1
|
Setup—PBX A to Gateway 1
|
Call Setup is initiated between PBX A and Gateway 1. The Call 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 Cisco SIP IP phone.
In the INVITE request:
•The IP address of the Cisco SIP IP 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 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 Cisco SIP IP phone sends a SIP 100 Trying response to Gateway 1. The 100 Trying response indicates that the INVITE request has been received by the Cisco SIP IP phone.
|
5
|
180 Ringing—Cisco SIP IP phone to Gateway 1
|
The Cisco SIP IP phone sends a SIP 180 Ringing response to Gateway 1. The 180 Ringing 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 Alert message indicates that Gateway 1 has received a 180 Ringing response from the Cisco SIP IP 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 Cisco SIP IP phone sends a SIP 200 OK response to Gateway 1. The 200 OK 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 Connect 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 Cisco SIP IP 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 Cisco SIP IP 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 Cisco SIP IP phone. The 200 OK response notifies the Cisco SIP IP phone that the INVITE was successfully processed.
|
13
|
ACK—Cisco SIP IP phone to Gateway 1
|
The Cisco SIP IP phone sends a SIP ACK to Gateway 1. The ACK confirms that the Cisco SIP IP 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 Cisco SIP IP 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 Cisco SIP IP phone. The 200 OK response notifies the Cisco SIP IP phone that the INVITE was successfully processed.
|
16
|
ACK—Cisco SIP IP phone to Gateway 1
|
The Cisco SIP IP phone sends a SIP ACK to Gateway 1. The ACK confirms that the Cisco SIP IP phone has received the 200 OK response. The call session is now active.
|
Gateway to-Cisco SIP IP Phone—Successful Call Setup and Call Transfer
Figure B-3 illustrates a successful gateway-to-Cisco SIP IP phone PC call setup and call transfer without consultation. In this scenario, there are three end users: User A, User B, and User C. 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 and is directly connected to the IP network. User C is located at PBX B. PBX B is connected to Gateway 2 (SIP Gateway) via a T1/E1. Gateway 1, Gateway 2, and the Cisco SIP IP phone are connected to one another 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 transfers User A's call to User C and then hangs up.
4. User C answers the call.
Figure B-3 Gateway-to-Cisco SIP IP Phone Call—Successful Call Setup and Call Transfer
Step
|
Action
|
Description
|
1
|
Setup—PBX A to Gateway 1
|
Call Setup is initiated between PBX A and Gateway 1. The Call 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 Cisco SIP IP phone.
In the INVITE request:
•The IP address of the Cisco SIP IP 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 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 Cisco SIP IP phone sends a SIP 100 Trying response to Gateway 1. The 100 Trying response indicates that the INVITE request has been received by the Cisco SIP IP phone.
|
5
|
180 Ringing—Cisco SIP IP phone to Gateway 1
|
The Cisco SIP IP phone sends a SIP 180 Ringing response to Gateway 1. The 180 Ringing 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 Alert message indicates that Gateway 1 has received a 180 Ringing response from the Cisco SIP IP 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 Cisco SIP IP phone sends a SIP 200 OK response to Gateway 1. The 200 OK 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 Connect 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 Cisco SIP IP phone. The ACK confirms that Gateway 1 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
|
BYE—Cisco SIP IP phone to Gateway 1
|
User B transfers User A's call to User C and then hangs up. The Cisco SIP IP phone sends a SIP BYE request to Gateway 1. The SIP BYE request includes the Also header. In this scenario, the Also header indicates that User C needs to be brought into the call while User B hangs up. This header distinguishes the call transfer BYE request from a normal disconnect BYE request.
The Request-By header could be included in the BYE request, however, Cisco's implementation does not require the header to complete the transfer. If the Requested-By header is included, the INVITE sent to the transferred-to party will include the Requested-By header. If the Requested-By header is not included, the INVITE sent to the transferred-to party will not include the Requested-By header.
|
12
|
200 OK—Gateway 1 to Cisco SIP IP phone
|
Gateway 1 sends a SIP 200 OK message to the Cisco SIP IP phone. The 200 OK response notifies the Cisco SIP IP phone that the BYE request has been received. The call session between User A and User B is now terminated.
|
13
|
INVITE—Gateway 1 to Gateway 2
|
Gateway 1 sends a SIP INVITE request to Gateway 2. In the INVITE request, a unique Call-ID is generated and the Requested-By field indicates that User B requested the call.
|
14
|
Setup—Gateway 2 to PBX B
|
Gateway 2 receives the INVITE request from Gateway 1 and initiates a Call Setup with User C via PBX B.
|
15
|
100 Trying—Gateway 2 to Gateway 1
|
Gateway 2 sends a SIP 100 Trying response to the INVITE request sent by Gateway 1. The 100 Trying response indicates that Gateway 2 has received the INVITE request but that User C has not yet been located.
|
16
|
Call Proceeding—PBX B to Gateway 2
|
PBX B sends a Call Proceeding message to Gateway 2. User C's phone begins to ring.
|
17
|
Alerting—PBX B to Gateway 2
|
PBX B sends an Alert message to Gateway 2.
|
18
|
180 Ringing—Gateway 2 to Gateway 1
|
Gateway 2 sends a SIP 180 Ringing response to Gateway 1. The 180 Ringing response indicates that Gateway 2 has located, and is trying to alert, User C.
|
19
|
Connect—PBX B to Gateway 2
|
User C answers the phone. PBX B sends a Connect message to Gateway 2. The Connect message notifies Gateway 2 that the connection has been made.
|
20
|
200 OK—Gateway 2 to Gateway 1
|
Gateway 2 sends a SIP 200 OK response to Gateway 1. The 200 OK response notifies Gateway 1 that the connection has been made.
If User C supports the media capability advertised in the INVITE message sent by User A, it advertises the intersection of its own and User A's media capability in the 200 OK response. If User C does not support the media capability advertised by User A, it sends back a 400 Bad Request response with a 304 Warning header field.
|
21
|
Connect ACK—Gateway 2 to PBX B
|
Gateway 2 acknowledges PBX B's Connect message.
|
22
|
ACK—Gateway 1 to Gateway 2
|
Gateway 1 sends a SIP ACK to Gateway 2. The ACK confirms that Gateway 1 has received the 200 OK message from Gateway 2.
|
Cisco SIP IP Phone-to-Cisco SIP IP Phone 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 Cisco SIP IP Phone-to-Cisco SIP IP Phone Simple Call Hold
Step
|
Action
|
Description
|
1
|
INVITE—Cisco SIP IP phone A to Cisco SIP IP phone B
|
Cisco SIP IP phone A sends a SIP INVITE request to Cisco SIP IP phone B. The INVITE 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 email 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-0002@companyb.com; user=phone." The "user=phone" parameter distinquishes that the Request-URI address is a telephone number rather than a user name.
•Cisco SIP IP 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—Cisco SIP IP phone B to Cisco SIP IP phone A
|
Cisco SIP IP phone B sends a SIP 180 Ringing response to Cisco SIP IP phone A.
|
3
|
200 OK—Cisco SIP IP phone B to Cisco SIP IP phone A
|
Cisco SIP IP phone B sends a SIP 200 OK response to Cisco SIP IP phone A. The 200 OK response notifies Cisco SIP IP phone A that the connection has been made.
If Cisco SIP IP phone B supports the media capability advertised in the INVITE message sent by Cisco SIP IP phone A, it advertises the intersection of its own and Cisco SIP IP phone A's media capability in the 200 OK response. If Cisco SIP IP phone B does not support the media capability advertised by Cisco SIP IP phone A, it sends back a 400 Bad Request response with a 304 Warning header field.
|
4
|
ACK—Cisco SIP IP phone A to Cisco SIP IP phone B
|
Cisco SIP IP phone A sends a SIP ACK to Cisco SIP IP phone B. The ACK confirms that Cisco SIP IP phone A has received the 200 OK response from Cisco SIP IP phone B.
The ACK might contain a message body with the final session description to be used by Cisco SIP IP phone B. If the message body of the ACK is empty, Cisco SIP IP phone B uses the session description in the INVITE request.
|
A two-way RTP channel is established between Cisco SIP IP phone A and Cisco SIP IP phone B.
|
5
|
INVITE—Cisco SIP IP phone B to Cisco SIP IP phone A
|
Cisco SIP IP phone B sends a mid-call INVITE to Cisco SIP IP phone A with new SDP session parameters (IP address), which are used to place the call on hold.
|
6
|
200 OK—Cisco SIP IP phone A to Cisco SIP IP phone B
|
Cisco SIP IP phone A sends a SIP 200 OK response to Cisco SIP IP phone B.
|
7
|
ACK—Cisco SIP IP phone B to Cisco SIP IP phone A
|
Cisco SIP IP phone B sends a SIP ACK to Cisco SIP IP phone A. The ACK confirms that Cisco SIP IP phone B has received the 200 OK response from Cisco SIP IP phone A.
|
The RTP channel between Cisco SIP IP phone A and Cisco SIP IP phone B is torn down.
|
8
|
INVITE—Cisco SIP IP phone B to Cisco SIP IP phone A
|
Cisco SIP IP phone B sends a mid-call INVITE to Cisco SIP IP 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.
SDP: c=IN IP4 181.23.250.2
|
9
|
200 OK—Cisco SIP IP phone A to Cisco SIP IP phone B
|
Cisco SIP IP phone A sends a SIP 200 OK response to Cisco SIP IP phone B.
|
10
|
ACK—Cisco SIP IP phone B to Cisco SIP IP phone A
|
Cisco SIP IP phone B sends a SIP ACK to Cisco SIP IP phone A. The ACK confirms that Cisco SIP IP phone B has received the 200 OK response from Cisco SIP IP phone A.
|
A two-way RTP channel is reestablished between IP phone A and IP phone B.
|
Cisco SIP IP Phone-to-Cisco SIP IP Phone 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 Cisco SIP IP Phone-to-Cisco SIP IP Phone Call Hold with Consultation
Step
|
Action
|
Description
|
1
|
INVITE—Cisco SIP IP phone A to Cisco SIP IP phone B
|
Cisco SIP IP phone A sends a SIP INVITE request to Cisco SIP IP phone B. The INVITE 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 email 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-0002@companyb.com; user=phone." The "user=phone" parameter distinquishes that the Request-URI address is a telephone number rather than a user name.
•Cisco SIP IP 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—Cisco SIP IP phone B to Cisco SIP IP phone A
|
Cisco SIP IP phone B sends a SIP 180 Ringing response to Cisco SIP IP phone A.
|
3
|
200 OK—Cisco SIP IP phone B to Cisco SIP IP phone A
|
Cisco SIP IP phone B sends a SIP 200 OK response to Cisco SIP IP phone A. The 200 OK response notifies Cisco SIP IP phone A that the connection has been made.
If Cisco SIP IP phone B supports the media capability advertised in the INVITE message sent by Cisco SIP IP phone A, it advertises the intersection of its own and Cisco SIP IP phone A's media capability in the 200 OK response. If Cisco SIP IP phone B does not support the media capability advertised by Cisco SIP IP phone A, it sends back a 400 Bad Request response with a 304 Warning header field.
|
4
|
ACK—Cisco SIP IP phone A to Cisco SIP IP phone B
|
Cisco SIP IP phone A sends a SIP ACK to Cisco SIP IP phone B. The ACK confirms that Cisco SIP IP phone A has received the 200 OK response from Cisco SIP IP phone B.
The ACK might contain a message body with the final session description to be used by Cisco SIP IP phone B. If the message body of the ACK is empty, Cisco SIP IP phone B uses the session description in the INVITE request.
|
A two-way RTP channel is established between Cisco SIP IP phone A and Cisco SIP IP phone B.
|
5
|
INVITE—Cisco SIP IP phone B to Cisco SIP IP phone A
|
Cisco SIP IP phone B sends a mid-call INVITE to Cisco SIP IP phone A with new SDP session parameters (IP address), which are used to place the call on hold.
|
6
|
200 OK—Cisco SIP IP phone A to Cisco SIP IP phone B
|
Cisco SIP IP phone A sends a SIP 200 OK response to Cisco SIP IP phone B.
|
7
|
ACK—Cisco SIP IP phone B to Cisco SIP IP phone A
|
Cisco SIP IP phone B sends a SIP ACK to Cisco SIP IP phone A. The ACK confirms that Cisco SIP IP phone B has received the 200 OK response from Cisco SIP IP phone A.
|
The RTP channel between Cisco SIP IP phone A and Cisco SIP IP phone B is torn down.
|
8
|
INVITE—Cisco SIP IP phone B to Cisco SIP IP phone C
|
Cisco SIP IP phone B sends a SIP INVITE request to Cisco SIP IP phone C. The INVITE request is an invitation to User C to participate in a call session.
|
9
|
180 Ringing—Cisco SIP IP phone C to Cisco SIP IP phone B
|
Cisco SIP IP phone C sends a SIP 180 Ringing response to Cisco SIP IP phone B.
|
10
|
200 OK—Cisco SIP IP phone C to Cisco SIP IP phone B
|
Cisco SIP IP phone C sends a SIP 200 OK response to Cisco SIP IP phone B. The 200 OK response notifies Cisco SIP IP phone B that the connection has been made.
If Cisco SIP IP phone B supports the media capability advertised in the INVITE message sent by Cisco SIP IP phone A, it advertises the intersection of its own and Cisco SIP IP phone A's media capability in the 200 OK response. If Cisco SIP IP phone B does not support the media capability advertised by Cisco SIP IP phone A, it sends back a 400 Bad Request response with a 304 Warning header field.
|
11
|
ACK—Cisco SIP IP phone B to Cisco SIP IP phone C
|
Cisco SIP IP phone B sends a SIP ACK to Cisco SIP IP phone C. The ACK confirms that Cisco SIP IP phone B has received the 200 OK response from Cisco SIP IP phone C.
The ACK might contain a message body with the final session description to be used by Cisco SIP IP phone C. If the message body of the ACK is empty, Cisco SIP IP phone C uses the session description in the INVITE request.
|
A two-way RTP channel is established between Cisco SIP IP phone B and Cisco SIP IP phone C.
|
12
|
BYE—Cisco SIP IP phone B to Cisco SIP IP phone C
|
The call continues and then User B hangs up. Cisco SIP IP phone B sends a SIP BYE request to Cisco SIP IP phone C. The BYE request indicates that User B wants to release the call.
|
13
|
200 OK—Cisco SIP IP phone C to Cisco SIP IP phone B
|
Cisco SIP IP phone C sends a SIP 200 OK message to Cisco SIP IP phone B. The 200 OK response notifies Cisco SIP IP phone B that the BYE request has been received. The call session between User A and User B is now terminated.
|
The RTP channel between Cisco SIP IP phone B and Cisco SIP IP phone C is torn down.
|
14
|
INVITE—Cisco SIP IP phone B to Cisco SIP IP phone A
|
Cisco SIP IP phone B sends a mid-call INVITE to Cisco SIP IP 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.
SDP: c=IN IP4 181.23.250.2
|
15
|
200 OK—Cisco SIP IP phone A to Cisco SIP IP phone B
|
Cisco SIP IP phone A sends a SIP 200 OK response to Cisco SIP IP phone B.
|
16
|
ACK—Cisco SIP IP phone B to Cisco SIP IP phone A
|
Cisco SIP IP phone B sends a SIP ACK to Cisco SIP IP phone A. The ACK confirms that Cisco SIP IP phone B has received the 200 OK response from Cisco SIP IP phone A.
|
A two-way RTP channel is reestablished between Cisco SIP IP phone A and Cisco SIP IP phone B.
|
Cisco SIP IP Phone-to-Cisco SIP IP Phone Call Waiting
Figure B-6 illustrates a successful call between Cisco SIP IP phones in which two parties are in a call, 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 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 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 Cisco SIP IP Phone-to-Cisco SIP IP Phone Call Waiting
Step
|
Action
|
Description
|
1
|
INVITE—Cisco SIP IP phone A to Cisco SIP IP phone B
|
Cisco SIP IP phone A sends a SIP INVITE request to Cisco SIP IP phone B. The INVITE 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 email 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-0002@companyb.com; user=phone." The "user=phone" parameter distinquishes that the Request-URI address is a telephone number rather than a user name.
•Cisco SIP IP 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—Cisco SIP IP phone B to Cisco SIP IP phone A
|
Cisco SIP IP phone B sends a SIP 180 Ringing response to Cisco SIP IP phone A.
|
3
|
200 OK—Cisco SIP IP phone B to Cisco SIP IP phone A
|
Cisco SIP IP phone B sends a SIP 200 OK response to Cisco SIP IP phone A. The 200 OK response notifies Cisco SIP IP phone A that the connection has been made.
If Cisco SIP IP phone B supports the media capability advertised in the INVITE message sent by Cisco SIP IP phone A, it advertises the intersection of its own and Cisco SIP IP phone A's media capability in the 200 OK response. If Cisco SIP IP phone B does not support the media capability advertised by Cisco SIP IP phone A, it sends back a 400 Bad Request response with a 304 Warning header field.
|
4
|
ACK—Cisco SIP IP phone A to Cisco SIP IP phone B
|
Cisco SIP IP phone A sends a SIP ACK to Cisco SIP IP phone B. The ACK confirms that Cisco SIP IP phone A has received the 200 OK response from Cisco SIP IP phone B.
The ACK might contain a message body with the final session description to be used by Cisco SIP IP phone B. If the message body of the ACK is empty, Cisco SIP IP phone B uses the session description in the INVITE request.
|
A two-way RTP channel is established between Cisco SIP IP phone A and Cisco SIP IP phone B.
|
5
|
INVITE—Cisco SIP IP phone C to Cisco SIP IP phone B
|
Cisco SIP IP phone C sends a SIP INVITE request to Cisco SIP IP phone B. The INVITE request is an invitation to User B to participate in a call session.
|
6
|
180 Ringing—Cisco SIP IP phone B to Cisco SIP IP phone C
|
Cisco SIP IP phone B sends a SIP 180 Ringing response to Cisco SIP IP phone C.
|
7
|
INVITE—Cisco SIP IP phone B to Cisco SIP IP phone A
|
Cisco SIP IP phone B sends a mid-call INVITE to Cisco SIP IP phone A with new SDP session parameters (IP address), which are used to place the call on hold.
|
8
|
200 OK—Cisco SIP IP phone A to Cisco SIP IP phone B
|
Cisco SIP IP phone A sends a SIP 200 OK response to Cisco SIP IP phone B.
|
9
|
ACK—Cisco SIP IP phone B to Cisco SIP IP phone A
|
Cisco SIP IP phone B sends a SIP ACK to Cisco SIP IP phone A. The ACK confirms that Cisco SIP IP phone B has received the 200 OK response from Cisco SIP IP phone A.
|
The RTP channel between Cisco SIP IP phone A and Cisco SIP IP phone B is torn down.
|
10
|
200 OK—Cisco SIP IP phone B to Cisco SIP IP phone C
|
Cisco SIP IP phone B sends a SIP 200 OK response to Cisco SIP IP phone C. The 200 OK response notifies Cisco SIP IP phone C that the connection has been made.
|
11
|
ACK—Cisco SIP IP phone C to Cisco SIP IP phone B
|
Cisco SIP IP phone C sends a SIP ACK to Cisco SIP IP phone B. The ACK confirms that Cisco SIP IP phone C has received the 200 OK response from Cisco SIP IP phone B.
The ACK might contain a message body with the final session description to be used by Cisco SIP IP phone B. If the message body of the ACK is empty, Cisco SIP IP phone B uses the session description in the INVITE request.
|
A two-way RTP channel is established between Cisco SIP IP phone B and Cisco SIP IP phone C.
|
12
|
INVITE—Cisco SIP IP phone B to Cisco SIP IP phone C
|
Cisco SIP IP phone B sends a mid-call INVITE to Cisco SIP IP phone C with new SDP session parameters (IP address), which are used to place the call on hold.
|
13
|
200 OK—Cisco SIP IP phone C to Cisco SIP IP phone B
|
Cisco SIP IP phone C sends a SIP 200 OK response to Cisco SIP IP phone B.
|
14
|
ACK—Cisco SIP IP phone B to Cisco SIP IP phone C
|
Cisco SIP IP phone B sends a SIP ACK to Cisco SIP IP phone C. The ACK confirms that Cisco SIP IP phone B has received the 200 OK response from Cisco SIP IP phone C.
|
The RTP channel between Cisco SIP IP phone B and Cisco SIP IP phone C is torn down.
|
15
|
INVITE—Cisco SIP IP phone B to Cisco SIP IP phone A
|
Cisco SIP IP phone B sends a mid-call INVITE to Cisco SIP IP phone A with the same call ID as the previous INVITE (sent to Cisco SIP IP phone A) and new SDP session parameters (IP address), which are used to reestablish the call.
SDP: c=IN IP4 181.23.250.2
|
16
|
200 OK—Cisco SIP IP phone A to Cisco SIP IP phone B
|
Cisco SIP IP phone A sends a SIP 200 OK response to Cisco SIP IP phone B.
|
17
|
ACK—Cisco SIP IP phone B to Cisco SIP IP phone A
|
Cisco SIP IP phone B sends a SIP ACK to Cisco SIP IP phone A. The ACK confirms that Cisco SIP IP phone B has received the 200 OK response from Cisco SIP IP phone A.
|
A two-way RTP channel is reestablished between Cisco SIP IP phone A and Cisco SIP IP phone B.
|
18
|
BYE—Cisco SIP IP phone B to Cisco SIP IP phone A
|
The call continues and then User B hangs up. Cisco SIP IP phone B sends a SIP BYE request to Cisco SIP IP phone A. The BYE request indicates that User B wants to release the call.
|
19
|
200 OK—Cisco SIP IP phone A to Cisco SIP IP phone B
|
Cisco SIP IP phone A sends a SIP 200 OK message to Cisco SIP IP phone B. The 200 OK response notifies Cisco SIP IP phone B that the BYE request has been received. The call session between User A and User B is now terminated.
|
The RTP channel between Cisco SIP IP phone A and Cisco SIP IP phone B is torn down.
|
14
|
INVITE—Cisco SIP IP phone B to Cisco SIP IP phone C
|
Cisco SIP IP phone B sends a mid-call INVITE to Cisco SIP IP phone C with the same call ID as the previous INVITE (sent to Cisco SIP IP phone C) and new SDP session parameters (IP address), which are used to reestablish the call.
SDP: c=IN IP4 181.23.250.2
|
15
|
200 OK—Cisco SIP IP phone C to Cisco SIP IP phone B
|
Cisco SIP IP phone C sends a SIP 200 OK response to Cisco SIP IP phone B.
|
16
|
ACK—Cisco SIP IP phone B to Cisco SIP IP phone C
|
Cisco SIP IP phone B sends a SIP ACK to Cisco SIP IP phone C. The ACK confirms that Cisco SIP IP phone B has received the 200 OK response from Cisco SIP IP phone A.
|
A two-way RTP channel is reestablished between Cisco SIP IP phone B and Cisco SIP IP phone C.
|
Cisco SIP IP Phone-to-Cisco SIP IP Phone 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 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 Cisco SIP IP Phone-to-Cisco SIP IP Phone Call Transfer without Consultation
Step
|
Action
|
Description
|
1
|
INVITE—Cisco SIP IP phone A to Cisco SIP IP phone B
|
Cisco SIP IP phone A sends a SIP INVITE request to Cisco SIP IP phone B. The INVITE 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 email 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-0002@companyb.com; user=phone." The "user=phone" parameter distinquishes that the Request-URI address is a telephone number rather than a user name.
•Cisco SIP IP 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—Cisco SIP IP phone B to Cisco SIP IP phone A
|
Cisco SIP IP phone B sends a SIP 180 Ringing response to Cisco SIP IP phone A.
|
3
|
200 OK—Cisco SIP IP phone B to Cisco SIP IP phone A
|
Cisco SIP IP phone B sends a SIP 200 OK response to Cisco SIP IP phone A. The 200 OK response notifies Cisco SIP IP phone A that the connection has been made.
If Cisco SIP IP phone B supports the media capability advertised in the INVITE message sent by Cisco SIP IP phone A, it advertises the intersection of its own and Cisco SIP IP phone A's media capability in the 200 OK response. If Cisco SIP IP phone B does not support the media capability advertised by Cisco SIP IP phone A, it sends back a 400 Bad Request response with a 304 Warning header field.
|
4
|
ACK—Cisco SIP IP phone A to Cisco SIP IP phone B
|
Cisco SIP IP phone A sends a SIP ACK to Cisco SIP IP phone B. The ACK confirms that Cisco SIP IP phone A has received the 200 OK response from Cisco SIP IP phone B.
The ACK might contain a message body with the final session description to be used by Cisco SIP IP phone B. If the message body of the ACK is empty, Cisco SIP IP phone B uses the session description in the INVITE request.
|
A two-way RTP channel is established between Cisco SIP IP phone A and Cisco SIP IP phone B.
User B then selects the option to transfer the call to User C.
|
5
|
BYE—Cisco SIP IP phone B to Cisco SIP IP phone A
|
The call continues and then User B hangs up. Cisco SIP IP phone B sends a SIP BYE request to Cisco SIP IP phone A.
The SIP BYE request includes the Also header. The Also header indicates that User C needs to be brought into the call while User B hangs up. The header distinguishes the call transfer BYE request from a normal disconnect BYE disconnect BYE request.
|
6
|
200 OK—Cisco SIP IP phone A to Cisco SIP IP phone B
|
Cisco SIP IP phone A sends a SIP 200 OK message to Cisco SIP IP phone B. The 200 OK response notifies Cisco SIP IP phone B that the BYE request has been received. The call session between User A and User B is now terminated.
|
The RTP channel between Cisco SIP IP phone A and Cisco SIP IP phone B is torn down.
|
7
|
INVITE—Cisco SIP IP phone A to Cisco SIP IP phone C (Requested by Cisco SIP IP phone B)
|
At the request of Cisco SIP IP phone B, Cisco SIP IP phone A sends a SIP INVITE request to Cisco SIP IP phone C. The INVITE request is an invitation to User C to participate in a call session.
|
8
|
180 Ringing—Cisco SIP IP phone C to Cisco SIP IP phone A
|
Cisco SIP IP phone C sends a SIP 180 Ringing response to Cisco SIP IP phone A.
|
9
|
200 OK—Cisco SIP IP phone C to Cisco SIP IP phone A
|
Cisco SIP IP phone C sends a SIP 200 OK response to Cisco SIP IP phone A. The 200 OK response notifies Cisco SIP IP phone A that the connection has been made.
|
10
|
ACK—Cisco SIP IP phone A to Cisco SIP IP phone C
|
Cisco SIP IP phone A sends a SIP ACK to Cisco SIP IP phone C. The ACK confirms that Cisco SIP IP phone A has received the 200 OK response from Cisco SIP IP phone C.
|
A two-way RTP channel is established between Cisco SIP IP phone A and Cisco SIP IP phone C.
|
Cisco SIP IP Phone-to-Cisco SIP IP Phone Call Transfer with Consultation
Figure B-8 illustrates a successful call between Cisco SIP IP phones in which two parties are in a call, one of the participants contacts a third party, and then that participant transfers the call to the third party. This is called an attended 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 calls User C and User C consents to take the call.
4. User B transfers the call to User C.
Figure B-8 Cisco SIP IP Phone-to-Cisco SIP IP Phone Call Transfer with Consultation
Step
|
Action
|
Description
|
1
|
INVITE—Cisco SIP IP phone A to Cisco SIP IP phone B
|
Cisco SIP IP phone A sends a SIP INVITE request to Cisco SIP IP phone B. The INVITE 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 email 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-0002@companyb.com; user=phone." The "user=phone" parameter distinquishes that the Request-URI address is a telephone number rather than a user name.
•Cisco SIP IP 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—Cisco SIP IP phone B to Cisco SIP IP phone A
|
Cisco SIP IP phone B sends a SIP 180 Ringing response to Cisco SIP IP phone A.
|
3
|
200 OK—Cisco SIP IP phone B to Cisco SIP IP phone A
|
Cisco SIP IP phone B sends a SIP 200 OK response to Cisco SIP IP phone A. The 200 OK response notifies Cisco SIP IP phone A that the connection has been made.
If Cisco SIP IP phone B supports the media capability advertised in the INVITE message sent by Cisco SIP IP phone A, it advertises the intersection of its own and Cisco SIP IP phone A's media capability in the 200 OK response. If Cisco SIP IP phone B does not support the media capability advertised by Cisco SIP IP phone A, it sends back a 400 Bad Request response with a 304 Warning header field.
|
4
|
ACK—Cisco SIP IP phone A to Cisco SIP IP phone B
|
Cisco SIP IP phone A sends a SIP ACK to Cisco SIP IP phone B. The ACK confirms that Cisco SIP IP phone A has received the 200 OK response from Cisco SIP IP phone B.
The ACK might contain a message body with the final session description to be used by Cisco SIP IP phone B. If the message body of the ACK is empty, Cisco SIP IP phone B uses the session description in the INVITE request.
|
A two-way RTP channel is established between Cisco SIP IP phone A and Cisco SIP IP phone B.
User B then selects the option to transfer the call to User C.
|
5
|
INVITE—Cisco SIP IP phone B to Cisco SIP IP phone A
|
Cisco SIP IP phone B sends a mid-call INVITE to Cisco SIP IP phone A with new SDP session parameters (IP address), which are used to place the call on hold.
|
6
|
200 OK—Cisco SIP IP phone A to Cisco SIP IP phone B
|
Cisco SIP IP phone A sends a SIP 200 OK response to Cisco SIP IP phone B.
|
7
|
ACK—Cisco SIP IP phone B to Cisco SIP IP phone A
|
Cisco SIP IP phone B sends a SIP ACK to Cisco SIP IP phone A. The ACK confirms that Cisco SIP IP phone B has received the 200 OK response from Cisco SIP IP phone A.
|
The RTP channel between Cisco SIP IP phone A and Cisco SIP IP phone B is torn down.
|
8
|
INVITE—Cisco SIP IP phone B to Cisco SIP IP phone C
|
Cisco SIP IP phone B sends a SIP INVITE request to Cisco SIP IP phone C. The INVITE request is an invitation to User C to participate in a call session.
|
9
|
180 Ringing—Cisco SIP IP phone C to Cisco SIP IP phone B
|
Cisco SIP IP phone C sends a SIP 180 Ringing response to Cisco SIP IP phone B.
|
10
|
200 OK—Cisco SIP IP phone C to Cisco SIP IP phone B
|
Cisco SIP IP phone C sends a SIP 200 OK response to Cisco SIP IP phone B. The 200 OK response notifies Cisco SIP IP phone B that the connection has been made.
If Cisco SIP IP phone B supports the media capability advertised in the INVITE message sent by Cisco SIP IP phone A, it advertises the intersection of its own and Cisco SIP IP phone A's media capability in the 200 OK response. If Cisco SIP IP phone B does not support the media capability advertised by Cisco SIP IP phone A, it sends back a 400 Bad Request response with a 304 Warning header field.
|
11
|
ACK—Cisco SIP IP phone B to Cisco SIP IP phone C
|
Cisco SIP IP phone B sends a SIP ACK to Cisco SIP IP phone C. The ACK confirms that Cisco SIP IP phone B has received the 200 OK response from Cisco SIP IP phone C.
The ACK might contain a message body with the final session description to be used by Cisco SIP IP phone C. If the message body of the ACK is empty, Cisco SIP IP phone C uses the session description in the INVITE request.
|
A two-way RTP channel is established between Cisco SIP IP phone B and Cisco SIP IP phone C.
|
12
|
BYE—Cisco SIP IP phone B to Cisco SIP IP phone C
|
The call continues and then User B hangs up. Cisco SIP IP phone B sends a SIP BYE request to Cisco SIP IP phone C. The BYE request indicates that User B wants to release the call.
|
13
|
200 OK—Cisco SIP IP phone C to Cisco SIP IP phone B
|
Cisco SIP IP phone C sends a SIP 200 OK message to Cisco SIP IP phone B. The 200 OK response notifies Cisco SIP IP phone B that the BYE request has been received. The call session between User A and User B is now terminated.
|
The RTP channel between Cisco SIP IP phone B and Cisco SIP IP phone C is torn down.
|
14
|
BYE—Cisco SIP IP phone B to Cisco SIP IP phone A
|
The call continues and then User B hangs up. Cisco SIP IP phone B sends a SIP BYE request to Cisco SIP IP phone A.
The SIP BYE request includes the Also header. The Also header indicates that User C needs to be brought into the call while User B hangs up. The header distinguishes the call transfer BYE request from a normal disconnect BYE disconnect BYE request.
|
15
|
200 OK—Cisco SIP IP phone A to Cisco SIP IP phone B
|
Cisco SIP IP phone A sends a SIP 200 OK message to Cisco SIP IP phone B. The 200 OK response notifies Cisco SIP IP phone B that the BYE request has been received. The call session between User A and User B is now terminated.
|
The RTP channel between Cisco SIP IP phone A and Cisco SIP IP phone B is torn down.
|
16
|
INVITE—Cisco SIP IP phone A to Cisco SIP IP phone C (Requested by Cisco SIP IP phone B)
|
At the request of Cisco SIP IP phone B, Cisco SIP IP phone A sends a SIP INVITE request to Cisco SIP IP phone C. The INVITE request is an invitation to User C to participate in a call session.
|
17
|
180 Ringing—Cisco SIP IP phone C to Cisco SIP IP phone A
|
Cisco SIP IP phone C sends a SIP 180 Ringing response to Cisco SIP IP phone A.
|
18
|
200 OK—Cisco SIP IP phone C to Cisco SIP IP phone A
|
Cisco SIP IP phone C sends a SIP 200 OK response to Cisco SIP IP phone A. The 200 OK response notifies Cisco SIP IP phone A that the connection has been made.
|
19
|
ACK—Cisco SIP IP phone A to Cisco SIP IP phone C
|
Cisco SIP IP phone A sends a SIP ACK to Cisco SIP IP phone C. The ACK confirms that Cisco SIP IP phone A has received the 200 OK response from Cisco SIP IP phone C.
|
A two-way RTP channel is established between Cisco SIP IP phone A and Cisco SIP IP phone C.
|
Cisco SIP IP Phone-to-Cisco SIP IP Phone Network Call Forwarding (Unconditional)
Figure B-9 illustrates successful call forwarding between Cisco SIP IP phones in which User B has requested unconditional call forwarding from the network. When User A calls User B, the call is immediately transferred to Cisco SIP IP phone C. 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 B requests that the network forward all calls to Cisco SIP IP phone C.
2. User A calls User B.
3. The network transfers the call to Cisco SIP IP phone C.
Figure B-9 Cisco SIP IP Phone-to-Cisco SIP IP Phone Network Call Forwarding (Unconditional)
Step
|
Action
|
Description
|
1
|
INVITE—Cisco SIP IP phone A to SIP proxy server
|
Cisco SIP IP phone A sends a SIP INVITE request to the SIP proxy server. The INVITE 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 email 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-0002@companyb.com; user=phone." The "user=phone" parameter distinquishes that the Request-URI address is a telephone number rather than a user name.
•Cisco SIP IP 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 i |
