Table Of Contents
Cisco SIP Proxy Server (CSPS) Call Flows
SIP Messages and Methods
Requests
Responses
The Registration Process
The Invitation Process
Call Flow Scenarios for Successful Calls
SIP Gateway-to-SIP Gateway—Call via SIP Redirect Server
SIP Gateway-to-SIP Gateway—Call via SIP Proxy Server
SIP IP Phone-to-SIP IP Phone Call Forward Unconditionally
SIP IP Phone-to-SIP IP Phone Call Forward on Busy
SIP IP Phone-to-SIP IP Phone Call Forward No Answer
SIP IP Phone-to-SIP IP Phone Call Forward Unavailable
Call Flow Scenarios for Failed Calls
SIP Gateway-to-SIP Gateway via SIP Redirect Server—Called User is Busy
SIP Gateway-to-SIP Gateway via SIP Redirect Server—Called User Does Not Answer
SIP Gateway-to-SIP Gateway via SIP Redirect Server—Client, Server, or Global Error
SIP Gateway-to-SIP Gateway via SIP Proxy Server—Called User is Busy
SIP Gateway-to-SIP Gateway via SIP Proxy Server—Client or Server Error
SIP Gateway-to-SIP Gateway via SIP Proxy Server—Global Error
SIP phone-to-SIP/H.323 Gateway—Call via SIP Proxy Server with Record-Route disabled
SIP phone-to-SIP/H.323 Gateway—Call via SIP Proxy Server with Record-Route enabled
SIP Phone to SIP/H.323 Gateway—Call via SIP Redirect Server
SIP phone-to-SIP/H.323 Gateway—Call via SIP Proxy Server with Record-Route disabled (Call failed with a 503 Service Unavailable response)
Cisco SIP Proxy Server (CSPS) Call Flows
This appendix describes the types of SIP methods used by the CSPS and the flow of these messages. This appendix contains the following sections:
•
SIP Messages and Methods
•Call Flow Scenarios for Successful Calls
•Call Flow Scenarios for Failed Calls
SIP Messages and Methods
All SIP messages are either requests from a server or client or responses to a request. The messages are formatted according to RFC 822, "Standard for the format of ARPA internet text messages." For all messages, the general format is:
•A start line
•One or more header fields
•An empty line
•A message body (optional)
Each line must end with a carriage return-line feed (CRLF).
Requests
SIP uses six types (methods) of requests:
•INVITE—Indicates a user or service is being invited to participate in a call session.
•ACK—Confirms that the client has received a final response to an INVITE request.
•BYE—Terminates a call and can be sent by either the caller or the callee.
•CANCEL—Cancels any pending searches but does not terminate a call that has already been accepted.
•OPTIONS—Queries the capabilities of servers.
•REGISTER—Registers the address listed in the To header field with a SIP server.
Responses
The following types of responses are used by SIP and generated by the CSPS:
•SIP 1xx—Informational Responses
•SIP 2xx—Successful Responses
•SIP 3xx—Redirection Responses
•SIP 4xx—Client Failure Responses
•SIP 5xx—Server Failure Responses
•SIP 6xx—Global Failure Responses
The Registration Process
A registration occurs when a client needs to inform a proxy or redirect server of its location. During this process, the client sends a REGISTER request to the proxy or redirect server and includes the address (or addresses) at which it can be reached.
The Invitation Process
An invitation occurs when one SIP end point (user A) "invites" another SIP endpoint (user B) to join in a call. During this process, user A sends an INVITE message requesting that user B join a particular conference or establish a two-party conversation. If user B wants to join the call, it sends an affirmative response (SIP 2xx). Otherwise, it sends a failure response (SIP 4xx). Upon receiving the response, user A acknowledges the response with an ACK message. If user A no longer wants to establish this conference, it sends a BYE message instead of an ACK message.
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 via SIP Redirect Server
•SIP Gateway-to-SIP Gateway—Call via SIP Proxy Server
•SIP IP Phone-to-SIP IP Phone Call Forward Unconditionally
•SIP IP Phone-to-SIP IP Phone Call Forward on Busy
•SIP IP Phone-to-SIP IP Phone Call Forward No Answer
•SIP IP Phone-to-SIP IP Phone Call Forward Unavailable
Note The messages are provided as examples for reference only.
SIP Gateway-to-SIP Gateway—Call via SIP Redirect Server
Figure B-1 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.
The call flow scenario is as follows:
1. User A calls User B via SIP gateway 1 using a SIP redirect server.
2. User B answers the call.
3. User B hangs up.
Figure B-1 SIP Gateway-to-SIP Gateway—Call via SIP Redirect Server
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 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 was received by SIP gateway 2, but that User B is not yet 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 ring back 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 B-2 and Figure B-3 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 B-2, the record route feature is enabled on the proxy server. In the scenario illustrated by Figure B-3, 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.
The call flow is as follows:
1. User A calls User B via SIP gateway 1 using a proxy server.
2. User B answers the call.
3. User B hangs up.
Figure B-2 SIP Gateway-to-SIP Gateway—Call via SIP Proxy Server with Record Route Enabled
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 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 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.
|
Figure B-3 SIP Gateway-to-SIP Gateway—Call via a Proxy Server with Record Route Disabled
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 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 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 IP Phone-to-SIP IP Phone Call Forward Unconditionally
Figure B-4 and Figure B-5 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 end points 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 B-4 illustrates the call as processed by a recursive proxy and Figure B-5 illustrates the call as processed by a non-recursive proxy.
Figure B-4 SIP IP Phone-to-SIP IP Phone Call Forward Unconditionally Call Setup via 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 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.
|
Figure B-5 SIP IP Phone-to-SIP IP Phone Call Forward Unconditionally via 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 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 an 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 B-6 and Figure B-7 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 B-6 illustrates the call as processed by a recursive proxy and Figure B-7 illustrates the call as processed by a non-recursive proxy.
Figure B-6 SIP IP Phone-to-SIP IP Phone Call Forward on Busy Call Setup via 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 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
|
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.
|
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
|
180 Ringing—SIP proxy server to SIP IP phone A
|
The SIP proxy server forwards the 180 Ringing response to SIP IP phone A.
|
7
|
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.
|
8
|
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).
|
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.
|
Figure B-7 SIP IP Phone-to-SIP IP Phone Call Forward on Busy Call Setup via 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 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
|
302 Moved Temporarily—SIP proxy server to SIP IP phone A
|
The SIP proxy server sends an 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 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 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 No Answer
Figure B-8 and Figure B-9 illustrate a successful SIP IP phone-to-SIP IP phone call forward when 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 an response timeout occurs. Figure B-8 illustrates the call as processed by a recursive proxy and Figure B-9 illustrates the call as processed by a non-recursive proxy.
Figure B-8 SIP IP Phone-to-SIP IP Phone Call Forward No Answer Call Setup via 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 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.
|
Figure B-9 SIP IP Phone-to-SIP IP Phone Call Forward No Answer Setup via 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 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.
|
Timeout to INVITE request occurs.
|
4
|
302 Moved Temporarily—SIP proxy server to SIP IP phone A
|
The SIP proxy server sends an 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 B-10 and Figure B-11 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 B-10 illustrates the call as processed by a recursive proxy and Figure B-11 illustrates the call as processed by a non-recursive proxy.
Figure B-10 SIP IP Phone-to-SIP IP Phone Call Forward Unavailable Call Setup via 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 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.
|
Figure B-11 SIP IP Phone-to-SIP IP Phone Call Forward Unavailable Call Setup via 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 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.
|
Call forward unavailable timer expires.
|
6
|
302 Moved Temporarily—SIP proxy server to SIP IP phone A
|
The SIP proxy server sends an 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 via SIP Redirect Server—Called User is Busy
•SIP Gateway-to-SIP Gateway via SIP Redirect Server—Called User Does Not Answer
•SIP Gateway-to-SIP Gateway via SIP Redirect Server—Client, Server, or Global Error
•SIP Gateway-to-SIP Gateway via SIP Proxy Server—Called User is Busy
•SIP Gateway-to-SIP Gateway via SIP Proxy Server—Client or Server Error
•SIP Gateway-to-SIP Gateway via SIP Proxy Server—Global Error
•SIP phone-to-SIP/H.323 Gateway—Call via SIP Proxy Server with Record-Route disabled
•SIP phone-to-SIP/H.323 Gateway—Call via SIP Proxy Server with Record-Route enabled
•SIP Phone to SIP/H.323 Gateway—Call via SIP Redirect Server
•SIP phone-to-SIP/H.323 Gateway—Call via SIP Proxy Server with Record-Route disabled (Call failed with a 503 Service Unavailable response)
Note The messages are provided as examples for reference only.
SIP Gateway-to-SIP Gateway via SIP Redirect Server—Called User is Busy
Figure B-12 illustrates an unsuccessful call in which User A initiates a call to User B but User B is on the phone and is unable or unwilling to accept another call.
Figure B-12 SIP Gateway-to-SIP Gateway Call via a SIP Redirect Server—Called User is Busy
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 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 B-13 illustrates an unsuccessful call in which User A initiates a call to User B but User B does not answer.
Figure B-13 SIP Gateway-to-SIP Gateway Call via a SIP Redirect Server—Called User is 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 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 B-14 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.
Figure B-14 SIP Gateway-to-SIP Gateway Call via a SIP Redirect Server—Client, Server, or Global
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 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 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. The call actions differ, based on the class of failure response.
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 B-15 illustrates an unsuccessful call in which User A initiates a call to User B but User B is on the phone and is unwilling or unable to accept another call.
Figure B-15 SIP Gateway-to-SIP Gateway Call via a SIP Proxy Server—Called User is Busy
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 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 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 B-16 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.
Figure B-16 SIP Gateway-to-SIP Gateway Call via a SIP Proxy Server—Client or Server Error
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 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 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 B-17 illustrates an unsuccessful call in which User A initiates a call to User B and receives a class 6xx response.
Figure B-17 SIP Gateway-to-SIP Gateway Call via a SIP Proxy Server—Global Error 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 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 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 phone-to-SIP/H.323 Gateway—Call via SIP Proxy Server with Record-Route disabled
Figure B-18 Call Via SIP Proxy Server with Record-Route disabled
Step
|
Action
|
Description
|
1
|
INVITE-SIP phone to SIP proxy server
|
SIP UAC sends an INVITE request to the SIP proxy server.
INVITE sip:20002@proxy.cisco.com;user=phone;phone-context=000000 SIP/2.0
Via: SIP/2.0/UDP 161.44.3.207:49489
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:20002@company.com;user=phone;phone-context=000000>
Date: Thu, 18 Mar 2000 04:48:28 UTC
Call-ID: 23-99990146-0-5894369F@161.44.3.207
Cisco-Guid: 428806444-2576941380-0-1486104925
User-Agent: Cisco IP Phone
CSeq:1 INVITE
Max-Forwards: 6
|
| |
|
Timestamp: 732430108
Contact: <sip:+19195550001@bounty.cisco.com:49489;user=phone>
Expires: 5
Content-Type: application/sdp
v=0
o=CiscoSystemsSIP- UserAgent 8870 5284 IN IP4 172.18.193.101
s=SIP Call
t=0 0
c=IN IP4 172.18.193.101
m=audio 20354 RTP/AVP 0 3
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
In the INVITE request:
|
| |
|
The phone number of called party is inserted in the Request-URI field in the form of a SIP URL. The SIP URL identifies the address of the called party 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 the called party appears as "INVITE sip:20002@proxy.cisco.com; user=phone". The "user=phone" parameter distinguishes 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 the calling party is ready to receive is specified.
|
| |
INVITE-SIP phone to SIP proxy server
|
SIP UAC sends an INVITE request to the SIP proxy server.
INVITE sip:20002@proxy.cisco.com;user=phone;phone-context=000000 SIP/2.0
Via: SIP/2.0/UDP 161.44.3.207:49489
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:20002@company.com;user=phone;phone-context=000000>
Date: Thu, 18 Mar 2000 04:48:28 UTC
Call-ID: 23-99990146-0-5894369F@161.44.3.207
Cisco-Guid: 428806444-2576941380-0-1486104925
User-Agent: Cisco IP Phone
CSeq:1 INVITE
Max-Forwards: 6
|
2
|
100-Trying SIP Proxy sends to UAC
|
SIP proxy server sends 100-Trying response message to the upstream UAC upon receiving the INVITE in step ++SIP/2.0 100 TryingVia: SIP/2.0/UDP 161.44.3.207:49489Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>To: <sip:20002@company.com;user=phone;phone-context=000000>CSeq: 1 INVITEContent-Length: 0
|
3
|
RAS LRQ - SIP Proxy sends a RAS LRQ message to a DGK
|
The SIP proxy server expands the "20002" number into "19193920002" number but found no static route to route the request. It then invoke the new routing module, creates a LRQ RAS message from the incoming INVITE SIP message. The LRQ message is sent to one of the DGK configured in the sipd.conf file.
The SIP proxy server adds a technology prefix "001#" in front of the expanded number and use it to fill the "destinationInfo" field of the LRQ RAS message. The (decoded) RAS LRQ looks like the following example:
value RasMessage ::= locationRequest :
|
| |
|
{
requestSeqNum 2519
destinationInfo
{
e164 : "001#19193920002"
}
nonStandardData
{
nonStandardIdentifier h221NonStandard :
{
t35CountryCode 181
t35Extension 0
manufacturerCode 18
}
|
| |
|
data '8284901100ECAA98A025220008000000000E1963...'H
}
replyAddress ipAddress :
{
ip 'AC12C247'H
port 1719
}
sourceInfo
{
h323-ID : {"genuity-sip1"}
}
canMapAlias TRUE
}
|
4
|
RAS RIP - H.323 DGK sends back a RIP to the SIP proxy server
|
Upon receiving the RAS LRQ message from the SIP proxy server, the H.323 DGK can send back a RIP with delay timer value. SIP server should adjust timer accordingly.
value RasMessage ::= requestInProgress :
{
requestSeqNum 2519
delay 9000
}
|
5
|
RAS LCF - H.323 DGK sends back a LCF to the SIP proxy server
|
{
requestSeqNum 2519
callSignalAddress ipAddress :
{
ip 'AC12C250'H
port 1720
}
rasAddress ipAddress :
{
ip 'AC12C250'H
port 56812
}
nonStandardData
{
nonStandardIdentifier h221NonStandard :
{
t35CountryCode 181
t35Extension 0
|
| |
|
manufacturerCode 18
}
data '0002400900630033003600320030002D0032002D...'H
}
destinationType
{
gateway
{
protocol
{
voice :
{
supportedPrefixes
{
}
}
}
}
|
| |
|
mc FALSE
undefinedNode FALSE
}
}
value LCFnonStandardInfo ::=
{
termAlias
{
h323-ID : {"c3620-2-gw"},
e164 : "001#19193920002"
}
gkID {"c3620-1-gk"}
gateways
{
{
gwType voip : NULL
gwAlias
{
|
| |
|
h323-ID : {"c3620-2-gw"},
e164 : "001#19193920002"
}
sigAddress
{
ip 'AC12C250'H
port 1720
}
resources
{
maxDSPs 0
inUseDSPs 0
maxBChannels 0
inUseBChannels 0
activeCalls 0
bandwidth 0
inuseBandwidth 0
}
}
}
}
|
6
|
SIP INVITE - SIP proxy server forwards the INVITE to the gateway
|
The SIP proxy server receives the RAS LCF message, decode it and obtain the gateway transport address (172.18.194.80) value from the "callSignalAddress ipAddress:" field of the LCF message. It then adds the SIP port number (5060) and forwards the INVITE to the gateway. Since the "001#" tech-prefix flag is turned "On" in the sipd.conf file, the "001#" string will not be stripped from the request-uri.
The forwarded SIP INVITE message can be similar to the following:
INVITE sip:001#19193920002@172.18.194.80:5060; user=phone;phone-context=000000 SIP/2.0
Via: SIP/2.0/UDP proxy.cisco.com:48754; branch=1
Via: SIP/2.0/UDP 161.44.3.207:49489
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:20002@company.com;user=phone;phone-context=000000>
Date: Thu, 18 Mar 2000 04:48:28 UTC
Call-ID: 23-99990146-0-5894369F@161.44.3.207
Cisco-Guid: 428806444-2576941380-0-1486104925
User-Agent: Cisco IP PhoneCSeq:1
INVITEMax-Forwards: 6
Timestamp: 732430108
Contact: <sip:+19195550001@bounty.cisco.com:49489;user=phone>
Expires: 5
Content-Type: application/sdp
v=0
o=CiscoSystemsSIP- UserAgent 8870 5284 IN IP4 172.18.193.101
s=SIP Callt=0 0
c=IN IP4 172.18.193.101
m=audio 20354 RTP/AVP 0 3
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
|
7
|
SIP 180 Ringing - Gateway sends 180 Ringing back to the SIP proxy server
|
The SIP/H.323 gateway receives the forwarded SIP INVITE message from the SIP proxy server and sends it downstream. Assume the call signal reaches the end-point and a SIP 180 Ringing is sent from the gateway up to the SIP proxy server.
The SIP 180-Ringing message can be similar to the following:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP proxy.cisco.com:48754; branch=1
Via: SIP/2.0/UDP 161.44.3.207:49489
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:20002@company.com;user=phone;phone-context=000000>
CSeq: 1 INVITE
Content-Length: 0
|
8
|
SIP 180 Ringing - SIP proxy server forwards to the UAC
|
The SIP proxy server receives the 180 Ringing from the gateway, it found the record in TCB and forwards the 180 Ringing upstream to the UAC.
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 161.44.3.207:49489
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:20002@company.com;user=phone;phone-context=000000>
CSeq: 1 INVITE
Content-Length: 0
|
9
|
SIP 200 OK - Gateway sends 200 OK to upstream SIP proxy server
|
The called party picks up the phone ... The gateway sends a 200 OK to the SIP proxy server.
The SIP 200 OK message can be similar to the following:
SIP/2.0 200 OK
Via: SIP/2.0/UDP proxy.cisco.com:48754; branch=1
Via: SIP/2.0/UDP 161.44.3.207:49489
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:20002@company.com;user=phone;phone-context=000000>
Contact: <sip:001#19195550002@172.18.194.80>
CSeq: 1 INVITE
Content-Length: 0
v=0
o=CiscoSystemsSIP- Gateway 537556 235334 IN IP4 172.18.194.80
s=SIP Call
t=0 0
c=IN IP4 gateway.cisco.com
m=audio 5004 RTP/AVP 0 3
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
|
10
|
SIP 200 OK - The SIP proxy server forward the 200 OK to the calling UAC
|
The SIP proxy server receives the 200 OK from the gateway. It forwards it upstream to the calling UAC.
SIP/2.0 200 OK
Via: SIP/2.0/UDP 161.44.3.207:49489
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:20002@company.com;user=phone;phone-context=000000>
Contact: <sip:001#19195550002@172.18.194.80>
CSeq: 1 INVITE
Content-Length: 0
v=0
o=CiscoSystemsSIP- Gateway 537556 235334 IN IP4 172.18.194.80
s=SIP Call
t=0 0
c=IN IP4 gateway.cisco.com
m=audio 5004 RTP/AVP 0 3
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
|
11
|
SIP ACK - The calling UAC sends ACK directly to the gateway
|
Upon receiving the 200 OK message, the UAC opens the media port and responds with ACK directly to the gateway.
SIP/2.0 ACK
Via: SIP/2.0/UDP 161.44.3.207:49489
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:20002@company.com;user=phone;phone-context=000000>
CSeq: 1 ACK
|
12
|
SIP BYE - The gateway sends BYE to the calling UAC
|
The callee hang up the phone ... the gateway sends a BYE to the calling UAC.
SIP/2.0 BYE
Via: SIP/2.0/UDP 172.18.194.80:43576
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:20002@company.com;user=phone;phone-context=000000>
CSeq: 1 BYE
|
13
|
SIP 200 OK - The calling UAC sends back a 200 OK to the gateway
|
The calling UAC receives the BYE from the gateway, it sends back a 200 OK.
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.18.194.80:43576
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:20002@company.com;user=phone;phone-context=000000>
CSeq: 1 BYE
|
SIP phone-to-SIP/H.323 Gateway—Call via SIP Proxy Server with Record-Route enabled
Figure B-19 Call Via SIP Proxy Server with Record-Route enabled
Steps
|
Action
|
Description
|
1
|
INVITE-SIP phone to SIP proxy server
|
SIP UAC sends an INVITE request to the SIP proxy server.
INVITE sip:20002@proxy.cisco.com;user=phone;phone-context=000000 SIP/2.0
Via: SIP/2.0/UDP 161.44.3.207:49489
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:20002@company.com;user=phone;phone-context=000000>
Date: Thu, 18 Mar 2000 04:48:28 UTC
Call-ID: 23-99990146-0-5894369F@161.44.3.207
Cisco-Guid: 428806444-2576941380-0-1486104925
User-Agent: Cisco IP Phone
CSeq:1 INVITE
Max-Forwards: 6
Timestamp: 732430108
Contact: <sip:+19195550001@bounty.cisco.com:49489;user=phone>
Expires: 5
Content-Type: application/sdp
v=0
o=CiscoSystemsSIP- UserAgent 8870 5284 IN IP4 172.18.193.101
s=SIP Call
t=0 0
c=IN IP4 172.18.193.101
m=audio 20354 RTP/AVP 0 3
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
In the INVITE request:
•The phone number of called party is inserted in the Request-URI field in the form of a SIP URL. The SIP URL identifies the address of the called party 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 the called party appears as "INVITE sip:20002@proxy.cisco.com; user=phone" The "user=phone" parameter distinguishes 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 the calling party is ready to receive is specified.
|
2
|
100-Trying SIP Proxy sends to UAC
|
SIP proxy server sends 100-Trying response message to the upstream UAC upon receiving the INVITE in step 1.
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 161.44.3.207:49489
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "255-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:20002@company.com;user=phone;phone-context=000000>
CSeq: 1 INVITE
Content-Length: 0
|
3
|
RAS LRQ - SIP Proxy sends a RAS LRQ message to a DGK
|
The SIP proxy server expands the "20002" number into "9193920002" number but found no static route to route the request. It then invoke the new routing module, creates a LRQ RAS message from the incoming INVITE SIP message. The LRQ message is sent to one of the DGK configured in the sipd.conf file.
The SIP proxy server adds a technology prefix "001#" in front of the expanded number and use it to fill the "destinationInfo" field of the LRQ RAS message. The (decoded) RAS LRQ looks like the following example:
value RasMessage ::= locationRequest :
{
requestSeqNum 2519
destinationInfo
{
e164 : "001#19193920002"
}
nonStandardData
{
nonStandardIdentifier h221NonStandard :
{
t35CountryCode 181
t35Extension 0
manufacturerCode 18
}
data '8284901100ECAA98A025220008000000000E1963...'H
}
replyAddress ipAddress :
{
ip 'AC12C247'H
port 1719
}
sourceInfo
{
h323-ID : {"genuity-sip1"}
}
canMapAlias TRUE
}
|
4
|
RAS RIP - H.323 DGK sends back a RIP to the SIP proxy server
|
Upon receiving the RAS LRQ message from the SIP proxy server, the H.323 DGK can send back a RIP with delay timer value. SIP server should adjust timer accordingly.
value RasMessage ::= requestInProgress :
{
requestSeqNum 2519
delay 9000
}
|
5
|
RAS LCF - H.323 DGK sends back a LCF to the SIP proxy server
|
The H.323 DGK forwards the request to H.323 network and finds a SIP/H.323 gateway that can handle this particular call. It then sends back to the SIP proxy server a RAS LCF message.
value RasMessage ::= locationConfirm :
{
requestSeqNum 2519
callSignalAddress ipAddress :
{
ip 'AC12C250'H
port 1720
}
rasAddress ipAddress :
{
ip 'AC12C250'H
port 56812
}
nonStandardData
{
nonStandardIdentifier h221NonStandard :
{
t35CountryCode 181
t35Extension 0
manufacturerCode 18
}
data '0002400900630033003600320030002D0032002D...'H
}
destinationType
{
gateway
{
protocol
{
voice :
{
|
| |
|
supportedPrefixes
{
}
}
}
}
mc FALSE
undefinedNode FALSE
}
}
value LCFnonStandardInfo ::=
{
termAlias
{
h323-ID : {"c3620-2-gw"},
e164 : "001#19193920002"
}
gkID {"c3620-1-gk"}
gateways
{
{
gwType voip : NULL
gwAlias
{
h323-ID : {"c3620-2-gw"},
e164 : "001#19193920002"
}
sigAddress
{
ip 'AC12C250'H
port 1720
}
resources
|
| |
|
{
maxDSPs 0
inUseDSPs 0
maxBChannels 0
inUseBChannels 0
activeCalls 0
bandwidth 0
inuseBandwidth 0
}
}
}
}
|
6
|
SIP INVITE - SIP proxy server forwards the INVITE to the gateway
|
To: <sip:20002@company.com;user=phone;phone-context=000000>
Date: Thu, 18 Mar 2000 04:48:28 UTC
Call-ID: 23-99990146-0-5894369F@161.44.3.207
Cisco-Guid: 428806444-2576941380-0-1486104925
User-Agent: Cisco IP Phone
CSeq:1 INVITE
Max-Forwards: 6
Timestamp: 732430108
Contact: <sip:+19193920001@bounty.cisco.com:49489;user=phone>
Expires: 5
Content-Type: application/sdp
v=0
o=CiscoSystemsSIP- UserAgent 8870 5284 IN IP4 172.18.193.101
s=SIP Call
t=0 0
c=IN IP4 172.18.193.101
m=audio 20354 RTP/AVP 0 3
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
|
7
|
SIP 180 Ringing - Gateway sends 180 Ringing back to the SIP proxy server
|
The SIP/H.323 gateway receives the forwarded SIP INVITE message from the SIP proxy server and sends it downstream. Assume the call signal reaches the end-point and a SIP 180 Ringing is sent from the gateway up to the SIP proxy server.
The SIP 180-Ringing message can be similar to the following:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP proxy.cisco.com:48754; branch=1
Via: SIP/2.0/UDP 161.44.3.207:49489
Record-Route: < sip:001#9195550002@proxy.cisco.com; maddr=proxy.cisco.com>
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:20002@company.com;user=phone;phone-context=000000>
CSeq: 1 INVITE
Content-Length: 0
|
8
|
SIP 180 Ringing - SIP proxy server forwards to the UAC
|
The SIP proxy server receives the 180 Ringing from the gateway, it found the record in TCB and forwards the 180 Ringing upstream to the UAC.
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 161.44.3.207:49489
Record-Route: < sip:001#9193920002@proxy.cisco.com; maddr=proxy.cisco.com>
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:20002@company.com;user=phone;phone-context=000000>
CSeq: 1 INVITE
Content-Length: 0
|
9
|
SIP 200 OK - Gateway sends 200 OK to upstream SIP proxy server
|
The called party picks up the phone ... The gateway sends a 200 OK to the SIP proxy server.
The SIP 200 OK message can be similar to the following:
SIP/2.0 200 OK
Via: SIP/2.0/UDP proxy.cisco.com:48754; branch=1
Via: SIP/2.0/UDP 161.44.3.207:49489
Record-Route: < sip:001#9193920002@proxy.cisco.com; maddr=proxy.cisco.com>
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:20002@company.com;user=phone;phone-context=000000>
CSeq: 1 INVITE
Contact: <sip:001#19193920002@172.18.194.80>
Content-Length: 0
v=0
o=CiscoSystemsSIP- Gateway 537556 235334 IN IP4 172.18.194.80
s=SIP Call
t=0 0
c=IN IP4 gateway.cisco.com
m=audio 5004 RTP/AVP 0 3
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
|
10
|
SIP 200 OK - The SIP proxy server forward the 200 OK to the calling UAC
|
The SIP proxy server receives the 200 OK from the gateway. It forwards it upstream to the calling UAC.
SIP/2.0 200 OK
Via: SIP/2.0/UDP 161.44.3.207:49489
Record-Route: < sip:001#19193920002@proxy.cisco.com; maddr=proxy.cisco.com>
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:20002@company.com;user=phone;phone-context=000000>
CSeq: 1 INVITE
Contact: <sip:001#19193920002@172.18.194.80>
Content-Length: 0
v=0
o=CiscoSystemsSIP- Gateway 537556 235334 IN IP4 172.18.194.80
s=SIP Call
t=0 0
c=IN IP4 gateway.cisco.com
m=audio 5004 RTP/AVP 0 3
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
|
11
|
SIP ACK - The calling UAC sends ACK to the SIP proxy
|
Upon receiving the 200 OK message, the caller UAC opens the media port and responds with an ACK to the SIP proxy.
SIP/2.0 ACK
Via: SIP/2.0/UDP 161.44.3.207:49489
Route: <sip:001#19193920002@172.18.194.80>
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:20002@company.com;user=phone;phone-context=000000>
CSeq: 1 ACK
|
12
|
SIP ACK - The SIP proxy forwards an ACK to the gateway
|
Upon receiving the SIP ACK message, the SIP proxy server forwards the ACK to the downstream gateway.
SIP/2.0 ACK
Via: SIP/2.0/UDP 172.18.194.80:48987
Via: SIP/2.0/UDP 161.44.3.207:49489
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:20002@company.com;user=phone;phone-context=000000>
CSeq: 1 ACK
|
13
|
SIP BYE - The gateway sends BYE to the SIP proxy
|
The callee hang up the phone ... the gateway sends a BYE to the SIP proxy.
SIP/2.0 BYE sip: +19195550001@bounty.cisco.com
Via: SIP/2.0/UDP 172.18.194.80:5060
Route: < sip: +19195550001@ bounty.cisco.com >
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: <sip:+19193920002@company.com;user=phone>
To: "555-0001" <sip:+19195550001@bounty.cisco.com>
CSeq: 1 BYE
|
14
|
SIP BYE - The SIP proxy forwards they BYE to the calling party
|
The SIP proxy server receives the BYE from the gateway, it forwards it upstream to the calling user agent.
SIP/2.0 BYE sip: +19195550001@ bounty.cisco.com:5060
Via: SIP/2.0/UDP 172.18.194.80:5060
Via: SIP/2.0/UDP 172.18.194.80:43576
Record-Route: <sip: +19195550001@proxy.cisco.com>
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: <sip:+19193920002@company.com;user=phone>
To: "555-0001" <sip:+19195550001@bounty.cisco.com>
CSeq: 1 BYE
|
15
|
SIP 200 OK - The calling UAC sends back a 200 OK to the SIP proxy
|
The calling UAC receives the BYE from the gateway, it sends back a 200 OK to the SIP proxy.
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.18.194.80:43576
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: <sip:+19193920002@company.com;user=phone>
To: "555-0001" <sip:+19195550001@bounty.cisco.com>
CSeq: 1 BYE
|
16
|
SIP 200 OK - The SIP proxy forwards the 200 OK to the gateway
|
The SIP proxy receives the 200 OK from the calling UAC, it forwards it to the gateway.
SIP/2.0 200 OK
Via: SIP/2.0/UDP proxy.cisco.com:5060
Via: SIP/2.0/UDP 172.18.194.80:43576
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: <sip:+19193920002@company.com;user=phone>
To: "555-0001" <sip:+19195550001@bounty.cisco.com>
CSeq: 1 BYE
|
SIP Phone to SIP/H.323 Gateway—Call via SIP Redirect Server
Figure B-20 Call via SIP Redirect Server
Steps
|
Action
|
Description
|
1
|
INVITE-SIP phone to SIP redirect server
|
SIP UAC sends an INVITE request to the SIP redirect server.
INVITE sip:50002@redirect.cisco.com;user=phone;phone-context=000000 SIP/2.0
Via: SIP/2.0/UDP 161.44.3.207:49489
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:50002@company.com;user=phone;phone-context=000000>
Date: Thu, 18 Mar 2000 04:48:28 UTC
Call-ID: 23-99990146-0-5894369F@161.44.3.207
Cisco-Guid: 428806444-2576941380-0-1486104925
User-Agent: Cisco IP Phone
CSeq:1 INVITE
Max-Forwards: 6
Timestamp: 732430108
Contact: <sip:+19195550001@bounty.cisco.com:49489;user=phone>
Expires: 5
Content-Type: application/sdp
v=0
o=CiscoSystemsSIP- UserAgent 8870 5284 IN IP4 172.18.193.101
s=SIP Call
t=0 0
c=IN IP4 172.18.193.101
m=audio 20354 RTP/AVP 0 3
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
In the INVITE request:
•The phone number of called party is inserted in the Request-URI field in the form of a SIP URL. The SIP URL identifies the address of the called party 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 the called party appears as "INVITE sip:50002@redirect.cisco.com; user=phone" The "user=phone" parameter distinguishes 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 the calling party is ready to receive is specified.
|
2
|
100-Trying SIP redirect server sends back 100 Trying to UAC
|
SIP redirect server sends 100-Trying response message to the upstream UAC upon receiving the INVITE in step 1.
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 161.44.3.207:49489
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:50002@company.com;user=phone;phone-context=000000>
CSeq: 1 INVITE
Content-Length: 0
|
3
|
RAS LRQ - SIP redirect server sends a RAS LRQ message to a DGK
|
The SIP redirect server expands the "50002" number into "9193650002" number but found no static route. It then invoke the new routing module, creates a LRQ RAS message from the incoming INVITE SIP message. The LRQ message is sent to one of the DGK configured in the sipd.conf file.
The SIP redirect server adds a technology prefix "002#" in front of the expanded number and use it to fill the "destinationInfo" field of the LRQ RAS message. The (decoded) RAS LRQ looks like the following example:
value RasMessage ::= locationRequest :
{
requestSeqNum 2519
destinationInfo
{
e164 : "002#19193650002"
}
nonStandardData
{
nonStandardIdentifier h221NonStandard :
{
t35CountryCode 181
t35Extension 0
manufacturerCode 18
}
data '8284901100ECAA98A025220008000000000E1963...'H
}
replyAddress ipAddress :
{
ip 'AC12C247'H
port 1719
}
sourceInfo
{
h323-ID : {"genuity-sip1"}
}
canMapAlias TRUE
}
|
4
|
RAS RIP - H.323 DGK sends back a RIP to the SIP redirect server
|
Upon receiving the RAS LRQ message from the SIP redirect server, the H.323 DGK can send back a RIP with delay timer value. SIP server should adjust timer accordingly.
value RasMessage ::= requestInProgress :
{
requestSeqNum 2519
delay 9000
}
|
5
|
RAS LCF - H.323 DGK sends back a LCF to the SIP redirect server
|
The H.323 DGK forwards the request to H.323 network and finds a SIP/H.323 gateway that can handle this particular call. It then sends back to the SIP redirect server a RAS LCF message.
value RasMessage ::= locationConfirm :
{
requestSeqNum 2519
callSignalAddress ipAddress :
{
ip 'AC12C250'H
port 1720
}
rasAddress ipAddress :
{
ip 'AC12C250'H
port 56812
}
nonStandardData
{
nonStandardIdentifier h221NonStandard :
{
t35CountryCode 181
t35Extension 0
manufacturerCode 18
}
data '0002400900630033003600320030002D0032002D...'H
}
destinationType
{
gateway
{
protocol
{
voice :
{
supportedPrefixes
{
}
|
| |
|
}
}
}
mc FALSE
undefinedNode FALSE
}
}
value LCFnonStandardInfo ::=
{
termAlias
{
h323-ID : {"c3620-2-gw"},
e164 : "4056701000"
}
gkID {"c3620-1-gk"}
gateways
{
{
gwType voip : NULL
gwAlias
{
h323-ID : {"c3620-2-gw"},
e164 : "002#19193650002"
}
sigAddress
{
ip 'AC12C250'H
port 1720
}
|
| |
|
resources
{
maxDSPs 0
inUseDSPs 0
maxBChannels 0
inUseBChannels 0
activeCalls 0
bandwidth 0
inuseBandwidth 0
}
}
}
}
|
6
|
SIP 302 Moved Temporarily - SIP redirect server sends a 302 Moved Temporarily to the UAC
|
The SIP redirect server receives the RAS LCF message, decode it and obtain the gateway transport address (172.18.194.80) value from the "callSignalAddress ipAddress" field of the LCF message. It then add the SIP port number (5060) and return the 302 Moved Temporarily message back to the UAC. Since the "002#" tech-prefix flag is turned "Off" in the sipd.conf file, the "002#" string will be stripped from the contact header.
The returned SIP 302 Moved Temporarily message can be similar to the following example:
SIP/2.0 302 MovedTemporarily
Via: SIP/2.0/UDP 161.44.3.207:49489
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:50002@company.com;user=phone;phone-context=000000>
CSeq: 1 INVITE
Contact: <sip:19193650002@172.18.194.80:5060>
Content-Length: 0
|
7
|
SIP ACK - UAC sends back a SIP ACK to the redirect server
|
Upon receiving of the 302 response message, the UAC sends back a SIP ACK to the redirect server.
SIP/2.0 ACK
Via: SIP/2.0/UDP 161.44.3.207:49489
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:50002@company.com;user=phone;phone-context=000000>
CSeq: 1 ACK
|
8
|
SIP INVITE - UAC sends directly to the gateway
|
The UAC sends a new INVITE directly to the gateway.
The SIP INVITE message can be similar to the following example.
INVITE sip:19193650002@172.18.194.80:5060; user=phone;phone-context=000000 SIP/2.0
Via: SIP/2.0/UDP 161.44.3.207:49489
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:50002@company.com;user=phone;phone-context=000000>
Date: Thu, 18 Mar 2000 04:48:28 UTC
Call-ID: 23-99990146-0-5894369F@161.44.3.207
Cisco-Guid: 428806444-2576941380-0-1486104925
User-Agent: Cisco IP Phone
CSeq: 2 INVITE
Max-Forwards: 6
Timestamp: 732430108
Contact: <sip:+19195550001@bounty.cisco.com:49489;user=phone>
Expires: 5
Content-Type: application/sdp
v=0
o=CiscoSystemsSIP- UserAgent 8870 5284 IN IP4 172.18.193.101
s=SIP Call
t=0 0
c=IN IP4 172.18.193.101
m=audio 20354 RTP/AVP 0 3
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
|
9
|
SIP 180 Ringing - Gateway sends 180 Ringing back to the UAC
|
The SIP/H.323 gateway receives the SIP INVITE message from the UAC and sends it downstream. Assume the call signal reaches the end-point and a SIP 180 Ringing is sent from the gateway to the UAC.
The SIP 180-Ringing message can be similar to the following example:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 161.44.3.207:49489
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:50002@company.com;user=phone;phone-context=000000>
CSeq: 2 INVITE
Content-Length: 0
|
10
|
SIP 200 OK - The gateway sends 200 OK to the calling UAC
|
The called party picks up the phone and the gateway sends 200 OK to the calling UAC.
SIP/2.0 200 OK
Via: SIP/2.0/UDP 161.44.3.207:49489
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:50002@company.com;user=phone;phone-context=000000>
CSeq: 2 INVITE
Content-Length: 0
v=0
o=CiscoSystemsSIP- Gateway 537556 235334 IN IP4 172.18.194.80
s=SIP Call
t=0 0
c=IN IP4 gateway.cisco.com
m=audio 5004 RTP/AVP 0 3
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
|
11
|
SIP ACK - The calling UAC sends ACK to the gateway
|
Upon receiving the 200 OK message, the UAC opens the media port and responds with ACK to the gateway.
SIP/2.0 ACK
Via: SIP/2.0/UDP 161.44.3.207:49489
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:50002@company.com;user=phone;phone-context=000000>
CSeq: 2 ACK
|
12
|
SIP BYE - The gateway sends BYE to the calling UAC
|
User hang up the phone ... the gateway sends a BYE to the calling UAC.
SIP/2.0 BYE sip:+19195550001@bounty.cisco.com
Via: SIP/2.0/UDP 172.18.194.80:43576
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: <sip:+1913650002@company.com;user=phone>
To: "555-0001" <sip:+19195550001@bounty.cisco.com>
CSeq: 1 BYE
|
13
|
SIP 200 OK - The calling UAC sends back a 200 OK to the gateway
|
The calling UAC receives the BYE from the gateway, it sends back a 200 OK.
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.18.194.80:43576
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: <sip:+19193650002@company.com;user=phone>
To: "555-0001" <sip:+19195550001@bounty.cisco.com>
CSeq: 1 BYE
|
SIP phone-to-SIP/H.323 Gateway—Call via SIP Proxy Server with Record-Route disabled (Call failed with a 503 Service Unavailable response)
Figure B-21 Call via SIP Proxy Server with Record-Route disabled (Call failed with a 503 Service Unavailable response)
Steps
|
Action
|
Description
|
1
|
INVITE-SIP phone to SIP proxy server
|
SIP UAC sends an INVITE request to the SIP proxy server.
INVITE sip:50002@proxy.cisco.com;user=phone;phone-context=000000 SIP/2.0
Via: SIP/2.0/UDP 161.44.3.207:49489
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:50002@company.com;user=phone;phone-context=000000>
Date: Thu, 18 Mar 2000 04:48:28 UTC
Call-ID: 23-99990146-0-5894369F@161.44.3.207
Cisco-Guid: 428806444-2576941380-0-1486104925
User-Agent: Cisco IP Phone
CSeq:1 INVITE
Max-Forwards: 6
Timestamp: 732430108
Contact: <sip:+19195550001@bounty.cisco.com:49489;user=phone>
Expires: 5
Content-Type: application/sdp
v=0
o=CiscoSystemsSIP- UserAgent 8870 5284 IN IP4 172.18.193.101
s=SIP Call
t=0 0
c=IN IP4 172.18.193.101
m=audio 20354 RTP/AVP 0 3
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
In the INVITE request:
•The phone number of called party is inserted in the Request-URI field in the form of a SIP URL. The SIP URL identifies the address of the called party 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 the called party appears as "INVITE sip:50002@proxy.cisco.com; user=phone" The "user=phone" parameter distinguishes 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 the calling party is ready to receive is specified.
|
| |
|
|
2
|
100-Trying SIP Proxy sends to UAC
|
SIP proxy server sends 100-Trying response message to the upstream UAC upon receiving the INVITE in step 1.
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 161.44.3.207:49489
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:50002@company.com;user=phone;phone-context=000000>
CSeq: 1 INVITE
Content-Length: 0
|
3
|
RAS LRQ - SIP Proxy sends a RAS LRQ message to a DGK
|
The SIP proxy server expands the "50002" number into "9193650002" number but found no static route to route the request. It then invoke the new routing module, creates a LRQ RAS message from the incoming INVITE SIP message. The LRQ message is sent to one of the DGK configured in the sipd.conf file.
The SIP proxy server adds a technology prefix "002#" in front of the expanded number and use it to fill the "destinationInfo" field of the LRQ RAS message. The (decoded) RAS LRQ looks like the following example:
value RasMessage ::= locationRequest :
{
requestSeqNum 2519
destinationInfo
{
e164 : "002#19193650002"
}
nonStandardData
{
nonStandardIdentifier h221NonStandard :
{
t35CountryCode 181
t35Extension 0
manufacturerCode 18
}
data '8284901100ECAA98A025220008000000000E1963...'H
}
replyAddress ipAddress :
{
ip 'AC12C247'H
port 1719
}
sourceInfo
{
h323-ID : {"genuity-sip1"}
}
canMapAlias TRUE
}
|
4
|
RAS RIP - H.323 DGK sends back a RIP to the SIP proxy server
|
Upon receiving the RAS LRQ message from the SIP proxy server, the H.323 DGK can send back a RIP with delay timer value. SIP server should adjust timer accordingly.
value RasMessage ::= requestInProgress :
{
requestSeqNum 2519
delay 9000
}
|
5
|
RAS LCF - H.323 DGK sends back a LCF to the SIP proxy server
|
The H.323 DGK forwards the request to H.323 network and finds a SIP/H.323 gateway that can handle this particular call. It then sends back to the SIP proxy server a RAS LCF message.
value RasMessage ::= locationConfirm :
{
requestSeqNum 2519
callSignalAddress ipAddress :
{
ip 'AC12C250'H
port 1720
}
rasAddress ipAddress :
{
ip 'AC12C250'H
port 56812
}
nonStandardData
{
nonStandardIdentifier h221NonStandard :
{
t35CountryCode 181
t35Extension 0
manufacturerCode 18
}
data '0002400900630033003600320030002D0032002D...'H
}
destinationType
{
gateway
{
protocol
{
voice :
{
supportedPrefixes
{
|
| |
|
}
}
}
mc FALSE
undefinedNode FALSE
}
}
value LCFnonStandardInfo ::=
{
termAlias
{
h323-ID : {"c3620-2-gw"},
e164 : "002#19193650002"
}
gkID {"c3620-1-gk"}
gateways
{
{
gwType voip : NULL
gwAlias
{
h323-ID : {"c3620-2-gw"},
e164 : "002#19193650002"
}
sigAddress
{
ip 'AC12C250'H
port 1720
}
|
| |
|
resources
{
maxDSPs 0
inUseDSPs 0
maxBChannels 0
inUseBChannels 0
activeCalls 0
bandwidth 0
inuseBandwidth 0
}
}
}
}
|
6
|
SIP INVITE - SIP proxy server forwards the INVITE to the gateway
|
The SIP proxy server receives the RAS LCF message, decode it and obtain the gateway transport address (172.18.194.80) value from the "callSignalAddress ipAddress" field of the LCF message. It then add the SIP port number (5060) and forward the INVITE to the gateway. Since the "002#" tech-prefix flag is turned "Off" in the sipd.conf file, the "002#" string will be stripped from the request-uri.
The forwarded SIP INVITE message can be similar to the following:
INVITE sip: 19193650002@172.18.194.80:5060; user=phone;phone-context=000000 SIP/2.0
Via: SIP/2.0/UDP proxy.cisco.com:48754; branch=1
Via: SIP/2.0/UDP 161.44.3.207:49489
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:50002@company.com;user=phone;phone-context=000000>
Date: Thu, 18 Mar 2000 04:48:28 UTC
Call-ID: 23-99990146-0-5894369F@161.44.3.207
Cisco-Guid: 428806444-2576941380-0-1486104925
User-Agent: Cisco IP Phone
CSeq:1 INVITE
Max-Forwards: 6
Timestamp: 732430108
Contact: <sip:+19195550001@bounty.cisco.com:49489;user=phone>
Expires: 5
Content-Type: application/sdp
v=0
o=CiscoSystemsSIP- UserAgent 8870 5284 IN IP4 172.18.193.101
s=SIP Call
t=0 0
c=IN IP4 172.18.193.101
m=audio 20354 RTP/AVP 0 3
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
|
7
|
SIP 100 Trying - Gateway sends 100 Trying back to the SIP proxy server
|
The SIP/H.323 gateway receives the forwarded SIP INVITE message from the SIP proxy server and sends 100-Trying back to the SIP proxy server.
The SIP 100-Trying message can be similar to the following:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP proxy.cisco.com:48754; branch=1
Via: SIP/2.0/UDP 161.44.3.207:49489
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:50002@company.com;user=phone;phone-context=000000>
CSeq: 1 INVITE
Content-Length: 0
|
8
|
SIP 100-Trying - SIP proxy server forwards to the UAC
|
The SIP proxy server receives the 100-Trying from the gateway, it found the record in TCB and forwards the 100-Trying upstream to the UAC.
SIP/2.0 100-Trying
Via: SIP/2.0/UDP proxy.cisco.com:48754; branch=1
Via: SIP/2.0/UDP 161.44.3.207:49489
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:50002@company.com;user=phone;phone-context=000000>
CSeq: 1 INVITE
Content-Length: 0
|
9
|
SIP 503 Service Unavailable— Gateway sends 503 Service Unavailable to upstream SIP proxy server
|
The gateway overloaded and sends a 503 Service Unavailable to the upstream SIP proxy server.
The SIP 503 Service Unavailable message can be similar to the following:
SIP/2.0 503 Service Unavailable
Via: SIP/2.0/UDP proxy.cisco.com:48754; branch=1
Via: SIP/2.0/UDP 161.44.3.207:49489
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:50002@company.com;user=phone;phone-context=000000>
CSeq: 1 INVITE
Content-Length: 0
|
10
|
SIP 503 Service Unavailable - The SIP proxy server forward the 503 Service Unavailable to the calling UAC
|
The SIP proxy server receives the 503 Service Unavailable from the gateway. It forwards it upstream to the calling UAC.
SIP/2.0 503 Service Unavailable
Via: SIP/2.0/UDP 161.44.3.207:49489
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:50002@company.com;user=phone;phone-context=000000>
CSeq: 1 INVITE
Content-Length: 0
|
11
|
SIP ACK - The calling UAC sends ACK to the SIP proxy server
|
Upon receiving the 503 Service Unavailable message, the UAC responds with ACK to the SIP proxy server.
SIP/2.0 ACK
Via: SIP/2.0/UDP 161.44.3.207:49489
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:50002@company.com;user=phone;phone-context=000000>
CSeq: 1 ACK
|
12
|
SIP ACK - The SIP proxy server sends ACK to the downstream gateway
|
Upon receiving the ACK from UAC, the SIP proxy server forwards the ACK to the downstream gateway.
SIP/2.0 ACK
Via: SIP/2.0/UDP proxy.cisco.com:48754; branch=1
Via: SIP/2.0/UDP 161.44.3.207:49489
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:50002@company.com;user=phone;phone-context=000000>
CSeq: 1 ACK
|
