Table of Contents
Session Initiation Protocol Gateway Call Flows and Compliance Information
This document provides information about the Session Initiation Protocol (SIP) call flows as they are implemented in the Cisco IOS 12.1(3)T software release and used in Cisco Voice over IP (VoIP) gateways. The primary focus of this document is to demonstrate the SIP methods and responses used to set up and tear down calls using Cisco VoIP gateways.
This document contains the following information:
SIP is a new protocol developed by the Internet Engineering Task Force (IETF) Multiparty Multimedia Session Control (MMUSIC) Working Group as an alternative to the ITU-T H.323 specification. SIP is defined by RFC 2543 and is used for multimedia call session setup and control over IP networks.
SIP uses six request methods:
- INVITEIndicates a user or service is being invited to participate in a call session.
- ACKConfirms that the client has received a final response to an INVITE request.
- BYETerminates a call and can be sent by either the caller or the callee.
- CANCELCancels any pending searches but does not terminate a call that has already been accepted.
- OPTIONSQueries the capabilities of servers.
- REGISTERRegisters the address listed in the To header field with a SIP server. Gateways do not support the REGISTER method.
The following types of responses are used by SIP and generated by the Cisco SIP gateway:
- SIP 1xxInformational Responses
- SIP 2xxSuccessful Responses
- SIP 3xxRedirection Responses
- SIP 4xxClient Failure Responses
- SIP 5xxServer Failure Responses
- SIP 6xxGlobal Failure Responses
This section describes call flows for the following scenarios, which illustrate successful calls:
Figure 1 illustrates a successful gateway-to-gateway call setup and disconnect. In this call flow scenario, the two end users are User A and User B. User A is located at PBX A. PBX A is connected to SIP gateway 1 via a T1/E1. User B is located at PBX B. PBX B is connected to SIP gateway 2 via a T1/E1. User B's phone number is 555-0002. SIP gateway 1 is connected to SIP gateway 2 over an IP network.
The call flow scenario is as follows:
1. User A calls User B.
2. User B answers the call.
3. User B hangs up.
Figure 1: SIP Gateway-to-SIP Gateway Call
| Step
| Action
| Description
|
1
| SetupPBX 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
| INVITESIP Gateway 1 to SIP Gateway 2
| SIP gateway 1 sends an INVITE request to SIP gateway 2. The INVITE request is an invitation to User B to participate in a call session.
In the INVITE request:
- The phone number of User B is inserted in the Request-URI field in the form of a SIP URL. The SIP URL identifies the address of User B and takes a form similar to an email address (user@host where user is the telephone number and host is either a domain name or a numeric network address). For example, the Request-URI field in the INVITE request to User B appears as "INVITE sip:555-0002@companyb.com; user=phone." The "user=phone" parameter indicates that the Request-URI address is a telephone number rather than a user name.
- PBX A is identified as the call session initiator in the From field.
- A unique numeric identifier is assigned to the call and is inserted in the Call-ID field.
- The transaction number within a single call leg is identified in the CSeq field.
- The media capability User A is ready to receive is specified.
- The port on which SIP gateway 1 is prepared to receive the RTP data is specified.
|
3
| Call ProceedingSIP Gateway 1 to PBX A
| SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
|
4
| SetupSIP Gateway 2 to PBX B
| SIP gateway 2 receives the INVITE request from SIP gateway 1 and initiates a Call Setup with User B via PBX B.
|
5
| 100 TryingSIP Gateway 2 to SIP Gateway 1
| SIP gateway 2 sends a 100 Trying response to the INVITE request sent by SIP gateway 1. The 100 Trying response indicates that the INVITE request has been received by SIP gateway 2 but that User B has not yet been located and that some unspecified action, such as a database consultation, is taking place.
|
6
| Call ProceedingPBX B to SIP Gateway 2
| PBX B sends a Call Proceeding message to SIP gateway 2 to acknowledge the Call Setup request.
|
7
| AlertingPBX B to SIP Gateway 2
| PBX B locates User B and sends an Alert message to SIP gateway 2. User B's phone begins ringing.
|
8
| 180 RingingSIP Gateway 2 to SIP Gateway 1
| SIP gateway 2 sends a 180 Ringing response to SIP gateway 1. The 180 Ringing response indicates that SIP gateway 2 has located, and is trying to alert, User B.
|
9
| AlertingSIP Gateway 1 to PBX A
| SIP gateway 1 sends an Alert message to User A via PBX A. The Alert message indicates that SIP gateway 1 has received a 180 Ringing response from SIP gateway 2. User A hears the ringback tone that indicates that User B is being alerted.
|
At this point, a one-way voice path is established between SIP gateway 1 and PBX A and between SIP gateway 2 and PBX B. A two-way RTP channel is established between SIP gateway 1 and SIP gateway 2.
|
10
| ConnectPBX B to SIP Gateway 2
| User B answers phone. PBX B sends a Connect message to SIP gateway 2. The Connect message notifies SIP gateway 2 that the connection has been made.
|
11
| 200 OKSIP Gateway 2 to SIP Gateway 1
| SIP gateway 2 sends a 200 OK response to SIP gateway 1. The 200 OK response notifies SIP gateway 1 that the connection has been made.
If User B supports the media capability advertised in the INVITE message sent by SIP gateway 1, it advertises the intersection of its own and User A's media capability in the 200 OK response. If User B does not support the media capability advertised by User A, it sends back a 400 Bad Request response with a 304 Warning header field.
|
12
| ConnectSIP Gateway 1 to PBX A
| SIP gateway 1 sends a Connect message to PBX A. The Connect message notifies PBX A that the connection has been made.
|
13
| Connect ACKPBX A to SIP Gateway 1
| PBX A acknowledges SIP gateway 1's Connect message.
|
14
| ACKSIP Gateway 1 to SIP Gateway 2
| SIP gateway 1 sends a an ACK to SIP gateway 2. The ACK confirms that SIP gateway 1 has received the 200 OK response from SIP gateway 2.
|
15
| Connect ACKSIP Gateway 2 to PBX B
| SIP gateway 2 acknowledges PBX B's Connect message.
The call session is now active over a two-way voice path via Real Time Transport Protocol (RTP).
|
At this point, a two-way voice path is established between SIP gateway 1 and PBX A and between SIP gateway 2 and PBX B. A two-way RTP channel is established between SIP gateway 1 and SIP gateway 2.
|
16
| DisconnectPBX B to SIP Gateway 2
| Once User B hangs up, PBX B sends a Disconnect message to SIP gateway 2. The Disconnect message starts the call session termination process.
|
17
| BYESIP 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.
|
18
| ReleaseSIP Gateway 2 to PBX B
| SIP gateway 2 sends a Release message to PBX B.
|
19
| DisconnectSIP Gateway 1 to PBX A
| SIP gateway 1 sends a Disconnect message to PBX A.
|
20
| ReleasePBX A to SIP Gateway 1
| PBX A sends a Disconnect message to SIP gateway 1.
|
21
| 200 OKSIP Gateway 1 to SIP Gateway 2
| SIP gateway 1 sends a 200 OK response to SIP gateway 2. The 200 OK response notifies SIP gateway 2 that SIP gateway 1 has received the BYE request.
|
22
| Release CompletePBX B to SIP Gateway 2
| PBX B sends a Release Complete message to SIP gateway 2.
|
23
| Release CompleteSIP Gateway 1 to PBX A
| SIP gateway 1 sends a Release Complete message to PBX A and the session is terminated.
|
Figure 2 illustrates a successful gateway-to-gateway call setup and disconnect via a SIP redirect server. In this scenario, the two end users are identified as User A and User B. User A is located at PBX A. PBX A is connected to SIP gateway 1 via a T1/E1. SIP gateway 1 is using a SIP redirect server. User B is located at PBX B. PBX B is connected to SIP gateway 2 via a T1/E1. User B's phone number is 555-0002. SIP gateway 1 is connected to SIP gateway 2 over an IP network.
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 2: SIP Gateway-to-SIP Gateway Call via SIP Redirect Server
Step
| Action
| Description
|
1
| SetupPBX A to SIP Gateway1
| 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 UserB.
|
2
| INVITESIP Gateway 1 to SIP Redirect Server
| SIP gateway 1 sends an INVITE request to the SIP redirect server. The INVITE request is an invitation to User B to participate in a call session.
In the INVITE request:
- The phone number of User B is inserted in the Request-URI field in the form of a SIP URL. The SIP URL identifies the address of User B and takes a form similar to an email address (user@host where user is the telephone number and host is either a domain name or a numeric network address). For example, the Request-URI field in the INVITE request to User B appears as "INVITE sip:555-0002@companyb.com; user=phone." The "user=phone" parameter distinquishes that the Request-URI address is a telephone number rather than a user name.
- PBX A is identified as the call session initiator in the From field.
- A unique numeric identifier is assigned to the call and is inserted in the Call-ID field.
- The transaction number within a single call leg is identified in the CSeq field.
- The media capability User A is ready to receive is specified.
- The port on which SIP gateway 1 is prepared to receive the RTP data is specified.
|
3
| 300 Multiple ChoiceSIP Redirect Server to SIP Gateway1
| 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
| ACKSIP Gateway 1 to SIP Redirect Server
| SIP gateway 1 acknowledges the 300 Multiple Choice response with an ACK.
|
5
| INVITESIP 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
| SetupSIP Gateway 2 to PBXB
| SIP gateway 2 receives the INVITE request from SIP gateway 1 and initiates a Call Setup with User B via PBXB.
|
7
| Call ProceedingSIP Gateway1 to PBX A
| SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
|
8
| 100 TryingSIP Gateway 2 to SIP Gateway 1
| SIP gateway 2 sends a 100 Trying response to the INVITE request sent by SIP gateway1. The 100 Trying response indicates that the INVITE request has been received by SIP gateway 2 but that User B has not yet been located.
|
9
| Call ProceedingPBX B to SIP Gateway 2
| PBX B sends a Call Proceeding message to SIP gateway 2 to acknowledge the Call Setup request.
|
10
| AlertingPBX 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 RingingSIP 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
| AlertingSIP Gateway 1 to PBX A
| SIP gateway 1 sends an Alert message to PBX A. User A hears ringback tone.
|
At this point, a one-way voice path is established between SIP gateway 1 and PBXA and between SIP gateway 2 and PBX B. A two-way RTP channel is established between SIP gateway 1 and SIP gateway 2.
|
13
| ConnectPBX 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 OKSIP 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
| ConnectSIP 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 ACKPBX A to SIP Gateway 1
| PBX A acknowledges SIP gateway 1's Connect message.
|
17
| ACKSIP 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 ACKSIP 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 PBXA and between SIP gateway 2 and PBX B. A two-way RTP channel is established between SIP gateway 1 and SIP gateway 2.
|
19
| DisconnectPBX B to SIP Gateway2
| 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
| BYESIP 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
| DisconnectSIP Gateway 1 to PBXA
| SIP gateway 1 sends a Disconnect message to PBX A.
|
22
| ReleaseSIP Gateway 2 to PBX B
| SIP gateway 2 sends a Release message to PBX B.
|
23
| ReleasePBX A to SIP Gateway 1
| PBX A sends a Release message to SIP gateway 1.
|
24
| 200 OKSIP 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 CompletePBX B to SIP Gateway 2
| PBX B sends a Release Complete message to SIP gateway 2.
|
26
| Release CompleteSIP Gateway 1 to PBX A
| SIP gateway 1 sends a Release Complete message to PBX A and the session is terminated.
|
Figure 3 and Figure 4 illustrate a successful gateway-to-gateway call setup and disconnect via a proxy server. In these scenarios, the two end users are User A and User B. User A is located at PBX A. PBX A is connected to SIP Gateway 1 via a T1/E1. SIP Gateway 1 is using a proxy server. SIP Gateway 1 is connected to SIP Gateway 2 over an IP network. User B is located at PBX B. PBX B is connected to SIP Gateway 2 (a SIP gateway) via a T1/E1. User B's phone number is 555-0002.
In the scenario illustrated by Figure 3, the record route feature is enabled on the proxy server. In the scenario illustrated by Figure 4, record route is disabled on the proxy server.
When record route is enabled, the proxy server adds the Record-Route header to the SIP messages to ensure that it is in the path of subsequent SIP requests for the same call leg. The Record-Route field contains a globally reachable Request-URI that identifies the proxy server. When record route is enabled, each proxy server adds its Request-URI to the beginning of the list.
When record route is disabled, SIP messages flow directly through the SIP gateways once a call has been established.
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 3: SIP Gateway-to-SIP Gateway Call via SIP Proxy Server with Record Route Enabled
Step
| Action
| Description
|
1
| SetupPBX A to SIP Gateway1
| 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 UserB.
|
2
| INVITESIP Gateway 1 to Proxy Server
| SIP gateway 1 sends an INVITE request to the SIP proxy server. The INVITE request is an invitation to User B to participate in a call session.
In the INVITE request:
- The phone number of User B is inserted in the Request-URI field in the form of a SIP URL. The SIP URL identifies the address of User B and takes a form similar to an email address (user@host where user is the telephone number and host is either a domain name or a numeric network address). For example, the Request-URI field in the INVITE request to User B appears as "INVITE sip:555-0002@companyb.com; user=phone." The "user=phone" parameter distinquishes that the Request-URI address is a telephone number rather than a user name.
- PBX A is identified as the call session initiator in the From field.
- A unique numeric identifier is assigned to the call and is inserted in the Call-ID field.
- The transaction number within a single call leg is identified in the CSeq field.
- The media capability User A is ready to receive is specified.
- The port on which SIP gateway 1 is prepared to receive the RTP data is specified.
|
3
| Call ProceedingSIP Gateway1 to PBX A
| SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
|
4
| INVITESIP Proxy Server to SIP Gateway 2
| The SIP proxy server checks whether it's own address is contained in the Via field (to prevent loops), directly copies the To, From, Call-ID, and Contact fields from the request it received from SIP gateway 1, changes the Request-URI to indicate the server to which it intends to send the INVITE request, and then sends a new INVITE request to SIP gateway 2.
In the INVITE request, the SIP proxy server also adds 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.
|
5
| 100 TryingSIP Proxy Server to SIP Gateway 1
| The SIP proxy server sends a 100 Trying response to SIP gateway 1.
|
6
| SetupSIP Gateway 2 to PBXB
| SIP gateway 2 receives the INVITE request from the SIP proxy server and initiates a Call Setup with UserB via PBXB.
|
7
| 100 TryingSIP 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 ProceedingPBX B to SIP Gateway 2
| PBX B sends a Call Proceeding message to SIP gateway 2 to acknowledge the Call Setup request.
|
9
| AlertingPBX B to SIP Gateway 2
| PBX B locates User B and sends an Alert message to SIP gateway 2. User B's phone begin to ring.
|
10
| 180 RingingSIP Gateway 2 to SIP Proxy Server
| SIP gateway 2 sends a 180 Ringing response to the SIP proxy server.
|
11
| 180 RingingSIP Proxy Server to SIP Gateway 1
| The SIP proxy server forwards the 180 Ringing response to SIP gateway 1.
|
12
| AlertingSIP 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
| ConnectPBX 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 OKSIP 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.
In the 200 OK response, the SIP gateway 2 adds the Record-Route header (received in the INVITE request) to ensure that it is in the path of subsequent SIP requests for the same call leg.
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.
|
15
| 200 OKSIP 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
| ConnectSIP 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 ACKPBX A to SIP Gateway 1
| PBX A acknowledges SIP gateway 1's Connect message.
|
18
| ACKSIP 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
| ACKSIP Proxy Server to SIP Gateway2
| 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 ACKSIP 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
| DisconnectPBX B to SIP Gateway2
| After the call is completed, PBX B sends a Disconnect message to SIP gateway2. The Disconnect message starts the call session termination process.
|
22
| BYESIP 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 UserB's SIP URL.
|
23
| BYESIP Proxy Server to SIP Gateway1
| The SIP proxy server forwards the BYE request to SIP gateway 1.
|
24
| DisconnectSIP Gateway 1 to PBXA
| SIP gateway 1 sends a Disconnect message to PBX A.
|
25
| ReleaseSIP Gateway 2 to PBX B
| After the call is completed, SIP gateway 2 sends a Release message to PBX B.
|
26
| ReleasePBX A to SIP Gateway 1
| PBX A sends a Release message to SIP gateway 1.
|
27
| 200 OKSIP 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 OKSIP Proxy Server to SIP Gateway 2
| The SIP proxy server forwards the 200 OK response to SIP gateway 2.
|
29
| Release CompletePBX B to SIP Gateway 2
| PBX B sends a Release Complete message to SIP gateway 2.
|
30
| Release CompleteSIP Gateway 1 to PBX A
| SIP gateway 1 sends a Release Complete message to PBX A and the call session is terminated.
|
Figure 4: SIP Gateway-to-SIP Gateway Call via a Proxy Server with Record Route Disabled
Step
| Action
| Description
|
1
| SetupPBX A to SIP Gateway1
| 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 UserB.
|
2
| INVITESIP Gateway 1 to SIP Proxy Server
| SIP gateway 1 sends an INVITE request to the SIP proxy server. The INVITE request is an invitation to User B to participate in a call session.
In the INVITE request:
- The phone number of User B is inserted in the Request-URI field in the form of a SIP URL. The SIP URL identifies the address of User B and takes a form similar to an email address (user@host where user is the telephone number and host is either a domain name or a numeric network address). For example, the Request-URI field in the INVITE request to User B appears as "INVITE sip:555-0002@companyb.com; user=phone." The "user=phone" parameter distinquishes that the Request-URI address is a telephone number rather than a user name.
- PBX A is identified as the call session initiator in the From field.
- A unique numeric identifier is assigned to the call and is inserted in the Call-ID field.
- The transaction number within a single call leg is identified in the CSeq field.
- The media capability User A is ready to receive is specified.
- The port on which SIP gateway 1 is prepared to receive the RTP data is specified.
|
3
| Call ProceedingSIP Gateway1 to PBX A
| SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
|
4
| INVITESIP Proxy Server to SIP Gateway 2
| The SIP proxy server checks whether it's own address is contained in the Via field (to prevent loops), directly copies the To, From, Call-ID, and Contact fields from the request it received from SIP gateway 1, changes the Request-URI to indicate the server to which it intends to send the INVITE request, and then sends a new INVITE request to SIP gateway 2.
|
5
| 100 TryingSIP Proxy Server to SIP Gateway 1
| The SIP proxy server sends a 100 Trying response to SIP gateway 1.
|
6
| SetupSIP Gateway 2 to PBXB
| SIP gateway 2 receives the INVITE request from the SIP proxy server and initiates a Call Setup with UserB via PBXB.
|
7
| 100 TryingSIP 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 ProceedingPBX B to SIP Gateway 2
| PBX B sends a Call Proceeding message to SIP gateway 2 to acknowledge the Call Setup request.
|
9
| AlertingPBX B to SIP Gateway 2
| PBX B locates User B and sends an Alert message to SIP gateway 2. User B's phone begin to ring.
|
10
| 180 RingingSIP Gateway 2 to SIP Proxy Server
| SIP gateway 2 sends a 180 Ringing response to the SIP proxy server.
|
11
| 180 RingingSIP Proxy Server to SIP Gateway 1
| The SIP proxy server forwards the 180 Ringing response to SIP gateway 1.
|
12
| AlertingSIP 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 UserB 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
| ConnectPBX 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 OKSIP 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.
|
15
| 200 OKSIP 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
| ConnectSIP 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 ACKPBX A to SIP Gateway 1
| PBX A acknowledges SIP gateway 1's Connect message.
|
18
| ACKSIP 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 ACKSIP 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
| DisconnectPBX B to SIP Gateway2
| After the call is completed, PBX B sends a Disconnect message to SIP gateway2. The Disconnect message starts the call session termination process.
|
21
| BYESIP 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
| DisconnectSIP Gateway 1 to PBXA
| SIP gateway 1 sends a Disconnect message to PBX A.
|
23
| ReleaseSIP Gateway 2 to PBX B
| After the call is completed, SIP gateway 2 sends a Release message to PBX B.
|
24
| ReleasePBX A to SIP Gateway 1
| PBX A sends a Release message to SIP gateway 1.
|
25
| 200 OKSIP 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 CompletePBX B to SIP Gateway 2
| PBX B sends a Release Complete message to SIP gateway 2.
|
27
| Release CompleteSIP Gateway 1 to PBX A
| SIP gateway 1 sends a Release Complete message to PBX A and the call session is terminated.
|
This section describes the following SIP Gateway-to-SIP IP phone call flows:
Figure 5 illustrates a successful gateway-to-SIP IP phone call setup and disconnect. In this scenario, the two end users are User A and User B. User A is located at PBX A. PBX A is connected to SIP gateway 1 via a T1/E1. User B is located at a SIP IP phone. SIP gateway 1 is connected to the SIP IP phone over an IP network.
The call flow is as follows:
1. User A calls User B.
2. User B answers the call.
3. User B hangs up.
Figure 5: SIP Gateway-to-SIP IP PhoneCall Setup and Disconnect
Step
| Action
| Description
|
1
| SetupPBX A to SIP Gateway1
| 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 UserB.
|
2
| INVITESIP Gateway 1 to SIP IP Phone
| SIP gateway 1 maps the SIP URL phone number to a dial-peer. The dial-peer includes the IP address and the port number of the SIP enabled entity to contact. SIP gateway 1 sends an INVITE request to the address it receives in the dial peer which, in this scenario, is the SIP IP phone.
In the INVITE request:
- The IP address of the SIP IP phone is inserted in the Request-URI field.
- PBX A is identified as the call session initiator in the From field.
- A unique numeric identifier is assigned to the call and is inserted in the Call-ID field.
- The transaction number within a single call leg is identified in the CSeq field.
- The media capability User A is ready to receive is specified.
- The port on which the SIP gateway is prepared to receive the RTP data is specified.
|
3
| Call ProceedingSIP Gateway1 to PBX A
| SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
|
4
| 100 TryingSIP IP Phone to SIP Gateway 1
| The SIP IP phone sends a 100 Trying response to SIP gateway 1. The 100 Trying response indicates that the INVITE request has been received by the SIP IP phone.
|
5
| 180 RingingSIP IP Phone to SIP Gateway 1
| The SIP IP phone sends a 180 Ringing response to SIP gateway 1. The 180 Ringing response indicates that the user is being alerted.
|
6
| AlertingSIP Gateway 1 to PBX A
| SIP gateway 1 sends an Alert message to User A. The Alert message indicates that SIP gateway 1 has received a 180 Ringing response from the SIP IP phone. User A hears the ringback tone that indicates that User B is being alerted.
|
7
| 200 OKSIP IP Phone to SIP Gateway 1
| The SIP IP phone sends a 200 OK response to SIP gateway 1. The 200 OK response notifies SIP gateway 1 that the connection has been made.
|
8
| ConnectSIP Gateway 1 to PBX A
| SIP gateway 1 sends a Connect message to PBX A. The Connect message notifies PBX A that the connection has been made.
|
9
| Connect ACKPBX A to SIP Gateway 1
| PBX A acknowledges SIP gateway 1's Connect message.
|
10
| ACKSIP Gateway 1 to SIP IP Phone
| SIP gateway 1 sends an ACK to the SIP IP phone. The ACK confirms that SIP gateway1 has received the 200 OK response. The call session is now active.
|
At this point, a two-way voice path is established between SIP gateway 1 and PBX A. A two-way RTP channel is established between SIP gateway 1 and SIP IP phone B.
|
11
| BYESIP IP Phone to SIP Gateway1
| User B terminates the call session at his SIP IP phone and the phone sends a BYE request to SIP gateway 1. The BYE request indicates that User B wants to release the call.
|
12
| DisconnectSIP Gateway 1 to PBX A
| SIP gateway 1 sends a Disconnect message to PBX A.
|
13
| ReleasePBX A to SIP Gateway 1
| PBX A sends a Release message to SIP gateway 1.
|
14
| 200 OKSIP Gateway 1 to SIP IP Phone
| SIP gateway 1 sends a 200 OK response to the SIP IP phone. The 200 OK response notifies the phone that SIP gateway 1 has received the BYE request.
|
15
| Release CompleteSIP Gateway 1 to PBX A
| SIP gateway 1 sends a Release Complete message to PBX A and the call session is terminated.
|
Figure 6 illustrates a successful gateway-to-SIP IP phone call setup and call hold. In this scenario, the two end users are User A and User B. User A is located at PBX A. PBX A is connected to SIP gateway 1 via a T1/E1. User B is located at a SIP IP phone. SIP gateway 1 is connected to the SIP IP phone over an IP network.
The call flow is as follows:
1. User A calls User B.
2. User B answers the call.
3. User B puts User A on hold.
4. User B takes User A off hold.
Figure 6: SIP Gateway-to-SIP IP Phone CallCall Setup and Call Hold
Step
| Action
| Description
|
1
| SetupPBX A to SIP Gateway1
| 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 UserB.
|
2
| INVITESIP Gateway 1 to SIP IP Phone
| SIP gateway 1 maps the SIP URL phone number to a dial-peer. The dial-peer includes the IP address and the port number of the SIP enabled entity to contact. SIP gateway 1 sends an INVITE request to the address it receives in the dial peer which, in this scenario, is the SIP IP phone.
In the INVITE request:
- The IP address of the SIP IP phone is inserted in the Request-URI field.
- PBX A is identified as the call session initiator in the From field.
- A unique numeric identifier is assigned to the call and is inserted in the Call-ID field.
- The transaction number within a single call leg is identified in the CSeq field.
- The media capability User A is ready to receive is specified.
- The port on which the SIP gateway is prepared to receive the RTP data is specified.
|
3
| Call ProceedingSIP Gateway 1 to PBX A
| SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
|
4
| 100 TryingSIP IP Phone to SIP Gateway 1
| The SIP IP phone sends a 100 Trying response to SIP gateway 1. The 100 Trying response indicates that the INVITE request has been received by the SIP IP phone.
|
5
| 180 RingingSIP IP Phone to SIP Gateway 1
| The SIP IP phone sends a 180 Ringing response to SIP gateway 1. The 180 Ringing response indicates that the user is being alerted.
|
6
| AlertingSIP Gateway 1 to PBX A
| SIP gateway 1 sends an Alert message to User A. The Alert message indicates that SIP gateway 1 has received a 180 Ringing response from the SIP IP phone. User A hears the ringback tone that indicates that User B is being alerted.
|
7
| 200 OKSIP IP Phone to SIP Gateway 1
| The SIP IP phone sends a 200 OK response to SIP gateway 1. The 200 OK response notifies SIP gateway 1 that the connection has been made.
|
8
| ConnectSIP Gateway 1 to PBX A
| SIP gateway 1 sends a Connect message to PBX A. The Connect message notifies PBX A that the connection has been made.
|
9
| ACKSIP Gateway 1 to SIP IP Phone
| SIP gateway 1 sends an ACK to the SIP IP phone. The ACK confirms that User A has received the 200 OK response. The call session is now active.
|
10
| Connect ACKPBX A to SIP Gateway 1
| PBX A acknowledges SIP gateway 1's Connect message.
|
At this point, a two-way voice path is established between SIP gateway 1 and PBX A. A two-way RTP channel is established between SIP gateway 1 and SIP IP phone B.
|
11
| INVITESIP IP Phone to SIP Gateway 1
| User B puts User A on hold. The SIP IP phone sends an INVITE request to SIP gateway 1.
|
12
| 200 OKSIP Gateway 1 to SIP IP Phone
| SIP gateway 1 sends a 200 OK response to the SIP IP phone. The 200 OK response notifies the SIP IP phone that the INVITE was successfully processed.
|
13
| ACKSIP IP Phone to SIP Gateway1
| The SIP IP phone sends an ACK to SIP gateway 1. The ACK confirms that the SIP IP phone has received the 200 OK response. The call session is now temporarily inactive. No RTP packets are being sent.
|
The two-way RTP channel is torn down. The call is on hold.
|
14
| INVITESIP IP Phone to SIP Gateway 1
| User B takes User A off hold. The SIP IP phone sends an INVITE request to SIP gateway 1.
|
15
| 200 OKSIP Gateway 1 to SIP IP Phone
| SIP gateway 1 sends a 200 OK response to the SIP IP phone. The 200 OK response notifies the SIP IP phone that the INVITE was successfully processed.
|
16
| ACKSIP IP Phone to SIP Gateway1
| The SIP IP phone sends an ACK to SIP gateway 1. The ACK confirms that the SIP IP phone has received the 200 OK response. The call session is now active.
|
At this point, a two-way voice path exists between SIP gateway 1 and PBX A and the two-way RTP channel is reestablished between SIP gateway 1 and SIP IP phone B.
|
Figure 7 illustrates a successful gateway-to-SIP IP phone call setup and call transfer without consultation. In this scenario, there are three end users: User A, User B, and User C. User A is located at PBX A. PBX A is connected to SIP gateway 1 via a T1/E1. User B is located at a SIP IP phone and is directly connected to the IP network. User C is located at PBX B. PBX B is connected to SIP gateway 2 via a T1/E1. SIP gateway 1, SIP gateway 2, and the SIP IP phone are connected to one another over an IP network.
The call flow is as follows:
1. User A calls User B.
2. User B answers the call.
3. User B transfers User A's call to User C and then hangs up.
4. User C answers the call.
Figure 7: SIP Gateway-to-SIP IP Phone CallCall Setup and Transfer
Step
| Action
| Description
|
1
| SetupPBX A to SIP Gateway1
| 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 UserB.
|
2
| INVITESIP Gateway 1 to SIP IP Phone
| SIP gateway 1 maps the SIP URL phone number to a dial-peer. The dial-peer includes the IP address and the port number of the SIP enabled entity to contact. SIP gateway 1 sends an INVITE request to the address it receives in the dial peer which, in this scenario, is the SIP IP phone.
In the INVITE request:
- The IP address of the SIP IP phone is inserted in the Request-URI field.
- PBX A is identified as the call session initiator in the From field.
- A unique numeric identifier is assigned to the call and is inserted in the Call-ID field.
- The transaction number within a single call leg is identified in the CSeq field.
- The media capability User A is ready to receive is specified.
- The port on which the SIP gateway is prepared to receive the RTP data is specified.
|
3
| Call ProceedingSIP Gateway1 to PBX A
| SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
|
4
| 100 TryingSIP IP Phone to SIP Gateway 1
| The SIP IP phone sends a 100 Trying response to SIP gateway 1. The 100 Trying response indicates that the INVITE request has been received by the SIP IP phone.
|
5
| 180 RingingSIP IP Phone to SIP Gateway 1
| The SIP IP phone sends a 180 Ringing response to SIP gateway 1. The 180 Ringing response indicates that the user is being alerted.
|
6
| AlertingSIP Gateway 1 to PBX A
| SIP gateway 1 sends an Alert message to User A. The Alert message indicates that SIP gateway 1 has received a 180 Ringing response from the SIP IP phone. User A hears the ringback tone that indicates that User B is being alerted.
|
7
| 200 OKSIP IP Phone to SIP Gateway 1
| The SIP IP phone sends a 200 OK response to SIP gateway 1. The 200 OK response notifies SIP gateway 1 that the connection has been made.
|
8
| ConnectSIP Gateway 1 to PBX A
| SIP gateway 1 sends a Connect message to PBX A. The Connect message notifies PBX A that the connection has been made.
|
9
| Connect ACKPBX A to SIP Gateway 1
| PBX A acknowledges SIP gateway 1's Connect message.
|
10
| ACKSIP Gateway 1 to SIP IP Phone
| SIP gateway 1 sends an ACK to the SIP IP phone. The ACK confirms that SIP gateway1 has received the 200 OK response. The call session is now active.
|
At this point, a two-way voice path is established between SIP gateway 1 and PBX A. A two-way RTP channel is established between SIP gateway 1 and SIP IP phone B.
|
11
| BYESIP IP Phone to SIP Gateway1
| User B transfers User A's call to User C and then hangs up. The SIP IP phone sends a BYE request to SIP gateway 1. The BYE request includes the Also header. In this scenario, the Also header indicates that User C needs to be brought into the call while User B hangs up. This header distinguishes the call transfer BYE request from a normal disconnect BYE request.
The Request-By header could be included in the BYE request, however, Cisco's implementation does not require the header to complete the transfer. If the Requested-By header is included, the INVITE sent to the transferred-to party will include the Requested-By header. If the Requested-By header is not included, the INVITE sent to the transferred-to party will not include the Requested-By header.
|
12
| 200 OKSIP Gateway 1 to SIP IP Phone
| SIP gateway 1 sends a 200 OK message to the SIP IP phone. The 200 OK response notifies the SIP IP phone that the BYE request has been received. The call session between User A and User B is now terminated.
|
13
| INVITESIP Gateway 1 to SIP Gateway 2
| SIP gateway 1 sends an INVITE request to SIP gateway 2. In the INVITE request, a unique Call-ID is generated and the Requested-By field indicates that User B requested the call.
|
14
| SetupSIP Gateway 2 to PBXB
| SIP gateway 2 receives the INVITE request from SIP gateway 1 and initiates a Call Setup with User C via PBX B.
|
15
| 100 TryingSIP Gateway 2 to SIP Gateway 1
| SIP gateway 2 sends a 100 Trying response to the INVITE request sent by SIP gateway 1. The 100 Trying response indicates that SIP gateway 2 has received the INVITE request but that User C has not yet been located.
|
16
| Call ProceedingPBX B to SIP Gateway 2
| PBX B sends a Call Proceeding message to SIP gateway 2. User C's phone begins to ring.
|
17
| AlertingPBX B to SIP Gateway 2
| PBX B sends an Alert message to SIP gateway 2. The message indicates that the PBX is attempting to alert the user of the call (that is to say, the phone is ringing).
|
18
| 180 RingingSIP Gateway 2 to SIP Gateway 1
| SIP gateway 2 sends a 180 Ringing response to SIP gateway 1. The 180 Ringing response indicates that SIP gateway 2 has located, and is trying to alert, User C.
|
19
| AlertingSIP Gateway 1 to PBX A
| SIP gateway 1 sends an Alert message to PBX A. The Alert message indicates that SIP gateway 1 has received a 180 Ringing response from the SIP IP phone. User A hears the ringback tone that indicates that User C is being alerted.
|
20
| ConnectPBX B to SIP Gateway 2
| User C answers the phone. PBX B sends a Connect message to SIP gateway 2. The Connect message notifies SIP gateway 2 that the connection has been made.
|
21
| 200 OKSIP Gateway 2 to SIP Gateway 1
| SIP gateway 2 sends a 200 OK response to SIP gateway 1. The 200 OK response notifies SIP gateway 1 that the connection has been made.
If User C supports the media capability advertised in the INVITE message sent by User A, it advertises the intersection of its own and User A's media capability in the 200 OK response. If User C does not support the media capability advertised by User A, it sends back a 400 Bad Request response with a 304 Warning header field.
|
22
| ConnectSIP Gateway 1 to PBX A
| SIP gateway 1 sends a Connect message to PBX A. The Connect message notifies PBX A that the connection has been made.
|
23
| Connect ACKPBX A to SIP Gateway 1
| PBX A acknowledges SIP gateway 1's Connect message.
|
24
| ACKSIP Gateway 1 to SIP Gateway 2
| SIP gateway 1 sends an ACK to SIP gateway 2. The ACK confirms that SIP gateway 1 has received the 200 OK message from SIP gateway 2.
|
25
| Connect ACKSIP 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.
|
This section includes call flows for scenarios in which the call setup has failed because of one of the following reasons:
- The called user is busyA SIP 486 Busy Here response is received.
- The called user does not answer and the request times outA SIP CANCEL request is sent.
- A client, server, or global error occursA SIP 4xx, 5xx, or 6xx failure response is received.
The network configurations in which the call flow scenarios occur are the following:
- SIP gateway-to-SIP gateway calls
- SIP gateway-to-SIP gateway calls via a redirect server
- SIP gateway-to-SIP gateway calls via proxy server
- SIP gateway-to-SIP IP phone calls
This section describes the call flows for failed SIP gateway-to-SIP gateway calls. In the following call flows, the network configuration is the same as the network configuration outlined in the "SIP Gateway-to-SIP Gateway Call" section. However, instead of successfully establishing a call session, one of the following situations occurs:
Figure 8 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 8: SIP Gateway-to-SIP Gateway CallCalled User is Busy
Step
| Action
| Description
|
1
| SetupPBX A to SIP Gateway1
| 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 UserB.
|
2
| INVITESIP Gateway 1 to SIP Gateway 2
| SIP gateway 1 sends an INVITE request to SIP gateway 2. The INVITE request is an invitation to User B to participate in a call session.
In the INVITE request:
- The phone number of User B is inserted in the Request-URI field in the form of a SIP URL.
- PBX A is identified as the call session initiator in the From field.
- A unique numeric identifier is assigned to the call and is inserted in the Call-ID field.
- The transaction number within a single call leg is identified in the CSeq field.
- The media capability User A is ready to receive is specified.
- The port on which SIP gateway 1 is prepared to receive the RTP data is specified.
|
3
| Call ProceedingSIP Gateway 1 to PBX A
| SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
|
4
| SetupSIP Gateway 2 to PBXB
| SIP gateway 2 receives the INVITE request from SIP gateway 1 and initiates a Call Setup with User B via PBXB.
|
5
| 100 TryingSIP Gateway 2 to SIP Gateway 1
| SIP gateway 2 sends a 100 Trying response to the INVITE request sent by SIP gateway 1. The 100 Trying message indicates that the INVITE request has been received by SIP gateway 2 but that User B has not yet been located and that some unspecified action, such as a database consultation, is taking place.
|
6
| Call ProceedingPBX B to SIP Gateway 2
| PBX B sends a Call Proceeding message to SIP gateway 2 to acknowledge the Call Setup request.
|
7
| Disconnect (Busy)PBX B to SIP Gateway 2
| PBX B sends a Disconnect message to SIP gateway 2. In the Disconnect message, the cause code indicates that User B is busy. The Disconnect message starts the call session termination process.
|
8
| 486 Busy HereSIP Gateway 2 to SIP Gateway 1
| SIP gateway 2 maps the Release message cause code (Busy) to the 486 Busy Here response and sends the response to SIP gateway 1. The 486 Busy Here response is a client error response that indicates that User B's phone was successfully contacted but User B was not willing or was unable to take another call.
|
9
| Disconnect (Busy)SIP Gateway 1 to PBX A
| SIP gateway 1 sends a Release message to PBX A. User A hears a busy tone.
|
10
| ReleaseSIP Gateway 2 to PBX B
| SIP gateway 2 sends a Release message to PBX B.
|
11
| ReleasePBX A to SIP Gateway 1
| PBX A sends a Release message to SIP gateway 1.
|
12
| ACKSIP Gateway 1 to SIP Gateway 2
| SIP gateway 1 sends an ACK to SIP gateway 2. The ACK confirms that the 486 Busy Here response has been received.
|
13
| Release CompletePBX B to SIP Gateway 2
| PBX B sends a Release Complete message to SIP gateway 2.
|
14
| Release CompleteSIP Gateway 1 to PBX A
| SIP gateway 1 sends a Release Complete message to PBX A and the call session attempt is terminated.
|
Figure 9 illustrates an unsuccessful call in which User A initiates a call to User B but User B does not answer.
Figure 9: SIP Gateway-to-SIP Gateway CallCalled User Does Not Answer
Step
| Action
| Description
|
1
| SetupPBX A to SIP Gateway1
| 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 UserB.
|
2
| INVITESIP Gateway 1 to SIP Gateway 2
| SIP gateway 1 sends an INVITE request to SIP gateway 2. The INVITE request is an invitation to User B to participate in a call session.
In the INVITE request:
- The phone number of User B is inserted in the Request-URI field in the form of a SIP URL.
- PBX A is identified as the call session initiator in the From field.
- A unique numeric identifier is assigned to the call and is inserted in the Call-ID field.
- The transaction number within a single call leg is identified in the CSeq field.
- The media capability User A is ready to receive is specified.
- The port on which SIP gateway 1 is prepared to receive the RTP data is specified.
|
3
| Call ProceedingSIP Gateway1 to PBX A
| SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
|
4
| SetupSIP Gateway 2 to PBXB
| SIP gateway 2 receives the INVITE request from SIP gateway 1 and initiates a Call Setup with User B via PBXB.
|
5
| 100 TryingSIP Gateway 2 to SIP Gateway 1
| SIP gateway 2 sends a 100 Trying response to the INVITE request sent by SIP gateway 1. The 100 Trying response indicates that the INVITE request has been received by SIP gateway 2 but that User B has not yet been located and that some unspecified action, such as a database consultation, is taking place.
|
6
| Call ProceedingPBX B to SIP Gateway 2
| PBX B sends a Call Proceeding message to SIP gateway 2 to acknowledge the Call Setup request.
|
7
| AlertingPBX B to SIP Gateway 2
| PBX B sends an Alert message to SIP gateway 2. The message indicates that the PBX is attempting to alert the user of the call (that is to say, the phone is ringing).
|
8
| 180 RingingSIP Gateway 2 to SIP Gateway 1
| SIP gateway 2 sends a 180 Ringing response to SIP gateway 1. The 180 Ringing response indicates that SIP gateway 2 has located, and is trying to alert, User B.
|
9
| AlertingSIP Gateway 1 to PBX A
| SIP gateway 1 sends an Alert message to PBX A. The Alert message indicates that SIP gateway 1 has received a 180 Ringing response from SIP gateway 2. User A hears the ringback tone that indicates that User B is being alerted.
|
10
| Cancel (Ring Timeout)SIP Gateway 1 to SIP Gateway 2
| Because SIP gateway 2 did not return an appropriate response within the time specified by the Expires header in the INVITE request, SIP gateway 1 sends a SIP CANCEL request to SIP gateway 2. A CANCEL request cancels a pending request with the same Call-ID, To, From, and CSeq header field values.
|
11
| DisconnectSIP Gateway 1 to PBX A
| SIP gateway 1 sends a Disconnect message to PBX A.
|
12
| DisconnectSIP Gateway 2 to PBX B
| SIP gateway 2 sends a Disconnect message to PBX B.
|
13
| ReleasePBX A to SIP Gateway 1
| PBX A sends a Release message to SIP gateway 1.
|
14
| ReleasePBX B to SIP Gateway 2
| PBX B sends a Release message to SIP gateway 2.
|
15
| 200 OKSIP Gateway 2 to SIP Gateway 1
| SIP gateway 2 sends a 200 OK response to SIP gateway 2. The 200 OK response confirms that the Cancel request has been received.
|
16
| Release CompleteSIP Gateway 1 to PBX A
| SIP gateway 1 sends a Release Complete message to PBX A.
|
17
| Release CompleteSIP Gateway 2 to PBX B
| SIP gateway 2 sends a Release Complete message to PBX B and the call session attempt is terminated.
|
Figure 10 illustrates an unsuccessful call in which User A initiates a call to User B but there are no more channels available on the gateway. Therefore, SIP gateway 2 refuses the connection.
Figure 10: SIP Gateway-to-SIP Gateway CallClient, Server, or Global Error
Step
| Action
| Description
|
1
| SetupPBX A to SIP Gateway1
| 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 UserB.
|
2
| INVITESIP Gateway 1 to SIP Gateway 2
| SIP gateway 1 sends an INVITE request to SIP gateway 2. The INVITE request is an invitation to User B to participate in a call session.
In the INVITE request:
- The phone number of User B is inserted in the Request-URI field in the form of a SIP URL.
- PBX A is identified as the call session initiator in the From field.
- A unique numeric identifier is assigned to the call and is inserted in the Call-ID field.
- The transaction number within a single call leg is identified in the CSeq field.
- The media capability User A is ready to receive is specified.
- The port on which SIP gateway 1 is prepared to receive the RTP data is specified.
|
3
| Call ProceedingSIP Gateway1 to PBX A
| SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
|
4
| 100 TryingSIP Gateway 2 to SIP Gateway 1
| SIP gateway 2 sends a 100 Trying response to the INVITE request sent by SIP gateway 1. The 100 Trying message indicates that the INVITE request has been received by SIP gateway 2 but that User B has not yet been located and that some unspecified action, such as a database consultation, is taking place.
|
5
| Class 4xx/5xx/6xx FailureSIP Gateway 2 to SIP Gateway 1
| SIP gateway 2 determines that it does not have any more channels available, refuses the connection, and sends a SIP 503 Service Unavailable response to SIP gateway 1.
The 503 Service Unavailable response is a class 4xx, 5xx, or class 6xx failure response. Depending on which class the failure response is, the call actions differ.
If SIP gateway 2 sends a class 4xx failure response (a definite failure response that is a client error), the request will not be retried without modification.
If SIP gateway 2 sends a class 5xx failure response (an indefinite failure that is a server error), the request is not terminated but rather other possible locations are tried.
If SIP gateway 2 sends a class 6xx failure response (a global error), the search for User B is terminated because the 6xx response indicates that a server has definite information about User B, but not for the particular instance indicated in the Request-URI field. Therefore, all further searches for this user will fail.
The call failure on SIP gateway 2 might occur before a proceeding indication from PBX B. In that case a SIP failure response is sent before the 100 Trying response.
|
6
| DisconnectSIP Gateway 1 to PBX A
| SIP gateway 1 sends a Disconnect message to PBX A.
|
7
| ReleasePBX A to SIP Gateway 1
| PBX A sends a Release message to SIP gateway 1.
|
8
| ACKSIP Gateway 1 to SIP Gateway 2
| SIP gateway 1 sends an ACK to SIP gateway 2. The ACK confirms that the 503 Service Unavailable response has been received.
|
9
| Release CompleteSIP Gateway 1 to PBX A
| SIP gateway 1 sends a Release Complete message to PBX A and the call session attempt is terminated.
|
This section describes the call flows for gateway-to-gateway calls via a redirect server that have failed. In the following call flows, the network configuration is the same as the network configuration outlined in the "SIP Gateway-to-SIP Gateway Call via SIP Redirect Server" section. However, instead of successfully establishing a call session, one of the following situations occurs:
Figure 11 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 11: SIP Gateway-to-SIP Gateway Call via a SIP Redirect ServerCalled User is Busy
Step
| Action
| Description
|
1
| SetupPBX 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
| INVITESIP Gateway 1 to SIP Redirect Server
| SIP gateway 1 sends an INVITE request to the SIP redirect server. The INVITE request is an invitation to User B to participate in a call session.
In the INVITE request:
- The phone number of User B is inserted in the Request-URI field in the form of a SIP URL.
- PBX A is identified as the call session initiator in the From field.
- A unique numeric identifier is assigned to the call and is inserted in the Call-ID field.
- The transaction number within a single call leg is identified in the CSeq field.
- The media capability User A is ready to receive is specified.
- The port on which SIP gateway 1 is prepared to receive the RTP data is specified.
|
3
| 302 Moved Temporarily SIP Redirect Server to SIP Gateway 1
| SIP redirect server sends a 302 Moved Temporarily message to SIP gateway 1. The message indicates that User B is not available and includes instructions to locate UserB.
|
4
| ACKSIP Gateway 1 to SIP Redirect Server
| SIP gateway 1 acknowledges the 302 Moved Temporarily response with an ACK.
|
5
| INVITESIP 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 ProceedingSIP Gateway 1 to PBX A
| SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
|
7
| SetupSIP 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 PBXB.
|
8
| 100 TryingSIP 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 ProceedingPBX 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 HereSIP 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 not willing or was 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
| ReleasePBX A to SIP Gateway 1
| PBX A sends a Release message to SIP gateway 1.
|
14
| ReleaseSIP Gateway 2 to PBX B
| SIP gateway 1 sends a Release message to PBX B.
|
15
| ACKSIP 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 CompleteSIP Gateway 1 to PBXA
| SIP gateway 1 sends a Release Complete message to PBX A and the call session attempt is terminated.
|
17
| Release CompletePBX B to SIP Gateway 2
| PBX B sends a Release Complete message to SIP gateway 2.
|
Figure 12 illustrates an unsuccessful call in which User A initiates a call to User B but User B does not answer.
Figure 12: SIP Gateway-to-SIP Gateway Call via a SIP Redirect ServerCalled User is Does Not Answer
Step
| Action
| Description
|
1
| SetupPBX A to SIP Gateway1
| 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 UserB.
|
2
| INVITESIP Gateway 1 to SIP Redirect Server
| SIP gateway 1 sends an INVITE request to the SIP redirect server. The INVITE request is an invitation to User B to participate in a call session.
In the INVITE request:
- The phone number of User B is inserted in the Request-URI field in the form of a SIP URL.
- PBX A is identified as the call session initiator in the From field.
- A unique numeric identifier is assigned to the call and is inserted in the Call-ID field.
- The transaction number within a single call leg is identified in the CSeq field.
- The media capability User A is ready to receive is specified.
- The port on which SIP gateway 1 is prepared to receive the RTP data is specified.
|
3
| 302 Moved Temporarily SIP Redirect Server to SIP Gateway1
| 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 UserB.
|
4
| ACKSIP Gateway 1 to SIP Redirect Server
| SIP gateway 1 acknowledges the 302 Moved Temporarily response with an ACK.
|
5
| INVITESIP 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 ProceedingSIP Gateway 1 to PBX A
| SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
|
7
| SetupSIP Gateway 2 to PBXB
| SIP gateway 2 receives the INVITE request from SIP gateway 1 and initiates a Call Setup with User B via PBXB.
|
8
| 100 TryingSIP 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 ProceedingPBX B to SIP Gateway 2
| PBX B sends a Call Proceeding message to SIP gateway 2 to acknowledge the Call Setup request.
|
10
| AlertingPBX B to SIP Gateway 2
| PBX B sends an Alert message to SIP gateway 2. User B's phone begins to ring.
|
11
| 180 RingingSIP 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
| AlertingSIP 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
| DisconnectSIP Gateway 1 to PBX A
| SIP gateway 1 sends a Disconnect message to PBX A.
|
15
| ReleasePBX A to SIP Gateway 1
| PBX A sends a Release message to SIP gateway 1.
|
16
| DisconnectSIP Gateway 2 to PBX B
| SIP gateway 2 sends a Disconnect message to PBX B.
|
17
| 200 OKSIP 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 CompletePBX A to SIP Gateway 1
| PBX A sends a Release Complete message to SIP gateway 1 and the call session attempt is terminated.
|
19
| ReleasePBX B to SIP Gateway 2
| PBX B sends a Release message to SIP gateway 2.
|
20
| Release CompleteSIP Gateway 2 to PBX B
| SIP gateway 2 sends a Release Complete message to PBX B.
|
Figure 13 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 13: SIP Gateway-to-SIP Gateway Call via a SIP Redirect ServerClient, Server, or Global
Step
| Action
| Description
|
1
| SetupPBX A to SIP Gateway1
| 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 UserB.
|
2
| INVITESIP Gateway 1 to SIP Redirect Server
| SIP gateway 1 sends an INVITE request to the SIP redirect server. The INVITE request is an invitation to User B to participate in a call session.
In the INVITE request:
- The phone number of User B is inserted in the Request-URI field in the form of a SIP URL.
- PBX A is identified as the initiator in the From field.
- A unique numeric identifier is assigned to the call and is inserted in the Call-ID field.
- The transaction number within a single call leg is identified in the CSeq field.
- The media capability User A is ready is specified.
- The port on which SIP gateway 1 is prepared to receive the RTP data is specified.
|
3
| 300 Multiple ChoiceSIP Redirect Server to SIP Gateway1
| 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
| ACKSIP Gateway 1 to SIP Redirect Server
| SIP gateway 1 acknowledges the 300 Multiple Choice response with an ACK.
|
5
| INVITESIP 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 ProceedingSIP Gateway1 to SIP Gateway 2
| SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
|
7
| 100 TryingSIP 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 FailureSIP Gateway 2 to SIP Gateway 1
| SIP gateway 2 determines that User B does not exist at the domain specified in the INVITE request sent by SIP gateway 1. SIP gateway 2 refuses the connection and sends a 404 Not Found response to SIP gateway 1.
The 404 Not Found response is a class 4xx failure response. Depending on which class the failure response is, the call actions differ.
If SIP gateway 2 sends a class 4xx failure response (a definite failure response that is a client error), the request will not be retried without modification.
If SIP gateway 2 sends a class 5xx failure response (an indefinite failure that is a server error), the request is not terminated but rather other possible locations are tried.
If SIP gateway 2 sends a class 6xx failure response (a global error), the search for User B is terminated because the 6xx response indicates that a server has definite information about User B, but not for the particular instance indicated in the Request-URI field. Therefore, all further searches for this user will fail.
|
9
| DisconnectSIP Gateway 1 to PBX A
| SIP gateway 1 sends a Disconnect message to PBX A.
|
10
| ReleasePBX A to SIP Gateway 1
| PBX A sends a Release message to SIP gateway 1.
|
11
| ACKSIP 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 CompleteSIP Gateway 1 to PBX A
| SIP gateway 1 sends a Release Complete message to PBX A and the call session attempt is terminated.
|
This section describes the call flows for gateway-to-gateway calls via a proxy server that have failed. In the following call flows, the network configuration is the same as the network configuration outlined in the "SIP Gateway-to-SIP Gateway Call via SIP Proxy Server" section. However, instead of successfully establishing a call session, one of the following situations occurs:
Figure 14 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 14: SIP Gateway-to-SIP Gateway Call via a SIP Proxy ServerCalled User is Busy
Step
| Action
| Description
|
1
| SetupPBX A to SIP Gateway1
| 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 UserB.
|
2
| INVITESIP Gateway 1 to SIP Proxy Server
| SIP gateway 1 sends an INVITE request to the SIP proxy server. The INVITE request is an invitation to User B to participate in a call session.
In the INVITE request:
- The phone number of User B is inserted in the Request-URI field in the form of a SIP URL.
- PBX A is identified as the call session initiator in the From field.
- A unique numeric identifier is assigned to the call and is inserted in the Call-ID field.
- The transaction number within a single call leg is identified in the CSeq field.
- The media capability User A is ready to receive is specified.
- The port on which SIP gateway 1 is prepared to receive the RTP data is specified.
|
3
| INVITESIP Proxy Server to SIP Gateway 2
| The SIP proxy server checks whether it's own address is contained in the Via field (to prevent loops), directly copies the To, From, Call-ID, and Contact fields from the request it received from SIP gateway 1, changes the Request-URI to indicate the server to which it intends to send the INVITE request, and then sends a new INVITE request to SIP gateway 2.
|
4
| Call ProceedingSIP Gateway1 to PBX A
| SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
|
5
| SetupSIP Gateway 2 to PBXB
| SIP gateway 2 receives the INVITE request from the SIP proxy server and initiates a Call Setup with UserB via PBXB.
|
6
| 100 TryingSIP Proxy Server to SIP Gateway 1
| The SIP proxy server sends a 100 Trying response to SIP gateway 1.
|
7
| 100 TryingSIP Gateway 2 to SIP Proxy Server
| SIP gateway 2 sends a 100 Trying response to the SIP proxy server.
|
8
| Release Complete (Busy)PBXBto SIP Gateway2
| 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 HereSIP 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 not willing or was unable to take another call.
|
10
| 486 Busy HereSIP 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
| ReleasePBX A to SIP Gateway 1
| PBX A sends a Release message to SIP gateway 1.
|
13
| ACKSIP Gateway 1 to SIP Proxy Server
| SIP gateway 1 sends an SIP ACK to the SIP proxy server.
|
14
| ACKSIP 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 CompleteSIP Gateway 1 to PBX A
| SIP gateway 1 sends a Release Complete message to PBX A and the call session attempt is terminated.
|
Figure 15 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 15: SIP Gateway-to-SIP Gateway Call via a SIP Proxy ServerClient or Server Error
Step
| Action
| Description
|
1
| SetupPBX A to SIP Gateway1
| 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 UserB.
|
2
| INVITESIP Gateway 1 to SIP Proxy Server
| SIP gateway 1 sends an INVITE request to the SIP proxy server. The INVITE request is an invitation to User B to participate in a call session.
In the INVITE request:
- The phone number of User B is inserted in the Request-URI field in the form of a SIP URL.
- PBX A is identified as the initiator in the From field.
- A unique numeric identifier is assigned to the call and is inserted in the Call-ID field.
- The transaction number within a single call leg is identified in the CSeq field.
- The media capability User A is ready to receive is specified.
- The port on which SIP gateway 1 is prepared to receive the RTP data is specified.
|
3
| INVITESIP Proxy Server to SIP Gateway 2
| The SIP proxy server checks whether it's own address is contained in the Via field (to prevent loops), directly copies the To, From, Call-ID, and Contact fields from the request it received from SIP gateway 1, changes the Request-URI to indicate the server to which it intends to send the INVITE request, and then sends a new INVITE request to SIP gateway 2.
|
4
| Call ProceedingSIP Gateway1 to PBX A
| SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
|
5
| 100 TryingSIP Proxy Server to SIP Gateway 1
| The SIP proxy server sends a 100 Trying response to SIP gateway 1.
|
6
| 100 TryingSIP Gateway 2 to SIP Proxy Server
| SIP gateway 2 sends a 100 Trying response to the SIP proxy server.
|
7
| Class 4xx/5xx/6xx FailureSIP 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 FailureSIP Proxy Server to SIP Gateway 1
| The SIP proxy server forwards the SIP 503 Service Unavailable response to SIP gateway 1.
|
9
| DisconnectSIP Gateway 1 to PBXA
| SIP gateway 1 sends a Disconnect message to PBX A.
|
10
| ReleasePBX A to SIP Gateway 1
| PBX A sends a Release message to SIP gateway 1.
|
11
| ACKSIP Gateway 1 to SIP Proxy Server
| SIP Gateway 1 sends an ACK to the SIP proxy server.
|
12
| ACKSIP 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 CompleteSIP Gateway 1 to PBX A
| SIP Gateway 1 sends a Release Complete message to PBX A and the call session attempt is terminated.
|
Figure 16 illustrates an unsuccessful call in which User A initiates a call to User B and receives a class 6xx response.
Figure 16: SIP Gateway-to-SIP Gateway Call via a SIP Proxy ServerGlobal Error Response
Step
| Action
| Description
|
1
| SetupPBX A to SIP Gateway1
| 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 UserB.
|
2
| INVITESIP Gateway 1 to SIP Proxy Server
| SIP gateway 1 sends an INVITE request to the SIP proxy server. The INVITE request is an invitation to User B to participate in a call session.
In the INVITE request:
- The phone number of User B is inserted in the Request-URI field in the form of a SIP URL.
- PBX A is identified as the call session initiator in the From field.
- A unique numeric identifier is assigned to the call and is inserted in the Call-ID field.
- The transaction number within a single call leg is identified in the CSeq field.
- The media capability User A is ready to receive is specified.
- The port on which SIP gateway 1 is prepared to receive the RTP data is specified.
|
3
| Call ProceedingSIP Gateway1 to PBX A
| SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
|
4
| INVITESIP Proxy Server to SIP Gateway 2
| The SIP proxy server checks whether it's own address is contained in the Via field (to prevent loops), directly copies the To, From, Call-ID, and Contact fields from the request it received from SIP gateway 1, changes the Request-URI to indicate the server to which it intends to send the INVITE request, and then sends a new INVITE request to SIP gateway 2.
|
5
| SetupSIP Gateway 2 to PBXB
| SIP gateway 2 receives the INVITE request from the SIP proxy server and initiates a Call Setup with UserB via PBXB.
|
6
| 100 TryingSIP 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 gateway1.
|
7
| 100 TryingSIP Proxy Server to SIP Gateway 1
| The SIP proxy server forwards the 100 Trying response to SIP gateway 1.
|
8
| Release CompletePBX 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 FailureSIP 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 FailureSIP Proxy Server to SIP Gateway 1
| The SIP proxy server forwards the 6xx failure to SIP gateway 1.
|
11
| DisconnectSIP Gateway 1 to PBX A
| SIP gateway 1 sends a Disconnect message to PBX A.
|
12
| ReleasePBX A to SIP Gateway 1
| PBX A sends a Release message to SIP gateway 1.
|
13
| ACKSIP Gateway 1 to SIP Proxy Server
| SIP gateway 1 sends an ACK to the SIP proxy server.
|
14
| ACKSIP 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 CompleteSIP Gateway 1 to PBX A
| SIP gateway 1 sends a Release Complete message to PBX A and the call session attempt is terminated.
|
This section describes the call flows for failed SIP gateway-to-SIP IP phone calls. In the following call flows, the network configuration is the same as the network configuration outlined in the "SIP Gateway-to-SIP IP Phone Calls" section. However, instead of successfully establishing a call session, one of the following situations occurs:
Figure 17 illustrates an unsuccessful call in which User A initiates a call to User B but User B is on the phone and is unable or unwilling to take another call.
Figure 17: SIP Gateway-to-SIP IP PhoneCalled User is Busy
Step
| Action
| Description
|
1
| SetupPBX A to SIP Gateway1
| 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 UserB.
|
2
| INVITESIP Gateway 1 to SIP IP Phone
| SIP gateway 1 maps the SIP URL phone number to a dial-peer. The dial-peer includes the IP address and the port number of the SIP enabled entity to contact. SIP gateway 1 sends an INVITE request to the address it receives in the dial peer which, in this scenario, is the SIP IP phone.
In the INVITE request:
- The IP address of the SIP IP phone is inserted in the Request-URI field.
- PBX A is identified as the call session initiator in the From field.
- A unique numeric identifier is assigned to the call and is inserted in the Call-ID field.
- The transaction number within a single call leg is identified in the CSeq field.
- The media capability User A is ready to receive is specified.
- The port on which the SIP gateway is prepared to receive the RTP data is specified.
|
3
| Call ProceedingSIP Gateway1 to PBX A
| SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
|
4
| 100 TryingSIP IP Phone to SIP Gateway 1
| The SIP IP phone sends a 100 Trying response to SIP gateway 1. The 100 Trying response indicates that the INVITE request has been received by the SIP IP phone.
|
5
| 486 Busy HereSIP IP Phone to SIP Gateway 1
| The SIP IP phone sends a 486 Busy Here response to SIP gateway 1. The 486 Busy Here response is a client error response that indicates that User B was successfully contacted but User B was not willing or was unable to take the call.
|
6
| Disconnect (Busy)SIP Gateway 1 to PBX A
| SIP gateway 1 sends a Disconnect message to PBX A.
|
7
| ReleasePBX A to SIP Gateway 1
| PBX A sends a Release message to SIP gateway 1.
|
8
| ACKSIP Gateway 1 to SIP IP Phone
| SIP gateway 1 sends an ACK to the SIP IP phone. The ACK confirms that User A has received the 486 Busy Here response. The call session attempt is now being terminated.
|
9
| Release CompleteSIP Gateway 1 to PBX A
| SIP gateway 1 sends a Release Complete message to PBX A and the call session attempt is terminated.
|
Figure 18 illustrates the call flow in which User A initiates a call to User B but User B does not answer.
Figure 18: SIP Gateway-to-SIP IP PhoneCalled User Does Not Answer
Step
| Action
| Description
|
1
| SetupPBX A to SIP Gateway1
| 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
| INVITESIP Gateway 1 to SIP IP Phone
| SIP gateway 1 maps the SIP URL phone number to a dial-peer. The dial-peer includes the IP address and the port number of the SIP enabled entity to contact. SIP gateway 1 sends an INVITE request to the address it receives in the dial peer which, in this scenario, is the SIP IP phone.
In the INVITE request:
- The IP address of the SIP IP phone is inserted in the Request-URI field.
- PBX A is identified as the call session initiator in the From field.
- A unique numeric identifier is assigned to the call and is inserted in the Call-ID field.
- The transaction number within a single call leg is identified in the CSeq field.
- The media capability User A is ready to receive is specified.
- The port on which the SIP gateway is prepared to receive the RTP data is specified.
|
3
| Call ProceedingSIP Gateway1 to PBX A
| SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
|
4
| 100 TryingSIP IP Phone to SIP Gateway 1
| The SIP IP phone sends a 100 Trying response to SIP gateway 1. The 100 Trying response indicates that the INVITE request has been received by the SIP IP phone.
|
5
| 180 RingingSIP IP Phone to SIP Gateway 1
| The SIP IP phone sends a 180 Ringing response to SIP gateway 1. The 180Ringing response indicates that the user is being alerted.
|
6
| AlertingSIP Gateway 1 to PBX A
| SIP gateway 1 sends an Alert message to PBX A. The Alert message indicates that SIP gateway 1 has received a 180 Ringing response from the SIP IP phone. User A hears the ringback tone that indicates that User B is being alerted.
|
7
| CANCEL (Ring Timeout)SIP Gateway 1 to SIP IP Phone
| Because SIP gateway 1 did not return an appropriate response within the time specified by the Expires header in the INVITE request, SIP gateway 1 sends a SIP CANCEL request to SIP gateway 2. A CANCEL request cancels a pending request with the same Call-ID, To, From, and CSeq header field values.
|
8
| DisconnectSIP Gateway 1 to PBX A
| SIP gateway 1 sends a Disconnect message to PBX A.
|
9
| Release CompleteSIP Gateway 1 to PBX A
| SIP gateway 1 sends a Release Complete message to PBX A and the call session attempt is terminated.
|
10
| 200 OKSIP IP Phone to SIP Gateway 1
| The SIP IP phone sends a 200 OK response to SIP gateway 1. The 200 OK response confirms that User A has received the Cancel request. The call session attempt is now being terminated.
|
11
| Release CompleteSIP Gateway 1 to PBX A
| SIP gateway 1 sends a Release Complete message to PBX A and the call session is terminated.
|
Figure 19 illustrates an unsuccessful call in which User A initiates a call to User B and receives a class 4xx, 5xx, or 6xx response.
Figure 19: SIP Gateway-to-SIP IP PhoneClient, Server, or Global Error
Step
| Action
| Description
|
1
| SetupPBX A to SIP Gateway1
| 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 UserB.
|
2
| INVITESIP Gateway 1 to SIP IP Phone
| SIP gateway 1 maps the SIP URL phone number to a dial-peer. The dial-peer includes the IP address and the port number of the SIP enabled entity to contact. SIP gateway 1 sends an INVITE request to the address it receives in the dial peer which, in this scenario, is the SIP IP phone.
In the INVITE request:
- The IP address of the SIP IP phone is inserted in the Request-URI field.
- PBX A is identified as the call session initiator in the From field.
- A unique numeric identifier is assigned to the call and is inserted in the Call-ID field.
- The transaction number within a single call leg is identified in the CSeq field.
- The media capability User A is ready to receive is specified.
- The port on which the SIP gateway is prepared to receive the RTP data is specified.
|
3
| Call ProceedingSIP Gateway1 to PBX A
| SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the Call Setup request.
|
4
| 100 TryingSIP IP Phone to SIP Gateway 1
| The SIP IP phone sends a 100 Trying response to SIP gateway 1. The 100 Trying response indicates that the INVITE request has been received by the SIP IP phone.
|
5
| 4xx/5xx/6xx FailureSIP IP Phone to SIP Gateway 1
| The SIP IP phone sends a class 4xx, 5xx, or class 6xx failure response to SIP gateway1. Depending on which class the failure response is, the call actions differ.
If the SIP IP phone sends a class 4xx failure response (a definite failure response that is a client error), the request will not be retried without modification.
If the SIP IP phone sends a class 5xx failure response (an indefinite failure that is a server error), the request is not terminated but rather other possible locations are tried.
If the SIP IP phone sends a class 6xx failure response (a global error), the search for User B is terminated because the 6xx response indicates that a server has definite information about User B, but not for the particular instance indicated in the Request-URI field. Therefore, all further searches for this user will fail.
|
6
| DisconnectSIP Gateway 1 to PBX A
| SIP gateway 1 sends a Release message to PBX A.
|
7
| ReleasePBX A to SIP Gateway 1
| PBX A sends a Release message to SIP gateway 1.
|
8
| ACKSIP Gateway 1 to SIP IP Phone
| SIP gateway 1 sends an ACK to the SIP IP phone. The ACK confirms that UserA has received the 4xx/5xx/6xx failure response. The call session attempt is now being terminated.
|
9
| Release CompleteSIP Gateway 1 to PBX A
| SIP gateway 1 sends a Release Complete message to PBX A and the call session attempt is terminated.
|
This section describes how the Cisco SIP User Agent and the Cisco SIP Gateway comply with the IETF definition of SIP as described in RFC 2543.
This section contains compliance information on the following:
Function
| Supported?
|
User Agent Client (UAC)
| Yes
|
User Agent Server (UAS)
| Yes
|
Proxy Server
| The SIP gateway does not have the proxy or redirect server functionality, but can work with an external third-party proxy or redirect server.
|
Redirect Server
|
There are six methods used by the SIP gateway.
Method
| Supported?
| Comments
|
INVITE
| Yes
| The gateway supports mid-call INVITEs with the same call ID but different SDP session parameters (to change the transport address).
|
ACK
| Yes
|
|
OPTIONS
| Yes
| The gateway does not generate OPTIONS. However, it will respond to OPTIONS requests.
|
BYE
| Yes
|
|
CANCEL
| Yes
|
|
REGISTER
| No
| In SIP, there is no requirement for a SIP gateway to register using this method. Therefore, the gateway does not generate or process this method.
|
Cisco IOS Release 12.1(3)T supports the following SIP Responses:
1xx Response
| Comments
|
100 Trying
This response indicates that action is being taken on behalf of the caller, but that the callee has not yet been located.
| The SIP gateway generates this response for an incoming INVITE.
Upon receiving this response, the gateway stops retransmitting INVITEs. It then waits for a 180 Ringing or 200 OK response.
|
180 Ringing
This response indicates that the callee has been located and is being notified of the call.
| The SIP gateway generates a 180 Ringing response when the called party has been located and is being alerted.
Upon receiving this response, the gateway waits for a 200 OK response.
|
181 Call is being forwarded
This response indicates that the call is being rerouted to another destination.
| The SIP gateway does not generate this response.
Upon receiving this response, the gateway processes the responses the same way that it processes a 100 Trying response.
|
182 Queued
This response indicates that the callee is not currently available but that they have elected to queue the call rather than rejectit.
|
183 Session progress
This response is used to perform inband alerting for the caller.
| The SIP gateway generates a 183 Session progress response when it receives an ISDN Progress message from a PSTN.
|
2xx Response
| Comments
|
200 OK
This response indicates that the request has been successfully processed. The action taken depends on the request made.
| The SIP gateway generates this response when the PBX indicates that the user has answered the phone.
Upon receiving this response, the gateway forwards the response to the corresponding party and responds with an ACK.
|
3xx Response
| Comments
|
300 Multiple choices
This response indicates that the address resolved to more than one location. All locations are provided and the user or UA is allowed to select which location to use.
| The SIP gateway does not generate this response. Upon receiving this response, the gateway contacts the new address in the Contact header field.
|
301 Moved permanently
This response indicates that the user is no longer available at the specified location. An alternate location is included in the header.
|
302 Moved temporarily
This response indicates that the user is temporarily unavailable at the specified location. An alternate location is included in the header.
|
305 Use proxy
This response indicates that the caller must use a proxy to contact the callee.
|
380 Alternative service
This response indicates that the call was unsuccessful, but that alternative services are available.
|
4xx Response
| Comments
|
400 Bad Request
This response indicates that the request could not be understood because of an illegal format.
| The SIP gateway generates a 400 Bad Request response for a badly formed request.
Upon receiving this response, the gateway initiates a graceful call disconnect and clears the call.
|
401 Unauthorized
This response indicates that the request requires user authentication.
| The SIP gateway does not generate this response.
Upon receiving this response, the gateway initiates a graceful call disconnect and clears the call.
|
402 Payment required
This response indicates that payment is required to complete the call.
|
403 Forbidden
This response indicates that the server has received and understood the request but will not provide the service.
|
404 Not Found
This response indicates that the server has definite information that the user does not exist in the specified domain.
| The SIP gateway generates this response if it is unable to locate the callee.
Upon receiving this response, the gateway initiates a graceful call disconnect and clears the call.
|
405 Method Not Allowed
This response indicates that the method specified in the request is not allowed. The response contains a list of allowed methods.
| The SIP gateway generates this response if an invalid method is specified in the request.
Upon receiving this response, the gateway initiates a graceful call disconnect and clears the call.
|
406 Not Acceptable
This response indicates that the requested resource is capable of generating only responses that have content characteristics not acceptable as specified in the accept header of the request.
| The SIP gateway does not generate this response.
Upon receiving this response, the gateway initiates a graceful call disconnect and clears the call.
|
407 Proxy authentication required
This response is similar to the 401 Unauthorized response. However, this response indicates that the client must first authenticate itself with the proxy.
| The SIP gateway does not generate this response.
Upon receiving this response, the gateway initiates a graceful call disconnect and clears the call.
|
408 Request timeout
This response indicates that the server could not produce a response before the Expires time out.
|
409 Conflict
This response indicates that the request could not be processed because of a conflict with the current state of the resource.
|
410 Gone
This response indicates that a resource is no longer available at the server and no forwarding address is known.
| The SIP gateway generates this response if the PSTN returns a cause code of unallocated number.
Upon receiving this response, the gateway initiates a graceful call disconnect and clears the call.
|
411 Length required
This response indicates that the user refuses to accept the request without a defined content length.
| The SIP gateway does not generate this response.
Upon receiving this response, the gateway initiates a graceful call disconnect and clears the call.
|
413 Request entity too large
This response indicates that server refuses to process the request because it is larger than the server is willing or able to process.
|
414 Request-URI too long
This response indicates that the server refuses to process the request because the Request-URI is too long for the server to interpret.
|
415 Unsupported media
This response indicates that the server refuses to process the request because the format of the body is not supported by the destination endpoint.
|
420 Bad extension
This response indicates that the server could not understand the protocol extension indicated in the Require header.
| The SIP gateway generates this response if it cannot understand the service requested in the Require header field.
Upon receiving this response, the gateway initiates a graceful call disconnect and clears the call.
|
480 Temporarily unavailable
This response indicates that the callee was contacted but is temporarily unavailable.
| The SIP gateway generates this response if the callee is unavailable (for example, the callee does not answer the phone within a certain amount of time or the called number does not exist or is no longer in service).
Upon receiving this response, the gateway initiates a graceful call disconnect and clears the call.
|
481 Call leg/transaction does not exist
This response indicates that the server is ignoring the request because it was either a BYE for which there was no matching legID or a CANCEL for which there was no matching transaction.
| The SIP gateway generates this response if the call leg ID or transaction cannot be identified.
Upon receiving this response, the gateway initiates a graceful call disconnect and clears the call.
|
482 Loop detected
This response indicates that the server received a request that included itself in the path.
| The SIP gateway does not generate this response.
Upon receiving this response, the gateway initiates a graceful call disconnect and clears the call.
|
483 Too many hops
This response indicates that the server received a request that required more hops than allowed by the Max-Forwards header.
|
484 Address incomplete
This response indicates that the server received a request containing an incomplete address.
|
485 Ambiguous
This response indicates that the server received a request in which the callee address was ambiguous. It can provide possible alternate addresses.
|
486 Busy here
This response indicates that the callee was contacted but that their system is unable to take additional calls.
| The SIP gateway generates this response if it the callee was contacted but was busy.
Upon receiving this response, the gateway initiates a graceful call disconnect and clears the call.
|
5xx Response
| Comments
|
500 Server internal error
This response indicates that the server or gateway encountered an unexpected error that prevented it from processing the request.
| The SIP gateway generates this response if it encountered an unexpected error that prevented it from processing the request.
Upon receiving this response, the gateway initiates a graceful call disconnect and clears the call.
|
501 Not implemented
This response indicates that the server or gateway does not support the functions required to complete the request.
|
502 Bad gateway
This response indicates that the server or gateway received an invalid response from a downstream server.
|
503 Service unavailable
This response indicates that the server or gateway is unable to process the request due to an overload or maintenance problem.
|
504 Gateway timeout
This response indicates that the server or gateway did not receive a timely response from another server (such as a location server).
|
505 Version not supported
This response indicates that the server or gateway does not support the version of the SIP protocol used in the request.
|
6xx Response
| Comments
|
600 Busy everywhere
This response indicates that the callee was contacted but that the callee is busy and cannot take the call at this time.
| The SIP gateway does not generate this response.
Upon receiving this response, the gateway initiates a graceful call disconnect and clears the call.
|
603 Decline
This response indicates that the callee was contacted but cannot or does not want to participate in the call.
|
604 Does not exist anywhere
This response indicates that the server has authoritative information that the callee does not exist in the network.
|
606 Not acceptable
This response indicates that the callee was contacted, but that some aspect of the session description was unacceptable.
| The SIP gateway generates this response if some aspect of the session description is unacceptable to the callee.
Upon receiving this response, the gateway initiates a graceful call disconnect and clears the call.
|
Header Field
| Supported?
|
Accept
| Yes
|
Accept-Encoding
| No
|
Accept-Language
| No
|
Allow
| Yes
|
Authorization
| No
|
Call-ID
| Yes
|
Contact
| Yes
|
Content-Encoding
| No
|
Content-Length
| Yes
|
Content-Type
| Yes
|
Cseq
| Yes
|
Date
| Yes
|
Encryption
| No
|
Expires
| Yes
|
From
| Yes
|
Hide
| No
|
Max-Forwards
| Yes
|
Organization
| No
|
Priority
| No
|
Proxy-Authenticate
| No
|
Proxy Authorization
| No
|
Proxy-Require
| No
|
Record-Route
| Yes
|
Require
| Yes
|
Response-Key
| No
|
Retry-After
| No
|
Route
| Yes
|
Server
| No
|
Subject
| No
|
Timestamp
| Yes
|
To
| Yes
|
Unsupported
| No
|
User-Agent
| Yes
|
Via
| Yes
|
Warning
| Yes
|
WWW-Authenticate
| No
|
Transport Layer Protocol
| Supported?
| Comments
|
Unicast UDP
| Yes
| None.
|
Multicast UDP
| No
| There are two applications for Multicast UDP.
The first application is multicast registration. Because gateways do not register in the SIP environment, the multicast registration is not needed.
The second application is multicast RTP session which is for future use and is not a requirement in Cisco IOS Release 12.1(3)T.
|
TCP
| Yes
| None.
|
Encryption Mode
| Supported?
| Comments
|
End-to-end Encryption
| No
| IPSEC can be used for security.
|
Privacy of SIP Responses
| No
| None.
|
Hop-by-Hope Encryption
| No
| IPSEC can be used for security.
|
Via Field Encryption
| No
|
Encryption Mode
| No
|
Basic Authentication
| No
|
Digest Authentication
| No
|
Proxy Authentication
| No
|
PGP
| No
|
SDP Headers
| Supported?
|
vProtocol version
| Yes
|
oOwner/creator and session identifier
| Yes
|
aSession name
| No
|
cConnection information
| Yes
|
mMedia name and transport address
| Yes
|
DNS Resource Record Type
| Supported?
|
Type A
| Yes
|
Type SRV
| Yes
|
Cisco Connection Online (CCO) is Cisco Systems' primary, real-time support channel. Maintenance customers and partners can self-register on CCO to obtain additional information and services.
Available 24 hours a day, 7 days a week, CCO provides a wealth of standard and value-added services to Cisco's customers and business partners. CCO services include product information, product documentation, software updates, release notes, technical tips, the Bug Navigator, configuration notes, brochures, descriptions of service offerings, and download access to public and authorized files.
CCO serves a wide variety of users through two interfaces that are updated and enhanced simultaneously: a character-based version and a multimedia version that resides on the World Wide Web (WWW). The character-based CCO supports Zmodem, Kermit, Xmodem, FTP, and Internet e-mail, and it is excellent for quick access to information over lower bandwidths. The WWW version of CCO provides richly formatted documents with photographs, figures, graphics, and video, as well as hyperlinks to related information.
You can access CCO in the following ways:
For a copy of CCO's Frequently Asked Questions (FAQ), contact cco-help@cisco.com. For additional information, contact cco-team@cisco.com.
 |
Note If you are a network administrator and need personal technical assistance with a Cisco product that is under warranty or covered by a maintenance contract, contact Cisco's Technical Assistance Center (TAC) at 800 553-2447, 408 526-7209, or tac@cisco.com. To obtain general information about Cisco Systems, Cisco products, or upgrades, contact 800 553-6387, 408 526-7208, or cs-rep@cisco.com. |
Cisco documentation and additional literature are available in a CD-ROM package, which ships with your product. The Documentation CD-ROM, a member of the Cisco Connection Family, is updated monthly. Therefore, it might be more current than printed documentation. To order additional copies of the Documentation CD-ROM, contact your local sales representative or call customer service. The CD-ROM package is available as a single package or as an annual subscription. You can also access Cisco documentation on the World Wide Web at http://www.cisco.com, http://www-china.cisco.com, or http://www-europe.cisco.com.
If you are reading Cisco product documentation on the World Wide Web, you can submit comments electronically. Click Feedback in the toolbar and select Documentation. After you complete the form, click Submit to send it to Cisco. We appreciate your comments.








Posted: Tue Sep 19 17:37:44 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.