cc/td/doc/product/voice/c_ipphon/english/ipp7960/addprot/sip/admin
hometocprevnextglossaryfeedbacksearchhelp
PDF

Table of Contents

SIP Call Flows
Call Flow Scenarios for Successful Calls
Call Flow Scenarios for Failed Calls

SIP Call Flows


This chapter includes the following sections:

SIP uses the following request methods:

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

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

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.

Cisco SIP IP Phone-to-Cisco SIP IP Phone Simple Call Hold

Figure B-3 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-3   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 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-0002@companyb.com; user=phone." The "user=phone" parameter distinquishes that the Request-URI address is a telephone number rather than a username.
  • 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 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—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.

Call_ID=1 
SDP: c=IN IP4 181.23.250.2

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—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-4 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-4   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 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-0002@companyb.com; user=phone." The "user=phone" parameter distinquishes that the Request-URI address is a telephone number rather than a username.
  • 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.

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—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.

Call_ID=1 
SDP: c=IN IP4 181.23.250.2

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—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-5 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-5   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 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-0002@companyb.com; user=phone." The "user=phone" parameter distinquishes that the Request-URI address is a telephone number rather than a username.
  • 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.

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—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.

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—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.

Call_ID=1 
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.

20.

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.

Call_ID=2 
SDP: c=IN IP4 181.23.250.2

 

21.

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.

22.

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-6 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-6   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 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-0002@companyb.com; user=phone." The "user=phone" parameter distinquishes that the Request-URI address is a telephone number rather than a username.
  • 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.

100 Trying—Cisco SIP IP phone B to Cisco SIP IP phone A

The Cisco SIP IP phone B sends a SIP 100 Trying response to Cisco SIP IP phone A. The 100 Trying response indicates that the INVITE request has been received by Cisco SIP IP phone B.

3.

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.

4.

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.

5.

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 blind transfer the call to User C.

6.

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.

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—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.

8.

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.

User B dials User C.

9.

REFER—Cisco SIP IP phone B to Cisco SIP IP phone A

Cisco SIP IP phone B sends a REFER message to Cisco SIP IP phone A. The REFER message contains the following information:

  • Refer-To: C
  • Referred-By: B

The REFER message indicates that Cisco SIP IP phone A should send an INVITE request to Cisco SIP IP phone C.

10.

202 ACCEPTED—Cisco SIP IP phone A to Cisco SIP IP phone B

Cisco SIP IP phone A sends a SIP 202 ACCEPTED message to Cisco SIP IP phone B. The 202 ACCEPTED confirms that the REFER message has been received.

11.

BYE—Cisco SIP IP phone B to Cisco SIP IP phone A

Cisco SIP IP phone B sends a BYE message to Cisco SIP IP phone A. This message indicates that Cisco SIP IP phone B will be disconnecting from the call.

12.

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. The 200 OK response notifies Cisco SIP IP phone B that the BYE message was received.

13.

INVITE—Cisco SIP IP phone A to Cisco SIP IP phone C

Because of the REFER message from 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. The INVITE request contains the following information:

  • Referred-By: B

This message indicates that the INVITE was referred by Cisco SIP IP phone B.

14.

100 Trying—Cisco SIP IP phone C to Cisco SIP IP phone A

The Cisco SIP IP phone C sends a SIP 100 Trying response to Cisco SIP IP phone A. The 100 Trying response indicates that the INVITE request has been received by Cisco SIP IP phone C.

15.

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.

16.

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.

17.

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.

18.

NOTIFY—Cisco SIP IP phone A to Cisco SIP IP phone B

Cisco SIP IP phone A sends a NOTIFY message to Cisco SIP IP phone B. The NOTIFY message notifies Cisco SIP IP phone C of the REFER event.

19.

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 NOTIFY message was received.

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 Without Consultation Using Failover to Bye/Also

Figure B-6 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   Cisco SIP IP Phone-to-Cisco SIP IP Phone Call Transfer without Consultation Using Bye/Also


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 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-0002@companyb.com; user=phone." The "user=phone" parameter distinquishes that the Request-URI address is a telephone number rather than a username.
  • 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.

100 Trying—Cisco SIP IP phone B to Cisco SIP IP phone A

The Cisco SIP IP phone B sends a SIP 100 Trying response to Cisco SIP IP phone A. The 100 Trying response indicates that the INVITE request has been received by Cisco SIP IP phone B.

3.

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.

4.

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.

5.

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 blind transfer the call to User C.

6.

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.

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—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.

8.

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.

User B dials User C.

9.

REFER—Cisco SIP IP phone B to Cisco SIP IP phone A

Cisco SIP IP phone B sends a REFER message to Cisco SIP IP phone A. The REFER message contains the following information:

  • Refer-To: C
  • Referred-By: B

The REFER message indicates that Cisco SIP IP phone A should send an INVITE request to Cisco SIP IP phone C.

10.

501 Not Implemented—
Cisco SIP IP Phone A to Cisco SIP IP phone B

Cisco SIP IP phone A sends a 501 Not Implemented message to Cisco SIP IP phone B. This message indicates that the REFER message is not supported and that Cisco SIP IP phone B should failover to Bye/Also.

11.

BYE—Cisco SIP IP phone B to Cisco SIP IP phone A

Cisco SIP IP phone B sends a BYE message to Cisco SIP IP phone A. The BYE message includes the following information:

  • Also: C

This message indicates that the 501 Not Implemented message was received in response to a REFER message.

12.

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. The 200 OK response notifies Cisco SIP IP phone B that the BYE message was received.

13.

INVITE—Cisco SIP IP phone A to Cisco SIP IP phone C

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. The INVITE request contains the following information:

  • Requested-By: B

This message indicates that the INVITE was requested by Cisco SIP IP phone B.

14.

100 Trying—Cisco SIP IP phone C to Cisco SIP IP phone A

The Cisco SIP IP phone C sends a SIP 100 Trying response to Cisco SIP IP phone A. The 100 Trying response indicates that the INVITE request has been received by Cisco SIP IP phone C.

15.

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.

16.

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.

17.

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.

5. User B disconnects with User C.

6. User C and User A connect to each other.


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 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-0002@companyb.com; user=phone." The "user=phone" parameter distinquishes that the Request-URI address is a telephone number rather than a username.
  • 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.

100 Trying—Cisco SIP IP phone B to Cisco SIP IP phone A

The Cisco SIP IP phone B sends a SIP 100 Trying response to Cisco SIP IP phone A. The 100 Trying response indicates that the INVITE request has been received by Cisco SIP IP phone B.

3.

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.

4.

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.

5.

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.

6.

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.

Call_ID=1 
SDP: c=IN IP4 0.0.0.0

7.

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.

8.

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.

User B dials User C.

9.

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.

10.

100 Trying—Cisco SIP IP phone C to Cisco SIP IP phone B

The Cisco SIP IP phone C sends a SIP 100 Trying response to Cisco SIP IP phone B. The 100 Trying response indicates that the INVITE request has been received by Cisco SIP IP phone C.

11.

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.

12.

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.

13.

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.
User B then selects the option to transfer the call to User C.

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 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.

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 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.

17.

REFER—Cisco SIP IP phone B to Cisco SIP IP phone A

Cisco SIP IP phone B sends a REFER message to Cisco SIP IP phone A. The REFER message contains the following information:

  • Refer-To: C
  • Replaces: B
  • Referred-By: B

The REFER message indicates that the user (recipient) should contact a third party for use in transferring parties.

18.

202 ACCEPTED—Cisco SIP IP phone A to Cisco SIP IP phone B

Cisco SIP IP phone A sends a SIP 202 ACCEPTED message to Cisco SIP IP phone B. The 202 ACCEPTED confirms that the REFER message has been received.

19.

INVITE—Cisco SIP IP phone A to Cisco SIP IP phone C

Cisco SIP IP phone A sends a SIP INVITE request to Cisco SIP IP phone C. The INVITE request contains the following information:

  • Referred-By: B
  • Replaces: B
20.

200 OK—Cisco SIP IP phone C to Cisco SIP IP phone A

Cisco SIP IP phone C sends a SIP 200 OK message to Cisco SIP IP phone A. The 200 OK response notifies Cisco SIP IP phone A that the INVITE request has been received.

21.

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.

22.

BYE—Cisco SIP IP phone C to Cisco SIP IP phone B

Cisco SIP IP phone C sends a SIP BYE request to Cisco SIP IP phone B.

23.

200 OK—Cisco SIP IP phone B to Cisco SIP IP phone C

Cisco SIP IP phone B sends a SIP 200 OK message to Cisco SIP IP phone C. The 200 OK response notifies Cisco SIP IP phone C that the BYE request has been received.

24.

NOTIFY—Cisco SIP IP phone A to Cisco SIP IP phone B

Cisco SIP IP phone A sends a NOTIFY message to Cisco SIP IP phone B. The NOTIFY message notifies Cisco SIP IP phone B of the REFER event.

25.

200 OK—Cisco SIP IP phone B to Cisco SIP IP phone A

Cisco SIP IP phone B sends a SIP 200 OK message to Cisco SIP IP phone A. The 200 OK response notifies Cisco SIP IP phone A that the NOTIFY request has been received.

26.

BYE—Cisco SIP IP phone B to Cisco SIP IP phone A

Cisco SIP IP phone B sends a SIP BYE request to Cisco SIP IP phone A.

27.

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 A that the BYE request has been received.

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 Using Failover to Bye/Also

Figure B-9 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.

5. User B disconnects with User C.

6. User C and User A connect to each other.


Figure B-9   Cisco SIP IP Phone-to-Cisco SIP IP Phone Call Transfer with Consultation Using Failover to Bye/Also


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 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-0002@companyb.com; user=phone." The "user=phone" parameter distinquishes that the Request-URI address is a telephone number rather than a username.
  • 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.

100 Trying—Cisco SIP IP phone B to Cisco SIP IP phone A

The Cisco SIP IP phone B sends a SIP 100 Trying response to Cisco SIP IP phone A. The 100 Trying response indicates that the INVITE request has been received by Cisco SIP IP phone B.

3.

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.

4.

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.

5.

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.

6.

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.

Call_ID=1 
SDP: c=IN IP4 0.0.0.0

7.

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.

8.

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.

User B dials User C.

9.

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.

10.

100 Trying—Cisco SIP IP phone C to Cisco SIP IP phone B

The Cisco SIP IP phone C sends a SIP 100 Trying response to Cisco SIP IP phone B. The 100 Trying response indicates that the INVITE request has been received by the Cisco SIP IP phone.

11.

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.

12.

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.

13.

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.
User B then selects the option to transfer the call to User C.

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 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.

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 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.

17.

REFER—Cisco SIP IP phone B to Cisco SIP IP phone A

Cisco SIP IP phone B sends a REFER message to Cisco SIP IP phone A. The REFER message contains the following information:

  • Refer-To: C
  • Replaces: B
  • Referred-By: B

The REFER message indicates that the user (recipient) should contact a third party for use in transferring parties.

18.

501 Not Implemented—
Cisco SIP IP Phone A to Cisco SIP IP Phone B

Cisco SIP IP phone A sends a 501 Not Implemented message to Cisco SIP IP phone B. This message indicates that the REFER message is not supported and that Cisco SIP IP phone B should failover to Bye/Also.

19.

BYE—Cisco SIP IP phone B to Cisco SIP IP phone A

Cisco SIP IP phone B sends a BYE message to Cisco SIP IP phone A. The BYE message includes the following information:

  • Also: C

This message indicates that the 501 Not Implemented message was received in response to a REFER message.

20.

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.

21.

BYE—Cisco SIP IP phone B to Cisco SIP IP phone C

Cisco SIP IP phone B sends a SIP BYE request to Cisco SIP IP phone C.

22.

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.

23.

INVITE—Cisco SIP IP phone A to Cisco SIP IP phone C

Cisco SIP IP phone A sends a SIP INVITE request to Cisco SIP IP phone C. The INVITE request contains the following information:

  • Requested-By: B

This message indicates that the INVITE was requested by Cisco SIP IP phone B.

24.

100 Trying—Cisco SIP IP phone C to Cisco SIP IP phone A

The Cisco SIP IP phone C sends a SIP 100 Trying response to Cisco SIP IP phone A. The 100 Trying response indicates that the INVITE request has been received by Cisco SIP IP phone C.

25.

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.

26.

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.

27.

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-10 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-10   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 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-0002@companyb.com; user=phone." The "user=phone" parameter distinquishes that the Request-URI address is a telephone number rather than a username.
  • 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.

INVITE—SIP proxy server to SIP redirect server

SIP proxy server sends the SIP INVITE request to the SIP redirect server.

3.

302 Moved Temporarily—SIP redirect server to SIP proxy server

SIP redirect server sends a SIP 302 Moved temporarily message to the SIP proxy server. The message indicates that User B is not available at SIP phone B and includes instructions to locate User B at Cisco SIP IP phone C.

4.

INVITE—SIP proxy server to Cisco SIP IP phone C

SIP proxy server 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.

5.

180 Ringing—Cisco SIP IP phone C to SIP proxy server

Cisco SIP IP phone C sends a SIP 180 Ringing response to the SIP proxy server.

6.

200 OK—Cisco SIP IP phone C to SIP proxy server

Cisco SIP IP phone C sends a SIP 200 OK response to the SIP proxy server.

7.

200 OK—SIP proxy server to Cisco SIP IP phone A

SIP proxy server forwards the SIP 200 OK response to Cisco SIP IP phone A.

8.

ACK—Cisco SIP IP phone A to SIP proxy server

Cisco SIP IP phone A sends a SIP ACK to the SIP proxy server. The ACK confirms that the SIP proxy server has received the 200 OK response from Cisco SIP IP phone C.

9.

ACK—SIP proxy server to Cisco SIP IP phone C

SIP proxy server forwards the SIP ACK to the 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.

Cisco SIP IP Phone-to-Cisco SIP IP Phone Network Call Forwarding (Busy)

Figure B-11 illustrates successful call forwarding between Cisco SIP IP phones in which User B has requested call forwarding from the network in the event the phone is busy. When User A calls User B, the SIP proxy server tries to place the call to Cisco SIP IP phone B and, if the line is busy, the call is 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 if their phone (Cisco SIP IP phone B) is busy, the network should forward incoming calls to Cisco SIP IP phone C.

2. User A calls User B.

3. User B's phone is busy.

4. The network transfers the call to Cisco SIP IP phone C.


Figure B-11   Cisco SIP IP Phone-to-Cisco SIP IP Phone Network Call Forwarding (Busy)


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 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-0002@companyb.com; user=phone." The "user=phone" parameter distinquishes that the Request-URI address is a telephone number rather than a username.
  • 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.

INVITE—SIP proxy server to SIP redirect server

SIP proxy server sends the SIP INVITE request to the SIP redirect server.

3.

300 Multiple Choices—SIP redirect server to SIP proxy server

SIP redirect server sends a SIP 300 Multiple choices message to the SIP proxy server. The message indicates that User B can be reached either at SIP phone B or Cisco SIP IP phone C.

4.

INVITE—SIP proxy server to Cisco SIP IP phone B

SIP proxy server 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.

5.

486 Busy Here—Cisco SIP IP phone B to SIP proxy server

Cisco SIP IP phone B sends a 486 Busy here message to the SIP proxy server. The message indicates that Cisco SIP IP phone B is in use and the user is not willing or able to take additional calls.

6.

ACK—SIP proxy server to
Cisco SIP IP phone B

SIP proxy server forwards the SIP ACK to the Cisco SIP IP phone B. The ACK confirms that the SIP proxy server has received the 486 Busy here response from Cisco SIP IP phone B.

7.

INVITE—SIP proxy server to Cisco SIP IP phone C

SIP proxy server 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 SIP proxy server

Cisco SIP IP phone C sends a SIP 180 Ringing response to the SIP proxy server

9.

200 OK—Cisco SIP IP phone C to SIP proxy server

Cisco SIP IP phone C sends a SIP 200 OK response to the SIP proxy server.

10.

200 OK—SIP proxy server to Cisco SIP IP phone A

SIP proxy server forwards the SIP 200 OK response to Cisco SIP IP phone A.

11.

ACK—Cisco SIP IP phone A to SIP proxy server

Cisco SIP IP phone A sends a SIP ACK to the SIP proxy server. The ACK confirms that Cisco SIP IP phone A has received the 200 OK response from Cisco SIP IP phone C.

12.

ACK—SIP proxy server to
Cisco SIP IP phone C

SIP proxy server forwards the SIP ACK to the 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.

Cisco SIP IP Phone-to-Cisco SIP IP Phone Network Call Forwarding (No Answer)

Figure B-12 illustrates successful call forwarding between Cisco SIP IP phones in which User B has requested call forwarding from the network in the event that there is no answer. When User A calls User B, the proxy server tries to place the call to Cisco SIP IP phone B and, if there is no answer, the call is 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 if the phone (Cisco SIP IP phone B) is not answered within a set amount of time, the network should forward incoming calls to Cisco SIP IP phone C.

2. User A calls User B.

3. User B's phone is not answered.

4. The network transfers the call to Cisco SIP IP phone C.


Figure B-12   Cisco SIP IP Phone-to-Cisco SIP IP Phone Network Call Forwarding (No Answer)


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 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-0002@companyb.com; user=phone." The "user=phone" parameter distinquishes that the Request-URI address is a telephone number rather than a username.
  • 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.

INVITE—SIP proxy server to SIP redirect server

SIP proxy server sends the SIP INVITE request to the SIP redirect server.

3.

300 Multiple Choices—SIP redirect server to SIP proxy server

SIP redirect server sends a SIP 300 Multiple choices message to the SIP proxy server. The message indicates that User B can be reached either at SIP phone B or Cisco SIP IP phone C.

4.

INVITE—SIP proxy server to Cisco SIP IP phone B

SIP proxy server 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.

5.

180 Ringing—Cisco SIP IP phone B to SIP proxy server

Cisco SIP IP phone B sends a SIP 180 Ringing response to the SIP proxy server.

6.

180 Ringing—SIP proxy server to Cisco SIP IP phone A

SIP proxy server sends a SIP 180 Ringing response to Cisco SIP IP phone A.

The timeout expires before the phone is answered.

7.

CANCEL (Ring Timeout)—SIP proxy server to Cisco SIP IP phone B

SIP proxy server sends a CANCEL request to Cisco SIP IP phone B to cancel the invitation.

8.

200 OK—Cisco SIP IP phone B to SIP proxy server

Cisco SIP IP phone B sends a SIP 200 OK response to the SIP proxy server. The response confirms receipt of the cancellation request.

9.

INVITE—SIP proxy server to Cisco SIP IP phone C

SIP proxy server 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.

10.

180 Ringing—Cisco SIP IP phone C to SIP proxy server

Cisco SIP IP phone C sends a SIP 180 Ringing response to the SIP proxy server.

11.

200 OK—Cisco SIP IP phone C to SIP proxy server

Cisco SIP IP phone C sends a SIP 200 OK response to the SIP proxy server.

12.

200 OK—SIP proxy server to Cisco SIP IP phone A

SIP proxy server forwards the SIP 200 OK response to Cisco SIP IP phone A.

13.

ACK—Cisco SIP IP phone A to SIP proxy server

Cisco SIP IP phone A sends a SIP ACK to the SIP proxy server. The ACK confirms that Cisco SIP IP phone A has received the 200 OK response from Cisco SIP IP phone C.

14.

ACK—SIP proxy server to Cisco SIP IP phone C

SIP proxy server forwards the SIP ACK to the 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.

Cisco SIP IP Phone-to Cisco SIP IP Phone Three-Way Calling

Figure B-12 illustrates successful three-way calling between Cisco SIP IP phones in which User B mixes two RTP channels and therefore establishes a conference bridge between User A and User 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 A calls User B.

2. User B answers the call.

3. User B puts User A on hold.

4. User B calls User C.

5. User C answers the call.

6. User B takes User A off hold.


Figure B-13   Cisco SIP IP Phone-to Cisco SIP IP Phone 3-Way Calling


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 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-0002@companyb.com; user=phone." The "user=phone" parameter distinquishes that the Request-URI address is a telephone number rather than a username.
  • 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.

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—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. User A is put on hold.

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 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 C 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 username.
  • Cisco SIP IP phone B 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 B is ready to receive is specified.
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 C supports the media capability advertised in the INVITE message sent by Cisco SIP IP phone B, it advertises the intersection of its own and Cisco SIP IP phone B's media capability in the 200 OK response. If Cisco SIP IP phone C does not support the media capability advertised by Cisco SIP IP phone B, 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 SIP IP phone B and SIP IP phone C.

12.

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.

Call_ID=1 
SDP: c=IN IP4 181.23.250.2

To reestablish the call between phone A and phone B, the IP address of phone B is inserted into the c= SDP field.

13.

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.

14.

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.

SIP IP phone B acts as a bridge mixing the RTP channel between User A and User B with the channel between User B and User C; establishing a conference bridge between User A and User C.

Call Flow Scenarios for Failed Calls

This section describes call flows for the following scenarios, which illustrate unsuccessful calls:

Gateway-to-Cisco SIP IP Phone—Called User Is Busy

Figure B-14 illustrates an unsuccessful call in which User A initiates a call to User B, but User B is on the phone and is unable or unwilling to take another call.


Figure B-14   Gateway-to-Cisco SIP IP Phone—Called User is Busy


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.

486 Busy Here—Cisco SIP IP phone to Gateway 1

The Cisco SIP IP phone sends a SIP 486 Busy Here response to Gateway 1. The 486 Busy Here response is a client error response that indicates that User B was successfully contacted but that User B was not willing or was unable to take the call.

6.

Disconnect (Busy)—Gateway 1 to PBX A

Gateway 1 sends a Disconnect message to PBX A.

7.

Release—PBX A to Gateway 1

PBX A sends a Release message to Gateway 1.

8.

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 486 Busy Here response. The call session attempt is now being terminated.

9.

Release Complete—Gateway 1 to PBX A

Gateway 1 sends a Release Complete message to PBX A and the call session attempt is terminated.

Gateway-to-Cisco SIP IP Phone—Called User Does Not Answer

Figure B-15 illustrates the call flow in which User A initiates a call to User B but User B does not answer.


Figure B-15   Gateway-to-Cisco SIP IP Phone—Called User Does Not Answer


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 PBX A.

7.

CANCEL (Ring Timeout)—Gateway 1 to
Cisco SIP IP phone

Because Gateway 1 did not return an appropriate response within the time allocated in the INVITE request, Gateway 1 sends a SIP CANCEL request to Gateway 2. A CANCEL request cancels a pending request with the same Call-ID, To, From, and CSeq header field values.

8.

Disconnect—Gateway 1 to PBX A

Gateway 1 sends a Disconnect message to PBX A.

9.

Release Complete—Gateway 1 to PBX A

Gateway 1 sends a Release Complete message to PBX A and the call session attempt is terminated.

10.

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 confirms that User A has received the 486 Busy Here response. The call session attempt is now being terminated.

11.

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—Client, Server, or Global Error

Figure B-16 illustrates an unsuccessful call in which User A initiates a call to User B and receives a class 4xx, 5xx, or 6xx response.


Figure B-16   Gateway-to-Cisco SIP IP Phone—Client, Server, or Global Error


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.

4xx/5xx/6xx Failure—
Cisco SIP IP phone to Gateway 1

The Cisco SIP IP phone sends a class 4xx, 5xx, or class 6xx failure response to Gateway 1. Depending on which class the failure response is, the call actions differ.

If the Cisco SIP IP phone sends a class 4xx failure response (a definite failure response that is a client error), the request will not be retried without modification.

If the Cisco SIP IP phone sends a class 5xx failure response (an indefinite failure that is a server error), the request is not terminated but rather other possible locations are tried.

If the Cisco SIP IP phone sends a class 6xx failure response (a global error), the search for User B is terminated because the 6xx response indicates that a server has definite information about User B, but not for the particular instance indicated in the Request-URI field. Therefore, all further searches for this user will fail.

6.

Disconnect—Gateway 1 to
PBX A

Gateway 1 sends a Release message to PBX A.

7.

Release—PBX A to Gateway 1

PBX A sends a Release message to Gateway 1.

8.

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 486 Busy Here response. The call session attempt is now being terminated.

9.

Release Complete—Gateway 1 to PBX A

Gateway 1 sends a Release Complete message to PBX A and the call session attempt is terminated.

Cisco SIP IP Phone-to-Cisco SIP IP Phone—Called User Is Busy

Figure B-17 illustrates an unsuccessful call in which User A initiates a call to User B but User B is on the phone and is unable or unwilling to take another call.


Figure B-17   Cisco SIP IP Phone-to-Cisco SIP IP Phone—Called User Is Busy


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 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-0002@companyb.com; user=phone." The "user=phone" parameter distinquishes that the Request-URI address is a telephone number rather than a username.
  • 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.

486 Busy Here—Cisco SIP IP phone B to Cisco SIP IP phone A

Cisco SIP IP phone B sends a 486 Busy here message to the Cisco SIP IP phone A. The message indicates that Cisco SIP IP phone B is in use and the user is not willing or able to take additional calls.

3.

ACK—Cisco SIP IP phone A to Cisco SIP IP phone B

Cisco SIP IP phone A sends a SIP ACK to the Cisco SIP IP phone B. The ACK confirms that Cisco SIP IP phone A has received the 486 Busy Here response from Cisco SIP IP phone B.

Cisco SIP IP Phone-to-Cisco SIP IP Phone—Called User Does Not Answer

Figure B-18 illustrates an unsuccessful call in which User A initiates a call to User B but User B does not answer.


Figure B-18   Cisco SIP IP Phone-to-Cisco SIP IP Phone—Called User Does Not Answer


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 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-0002@companyb.com; user=phone." The "user=phone" parameter distinquishes that the Request-URI address is a telephone number rather than a username.
  • 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.

CANCEL (Ring Timeout)—Cisco SIP IP phone A to Cisco SIP IP phone B

Cisco SIP IP phone A sends a CANCEL request to Cisco SIP IP phone B to cancel the invitation.

4.

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 response confirms receipt of the cancellation request.

Cisco SIP IP Phone-to-Cisco SIP IP Phone—Authentication Error

Figure B-19 illustrates an unsuccessful call in which User A initiates a call to User B but is prompted for authentication credentials by the proxy server. User A's SIP IP phone then reinitiates the call with an SIP INVITE request that includes it's authentication credentials.


Figure B-19   Cisco SIP IP Phone-to-Cisco SIP IP Phone—Authentication Error


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 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-0002@companyb.com; user=phone." The "user=phone" parameter distinquishes that the Request-URI address is a telephone number rather than a username.
  • 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.

407 Authentication Error—SIP proxy server to Cisco SIP IP phone A

SIP proxy server sends a SIP 407 Authentication Error response to Cisco SIP IP phone A.

3.

ACK—Cisco SIP IP phone A to SIP proxy server

Cisco SIP IP phone A sends a SIP ACK to the SIP proxy server acknowledging the 407 error message.

4.

Resend INVITE—Cisco SIP IP phone A to SIP proxy server

Cisco SIP IP phone A resends a SIP INVITE to the SIP proxy server with authentication credentials.

Call from a Cisco SIP IP Phone to a Gateway Acting as a Backup Proxy

Figure B-20 illustrates a successful call from a Cisco SIP IP phone to a gateway acting as a backup proxy.


Figure B-20   A Successful Call from a Cisco SIP IP Phone to a Gateway (Backup Proxy)


Step  Action  Description 
1.

INVITE—Cisco SIP IP phone to primary proxy

Cisco SIP IP phone tries to connect to the proxy by sending out the INVITE message.

2.

INVITE—Cisco SIP IP phone to primary proxy (second try)

Cisco SIP IP phone retries a second time to connect to the proxy by sending out the INVITE message.

3.

INVITE—Cisco SIP IP phone to primary proxy (third try)

Cisco SIP IP phone retries a third time to connect to the proxy by sending out the INVITE message.

4.

INVITE—Cisco SIP IP phone to primary proxy (fourth try)

Cisco SIP IP phone retries a fourth time to connect to the proxy by sending out the INVITE message.

5.

INVITE—Cisco SIP IP phone to primary proxy (fifth try)

Cisco SIP IP phone retries a fifth time to connect to the proxy by sending out the INVITE message.

6.

INVITE—Cisco SIP IP phone to primary proxy (sixth try)

Cisco SIP IP phone retries a sixth time to connect to the proxy by sending out the INVITE message.

7.

INVITE—Cisco SIP IP phone to primary proxy (seventh try)

Cisco SIP IP phone retries a seventh time to connect to the proxy. If the connection is not successful after this trial, "Network Delay, Trying Backup" message displays on the Phone.

8.

INVITE—Cisco SIP IP phone to gateway (backup proxy)

Cisco SIP IP phone tries to connect to the gateway (backup proxy) by sending out the INVITE message.

9.

Setup—Gateway to PBX

Call Setup is initiated between gateway to PBX. The Call Setup includes the standard transactions that take place as User A attempts to call User B.

10.

Call Proceeding—PBX to gateway

PBX sends a Call Proceeding message to gateway to acknowledge the Call Setup request.

11.

100 Trying—Gateway to
Cisco SIP IP phone (User A)

Gateway sends a SIP 100 Trying response to User A. The 100 Trying response indicates that the INVITE request has been received by the gateway.

12.

Alerting—PBX to gateway

PBX sends an Alert message to gateway. The Alert message indicates that PBX has received a 100 Trying Ringing response from the gateway.

13.

180 Ringing—Gateway to
Cisco SIP IP phone (User A)

The gateway sends a SIP 180 Ringing response to User A. The 180 Ringing response indicates that the gateway is being alerted.

14.

Connect—PBX to gateway

PBX sends a Connect message to gateway. The Connect message notifies the gateway that the connection has been made.

15.

200 OK—Gateway to
Cisco SIP IP phone (User A)

Gateway sends a SIP 200 OK response to the User A. The 200 OK response notifies User A that the connection has been made.

16.

ACK—Cisco SIP IP phone
(User A) to 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.

17.

Connect ACK—Gateway to PBX

Gateway acknowledges PBX's Connect message.

18.

BYE—Cisco SIP IP phone
(User A) to gateway

User A terminates the call session and sends a SIP BYE request to gateway. The BYE request indicates that User A wants to release the call.

19.

Disconnect—Gateway to PBX

Gateway sends a Disconnect message to PBX.

20.

Release—PBX to gateway

PBX sends a Release message to gateway.

21.

200 OK—Gateway to
Cisco SIP IP phone (User A)

Gateway sends a SIP 200 OK response to User A. The 200 OK response notifies User A that the gateway has received the BYE request.

22.

Release Complete—Gateway to PBX

Gateway sends a Release Complete message to PBX and the call session is terminated.

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

Figure B-21 illustrates a successful call from a Cisco SIP IP phone to a Cisco SIP IP phone via a backup proxy.


Figure B-21   A Successful Call from a Cisco SIP IP Phone to a Cisco SIP IP Phone via a Backup Proxy


Step  Action  Description 
1.

INVITE—Cisco SIP IP Phone (User A) to primary proxy

Cisco SIP IP Phone tries to connect to the primary proxy by sending out the INVITE message.

2.

INVITE—Cisco SIP IP phone (User A) to primary proxy (second try)

Cisco SIP IP phone retries a second time to connect to the primary proxy by sending out the INVITE message.

3.

INVITE—Cisco SIP IP phone (User A) to primary proxy (third try)

Cisco SIP IP phone retries a third time to connect to the primary proxy by sending out the INVITE message.

4.

INVITE—Cisco SIP IP phone (User A) to primary proxy (fourth try)

Cisco SIP IP phone retries a fourth time to connect to the primary proxy by sending out the INVITE message.

5.

INVITE—Cisco SIP IP phone (User A) to primary proxy (fifth try)

Cisco SIP IP phone retries a fifth time to connect to the primary proxy by sending out the INVITE message.

6.

INVITE—Cisco SIP IP phone (User A) to primary proxy (sixth try)

Cisco SIP IP phone retries a sixth time to connect to the primary proxy by sending out the INVITE message.

7.

INVITE—Cisco SIP IP phone (User A) to primary proxy (seventh try)

Cisco SIP IP phone retries a seventh time to connect to the primary proxy. If the connection is not successful after this trial, the "Network Delay, Trying Backup" message displays on the Phone.

8.

INVITE—Cisco SIP IP phone (User A) to backup proxy

Cisco SIP IP phone tries to connect to the backup proxy by sending out the INVITE message.

9.

100 Trying—Backup proxy to Cisco SIP IP phone (User A)

Backup proxy sends a SIP 100 Trying response to Cisco SIP IP phone. The 100 Trying response indicates that the INVITE request has been received by the backup proxy.

10.

INVITE—Backup proxy to Cisco SIP IP phone (User B)

Backup proxy tries to connect to User B by sending out the INVITE message.

11.

100 Trying—Cisco SIP IP phone (User B) to backup proxy

User B sends a SIP 100 Trying response to backup proxy. The 100 Trying response indicates that the INVITE request has been received by User B.

12.

180 Ringing—Cisco SIP IP phone (User B) to backup proxy

User B sends a SIP 180 Ringing response to the backup proxy. The 180 Ringing response indicates that User B is being alerted.

13.

180 Ringing—Backup proxy to Cisco SIP IP phone (User A)

The backup proxy sends a SIP 180 Ringing response to User A. The 180 Ringing response indicates that the backup proxy is being alerted.

14.

200 OK—Cisco SIP IP phone (User B) to backup proxy

User B sends a SIP 200 OK response to the backup proxy. The 200 OK response notifies the backup proxy that the connection has been made.

15.

200 OK—Backup proxy to
Cisco SIP IP phone (User A)

Backup proxy sends a SIP 200 OK response to User A. The 200 OK response notifies User A that the connection has been made.

16.

ACK—Cisco SIP IP phone (User A) to backup proxy

User A acknowledges backup proxy's Connect message.

17.

ACK—Backup proxy to
Cisco SIP IP phone (User B)

Backup proxy acknowledges User B's Connect message.

18.

BYE—Cisco SIP IP phone
(User A) to backup proxy

User A terminates the call session and sends a SIP BYE request to backup proxy. The BYE request indicates that User A wants to release the call.

19.

BYE—Backup proxy to
Cisco SIP IP phone (User B)

Backup proxy terminates the call session and sends a SIP BYE request to User B. The BYE request indicates that the backup proxy wants to release the call.

20.

200 OK—Cisco SIP IP phone (User B) to backup proxy

User B sends a SIP 200 OK response to the backup proxy. The 200 OK response notifies the backup proxy that User B has received the BYE request.

21.

200 OK—Backup proxy to
Cisco SIP IP phone (User A)

Backup proxy sends a SIP 200 OK response to User A. The 200 OK response notifies User A that the backup proxy has received the BYE request.

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

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


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


Step  Action  Description 
1.

INVITE—Cisco SIP IP phone to gateway (emergency proxy)

Cisco SIP IP 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 PBX

Call setup is initiated between the gateway and PBX. The call setup includes the standard transactions that take place as User A attempts to call User B.

3.

Call Proceeding—PBX to gateway

PBX sends a Call Proceeding message to gateway to acknowledge the Call Setup request.

4.

100 Trying—Gateway to
Cisco SIP IP phone (User A)

Gateway sends a SIP 100 Trying response to User A. The 100 Trying response indicates that the INVITE request has been received by the gateway.

5.

Alerting—PBX to gateway

PBX sends an Alert message to the gateway. The Alert 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 180 Ringing response indicates that the gateway is being alerted.

7.

Connect—PBX to gateway

PBX sends a Connect message to gateway. The Connect message notifies the gateway that the connection has been made.

8.

200 OK—Gateway to Cisco SIP IP phone (User A)

Gateway sends a SIP 200 OK response to the User A. The 200 OK response notifies User A that the connection has been made.

9.

ACK—Cisco SIP IP phone
(User A) to 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 PBX

Gateway acknowledges PBX's Connect message.

11.

BYE—Cisco SIP IP phone
(User A) to gateway

User A terminates the call session and sends a SIP BYE request to gateway. The BYE request indicates that User A wants to release the call.

12.

Disconnect—Gateway to PBX

Gateway sends a Disconnect message to PBX.

13.

Release—PBX to gateway

PBX sends a Release message to the gateway.

14.

200 OK—Gateway to Cisco SIP IP phone (User A)

Gateway sends a SIP 200 OK response to User A. The 200 OK response notifies User A that the gateway has received the BYE request.

15.

Release Complete—Gateway to PBX

Gateway sends a Release Complete message to the PBX and the call session is terminated.

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

Figure B-23 illustrates a successful call from a Cisco SIP IP phone to a Cisco SIP IP phone via emergency proxy. User B is the extension of the dial template with the "Route" attribute as "emergency" in the dialplan.xml file.


Figure B-23   A Successful Call from a Cisco SIP IP Phone to a Cisco SIP IP Phone via Emergency Proxy


Step  Action  Description 
1.

INVITE—Cisco SIP IP phone (User A) to emergency proxy

Cisco SIP IP phone tries to connect to the emergency proxy by sending out the INVITE message. The dial template for the emergency route is matched.

2.

100 Trying—Emergency proxy to Cisco SIP IP phone (User A)

Emergency proxy sends a SIP 100 Trying response to User A. The 100 Trying response indicates that the INVITE request has been received by the emergency proxy.

3.

INVITE—Emergency proxy to Cisco SIP IP phone (User B)

Backup proxy tries to connect to User B by sending out the INVITE message.

4.

100 Trying—Cisco SIP IP phone (User B) to emergency proxy

User B sends a SIP 100 Trying response to the emergency proxy. The 100 Trying response indicates that the INVITE request has been received by User B.

5.

180 Ringing—Cisco SIP IP phone (User B) to emergency proxy

User B sends a SIP 180 Ringing response to the emergency proxy. The 180 Ringing response indicates that User B is being alerted.

6.

180 Ringing—Emergency proxy to Cisco SIP IP phone (User A)

The emergency proxy sends a SIP 180 Ringing response to User A. The 180 Ringing response indicates that the emergency proxy is being alerted.

7.

200 OK—Cisco SIP IP phone (User B) to emergency proxy

User B sends a SIP 200 OK response to the emergency proxy. The 200 OK response notifies the emergency proxy that the connection has been made.

8.

200 OK—Emergency proxy to Cisco SIP IP phone (User A)

Emergency proxy sends a SIP 200 OK response to User A. The 200 OK response notifies User A that the connection has been made.

9.

ACK—Cisco SIP IP phone
(User A) to emergency proxy

User A acknowledges the emergency proxy's Connect message.

10.

ACK—Emergency proxy to Cisco SIP IP phone (User B)

Emergency proxy acknowledges User B's Connect message.

11.

BYE—Cisco SIP IP phone
(User A) to emergency proxy

User A terminates the call session and sends a SIP BYE request to the emergency proxy. The BYE request indicates that User A wants to release the call.

12.

BYE—Emergency proxy to Cisco SIP IP phone (User B)

Emergency proxy terminates the call session and sends a SIP BYE request to User B. The BYE request indicates that the emergency proxy wants to release the call.

13.

200 OK—Cisco SIP IP phone (User B) to emergency proxy

User B sends a SIP 200 OK response to the emergency proxy. The 200 OK response notifies the emergency proxy that User B has received the BYE request.

14.

200 OK—Emergency proxy to Cisco SIP IP phone (User A)

Emergency proxy sends a SIP 200 OK response to User A. The 200 OK response notifies User A that the emergency proxy has received the BYE request.


hometocprevnextglossaryfeedbacksearchhelp
Posted: Sat Nov 29 15:20:25 PST 2003
All contents are Copyright © 1992--2003 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.