Session Initiation Protocol Gateway Call Flows

Step	Action	Description
1	Setup---PBX A -> GW1	Call Setup is initiated between PBX A and GW1. The Call Setup includes the standard transactions that take place as User A attempts to call User B.
2	INVITE---GW1 -> PS	GW1 sends a SIP INVITE request to the 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 GW1 is prepared to receive the RTP data is specified.
3	Call Proceeding---GW1 -> PBX A	GW1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
4	INVITE---PS -> GW2	The proxy server checks whether it's 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 GW1, 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 GW2.
5	100 Trying---PS -> GW1	The proxy server sends a SIP 100 Trying response to GW1.
6	Setup---GW2 -> PBX B	GW2 receives the INVITE request from the proxy server and initiates a Call Setup with User B via PBX B.
7	100 Trying---GW2 -> PS	GW2 sends a SIP 100 Trying response to the proxy server. The proxy server might or might not forward the 100 Trying response to GW1.
8	Call Proceeding---PBX B -> GW2	PBX B sends a Call Proceeding message to GW2 to acknowledge the Call Setup request.
9	Alerting---PBX B -> GW2	PBX B locates User B and sends an Alert message to GW2. User B's phone begin to ring.
10	180 Ringing---GW2 -> PS	GW2 sends a SIP 180 Ringing response to the proxy server.
11	180 Ringing---PS -> GW1	The proxy server forwards the 180 Ringing response to GW1.
12	Alerting---GW1 -> PBX A	GW1 sends an Alert message to User A via PBX A. The Alert message indicates that GW1 has received a 180 Ringing response. User A hears the ringback tone that indicates that User B is being alerted.
13	Connect---PBX B -> GW2	User B answers the phone. PBX B sends a Connect message to GW2. The connect message notifies GW2 that the connection has been made.
14	200 OK---GW2 -> PS	GW2 sends a SIP 200 OK response to the proxy server. The 200 OK response notifies the proxy server that the connection has been made. If User B 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 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 proxy server must forward 200 OK responses upstream.
15	200 OK---PS -> GW1	The proxy server forwards the 200 OK response that it received from GW2 to GW1.
16	Connect---GW1 -> PBX A	GW1 sends a Connect message to PBX A. The Connect message notifies PBX A that the connection has been made.
17	Connect ACK---PBX A -> GW1	PBX A acknowledges GW1's Connect message.
18	ACK---GW1 -> PS	GW1 sends a SIP ACK request to the proxy server. The ACK request confirms that GW1 has received the 200 OK response from the proxy server. The ACK request might contain a message body with the final session description to be used by User B. If the message body of the ACK request is empty, User B uses the session description in the INVITE request.
19	ACK---PS -> GW2	Depending on the values in the To, From, CSeq, and Call-ID field, the proxy server might process the ACK request locally or proxy it. If the fields in the ACK request match those in previous requests processed by the proxy server, the server proxies the ACK request. If there is no match, the ACK request is proxied as if it were an INVITE request. The proxy server forwards GW1's ACK response to GW2.
20	Connect ACK---GW2 -> PBX B	GW2 acknowledges PBX B's Connect message. The call session is now active. Note The 2-way voice path is established directly between GW1 and GW2; not via the proxy server.
21	Disconnect---PBX B -> GW2	After the call is completed, PBX B sends a Disconnect message to GW2. The Disconnect message starts the call session termination process.
22	BYE---GW2 -> PS	GW2 sends a SIP BYE request to the 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---PS -> GW1	The proxy server forwards the SIP BYE request to GW1.
24	Disconnect---GW1 -> PBX A	GW1 sends a Disconnect message to PBX A.
25	Release---GW2 -> PBX B	After the call is completed, GW2 sends a Release message to PBX B.
26	Release---PBX A -> GW1	PBX A sends a Release message to GW1.
27	200 OK---GW1 -> PS	GW1 sends a SIP 200 OK response to the proxy server. The 200 OK response notifies GW2 that GW1 has received the BYE request.
28	200 OK---PS -> GW2	The proxy server forwards the 200 OK response to GW2.
29	Release Complete---PBX B -> GW2	PBX B sends a Release Complete message to GW2.
30	Release Complete---GW1 -> PBX A	GW1 sends a Release Complete message to PBX A and the call session is terminated.

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

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

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

Step	Action	Description
1	Setup---PBX A -> GW1	Call Setup is initiated between PBX A and GW1. The Call Setup includes the standard transactions that take place as User A attempts to call User B.
2	INVITE---GW1 -> RS	GW1 sends a SIP INVITE request to the 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 GW1 is prepared to receive the RTP data is specified.
3	300 Multiple Choice---RS -> GW1	The redirect server sends GW1 a SIP 300 Multiple Choice response. The 300 Multiple Choice response indicates that the 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 redirect server returns these possible addresses to GW1 in the 300 Multiple Choice response.
4	ACK---GW1 -> RS	GW1 acknowledges the 300 Multiple Choice response with a SIP ACK request.
5	INVITE---GW1 -> GW2	GW1 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---GW1 -> PBX A	GW1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
7	Setup---GW2 -> PBX B	GW2 receives the INVITE request from GW1 and initiates a Call Setup with User B via PBX B.
8	100 Trying---GW2 -> GW1	GW2 sends a SIP 100 Trying response to the INVITE request sent by GW1. The 100 Trying response indicates that the INVITE request has been received by GW2 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 -> GW2	PBX B sends a Call Proceeding message to GW2 to acknowledge the Call Setup request.
10	Disconnect (Busy)---PBX B -> GW2	PBX B sends a Disconnect message to GW2. 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---GW2 - > GW1	GW2 maps the Release message cause code (Busy) to the SIP 486 Busy response and sends the response to GW1. The 486 Busy Here response is a client error response that indicates that User B's phone was successfully contacted but User B was not willing or was unable to take another call.
12	Disconnect (Busy) ---GW1 -> PBX A	GW1 sends a Disconnect message to PBX A. User A hears a busy tone.
13	Release---PBX A -> GW1	PBX A sends a Release message to GW1.
14	Release---GW2 -> PBX B	GW1 sends a Release message to PBX B.
15	ACK---GW1 -> GW2	GW1 sends a SIP ACK request to GW2. The ACK request confirms that the 486 Busy Here response has been received.
16	Release Complete---GW1 -> PBX A	GW1 sends a Release Complete message to PBX A and the call session attempt is terminated.
17	Release Complete---PBX B -> GW2	PBX B sends a Release Complete message to GW2.

Step	Action	Description
1	Setup---PBX A -> GW1	Call Setup is initiated between PBX A and GW1. The Call Setup includes the standard transactions that take place as User A attempts to call User B.
2	INVITE---GW1 -> RS	GW1 sends a SIP INVITE request to the 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 GW1 is prepared to receive the RTP data is specified.
3	300 Multiple Choice---RS -> GW1	The redirect server sends GW1 a SIP 300 Multiple Choice response. The 300 Multiple Choice response indicates that the 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 redirect server returns these possible addresses to User A in the 300 Multiple Choice response.
4	ACK---GW1 -> RS	GW1 acknowledges the 300 Multiple Choice response with a SIP ACK request.
5	INVITE---GW1 -> GW2	GW1 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---GW1 -> PBX A	GW1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
7	Setup---GW2 -> PBX B	GW2 receives the INVITE request from GW1 and initiates a Call Setup with User B via PBX B.
8	100 Trying---GW2 -> GW1	GW2 sends a SIP 100 Trying response to the INVITE request sent by GW1. The 100 Trying message indicates that the INVITE request has been received by GW2 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 -> GW2	PBX B sends a Call Proceeding message to GW2 to acknowledge the Call Setup request.
10	Alerting---PBX B -> GW2	PBX B sends an Alert message to GW2. User B's phone begins to ring.
11	180 Ringing---GW2 -> GW1	GW2 sends a SIP 180 Ringing response to GW1. The 180 Ringing response indicates that GW2 has located, and is trying to alert, User B.
12	Alerting---GW1 to PBX A	GW1 sends an Alert message to PBX A.
13	CANCEL (Ring Timeout)---GW1 - > GW2	Because GW2 did not return an appropriate response within the time allocated in the INVITE request, GW1 sends a SIP CANCEL request to GW2. A CANCEL request cancels a pending request with the same Call-ID, To, From, and CSeq header field values.
14	Disconnect---GW1 -> PBX A	GW1 sends a Disconnect message to PBX A.
15	Release---PBX A to GW1	PBX A sends a Release message to GW1.
16	Disconnect---GW2 -> PBX B	GW2 sends a Disconnect message to PBX B.
17	200 OK---GW1 -> GW2	GW1 sends a SIP 200 OK response to GW2. The 200 OK response confirms that the CANCEL request has been received.
18	Release Complete---PBX A -> GW1	PBX A sends a Release Complete message to GW1 and the call session attempt is terminated.
19	Release---PBX B -> GW2	PBX B sends a Release message to GW2.
20	Release Complete---GW2 -> PBX B	GW2 sends a Release Complete message to PBX B.

Step	Action	Description
1	Setup---PBX A -> GW1	Call Setup is initiated between PBX A and GW1. The Call Setup includes the standard transactions that take place as User A attempts to call User B.
2	INVITE---GW1 -> RS	GW1 sends a SIP INVITE request to the 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's 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 GW1 is prepared to receive the RTP data is specified.
3	300 Multiple Choice---RS -> GW1	The redirect server sends GW1 a SIP 300 Multiple Choice response. The 300 Multiple Choice response indicates that the 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 redirect server returns these possible addresses to User A in the 300 Multiple Choice response.
4	ACK---GW1 -> RS	GW1 acknowledges the 300 Multiple Choice response with a SIP ACK request.
5	INVITE---GW1 -> GW2	GW1 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---GW1 -> GW2	GW1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
7	100 Trying---GW2 -> GW1	GW2 sends a SIP 100 Trying response to the INVITE request sent by GW1. The 100 Trying message indicates that the INVITE request has been received by GW2 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---GW2 -> GW1	GW2 determines that User B does not exist at the domain specified in the INVITE request sent by GW1. GW2 refuses the connection and sends a SIP 404 Not Found response to GW1. The 404 Not Found response is a class 4xx failure response. Depending on which class the failure response is, the call actions differ. If GW2 sends a class 4xx failure response (a definite failure response that is a client error), the request will not be retried without modification. If GW2 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 GW2 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---GW1 -> PBX A	GW1 sends a Disconnect message to PBX A.
10	Release---PBX A -> GW1	PBX A sends a Release message to GW1.
11	ACK---GW1 -> GW2	GW1 sends a SIP ACK request to GW2. The ACK request confirms that the failure response has been received.
12	Release Complete---GW1 -> PBX A	GW1 sends a Release Complete message to PBX A and the call session attempt is terminated.

Step	Action	Description
1	Setup---PBX A -> GW1	Call Setup is initiated between PBX A and GW1. The Call Setup includes the standard transactions that take place as User A attempts to call User B.
2	INVITE---GW1 -> PS	GW1 sends a SIP INVITE request to the 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 GW1 is prepared to receive the RTP data is specified.
3	INVITE---PS -> GW2	The proxy server checks whether it's 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 GW1, 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 GW2.
4	Call Proceeding---GW1 -> PBX A	GW1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
5	Setup---GW2 -> PBX B	GW2 receives the INVITE request from the proxy server and initiates a Call Setup with User B via PBX B.
6	100 Trying---PS -> GW1	The proxy server sends a SIP 100 Trying response to GW1.
7	100 Trying---GW2 -> PS	GW2 sends a SIP 100 Trying response to the proxy server.
8	Release Complete (Busy)---PBX B -> GW2	PBX B sends a Release Complete message to GW2. 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---GW2 -> PS	GW2 maps the Release message cause code (Busy) to the SIP 486 Busy response and sends the response to the 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 not willing or was unable to take another call. The proxy server must send a SIP ACK request upon receiving a class 4xx failure response.
10	486 Busy Here---PS -> GW1	The proxy server forwards the SIP 486 Busy response to GW1.
11	Disconnect (Busy)---GW1 -> PBX A	GW1 sends a Disconnect message to PBX A.
12	Release---PBX A -> GW1	PBX A sends a Release message to GW1.
13	ACK---GW1 -> PS	GW1 sends an SIP ACK request to the proxy server.
14	ACK---PS -> GW2	The proxy server forwards the SIP ACK request to GW2. The ACK request confirms that the 486 Busy Here response has been received.
15	Release Complete---GW1 -> PBX A	GW1 sends a Release Complete message to PBX A and the call session attempt is terminated.

Step	Action	Description
1	Setup---PBX A -> GW1	Call Setup is initiated between PBX A and GW1. The Call Setup includes the standard transactions that take place as User A attempts to call User B.
2	INVITE---GW1 -> PS	GW1 sends a SIP INVITE request to the 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. 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 GW1 is prepared to receive the RTP data is specified.
3	INVITE---PS -> GW2	The proxy server checks whether it's 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 GW1, 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 GW2.
4	Call Proceeding---GW1 -> PBX A	GW1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
5	100 Trying---PS -> GW1	The proxy server sends a SIP 100 Trying response to GW1.
6	100 Trying---GW2 -> PS	GW2 sends a SIP 100 Trying response to the proxy server.
7	Class 4xx/5xx/6xx Failure---GW2 -> PS	GW2 determines that it does not have any more channels available, refuses the connection, and sends a SIP 503 Service Unavailable response to GW1. 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 GW2 sends a class 4xx or 5xx failure response to the proxy server. Depending on which class the failure response is, the call actions differ. If GW2 sends a class 4xx failure response (a definite failure response that is a client error), the request will not be retried without modification and the proxy server must send an ACK request. If GW2 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 and again, the proxy server must send an ACK request.
8	Class 4xx/5xx/6xx Failure---PS -> GW1	The proxy server forwards the SIP 503 Service Unavailable response to GW1.
9	Disconnect---GW1 -> PBX A	GW1 sends a Disconnect message to PBX A.
10	Release---PBX A -> GW1	PBX A sends a Release message to GW1.
11	ACK---GW1 -> PS	GW1 sends a SIP ACK request to the proxy server.
12	ACK---PS -> GW2	The proxy server forwards the SIP ACK request to GW2. The ACK request confirms that the 486 Busy Here response has been received.
13	Release Complete---GW1 -> PBX A	GW1 sends a Release Complete message to PBX A and the call session attempt is terminated.

Step	Action	Description
1	Setup---PBX A -> GW1	Call Setup is initiated between PBX A and GW1. The Call Setup includes the standard transactions that take place as User A attempts to call User B.
2	INVITE---GW1 -> PS	GW1 sends a SIP INVITE request to the 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 GW1 is prepared to receive the RTP data is specified.
3	Call Proceeding---GW1 -> PBX A	GW1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
4	INVITE---PS -> GW2	The proxy server checks whether it's 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 GW1, 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 GW2.
5	Setup---GW2 -> PBX B	GW2 receives the INVITE request from the proxy server and initiates a Call Setup with User B via PBX B.
6	100 Trying---GW2 -> PS	GW2 sends a SIP 100 Trying response to the proxy server. The proxy server might or might not forward the 100 Trying response to GW1.
7	100 Trying---PS -> GW1	The proxy server forwards the SIP 100 Trying response to GW1.
8	Release Complete---PBX B - > GW2	PBX B sends a Release Complete message to GW2. The Release Complete message starts the call session termination process.
9	6xx Failure---GW2 -> GW1	GW2 sends a class 6xx failure response (a global error) to GW1. 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 proxy server must forward all class 6xx failure responses to the client and send an ACK.
10	6xx Failure---PS -> GW1	The proxy server forwards the 6xx failure to GW1.
11	Disconnect---GW1 -> PBX A	GW1 sends a Disconnect message to PBX A.
12	Release---PBX A -> GW1	PBX A sends a Release message to GW1.
13	ACK---GW1 -> PS	GW1 sends a SIP ACK request to the proxy server.
14	ACK---PS -> GW2	The proxy server sends a SIP ACK request to GW2. The ACK request confirms that the 486 Busy Here response has been received.
15	Release Complete---GW1 -> PBX A	GW1 sends a Release Complete message to PBX A and the call session attempt is terminated.

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

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