Chap 7: SIP Call Flow Process for the Cisco VoIP Infrastructure Solution for SIP

This chapter describes the flow of these messages in the Cisco VoIP Infrastructure Solution for SIP. It includes the following sections:

Call Flow Scenarios for Successful Calls

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

SIP Gateway-to-SIP Gateway—Call Setup and Disconnect

Figure 7-1 illustrates a successful gateway-to-gateway call setup and disconnect. In this call flow scenario, the two end users are User A and User B. User A is located at PBX A. PBX A is connected to SIP gateway 1 via a T1/E1. User B is located at PBX B. PBX B is connected to SIP gateway 2 via a T1/E1. User B's phone number is 555-0002. SIP gateway 1 is connected to SIP gateway 2 over an IP network.

Step	Action	Description
1	Setup—PBX A to SIP gateway 1	Call Setup is initiated between PBX A and SIP gateway 1. The Call Setup includes the standard transactions that take place as User A attempts to call User B.
2	INVITE—SIP gateway 1 to SIP gateway 2	SIP gateway 1 sends an INVITE request to SIP gateway 2. The INVITE request is an invitation to User B to participate in a call session. In the INVITE request: The phone number of User B is inserted in the Request-URI field in the form of a SIP URL. The SIP URL identifies the address of User B and takes a form similar to an email address (user@host where user is the telephone number and host is either a domain name or a numeric network address). For example, the Request-URI field in the INVITE request to User B appears as "INVITE sip:555-0002@companyb.com; user=phone." The "user=phone" parameter indicates that the Request-URI address is a telephone number rather than a user name. 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 SIP gateway 1 is prepared to receive the RTP data is specified.
3	Call Proceeding—SIP gateway 1 to PBX A	SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
4	Setup—SIP gateway 2 to PBX B	SIP gateway 2 receives the INVITE request from SIP gateway 1 and initiates a Call Setup with User B via PBX B.
5	100 Trying—SIP gateway 2 to SIP gateway 1	SIP gateway 2 sends a 100 Trying response to the INVITE request sent by SIP gateway 1. The 100 Trying response indicates that the INVITE request has been received by SIP gateway 2 but that User B has not yet been located and that some unspecified action, such as a database consultation, is taking place.
6	Call Proceeding—PBX B to SIP gateway 2	PBX B sends a Call Proceeding message to SIP gateway 2 to acknowledge the Call Setup request.
7	Alerting—PBX B to SIP gateway 2	PBX B locates User B and sends an Alert message to SIP gateway 2. User B's phone begins ringing.
8	180 Ringing—SIP gateway 2 to SIP gateway 1	SIP gateway 2 sends a 180 Ringing response to SIP gateway 1. The 180 Ringing response indicates that SIP gateway 2 has located, and is trying to alert, User B.
9	Alerting—SIP gateway 1 to PBX A	SIP gateway 1 sends an Alert message to User A via PBX A. The Alert message indicates that SIP gateway 1 has received a 180 Ringing response from SIP gateway 2. User A hears the ringback tone that indicates that User B is being alerted.
At this point, a one-way voice path is established between SIP gateway 1 and PBX A and between SIP gateway 2 and PBX B. A two-way RTP channel is established between SIP gateway 1 and SIP gateway 2.
10	Connect—PBX B to SIP gateway 2	User B answers phone. PBX B sends a Connect message to SIP gateway 2. The Connect message notifies SIP gateway 2 that the connection has been made.
11	200 OK—SIP gateway 2 to SIP gateway 1	SIP gateway 2 sends a 200 OK response to SIP gateway 1. The 200 OK response notifies SIP gateway 1 that the connection has been made. If User B supports the media capability advertised in the INVITE message sent by SIP gateway 1, it advertises the intersection of its own and User A's media capability in the 200 OK response. If User B does not support the media capability advertised by User A, it sends back a 400 Bad Request response with a 304 Warning header field.
12	Connect—SIP gateway 1 to PBX A	SIP gateway 1 sends a Connect message to PBX A. The Connect message notifies PBX A that the connection has been made.
13	Connect ACK—PBX A to SIP gateway 1	PBX A acknowledges SIP gateway 1's Connect message.
14	ACK—SIP gateway 1 to SIP gateway 2	SIP gateway 1 sends an ACK to SIP gateway 2. The ACK confirms that SIP gateway 1 has received the 200 OK response from SIP gateway 2.
15	Connect ACK—SIP gateway 2 to PBX B	SIP gateway 2 acknowledges PBX B's Connect message. The call session is now active over a two-way voice path via Real-time Transport Protocol (RTP).
At this point, a two-way voice path is established between SIP gateway 1 and PBX A and between SIP gateway 2 and PBX B. A two-way RTP channel is established between SIP gateway 1 and SIP gateway 2.
16	Disconnect—PBX B to SIP gateway 2	Once User B hangs up, PBX B sends a Disconnect message to SIP gateway 2. The Disconnect message starts the call session termination process.
17	BYE—SIP gateway 2 to SIP gateway 1	SIP gateway 2 sends a BYE request to SIP gateway 1. The BYE request indicates that User B wants to release the call. Because it is User B that wants to terminate the call, the Request-URI field is now replaced with PBX A's SIP URL and the From field contains User B's SIP URL. The cseq value is incremented by one.
18	Release—SIP gateway 2 to PBX B	SIP gateway 2 sends a Release message to PBX B.
19	Disconnect—SIP gateway 1 to PBX A	SIP gateway 1 sends a Disconnect message to PBX A.
20	Release—PBX A to SIP gateway 1	PBX A sends a Disconnect message to SIP gateway 1.
21	200 OK—SIP gateway 1 to SIP gateway 2	SIP gateway 1 sends a 200 OK response to SIP gateway 2. The 200 OK response notifies SIP gateway 2 that SIP gateway 1 has received the BYE request.
22	Release Complete—PBX B to SIP gateway 2	PBX B sends a Release Complete message to SIP gateway 2.
23	Release Complete—SIP gateway 1 to PBX A	SIP gateway 1 sends a Release Complete message to PBX A and the session is terminated.

SIP Gateway-to-SIP Gateway—Call via SIP Redirect Server

Figure 7-2 illustrates a successful gateway-to-gateway call setup and disconnect via a SIP redirect server. In this scenario, the two end users are identified as User A and User B. User A is located at PBX A. PBX A is connected to SIP gateway 1 via a T1/E1. SIP gateway 1 is using a SIP redirect server. User B is located at PBX B. PBX B is connected to SIP gateway 2 via a T1/E1. User B's phone number is 555-0002. SIP gateway 1 is connected to SIP gateway 2 over an IP network.

Step	Action	Description
1	Setup—PBX A to SIP gateway 1	Call Setup is initiated between PBX A and SIP gateway 1. The Call Setup includes the standard transactions that take place as User A attempts to call User B.
2	INVITE—SIP gateway 1 to SIP redirect server	SIP gateway 1 sends an INVITE request to the SIP redirect server. The INVITE request is an invitation to User B to participate in a call session. In the INVITE request: The phone number of User B is inserted in the Request-URI field in the form of a SIP URL. The SIP URL identifies the address of User B and takes a form similar to an email address (user@host where user is the telephone number and host is either a domain name or a numeric network address). For example, the Request-URI field in the INVITE request to User B appears as "INVITE sip:555-0002@companyb.com; user=phone." The "user=phone" parameter distinquishes that the Request-URI address is a telephone number rather than a user name. 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 SIP gateway 1 is prepared to receive the RTP data is specified.
3	300 Multiple Choice—SIP redirect server to SIP gateway 1	The SIP redirect server sends a 300 Multiple Choice response to SIP gateway 1. The 300 Multiple Choice response indicates that the SIP redirect server accepted the INVITE request, contacted a location server with all or part of User B's SIP URL, and the location server provided a list of alternative locations where User B might be located. The SIP redirect server returns these possible addresses to SIP gateway 1 in the 300 Multiple Choice response.
4	ACK—SIP gateway 1 to SIP redirect server	SIP gateway 1 acknowledges the 300 Multiple Choice response with an ACK.
5	INVITE—SIP gateway 1 to SIP gateway 2	SIP gateway 1 sends a new INVITE request to SIP gateway 2. The new INVITE request includes the first contact listed in the 300 Multiple Choice response as the new address for User B, a higher transaction number in the CSeq field, and the same Call-ID as the first INVITE request.
6	Setup—SIP gateway 2 to PBX B	SIP gateway 2 receives the INVITE request from SIP gateway 1 and initiates a Call Setup with User B via PBX B.
7	Call Proceeding—SIP gateway 1 to PBX A	SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
8	100 Trying—SIP gateway 2 to SIP gateway 1	SIP gateway 2 sends a 100 Trying response to the INVITE request sent by SIP gateway 1. The 100 Trying response indicates that the INVITE request has been received by SIP gateway 2 but that User B has not yet been located.
9	Call Proceeding—PBX B to SIP gateway 2	PBX B sends a Call Proceeding message to SIP gateway 2 to acknowledge the Call Setup request.
10	Alerting—PBX B to SIP gateway 2	PBX B locates User B and sends an Alert message to SIP gateway 2. User B's phone begins to ring.
11	180 Ringing—SIP gateway 2 to SIP gateway 1	SIP gateway 2 sends a 180 Ringing response to SIP gateway 1. The 180 Ringing response indicates that SIP gateway 2 has located, and is trying to alert, User B.
12	Alerting—SIP gateway 1 to PBX A	SIP gateway 1 sends an Alert message to PBX A. User A hears ringback tone.
At this point, a one-way voice path is established between SIP gateway 1 and PBXA and between SIP gateway 2 and PBX B. A two-way RTP channel is established between SIP gateway 1 and SIP gateway 2.
13	Connect—PBX B to SIP gateway 2	User B answers phone. PBX B sends a Connect message to SIP gateway 2. The Connect message notifies SIP gateway 2 that the connection has been made.
14	200 OK—SIP gateway 2 to SIP gateway 1	SIP gateway 2 sends a 200 OK response to SIP gateway 1. The 200 OK response notifies SIP gateway 1 that the connection has been made. If User B supports the media capability advertised in the INVITE message sent by SIP gateway 1, it advertises the intersection of its own and User A's media capability in the 200 OK response. If User B does not support the media capability advertised by User A, it sends back a 400 Bad Request response with a 304 Warning header field.
15	Connect—SIP gateway 1 to PBX A	SIP gateway 1 sends a Connect message to PBX A. The Connect message notifies PBX A that the connection has been made.
16	Connect ACK—PBX A to SIP gateway 1	PBX A acknowledges SIP gateway 1's Connect message.
17	ACK—SIP gateway 1 to SIP gateway 2	SIP gateway 1 sends an ACK to SIP gateway 2. The ACK confirms that the 200 OK response has been received. The call is now in progress over a two-way voice path via RTP.
18	Connect ACK—SIP gateway 2 to PBX B	SIP gateway 2 acknowledges PBX B's Connect message.
At this point, a two-way voice path is established between SIP gateway 1 and PBX A and between SIP gateway 2 and PBX B. A two-way RTP channel is established between SIP gateway 1 and SIP gateway 2.
19	Disconnect—PBX B to SIP gateway 2	Once User B hangs up, PBX B sends a Disconnect message to SIP gateway 2. The Disconnect message starts the call session termination process.
20	BYE—SIP gateway 2 to SIP gateway 1	SIP gateway 2 sends a BYE request to SIP gateway 1. The BYE request indicates that User B wants to release the call. Because it is User B that wants to terminate the call, the Request-URI field is now replaced with PBX A's SIP URL and the From field contains User B's SIP URL.
21	Disconnect—SIP gateway 1 to PBX A	SIP gateway 1 sends a Disconnect message to PBX A.
22	Release—SIP gateway 2 to PBX B	SIP gateway 2 sends a Release message to PBX B.
23	Release—PBX A to SIP gateway 1	PBX A sends a Release message to SIP gateway 1.
24	200 OK—SIP gateway 1 to SIP gateway 2	SIP gateway 1 sends a 200 OK response to SIP gateway 2. The 200 OK response notifies SIP gateway 2 that SIP gateway 1 has received the BYE request.
25	Release Complete—PBX B to SIP gateway 2	PBX B sends a Release Complete message to SIP gateway 2.
26	Release Complete—SIP gateway 1 to PBX A	SIP gateway 1 sends a Release Complete message to PBX A and the session is terminated.

SIP Gateway-to-SIP Gateway—Call via SIP Proxy Server

Figure 7-3 and Figure 7-4 illustrate a successful gateway-to-gateway call setup and disconnect via a proxy server. In these scenarios, the two end users are User A and User B. User A is located at PBX A. PBX A is connected to SIP gateway 1 via a T1/E1. SIP gateway 1 is using a proxy server. SIP gateway 1 is connected to SIP gateway 2 over an IP network. User B is located at PBX B. PBX B is connected to SIP gateway 2 (a SIP gateway) via a T1/E1. User B's phone number is 555-0002.

In the scenario illustrated by Figure 7-3, the record route feature is enabled on the proxy server. In the scenario illustrated by Figure 7-4, record route is disabled on the proxy server.

When record route is enabled, the proxy server adds the Record-Route header to the SIP messages to ensure that it is in the path of subsequent SIP requests for the same call leg. The Record-Route field contains a globally reachable Request-URI that identifies the proxy server. When record route is enabled, each proxy server adds its Request-URI to the beginning of the list.

When record route is disabled, SIP messages flow directly through the SIP gateways once a call has been established.

Step	Action	Description
1	Setup—PBX A to SIP gateway 1	Call Setup is initiated between PBX A and SIP gateway 1. The Call Setup includes the standard transactions that take place as User A attempts to call User B.
2	INVITE—SIP gateway 1 to proxy server	SIP gateway 1 sends an INVITE request to the SIP proxy server. The INVITE request is an invitation to User B to participate in a call session. In the INVITE request: The phone number of User B is inserted in the Request-URI field in the form of a SIP URL. The SIP URL identifies the address of User B and takes a form similar to an email address (user@host where user is the telephone number and host is either a domain name or a numeric network address). For example, the Request-URI field in the INVITE request to User B appears as "INVITE sip:555-0002@companyb.com; user=phone." The "user=phone" parameter distinquishes that the Request-URI address is a telephone number rather than a user name. 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 SIP gateway 1 is prepared to receive the RTP data is specified.
3	Call Proceeding—SIP gateway 1 to PBX A	SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
4	INVITE—SIP proxy server to SIP gateway 2	The SIP proxy server checks whether its own address is contained in the Via field (to prevent loops), directly copies the To, From, Call-ID, and Contact fields from the request it received from SIP gateway 1, changes the Request-URI to indicate the server to which it intends to send the INVITE request, and then sends a new INVITE request to SIP gateway 2.
5	100 Trying—SIP proxy server to SIP gateway 1	The SIP proxy server sends a 100 Trying response to SIP gateway 1.
6	Setup—SIP gateway 2 to PBX B	SIP gateway 2 receives the INVITE request from the SIP proxy server and initiates a Call Setup with User B via PBX B.
7	100 Trying—SIP gateway 2 to SIP proxy server	SIP gateway 2 sends a 100 Trying response to the SIP proxy server. The SIP proxy server might or might not forward the 100 Trying response to SIP gateway 1.
8	Call Proceeding—PBX B to SIP gateway 2	PBX B sends a Call Proceeding message to SIP gateway 2 to acknowledge the Call Setup request.
9	Alerting—PBX B to SIP gateway 2	PBX B locates User B and sends an Alert message to SIP gateway 2. User B's phone begins to ring.
10	180 Ringing—SIP gateway 2 to SIP proxy server	SIP gateway 2 sends a 180 Ringing response to the SIP proxy server.
11	180 Ringing—SIP proxy server to SIP gateway 1	The SIP proxy server forwards the 180 Ringing response to SIP gateway 1.
12	Alerting—SIP gateway 1 to PBX A	SIP gateway 1 sends an Alert message to User A via PBX A. The Alert message indicates that SIP gateway 1 has received a 180 Ringing response. User A hears the ringback tone that indicates that User B is being alerted.
At this point, a one-way voice path is established between SIP gateway 1 and PBX A and between SIP gateway 2 and PBX B. A two-way RTP channel is established between SIP gateway 1 and SIP gateway 2.
13	Connect—PBX B to SIP gateway 2	User B answers the phone. PBX B sends a Connect message to SIP gateway 2. The connect message notifies SIP gateway 2 that the connection has been made.
14	200 OK—SIP gateway 2 to SIP proxy server	SIP gateway 2 sends a 200 OK response (including the Record-Route header received in the INVITE) to the SIP proxy server. The 200 OK response notifies the SIP proxy server that the connection has been made. If User B supports the media capability advertised in the INVITE message sent by the SIP proxy server, it advertises the intersection of its own and User A's media capability in the 200 OK response. If User B does not support the media capability advertised by User A, it sends back a 400 Bad Request response with a 304 Warning header field. The SIP proxy server must forward 200 OK responses upstream.
15	200 OK—SIP proxy server to SIP gateway 1	The SIP proxy server forwards the 200 OK response that it received from SIP gateway 2 to SIP gateway 1. In the 200 OK response, the SIP proxy server forwards the Record-Route header to ensure that it is in the path of subsequent SIP requests for the same call leg. In the Record-Route field, the SIP proxy server adds its Request-URI.
16	Connect—SIP gateway 1 to PBX A	SIP gateway 1 sends a Connect message to PBX A. The Connect message notifies PBX A that the connection has been made.
17	Connect ACK—PBX A to SIP gateway 1	PBX A acknowledges SIP gateway 1's Connect message.
18	ACK—SIP gateway 1 to SIP proxy server	SIP gateway 1 sends an ACK to the SIP proxy server. The ACK confirms that SIP gateway 1 has received the 200 OK response from the SIP proxy server.
19	ACK—SIP proxy server to SIP gateway 2	Depending on the values in the To, From, CSeq, and Call-ID field, the SIP proxy server might process the ACK locally or proxy it. If the fields in the ACK match those in previous requests processed by the SIP proxy server, the server proxies the ACK. If there is no match, the ACK is proxied as if it were an INVITE request. The SIP proxy server forwards SIP gateway 1's ACK response to SIP gateway 2.
20	Connect ACK—SIP gateway 2 to PBX B	SIP gateway 2 acknowledges PBX B's Connect message. The call session is now active. The 2-way voice path is established directly between SIP gateway 1 and SIP gateway 2; not via the SIP proxy server.
At this point, a two-way voice path is established between SIP gateway 1 and PBX A and between SIP gateway 2 and PBX B. A two-way RTP channel is established between SIP gateway 1 and SIP gateway 2.
21	Disconnect—PBX B to SIP gateway 2	After the call is completed, PBX B sends a Disconnect message to SIP gateway 2. The Disconnect message starts the call session termination process.
22	BYE—SIP gateway 2 to SIP proxy server	SIP gateway 2 sends a BYE request to the SIP proxy server. The BYE request indicates that User B wants to release the call. Because it is User B that wants to terminate the call, the Request-URI field is now replaced with PBX A's SIP URL and the From field contains User B's SIP URL.
23	BYE—SIP proxy server to SIP gateway 1	The SIP proxy server forwards the BYE request to SIP gateway 1.
24	Disconnect—SIP gateway 1 to PBX A	SIP gateway 1 sends a Disconnect message to PBX A.
25	Release—SIP gateway 2 to PBX B	After the call is completed, SIP gateway 2 sends a Release message to PBX B.
26	Release—PBX A to SIP gateway 1	PBX A sends a Release message to SIP gateway 1.
27	200 OK—SIP gateway 1 to SIP proxy server	SIP gateway 1 sends a 200 OK response to the SIP proxy server. The 200 OK response notifies SIP gateway 2 that SIP gateway 1 has received the BYE request.
28	200 OK—SIP proxy server to SIP gateway 2	The SIP proxy server forwards the 200 OK response to SIP gateway 2.
29	Release Complete—PBX B to SIP gateway 2	PBX B sends a Release Complete message to SIP gateway 2.
30	Release Complete—SIP gateway 1 to PBX A	SIP gateway 1 sends a Release Complete message to PBX A and the call session is terminated.

Step	Action	Description
1	Setup—PBX A to SIP gateway 1	Call Setup is initiated between PBX A and SIP gateway 1. The Call Setup includes the standard transactions that take place as User A attempts to call User B.
2	INVITE—SIP gateway 1 to SIP proxy server	SIP gateway 1 sends an INVITE request to the SIP proxy server. The INVITE request is an invitation to User B to participate in a call session. In the INVITE request: The phone number of User B is inserted in the Request-URI field in the form of a SIP URL. The SIP URL identifies the address of User B and takes a form similar to an email address (user@host where user is the telephone number and host is either a domain name or a numeric network address). For example, the Request-URI field in the INVITE request to User B appears as "INVITE sip:555-0002@companyb.com; user=phone." The "user=phone" parameter distinquishes that the Request-URI address is a telephone number rather than a user name. 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 SIP gateway 1 is prepared to receive the RTP data is specified.
3	Call Proceeding—SIP gateway 1 to PBX A	SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
4	INVITE—SIP proxy server to SIP gateway 2	The SIP proxy server checks whether its own address is contained in the Via field (to prevent loops), directly copies the To, From, Call-ID, and Contact fields from the request it received from SIP gateway 1, changes the Request-URI to indicate the server to which it intends to send the INVITE request, and then sends a new INVITE request to SIP gateway 2.
5	100 Trying—SIP proxy server to SIP gateway 1	The SIP proxy server sends a 100 Trying response to SIP gateway 1.
6	Setup—SIP gateway 2 to PBX B	SIP gateway 2 receives the INVITE request from the SIP proxy server and initiates a Call Setup with User B via PBX B.
7	100 Trying—SIP gateway 2 to SIP proxy server	SIP gateway 2 sends a 100 Trying response to the SIP proxy server. The SIP proxy server might or might not forward the 100 Trying response to SIP gateway 1.
8	Call Proceeding—PBX B to SIP gateway 2	PBX B sends a Call Proceeding message to SIP gateway 2 to acknowledge the Call Setup request.
9	Alerting—PBX B to SIP gateway 2	PBX B locates User B and sends an Alert message to SIP gateway 2. User B's phone begins to ring.
10	180 Ringing—SIP gateway 2 to SIP proxy server	SIP gateway 2 sends a 180 Ringing response to the SIP proxy server.
11	180 Ringing—SIP proxy server to SIP gateway 1	The SIP proxy server forwards the 180 Ringing response to SIP gateway 1.
12	Alerting—SIP gateway 1 to PBX A	SIP gateway 1 sends an Alert message to User A via PBX A. The Alert message indicates that SIP gateway 1 has received a 180 Ringing response. User A hears the ringback tone that indicates that User B is being alerted.
At this point, a one-way voice path is established between SIP gateway 1 and PBX A and between SIP gateway 2 and PBX B. A two-way RTP channel is established between SIP gateway 1 and SIP gateway 2.
13	Connect—PBX B to SIP gateway 2	User B answers the phone. PBX B sends a Connect message to SIP gateway 2. The connect message notifies SIP gateway 2 that the connection has been made.
14	200 OK—SIP gateway 2 to SIP proxy server	SIP gateway 2 sends a 200 OK response to the SIP proxy server. The 200 OK response notifies the SIP proxy server that the connection has been made. If User B supports the media capability advertised in the INVITE message sent by the SIP proxy server, it advertises the intersection of its own and User A's media capability in the 200 OK response. If User B does not support the media capability advertised by User A, it sends back a 400 Bad Request response with a 304 Warning header field. The SIP proxy server must forward 200 OK responses upstream.
15	200 OK—SIP proxy server to SIP gateway 1	The SIP proxy server forwards the 200 OK response that it received from SIP gateway 2 to SIP gateway 1.
16	Connect—SIP gateway 1 to PBX A	SIP gateway 1 sends a Connect message to PBX A. The Connect message notifies PBX A that the connection has been made.
17	Connect ACK—PBX A to SIP gateway 1	PBX A acknowledges SIP gateway 1's Connect message.
18	ACK—SIP gateway 1 to SIP gateway 2	SIP gateway 1 sends an ACK to SIP gateway 2. The ACK confirms that SIP gateway 1 has received the 200 OK response from the SIP proxy server.
19	Connect ACK—SIP gateway 2 to PBX B	SIP gateway 2 acknowledges PBX B's Connect message. The call session is now active. The 2-way voice path is established directly between SIP gateway 1 and SIP gateway 2; not via the SIP proxy server.
At this point, a two-way voice path is established between SIP gateway 1 and PBX A and between SIP gateway 2 and PBX B. A two-way RTP channel is established between SIP gateway 1 and SIP gateway 2.
20	Disconnect—PBX B to SIP gateway 2	After the call is completed, PBX B sends a Disconnect message to SIP gateway 2. The Disconnect message starts the call session termination process.
21	BYE—SIP gateway 2 to SIP gateway 1	SIP gateway 2 sends a BYE request to SIP gateway 1. The BYE request indicates that User B wants to release the call. Because it is User B that wants to terminate the call, the Request-URI field is now replaced with PBX A's SIP URL and the From field contains User B's SIP URL.
22	Disconnect—SIP gateway 1 to PBX A	SIP gateway 1 sends a Disconnect message to PBX A.
23	Release—SIP gateway 2 to PBX B	After the call is completed, SIP gateway 2 sends a Release message to PBX B.
24	Release—PBX A to SIP gateway 1	PBX A sends a Release message to SIP gateway 1.
25	200 OK—SIP gateway 1 to SIP gateway 2	SIP gateway 1 sends a 200 OK response to SIP gateway 2. The 200 OK response notifies SIP gateway 2 that SIP gateway 1 has received the BYE request.
26	Release Complete—PBX B to SIP gateway 2	PBX B sends a Release Complete message to SIP gateway 2.
27	Release Complete—SIP gateway 1 to PBX A	SIP gateway 1 sends a Release Complete message to PBX A and the call session is terminated.

SIP Gateway-to-SIP Gateway Call—Call Setup with Delayed Media via Third-Party Call Controller

Figure 7-5 illustrates a successful gateway-to-gateway call setup via a third-party call control agent.

Step	Action	Description
1	INVITE—Call controller to SIP gateway 2	The third party call control agent sends an INVITE request to SIP gateway 2. The INVITE request is an invitation to User B to participate in a call session. In the INVITE request: The phone number of User B is inserted in the Request-URI field in the form of a SIP URL. The SIP URL identifies the address of User B and takes a form similar to an email address (user@host where user is the telephone number and host is either a domain name or a numeric network address). For example, the Request-URI field in the INVITE request to User B appears as "INVITE sip:555-0002@companyb.com; user=phone." The "user=phone" parameter indicates that the Request-URI address is a telephone number rather than a user name. 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 SDP media line is omitted or the INVITE does not contain any SDP information.
2	INVITE—Call controller to SIP gateway 1	The third party call control agent sends an INVITE request to SIP gateway 1. The INVITE request is an invitation to User A to participate in a call session. In the INVITE request: The phone number of User A is inserted in the Request-URI field in the form of a SIP URL. The SIP URL identifies the address of User A and takes a form similar to an email address (user@host where user is the telephone number and host is either a domain name or a numeric network address). For example, the Request-URI field in the INVITE request to User A appears as "INVITE sip:555-0002@companyb.com; user=phone." The "user=phone" parameter indicates that the Request-URI address is a telephone number rather than a user name. 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 SDP media line is omitted or the INVITE does not contain any SDP information.
3	Setup—SIP gateway 2 to PBX B	SIP gateway 2 receives the INVITE request from the call controller and initiates a Call Setup with User B via PBX B.
4	Setup—SIP gateway 1 to PBX A	SIP gateway 1 receives the INVITE request from the call controller and initiates a Call Setup with User A via PBX A.
5	100 Trying—SIP gateway 2 to call controller	SIP gateway 2 sends a 100 Trying response to the INVITE request sent by the call controller. The 100 Trying response indicates that the INVITE request has been received by SIP gateway 2 but that User B has not yet been located and that some unspecified action, such as a database consultation, is taking place.
6	Call Proceeding—PBX B to SIP gateway 2	PBX B sends a Call Proceeding message to SIP gateway 2 to acknowledge the Call Setup request.
7	100 Trying—SIP gateway 1 to call controller	SIP gateway 1 sends a 100 Trying response to the INVITE request sent by the call controller. The 100 Trying response indicates that the INVITE request has been received by SIP gateway 2 but that User A has not yet been located and that some unspecified action, such as a database consultation, is taking place.
8	Call Proceeding—PBX A to SIP gateway 1	PBX A sends a Call Proceeding message to SIP gateway 1 to acknowledge the Call Setup request.
9	183 Session Progress—SIP gateway 2 to call controller	SIP gateway 2 sends a 183 Session Progress message to the call controller.
10	183 Session Progress—SIP gateway 1 to call controller	SIP gateway 1 sends a 183 Session Progress message to the call controller.
11	Connect—PBX A to SIP gateway 1	User A answers phone. PBX A sends a Connect message to SIP gateway 1. The Connect message notifies SIP gateway 1 that the connection has been made.
12	200 OK—SIP gateway 1 to call controller	SIP gateway 1 sends a 200 OK response to the call controller. The 200 OK response notifies the call controller that the connection has been made. In the call 200 OK response, the SDP information of User A is specified.
13	Connect ACK—SIP gateway 1 to PBX A	SIP gateway 1 acknowledges PBX A's Connect message.
14	Connect—PBX B to SIP gateway 2	PBX B sends a Connect message to SIP gateway 2. The Connect message notifies SIP gateway 2 that the connection has been made.
15	200 OK—SIP gateway 2 to call controller	SIP gateway 2 sends a 200 OK response to the call controller. The 200 OK response notifies the call controller that the connection has been made. In the call 200 OK response, the SDP information of User B is specified.
16	Connect ACK—SIP gateway 2 to PBX B	SIP gateway 2 acknowledges PBX B's Connect message.
17	ACK—Call controller to SIP gateway 1	The call controller sends an ACK response to SIP gateway 1. The ACK response confirms that the call controller has received the 200 OK response from SIP gateway 1. In the ACK response, the SDP information of User B is specified. Media negotiation takes place.
14	ACK—Call controller to SIP gateway 2	The call controller sends an ACK response to SIP gateway 2. The ACK response confirms that the call controller has received the 200 OK response from SIP gateway 2. In the ACK response, the SDP information of User A is specified. Media negotiation takes place.
At this point, a two-way voice path is established between SIP gateway 1 and PBX A and between SIP gateway 2 and PBX B. A two-way RTP channel is established between SIP gateway 1 and SIP gateway 2.

SIP Gateway-to-SIP Gateway—Call Setup using a FQDN and Delayed Media

Figure 7-6 illustrates a successful gateway-to-gateway call setup using delayed media and a FQDN in the SDP session connection parameter.

Step	Action	Description
1	INVITE—Call controller to SIP gateway 2	The third party call control agent sends an INVITE request to SIP gateway 2. The INVITE request is an invitation to User B to participate in a call session. In the INVITE request: The phone number of User B is inserted in the Request-URI field in the form of a SIP URL. The SIP URL identifies the address of User B and takes a form similar to an email address (user@host where user is the telephone number and host is either a domain name or a numeric network address). For example, the Request-URI field in the INVITE request to User B appears as "INVITE sip:555-0002@companyb.com; user=phone." The "user=phone" parameter indicates that the Request-URI address is a telephone number rather than a user name. 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 SDP media line is omitted or the INVITE does not contain any SDP information.
2	INVITE—Call controller to SIP gateway 1	The third party call control agent sends an INVITE request to SIP gateway 1. The INVITE request is an invitation to User A to participate in a call session. In the INVITE request: The phone number of User A is inserted in the Request-URI field in the form of a SIP URL. The SIP URL identifies the address of User A and takes a form similar to an email address (user@host where user is the telephone number and host is either a domain name or a numeric network address). For example, the Request-URI field in the INVITE request to User A appears as "INVITE sip:555-0002@companyb.com; user=phone." The "user=phone" parameter indicates that the Request-URI address is a telephone number rather than a user name. 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 SDP media line is omitted or the INVITE does not contain any SDP information.
3	Setup—SIP gateway 2 to PBX B	SIP gateway 2 receives the INVITE request from the call controller and initiates a Call Setup with User B via PBX B.
4	Setup—SIP gateway 1 to PBX A	SIP gateway 1 receives the INVITE request from the call controller and initiates a Call Setup with User A via PBX A.
5	100 Trying—SIP gateway 2 to call controller	SIP gateway 2 sends a 100 Trying response to the INVITE request sent by the call controller. The 100 Trying response indicates that the INVITE request has been received by SIP gateway 2 but that User B has not yet been located and that some unspecified action, such as a database consultation, is taking place.
6	Call Proceeding—PBX B to SIP gateway 2	PBX B sends a Call Proceeding message to SIP gateway 2 to acknowledge the Call Setup request.
7	100 Trying—SIP gateway 1 to call controller	SIP gateway 1 sends a 100 Trying response to the INVITE request sent by the call controller. The 100 Trying response indicates that the INVITE request has been received by SIP gateway 2 but that User A has not yet been located and that some unspecified action, such as a database consultation, is taking place.
8	Call Proceeding—PBX A to SIP gateway 1	PBX A sends a Call Proceeding message to SIP gateway 1 to acknowledge the Call Setup request.
9	183 Session Progress—SIP gateway 2 to call controller	SIP gateway 2 sends a 183 Session Progress message to the call controller.
10	183 Session Progress—SIP gateway 1 to call controller	SIP gateway 1 sends a 183 Session Progress message to the call controller.
11	Connect—PBX A to SIP gateway 1	User A answers phone. PBX A sends a Connect message to SIP gateway 1. The Connect message notifies SIP gateway 1 that the connection has been made.
12	200 OK—SIP gateway 1 to call controller	SIP gateway 1 sends a 200 OK response to the call controller. The 200 OK response notifies the call controller that the connection has been made. In the call 200 OK response, the SDP information of User A is specified.
13	Connect ACK—SIP gateway 1 to PBX A	SIP gateway 1 acknowledges PBX A's Connect message.
14	Connect—PBX B to SIP gateway 2	PBX B sends a Connect message to SIP gateway 2. The Connect message notifies SIP gateway 2 that the connection has been made.
15	200 OK—SIP gateway 2 to call controller	SIP gateway 2 sends a 200 OK response to the call controller. The 200 OK response notifies the call controller that the connection has been made. In the call 200 OK response, the SDP information of User B is specified.
16	Connect ACK—SIP gateway 2 to PBX B	SIP gateway 2 acknowledges PBX B's Connect message.
17	ACK—Call controller to SIP gateway 1	The call controller sends an ACK response to SIP gateway 1. The ACK response confirms that the call controller has received the 200 OK response from SIP gateway 1. In the ACK response the media capability of User B is specified and the domain name of gateway 2 is specified in the SDP sessions parameter (c=) field. Media negotiation takes place. At this point, a DNS query is performed by SIP gateway 1 to resolve c=IN IP4 gw2.com.
18	ACK—Call controller to SIP gateway 2	The call controller sends an ACK to SIP gateway 2. The ACK confirms that the call controller has received the ACK response from SIP gateway 2. In the 200 OK response the media capability of User A is specified and the domain name of gateway 1 is specified in the SDP sessions parameter (c=). Media negotiation takes place. At this point, a DNS query is performed by SIP gateway 2 to resolve c=IN IP4 gw1.com.
At this point, a two-way voice path is established between SIP gateway 1 and PBX A and between SIP gateway 2 and PBX B. A two-way RTP channel is established between SIP gateway 1 and SIP gateway 2.

SIP Gateway-to- SIP Gateway Call—Redirection with CC-Diversion

Figure 7-7 illustrates a successful gateway-to-gateway call setup with call redirection with CC-Diversion.

In this scenario, the three end users are identified as Alice at phone A, Bob at phone B, and Carol at phone C. Alice at phone A is located at PBX A. PBX A is connected to SIP gateway 1 via a T1/E1. SIP gateway 1 is using a SIP redirect server. Bob at phone B and Carol at phone C are located at PBX B. PBX B is connected to SIP gateway 2 via a T1/E1. SIP gateway 1 is connected to SIP gateway 2 over an IP network.

1. Alice at phone A initiates a call with Bob via SIP gateway 1 that is using a SIP proxy server.

2. The proxy server returns Carol at SIP gateway 2 as a contact location for Bob.

Step	Action	Description
1	Setup—PBX A to SIP gateway 1	Call Setup is initiated between PBX A and SIP gateway 1. The Call Setup includes the standard transactions that take place as Alice at phone A attempts to call Bob at phone B.
2	Call Proceeding—SIP gateway 1 to PBX A	SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
3	INVITE—SIP gateway 1 to SIP proxy server	SIP gateway 1 sends an INVITE request to the proxy server. The INVITE request is an invitation to Bob to participate in a call session. In the INVITE request: Bob's phone number is inserted in the Request-URI field in the form of a SIP URL. The SIP URL identifies Bob's address and takes a form similar to an email address (user@host where user is the telephone number and host is either a domain name or a numeric network address). For example, the Request-URI field in the INVITE request to Bob might appear as "INVITE sip:555-0002@companyb.com; user=phone." The "user=phone" parameter distinguishes that the Request-URI address is a telephone number rather than a user name. Alice (via SIP gateway 1) is identified as the call session initiator in the From field. A unique numeric identifier is assigned to the call and inserted in the Call-ID field. The transaction number within a single call leg is identified in the CSeq field. The media capability SIP gateway 1 is ready to receive is specified in the SDP. The port on which SIP gateway 1 is prepared to receive the RTP data is specified in the SDP. Alice at SIP gateway 1 is specified as a CC-Diversion header. In addition, the CC-Diversion header field contains a reason for the diversion and a counter. Possible values for the diversion reason include the following: unknown, user-busy, no-answer, unconditional, deflection, and follow-me.
4	302 Moved Temporarily—SIP proxy server to SIP gateway 1	The SIP proxy server determines that Bob's calls have been configured to be redirected to Carol at phone C via SIP gateway 2. The SIP proxy server sends a 302 Moved Temporarily message to SIP gateway 1. In the 302 Moved Temporarily message, Carol at SIP gateway 2 is added as the Contact and there are two CC-Diversion header fields included; one for Bob at GW2 (IP address or domain name) and one for Alice at SIP gateway 1 (IP address or domain name).
5	ACK—SIP gateway 1 to SIP proxy server	SIP gateway 1 sends an ACK to the SIP proxy server. The ACK confirms that the 302 Moved Temporarily response has been received.
6	INVITE—SIP gateway 1 to SIP gateway 2	SIP gateway 1 sends an INVITE request to Carol at phone C via SIP gateway 2. The INVITE request contains two CC-Diversion headers; one for Bob at SIP gateway 2 (IP address or domain name) and one for Alice at SIP gateway 1 (IP address or domain name).
7	Setup—SIP gateway 2 to PBX B	SIP gateway 2 receives the INVITE request from SIP gateway 1 and initiates a Call Setup with Carol via PBX B. In the Call Setup, the ISDN Redirecting Number IE is generated using the contents of the top CC-Diversion header field; in this case, Bob at SIP gateway 2.
8	Call Proceeding—PBX B to SIP gateway 2	PBX B sends a Call Proceeding message to SIP gateway 2 to acknowledge the Call Setup request.
9	Alerting—PBX B to SIP gateway 2	PBX B locates Carol at phone C and sends an Alert message to SIP gateway 2. Carol's phone begins to ring.
10	180 Ringing—SIP gateway 2 to SIP gateway 1	SIP gateway 2 sends a 180 Ringing response to SIP gateway 1. The 180 Ringing response indicates that SIP gateway 2 has located, and is trying to alert, Carol at phone C.
11	Alerting—SIP gateway 1 to PBX A	SIP gateway 1 sends an Alert message to PBX A. Alice hears ringback tone.
At this point, a one-way voice path is established between SIP gateway 1 and PBXA and between SIP gateway 2 and PBX B. A two-way RTP channel is established between SIP gateway 1 and SIP gateway 2.
12	Connect—PBX B to SIP gateway 2	Carol answers phone. PBX B sends a Connect message to SIP gateway 2. The Connect message notifies SIP gateway 2 that the connection has been made.
13	200 OK—SIP gateway 2 to SIP gateway 1	SIP gateway 2 sends a 200 OK response to SIP gateway 1. The 200 OK response notifies SIP gateway 1 that the connection has been made. If Carol via SIP gateway 2 supports the media capability advertised in the INVITE message sent by SIP gateway 1, it advertises the intersection of its own and Alice's media capability in the 200 OK response. If Carol at SIP gateway 2 does not support the media capability advertised by Alice at SIP gateway 1, SIP gateway 2 sends back a 400 Bad Request response with a "Warning: 304 Codec negotiation failed" header field.
14	Connect—SIP gateway 1 to PBX A	SIP gateway 1 sends a Connect message to PBX A. The Connect message notifies PBX A that the connection has been made.
15	Connect ACK—PBX A to SIP gateway 1	PBX A acknowledges SIP gateway 1's Connect message.
16	ACK—SIP gateway 1 to SIP gateway 2	SIP gateway 1 sends an ACK to SIP gateway 2. The ACK confirms that the 200 OK response has been received. The call is now in progress over a two-way voice path via RTP.
17	Connect ACK—SIP gateway 2 to PBX B	SIP gateway 2 acknowledges PBX B's Connect message.
At this point, a two-way voice path is established between SIP gateway 1 and PBX A and between SIP gateway 2 and PBX B. A two-way RTP channel is established between SIP gateway 1 and SIP gateway 2.

SIP Gateway-to-SIP Gateway Call—SIP 3xx Redirection Response

Figure 7-8 illustrates a successful gateway-to-gateway call setup in which a SIP 3xx Redirection response is processed after the receipt of a SIP 18x Information response.

1. Alice at phone A initiates a call with Bob via SIP gateway 1that is using a SIP proxy server.

2. The proxy server returns Carol at SIP gateway 2 as a contact location for Bob.

Step	Action	Description
1	Setup—PBX A to SIP gateway 1	Call Setup is initiated between PBX A and SIP gateway 1. The Call Setup includes the standard transactions that take place as Alice at phone A attempts to call Bob at phone B.
2	Call Proceeding—SIP gateway 1 to PBX A	SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
3	INVITE—SIP gateway 1 to SIP proxy server	SIP gateway 1 sends an INVITE request to the proxy server. The INVITE request is an invitation to Bob to participate in a call session. In the INVITE request: Bob's phone number is inserted in the Request-URI field in the form of a SIP URL. The SIP URL identifies Bob's address and takes a form similar to an email address (user@host where user is the telephone number and host is either a domain name or a numeric network address). For example, the Request-URI field in the INVITE request to Bob might appear as "INVITE sip:555-0002@companyb.com; user=phone." The "user=phone" parameter distinguishes that the Request-URI address is a telephone number rather than a user name. Alice via SIP gateway 1 is identified as the call session initiator in the From field. A unique numeric identifier is assigned to the call and inserted in the Call-ID field. The transaction number within a single call leg is identified in the CSeq field. The media capability SIP gateway 1 is ready to receive is specified in the SDP. The port on which SIP gateway 1 is prepared to receive the RTP data is specified in the SDP. Alice at SIP gateway 1 is specified as a CC-Diversion header. In addition, the CC-Diversion header field contains a reason for the diversion and a counter. Possible values for the diversion reason include the following: unknown, user-busy, no-answer, unconditional, deflection, and follow-me.
4	100 Trying—SIP proxy server to SIP gateway 1	The 100 Trying response indicates that the INVITE request has been received.
5	302 Moved Temporarily—SIP proxy server to SIP gateway 1	The SIP proxy server determines that Bob's calls have been configured to be redirected to Carol at phone C via SIP gateway 2. The SIP proxy server sends a 302 Moved Temporarily message to SIP gateway 1. In the 302 Moved Temporarily message, Carol at SIP gateway 2 is added as the Contact and there are two CC-Diversion header fields included; one for Alice at SIP gateway 1 (IP address or domain name) and Bob at SIP gateway 2 (IP address or domain name).
6	INVITE—SIP gateway 1 to SIP gateway 2	SIP gateway 1 sends an INVITE request to Carol at phone C via SIP gateway 2. The INVITE request contains two CC-Diversion headers; one for Alice at SIP gateway 1 (IP address or domain name) and Bob at SIP gateway 2 (IP address or domain name).
7	Setup—SIP gateway 2 to PBX B	SIP gateway 2 receives the INVITE request from SIP gateway 1 and initiates a Call Setup with Carol via PBX B. In the Call Setup, the ISDN Redirecting Number IE is generated using the contents of the top CC-Diversion header field; in this case, Bob at SIP gateway 2.
8	Call Proceeding—PBX B to SIP gateway 2	PBX B sends a Call Proceeding message to SIP gateway 2 to acknowledge the Call Setup request.
9	Alerting—PBX B to SIP gateway 2	PBX B locates Carol at phone C and sends an Alert message to SIP gateway 2. Carol's phone begins to ring.
10	180 Ringing—SIP gateway 2 to SIP gateway 1	SIP gateway 2 sends a 180 Ringing response to SIP gateway 1. The 180 Ringing response indicates that SIP gateway 2 has located, and is trying to alert, Carol at phone C.
11	Alerting—SIP gateway 1 to PBX A	SIP gateway 1 sends an Alert message to PBX A. Alice hears ringback tone.
At this point, a one-way voice path is established between SIP gateway 1 and PBXA and between SIP gateway 2 and PBX B. A two-way RTP channel is established between SIP gateway 1 and SIP gateway 2.
12	Connect—PBX B to SIP gateway 2	Carol answers phone. PBX B sends a Connect message to SIP gateway 2. The Connect message notifies SIP gateway 2 that the connection has been made.
13	200 OK—SIP gateway 2 to SIP gateway 1	SIP gateway 2 sends a 200 OK response to SIP gateway 1. The 200 OK response notifies SIP gateway 1 that the connection has been made. If Carol via SIP gateway 2 supports the media capability advertised in the INVITE message sent by SIP gateway 1, it advertises the intersection of its own and Alice's media capability in the 200 OK response. If Carol at SIP gateway 2 does not support the media capability advertised by Alice at SIP gateway 1, SIP gateway 2 sends back a 400 Bad Request response with a "Warning: 304 Codec negotiation failed" header field.
14	Connect—SIP gateway 1 to PBX A	SIP gateway 1 sends a Connect message to PBX A. The Connect message notifies PBX A that the connection has been made.
15	Connect ACK—PBX A to SIP gateway 1	PBX A acknowledges SIP gateway 1's Connect message.
16	ACK—SIP gateway 1 to SIP gateway 2	SIP gateway 1 sends an ACK to SIP gateway 2. The ACK confirms that the 200 OK response has been received. The call is now in progress over a two-way voice path via RTP.
17	Connect ACK—SIP gateway 2 to PBX B	SIP gateway 2 acknowledges PBX B's Connect message.
At this point, a two-way voice path is established between SIP gateway 1 and PBX A and between SIP gateway 2 and PBX B. A two-way RTP channel is established between SIP gateway 1 and SIP gateway 2.

SIP Gateway-to-SIP IP Phone—Successful Call Setup and Disconnect

Figure 7-9 illustrates a successful gateway-to-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 SIP gateway 1 via a T1/E1. User B is located at a SIP IP phone. SIP gateway 1 is connected to the SIP IP phone over an IP network.

Step	Action	Description
1	Setup—PBX A to SIP gateway 1	Call Setup is initiated between PBX A and SIP gateway 1. The Call Setup includes the standard transactions that take place as User A attempts to call User B.
2	INVITE—SIP gateway 1 to SIP IP phone	SIP 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. SIP gateway 1 sends an INVITE request to the address it receives in the dial peer which, in this scenario, is the SIP IP phone. In the INVITE request: The IP address of the 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 SIP gateway is prepared to receive the RTP data is specified.
3	Call Proceeding—SIP gateway 1 to PBX A	SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
4	100 Trying—SIP IP phone to SIP gateway 1	The SIP IP phone sends a 100 Trying response to SIP gateway 1. The 100 Trying response indicates that the INVITE request has been received by the SIP IP phone.
5	180 Ringing—SIP IP phone to SIP gateway 1	The SIP IP phone sends a 180 Ringing response to SIP gateway 1. The 180 Ringing response indicates that the user is being alerted.
6	Alerting—SIP gateway 1 to PBX A	SIP gateway 1 sends an Alert message to User A. The Alert message indicates that SIP gateway 1 has received a 180 Ringing response from the SIP IP phone. User A hears the ringback tone that indicates that User B is being alerted.
7	200 OK—SIP IP phone to SIP gateway 1	The SIP IP phone sends a 200 OK response to SIP gateway 1. The 200 OK response notifies SIP gateway 1 that the connection has been made.
8	Connect—SIP gateway 1 to PBX A	SIP 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 SIP gateway 1	PBX A acknowledges SIP gateway 1's Connect message.
10	ACK—SIP gateway 1 to SIP IP phone	SIP gateway 1 sends an ACK to the SIP IP phone. The ACK confirms that SIP gateway 1 has received the 200 OK response. The call session is now active.
At this point, a two-way voice path is established between SIP gateway 1 and PBX A. A two-way RTP channel is established between SIP gateway 1 and SIP IP phone B.
11	BYE—SIP IP phone to SIP gateway 1	User B terminates the call session at his SIP IP phone and the phone sends a BYE request to SIP gateway 1. The BYE request indicates that User B wants to release the call.
12	Disconnect—SIP gateway 1 to PBX A	SIP gateway 1 sends a Disconnect message to PBX A.
13	Release—PBX A to SIP gateway 1	PBX A sends a Release message to SIP gateway 1.
14	200 OK—SIP gateway 1 to SIP IP phone	SIP gateway 1 sends a 200 OK response to the SIP IP phone. The 200 OK response notifies the phone that SIP gateway 1 has received the BYE request.
15	Release Complete—SIP gateway 1 to PBX A	SIP gateway 1 sends a Release Complete message to PBX A and the call session is terminated.

SIP Gateway-to-SIP IP Phone—Successful Call Setup and Call Hold

Figure 7-10 illustrates a successful gateway-to-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 SIP gateway 1 via a T1/E1. User B is located at a SIP IP phone. SIP gateway 1 is connected to the SIP IP phone over an IP network.

Step	Action	Description
1	Setup—PBX A to SIP gateway 1	Call Setup is initiated between PBX A and SIP gateway 1. The Call Setup includes the standard transactions that take place as User A attempts to call User B.
2	INVITE—SIP gateway 1 to SIP IP phone	SIP 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. SIP gateway 1 sends an INVITE request to the address it receives in the dial peer which, in this scenario, is the SIP IP phone. In the INVITE request: The IP address of the 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 SIP gateway is prepared to receive the RTP data is specified.
3	Call Proceeding—SIP gateway 1 to PBX A	SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
4	100 Trying—SIP IP phone to SIP gateway 1	The SIP IP phone sends a 100 Trying response to SIP gateway 1. The 100 Trying response indicates that the INVITE request has been received by the SIP IP phone.
5	180 Ringing—SIP IP phone to SIP gateway 1	The SIP IP phone sends a 180 Ringing response to SIP gateway 1. The 180 Ringing response indicates that the user is being alerted.
6	Alerting—SIP gateway 1 to PBX A	SIP gateway 1 sends an Alert message to User A. The Alert message indicates that SIP gateway 1 has received a 180 Ringing response from the SIP IP phone. User A hears the ringback tone that indicates that User B is being alerted.
7	200 OK—SIP IP phone to SIP gateway 1	The SIP IP phone sends a 200 OK response to SIP gateway 1. The 200 OK response notifies SIP gateway 1 that the connection has been made.
8	Connect—SIP gateway 1 to PBX A	SIP gateway 1 sends a Connect message to PBX A. The Connect message notifies PBX A that the connection has been made.
9	ACK—SIP gateway 1 to SIP IP phone	SIP gateway 1 sends an ACK to the 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 SIP gateway 1	PBX A acknowledges SIP gateway 1's Connect message.
At this point, a two-way voice path is established between SIP gateway 1 and PBX A. A two-way RTP channel is established between SIP gateway 1 and SIP IP phone B.
11	INVITE—SIP IP phone to SIP gateway 1	SIP IP phone B sends a mid-call INVITE to the SIP gateway with new SDP session parameters (IP address), which are used to place the call on hold. The SIP INVITE contains an invalid IP address, which places the call in limbo. SDP: c=IN IP4 0.0.0.0
12	200 OK—SIP gateway 1 to SIP IP phone	SIP gateway 1 sends a 200 OK response to the SIP IP phone. The 200 OK response notifies the SIP IP phone that the INVITE was successfully processed.
13	ACK—SIP IP phone to SIP gateway 1	The SIP IP phone sends an ACK to SIP gateway 1. The ACK confirms that the SIP IP phone has received the 200 OK response. The call session is now temporarily inactive. No RTP packets are being sent.
The two-way RTP channel is torn down. The call is on hold.
14	INVITE—SIP IP phone to SIP gateway 1	SIP IP phone B sends a mid-call INVITE to SIP gateway 1 with the same call ID as the previous INVITE and new SDP session parameters (IP address), which are used to re-establish the call. SDP: c=IN IP4 IP-UserB
15	200 OK—SIP gateway 1 to SIP IP phone	SIP gateway 1 sends a 200 OK response to the SIP IP phone. The 200 OK response notifies the SIP IP phone that the INVITE was successfully processed.
16	ACK—SIP IP phone to SIP gateway 1	The SIP IP phone sends an ACK to SIP gateway 1. The ACK confirms that the SIP IP phone has received the 200 OK response. The call session is now active.
At this point, a two-way voice path exists between SIP gateway 1 and PBX A and the two-way RTP channel is re-established between SIP gateway 1 and SIP IP phone B.

SIP Gateway-to-SIP IP Phone—Successful Call Setup and Transfer

Figure 7-11 illustrates a successful gateway-to-SIP IP phone call setup and call transfer without consultation. In this scenario, there are three end users: User A, User B, and User C. User A is located at PBX A. PBX A is connected to SIP gateway 1 via a T1/E1. User B is located at a SIP IP phone and is directly connected to the IP network. User C is located at PBX B. PBX B is connected to SIP gateway 2 via a T1/E1. SIP gateway 1, SIP gateway 2, and the SIP IP phone are connected to one another over an IP network.

Step	Action	Description
1	Setup—PBX A to SIP gateway 1	Call Setup is initiated between PBX A and SIP gateway 1. The Call Setup includes the standard transactions that take place as User A attempts to call User B.
2	INVITE—SIP gateway 1 to SIP IP phone	SIP 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. SIP gateway 1 sends an INVITE request to the address it receives in the dial peer which, in this scenario, is the SIP IP phone. In the INVITE request: The IP address of the 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 SIP gateway is prepared to receive the RTP data is specified.
3	Call Proceeding—SIP gateway 1 to PBX A	SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
4	100 Trying—SIP IP phone to SIP gateway 1	The SIP IP phone sends a 100 Trying response to SIP gateway 1. The 100 Trying response indicates that the INVITE request has been received by the SIP IP phone.
5	180 Ringing—SIP IP phone to SIP gateway 1	The SIP IP phone sends a 180 Ringing response to SIP gateway 1. The 180 Ringing response indicates that the user is being alerted.
6	Alerting—SIP gateway 1 to PBX A	SIP gateway 1 sends an Alert message to User A. The Alert message indicates that SIP gateway 1 has received a 180 Ringing response from the SIP IP phone. User A hears the ringback tone that indicates that User B is being alerted.
7	200 OK—SIP IP phone to SIP gateway 1	The SIP IP phone sends a 200 OK response to SIP gateway 1. The 200 OK response notifies SIP gateway 1 that the connection has been made.
8	Connect—SIP gateway 1 to PBX A	SIP 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 SIP gateway 1	PBX A acknowledges SIP gateway 1's Connect message.
10	ACK—SIP gateway 1 to SIP IP phone	SIP gateway 1 sends an ACK to the SIP IP phone. The ACK confirms that SIP gateway 1 has received the 200 OK response. The call session is now active.
At this point, a two-way voice path is established between SIP gateway 1 and PBX A. A two-way RTP channel is established between SIP gateway 1 and SIP IP phone B.
11	BYE—SIP IP phone to SIP gateway 1	User B transfers User A's call to User C and then hangs up. The SIP IP phone sends a BYE request to SIP gateway 1. The BYE request includes the Also header. In this scenario, the Also header indicates that User C must be brought into the call while User B hangs up. This header distinguishes the call transfer BYE request from a normal disconnect BYE request. The Request-By header could be included in the BYE request, however, Cisco Systems' implementation does not require the header to complete the transfer. If the Requested-By header is included, the INVITE sent to the transferred-to party will include the Requested-By header. If the Requested-By header is not included, the INVITE sent to the transferred-to party will not include the Requested-By header.
12	200 OK—SIP gateway 1 to SIP IP phone	SIP gateway 1 sends a 200 OK message to the SIP IP phone. The 200 OK response notifies the SIP IP phone that the BYE request has been received. The call session between User A and User B is now terminated.
13	INVITE—SIP gateway 1 to SIP gateway 2	SIP gateway 1 sends an INVITE request to SIP gateway 2. In the INVITE request, a unique Call-ID is generated and the Requested-By field indicates that User B requested the call.
14	Setup—SIP gateway 2 to PBX B	SIP gateway 2 receives the INVITE request from SIP gateway 1 and initiates a Call Setup with User C via PBX B.
15	100 Trying—SIP gateway 2 to SIP gateway 1	SIP gateway 2 sends a 100 Trying response to the INVITE request sent by SIP gateway 1. The 100 Trying response indicates that SIP gateway 2 has received the INVITE request but that User C has not yet been located.
16	Call Proceeding—PBX B to SIP gateway 2	PBX B sends a Call Proceeding message to SIP gateway 2. User C's phone begins to ring.
17	Alerting—PBX B to SIP gateway 2	PBX B sends an Alert message to SIP gateway 2. The message indicates that the PBX is attempting to alert the user of the call (that is to say, the phone is ringing).
18	180 Ringing—SIP gateway 2 to SIP gateway 1	SIP gateway 2 sends a 180 Ringing response to SIP gateway 1. The 180 Ringing response indicates that SIP gateway 2 has located, and is trying to alert, User C.
19	Alerting—SIP gateway 1 to PBX A	SIP gateway 1 sends an Alert message to PBX A. The Alert message indicates that SIP gateway 1 has received a 180 Ringing response from the SIP IP phone. User A hears the ringback tone that indicates that User C is being alerted.
20	Connect—PBX B to SIP gateway 2	User C answers the phone. PBX B sends a Connect message to SIP gateway 2. The Connect message notifies SIP gateway 2 that the connection has been made.
21	200 OK—SIP gateway 2 to SIP gateway 1	SIP gateway 2 sends a 200 OK response to SIP gateway 1. The 200 OK response notifies SIP gateway 1 that the connection has been made. If User C supports the media capability advertised in the INVITE message sent by User A, it advertises the intersection of its own and User A's media capability in the 200 OK response. If User C does not support the media capability advertised by User A, it sends back a 400 Bad Request response with a 304 Warning header field.
22	Connect—SIP gateway 1 to PBX A	SIP gateway 1 sends a Connect message to PBX A. The Connect message notifies PBX A that the connection has been made.
23	Connect ACK—PBX A to SIP gateway 1	PBX A acknowledges SIP gateway 1's Connect message.
24	ACK—SIP gateway 1 to SIP gateway 2	SIP gateway 1 sends an ACK to SIP gateway 2. The ACK confirms that SIP gateway 1 has received the 200 OK message from SIP gateway 2.
25	Connect ACK—SIP gateway 2 to PBX B	SIP gateway 2 acknowledges PBX B's Connect message.
At this point, a two-way voice path is established between SIP gateway 1 and PBX A and between SIP gateway 2 and PBX B. A two-way RTP channel is established between SIP gateway 1 and SIP gateway 2.

SIP Gateway-to-uOne Call—Call Setup with Voice Mail

Step	Action	Description
1	INVITE—SIP gateway 1 to application server	SIP gateway 1 sends an INVITE request to the application server.
2	INVITE—Application server to SIP gateway 2	The application server sends the INVITE request to SIP gateway 2.
3	183 Session Progress—SIP gateway 2 to application server	SIP gateway 2 sends a 183 Session Progress message to the application server.
4	183 Session Progress—Application server to SIP gateway 1	The application server proxies the 183 Session Progress message to SIP gateway 1.
At this point, a timeout occurs.
5	Voice Mail control messages—Application server to uOne server	The application server forwards voice mail control messages to the uOne server (media server).
6	200 OK—uOne server to application server	The uOne server sends a 200 OK response to the application server. In the 200 OK response, the uOne server SDP is included.
7	200 OK response—Application server to SIP gateway 1	The application server proxies the 200 OK response to the SIP gateway. In the 200 OK response, the uOne server SDP is included.

SIP IP Phone-to-SIP Gateway—Automatic Route Selection

Figure 7-13, Figure 7-14, and Figure 7-15 illustrate scenarios in which the SIP Proxy has been configured to use different SIP gateways depending on the destination number.

In the first call flow scenario (Figure 7-13), User A first makes a local call. In the second (Figure 7-14), User A makes a long distance call within the United States. In the third (Figure 7-15), User A makes an international call to France.

Step	Action	Description
1	INVITE—SIP IP phone A to SIP proxy server	SIP IP phone A sends an 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. 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 gateway	SIP proxy server reads the invite and, based on the destination number, it sends the SIP INVITE request to the appropriate SIP gateway. For example, in the case of a 9... number, it sends the INVITE to the default SIP gateway. In the case of a 91... number, it sends the INVITE to the SIP gateway configured to handle all long-distance US calls. In the case of a 901133... number, it sends the INVITE to the SIP gateway configured to handle all international calls to France.
3	100 Trying—SIP proxy server to SIP IP phone A	SIP proxy server sends a 100 Trying message to SIP IP phone A.
4	180 Ringing—SIP gateway to SIP proxy server	SIP gateway sends a 180 Ringing response to the SIP proxy server.
5	180 Ringing—SIP proxy server to SIP IP phone A	SIP proxy server sends a 180 Ringing message to SIP IP phone A.
6	200 OK—SIP gateway to SIP proxy server	SIP gateway sends a 200 OK response to the SIP proxy server.
7	200 OK—SIP proxy server to SIP IP phone A	SIP proxy server forwards the 200 OK response to SIP IP phone A.
8	ACK—SIP IP phone A to SIP proxy server	SIP IP phone A sends an ACK to the SIP proxy server. The ACK confirms that the SIP proxy server has received the 200 OK response from SIP IP phone C.
9	ACK—SIP proxy server to SIP gateway	SIP proxy server forwards the SIP ACK to the SIP gateway. The ACK confirms that SIP IP phone A has received the 200 OK response from the SIP gateway.
At this point, a two-way RTP channel is established between SIP IP phone A and the SIP gateway.

SIP IP Phone-to-SIP Gateway—Call Setup and Call Hold with Delayed Media

Figure 7-16 illustrates a successful SIP IP phone-to-SIP gateway call setup and call hold using delayed media.

Step	Action	Description
1	INVITE—SIP IP phone to SIP gateway	SIP IP phone sends an INVITE request to the SIP gateway. The INVITE request is an invitation to User B to participate in a call session. In the INVITE request: The phone number of User B is inserted in the Request-URI field in the form of a SIP URL. The SIP URL identifies the address of User B and takes a form similar to an email address (user@host where user is the telephone number and host is either a domain name or a numeric network address). For example, the Request-URI field in the INVITE request to User B appears as "INVITE sip:555-0002@companyb.com; user=phone." The "user=phone" parameter indicates that the Request-URI address is a telephone number rather than a user name. SIP IP phone 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	Setup B—SIP gateway to PBX	The SIP gateway receives the INVITE request from the call controller and initiates a Call Setup with User B via the PBX.
3	Call Proceeding—PBX to SIP gateway	The PBX sends a Call Proceeding message to the SIP gateway to acknowledge the Call Setup request.
4	Alerting—PBX to SIP gateway	The PBX sends an Alert message to the SIP gateway.
5	180 Ringing—SIP gateway to SIP IP phone	The SIP gateway sends a 180 Ringing response to the SIP IP phone. The 180 Ringing response indicates that the User B is being alerted.
6	Connect—PBX to SIP gateway	User B answers the phone. The PBX sends a Connect message to the SIP gateway. The Connect message notifies the SIP gateway that the connection has been made.
7	200 OK—SIP gateway to SIP IP phone	The SIP gateway sends a 200 OK response to the SIP IP phone. The 200 OK response notifies the SIP IP phone that the connection has been made.
8	ACK—SIP IP phone to SIP gateway	SIP IP phone sends an ACK to the SIP gateway. The ACK confirms that the SIP IP phone has received the 200 OK response from the SIP gateway.
9	Connect ACK—SIP gateway to PBX	The SIP gateway acknowledges the PBX's Connect message. The call between User A and User B session is now active.
A two-way RTP channel is established between the SIP IP phone and the SIP gateway. A two-way voice path is established between the SIP gateway and the PBX.
10	INVITE—SIP IP phone to SIP gateway	SIP IP phone (User A) sends a mid-call INVITE request to the SIP gateway with a modified SDP session connection parameter (c=) that places the existing call between User A and User B on hold. The c= SDP field of the SIP INVITE contains an 0.0.0.0. This places the call in limbo.
11	200 OK—SIP gateway to SIP IP phone	SIP gateway 1 sends a 200 OK response to the SIP IP phone. The 200 OK response notifies the SIP IP phone that the INVITE was successfully processed.
12	ACK—SIP IP phone to SIP gateway	The SIP IP phone sends an ACK to the SIP gateway. The ACK confirms that the SIP IP phone has received the 200 OK response. The call session is now temporarily inactive. No RTP packets are being sent.
13	INVITE—SIP IP phone to SIP gateway	SIP IP phone sends an INVITE with delayed media to the SIP gateway. No media is specified in the SDP media name and transport address (m=) parameter.
14	200 OK—SIP gateway to SIP IP phone	The SIP gateway sends a 200 OK response to User A. In the 200 OK response, the SDP information of User B is specified.
15	ACK—SIP IP phone to SIP gateway	SIP IP phone sends an ACK to the SIP gateway. The ACK confirms that the SIP IP phone has received the 200 OK response from the SIP gateway. In the ACK response, the SDP information of User A is specified. Media negotiation takes place.
A two-way RTP channel is re-established between the SIP IP phone and the SIP gateway. A two-way voice path (to User B) is established between the SIP gateway and the PBX.

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

Figure 7-17 illustrates a successful call between 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 SIP IP phones, which are connected via an IP network.

Step	Action	Description
1	INVITE—SIP IP phone A to SIP IP phone B	SIP IP phone A sends an INVITE request to 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. 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—SIP IP phone B to SIP IP phone A	SIP IP phone B sends a 180 Ringing response to SIP IP phone A.
3	200 OK—SIP IP phone B to SIP IP phone A	SIP IP phone B sends a 200 OK response to SIP IP phone A. The 200 OK response notifies SIP IP phone A that the connection has been made. If SIP IP phone B supports the media capability advertised in the INVITE message sent by SIP IP phone A, it advertises the intersection of its own and SIP IP phone A's media capability in the 200 OK response. If SIP IP phone B does not support the media capability advertised by SIP IP phone A, it sends back a 400 Bad Request response with a 304 Warning header field.
4	ACK—SIP IP phone A to SIP IP phone B	SIP IP phone A sends an ACK to SIP IP phone B. The ACK confirms that SIP IP phone A has received the 200 OK response from SIP IP phone B.
At this point, a two-way RTP channel is established between SIP IP phone A and SIP IP phone B.
5	INVITE—SIP IP phone B to SIP IP phone A	SIP IP phone B sends a mid-call INVITE to SIP IP phone A with new SDP session parameters (IP address), which are used to place the call on hold. The SIP INVITE contains an invalid IP address, which places the call in limbo. SDP: c=IN IP4 0.0.0.0
6	200 OK—SIP IP phone A to SIP IP phone B	SIP IP phone A sends a 200 OK response to SIP IP phone B.
7	ACK—SIP IP phone B to SIP IP phone A	SIP IP phone B sends an ACK to SIP IP phone A. The ACK confirms that SIP IP phone B has received the 200 OK response from SIP IP phone A.
The two-way RTP channel is torn down. The call is on hold.
8	INVITE—SIP IP phone B to SIP IP phone A	SIP IP phone B sends a mid-call INVITE to SIP IP phone A with the same call ID as the previous INVITE and new SDP session parameters (IP address), which are used to re-establish the call. SDP: c=IN IP4 181.23.250.2
9	200 OK—SIP IP phone A to SIP IP phone B	SIP IP phone A sends a 200 OK response to SIP IP phone B.
10	ACK—SIP IP phone B to SIP IP phone A	SIP IP phone B sends an ACK to SIP IP phone A. The ACK confirms that SIP IP phone B has received the 200 OK response from SIP IP phone A.
At this point, the two-way RTP channel is re-established between IP phone A and IP phone B.

SIP IP Phone-to-SIP IP Phone—Call Hold with Consultation

Figure 7-18 illustrates a successful call between 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 SIP IP phones, which are connected via an IP network.

Step	Action	Description
1	INVITE—SIP IP phone A to SIP IP phone B	SIP IP phone A sends an INVITE request to 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. 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—SIP IP phone B to SIP IP phone A	SIP IP phone B sends a 180 Ringing response to SIP IP phone A.
3	200 OK—SIP IP phone B to SIP IP phone A	SIP IP phone B sends a 200 OK response to SIP IP phone A. The 200 OK response notifies SIP IP phone A that the connection has been made. If SIP IP phone B supports the media capability advertised in the INVITE message sent by SIP IP phone A, it advertises the intersection of its own and SIP IP phone A's media capability in the 200 OK response. If SIP IP phone B does not support the media capability advertised by SIP IP phone A, it sends back a 400 Bad Request response with a 304 Warning header field.
4	ACK—SIP IP phone A to SIP IP phone B	SIP IP phone A sends an ACK to SIP IP phone B. The ACK confirms that SIP IP phone A has received the 200 OK response from SIP IP phone B.
At this point, a two-way RTP channel is established between SIP IP phone A and SIP IP phone B.
5	INVITE—SIP IP phone B to SIP IP phone A	SIP IP phone B sends a mid-call INVITE to SIP IP phone A with new SDP session parameters (IP address), which are used to place the call on hold. The SIP INVITE contains an invalid IP address, which places the call in limbo. SDP: c=IN IP4 0.0.0.0
6	200 OK—SIP IP phone A to SIP IP phone B	SIP IP phone A sends a 200 OK response to SIP IP phone B.
7	ACK—SIP IP phone B to SIP IP phone A	SIP IP phone B sends an ACK to SIP IP phone A. The ACK confirms that SIP IP phone B has received the 200 OK response from SIP IP phone A.
The two-way RTP channel is torn down. The call is on hold.
8	INVITE—SIP IP phone B to SIP IP phone C	SIP IP phone B sends an INVITE request to SIP IP phone C. The INVITE request is an invitation to User C to participate in a call session.
9	180 Ringing—SIP IP phone C to SIP IP phone B	SIP IP phone C sends a 180 Ringing response to SIP IP phone B.
10	200 OK—SIP IP phone C to SIP IP phone B	SIP IP phone C sends a 200 OK response to SIP IP phone B. The 200 OK response notifies SIP IP phone B that the connection has been made. If SIP IP phone B supports the media capability advertised in the INVITE message sent by SIP IP phone A, it advertises the intersection of its own and SIP IP phone A's media capability in the 200 OK response. If SIP IP phone B does not support the media capability advertised by SIP IP phone A, it sends back a 400 Bad Request response with a 304 Warning header field.
11	ACK—SIP IP phone B to SIP IP phone C	SIP IP phone B sends an ACK to SIP IP phone C. The ACK confirms that SIP IP phone B has received the 200 OK response from SIP IP phone C.
At this point, a two-way RTP channel is established between SIP IP phone B and SIP IP phone C.
12	BYE—SIP IP phone B to SIP IP phone C	The call continues and then User B hangs up. SIP IP phone B sends a BYE request to SIP IP phone C. The BYE request indicates that User B wants to release the call.
13	200 OK—SIP IP phone C to SIP IP phone B	SIP IP phone C sends a 200 OK message to SIP IP phone B. The 200 OK response notifies SIP IP phone B that the BYE request has been received. The call session between User A and User B is now terminated.
At this point, the RTP channel between SIP IP phone C and SIP IP phone B is torn down.
14	INVITE—SIP IP phone B to SIP IP phone A	SIP IP phone B sends a mid-call INVITE to SIP IP phone A with the same call ID as the previous INVITE and new SDP session parameters (IP address), which are used to re-establish the call. SDP: c=IN IP4 181.23.250.2
15	200 OK—SIP IP phone A to SIP IP phone B	SIP IP phone A sends a 200 OK response to SIP IP phone B.
16	ACK—SIP IP phone B to SIP IP phone A	SIP IP phone B sends an ACK to SIP IP phone A. The ACK confirms that SIP IP phone B has received the 200 OK response from SIP IP phone A.
At this point, the two-way RTP channel is re-established between SIP IP phone A and SIP IP phone B.

SIP IP Phone-to-SIP IP Phone—Call Waiting

Figure 7-19 illustrates a successful call between 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 SIP IP phones, which are connected via an IP network.

Step	Action	Description
1	INVITE—SIP IP phone A to SIP IP phone B	SIP IP phone A sends an INVITE request to 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. 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—SIP IP phone B to SIP IP phone A	SIP IP phone B sends a 180 Ringing response to SIP IP phone A.
3	200 OK—SIP IP phone B to SIP IP phone A	SIP IP phone B sends a 200 OK response to SIP IP phone A. The 200 OK response notifies SIP IP phone A that the connection has been made. If SIP IP phone B supports the media capability advertised in the INVITE message sent by SIP IP phone A, it advertises the intersection of its own and SIP IP phone A's media capability in the 200 OK response. If SIP IP phone B does not support the media capability advertised by SIP IP phone A, it sends back a 400 Bad Request response with a 304 Warning header field.
4	ACK—SIP IP phone A to SIP IP phone B	SIP IP phone A sends an ACK to SIP IP phone B. The ACK confirms that SIP IP phone A has received the 200 OK response from SIP IP phone B.
At this point, a two-way RTP channel is established between SIP IP phone A and SIP IP phone B.
5	INVITE—SIP IP phone C to SIP IP phone B	SIP IP phone C sends an INVITE request to SIP IP phone B. The INVITE request is an invitation to User B to participate in a call session.
6	180 Ringing—SIP IP phone B to SIP IP phone C	SIP IP phone B sends a 180 Ringing response to SIP IP phone C.
7	INVITE—SIP IP phone B to SIP IP phone A	SIP IP phone B sends a mid-call INVITE to SIP IP phone A with new SDP session parameters (IP address), which are used to place the call on hold. The SIP INVITE contains an invalid IP address, which places the call in limbo. SDP: c=IN IP4 0.0.0.0
8	200 OK—SIP IP phone A to SIP IP phone B	SIP IP phone A sends a 200 OK response to SIP IP phone B.
9	ACK—SIP IP phone B to SIP IP phone A	SIP IP phone B sends an ACK to SIP IP phone A. The ACK confirms that SIP IP phone B has received the 200 OK response from SIP IP phone A.
The two-way RTP channel is torn down. SIP IP phone A is on hold.
10	200 OK—SIP IP phone B to SIP IP phone C	SIP IP phone B sends a 200 OK response to SIP IP phone C. The 200 OK response notifies SIP IP phone C that the connection has been made.
11	ACK—SIP IP phone C to SIP IP phone B	SIP IP phone C sends an ACK to SIP IP phone B. The ACK confirms that SIP IP phone C has received the 200 OK response from SIP IP phone B.
At this point, a two-way RTP channel is established between SIP IP phone B and SIP IP phone C. SIP IP phone A remains on hold.
12	INVITE—SIP IP phone B to SIP IP phone C	SIP IP phone B sends a mid-call INVITE to SIP IP phone C with new SDP session parameters (IP address), which are used to place the call on hold. The SIP INVITE contains an invalid IP address, which places the call in limbo. SDP: c=IN IP4 0.0.0.0
13	200 OK—SIP IP phone C to SIP IP phone B	SIP IP phone C sends a 200 OK response to SIP IP phone B.
14	ACK—SIP IP phone B to SIP IP phone C	SIP IP phone B sends an ACK to SIP IP phone C. The ACK confirms that SIP IP phone B has received the 200 OK response from SIP IP phone C.
The two-way RTP channel is torn down. SIP IP phone C is on hold.
15	INVITE—SIP IP phone B to SIP IP phone A	SIP IP phone B sends a mid-call INVITE to SIP IP phone A with the same call ID as the previous INVITE (sent to SIP IP phone A) and new SDP session parameters (IP address), which are used to re-establish the call. SDP: c=IN IP4 181.23.250.2
16	200 OK—SIP IP phone A to SIP IP phone B	SIP IP phone A sends a 200 OK response to SIP IP phone B.
17	ACK—SIP IP phone B to SIP IP phone A	SIP IP phone B sends an ACK to SIP IP phone A. The ACK confirms that SIP IP phone B has received the 200 OK response from SIP IP phone A.
At this point, the two-way RTP channel is re-established between SIP IP phone A and SIP IP phone B.
18	BYE—SIP IP phone B to SIP IP phone A	The call continues and then User B hangs up. SIP IP phone B sends a BYE request to SIP IP phone A. The BYE request indicates that User B wants to release the call.
19	200 OK—SIP IP phone A to SIP IP phone B	SIP IP phone A sends a 200 OK message to SIP IP phone B. The 200 OK response notifies SIP IP phone B that the BYE request has been received. The call session between User A and User B is now terminated.
At this point, the RTP channel between SIP IP phone A and SIP IP phone B is torn down. SIP IP phone C remains on hold.
20	INVITE—SIP IP phone B to SIP IP phone C	SIP IP phone B sends a mid-call INVITE to SIP IP phone C with the same call ID as the previous INVITE (sent to SIP IP phone C) and new SDP session parameters (IP address), which are used to re-establish the call. Call_ID=2 SDP: c=IN IP4 181.23.250.2
21	200 OK—SIP IP phone C to SIP IP phone B	SIP IP phone C sends a 200 OK response to SIP IP phone B.
22	ACK—SIP IP phone B to SIP IP phone C	SIP IP phone B sends an ACK to SIP IP phone C. The ACK confirms that SIP IP phone B has received the 200 OK response from SIP IP phone A.
At this point, the two-way RTP channel is re-established between SIP IP phone B and SIP IP phone C.

SIP IP Phone-to-SIP IP Phone—Call Transfer without Consultation

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

Step	Action	Description
1	INVITE—SIP IP phone A to SIP IP phone B	SIP IP phone A sends an INVITE request to 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. 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—SIP IP phone B to SIP IP phone A	SIP IP phone B sends a 180 Ringing response to SIP IP phone A.
3	200 OK—SIP IP phone B to SIP IP phone A	SIP IP phone B sends a 200 OK response to SIP IP phone A. The 200 OK response notifies SIP IP phone A that the connection has been made. If SIP IP phone B supports the media capability advertised in the INVITE message sent by SIP IP phone A, it advertises the intersection of its own and SIP IP phone A's media capability in the 200 OK response. If SIP IP phone B does not support the media capability advertised by SIP IP phone A, it sends back a 400 Bad Request response with a 304 Warning header field.
4	ACK—SIP IP phone A to SIP IP phone B	SIP IP phone A sends an ACK to SIP IP phone B. The ACK confirms that SIP IP phone A has received the 200 OK response from SIP IP phone B.
At this point, a two-way RTP channel is established between SIP IP phone A and SIP IP phone B. User B then selects the option to transfer the call to User C.
5	BYE—SIP IP phone B to SIP IP phone A	The SIP BYE request includes the Also header. The Also header indicates that User C must be brought into the call while User B hangs up. This header distinguishes the call transfer BYE request from a normal disconnect BYE request.
6	200 OK—SIP IP phone A to SIP IP phone B	SIP IP phone A sends a 200 OK message to SIP IP phone B. The 200 OK response notifies SIP IP phone B that the BYE request has been received. The call session between User A and User B is now terminated.
At this point, the RTP channel between SIP IP phone A and SIP IP phone B is torn down.
7	INVITE—SIP IP phone A to SIP IP phone C (Requested by SIP IP phone B)	At the request of SIP IP phone B, SIP IP phone A sends an INVITE request to SIP IP phone C. The INVITE request is an invitation to User C to participate in a call session.
8	180 Ringing—SIP IP phone C to SIP IP phone A	SIP IP phone C sends a 180 Ringing response to SIP IP phone A.
9	200 OK—SIP IP phone C to SIP IP phone A	SIP IP phone C sends a 200 OK response to SIP IP phone A. The 200 OK response notifies SIP IP phone A that the connection has been made.
10	ACK—SIP IP phone A to SIP IP phone C	SIP IP phone A sends an ACK to SIP IP phone C. The ACK confirms that SIP IP phone A has received the 200 OK response from SIP IP phone C.
At this point, a two-way RTP channel is established between SIP IP phone A and SIP IP phone C.

SIP IP Phone-to-SIP IP Phone—Call Transfer with Consultation

Figure 7-21 illustrates a successful call between 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 SIP IP phones, which are connected via an IP network.

Step	Action	Description
1	INVITE—SIP IP phone A to SIP IP phone B	SIP IP phone A sends an INVITE request to 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. 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—SIP IP phone B to SIP IP phone A	SIP IP phone B sends a 180 Ringing response to SIP IP phone A.
3	200 OK—SIP IP phone B to SIP IP phone A	SIP IP phone B sends a 200 OK response to SIP IP phone A. The 200 OK response notifies SIP IP phone A that the connection has been made. If SIP IP phone B supports the media capability advertised in the INVITE message sent by SIP IP phone A, it advertises the intersection of its own and SIP IP phone A's media capability in the 200 OK response. If SIP IP phone B does not support the media capability advertised by SIP IP phone A, it sends back a 400 Bad Request response with a 304 Warning header field.
4	ACK—SIP IP phone A to SIP IP phone B	SIP IP phone A sends an ACK to SIP IP phone B. The ACK confirms that SIP IP phone A has received the 200 OK response from SIP IP phone B.
At this point, a two-way RTP channel is established between SIP IP phone A and SIP IP phone B. User B then selects the option to transfer the call to User C.
5	INVITE—SIP IP phone B to SIP IP phone A	SIP IP phone B sends a mid-call INVITE to SIP IP phone A with new SDP session parameters (IP address), which are used to place the call on hold. The SIP INVITE contains an invalid IP address, which places the call in limbo. SDP: c=IN IP4 0.0.0.0
6	200 OK—SIP IP phone A to SIP IP phone B	SIP IP phone A sends a 200 OK response to SIP IP phone B.
7	ACK—SIP IP phone B to SIP IP phone A	SIP IP phone B sends an ACK to SIP IP phone A. The ACK confirms that SIP IP phone B has received the 200 OK response from SIP IP phone A.
The two-way RTP channel is torn down. The call is on hold.
8	INVITE—SIP IP phone B to SIP IP phone C	SIP IP phone B sends an INVITE request to SIP IP phone C. The INVITE request is an invitation to User C to participate in a call session.
9	180 Ringing—SIP IP phone C to SIP IP phone B	SIP IP phone C sends a 180 Ringing response to SIP IP phone B.
10	200 OK—SIP IP phone C to SIP IP phone B	SIP IP phone C sends a 200 OK response to SIP IP phone B. The 200 OK response notifies SIP IP phone B that the connection has been made. If SIP IP phone B supports the media capability advertised in the INVITE message sent by SIP IP phone A, it advertises the intersection of its own and SIP IP phone A's media capability in the 200 OK response. If SIP IP phone B does not support the media capability advertised by SIP IP phone A, it sends back a 400 Bad Request response with a 304 Warning header field.
11	ACK—SIP IP phone B to SIP IP phone C	SIP IP phone B sends an ACK to SIP IP phone C. The ACK confirms that SIP IP phone B has received the 200 OK response from SIP IP phone C.
At this point, a two-way RTP channel is established between SIP IP phone B and SIP IP phone C.
12	BYE—SIP IP phone B to SIP IP phone C	The call continues and then User B hangs up. SIP IP phone B sends a BYE request to SIP IP phone C. The BYE request indicates that User B wants to release the call.
13	200 OK—SIP IP phone C to SIP IP phone B	SIP IP phone C sends a 200 OK message to SIP IP phone B. The 200 OK response notifies SIP IP phone B that the BYE request has been received. The call session between User A and User B is now terminated.
At this point, the RTP channel between SIP IP phone B and SIP IP phone C is torn down.
14	BYE—SIP IP phone B to SIP IP phone A	The SIP BYE request includes the Also header. The Also header indicates that User C must be brought into the call while User B hangs up. This header distinguishes the call transfer BYE request from a normal disconnect BYE request.
15	200 OK—SIP IP phone A to SIP IP phone B	SIP IP phone A sends a 200 OK message to SIP IP phone B. The 200 OK response notifies SIP IP phone B that the BYE request has been received. The call session between User A and User B is now terminated.
At this point, the RTP channel between SIP IP phone A and SIP IP phone B is torn down.
16	INVITE—SIP IP phone A to SIP IP phone C (Requested by SIP IP phone B)	At the request of SIP IP phone B, SIP IP phone A sends an INVITE request to SIP IP phone C. The INVITE request is an invitation to User C to participate in a call session.
17	180 Ringing—SIP IP phone C to SIP IP phone A	SIP IP phone C sends a 180 Ringing response to SIP IP phone A.
18	200 OK—SIP IP phone C to SIP IP phone A	SIP IP phone C sends a 200 OK response to SIP IP phone A. The 200 OK response notifies SIP IP phone A that the connection has been made.
19	ACK—SIP IP phone A to SIP IP phone C	SIP IP phone A sends an ACK to SIP IP phone C. The ACK confirms that SIP IP phone A has received the 200 OK response from SIP IP phone C.
At this point, a two-way RTP channel is established between SIP IP phone A and SIP IP phone C.

SIP IP Phone-to-SIP IP Phone—Network Call Forwarding (Unconditional)

Figure 7-22 illustrates successful call forwarding between 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 SIP IP phone C. In this call flow scenario, the end users are User A, User B, and User C. They are all using SIP IP phones, which are connected via an IP network.

Step	Action	Description
1	INVITE—SIP IP phone A to SIP proxy server	SIP IP phone A sends an 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. 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 302 Moved Temporarily message to the SIP proxy server. The message indicates that User B is not available at SIP IP phone B and includes instructions to locate User B at SIP IP phone C.
4	ACK—SIP proxy server to SIP redirect server	The SIP proxy server sends an ACK to the SIP redirect server. The ACK confirms that the 302 Moved Temporarily response has been received.
5	INVITE—SIP proxy server to SIP IP phone C	SIP proxy server sends an INVITE request to SIP IP phone C. The INVITE request is an invitation to User C to participate in a call session.
6	180 Ringing—SIP IP phone C to SIP proxy server	SIP IP phone C sends a 180 Ringing response to the SIP proxy server.
7	200 OK—SIP IP phone C to SIP proxy server	SIP IP phone C sends a 200 OK response to the SIP proxy server.
8	200 OK—SIP proxy server to SIP IP phone A	SIP proxy server forwards the 200 OK response to SIP IP phone A.
9	ACK—SIP IP phone A to SIP proxy server	SIP IP phone A sends an ACK to the SIP proxy server. The ACK confirms that the SIP proxy server has received the 200 OK response from SIP IP phone C.
10	ACK—SIP proxy server to SIP IP phone C	SIP proxy server forwards the SIP ACK to SIP IP phone C. The ACK confirms that SIP IP phone A has received the 200 OK response from SIP IP phone C.
At this point, a two-way RTP channel is established between SIP IP phone A and SIP IP phone C.

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

Figure 7-23 and Figure 7-24 illustrate successful call forwarding between 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 proxy server tries to place the call to SIP IP phone B and, if the line is busy, the call is transferred to SIP IP phone C. In this call flow scenario, the end users are User A, User B, and User C. They are all using SIP IP phones, which are connected via an IP network.

1. User B requests that if their phone (SIP IP phone B) is busy the network should forward incoming calls to SIP IP phone C.

This section contains two call flows. In the first (Figure 7-23), a SIP redirect server is supplying the alternative addresses. In the second (Figure 7-24), the proxy has been configured with the alternative addresses.

Step	Action	Description
1	INVITE—SIP IP phone A to SIP proxy server	SIP IP phone A sends an 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. 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 300 Multiple choices message to the SIP proxy server. The message indicates that User B can be reached either at SIP IP phone B or SIP IP phone C.
4	ACK—SIP proxy server to SIP redirect server	The SIP proxy server sends an ACK to the SIP redirect server. The ACK confirms that the 300 Multiple Choices response has been received.
5	INVITE—SIP proxy server to SIP IP phone B	SIP proxy server sends an INVITE request to SIP IP phone B. The INVITE request is an invitation to User B to participate in a call session.
6	486 Busy Here—SIP IP phone B to SIP proxy server	SIP IP phone B sends a 486 Busy here message to the SIP proxy server. The message indicates that SIP IP phone B is in use and the user is either unwilling or unable to take additional calls.
7	ACK—SIP proxy server to SIP IP phone B	SIP proxy server sends the SIP ACK to SIP IP phone B. The ACK confirms that the SIP Proxy server has received the 486 Busy here response from SIP IP phone B.
8	INVITE—SIP proxy server to SIP IP phone C	SIP proxy server sends an INVITE request to SIP IP phone C. The INVITE request is an invitation to User C to participate in a call session.
9	180 Ringing—SIP IP phone C to SIP proxy server	SIP IP phone C sends a 180 Ringing response to the SIP proxy server
10	200 OK—SIP IP phone C to SIP proxy server	SIP IP phone C sends a 200 OK response to the SIP proxy server.
11	200 OK—SIP proxy server to SIP IP phone A	SIP proxy server forwards the 200 OK response to SIP IP phone A.
12	ACK—SIP IP phone A to SIP proxy server	SIP IP phone A sends an ACK to the SIP proxy server. The ACK confirms that SIP IP phone A has received the 200 OK response from SIP IP phone C.
13	ACK—SIP proxy server to SIP IP phone C	SIP proxy server forwards the SIP ACK to SIP IP phone C. The ACK confirms that SIP IP phone A has received the 200 OK response from SIP IP phone C.
At this point, a two-way RTP channel is established between SIP IP phone A and SIP IP phone C.

Step	Action	Description
1	INVITE—SIP IP phone A to SIP proxy server	SIP IP phone A sends an 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. 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 IP phone B	SIP proxy server sends an INVITE request to SIP IP phone B. The INVITE request is an invitation to User B to participate in a call session.
3	100 Trying—SIP Proxy to SIP IP phone A	SIP Proxy sends a 100 Trying message to SIP IP phone A.
4	486 Busy Here—SIP IP phone B to SIP proxy server	SIP IP phone B sends a 486 Busy here message to the SIP proxy server. The message indicates that SIP IP phone B is in use and the user is either unwilling or unable to take additional calls.
5	ACK—SIP proxy server to SIP IP phone B	SIP proxy server sends the SIP ACK to SIP IP phone B. The ACK confirms that the SIP Proxy server has received the 486 Busy here response from SIP IP phone B.
6	INVITE—SIP proxy server to SIP IP phone C	SIP proxy server sends an INVITE request to SIP IP phone C. The INVITE request is an invitation to User C to participate in a call session.
7	180 Ringing—SIP IP phone C to SIP proxy server	SIP IP phone C sends a 180 Ringing response to the SIP proxy server.
8	180 Ringing—SIP proxy server to SIP IP phone A	SIP proxy server sends a 180 Ringing response to SIP IP phone A.
9	200 OK—SIP IP phone C to SIP proxy server	SIP IP phone C sends a 200 OK response to the SIP proxy server.
10	200 OK—SIP proxy server to SIP IP phone A	SIP proxy server forwards the 200 OK response to SIP IP phone A.
11	ACK—SIP IP phone A to SIP proxy server	SIP IP phone A sends an ACK to the SIP proxy server. The ACK confirms that SIP IP phone A has received the 200 OK response from SIP IP phone C.
12	ACK—SIP proxy server to SIP IP phone C	SIP proxy server forwards the SIP ACK to SIP IP phone C. The ACK confirms that SIP IP phone A has received the 200 OK response from SIP IP phone C.
At this point, a two-way RTP channel is established between SIP IP phone A and SIP IP phone C.

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

Figure 7-25 and Figure 7-26 illustrate successful call forwarding between SIP IP phones in which User B has requested call forwarding from the network in the event there is no answer. When User A calls User B, the proxy server tries to place the call to SIP IP phone B and, if there is no answer, the call is transferred to SIP IP phone C. In this call flow scenario, the end users are User A, User B, and User C. They are all using SIP IP phones, which are connected via an IP network.

1. User B requests that if their phone (SIP IP phone B) is not answered within a set amount of time the network should forward incoming calls to SIP IP phone C.

This section contains two call flows. In the first (Figure 7-25), a SIP redirect server is supplying the alternative addresses. In the second (Figure 7-26), the proxy has been configured with the alternative addresses.

Step	Action	Description
1	INVITE—SIP IP phone A to SIP proxy server	SIP IP phone A sends an 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. 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 300 Multiple choices message to the SIP proxy server. The message indicates that User B can be reached either at SIP IP phone B or SIP IP phone C.
4	ACK—SIP proxy server to SIP redirect server	The SIP proxy server sends an ACK to the SIP redirect server. The ACK confirms that the 300 Multiple Choices response has been received.
5	INVITE—SIP proxy server to SIP IP phone B	SIP proxy server sends an INVITE request to SIP IP phone B. The INVITE request is an invitation to User B to participate in a call session.
6	180 Ringing—SIP IP phone B to SIP proxy server	SIP IP phone B sends a 180 Ringing response to the SIP proxy server.
7	180 Ringing—SIP proxy server to SIP IP phone A	SIP proxy server sends a 180 Ringing response to SIP IP phone A.
At this point, the timeout expires before the phone is answered.
8	CANCEL (Ring Timeout)—SIP proxy server to SIP IP phone B	SIP proxy server sends a CANCEL request to SIP IP phone B to cancel the invitation.
9	200 OK—SIP IP phone B to SIP proxy server	SIP IP phone B sends a 200 OK response to the SIP proxy server. The response confirms receipt of the cancellation request.
10	INVITE—SIP proxy server to SIP IP phone C	SIP proxy server sends an INVITE request to SIP IP phone C. The INVITE request is an invitation to User C to participate in a call session.
11	180 Ringing—SIP IP phone C to SIP proxy server	SIP IP phone C sends a 180 Ringing response to the SIP proxy server.
12	200 OK—SIP IP phone C to SIP proxy server	SIP IP phone C sends a 200 OK response to the SIP proxy server.
13	200 OK—SIP proxy server to SIP IP phone A	SIP proxy server forwards the 200 OK response to SIP IP phone A.
14	ACK—SIP IP phone A to SIP proxy server	SIP IP phone A sends an ACK to the SIP proxy server. The ACK confirms that SIP IP phone A has received the 200 OK response from SIP IP phone C.
15	ACK—SIP proxy server to SIP IP phone C	SIP proxy server forwards the SIP ACK to SIP IP phone C. The ACK confirms that SIP IP phone A has received the 200 OK response from SIP IP phone C.
At this point, a two-way RTP channel is established between SIP IP phone A and SIP IP phone C.

Step	Action	Description
1	INVITE—SIP IP phone A to SIP proxy server	SIP IP phone A sends an 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. 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 IP phone B	SIP proxy server sends an INVITE request to SIP IP phone B. The INVITE request is an invitation to User B to participate in a call session.
3	100 Trying—SIP Proxy to SIP IP phone A	SIP Proxy sends a 100 Trying message to SIP IP phone A.
4	180 Ringing—SIP IP phone B to SIP proxy server	SIP IP phone B sends a 180 Ringing response to the SIP proxy server.
5	180 Ringing—SIP proxy server to SIP IP phone A	SIP proxy server sends a 180 Ringing response to SIP IP phone A.
At this point, the timeout expires before the phone is answered.
6	CANCEL (Ring Timeout)—SIP proxy server to SIP IP phone B	SIP proxy server sends a CANCEL request to SIP IP phone B to cancel the invitation.
7	200 OK—SIP IP phone B to SIP proxy server	SIP IP phone B sends a 200 OK response to the SIP proxy server. The response confirms receipt of the cancellation request.
8	INVITE—SIP proxy server to SIP IP phone C	SIP proxy server sends an INVITE request to SIP IP phone C. The INVITE request is an invitation to User C to participate in a call session.
9	180 Ringing—SIP IP phone C to SIP proxy server	SIP IP phone C sends a 180 Ringing response to the SIP proxy server
10	200 OK—SIP IP phone C to SIP proxy server	SIP IP phone C sends a 200 OK response to the SIP proxy server.
11	200 OK—SIP proxy server to SIP IP phone A	SIP proxy server forwards the 200 OK response to SIP IP phone A.
12	ACK—SIP IP phone A to SIP proxy server	SIP IP phone A sends an ACK to the SIP proxy server. The ACK confirms that SIP IP phone A has received the 200 OK response from SIP IP phone C.
13	ACK—SIP proxy server to SIP IP phone C	SIP proxy server forwards the SIP ACK to SIP IP phone C. The ACK confirms that SIP IP phone A has received the 200 OK response from SIP IP phone C.
At this point, a two-way RTP channel is established between SIP IP phone A and SIP IP phone C.

SIP IP Phone-to-SIP IP Phone Call Forward Unconditionally

Figure 7-27 and Figure 7-28 illustrate a successful SIP IP phone-to-SIP IP phone call forward unconditionally via a SIP proxy. In these scenarios, the three end users and endpoints are identified as Alice at SIP IP phone A, Bob at SIP IP phone B, and Carol at SIP IP phone C. Bob's calls are configured to forward to Carol unconditionally. Figure 7-27 illustrates the call as processed by a recursive proxy and Figure 7-28 illustrates the call as processed by a non-recursive proxy.

Step	Action	Description
1	INVITE—SIP IP phone A to SIP proxy server	Alice's SIP IP phone A sends an INVITE request to the proxy server. The INVITE request is an invitation to Bob to participate in a call session. In the INVITE request: Bob's phone number is inserted in the Request-URI field in the form of a SIP URL. The SIP URL identifies Bob's address and takes a form similar to an email address (user@host where user is the telephone number and host is either a domain name or a numeric network address). For example, the Request-URI field in the INVITE request to Bob might appear as "INVITE sip:555-0002@companyb.com; user=phone." The "user=phone" parameter distinguishes that the Request-URI address is a telephone number rather than a user name. Alice at 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 inserted in the Call-ID field. The transaction number within a single call leg is identified in the CSeq field. The media capability SIP IP phone A is ready to receive is specified in the SDP. The port on which SIP IP phone A is prepared to receive the RTP data is specified in the SDP.
2	INVITE—SIP proxy server to SIP IP phone C	The SIP proxy server determines that Bob's calls have been configured to forward unconditionally to Carol at SIP IP phone C. The SIP proxy server sends an INVITE request to Carol at SIP IP phone C. In the INVITE request, the proxy server changes the Request-URI to divert the request to Carol at SIP IP phone C and adds a CC-Diversion header containing the Request-URI from the initial INVITE request and the reason for the diversion.
3	180 Ringing—SIP IP phone C to SIP proxy server	SIP IP phone C sends a 180 Ringing response to the SIP proxy server.
4	180 Ringing—SIP proxy server to SIP IP phone A	The SIP proxy server forwards the 180 Ringing response to SIP IP phone A.
5	200 OK—SIP IP phone C to SIP proxy server	SIP IP phone C sends a 200 OK response to SIP IP phone A. The 200 OK response notifies the SIP IP phone A that Carol has answered the phone (for example, the handset of SIP IP phone C went off-hook). If SIP IP phone C supports the media capability advertised in the INVITE message sent by the SIP proxy server, it advertises the intersection of its own and SIP IP phone A's media capability in the 200 OK response. If SIP IP phone C does not support the media capability advertised by SIP IP phone A, it sends back a 400 Bad Request response with a "Warning: 304 Codec negotiation failed" header field.
6	ACK—SIP IP phone A to SIP IP phone C	SIP IP phone A sends an ACK to SIP IP phone C. The ACK confirms that User A's SIP IP phone has received the 200 OK response from User C's SIP IP phone.
At this point, a two-way RTP channel is established between SIP IP phone A and SIP IP C phone.

Step	Action	Description
1	INVITE—SIP IP phone A to SIP proxy server	Alice's SIP IP phone A sends an INVITE request to the proxy server. The INVITE request is an invitation to Bob to participate in a call session. In the INVITE request: Bob's phone number is inserted in the Request-URI field in the form of a SIP URL. The SIP URL identifies Bob's address and takes a form similar to an email address (user@host where user is the telephone number and host is either a domain name or a numeric network address). For example, the Request-URI field in the INVITE request to Bob might appear as "INVITE sip:555-0002@companyb.com; user=phone." The "user=phone" parameter distinguishes that the Request-URI address is a telephone number rather than a user name. Alice at 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 inserted in the Call-ID field. The transaction number within a single call leg is identified in the CSeq field. The media capability SIP IP phone A is ready to receive is specified in the SDP. The port on which SIP IP phone A is prepared to receive the RTP data is specified in the SDP.
2	302 Moved Temporarily—SIP proxy server to SIP IP phone A	The SIP proxy server determines that Bob's calls have been configured to forward unconditionally to Carol at SIP IP phone C. The SIP proxy server sends a 302 Moved Temporarily message to SIP IP phone A. In the 302 Moved Temporarily message, Carol at SIP IP phone C is added as the Contact and a CC-Diversion header is added that contains the Request-URI from the initial INVITE and the reason for the diversion.
3	INVITE—SIP IP phone A to SIP IP phone C	SIP IP phone A sends an INVITE request to Carol at SIP IP phone C. The INVITE request contains a CC-Diversion header that contains the Request-URI from the initial INVITE request and the reason for the diversion.
4	180 Ringing—SIP IP phone C to SIP proxy server	SIP IP phone C sends a 180 Ringing response to SIP IP phone A.
5	200 OK—SIP IP phone C to SIP IP phone A	SIP IP phone C sends a 200 OK response to SIP IP phone A. The 200 OK response notifies the SIP IP phone A that Carol has answered the phone (for example, the handset of SIP IP phone C went off-hook). If SIP IP phone C supports the media capability advertised in the INVITE message sent by the SIP proxy server, it advertises the intersection of its own and SIP IP phone A's media capability in the 200 OK response. If SIP IP phone C does not support the media capability advertised by SIP IP phone A, it sends back a 400 Bad Request response with a "Warning: 304 Codec negotiation failed" header field.
6	ACK—SIP IP phone A to SIP IP phone C	SIP IP phone A sends an ACK to SIP IP phone C. The ACK confirms that SIP IP phone A has received the 200 OK response from SIP IP phone C.
At this point, a two-way RTP channel is established between SIP IP phone A and SIP IP phone C.

SIP IP Phone-to-SIP IP Phone Call Forward on Busy

Figure 7-29 and Figure 7-30 illustrate a successful SIP IP phone-to-SIP IP phone call forward on busy via a SIP proxy. In these scenarios, the three end users are identified as User A, User B, and User C. User B's calls are configured to forward to User C when User B's SIP IP phone sends a 486 Busy Here response. Figure 7-29 illustrates the call as processed by a recursive proxy and Figure 7-30 illustrates the call as processed by a non-recursive proxy.

Step	Action	Description
1	INVITE—SIP IP phone A to SIP proxy server	Alice's SIP IP phone A sends an INVITE request to the proxy server. The INVITE request is an invitation to Bob to participate in a call session. In the INVITE request: Bob's phone number is inserted in the Request-URI field in the form of a SIP URL. The SIP URL identifies Bob's address and takes a form similar to an email address (user@host where user is the telephone number and host is either a domain name or a numeric network address). For example, the Request-URI field in the INVITE request to Bob might appear as "INVITE sip:555-0002@companyb.com; user=phone." The "user=phone" parameter distinguishes that the Request-URI address is a telephone number rather than a user name. Alice at 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 inserted in the Call-ID field. The transaction number within a single call leg is identified in the CSeq field. The media capability SIP IP phone A is ready to receive is specified in the SDP. The port on which SIP IP phone A is prepared to receive the RTP data is specified in the SDP.
2	INVITE—SIP proxy server to SIP IP phone B	The proxy server forwards the INVITE request to Bob at SIP IP phone B.
3	486 Busy Here—SIP IP phone B to the SIP proxy server	SIP IP phone B sends a 486 Busy response to the SIP proxy server. The 486 Busy Here response is a client error response that indicates that Bob at SIP IP phone B was successfully contacted but Bob was either unwilling or unable to take another call.
4	ACK—SIP proxy server to SIP IP phone B	The SIP proxy server sends an ACK to SIP IP phone B. The ACK confirms that the 486 Busy Here response has been received.
5	INVITE—SIP proxy server to SIP IP phone C	The SIP proxy server sends an INVITE request to Carol at SIP IP phone C to which Bob's calls have been configured to forward on busy. In the INVITE request, the proxy server changes the Request-URI to divert the request to Carol at SIP IP phone C and adds a CC-Diversion header containing the Request-URI from the initial INVITE request and the reason for the diversion.
6	180 Ringing—SIP IP phone C to SIP proxy server	SIP IP phone C sends a 180 Ringing response to the SIP proxy server.
7	180 Ringing—SIP proxy server to SIP IP phone A	The SIP proxy server forwards the 180 Ringing response to SIP IP phone A.
8	200 OK—SIP IP phone C to SIP proxy server	SIP IP phone C sends a 200 OK response to SIP IP phone A. If SIP IP phone C supports the media capability advertised in the INVITE message sent by the SIP proxy server, it advertises the intersection of its own and SIP IP phone A's media capability in the 200 OK response. If SIP IP phone C does not support the media capability advertised by SIP IP phone A, it sends back a 400 Bad Request response with a "Warning: 304 Codec negotiation failed" header field.
9	200 OK—SIP proxy server to SIP IP phone A.	The SIP proxy server forwards the 200 OK response to SIP IP phone A. The 200 OK response notifies the SIP IP phone A that Carol has answered the phone (for example, the handset of SIP IP phone C went off-hook).
10	ACK—SIP IP phone A to SIP IP phone C	SIP IP phone A sends an ACK to SIP IP phone C. The ACK confirms that SIP IP phone A has received the 200 OK response from SIP IP phone C.
At this point, a two-way RTP channel is established between SIP IP phone A and SIP IP phone C.

Step	Action	Description
1	INVITE—SIP IP phone A to SIP proxy server	Alice's SIP IP phone A sends an INVITE request to the proxy server. The INVITE request is an invitation to Bob to participate in a call session. In the INVITE request: Bob's phone number is inserted in the Request-URI field in the form of a SIP URL. The SIP URL identifies Bob's address and takes a form similar to an email address (user@host where user is the telephone number and host is either a domain name or a numeric network address). For example, the Request-URI field in the INVITE request to Bob might appear as "INVITE sip:555-0002@companyb.com; user=phone." The "user=phone" parameter distinguishes that the Request-URI address is a telephone number rather than a user name. Alice at 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 inserted in the Call-ID field. The transaction number within a single call leg is identified in the CSeq field. The media capability SIP IP phone A is ready to receive is specified in the SDP. The port on which SIP IP phone A is prepared to receive the RTP data is specified in the SDP.
2	INVITE—SIP proxy server to SIP IP phone B	The SIP proxy server forwards the INVITE request to Bob at SIP IP phone B.
3	486 Busy Here—SIP IP phone B to the SIP proxy server	SIP IP phone B sends a 486 Busy response to the SIP proxy server. The 486 Busy Here response is a client error response that indicates that Bob at SIP IP phone B phone was successfully contacted but Bob was either unwilling or unable to take another call.
4	ACK—SIP proxy server to SIP IP phone B	The SIP proxy server sends an ACK to SIP IP phone B. The ACK confirms that the 486 Busy Here response has been received.
5	302 Moved Temporarily—SIP proxy server to SIP IP phone A	The SIP proxy server sends a 302 Moved Temporarily message to SIP IP phone A. In the 302 Moved Temporarily message, Carol at SIP IP phone C is added as the Contact and a CC-Diversion header is added that contains the Request-URI from the initial INVITE and the reason for the diversion.
6	INVITE—SIP proxy server to SIP IP phone C	The SIP proxy server sends an INVITE request to Carol at SIP IP phone C to which Bob's calls have been configured to forward on busy. In the INVITE request, the proxy server changes the Request-URI to divert the request to Carol at SIP IP phone C and adds a CC-Diversion header containing the Request-URI from the initial INVITE request and the reason for the diversion.
7	180 Ringing—SIP IP phone C to SIP IP phone A	SIP IP phone C sends a 180 Ringing response to SIP IP phone A.
8	200 OK—SIP IP phone C to SIP IP phone A	SIP IP phone C sends a 200 OK response to SIP IP phone A. The 200 OK response notifies the SIP IP phone A that Carol has answered the phone (for example, the handset of SIP IP phone C went off-hook). If SIP IP phone C supports the media capability advertised in the INVITE message sent by the SIP proxy server, it advertises the intersection of its own and SIP IP phone A's media capability in the 200 OK response. If SIP IP phone C does not support the media capability advertised by SIP IP phone A, it sends back a 400 Bad Request response with a "Warning: 304 Codec negotiation failed" header field.
9	ACK—SIP IP phone A to SIP IP phone C	SIP IP phone A sends an ACK to SIP IP phone C. The ACK confirms that SIP IP phone A has received the 200 OK response from SIP IP phone C.
At this point, a two-way RTP channel is established between SIP IP phone A and SIP IP phone C.

SIP IP Phone-to-SIP IP Phone Call Forward No Answer

Figure 7-31 and Figure 7-32 illustrate a successful SIP IP phone-to-SIP IP phone call forward when there is no answer via a SIP proxy. In these scenarios, the three end users are identified as User A, User B, and User C. User B's calls are configured to forward to User C when a response timeout occurs. Figure 7-31 illustrates the call as processed by a recursive proxy and Figure 7-32 illustrates the call as processed by a non-recursive proxy.

Step	Action	Description
1	INVITE—SIP IP phone A to SIP proxy server	Alice's SIP IP phone A sends an INVITE request to the proxy server. The INVITE request is an invitation to Bob to participate in a call session. In the INVITE request: Bob's phone number is inserted in the Request-URI field in the form of a SIP URL. The SIP URL identifies Bob's address and takes a form similar to an email address (user@host where user is the telephone number and host is either a domain name or a numeric network address). For example, the Request-URI field in the INVITE request to Bob might appear as "INVITE sip:555-0002@companyb.com; user=phone." The "user=phone" parameter distinguishes that the Request-URI address is a telephone number rather than a user name. Alice at 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 inserted in the Call-ID field. The transaction number within a single call leg is identified in the CSeq field. The media capability SIP IP phone A is ready to receive is specified in the SDP. The port on which SIP IP phone A is prepared to receive the RTP data is specified in the SDP.
2	INVITE—SIP proxy server to SIP IP phone B	The proxy server forwards the INVITE request to Bob at SIP IP phone B.
3	180 Ringing—SIP IP phone B to the SIP proxy server	SIP IP phone B sends a 180 Ringing response to the SIP proxy server.
Call forward no answer timer expires.
4	INVITE—SIP proxy server phone to SIP IP phone C	The SIP proxy server sends an INVITE request to Carol at SIP IP phone C to which Bob's calls have been configured to forward when there is no answer. In the INVITE request, SIP IP phone A changes the Request-URI to divert the request to Carol at SIP IP phone C and adds a CC-Diversion header containing the Request-URI from the initial INVITE request and the reason for the diversion.
5	180 Ringing—SIP IP phone C to SIP proxy server	SIP IP phone C sends a 180 Ringing response to the SIP proxy server.
6	200 OK—SIP IP phone C to SIP proxy server	SIP IP phone C sends a 200 OK response to SIP IP phone A. If SIP IP phone C supports the media capability advertised in the INVITE message sent by the SIP proxy server, it advertises the intersection of its own and SIP IP phone A's media capability in the 200 OK response. If SIP IP phone C does not support the media capability advertised by SIP IP phone A, it sends back a 400 Bad Request response with a "Warning: 304 Codec negotiation failed" header field.
7	200 OK—SIP proxy server to SIP IP phone A	The SIP proxy server forwards the 200 OK response to SIP IP phone A. The 200 OK response notifies the SIP IP phone A that Carol has answered the phone (for example, the handset of SIP IP phone C went off-hook).
8	ACK—SIP IP phone A to SIP IP phone C	SIP IP phone A sends an ACK to SIP IP phone C. The ACK confirms that SIP IP phone A has received the 200 OK response from SIP IP phone C.
At this point, a two-way RTP channel is established between SIP IP phone A and SIP IP phone C.

Step	Action	Description
1	INVITE—SIP IP phone A to SIP proxy server	Alice's SIP IP phone A sends an INVITE request to the proxy server. The INVITE request is an invitation to Bob to participate in a call session. In the INVITE request: Bob's phone number is inserted in the Request-URI field in the form of a SIP URL. The SIP URL identifies Bob's address and takes a form similar to an email address (user@host where user is the telephone number and host is either a domain name or a numeric network address). For example, the Request-URI field in the INVITE request to Bob might appear as "INVITE sip:555-0002@companyb.com; user=phone." The "user=phone" parameter distinguishes that the Request-URI address is a telephone number rather than a user name. Alice at 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 inserted in the Call-ID field. The transaction number within a single call leg is identified in the CSeq field. The media capability SIP IP phone A is ready to receive is specified in the SDP. The port on which SIP IP phone A is prepared to receive the RTP data is specified in the SDP.
2	INVITE—SIP proxy server to SIP IP phone B	The SIP proxy server forwards the INVITE request to Bob at SIP IP phone B.
3	180 Ringing—SIP IP phone B to the SIP proxy server	SIP IP phone B sends a 180 Ringing response to the SIP proxy server.
At this point, a timeout to INVITE request occurs.
4	302 Moved Temporarily—SIP proxy server to SIP IP phone A	The SIP proxy server sends a 302 Moved Temporarily message to SIP IP phone A. In the 302 Moved Temporarily message, Carol at SIP IP phone C is added as the Contact and a CC-Diversion header is added that contains the Request-URI from the initial INVITE and the reason for the diversion.
5	INVITE—SIP IP phone A to SIP IP phone C	SIP IP phone A sends an INVITE request to Carol at SIP IP phone C to which Bob's calls have been configured to forward when Bob is unavailable. In the INVITE request, the SIP proxy server changes the Request-URI to divert the request to Carol at SIP IP phone C and adds a CC-Diversion header containing the Request-URI from the initial INVITE request and the reason for the diversion.
6	180 Ringing—SIP IP phone C to SIP IP phone A	SIP IP phone C sends a 180 Ringing response to SIP IP phone A.
7	200 OK—SIP IP phone C to SIP IP phone A	SIP IP phone C sends a 200 OK response to SIP IP phone A. The 200 OK response notifies the SIP IP phone A that Carol has answered the phone (for example, the handset of SIP IP phone C went off-hook). If SIP IP phone C supports the media capability advertised in the INVITE message sent by the SIP proxy server, it advertises the intersection of its own and SIP IP phone A's media capability in the 200 OK response. If SIP IP phone C does not support the media capability advertised by SIP IP phone A, it sends back a 400 Bad Request response with a "Warning: 304 Codec negotiation failed" header field.
8	ACK—SIP IP phone A to SIP IP phone C	SIP IP phone A sends an ACK to SIP IP phone C. The ACK confirms that SIP IP phone A has received the 200 OK response from SIP IP phone C.
At this point, a two-way RTP channel is established between SIP IP phone A and SIP IP phone C.

SIP IP Phone-to-SIP IP Phone Call Forward Unavailable

Figure 7-33 and Figure 7-34 illustrate a successful SIP IP phone-to-SIP IP phone call forward when the callee is unavailable via a SIP proxy. In these scenarios, the three end users are identified as User A, User B, and User C. User B's calls are configured to forward to User C when User B is unavailable. Figure 7-33 illustrates the call as processed by a recursive proxy and Figure 7-34 illustrates the call as processed by a non-recursive proxy.

Step	Action	Description
1	INVITE—SIP IP phone A to SIP proxy server	Alice's SIP IP phone A sends an INVITE request to the proxy server. The INVITE request is an invitation to Bob to participate in a call session. In the INVITE request: Bob's phone number is inserted in the Request-URI field in the form of a SIP URL. The SIP URL identifies Bob's address and takes a form similar to an email address (user@host where user is the telephone number and host is either a domain name or a numeric network address). For example, the Request-URI field in the INVITE request to Bob might appear as "INVITE sip:555-0002@companyb.com; user=phone." The "user=phone" parameter distinguishes that the Request-URI address is a telephone number rather than a user name. Alice at 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 inserted in the Call-ID field. The transaction number within a single call leg is identified in the CSeq field. The media capability SIP IP phone A is ready to receive is specified in the SDP. The port on which SIP IP phone A is prepared to receive the RTP data is specified in the SDP.
2	100 Trying—SIP proxy server to SIP IP phone A	The SIP proxy server sends a 100 Trying response to the INVITE request sent by SIP IP phone A. The 100 Trying response indicates that the INVITE request has been received by the SIP proxy server but that Bob at SIP IP phone B has not yet been located and that some unspecified action, such as a database consultation, is taking place.
3 to 5	INVITE—proxy server to SIP IP phone B	The SIP proxy server forwards the INVITE request to Bob at SIP IP phone B.
Call forward unavailable timer expires.
6	INVITE—SIP proxy server to SIP IP phone C	The SIP proxy server sends an INVITE request to Carol at SIP IP phone C to which Bob's calls have been configured to forward when there is no answer. In the INVITE request, SIP IP phone A changes the Request-URI to divert the request to Carol at SIP IP phone C, and adds a CC-Diversion header containing the Request-URI from the initial INVITE request and the reason for the diversion.
7	180 Ringing—SIP IP phone C to SIP proxy server	SIP IP phone C sends a 180 Ringing response to the SIP proxy server.
8	200 OK—SIP IP phone C to SIP proxy server	SIP IP phone C sends a 200 OK response to SIP IP phone A. If SIP IP phone C supports the media capability advertised in the INVITE message sent by the SIP proxy server, it advertises the intersection of its own and SIP IP phone A's media capability in the 200 OK response. If SIP IP phone C does not support the media capability advertised by SIP IP phone A, it sends back a 400 Bad Request response with a "Warning: 304 Codec negotiation failed" header field.
9	200 OK—SIP proxy server to SIP IP phone A	The SIP proxy server forwards the 200 OK response to SIP IP phone A. The 200 OK response notifies the SIP IP phone A that Carol has answered the phone (for example, the handset of SIP IP phone went off-hook).
10	ACK—SIP IP phone A to SIP IP phone B	SIP IP phone A sends an ACK to SIP IP phone C. The ACK confirms that SIP IP phone A has received the 200 OK response from SIP IP phone C.
At this point, a two-way RTP channel is established between SIP IP phone A and SIP IP phone C.

Step	Action	Description
1	INVITE—SIP IP phone A to SIP proxy server	Alice's SIP IP phone A sends an INVITE request to the proxy server. The INVITE request is an invitation to Bob to participate in a call session. In the INVITE request: Bob's phone number is inserted in the Request-URI field in the form of a SIP URL. The SIP URL identifies Bob's address and takes a form similar to an email address (user@host where user is the telephone number and host is either a domain name or a numeric network address). For example, the Request-URI field in the INVITE request to Bob might appear as "INVITE sip:555-0002@companyb.com; user=phone." The "user=phone" parameter distinguishes that the Request-URI address is a telephone number rather than a user name. Alice at 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 inserted in the Call-ID field. The transaction number within a single call leg is identified in the CSeq field. The media capability SIP IP phone A is ready to receive is specified in the SDP. The port on which SIP IP phone A is prepared to receive the RTP data is specified in the SDP.
2	100 Trying—SIP proxy server to SIP IP phone A	The SIP proxy server sends a 100 Trying response to the INVITE request sent by SIP IP phone A. The 100 Trying response indicates that the INVITE request has been received by the SIP proxy server, but that Bob has not yet been located and that some unspecified action, such as a database consultation, is taking place.
3 to 5	INVITE—proxy server to SIP IP phone B	The SIP proxy server forwards the INVITE request to Bob at SIP IP phone B.
At this point, the call forward unavailable timer expires.
6	302 Moved Temporarily—SIP proxy server to SIP IP phone A	The SIP proxy server sends a 302 Moved Temporarily message to SIP IP phone A. In the 302 Moved Temporarily message, Carol at SIP IP phone C is added as the Contact and a CC-Diversion header is added that contains the Request-URI from the initial INVITE and the reason for the diversion.
7	INVITE—SIP IP phone A to SIP IP phone C	SIP IP phone A sends an INVITE request to Carol at SIP IP phone C to which Bobs calls have been configured to forward when there is no answer. In the INVITE request, SIP IP phone A changes the Request-URI to divert the request to Carol at SIP IP phone C, and adds a CC-Diversion header containing the Request-URI from the initial INVITE request and the reason for the diversion.
8	180 Ringing—SIP IP phone C to SIP IP phone A	SIP IP phone C sends a 180 Ringing response to SIP IP phone A.
9	200 OK—SIP IP phone C to SIP IP phone A	SIP IP phone C sends a 200 OK response to SIP IP phone A. The 200 OK response notifies the SIP IP phone A that Carol has answered the phone (for example, the handset of SIP IP phone C went off-hook). If SIP IP phone C supports the media capability advertised in the INVITE message sent by the SIP proxy server, it advertises the intersection of its own and SIP IP phone A's media capability in the 200 OK response. If SIP IP phone C does not support the media capability advertised by SIP IP phone A, it sends back a 400 Bad Request response with a "Warning: 304 Codec negotiation failed" header field.
10	ACK—SIP IP phone A to SIP IP phone C	SIP IP phone A sends an ACK to SIP IP phone C. The ACK confirms that SIP IP phone A has received the 200 OK response from SIP IP phone C.
At this point, a two-way RTP channel is established between SIP IP phone A and SIP IP phone C.

Call Flow Scenarios for Failed Calls

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

SIP Gateway-to-SIP Gateway—Called User is Busy

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

Step	Action	Description
1	Setup—PBX A to SIP gateway 1	Call Setup is initiated between PBX A and SIP gateway 1. The Call Setup includes the standard transactions that take place as User A attempts to call User B.
2	INVITE—SIP gateway 1 to SIP gateway 2	SIP gateway 1 sends an INVITE request to SIP gateway 2. 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. 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 SIP gateway 1 is prepared to receive the RTP data is specified.
3	Call Proceeding—SIP gateway 1 to PBX A	SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
4	Setup—SIP gateway 2 to PBX B	SIP gateway 2 receives the INVITE request from SIP gateway 1 and initiates a Call Setup with User B via PBX B.
5	100 Trying—SIP gateway 2 to SIP gateway 1	SIP gateway 2 sends a 100 Trying response to the INVITE request sent by SIP gateway 1. The 100 Trying message indicates that the INVITE request has been received by SIP gateway 2 but that User B has not yet been located and that some unspecified action, such as a database consultation, is taking place.
6	Call Proceeding—PBX B to SIP gateway 2	PBX B sends a Call Proceeding message to SIP gateway 2 to acknowledge the Call Setup request.
7	Disconnect (Busy)—PBX B to SIP gateway 2	PBX B sends a Disconnect message to SIP gateway 2. In the Disconnect message, the cause code indicates that User B is busy. The Disconnect message starts the call session termination process.
8	486 Busy Here—SIP gateway 2 to SIP gateway 1	SIP gateway 2 maps the Release message cause code (Busy) to the 486 Busy Here response and sends the response to SIP gateway 1. The 486 Busy Here response is a client error response that indicates that User B's phone was successfully contacted but User B was either unwilling or unable to take another call.
9	Disconnect (Busy)—SIP gateway 1 to PBX A	SIP gateway 1 sends a Release message to PBX A. User A hears a busy tone.
10	Release—SIP gateway 2 to PBX B	SIP gateway 2 sends a Release message to PBX B.
11	Release—PBX A to SIP gateway 1	PBX A sends a Release message to SIP gateway 1.
12	ACK—SIP gateway 1 to SIP gateway 2	SIP gateway 1 sends an ACK to SIP gateway 2. The ACK confirms that the 486 Busy Here response has been received.
13	Release Complete—PBX B to SIP gateway 2	PBX B sends a Release Complete message to SIP gateway 2.
14	Release Complete—SIP gateway 1 to PBX A	SIP gateway 1 sends a Release Complete message to PBX A and the call session attempt is terminated.

SIP Gateway-to-SIP Gateway—Called User Does Not Answer

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

Step	Action	Description
1	Setup—PBX A to SIP gateway 1	Call Setup is initiated between PBX A and SIP gateway 1. The Call Setup includes the standard transactions that take place as User A attempts to call User B.
2	INVITE—SIP gateway 1 to SIP gateway 2	SIP gateway 1 sends an INVITE request to SIP gateway 2. 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. 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 SIP gateway 1 is prepared to receive the RTP data is specified.
3	Call Proceeding—SIP gateway 1 to PBX A	SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
4	Setup—SIP gateway 2 to PBX B	SIP gateway 2 receives the INVITE request from SIP gateway 1 and initiates a Call Setup with User B via PBX B.
5	100 Trying—SIP gateway 2 to SIP gateway 1	SIP gateway 2 sends a 100 Trying response to the INVITE request sent by SIP gateway 1. The 100 Trying response indicates that the INVITE request has been received by SIP gateway 2 but that User B has not yet been located and that some unspecified action, such as a database consultation, is taking place.
6	Call Proceeding—PBX B to SIP gateway 2	PBX B sends a Call Proceeding message to SIP gateway 2 to acknowledge the Call Setup request.
7	Alerting—PBX B to SIP gateway 2	PBX B sends an Alert message to SIP gateway 2. The message indicates that the PBX is attempting to alert the user of the call (that is to say, the phone is ringing).
8	180 Ringing—SIP gateway 2 to SIP gateway 1	SIP gateway 2 sends a 180 Ringing response to SIP gateway 1. The 180 Ringing response indicates that SIP gateway 2 has located, and is trying to alert, User B.
9	Alerting—SIP gateway 1 to PBX A	SIP gateway 1 sends an Alert message to PBX A. The Alert message indicates that SIP gateway 1 has received a 180 Ringing response from SIP gateway 2. User A hears the ringback tone that indicates that User B is being alerted.
10	Cancel (Ring Timeout)—SIP gateway 1 to SIP gateway 2	Because SIP gateway 2 did not return an appropriate response within the time specified by the Expires header in the INVITE request, SIP gateway 1 sends a SIP CANCEL request to SIP gateway 2. A CANCEL request cancels a pending request with the same Call-ID, To, From, and CSeq header field values.
11	Disconnect—SIP gateway 1 to PBX A	SIP gateway 1 sends a Disconnect message to PBX A.
12	Disconnect—SIP gateway 2 to PBX B	SIP gateway 2 sends a Disconnect message to PBX B.
13	Release—PBX A to SIP gateway 1	PBX A sends a Release message to SIP gateway 1.
14	Release—PBX B to SIP gateway 2	PBX B sends a Release message to SIP gateway 2.
15	200 OK—SIP gateway 2 to SIP gateway 1	SIP gateway 2 sends a 200 OK response to SIP gateway 2. The 200 OK response confirms that the Cancel request has been received.
16	Release Complete—SIP gateway 1 to PBX A	SIP gateway 1 sends a Release Complete message to PBX A.
17	Release Complete—SIP gateway 2 to PBX B	SIP gateway 2 sends a Release Complete message to PBX B and the call session attempt is terminated.

SIP Gateway-to SIP Gateway—Client, Server, or Global Error

Figure 7-37 illustrates an unsuccessful call in which User A initiates a call to User B but there are no more channels available on the gateway. Therefore, SIP gateway 2 refuses the connection.

Step	Action	Description
1	Setup—PBX A to SIP gateway 1	Call Setup is initiated between PBX A and SIP gateway 1. The Call Setup includes the standard transactions that take place as User A attempts to call User B.
2	INVITE—SIP gateway 1 to SIP gateway 2	SIP gateway 1 sends an INVITE request to SIP gateway 2. 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. 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 SIP gateway 1 is prepared to receive the RTP data is specified.
3	Call Proceeding—SIP gateway 1 to PBX A	SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
4	100 Trying—SIP gateway 2 to SIP gateway 1	SIP gateway 2 sends a 100 Trying response to the INVITE request sent by SIP gateway 1. The 100 Trying message indicates that the INVITE request has been received by SIP gateway 2 but that User B has not yet been located and that some unspecified action, such as a database consultation, is taking place.
5	Class 4xx/5xx/6xx Failure—SIP gateway 2 to SIP gateway 1	SIP gateway 2 determines that it does not have any more channels available, refuses the connection, and sends a SIP 503 Service Unavailable response to SIP gateway 1. The 503 Service Unavailable response is a class 4xx, 5xx, or class 6xx failure response. Depending on which class the failure response is, the call actions differ. If SIP gateway 2 sends a class 4xx failure response (a definite failure response that is a client error), the request will not be retried without modification. If SIP gateway 2 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 SIP gateway 2 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. The call failure on SIP gateway 2 might occur before a proceeding indication from PBX B. In that case a SIP failure response is sent before the 100 Trying response.
6	Disconnect—SIP gateway 1 to PBX A	SIP gateway 1 sends a Disconnect message to PBX A.
7	Release—PBX A to SIP gateway 1	PBX A sends a Release message to SIP gateway 1.
8	ACK—SIP gateway 1 to SIP gateway 2	SIP gateway 1 sends an ACK to SIP gateway 2. The ACK confirms that the 503 Service Unavailable response has been received.
9	Release Complete—SIP gateway 1 to PBX A	SIP gateway 1 sends a Release Complete message to PBX A and the call session attempt is terminated.

SIP Gateway-to-SIP Gateway via SIP Redirect Server—Called User is Busy

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

Step	Action	Description
1	Setup—PBX A to SIP gateway 1	Call Setup is initiated between PBX A and SIP gateway 1. The Call Setup includes the standard transactions that take place as User A attempts to call User B.
2	INVITE—SIP gateway 1 to SIP redirect server	SIP gateway 1 sends an INVITE request to the SIP redirect 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. 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 SIP gateway 1 is prepared to receive the RTP data is specified.
3	302 Moved Temporarily— SIP redirect server to SIP gateway 1	SIP redirect server sends a 302 Moved Temporarily message to SIP gateway 1. The message indicates that User B is not available and includes instructions to locate User B.
4	ACK—SIP gateway 1 to SIP redirect server	SIP gateway 1 acknowledges the 302 Moved Temporarily response with an ACK.
5	INVITE—SIP gateway 1 to SIP gateway 2	SIP gateway 1 sends a new INVITE request to User B. The new INVITE request includes the first contact listed in the 300 Multiple Choice response as the new address for User B, a higher transaction number in the CSeq field, and the same Call-ID as the first INVITE request.
6	Call Proceeding—SIP gateway 1 to PBX A	SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
7	Setup—SIP gateway 2 to PBX B	SIP gateway 2 receives the INVITE request from SIP gateway 1 and initiates a Call Setup with User B via PBX B.
8	100 Trying—SIP gateway 2 to SIP gateway 1	SIP gateway 2 sends a 100 Trying response to the INVITE request sent by SIP gateway 1. The 100 Trying response indicates that the INVITE request has been received by SIP gateway 2 but that User B has not yet been located and that some unspecified action, such as a database consultation, is taking place.
9	Call Proceeding—PBX B to SIP gateway 2	PBX B sends a Call Proceeding message to SIP gateway 2 to acknowledge the Call Setup request.
10	Disconnect (Busy)—PBX B to SIP gateway 2	PBX B sends a Disconnect message to SIP gateway 2. In the Disconnect message, the cause code indicates that User B is busy. The Disconnect message starts the call session termination process.
11	486 Busy Here—SIP gateway 2 to SIP gateway 1	SIP gateway 2 maps the Release message cause code (Busy) to the 486 Busy response and sends the response to SIP gateway 1. The 486 Busy Here response is a client error response that indicates that User B's phone was successfully contacted but User B was either unwilling or unable to take another call.
12	Disconnect (Busy) —SIP gateway 1 to PBX A	SIP gateway 1 sends a Disconnect message to PBX A. User A hears a busy tone.
13	Release—PBX A to SIP gateway 1	PBX A sends a Release message to SIP gateway 1.
14	Release—SIP gateway 2 to PBX B	SIP gateway 1 sends a Release message to PBX B.
15	ACK—SIP gateway 1 to SIP gateway 2	SIP gateway 1 sends an ACK to SIP gateway 2. The ACK confirms that the 486 Busy Here response has been received.
16	Release Complete—SIP gateway 1 to PBX A	SIP gateway 1 sends a Release Complete message to PBX A and the call session attempt is terminated.
17	Release Complete—PBX B to SIP gateway 2	PBX B sends a Release Complete message to SIP gateway 2.

SIP Gateway-to-SIP Gateway via SIP Redirect Server—Called User Does Not Answer

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

Step	Action	Description
1	Setup—PBX A to SIP gateway 1	Call Setup is initiated between PBX A and SIP gateway 1. The Call Setup includes the standard transactions that take place as User A attempts to call User B.
2	INVITE—SIP gateway 1 to SIP redirect server	SIP gateway 1 sends an INVITE request to the SIP redirect 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. 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 SIP gateway 1 is prepared to receive the RTP data is specified.
3	302 Moved Temporarily— SIP redirect server to SIP gateway 1	SIP redirect server sends a 302 Moved Temporarily message to SIP gateway 1. The message indicates that User B is not available and includes instructions to locate User B.
4	ACK—SIP gateway 1 to SIP redirect server	SIP gateway 1 acknowledges the 302 Moved Temporarily response with an ACK.
5	INVITE—SIP gateway 1 to SIP gateway 2	SIP gateway 1 sends a new INVITE request to User B. The new INVITE request includes a new address for User B, a higher transaction number in the CSeq field, but the same Call-ID as the first INVITE request.
6	Call Proceeding—SIP gateway 1 to PBX A	SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
7	Setup—SIP gateway 2 to PBX B	SIP gateway 2 receives the INVITE request from SIP gateway 1 and initiates a Call Setup with User B via PBX B.
8	100 Trying—SIP gateway 2 to SIP gateway 1	SIP gateway 2 sends a 100 Trying response to the INVITE request sent by SIP gateway 1. The 100 Trying message indicates that the INVITE request has been received by SIP gateway 2 but that User B has not yet been located and that some unspecified action, such as a database consultation, is taking place.
9	Call Proceeding—PBX B to SIP gateway 2	PBX B sends a Call Proceeding message to SIP gateway 2 to acknowledge the Call Setup request.
10	Alerting—PBX B to SIP gateway 2	PBX B sends an Alert message to SIP gateway 2. User B's phone begins to ring.
11	180 Ringing—SIP gateway 2 to SIP gateway 1	SIP gateway 2 sends a 180 Ringing response to SIP gateway 1. The 180 Ringing response indicates that SIP gateway 2 has located, and is trying to alert, User B.
12	Alerting—SIP gateway 1 to PBX A	SIP gateway 1 sends an Alert message to PBX A.
13	CANCEL (Ring Timeout)—SIP gateway 1 to SIP gateway 2	Because SIP gateway 2 did not return an appropriate response within the time specified by the Expires header in the INVITE request, SIP gateway 1 sends a SIP CANCEL request to SIP gateway 2. A CANCEL request cancels a pending request with the same Call-ID, To, From, and CSeq header field values.
14	Disconnect—SIP gateway 1 to PBX A	SIP gateway 1 sends a Disconnect message to PBX A.
15	Release—PBX A to SIP gateway 1	PBX A sends a Release message to SIP gateway 1.
16	Disconnect—SIP gateway 2 to PBX B	SIP gateway 2 sends a Disconnect message to PBX B.
17	200 OK—SIP gateway 1 to SIP gateway 2	SIP gateway 1 sends a 200 OK response to SIP gateway 2. The 200 OK response confirms that the CANCEL request has been received.
18	Release Complete—PBX A to SIP gateway 1	PBX A sends a Release Complete message to SIP gateway 1 and the call session attempt is terminated.
19	Release—PBX B to SIP gateway 2	PBX B sends a Release message to SIP gateway 2.
20	Release Complete—SIP gateway 2 to PBX B	SIP gateway 2 sends a Release Complete message to PBX B.

SIP Gateway-to-SIP Gateway via SIP Redirect Server—Client, Server, or Global Error

Figure 7-40 illustrates an unsuccessful call in which User A initiates a call to User B but SIP gateway 2 determines that User B does not exist at the domain specified in the INVITE request sent by SIP gateway 1. SIP gateway 2 refuses the connection.

Step	Action	Description
1	Setup—PBX A to SIP gateway 1	Call Setup is initiated between PBX A and SIP gateway 1. The Call Setup includes the standard transactions that take place as User A attempts to call User B.
2	INVITE—SIP gateway 1 to SIP redirect server	SIP gateway 1 sends an INVITE request to the SIP redirect 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. PBX A is identified as the 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 is specified. The port on which SIP gateway 1 is prepared to receive the RTP data is specified.
3	300 Multiple Choice—SIP redirect server to SIP gateway 1	The SIP redirect server sends a 300 Multiple Choice response to SIP gateway 1. The 300 Multiple Choice response indicates that the SIP redirect server accepted the INVITE request, contacted a location server with all or part of User B's SIP URL, and the location server provided a list of alternative locations where User B might be located. The SIP redirect server returns these possible addresses to User A in the 300 Multiple Choice response.
4	ACK—SIP gateway 1 to SIP redirect server	SIP gateway 1 acknowledges the 300 Multiple Choice response with an ACK.
5	INVITE—SIP gateway 1 to SIP gateway 2	SIP gateway 1 sends a new INVITE request to User B. The new INVITE request includes a new address for User B, a higher transaction number in the CSeq field, but the same Call-ID as the first INVITE request.
6	Call Proceeding—SIP gateway 1 to SIP gateway 2	SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
7	100 Trying—SIP gateway 2 to SIP gateway 1	SIP gateway 2 sends a 100 Trying response to the INVITE request sent by SIP gateway 1. The 100 Trying message indicates that the INVITE request has been received by SIP gateway 2 but that User B has not yet been located and that some unspecified action, such as a database consultation, is taking place.
8	Class 4xx/5xx/6xx Failure—SIP gateway 2 to SIP gateway 1	SIP gateway 2 determines that User B does not exist at the domain specified in the INVITE request sent by SIP gateway 1. SIP gateway 2 refuses the connection and sends a 404 Not Found response to SIP gateway 1. The 404 Not Found response is a class 4xx failure response. Depending on which class the failure response is, the call actions differ. If SIP gateway 2 sends a class 4xx failure response (a definite failure response that is a client error), the request will not be retried without modification. If SIP gateway 2 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 SIP gateway 2 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.
9	Disconnect—SIP gateway 1 to PBX A	SIP gateway 1 sends a Disconnect message to PBX A.
10	Release—PBX A to SIP gateway 1	PBX A sends a Release message to SIP gateway 1.
11	ACK—SIP gateway 1 to SIP gateway 2	SIP gateway 1 sends an ACK to SIP gateway 2. The ACK confirms that the 404 Not Found failure response has been received.
12	Release Complete—SIP gateway 1 to PBX A	SIP gateway 1 sends a Release Complete message to PBX A and the call session attempt is terminated.

SIP Gateway-to-SIP Gateway via SIP Proxy Server—Called User is Busy

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

Step	Action	Description
1	Setup—PBX A to SIP gateway 1	Call Setup is initiated between PBX A and SIP gateway 1. The Call Setup includes the standard transactions that take place as User A attempts to call User B.
2	INVITE—SIP gateway 1 to SIP proxy server	SIP gateway 1 sends an 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. 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 SIP gateway 1 is prepared to receive the RTP data is specified.
3	INVITE—SIP proxy server to SIP gateway 2	The SIP proxy server checks whether its own address is contained in the Via field (to prevent loops), directly copies the To, From, Call-ID, and Contact fields from the request it received from SIP gateway 1, changes the Request-URI to indicate the server to which it intends to send the INVITE request, and then sends a new INVITE request to SIP gateway 2.
4	Call Proceeding—SIP gateway 1 to PBX A	SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
5	Setup—SIP gateway 2 to PBX B	SIP gateway 2 receives the INVITE request from the SIP proxy server and initiates a Call Setup with User B via PBX B.
6	100 Trying—SIP proxy server to SIP gateway 1	The SIP proxy server sends a 100 Trying response to SIP gateway 1.
7	100 Trying—SIP gateway 2 to SIP proxy server	SIP gateway 2 sends a 100 Trying response to the SIP proxy server.
8	Release Complete (Busy)—PBX B to SIP gateway 2	PBX B sends a Release Complete message to SIP gateway 2. In the Release Complete message, the cause code indicates that User B is busy. The Release Complete message starts the call session termination process.
9	486 Busy Here—SIP gateway 2 to SIP proxy server	SIP gateway 2 maps the Release message cause code (Busy) to the 486 Busy response and sends the response to the SIP proxy server. The 486 Busy Here response is a client error response that indicates that User B's phone was successfully contacted but User B was either unwilling or unable to take another call.
10	486 Busy Here—SIP proxy server to SIP gateway 1	The SIP proxy server forwards the 486 Busy response to SIP gateway 1.
11	Disconnect (Busy)—SIP gateway 1 to PBX A	SIP gateway 1 sends a Disconnect message to PBX A.
12	Release—PBX A to SIP gateway 1	PBX A sends a Release message to SIP gateway 1.
13	ACK—SIP gateway 1 to SIP proxy server	SIP gateway 1 sends an SIP ACK to the SIP proxy server.
14	ACK—SIP proxy server to SIP gateway 2	The SIP proxy server forwards the SIP ACK to SIP gateway 2. The ACK confirms that the 486 Busy Here response has been received.
15	Release Complete—SIP gateway 1 to PBX A	SIP gateway 1 sends a Release Complete message to PBX A and the call session attempt is terminated.

SIP Gateway-to-SIP Gateway via SIP Proxy Server—Client or Server Error

Figure 7-42 illustrates an unsuccessful call in which User A initiates a call to User B but there are no more channels available on SIP gateway 2. Therefore, SIP gateway 2 refuses the connection.

Step	Action	Description
1	Setup—PBX A to SIP gateway 1	Call Setup is initiated between PBX A and SIP gateway 1. The Call Setup includes the standard transactions that take place as User A attempts to call User B.
2	INVITE—SIP gateway 1 to SIP proxy server	SIP gateway 1 sends an 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. PBX A is identified as the 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 SIP gateway 1 is prepared to receive the RTP data is specified.
3	INVITE—SIP proxy server to SIP gateway 2	The SIP proxy server checks whether its own address is contained in the Via field (to prevent loops), directly copies the To, From, Call-ID, and Contact fields from the request it received from SIP gateway 1, changes the Request-URI to indicate the server to which it intends to send the INVITE request, and then sends a new INVITE request to SIP gateway 2.
4	Call Proceeding—SIP gateway 1 to PBX A	SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
5	100 Trying—SIP proxy server to SIP gateway 1	The SIP proxy server sends a 100 Trying response to SIP gateway 1.
6	100 Trying—SIP gateway 2 to SIP proxy server	SIP gateway 2 sends a 100 Trying response to the SIP proxy server.
7	Class 4xx/5xx/6xx Failure—SIP gateway 2 to SIP proxy server	SIP gateway 2 determines that it does not have any more channels available, refuses the connection, and sends a SIP 503 Service Unavailable response to the SIP proxy server.
8	Class 4xx/5xx/6xx Failure—SIP proxy server to SIP gateway 1	The SIP proxy server forwards the SIP 503 Service Unavailable response to SIP gateway 1.
9	Disconnect—SIP gateway 1 to PBX A	SIP gateway 1 sends a Disconnect message to PBX A.
10	Release—PBX A to SIP gateway 1	PBX A sends a Release message to SIP gateway 1.
11	ACK—SIP gateway 1 to SIP proxy server	SIP gateway 1 sends an ACK to the SIP proxy server.
12	ACK—SIP proxy server to SIP gateway 2	The SIP proxy server forwards the SIP ACK to SIP gateway 2. The ACK confirms that the 503 Service Unavailable response has been received.
13	Release Complete—SIP gateway 1 to PBX A	SIP gateway 1 sends a Release Complete message to PBX A and the call session attempt is terminated.

SIP Gateway-to-SIP Gateway via SIP Proxy Server—Global Error

Figure 7-43 illustrates an unsuccessful call in which User A initiates a call to User B and receives a class 6xx response.

Step	Action	Description
1	Setup—PBX A to SIP gateway 1	Call Setup is initiated between PBX A and SIP gateway 1. The Call Setup includes the standard transactions that take place as User A attempts to call User B.
2	INVITE—SIP gateway 1 to SIP proxy server	SIP gateway 1 sends an 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. 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 SIP gateway 1 is prepared to receive the RTP data is specified.
3	Call Proceeding—SIP gateway 1 to PBX A	SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
4	INVITE—SIP proxy server to SIP gateway 2	The SIP proxy server checks whether its own address is contained in the Via field (to prevent loops), directly copies the To, From, Call-ID, and Contact fields from the request it received from SIP gateway 1, changes the Request-URI to indicate the server to which it intends to send the INVITE request, and then sends a new INVITE request to SIP gateway 2.
5	Setup—SIP gateway 2 to PBX B	SIP gateway 2 receives the INVITE request from the SIP proxy server and initiates a Call Setup with User B via PBX B.
6	100 Trying—SIP gateway 2 to SIP proxy server	SIP gateway 2 sends a 100 Trying response to the SIP proxy server. The SIP proxy server might or might not forward the 100 Trying response to SIP gateway 1.
7	100 Trying—SIP proxy server to SIP gateway 1	The SIP proxy server forwards the 100 Trying response to SIP gateway 1.
8	Release Complete—PBX B to SIP gateway 2	PBX B sends a Release Complete message to SIP gateway 2. The Release Complete message starts the call session termination process.
9	6xx Failure—SIP gateway 2 to SIP proxy server	SIP gateway 2 sends a class 6xx failure response (a global error) to the SIP proxy server. A class 6xx failure response indicates that a server has definite information about User B, but not for the particular instance indicated in the Request-URI field. All further searches for this user will fail, therefore the search is terminated. The SIP proxy server must forward all class 6xx failure responses to the client.
10	6xx Failure—SIP proxy server to SIP gateway 1	The SIP proxy server forwards the 6xx failure to SIP gateway 1.
11	Disconnect—SIP gateway 1 to PBX A	SIP gateway 1 sends a Disconnect message to PBX A.
12	Release—PBX A to SIP gateway 1	PBX A sends a Release message to SIP gateway 1.
13	ACK—SIP gateway 1 to SIP proxy server	SIP gateway 1 sends an ACK to the SIP proxy server.
14	ACK—SIP proxy server to SIP gateway 2	The SIP proxy server sends an ACK to SIP gateway 2. The ACK confirms that the 6xx failure response has been received.
15	Release Complete—SIP gateway 1 to PBX A	SIP gateway 1 sends a Release Complete message to PBX A and the call session attempt is terminated.

SIP Gateway-to-SIP IP Phone—Called User is Busy

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

Step	Action	Description
1	Setup—PBX A to SIP gateway 1	Call Setup is initiated between PBX A and SIP gateway 1. The Call Setup includes the standard transactions that take place as User A attempts to call User B.
2	INVITE—SIP gateway 1 to SIP IP phone	SIP 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. SIP gateway 1 sends an INVITE request to the address it receives in the dial peer which, in this scenario, is the SIP IP phone. In the INVITE request: The IP address of the 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 SIP gateway is prepared to receive the RTP data is specified.
3	Call Proceeding—SIP gateway 1 to PBX A	SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
4	100 Trying—SIP IP phone to SIP gateway 1	The SIP IP phone sends a 100 Trying response to SIP gateway 1. The 100 Trying response indicates that the INVITE request has been received by the SIP IP phone.
5	486 Busy Here—SIP IP phone to SIP gateway 1	The SIP IP phone sends a 486 Busy Here response to SIP gateway 1. The 486 Busy Here response is a client error response that indicates that User B was successfully contacted but User B was either unwilling or unable to take the call.
6	Disconnect (Busy)—SIP gateway 1 to PBX A	SIP gateway 1 sends a Disconnect message to PBX A.
7	Release—PBX A to SIP gateway 1	PBX A sends a Release message to SIP gateway 1.
8	ACK—SIP gateway 1 to SIP IP phone	SIP gateway 1 sends an ACK to the 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—SIP gateway 1 to PBX A	SIP gateway 1 sends a Release Complete message to PBX A and the call session attempt is terminated.

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

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

Step	Action	Description
1	Setup—PBX A to SIP gateway 1	Call Setup is initiated between PBX A and SIP gateway 1. The Call Setup includes the standard transactions that take place as User A attempts to call User B.
2	INVITE—SIP gateway 1 to SIP IP phone	SIP 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. SIP gateway 1 sends an INVITE request to the address it receives in the dial peer which, in this scenario, is the SIP IP phone. In the INVITE request: The IP address of the 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 SIP gateway is prepared to receive the RTP data is specified.
3	Call Proceeding—SIP gateway 1 to PBX A	SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
4	100 Trying—SIP IP phone to SIP gateway 1	The SIP IP phone sends a 100 Trying response to SIP gateway 1. The 100 Trying response indicates that the INVITE request has been received by the SIP IP phone.
5	180 Ringing—SIP IP phone to SIP gateway 1	The SIP IP phone sends a 180 Ringing response to SIP gateway 1. The 180 Ringing response indicates that the user is being alerted.
6	Alerting—SIP gateway 1 to PBX A	SIP gateway 1 sends an Alert message to PBX A. The Alert message indicates that SIP gateway 1 has received a 180 Ringing response from the SIP IP phone. User A hears the ringback tone that indicates that User B is being alerted.
7	CANCEL (Ring Timeout)—SIP gateway 1 to SIP IP phone	Because SIP gateway 1 did not return an appropriate response within the time specified by the Expires header in the INVITE request, SIP gateway 1 sends a SIP CANCEL request to SIP gateway 2. A CANCEL request cancels a pending request with the same Call-ID, To, From, and CSeq header field values.
8	Disconnect—SIP gateway 1 to PBX A	SIP gateway 1 sends a Disconnect message to PBX A.
9	Release Complete—SIP gateway 1 to PBX A	SIP gateway 1 sends a Release Complete message to PBX A and the call session attempt is terminated.
10	200 OK—SIP IP phone to SIP gateway 1	The SIP IP phone sends a 200 OK response to SIP gateway 1. The 200 OK response confirms that User A has received the Cancel request. The call session attempt is now being terminated.
11	Release Complete—SIP gateway 1 to PBX A	SIP gateway 1 sends a Release Complete message to PBX A and the call session is terminated.

SIP Gateway-to-SIP IP Phone—Client, Server, or Global Error

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

Step	Action	Description
1	Setup—PBX A to SIP gateway 1	Call Setup is initiated between PBX A and SIP gateway 1. The Call Setup includes the standard transactions that take place as User A attempts to call User B.
2	INVITE—SIP gateway 1 to SIP IP phone	SIP 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. SIP gateway 1 sends an INVITE request to the address it receives in the dial peer which, in this scenario, is the SIP IP phone. In the INVITE request: The IP address of the 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 SIP gateway is prepared to receive the RTP data is specified.
3	Call Proceeding—SIP gateway 1 to PBX A	SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
4	100 Trying—SIP IP phone to SIP gateway 1	The SIP IP phone sends a 100 Trying response to SIP gateway 1. The 100 Trying response indicates that the INVITE request has been received by the SIP IP phone.
5	4xx/5xx/6xx Failure—SIP IP phone to SIP gateway 1	The SIP IP phone sends a class 4xx, 5xx, or class 6xx failure response to SIP gateway 1. Depending on which class the failure response is, the call actions differ. If the 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 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 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—SIP gateway 1 to PBX A	SIP gateway 1 sends a Release message to PBX A.
7	Release—PBX A to SIP gateway 1	PBX A sends a Release message to SIP gateway 1.
8	ACK—SIP gateway 1 to SIP IP phone	SIP gateway 1 sends an ACK to the SIP IP phone. The ACK confirms that User A has received the 4xx/5xx/6xx failure response. The call session attempt is now being terminated.
9	Release Complete—SIP gateway 1 to PBX A	SIP gateway 1 sends a Release Complete message to PBX A and the call session attempt is terminated.

SIP IP Phone-to-SIP IP Phone—Called User is Busy

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

SIP IP Phone-to-SIP IP Phone—Call Screening Based on Caller

If your SIP proxy server has the capability, you can configure the proxy with lists that restrict incoming calls to only those from a list of allowed numbers. Figure 7-48 illustrates an unsuccessful call in which User A initiates a call to User B but User B has implemented a call screening list on the SIP proxy server and User A is not on that list.

SIP IP Phone-to-SIP IP Phone—Disallowed List

If your SIP proxy server has the capability, you can configure the proxy with lists that block outgoing calls to certain numbers or certain classes of numbers, such as 900 numbers.

Figure 7-49 illustrates an unsuccessful call in which User A initiates a call to User B but the SIP proxy server has been configured to block calls from User A to User B.

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

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

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

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

Step	Action	Description
1	INVITE—SIP IP phone A to SIP proxy server	SIP IP phone A sends an 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. 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 SIP IP phone A	SIP proxy server sends a 407 Authentication Error response to SIP IP phone A.
3	ACK—SIP IP phone A to SIP proxy server	SIP IP phone A sends a ACK to the SIP proxy server acknowledging the 407 error message.
4	Resend INVITE—SIP IP phone A to SIP proxy server	SIP IP phone A resends an INVITE to the SIP proxy server. The INVITE includes the Proxy-authenticate header with authentication credentials.

Table of Contents

SIP Call-Flow Process for the Cisco VoIP Infrastructure Solution for SIP