Cisco SIP Proxy Server Version 2.1 Administrator Guide - F. Call-Flow Scenarios [Cisco SIP Proxy Server]

Table Of Contents

SIP Call-Flow Scenarios

SIP Messages

Message Types

SIP URLs

Registration and Invitation Processes

Call-Flow Scenarios for Successful Calls

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

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

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

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

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

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

Call-Flow Scenarios for Failed Calls

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

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

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

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

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

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

SIP Phone-to-SIP/H.323 Gateway—Call via SIP Proxy Server with Record-Route Disabled

SIP Phone-to-SIP/H.323 Gateway—Call via SIP Proxy Server with Record-Route Enabled

SIP Phone to SIP/H.323 Gateway—Call via SIP Redirect Server

SIP Phone-to-SIP/H.323 Gateway—Call via SIP Proxy Server with Record-Route Disabled (Call Failed with a 503 Service Unavailable Response)

SIP Call-Flow Scenarios

This appendix describes the types of Session Initiation Protocol (SIP) messages used by the Cisco SIP proxy server (Cisco SPS) and the flow of these messages during various call scenarios. It contains the following sections:

•SIP Messages

•Call-Flow Scenarios for Successful Calls

•Call-Flow Scenarios for Failed Calls

For more troubleshooting information, see "Troubleshooting."

SIP Messages

Message Types

All SIP messages are either requests from a server or client or responses to a request (see Table F-1).

Table F-1 SIP Message Types

Type

Message

Action or Indication

Request

INVITE

Invites a user or service to participate in a call session

ACK

Confirms that the client has received a final response to an INVITE request

BYE

Terminates a call and can be sent by either the caller or the called party

CANCEL

Cancels any pending searches but does not terminate a call that has already been accepted

OPTIONS

Queries the capabilities of servers

REGISTER

Registers the address listed in the To header field with a SIP server

Response

SIP 1xx

Informational

SIP 2xx

Successful

SIP 3xx

Redirection

SIP 4xx

Client failure

SIP 5xx

Server failure

SIP 6xx

Global failure

Messages are formatted according to RFC 822, Standard for the Format of ARPA Internet Text Messages. The general format for all messages is as follows:

•A start line

•One or more header fields

•An empty line

•An optional message body

•An ending carriage return-line feed (CRLF)

SIP URLs

The SIP URL in a message identifies the address of a user and takes a form similar to an e-mail address:
user@host
where user is the telephone number and host is either a domain name or a numeric network address.

For example, the Request-URI field in an INVITE request to a user appears as follows:
INVITE sip:555-0002@company.com; user=phone
The user=phone parameter indicates that the Request-URI address is a telephone number rather than a username.

Registration and Invitation Processes

SIP messages facilitate two types of process: registration and invitation.

Registration occurs when a client informs a proxy or redirect server of its location. The client sends a REGISTER request to the proxy or redirect server and includes the addresses at which it can be reached.

Invitation occurs when one SIP endpoint (user A) invites another SIP endpoint (user B) to join in a call. This process occurs as follows:

1. User A sends an INVITE message requesting that user B join a particular conference or establish a two-party conversation.

2. If user B wants to join the call, it sends an affirmative response (SIP 2xx). If not, it sends a failure response (SIP 4xx).

3. If user A still wants to establish the conference, it acknowledges the response with an ACK message. If not, it sends a BYE message.

Call-Flow Scenarios for Successful Calls

This section describes call flows for the following successful-call scenarios:

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

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

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

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

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

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

Note The messages shown are examples for reference only.

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

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

The call flow scenario is as follows:

1. User A calls user B via SIP gateway 1 using a SIP redirect server.

2. User B answers the call.

3. User B hangs up.

Figure F-1 SIP Gateway-to-SIP Gateway—Call via SIP Redirect Server

Action

Description

Step 1

Setup—PBX A to SIP gateway 1

Call setup is initiated between PBX A and SIP gateway 1. Setup includes the standard transactions that take place as user A attempts to call user B.

Step 2

INVITE—SIP gateway 1 to SIP redirect server

SIP gateway 1 sends an INVITE request to the SIP redirect server. The request is an invitation to user B to participate in a call session. The following applies:

•The phone number of user B is inserted in the Request-URI field in the form of a SIP URL.

•PBX A is identified as the call-session initiator in the From field.

•A unique numeric identifier is assigned to the call and inserted in the Call-ID field.

•The transaction number within a single call leg is identified in the CSeq field.

•The media capability of user A is specified.

•The port on which SIP gateway 1 is prepared to receive RTP data is specified.

Step 3

300 Multiple Choice—SIP redirect server to SIP gateway 1

The SIP redirect server sends a 300 Multiple Choice response to SIP gateway 1. The 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.

Step 4

ACK—SIP gateway 1 to SIP redirect server

SIP gateway 1 acknowledges the 300 Multiple Choice response with an ACK.

Step 5

INVITE—SIP gateway 1 to SIP gateway 2

SIP gateway 1 sends a new INVITE request to SIP gateway 2. The new INVITE request includes the first contact listed in the 300 Multiple Choice response as the new address for user B, a higher transaction number in the CSeq field, and the same Call-ID as the first INVITE request.

Step 6

Setup—SIP gateway 2 to PBX B

SIP gateway 2 receives the INVITE request from SIP gateway 1 and initiates a call setup with user B via PBX B.

Step 7

Call Proceeding—SIP gateway 1 to PBX A

SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the call-setup request.

Step 8

100 Trying—SIP gateway 2 to SIP gateway 1

SIP gateway 2 sends a 100 Trying response to the INVITE request sent by SIP gateway 1. The response indicates that the INVITE request was received by SIP gateway 2, but that user B is not yet located.

Step 9

Call Proceeding—PBX B to SIP gateway 2

PBX B sends a Call Proceeding message to SIP gateway 2 to acknowledge the call-setup request.

Step 10

Alerting—PBX B to SIP gateway 2

PBX B locates user B and sends an Alert message to SIP gateway 2. User B's phone begins to ring.

Step 11

180 Ringing—SIP gateway 2 to SIP gateway 1

SIP gateway 2 sends a 180 Ringing response to SIP gateway 1. The response indicates that SIP gateway 2 has located, and is trying to alert user B.

Step 12

Alerting—SIP gateway 1 to PBX A

SIP gateway 1 sends an Alert message to PBX A. User A hears ringback tone.

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

Step 13

Connect—PBX B to SIP gateway 2

User B answers phone. PBX B sends a Connect message to SIP gateway 2. The message notifies SIP gateway 2 that the connection has been made.

Step 14

200 OK—SIP gateway 2 to SIP gateway 1

SIP gateway 2 sends a 200 OK response to SIP gateway 1. The 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 returns a 400 Bad Request response with a 304 Warning header field.

Step 15

Connect—SIP gateway 1 to PBX A

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

Step 16

Connect ACK—PBX A to SIP gateway 1

PBX A acknowledges SIP gateway 1's Connect message.

Step 17

ACK—SIP gateway 1 to SIP gateway 2

SIP gateway 1 sends an ACK to SIP gateway 2. The ACK confirms that the 200 OK response has been received.

The call is now in progress over a two-way voice path via RTP.

Step 18

Connect ACK—SIP gateway 2 to PBX B

SIP gateway 2 acknowledges PBX B's Connect message.

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

Step 19

Disconnect—PBX B to SIP gateway 2

Once user B hangs up, PBX B sends a Disconnect message to SIP gateway 2. The Disconnect message starts the call session termination process.

Step 20

BYE—SIP gateway 2 to SIP gateway 1

SIP gateway 2 sends a BYE request to SIP gateway 1. The 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.

Step 21

Disconnect—SIP gateway 1 to PBX A

SIP gateway 1 sends a Disconnect message to PBX A.

Step 22

Release—SIP gateway 2 to PBX B

SIP gateway 2 sends a Release message to PBX B.

Step 23

Release—PBX A to SIP gateway 1

PBX A sends a Release message to SIP gateway 1.

Step 24

200 OK—SIP gateway 1 to SIP gateway 2

SIP gateway 1 sends a 200 OK response to SIP gateway 2. The response notifies SIP gateway 2 that SIP gateway 1 has received the BYE request.

Step 25

Release Complete—PBX B to SIP gateway 2

PBX B sends a Release Complete message to SIP gateway 2.

Step 26

Release Complete—SIP gateway 1 to PBX A

SIP gateway 1 sends a Release Complete message to PBX A and the session is terminated.

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

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

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

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

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

The call flow is as follows:

1. User A calls user B via SIP gateway 1 using a proxy server.

2. User B answers the call.

3. User B hangs up.

Figure F-2 SIP Gateway-to-SIP Gateway—Call via SIP Proxy Server with Record Route Enabled

Action

Description

Step 1

Setup—PBX A to SIP gateway 1

Call setup is initiated between PBX A and SIP gateway 1. Setup includes the standard transactions that take place as user A attempts to call user B.

Step 2

INVITE—SIP gateway 1 to proxy server

SIP gateway 1 sends an INVITE request to the SIP proxy server. The request is an invitation to user B to participate in a call session. The following applies:

•The phone number of user B is inserted in the Request-URI field in the form of a SIP URL.

•PBX A is identified as the call-session initiator in the From field.

•A unique numeric identifier is assigned to the call and inserted in the Call-ID field.

•The transaction number within a single call leg is identified in the CSeq field.

•The media capability of user A is specified.

•The port on which SIP gateway 1 is prepared to receive RTP data is specified.

Step 3

Call Proceeding—SIP gateway 1 to PBX A

SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the call-setup request.

Step 4

INVITE—SIP proxy server to SIP gateway 2

SIP proxy server checks whether its own address is contained in the Via field (to prevent loops), directly copies the To, From, Call-ID, and Contact fields from the request it received from SIP gateway 1, changes the Request-URI to indicate the server to which it intends to send the INVITE request, and sends a new INVITE request to SIP gateway 2.

Step 5

100 Trying—SIP proxy server to SIP gateway 1

SIP proxy server sends a 100 Trying response to SIP gateway 1.

Step 6

Setup—SIP gateway 2 to PBX B

SIP gateway 2 receives the INVITE request from the SIP proxy server and initiates call setup with user B via PBX B.

Step 7

100 Trying—SIP gateway 2 to SIP proxy server

SIP gateway 2 sends a 100 Trying response to the SIP proxy server. SIP proxy server might or might not forward the 100 Trying response to SIP gateway 1.

Step 8

Call Proceeding—PBX B to SIP gateway 2

PBX B sends a Call Proceeding message to SIP gateway 2 to acknowledge the call-setup request.

Step 9

Alerting—PBX B to SIP gateway 2

PBX B locates user B and sends an Alert message to SIP gateway 2. User B's phone begins to ring.

Step 10

180 Ringing—SIP gateway 2 to SIP proxy server

SIP gateway 2 sends a 180 Ringing response to the SIP proxy server.

Step 11

180 Ringing—SIP proxy server to SIP gateway 1

SIP proxy server forwards the 180 Ringing response to SIP gateway 1.

Step 12

Alerting—SIP gateway 1 to PBX A

SIP gateway 1 sends an Alert message to user A via PBX A. The 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.

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

Step 13

Connect—PBX B to SIP gateway 2

User B answers the phone. PBX B sends a Connect message to SIP gateway 2. The message notifies SIP gateway 2 that the connection has been made.

Step 14

200 OK—SIP gateway 2 to SIP proxy server

SIP gateway 2 sends a 200 OK response (including the Record-Route header received in the INVITE) to the SIP proxy server. The 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 returns a 400 Bad Request response with a 304 Warning header field.

SIP proxy server must forward 200 OK responses upstream.

Step 15

200 OK—SIP proxy server to SIP gateway 1

SIP proxy server forwards the 200 OK response that it received from SIP gateway 2 to SIP gateway 1. In the 200 OK response, the SIP proxy server forwards the Record-Route header to ensure that it is in the path of subsequent SIP requests for the same call leg. In the Record-Route field, the SIP proxy server adds its Request-URI.

Step 16

Connect—SIP gateway 1 to PBX A

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

Step 17

Connect ACK—PBX A to SIP gateway 1

PBX A acknowledges SIP gateway 1's Connect message.

Step 18

ACK—SIP gateway 1 to SIP proxy server

SIP gateway 1 sends an ACK to the SIP proxy server. The ACK confirms that SIP gateway 1 has received the 200 OK response from the SIP proxy server.

Step 19

ACK—SIP proxy server to SIP gateway 2

Depending on the values in the To, From, CSeq, and Call-ID field, the SIP proxy server might process the ACK locally or proxy it. If the fields in the ACK match those in previous requests processed by the SIP proxy server, the server proxies the ACK. If there is no match, the ACK is proxied as if it were an INVITE request.

SIP proxy server forwards SIP gateway 1's ACK response to SIP gateway 2.

Step 20

Connect ACK—SIP gateway 2 to PBX B

SIP gateway 2 acknowledges PBX B's Connect message. The call session is now active.

The two-way voice path is established directly between SIP gateway 1 and SIP gateway 2; not via the SIP proxy server.

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

Step 21

Disconnect—PBX B to SIP gateway 2

After the call is completed, PBX B sends a Disconnect message to SIP gateway 2. The Disconnect message starts the call session termination process.

Step 22

BYE—SIP gateway 2 to SIP proxy server

SIP gateway 2 sends a BYE request to the SIP proxy server. The 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.

Step 23

BYE—SIP proxy server to SIP gateway 1

SIP proxy server forwards the BYE request to SIP gateway 1.

Step 24

Disconnect—SIP gateway 1 to PBX A

SIP gateway 1 sends a Disconnect message to PBX A.

Step 25

Release—SIP gateway 2 to PBX B

After the call is completed, SIP gateway 2 sends a Release message to PBX B.

Step 26

Release—PBX A to SIP gateway 1

PBX A sends a Release message to SIP gateway 1.

Step 27

200 OK—SIP gateway 1 to SIP proxy server

SIP gateway 1 sends a 200 OK response to the SIP proxy server. The response notifies SIP gateway 2 that SIP gateway 1 has received the BYE request.

Step 28

200 OK—SIP proxy server to SIP gateway 2

SIP proxy server forwards the 200 OK response to SIP gateway 2.

Step 29

Release Complete—PBX B to SIP gateway 2

PBX B sends a Release Complete message to SIP gateway 2.

Step 30

Release Complete—SIP gateway 1 to PBX A

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

Figure F-3 SIP Gateway-to-SIP Gateway—Call via a Proxy Server with Record Route Disabled

Action

Description

Step 1

Setup—PBX A to SIP gateway 1

Call setup is initiated between PBX A and SIP gateway 1. Setup includes the standard transactions that take place as user A attempts to call user B.

Step 2

INVITE—SIP gateway 1 to SIP proxy server

SIP gateway 1 sends an INVITE request to the SIP proxy server. The request is an invitation to user B to participate in a call session. The following applies:

•The phone number of user B is inserted in the Request-URI field in the form of a SIP URL.

•PBX A is identified as the call-session initiator in the From field.

•A unique numeric identifier is assigned to the call and inserted in the Call-ID field.

•The transaction number within a single call leg is identified in the CSeq field.

•The media capability that A is ready to receive is specified.

•The port on which SIP gateway 1 is prepared to receive RTP data is specified.

Step 3

Call Proceeding—SIP gateway 1 to PBX A

SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the call-setup request.

Step 4

INVITE—SIP proxy server to SIP gateway 2

SIP proxy server checks whether its own address is contained in the Via field (to prevent loops), directly copies the To, From, Call-ID, and Contact fields from the request it received from SIP gateway 1, changes the Request-URI to indicate the server to which it intends to send the INVITE request, and sends a new INVITE request to SIP gateway 2.

Step 5

100 Trying—SIP proxy server to SIP gateway 1

SIP proxy server sends a 100 Trying response to SIP gateway 1.

Step 6

Setup—SIP gateway 2 to PBX B

SIP gateway 2 receives the INVITE request from the SIP proxy server and initiates call setup with user B via PBX B.

Step 7

100 Trying—SIP gateway 2 to SIP proxy server

SIP gateway 2 sends a 100 Trying response to the SIP proxy server. SIP proxy server might or might not forward the 100 Trying response to SIP gateway 1.

Step 8

Call Proceeding—PBX B to SIP gateway 2

PBX B sends a Call Proceeding message to SIP gateway 2 to acknowledge the call-setup request.

Step 9

Alerting—PBX B to SIP gateway 2

PBX B locates user B and sends an Alert message to SIP gateway 2. User B's phone begins to ring.

Step 10

180 Ringing—SIP gateway 2 to SIP proxy server

SIP gateway 2 sends a 180 Ringing response to the SIP proxy server.

Step 11

180 Ringing—SIP proxy server to SIP gateway 1

SIP proxy server forwards the 180 Ringing response to SIP gateway 1.

Step 12

Alerting—SIP gateway 1 to PBX A

SIP gateway 1 sends an Alert message to user A via PBX A. The 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.

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

Step 13

Connect—PBX B to SIP gateway 2

User B answers the phone. PBX B sends a Connect message to SIP gateway 2. The message notifies SIP gateway 2 that the connection has been made.

Step 14

200 OK—SIP gateway 2 to SIP proxy server

SIP gateway 2 sends a 200 OK response to the SIP proxy server. The 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 returns a 400 Bad Request response with a 304 Warning header field.

SIP proxy server must forward 200 OK responses upstream.

Step 15

200 OK—SIP proxy server to SIP gateway 1

SIP proxy server forwards the 200 OK response that it received from SIP gateway 2 to SIP gateway 1.

Step 16

Connect—SIP gateway 1 to PBX A

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

Step 17

Connect ACK—PBX A to SIP gateway 1

PBX A acknowledges SIP gateway 1's Connect message.

Step 18

ACK—SIP gateway 1 to SIP gateway 2

SIP gateway 1 sends an ACK to SIP gateway 2. The ACK confirms that SIP gateway 1 has received the 200 OK response from the SIP proxy server.

Step 19

Connect ACK—SIP gateway 2 to PBX B

SIP gateway 2 acknowledges PBX B's Connect message. The call session is now active.

The two-way voice path is established directly between SIP gateway 1 and SIP gateway 2, and not via the SIP proxy server.

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

Step 20

Disconnect—PBX B to SIP gateway 2

After the call is completed, PBX B sends a Disconnect message to SIP gateway 2. The Disconnect message starts the call session termination process.

Step 21

BYE—SIP gateway 2 to SIP gateway 1

SIP gateway 2 sends a BYE request to SIP gateway 1. The 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.

Step 22

Disconnect—SIP gateway 1 to PBX A

SIP gateway 1 sends a Disconnect message to PBX A.

Step 23

Release—SIP gateway 2 to PBX B

After the call is completed, SIP gateway 2 sends a Release message to PBX B.

Step 24

Release—PBX A to SIP gateway 1

PBX A sends a Release message to SIP gateway 1.

Step 25

200 OK—SIP gateway 1 to SIP gateway 2

SIP gateway 1 sends a 200 OK response to SIP gateway 2. The response notifies SIP gateway 2 that SIP gateway 1 has received the BYE request.

Step 26

Release Complete—PBX B to SIP gateway 2

PBX B sends a Release Complete message to SIP gateway 2.

Step 27

Release Complete—SIP gateway 1 to PBX A

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

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

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

Figure F-4 SIP IP Phone-to-SIP IP Phone Call Forward Unconditionally Call Setup via Recursive Proxy

Action

Description

Step 1

INVITE—SIP IP phone A to SIP proxy server

Alice's phone A sends an INVITE request to the proxy server. The request is an invitation to Bob to participate in a call session. The following applies:

•Bob's phone number is inserted in the Request-URI field in the form of a SIP URL.

•Alice at phone A is identified as the call-session initiator in the From field.

•A unique numeric identifier is assigned to the call and inserted in the Call-ID field.

•The transaction number within a single call leg is identified in the CSeq field.

•The media capability of phone A is specified in the SDP.

•The port on which phone A is prepared to receive RTP data is specified in the SDP.

Step 2

INVITE—SIP proxy server to SIP IP phone C

SIP proxy server determines that Bob's calls have been configured to forward unconditionally to Carol at phone C. It sends an INVITE request to Carol at phone C, changes the Request-URI to divert the request to Carol at phone C, and adds a CC-Diversion header containing the Request-URI from the initial INVITE request and the reason for the diversion.

Step 3

180 Ringing—SIP IP phone C to SIP proxy server

Phone C sends a 180 Ringing response to the SIP proxy server.

Step 4

180 Ringing—SIP proxy server to SIP IP phone A

SIP proxy server forwards the 180 Ringing response to phone A.

Step 5

200 OK—SIP IP phone C to SIP proxy server

Phone C sends a 200 OK response to phone A. The response notifies phone A that Carol has answered the phone (for example, the handset went off-hook).

If phone C supports the media capability advertised in the INVITE message sent by the SIP proxy server, it advertises the intersection of its own and phone A's media capability in the 200 OK response. If phone C does not support the media capability advertised by phone A, it returns a 400 Bad Request response with a "Warning: 304 Codec negotiation failed" header field.

Step 6

ACK—SIP IP phone A to SIP IP phone C

Phone A sends an ACK to phone C. The ACK confirms that user A's phone has received the 200 OK response from user C's phone.

Note At this point, a two-way RTP channel is established between SIP IP phone A and SIP IP phone C.

Figure F-5 SIP IP Phone-to-SIP IP Phone Call Forward Unconditionally via Nonrecursive Proxy

Action

Description

Step 1

INVITE—SIP IP phone A to SIP proxy server

Alice's phone A sends an INVITE request to the proxy server. The request is an invitation to Bob to participate in a call session. The following applies:

•Bob's phone number is inserted in the Request-URI field in the form of a SIP URL.

•Alice at phone A is identified as the call-session initiator in the From field.

•A unique numeric identifier is assigned to the call and inserted in the Call-ID field.

•The transaction number within a single call leg is identified in the CSeq field.

•The media capability of phone A is specified in the SDP.

•The port on which phone A is prepared to receive RTP data is specified in the SDP.

Step 2

302 Moved Temporarily—SIP proxy server to SIP IP phone A

SIP proxy server determines that Bob's calls have been configured to forward unconditionally to Carol at phone C. It sends an 302 Moved Temporarily message to phone A. Carol at phone C is added as the Contact and a CC-Diversion header is added that contains the Request-URI from the initial INVITE and the reason for the diversion.

Step 3

INVITE—SIP IP phone A to SIP IP phone C

Phone A sends an INVITE request to Carol at phone C. The request contains a CC-Diversion header that contains the Request-URI from the initial INVITE request and the reason for the diversion.

Step 4

180 Ringing—SIP IP phone C to SIP proxy server

Phone C sends a 180 Ringing response to phone A.

Step 5

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

Phone C sends a 200 OK response to phone A. The response notifies phone A that Carol has answered the phone (for example, the handset went off-hook).

If phone C supports the media capability advertised in the INVITE message sent by the SIP proxy server, it advertises the intersection of its own and phone A's media capability in the 200 OK response. If phone C does not support the media capability advertised by phone A, it returns a 400 Bad Request response with a "Warning: 304 Codec negotiation failed" header field.

Step 6

ACK—SIP IP phone A to SIP IP phone C

Phone A sends an ACK to phone C. The ACK confirms that phone A has received the 200 OK response from phone C.

Note At this point, a two-way RTP channel is established between SIP IP phone A and SIP IP phone C.

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

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

Figure F-6 SIP IP Phone-to-SIP IP Phone Call Forward on Busy Call Setup via Recursive Proxy

Action

Description

Step 1

INVITE—SIP IP phone A to SIP proxy server

Alice's phone A sends an INVITE request to the proxy server. The request is an invitation to Bob to participate in a call session. The following applies:

•Bob's phone number is inserted in the Request-URI field in the form of a SIP URL.

•Alice at phone A is identified as the call-session initiator in the From field.

•A unique numeric identifier is assigned to the call and inserted in the Call-ID field.

•The transaction number within a single call leg is identified in the CSeq field.

•The media capability of phone A is specified in the SDP.

•The port on which phone A is prepared to receive RTP data is specified in the SDP.

Step 2

INVITE—SIP proxy server to SIP IP phone B

The proxy server forwards the INVITE request to Bob at phone B.

Step 3

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

Phone B sends a 486 Busy response to the SIP proxy server. The response indicates that Bob at phone B was successfully contacted but Bob was either unwilling or unable to take another call.

Step 4

INVITE—SIP proxy server to SIP IP phone C

SIP proxy server sends an INVITE request to Carol at phone C to which Bob's calls have been configured to forward on busy, changes the Request-URI to divert the request to Carol at phone C, and adds a CC-Diversion header containing the Request-URI from the initial INVITE request and the reason for the diversion.

Step 5

180 Ringing—SIP IP phone C to SIP proxy server

Phone C sends a 180 Ringing response to the SIP proxy server.

Step 6

180 Ringing—SIP proxy server to SIP IP phone A

SIP proxy server forwards the 180 Ringing response to phone A.

Step 7

200 OK—SIP IP phone C to SIP proxy server

Phone C sends a 200 OK response to phone A.

If phone C supports the media capability advertised in the INVITE message sent by the SIP proxy server, it advertises the intersection of its own and phone A's media capability in the 200 OK response. If phone C does not support the media capability advertised by phone A, it returns a 400 Bad Request response with a "Warning: 304 Codec negotiation failed" header field.

Step 8

200 OK—SIP proxy server to SIP IP phone A

SIP proxy server forwards the 200 OK response to phone A. The response notifies phone A that Carol has answered the phone (for example, the handset of went off-hook).

Step 9

ACK—SIP IP phone A to SIP IP phone C

Phone A sends an ACK to phone C. The ACK confirms that phone A has received the 200 OK response from phone C.

Note At this point, a two-way RTP channel is established between SIP IP phone A and SIP IP phone C.

Figure F-7 SIP IP Phone-to-SIP IP Phone Call Forward on Busy Call Setup via Nonrecursive Proxy

Action

Description

Step 1

INVITE—SIP IP phone A to SIP proxy server

Alice's phone A sends an INVITE request to the proxy server. The request is an invitation to Bob to participate in a call session. The following applies:

•Bob's phone number is inserted in the Request-URI field in the form of a SIP URL.

•Alice at phone A is identified as the call-session initiator in the From field.

•A unique numeric identifier is assigned to the call and inserted in the Call-ID field.

•The transaction number within a single call leg is identified in the CSeq field.

•The media capability of phone A is specified in the SDP.

•The port on which phone A is prepared to receive RTP data is specified in the SDP.

Step 2

INVITE—SIP proxy server to SIP IP phone B

SIP proxy server forwards the INVITE request to Bob at phone B.

Step 3

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

Phone B sends a 486 Busy response to the SIP proxy server. The response indicates that Bob at phone B was successfully contacted but was either unwilling or unable to take another call.

Step 4

302 Moved Temporarily—SIP proxy server to SIP IP phone A

SIP proxy server sends an 302 Moved Temporarily message to phone A. Carol at phone C is added as the Contact and a CC-Diversion header is added that contains the Request-URI from the initial INVITE and the reason for the diversion.

Step 5

INVITE—SIP proxy server to SIP IP phone C

SIP proxy server sends an INVITE request to Carol at phone C to which Bob's calls have been configured to forward on busy, changes the Request-URI to divert the request to Carol at phone C, and adds a CC-Diversion header containing the Request-URI from the initial INVITE request and the reason for the diversion.

Step 6

180 Ringing—SIP IP phone C to SIP IP phone A

Phone C sends a 180 Ringing response to phone A.

Step 7

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

Phone C sends a 200 OK response to phone A. The response notifies phone A that Carol has answered the phone (for example, the handset went off-hook).

If phone C supports the media capability advertised in the INVITE message sent by the SIP proxy server, it advertises the intersection of its own and phone A's media capability in the response. If phone C does not support the media capability advertised by phone A, it returns a 400 Bad Request response with a "Warning: 304 Codec negotiation failed" header field.

Step 8

ACK—SIP IP phone A to SIP IP phone C

Phone A sends an ACK to phone C. The ACK confirms that phone A has received the 200 OK response from phone C.

Note At this point, a two-way RTP channel is established between SIP IP phone A and SIP IP phone C.

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

Figure F-8 and Figure F-9 illustrate a successful SIP IP phone-to-SIP IP phone call forward when no answer via a SIP proxy. In these scenarios, the three end users are identified as user A, user B, and user C. User B's calls are configured to forward to user C when an response timeout occurs. Figure F-8 illustrates the call as processed by a recursive proxy and Figure F-9 illustrates the call as processed by a nonrecursive proxy.

Figure F-8 SIP IP Phone-to-SIP IP Phone Call Forward No Answer Call Setup via Recursive Proxy

Action

Description

Step 1

INVITE—SIP IP phone A to SIP proxy server

Alice's phone A sends an INVITE request to the proxy server. The request is an invitation to Bob to participate in a call session. The following applies:

•Bob's phone number is inserted in the Request-URI field in the form of a SIP URL.

•Alice at phone A is identified as the call-session initiator in the From field.

•A unique numeric identifier is assigned to the call and inserted in the Call-ID field.

•The transaction number within a single call leg is identified in the CSeq field.

•The media capability of phone A is specified in the SDP.

•The port on which phone A is prepared to receive RTP data is specified in the SDP.

Step 2

INVITE—SIP proxy server to SIP IP phone B

The proxy server forwards the INVITE request to Bob at phone B.

Step 3

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

Phone B sends a 180 Ringing response to the SIP proxy server.

Note Call forward no answer timer expires.

Step 4

INVITE—SIP proxy server phone to SIP IP phone C

SIP proxy server sends an INVITE request to Carol at phone C to which Bob's calls have been configured to forward when there is no answer. Phone A changes the Request-URI to divert the request to Carol at phone C and adds a CC-Diversion header containing the Request-URI from the initial INVITE request and the reason for the diversion.

Step 5

180 Ringing—SIP IP phone C to SIP proxy server

Phone C sends a 180 Ringing response to the SIP proxy server.

Step 6

200 OK—SIP IP phone C to SIP proxy server

Phone C sends a 200 OK response to phone A.

If phone C supports the media capability advertised in the INVITE message sent by the SIP proxy server, it advertises the intersection of its own and phone A's media capability in the 200 OK response. If phone C does not support the media capability advertised by phone A, it returns a 400 Bad Request response with a "Warning: 304 Codec negotiation failed" header field.

Step 7

200 OK—SIP proxy server to SIP IP phone A

SIP proxy server forwards the 200 OK response to phone A. The response notifies phone A that Carol has answered the phone (for example, the handset went off-hook).

Step 8

ACK—SIP IP phone A to SIP IP phone C

Phone A sends an ACK to phone C. The ACK confirms that phone A has received the 200 OK response from phone C.

Note At this point, a two-way RTP channel is established between SIP IP phone A and SIP IP phone C.

Figure F-9 SIP IP Phone-to-SIP IP Phone Call Forward No Answer Setup via Nonrecursive Proxy

Action

Description

Step 1

INVITE—SIP IP phone A to SIP proxy server

Alice's phone A sends an INVITE request to the proxy server. The request is an invitation to Bob to participate in a call session. The following applies:

•Bob's phone number is inserted in the Request-URI field in the form of a SIP URL.

•Alice at phone A is identified as the call-session initiator in the From field.

•A unique numeric identifier is assigned to the call and inserted in the Call-ID field.

•The transaction number within a single call leg is identified in the CSeq field.

•The media capability of phone A is specified in the SDP.

•The port on which phone A is prepared to receive RTP data is specified in the SDP.

Step 2

INVITE—SIP proxy server to SIP IP phone B

SIP proxy server forwards the INVITE request to Bob at phone B.

Step 3

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

Phone B sends a 180 Ringing response to the SIP proxy server.

Note Timeout to INVITE request occurs.

Step 4

302 Moved Temporarily—SIP proxy server to SIP IP phone A

SIP proxy server sends an 302 Moved Temporarily message to phone A. Carol at phone C is added as the Contact and a CC-Diversion header is added that contains the Request-URI from the initial INVITE and the reason for the diversion.

Step 5

INVITE—SIP IP phone A to SIP IP phone C

Phone A sends an INVITE request to Carol at phone C to which Bob's calls have been configured to forward when Bob is unavailable, changes the Request-URI to divert the request to Carol at phone C, and adds a CC-Diversion header containing the Request-URI from the initial INVITE request and the reason for the diversion.

Step 6

180 Ringing—SIP IP phone C to SIP IP phone A

Phone C sends a 180 Ringing response to phone A.

Step 7

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

Phone C sends a 200 OK response to phone A. The response notifies phone A that Carol has answered the phone (for example, the handset went off-hook).

If phone C supports the media capability advertised in the INVITE message sent by the SIP proxy server, it advertises the intersection of its own and phone A's media capability in the 200 OK response. If phone C does not support the media capability advertised by phone A, it returns a 400 Bad Request response with a "Warning: 304 Codec negotiation failed" header field.

Step 8

ACK—SIP IP phone A to SIP IP phone C

Phone A sends an ACK to phone C. The ACK confirms that phone A has received the 200 OK response from phone C.

Note At this point, a two-way RTP channel is established between SIP IP phone A and SIP IP phone C.

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

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

Figure F-10 SIP IP Phone-to-SIP IP Phone Call Forward Unavailable Call Setup via Recursive Proxy

Action

Description

Step 1

INVITE—SIP IP phone A to SIP proxy server

Alice's phone A sends an INVITE request to the proxy server. The request is an invitation to Bob to participate in a call session. The following applies:

•Bob's phone number is inserted in the Request-URI field in the form of a SIP URL.

•Alice at phone A is identified as the call-session initiator in the From field.

•A unique numeric identifier is assigned to the call and inserted in the Call-ID field.

•The transaction number within a single call leg is identified in the CSeq field.

•The media capability of phone A is specified in the SDP.

•The port on which phone A is prepared to receive RTP data is specified in the SDP.

Step 2

100 Trying—SIP proxy server to SIP IP phone A

SIP proxy server sends a 100 Trying response to the INVITE request sent by phone A. The response indicates that the INVITE request has been received by the SIP proxy server but that Bob at phone B has not yet been located and that some unspecified action, such as a database consultation, is taking place.

Step 3

INVITE—proxy server to SIP IP phone B

SIP proxy server forwards the INVITE request to Bob at phone B.

Step 4

Step 5

Note Call forward unavailable timer expires.

Step 6

INVITE—SIP proxy server to SIP IP phone C

SIP proxy server sends an INVITE request to Carol at phone C to which Bob's calls have been configured to forward when there is no answer. Phone A changes the Request-URI to divert the request to Carol at phone C and adds a CC-Diversion header containing the Request-URI from the initial INVITE request and the reason for the diversion.

Step 7

180 Ringing—SIP IP phone C to SIP proxy server

Phone C sends a 180 Ringing response to the SIP proxy server.

Step 8

200 OK—SIP IP phone C to SIP proxy server

Phone C sends a 200 OK response to phone A.

If phone C supports the media capability advertised in the INVITE message sent by the SIP proxy server, it advertises the intersection of its own and phone A's media capability in the 200 OK response. If phone C does not support the media capability advertised by phone A, it returns a 400 Bad Request response with a "Warning: 304 Codec negotiation failed" header field.

Step 9

200 OK—SIP proxy server to SIP IP phone A

SIP proxy server forwards the 200 OK response to phone A. The response notifies phone A that Carol has answered the phone (for example, the handset went off-hook).

Step 10

ACK—SIP IP phone A to SIP IP phone B

Phone A sends an ACK to phone C. The ACK confirms that phone A has received the 200 OK response from phone C.

Note At this point, a two-way RTP channel is established between SIP IP phone A and SIP IP phone C.

Figure F-11 SIP IP Phone-to-SIP IP Phone Call Forward Unavailable Call Setup via Nonrecursive Proxy

Action

Description

Step 1

INVITE—SIP IP phone A to SIP proxy server

Alice's phone A sends an INVITE request to the proxy server. The request is an invitation to Bob to participate in a call session. The following applies:

•Bob's phone number is inserted in the Request-URI field in the form of a SIP URL.

•Alice at phone A is identified as the call-session initiator in the From field.

•A unique numeric identifier is assigned to the call and inserted in the Call-ID field.

•The transaction number within a single call leg is identified in the CSeq field.

•The media capability of phone A is specified in the SDP.

•The port on which phone A is prepared to receive RTP data is specified in the SDP.

Step 2

100 Trying—SIP proxy server to SIP IP phone A

SIP proxy server sends a 100 Trying response to the INVITE request sent by phone A. The response indicates that the INVITE request has been received by the SIP proxy server but that Bob has not yet been located and that some unspecified action, such as a database consultation, is taking place.

Step 3

INVITE—proxy server to SIP IP phone B

SIP proxy server forwards the INVITE request to Bob at phone B.

Step 4

Step 5

Note Call forward unavailable timer expires.

Step 6

302 Moved Temporarily—SIP proxy server to SIP IP phone A

SIP proxy server sends an 302 Moved Temporarily message to phone A. Carol at phone C is added as the Contact and a CC-Diversion header is added that contains the Request-URI from the initial INVITE and the reason for the diversion.

Step 7

INVITE—SIP IP phone A to SIP IP phone C

Phone A sends an INVITE request to Carol at phone C to which Bobs calls have been configured to forward when there is no answer. Phone A changes the Request-URI to divert the request to Carol at phone C and adds a CC-Diversion header containing the Request-URI from the initial INVITE request and the reason for the diversion.

Step 8

180 Ringing—SIP IP phone C to SIP IP phone A

Phone C sends a 180 Ringing response to phone A.

Step 9

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

Phone C sends a 200 OK response to phone A. The response notifies phone A that Carol has answered the phone (for example, the handset went off-hook).

If phone C supports the media capability advertised in the INVITE message sent by the SIP proxy server, it advertises the intersection of its own and phone A's media capability in the 200 OK response. If phone C does not support the media capability advertised by phone A, it returns a 400 Bad Request response with a "Warning: 304 Codec negotiation failed" header field.

Step 10

ACK—SIP IP phone A to SIP IP phone C

Phone A sends an ACK to phone C. The ACK confirms that phone A has received the 200 OK response from phone C.

Note At this point, a two-way RTP channel is established between SIP IP phone A and SIP IP phone C.

Call-Flow Scenarios for Failed Calls

This section describes call flows for the following failed-call scenarios:

•SIP Gateway-to-SIP Gateway via SIP Redirect Server—Called User Is Busy

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

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

•SIP Gateway-to-SIP Gateway via SIP Proxy Server—Called User Is Busy

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

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

•SIP Phone-to-SIP/H.323 Gateway—Call via SIP Proxy Server with Record-Route Disabled

•SIP Phone-to-SIP/H.323 Gateway—Call via SIP Proxy Server with Record-Route Enabled

•SIP Phone to SIP/H.323 Gateway—Call via SIP Redirect Server

•SIP Phone-to-SIP/H.323 Gateway—Call via SIP Proxy Server with Record-Route Disabled (Call Failed with a 503 Service Unavailable Response)

Note The messages are provided as examples for reference only.

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

Figure F-12 illustrates an unsuccessful call in which user A initiates a call to user B but user B is on the phone and is unable or unwilling to accept another call.

Figure F-12 SIP Gateway-to-SIP Gateway Call via a SIP Redirect Server—Called User is Busy

Action

Description

Step 1

Setup—PBX A to SIP gateway 1

Call setup is initiated between PBX A and SIP gateway 1. Setup includes the standard transactions that take place as user A attempts to call user B.

Step 2

INVITE—SIP gateway 1 to SIP redirect server

SIP gateway 1 sends an INVITE request to the SIP redirect server. The request is an invitation to user B to participate in a call session. The following applies:

•The phone number of user B is inserted in the Request-URI field in the form of a SIP URL.

•PBX A is identified as the call-session initiator in the From field.

•A unique numeric identifier is assigned to the call and inserted in the Call-ID field.

•The transaction number within a single call leg is identified in the CSeq field.

•The media capability of user A is specified.

•The port on which SIP gateway 1 is prepared to receive RTP data is specified.

Step 3

302 Moved Temporarily— SIP redirect server to SIP gateway 1

SIP redirect server sends a 302 Moved Temporarily message to SIP gateway 1. The message indicates that user B is not available and includes instructions to locate user B.

Step 4

ACK—SIP gateway 1 to SIP redirect server

SIP gateway 1 acknowledges the 302 Moved Temporarily response with an ACK.

Step 5

INVITE—SIP gateway 1 to SIP gateway 2

SIP gateway 1 sends a new INVITE request to user B. The new INVITE request includes the first contact listed in the 300 Multiple Choice response as the new address for user B, a higher transaction number in the CSeq field, and the same Call-ID as the first INVITE request.

Step 6

Call Proceeding—SIP gateway 1 to PBX A

SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the call-setup request.

Step 7

Setup—SIP gateway 2 to PBX B

SIP gateway 2 receives the INVITE request from SIP gateway 1 and initiates call setup with user B via PBX B.

Step 8

100 Trying—SIP gateway 2 to SIP gateway 1

SIP gateway 2 sends a 100 Trying response to the INVITE request sent by SIP gateway 1. The 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.

Step 9

Call Proceeding—PBX B to SIP gateway 2

PBX B sends a Call Proceeding message to SIP gateway 2 to acknowledge the call-setup request.

Step 10

Disconnect (Busy)—PBX B to SIP gateway 2

PBX B sends a Disconnect message to SIP gateway 2. The cause code indicates that user B is busy. The Disconnect message starts the call session termination process.

Step 11

486 Busy Here—SIP gateway 2 to SIP gateway 1

SIP gateway 2 maps the Release message cause code (Busy) to the 486 Busy response and sends the response to SIP gateway 1. The response indicates that user B's phone was successfully contacted but user B was either unwilling or unable to take another call.

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

Step 13

Release—PBX A to SIP gateway 1

PBX A sends a Release message to SIP gateway 1.

Step 14

Release—SIP gateway 2 to PBX B

SIP gateway 1 sends a Release message to PBX B.

Step 15

ACK—SIP gateway 1 to SIP gateway 2

SIP gateway 1 sends an ACK to SIP gateway 2. The ACK confirms that the 486 Busy Here response has been received.

Step 16

Release Complete—SIP gateway 1 to PBX A

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

Step 17

Release Complete—PBX B to SIP gateway 2

PBX B sends a Release Complete message to SIP gateway 2.

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

Figure F-13 illustrates an unsuccessful call in which user A initiates a call to user B but user B does not answer.

Figure F-13 SIP Gateway-to-SIP Gateway Call via a SIP Redirect Server—Called User is Does Not Answer

Action

Description

Step 1

Setup—PBX A to SIP gateway 1

Call setup is initiated between PBX A and SIP gateway 1. Setup includes the standard transactions that take place as user A attempts to call user B.

Step 2

INVITE—SIP gateway 1 to SIP redirect server

SIP gateway 1 sends an INVITE request to the SIP redirect server. The request is an invitation to user B to participate in a call session. The following applies:

•The phone number of user B is inserted in the Request-URI field in the form of a SIP URL.

•PBX A is identified as the call-session initiator in the From field.

•A unique numeric identifier is assigned to the call and inserted in the Call-ID field.

•The transaction number within a single call leg is identified in the CSeq field.

•The media capability of user A is specified.

•The port on which SIP gateway 1 is prepared to receive RTP data is specified.

Step 3

302 Moved Temporarily— SIP redirect server to SIP gateway 1

SIP redirect server sends a 302 Moved Temporarily message to SIP gateway 1. The message indicates that user B is not available and includes instructions to locate user B.

Step 4

ACK—SIP gateway 1 to SIP redirect server

SIP gateway 1 acknowledges the 302 Moved Temporarily response with an ACK.

Step 5

INVITE—SIP gateway 1 to SIP gateway 2

SIP gateway 1 sends a new INVITE request to user B. The new INVITE request includes a new address for user B, a higher transaction number in the CSeq field, but the same Call-ID as the first INVITE request.

Step 6

Call Proceeding—SIP gateway 1 to PBX A

SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the call-setup request.

Step 7

Setup—SIP gateway 2 to PBX B

SIP gateway 2 receives the INVITE request from SIP gateway 1 and initiates call setup with user B via PBX B.

Step 8

100 Trying—SIP gateway 2 to SIP gateway 1

SIP gateway 2 sends a 100 Trying response to the INVITE request sent by SIP gateway 1. The 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.

Step 9

Call Proceeding—PBX B to SIP gateway 2

PBX B sends a Call Proceeding message to SIP gateway 2 to acknowledge the call-setup request.

Step 10

Alerting—PBX B to SIP gateway 2

PBX B sends an Alert message to SIP gateway 2. User B's phone begins to ring.

Step 11

180 Ringing—SIP gateway 2 to SIP gateway 1

SIP gateway 2 sends a 180 Ringing response to SIP gateway 1. The response indicates that SIP gateway 2 has located, and is trying to alert user B.

Step 12

Alerting—SIP gateway 1 to PBX A

SIP gateway 1 sends an Alert message to PBX A.

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

Step 14

Disconnect—SIP gateway 1 to PBX A

SIP gateway 1 sends a Disconnect message to PBX A.

Step 15

Release—PBX A to SIP gateway 1

PBX A sends a Release message to SIP gateway 1.

Step 16

Disconnect—SIP gateway 2 to PBX B

SIP gateway 2 sends a Disconnect message to PBX B.

Step 17

200 OK—SIP gateway 1 to SIP gateway 2

SIP gateway 1 sends a 200 OK response to SIP gateway 2. The 200 OK response confirms that the CANCEL request has been received.

Step 18

Release Complete—PBX A to SIP gateway 1

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

Step 19

Release—PBX B to SIP gateway 2

PBX B sends a Release message to SIP gateway 2.

Step 20

Release Complete—SIP gateway 2 to PBX B

SIP gateway 2 sends a Release Complete message to PBX B.

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

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

Figure F-14 SIP Gateway-to-SIP Gateway Call via a SIP Redirect Server—Client, Server, or Global

Action

Description

Step 1

Setup—PBX A to SIP gateway 1

Call setup is initiated between PBX A and SIP gateway 1. Setup includes the standard transactions that take place as user A attempts to call user B.

Step 2

INVITE—SIP gateway 1 to SIP redirect server

SIP gateway 1 sends an INVITE request to the SIP redirect server. The request is an invitation to user B to participate in a call session. The following applies:

•The phone number of user B is inserted in the Request-URI field in the form of a SIP URL.

•PBX A is identified as the initiator in the From field.

•A unique numeric identifier is assigned to the call and inserted in the Call-ID field.

•The transaction number within a single call leg is identified in the CSeq field.

•The media capability of user A is specified.

•The port on which SIP gateway 1 is prepared to receive RTP data is specified.

Step 3

300 Multiple Choice—SIP redirect server to SIP gateway 1

The SIP redirect server sends a 300 Multiple Choice response to SIP gateway 1. The 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.

Step 4

ACK—SIP gateway 1 to SIP redirect server

SIP gateway 1 acknowledges the 300 Multiple Choice response with an ACK.

Step 5

INVITE—SIP gateway 1 to SIP gateway 2

SIP gateway 1 sends a new INVITE request to user B. The new INVITE request includes a new address for user B, a higher transaction number in the CSeq field, but the same Call-ID as the first INVITE request.

Step 6

Call Proceeding—SIP gateway 1 to SIP gateway 2

SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the call-setup request.

Step 7

100 Trying—SIP gateway 2 to SIP gateway 1

SIP gateway 2 sends a 100 Trying response to the INVITE request sent by SIP gateway 1. The 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.

Step 8

Class 4xx/5xx/6xx Failure—SIP gateway 2 to SIP gateway 1

SIP gateway 2 determines that user B does not exist at the domain specified in the INVITE request sent by SIP gateway 1. SIP gateway 2 refuses the connection and sends a 404 Not Found response to SIP gateway 1.

The 404 Not Found response is a class 4xx failure response. The call actions differ, based on the class of failure response.

If SIP gateway 2 sends a class 4xx failure response (a definite failure response that is a client error), the request is not 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 terminates because the 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 fail.

Step 9

Disconnect—SIP gateway 1 to PBX A

SIP gateway 1 sends a Disconnect message to PBX A.

Step 10

Release—PBX A to SIP gateway 1

PBX A sends a Release message to SIP gateway 1.

Step 11

ACK—SIP gateway 1 to SIP gateway 2

SIP gateway 1 sends an ACK to SIP gateway 2. The ACK confirms that the 404 Not Found failure response has been received.

Step 12

Release Complete—SIP gateway 1 to PBX A

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

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

Figure F-15 illustrates an unsuccessful call in which user A initiates a call to user B but user B is on the phone and is unwilling or unable to accept another call.

Figure F-15 SIP Gateway-to-SIP Gateway Call via a SIP Proxy Server—Called User is Busy

Action

Description

Step 1

Setup—PBX A to SIP gateway 1

Call setup is initiated between PBX A and SIP gateway 1. Setup includes the standard transactions that take place as user A attempts to call user B.

Step 2

INVITE—SIP gateway 1 to SIP proxy server

SIP gateway 1 sends an INVITE request to the SIP proxy server. The request is an invitation to user B to participate in a call session. The following applies:

•The phone number of user B is inserted in the Request-URI field in the form of a SIP URL.

•PBX A is identified as the call-session initiator in the From field.

•A unique numeric identifier is assigned to the call and inserted in the Call-ID field.

•The transaction number within a single call leg is identified in the CSeq field.

•The media capability of user A is specified.

•The port on which SIP gateway 1 is prepared to receive RTP data is specified.

Step 3

INVITE—SIP proxy server to SIP gateway 2

SIP proxy server checks whether its own address is contained in the Via field (to prevent loops), directly copies the To, From, Call-ID, and Contact fields from the request it received from SIP gateway 1, changes the Request-URI to indicate the server to which it intends to send the INVITE request, and sends a new INVITE request to SIP gateway 2.

Step 4

Call Proceeding—SIP gateway 1 to PBX A

SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the call-setup request.

Step 5

Setup—SIP gateway 2 to PBX B

SIP gateway 2 receives the INVITE request from the SIP proxy server and initiates call setup with user B via PBX B.

Step 6

100 Trying—SIP proxy server to SIP gateway 1

SIP proxy server sends a 100 Trying response to SIP gateway 1.

Step 7

100 Trying—SIP gateway 2 to SIP proxy server

SIP gateway 2 sends a 100 Trying response to the SIP proxy server.

Step 8

Release Complete (Busy)—PBX B to SIP gateway 2

PBX B sends a Release Complete message to SIP gateway 2. The cause code indicates that user B is busy. The Release Complete message starts the call session termination process.

Step 9

486 Busy Here—SIP gateway 2 to SIP proxy server

SIP gateway 2 maps the Release message cause code (Busy) to the 486 Busy response and sends the response to the SIP proxy server. The response indicates that user B's phone was successfully contacted but user B was either unwilling or unable to take another call.

Step 10

486 Busy Here—SIP proxy server to SIP gateway 1

SIP proxy server forwards the 486 Busy response to SIP gateway 1.

Step 11

Disconnect (Busy)—SIP gateway 1 to PBX A

SIP gateway 1 sends a Disconnect message to PBX A.

Step 12

Release—PBX A to SIP gateway 1

PBX A sends a Release message to SIP gateway 1.

Step 13

ACK—SIP gateway 1 to SIP proxy server

SIP gateway 1 sends an SIP ACK to the SIP proxy server.

Step 14

ACK—SIP proxy server to SIP gateway 2

SIP proxy server forwards the SIP ACK to SIP gateway 2. The ACK confirms that the 486 Busy Here response has been received.

Step 15

Release Complete—SIP gateway 1 to PBX A

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

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

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

Figure F-16 SIP Gateway-to-SIP Gateway Call via a SIP Proxy Server—Client or Server Error

Action

Description

Step 1

Setup—PBX A to SIP gateway 1

Call setup is initiated between PBX A and SIP gateway 1. Setup includes the standard transactions that take place as user A attempts to call user B.

Step 2

INVITE—SIP gateway 1 to SIP proxy server

SIP gateway 1 sends an INVITE request to the SIP proxy server. The request is an invitation to user B to participate in a call session. The following applies:

•The phone number of user B is inserted in the Request-URI field in the form of a SIP URL.

•PBX A is identified as the initiator in the From field.

•A unique numeric identifier is assigned to the call and inserted in the Call-ID field.

•The transaction number within a single call leg is identified in the CSeq field.

•The media capability of user A is specified.

•The port on which SIP gateway 1 is prepared to receive RTP data is specified.

Step 3

INVITE—SIP proxy server to SIP gateway 2

SIP proxy server checks whether its own address is contained in the Via field (to prevent loops), directly copies the To, From, Call-ID, and Contact fields from the request it received from SIP gateway 1, changes the Request-URI to indicate the server to which it intends to send the INVITE request, and sends a new INVITE request to SIP gateway 2.

Step 4

Call Proceeding—SIP gateway 1 to PBX A

SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the call-setup request.

Step 5

100 Trying—SIP proxy server to SIP gateway 1

SIP proxy server sends a 100 Trying response to SIP gateway 1.

Step 6

100 Trying—SIP gateway 2 to SIP proxy server

SIP gateway 2 sends a 100 Trying response to the SIP proxy server.

Step 7

Class 4xx/5xx/6xx Failure—SIP gateway 2 to SIP proxy server

SIP gateway 2 determines that it does not have any more channels available, refuses the connection, and sends a SIP 503 Service Unavailable response to the SIP proxy server.

Step 8

Class 4xx/5xx/6xx Failure—SIP proxy server to SIP gateway 1

SIP proxy server forwards the SIP 503 Service Unavailable response to SIP gateway 1.

Step 9

Disconnect—SIP gateway 1 to PBX A

SIP gateway 1 sends a Disconnect message to PBX A.

Step 10

Release—PBX A to SIP gateway 1

PBX A sends a Release message to SIP gateway 1.

Step 11

ACK—SIP gateway 1 to SIP proxy server

SIP gateway 1 sends an ACK to the SIP proxy server.

Step 12

ACK—SIP proxy server to SIP gateway 2

SIP proxy server forwards the SIP ACK to SIP gateway 2. The ACK confirms that the 503 Service Unavailable response has been received.

Step 13

Release Complete—SIP gateway 1 to PBX A

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

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

Figure F-17 illustrates an unsuccessful call in which user A initiates a call to user B and receives a class 6xx response.

Figure F-17 SIP Gateway-to-SIP Gateway Call via a SIP Proxy Server—Global Error Response

Action

Description

Step 1

Setup—PBX A to SIP gateway 1

Call setup is initiated between PBX A and SIP gateway 1. Setup includes the standard transactions that take place as user A attempts to call user B.

Step 2

INVITE—SIP gateway 1 to SIP proxy server

SIP gateway 1 sends an INVITE request to the SIP proxy server. The request is an invitation to user B to participate in a call session. The following applies:

•The phone number of user B is inserted in the Request-URI field in the form of a SIP URL.

•PBX A is identified as the call-session initiator in the From field.

•A unique numeric identifier is assigned to the call and inserted in the Call-ID field.

•The transaction number within a single call leg is identified in the CSeq field.

•The media capability of user A is specified.

•The port on which SIP gateway 1 is prepared to receive RTP data is specified.

Step 3

Call Proceeding—SIP gateway 1 to PBX A

SIP gateway 1 sends a Call Proceeding message to PBX A to acknowledge the call-setup request.

Step 4

INVITE—SIP proxy server to SIP gateway 2

SIP proxy server checks whether its own address is contained in the Via field (to prevent loops), directly copies the To, From, Call-ID, and Contact fields from the request it received from SIP gateway 1, changes the Request-URI to indicate the server to which it intends to send the INVITE request, and sends a new INVITE request to SIP gateway 2.

Step 5

Setup—SIP gateway 2 to PBX B

SIP gateway 2 receives the INVITE request from the SIP proxy server and initiates call setup with user B via PBX B.

Step 6

100 Trying—SIP gateway 2 to SIP proxy server

SIP gateway 2 sends a 100 Trying response to the SIP proxy server. SIP proxy server might or might not forward the 100 Trying response to SIP gateway 1.

Step 7

100 Trying—SIP proxy server to SIP gateway 1

SIP proxy server forwards the 100 Trying response to SIP gateway 1.

Step 8

Release Complete—PBX B to SIP gateway 2

PBX B sends a Release Complete message to SIP gateway 2. The Release Complete message starts the call session termination process.

Step 9

6xx Failure—SIP gateway 2 to SIP proxy server

SIP gateway 2 sends a class 6xx failure response (a global error) to the SIP proxy server. The 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 fail, therefore the search is terminated.

SIP proxy server must forward all class 6xx failure responses to the client.

Step 10

6xx Failure—SIP proxy server to SIP gateway 1

SIP proxy server forwards the 6xx failure to SIP gateway 1.

Step 11

Disconnect—SIP gateway 1 to PBX A

SIP gateway 1 sends a Disconnect message to PBX A.

Step 12

Release—PBX A to SIP gateway 1

PBX A sends a Release message to SIP gateway 1.

Step 13

ACK—SIP gateway 1 to SIP proxy server

SIP gateway 1 sends an ACK to the SIP proxy server.

Step 14

ACK—SIP proxy server to SIP gateway 2

SIP proxy server sends an ACK to SIP gateway 2. The ACK confirms that the 6xx failure response has been received.

Step 15

Release Complete—SIP gateway 1 to PBX A

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

SIP Phone-to-SIP/H.323 Gateway—Call via SIP Proxy Server with Record-Route Disabled

Figure F-18 Call Via SIP Proxy Server with Record-Route disabled
Action

Description
Step 1

INVITE—SIP phone to SIP proxy server
SIP UAC sends an INVITE request to the SIP proxy server.

Example
INVITE sip:20002@proxy.cisco.com;user=phone;phone-context=000000 
SIP/2.0
Via: SIP/2.0/UDP 161.44.3.207:49489
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:20002@company.com;user=phone;phone-context=000000>
Date: Thu, 18 Mar 2000 04:48:28 UTC
Call-ID: 23-99990146-0-5894369F@161.44.3.207
Cisco-Guid: 428806444-2576941380-0-1486104925
User-Agent: Cisco IP Phone
CSeq:1 INVITE
Max-Forwards: 6
Timestamp: 732430108
Contact: <sip:+19195550001@bounty.cisco.com:49489;user=phone>
Expires: 5
Content-Type: application/sdp
v=0
o=CiscoSystemsSIP- UserAgent 8870 5284 IN IP4 172.18.193.101
s=SIP Call
t=0 0
c=IN IP4 172.18.193.101
m=audio 20354 RTP/AVP 0 3
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
The phone number of called party is inserted in the Request-URI field in the form of a SIP URL. A unique numeric identifier is assigned to the call and is inserted in the Call-ID field. The transaction number within a single call leg is identified in the Cseq field. The media capability the calling party is ready to receive is specified.
INVITE—SIP phone to SIP proxy server
SIP UAC sends an INVITE request to the SIP proxy server.

Example
INVITE sip:20002@proxy.cisco.com;user=phone;phone-context=000000 
SIP/2.0
Via: SIP/2.0/UDP 161.44.3.207:49489
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:20002@company.com;user=phone;phone-context=000000>
Date: Thu, 18 Mar 2000 04:48:28 UTC
Call-ID: 23-99990146-0-5894369F@161.44.3.207
Cisco-Guid: 428806444-2576941380-0-1486104925
User-Agent: Cisco IP Phone
CSeq:1 INVITE
Max-Forwards: 6
Step 2

100—Trying SIP Proxy sends to UAC
SIP proxy server sends 100-Trying response message to the upstream UAC upon receiving the INVITE in step ++SIP/2.0 100

Example
TryingVia: SIP/2.0/UDP 161.44.3.207:49489Call-ID: 
23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>To: 
<sip:20002@company.com;user=phone;phone-context=000000>CSeq: 1 
INVITEContent-Length: 0
Step 3

RAS LRQ—SIP Proxy sends a RAS LRQ message to a DGK
SIP proxy server expands the 20002 number into a 19193920002 number but finds no static route to route the request. It then invokes the new routing module and creates an LRQ RAS message from the incoming INVITE SIP message. The LRQ message is sent to one of the DGK configured in the sipd.conf file.

SIP proxy server prepends a technology prefix 001# to the expanded number and uses it to fill the "destinationInfo" field of the LRQ RAS message.

Example
value RasMessage ::= locationRequest :
{
        requestSeqNum 2519
        destinationInfo
        {
          e164 : "001#19193920002"
        }
        nonStandardData
        {
          nonStandardIdentifier h221NonStandard :
          {
            t35CountryCode 181
            t35Extension 0
            manufacturerCode 18
          }
data '8284901100ECAA98A025220008000000000E1963...'H
        }
        replyAddress ipAddress :
        {
          ip 'AC12C247'H
          port 1719
        }
        sourceInfo
        {
          h323-ID : {"genuity-sip1"}
        }
        canMapAlias TRUE
      }
Step 4

RAS RIP—H.323 DGK returns a RIP to the SIP proxy server
Upon receiving the RAS LRQ message from the SIP proxy server, the H.323 DGK can return a RIP with delay timer value. SIP server should adjust timer accordingly.

Example
value RasMessage ::= requestInProgress :
{
requestSeqNum 2519
delay 9000
}
Step 5

RAS LCF—H.323 DGK returns a LCF to the SIP proxy server
 {
        requestSeqNum 2519
        callSignalAddress ipAddress :
        {
          ip 'AC12C250'H
          port 1720
        }
        rasAddress ipAddress :
        {
          ip 'AC12C250'H
          port 56812
        }
        nonStandardData
        {
          nonStandardIdentifier h221NonStandard :
          {
            t35CountryCode 181
            t35Extension 0
 manufacturerCode 18
          }
          data '0002400900630033003600320030002D0032002D...'H
        }
        destinationType
        {
          gateway
          {
            protocol
            {
              voice :
              {
                supportedPrefixes
                {
                }
              }
            }
          }
mc FALSE
          undefinedNode FALSE
        }
      }
value LCFnonStandardInfo ::=
{
        termAlias
        {
          h323-ID : {"c3620-2-gw"},
          e164 : "001#19193920002"
}
        gkID {"c3620-1-gk"}
        gateways
        {
{
            gwType voip : NULL
            gwAlias
            {
 h323-ID : {"c3620-2-gw"},
              e164 : "001#19193920002"
            }
            sigAddress
            {
              ip 'AC12C250'H
              port 1720
            }
            resources
            {
              maxDSPs 0
              inUseDSPs 0
              maxBChannels 0
              inUseBChannels 0
              activeCalls 0
              bandwidth 0
              inuseBandwidth 0
            }
          }
        }
      }
Step 6

SIP INVITE—SIP proxy server forwards the INVITE to the gateway
SIP proxy server receives the RAS LCF message, decode it and obtain the gateway transport address (172.18.194.80) value from the callSignalAddress ipAddress field of the LCF message. It then adds the SIP port number (5060) and forwards the INVITE to the gateway. Since the 001# tech-prefix flag is turned on in the sipd.conf file, the 001# string is not stripped from the request-URI.

Example
INVITE sip:001#19193920002@172.18.194.80:5060; 
user=phone;phone-context=000000 SIP/2.0
Via: SIP/2.0/UDP proxy.cisco.com:48754; branch=1
Via: SIP/2.0/UDP  161.44.3.207:49489
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:20002@company.com;user=phone;phone-context=000000>
Date: Thu, 18 Mar 2000 04:48:28 UTC
Call-ID: 23-99990146-0-5894369F@161.44.3.207
Cisco-Guid: 428806444-2576941380-0-1486104925
User-Agent: Cisco IP PhoneCSeq:1
INVITEMax-Forwards: 6
Timestamp: 732430108
Contact: <sip:+19195550001@bounty.cisco.com:49489;user=phone>
Expires: 5
Content-Type: application/sdp
v=0
o=CiscoSystemsSIP- UserAgent 8870 5284 IN IP4 172.18.193.101
s=SIP Callt=0 0
c=IN IP4 172.18.193.101
m=audio 20354 RTP/AVP 0 3
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
Step 7

SIP 180 Ringing—Gateway sends 180 Ringing back to the SIP proxy server
The SIP/H.323 gateway receives the forwarded SIP INVITE message from the SIP proxy server and sends it downstream. Assume the call signal reaches the end-point and a SIP 180 Ringing is sent from the gateway up to the SIP proxy server.

Example
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP proxy.cisco.com:48754; branch=1
Via: SIP/2.0/UDP 161.44.3.207:49489
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:20002@company.com;user=phone;phone-context=000000>
CSeq: 1 INVITE
Content-Length: 0
Step 8

SIP 180 Ringing—SIP proxy server forwards to the UAC
SIP proxy server receives the 180 Ringing from the gateway, it found the record in TCB and forwards the 180 Ringing upstream to the UAC.

Example
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 161.44.3.207:49489
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:20002@company.com;user=phone;phone-context=000000>
CSeq: 1 INVITE
Content-Length: 0
Step 9

SIP 200 OK—Gateway sends 200 OK to upstream SIP proxy server
The called party picks up the phone. The gateway sends a 200 OK to the SIP proxy server.

Example
SIP/2.0 200 OK
Via: SIP/2.0/UDP proxy.cisco.com:48754; branch=1
Via: SIP/2.0/UDP 161.44.3.207:49489
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:20002@company.com;user=phone;phone-context=000000>
Contact: <sip:001#19195550002@172.18.194.80>
CSeq: 1 INVITE
Content-Length: 0
v=0
o=CiscoSystemsSIP- gateway 537556 235334 IN IP4 172.18.194.80
s=SIP Call
t=0 0
c=IN IP4 gateway.cisco.com
m=audio 5004 RTP/AVP 0 3
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
Step 10

SIP 200 OK—SIP proxy server forward the 200 OK to the calling UAC
SIP proxy server receives the 200 OK from the gateway. It forwards it upstream to the calling UAC.

Example
SIP/2.0 200 OK
Via: SIP/2.0/UDP 161.44.3.207:49489
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:20002@company.com;user=phone;phone-context=000000>
Contact: <sip:001#19195550002@172.18.194.80>
CSeq: 1 INVITE
Content-Length: 0
v=0
o=CiscoSystemsSIP- gateway 537556 235334 IN IP4 172.18.194.80
s=SIP Call
t=0 0
c=IN IP4 gateway.cisco.com
m=audio 5004 RTP/AVP 0 3
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
Step 11

SIP ACK—Calling UAC sends ACK directly to the gateway
Upon receiving the 200 OK message, the UAC opens the media port and responds with ACK directly to the gateway.

Example
SIP/2.0 ACK
Via: SIP/2.0/UDP 161.44.3.207:49489
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:20002@company.com;user=phone;phone-context=000000>
CSeq: 1 ACK
Step 12

SIP BYE—Gateway sends BYE to the calling UAC
The callee hangs up the phone. The gateway sends a BYE to the calling UAC.

Example
SIP/2.0 BYE
Via: SIP/2.0/UDP 172.18.194.80:43576
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:20002@company.com;user=phone;phone-context=000000>
CSeq: 1 BYE
Step 13

SIP 200 OK—Calling UAC returns a 200 OK to the gateway
The calling UAC receives the BYE from the gateway, it returns a 200 OK.

Example
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.18.194.80:43576
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:20002@company.com;user=phone;phone-context=000000>
CSeq: 1 BYE
SIP Phone-to-SIP/H.323 Gateway—Call via SIP Proxy Server with Record-Route Enabled

Figure F-19 Call Via SIP Proxy Server with Record-Route enabled
Action

Description
Step 1

INVITE—SIP phone to SIP proxy server
SIP UAC sends an INVITE request to the SIP proxy server.

Example
INVITE sip:20002@proxy.cisco.com;user=phone;phone-context=000000 
SIP/2.0
Via: SIP/2.0/UDP 161.44.3.207:49489
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:20002@company.com;user=phone;phone-context=000000>
Date: Thu, 18 Mar 2000 04:48:28 UTC
Call-ID: 23-99990146-0-5894369F@161.44.3.207
Cisco-Guid: 428806444-2576941380-0-1486104925
User-Agent: Cisco IP Phone
CSeq:1 INVITE
Max-Forwards: 6
Timestamp: 732430108
Contact: <sip:+19195550001@bounty.cisco.com:49489;user=phone>
Expires: 5
Content-Type: application/sdp
v=0
o=CiscoSystemsSIP- UserAgent 8870 5284 IN IP4 172.18.193.101
s=SIP Call
t=0 0
c=IN IP4 172.18.193.101
m=audio 20354 RTP/AVP 0 3
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
The following applies:

•The phone number of the called party is inserted in the Request-URI field in the form of a SIP URL.

•A unique numeric identifier is assigned to the call and is inserted in the Call-ID field.The transaction number within a single call leg is identified in the Cseq field.

The media capability the calling party is ready to receive is specified.
Step 2

100—Trying SIP Proxy sends to UAC
SIP proxy server sends 100-Trying response message to the upstream UAC upon receiving the INVITE in step 1.

Example
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 161.44.3.207:49489
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "255-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:20002@company.com;user=phone;phone-context=000000>
CSeq: 1 INVITE
Content-Length: 0
Step 3

RAS LRQ—SIP Proxy sends a RAS LRQ message to a DGK
SIP proxy server expands the 20002 number into a 9193920002 number but finds no static route to route the request. It then invokes the new routing module and creates an LRQ RAS message from the incoming INVITE SIP message. The LRQ message is sent to one of the DGK configured in the sipd.conf file.

SIP proxy server prepends a technology prefix 001# to the expanded number and uses it to fill the destinationInfo field of the LRQ RAS message. The (decoded) RAS LRQ looks like the following example:

Example
value RasMessage ::= locationRequest :
{
        requestSeqNum 2519
        destinationInfo
        {
          e164 : "001#19193920002"
        }
        nonStandardData
        {
          nonStandardIdentifier h221NonStandard :
          {
            t35CountryCode 181
            t35Extension 0
            manufacturerCode 18
          }
data '8284901100ECAA98A025220008000000000E1963...'H
        }
        replyAddress ipAddress :
        {
          ip 'AC12C247'H
          port 1719
        }
        sourceInfo
        {
          h323-ID : {"genuity-sip1"}
        }
        canMapAlias TRUE
      }
Step 4

RAS RIP—H.323 DGK returns a RIP to the SIP proxy server
Upon receiving the RAS LRQ message from the SIP proxy server, H.323 DGK can return a RIP with delay timer value. SIP server should adjust timer accordingly.

Example
value RasMessage ::= requestInProgress :
{
        requestSeqNum 2519
        delay 9000
}
Step 5

RAS LCF—H.323 DGK returns a LCF to the SIP proxy server
H.323 DGK forwards the request to the H.323 network and finds a SIP/H.323 gateway that can handle this particular call. It then returns a RAS LCF message to the SIP proxy server.

Example
value RasMessage ::= locationConfirm :
      {
        requestSeqNum 2519
        callSignalAddress ipAddress :
        {
          ip 'AC12C250'H
          port 1720
        }
        rasAddress ipAddress :
        {
          ip 'AC12C250'H
          port 56812
        }
        nonStandardData
        {
          nonStandardIdentifier h221NonStandard :
          {
            t35CountryCode 181
            t35Extension 0
            manufacturerCode 18
          }
          data '0002400900630033003600320030002D0032002D...'H
        }
        destinationType
        {
          gateway
          {
            protocol
            {
              voice :
              {
supportedPrefixes
                {
                }
              }
            }
          }
mc FALSE
          undefinedNode FALSE
        }
      }
value LCFnonStandardInfo ::=
{
        termAlias
        {
          h323-ID : {"c3620-2-gw"},
          e164 : "001#19193920002"
}
        gkID {"c3620-1-gk"}
        gateways
        {
{
            gwType voip : NULL
            gwAlias
            {
              h323-ID : {"c3620-2-gw"},
              e164 : "001#19193920002"
            }
            sigAddress
            {
              ip 'AC12C250'H
              port 1720
            }
            resources
{
              maxDSPs 0
              inUseDSPs 0
              maxBChannels 0
              inUseBChannels 0
              activeCalls 0
              bandwidth 0
              inuseBandwidth 0
            }
          }
        }
      }
Step 6

SIP INVITE—SIP proxy server forwards the INVITE to the gateway
SIP proxy server forwards the INVITE to the gateway.

Example
To: <sip:20002@company.com;user=phone;phone-context=000000>
Date: Thu, 18 Mar 2000 04:48:28 UTC
Call-ID: 23-99990146-0-5894369F@161.44.3.207
Cisco-Guid: 428806444-2576941380-0-1486104925
User-Agent: Cisco IP Phone
CSeq:1 INVITE
Max-Forwards: 6
Timestamp: 732430108
Contact: <sip:+19193920001@bounty.cisco.com:49489;user=phone>
Expires: 5
Content-Type: application/sdp
v=0
o=CiscoSystemsSIP- UserAgent 8870 5284 IN IP4 172.18.193.101
s=SIP Call
t=0 0
c=IN IP4 172.18.193.101
m=audio 20354 RTP/AVP 0 3
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
Step 7

SIP 180 Ringing—Gateway sends 180 Ringing back to the SIP proxy server
SIP/H.323 gateway receives the forwarded SIP INVITE message from the SIP proxy server and sends it downstream. Assume the call signal reaches the end-point and a SIP 180 Ringing is sent from the gateway up to the SIP proxy server.

Example
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP proxy.cisco.com:48754; branch=1
Via: SIP/2.0/UDP 161.44.3.207:49489
Record-Route: < sip:001#9195550002@proxy.cisco.com; 
maddr=proxy.cisco.com>
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:20002@company.com;user=phone;phone-context=000000>
CSeq: 1 INVITE
Content-Length: 0
Step 8

SIP 180 Ringing—SIP proxy server forwards to the UAC
SIP proxy server receives the 180 Ringing from the gateway, it found the record in TCB and forwards the 180 Ringing upstream to the UAC.

Example
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 161.44.3.207:49489
Record-Route: < sip:001#9193920002@proxy.cisco.com; 
maddr=proxy.cisco.com>
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:20002@company.com;user=phone;phone-context=000000>
CSeq: 1 INVITE
Content-Length: 0
Step 9

SIP 200 OK—Gateway sends 200 OK to upstream SIP proxy server
The called party picks up the phone. The gateway sends a 200 OK to the SIP proxy server.

Example
SIP/2.0 200 OK
Via: SIP/2.0/UDP proxy.cisco.com:48754; branch=1
Via: SIP/2.0/UDP 161.44.3.207:49489
Record-Route: < sip:001#9193920002@proxy.cisco.com; 
maddr=proxy.cisco.com>
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:20002@company.com;user=phone;phone-context=000000>
CSeq: 1 INVITE
Contact: <sip:001#19193920002@172.18.194.80>
Content-Length: 0
v=0
o=CiscoSystemsSIP- Gateway 537556  235334 IN IP4 172.18.194.80
s=SIP Call
t=0 0
c=IN IP4 gateway.cisco.com
m=audio 5004 RTP/AVP 0 3
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
Step 10

SIP 200 OK—SIP proxy server forward the 200 OK to the calling UAC
SIP proxy server receives the 200 OK from the gateway. It forwards it upstream to the calling UAC.

Example
SIP/2.0 200 OK
Via: SIP/2.0/UDP 161.44.3.207:49489
Record-Route: < sip:001#19193920002@proxy.cisco.com; 
maddr=proxy.cisco.com>
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:20002@company.com;user=phone;phone-context=000000>
CSeq: 1 INVITE
Contact: <sip:001#19193920002@172.18.194.80>
Content-Length: 0
v=0
 o=CiscoSystemsSIP- Gateway 537556  235334 IN IP4 172.18.194.80
s=SIP Call
t=0 0
c=IN IP4 gateway.cisco.com
m=audio 5004 RTP/AVP 0 3
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
Step 11

SIP ACK—Calling UAC sends ACK to the SIP proxy
The caller UAC opens the media port and responds with an ACK to the SIP proxy.

Example
SIP/2.0 ACK
Via: SIP/2.0/UDP 161.44.3.207:49489
Route: <sip:001#19193920002@172.18.194.80>
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:20002@company.com;user=phone;phone-context=000000>
CSeq: 1 ACK
Step 12

SIP ACK—SIP proxy forwards an ACK to the gateway
SIP proxy server forwards the ACK to the downstream gateway.

Example
SIP/2.0 ACK
Via: SIP/2.0/UDP 172.18.194.80:48987
Via: SIP/2.0/UDP 161.44.3.207:49489
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:20002@company.com;user=phone;phone-context=000000>
CSeq: 1 ACK
Step 13

SIP BYE—Gateway sends BYE to the SIP proxy
The callee hang up the phone. The gateway sends a BYE to the SIP proxy.

Example
SIP/2.0 BYE sip: +19195550001@bounty.cisco.com
Via: SIP/2.0/UDP 172.18.194.80:5060
Route: < sip: +19195550001@ bounty.cisco.com >
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: <sip:+19193920002@company.com;user=phone>
To: "555-0001" <sip:+19195550001@bounty.cisco.com>
CSeq: 1 BYE
Step 14

SIP BYE—SIP proxy forwards BYE to the calling party
SIP proxy server receives the BYE from the gateway and forwards it upstream to the calling user agent.

Example
SIP/2.0 BYE sip: +19195550001@ bounty.cisco.com:5060
Via: SIP/2.0/UDP 172.18.194.80:5060
Via: SIP/2.0/UDP 172.18.194.80:43576
Record-Route: <sip: +19195550001@proxy.cisco.com>
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: <sip:+19193920002@company.com;user=phone>
To: "555-0001" <sip:+19195550001@bounty.cisco.com>
CSeq: 1 BYE
Step 15

SIP 200 OK—Calling UAC returns a 200 OK to the SIP proxy
The calling UAC receives the BYE from the gateway, it returns a 200 OK to the SIP proxy.

Example
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.18.194.80:43576
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: <sip:+19193920002@company.com;user=phone>
To: "555-0001" <sip:+19195550001@bounty.cisco.com>
CSeq: 1 BYE
Step 16

SIP 200 OK—SIP proxy forwards the 200 OK to the gateway
SIP proxy receives the 200 OK from the calling UAC and forwards it to the gateway.

Example
SIP/2.0 200 OK
Via: SIP/2.0/UDP proxy.cisco.com:5060
Via: SIP/2.0/UDP 172.18.194.80:43576
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: <sip:+19193920002@company.com;user=phone>
To: "555-0001" <sip:+19195550001@bounty.cisco.com>
CSeq: 1 BYE
SIP Phone to SIP/H.323 Gateway—Call via SIP Redirect Server

Figure F-20 Call via SIP Redirect Server
Action

Description
Step 1

INVITE—SIP phone to SIP redirect server
SIP UAC sends an INVITE request to the SIP redirect server.

Example
INVITE sip:50002@redirect.cisco.com;user=phone;phone-context=000000 
SIP/2.0
Via: SIP/2.0/UDP 161.44.3.207:49489
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:50002@company.com;user=phone;phone-context=000000>
Date: Thu, 18 Mar 2000 04:48:28 UTC
Call-ID: 23-99990146-0-5894369F@161.44.3.207
Cisco-Guid: 428806444-2576941380-0-1486104925
User-Agent: Cisco IP Phone
CSeq:1 INVITE
Max-Forwards: 6
Timestamp: 732430108
Contact: <sip:+19195550001@bounty.cisco.com:49489;user=phone>
Expires: 5
Content-Type: application/sdp
v=0
o=CiscoSystemsSIP- UserAgent 8870 5284 IN IP4 172.18.193.101
s=SIP Call
t=0 0
c=IN IP4 172.18.193.101
m=audio 20354 RTP/AVP 0 3
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
The following applies:

•The phone number of called party is inserted in the Request-URI field in the form of a SIP URL.

•A unique numeric identifier is assigned to the call and is inserted in the Call-ID field.

•The transaction number within a single call leg is identified in the Cseq field.

•The media capability the calling party is ready to receive is specified.
Step 2

100—Trying SIP redirect server returns 100 Trying to UAC
SIP redirect server sends 100-Trying response message to the upstream UAC upon receiving the INVITE in step 1.

Example
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 161.44.3.207:49489
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:50002@company.com;user=phone;phone-context=000000>
CSeq: 1 INVITE
Content-Length: 0
Step 3

RAS LRQ—SIP redirect server sends a RAS LRQ message to a DGK
The SIP redirect server expands the 50002 number into a 9193650002 number but finds no static route. It then invokes the new routing module and creates an LRQ RAS message from the incoming INVITE SIP message. The LRQ message is sent to one of the DGK configured in the sipd.conf file.

The SIP redirect server prepends a technology prefix 002# to the expanded number and uses it to fill the destinationInfo field of the LRQ RAS message.

Example
value RasMessage ::= locationRequest :
{
        requestSeqNum 2519
        destinationInfo
        {
          e164 : "002#19193650002"
        }
        nonStandardData
        {
          nonStandardIdentifier h221NonStandard :
          {
            t35CountryCode 181
            t35Extension 0
            manufacturerCode 18
          }
data '8284901100ECAA98A025220008000000000E1963...'H
        }
        replyAddress ipAddress :
        {
          ip 'AC12C247'H
          port 1719
        }
        sourceInfo
        {
          h323-ID : {"genuity-sip1"}
        }
        canMapAlias TRUE
      }
Step 4

RAS RIP—H.323 DGK returns a RIP to the SIP redirect server
Upon receiving the RAS LRQ message from the SIP redirect server, the H.323 DGK can return a RIP with delay timer value. SIP server should adjust timer accordingly.

Example
value RasMessage ::= requestInProgress :
{
        requestSeqNum 2519
        delay 9000
         }
Step 5

RAS LCF—H.323 DGK returns a LCF to the SIP redirect server
The H.323 DGK forwards the request to the H.323 network and finds a SIP/H.323 gateway that can handle this particular call. It then returns a RAS LCF message to the SIP redirect server.

Example
value RasMessage ::= locationConfirm :
      {
        requestSeqNum 2519
        callSignalAddress ipAddress :
        {
          ip 'AC12C250'H
          port 1720
        }
        rasAddress ipAddress :
        {
          ip 'AC12C250'H
          port 56812
        }
        nonStandardData
        {
          nonStandardIdentifier h221NonStandard :
          {
            t35CountryCode 181
            t35Extension 0
            manufacturerCode 18
          }
          data '0002400900630033003600320030002D0032002D...'H
        }
        destinationType
        {
          gateway
          {
            protocol
            {
              voice :
              {
                supportedPrefixes
                {
                }
              }
            }
          }
          mc FALSE
          undefinedNode FALSE
        }
      }
value LCFnonStandardInfo ::=
      {
        termAlias
        {
          h323-ID : {"c3620-2-gw"},
          e164 : "4056701000"
        }
        gkID {"c3620-1-gk"}
        gateways
        {
          {
            gwType voip : NULL
            gwAlias
            {
              h323-ID : {"c3620-2-gw"},
              e164 : "002#19193650002"
            }
            sigAddress
            {
              ip 'AC12C250'H
              port 1720
            }
            resources
            {
              maxDSPs 0
              inUseDSPs 0
              maxBChannels 0
              inUseBChannels 0
              activeCalls 0
              bandwidth 0
              inuseBandwidth 0
            }
          }
        }
      }
Step 6

SIP 302 Moved Temporarily—SIP redirect server sends a 302 Moved Temporarily to the UAC
The SIP redirect server receives the RAS LCF message, decodes it, and obtains the gateway transport address (172.18.194.80) from the callSignalAddress ipAddress field of the LCF message. It then adds the SIP port number (5060) and returns the 302 Moved Temporarily message back to the UAC. Since the 002# tech-prefix flag is turned off in the sipd.conf file, the 002# string is stripped from the contact header.

Example
SIP/2.0 302 MovedTemporarily
Via: SIP/2.0/UDP  161.44.3.207:49489
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:50002@company.com;user=phone;phone-context=000000>
CSeq: 1 INVITE
Contact: <sip:19193650002@172.18.194.80:5060>
Content-Length: 0
Step 7

SIP ACK—UAC returns a SIP ACK to the redirect server
Upon receiving of the 302 response message, the UAC returns a SIP ACK to the redirect server.

Example
SIP/2.0 ACK
Via: SIP/2.0/UDP 161.44.3.207:49489
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:50002@company.com;user=phone;phone-context=000000>
CSeq: 1 ACK
Step 8

SIP INVITE—UAC sends directly to the gateway
The UAC sends a new INVITE directly to the gateway.

Example
INVITE sip:19193650002@172.18.194.80:5060; 
user=phone;phone-context=000000 SIP/2.0
Via: SIP/2.0/UDP  161.44.3.207:49489
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:50002@company.com;user=phone;phone-context=000000>
Date: Thu, 18 Mar 2000 04:48:28 UTC
Call-ID: 23-99990146-0-5894369F@161.44.3.207
Cisco-Guid: 428806444-2576941380-0-1486104925
User-Agent: Cisco IP Phone
CSeq: 2 INVITE
Max-Forwards: 6
Timestamp: 732430108
Contact: <sip:+19195550001@bounty.cisco.com:49489;user=phone>
Expires: 5
Content-Type: application/sdp
v=0
o=CiscoSystemsSIP- UserAgent 8870 5284 IN IP4 172.18.193.101
s=SIP Call
t=0 0
c=IN IP4 172.18.193.101
m=audio 20354 RTP/AVP 0 3
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
Step 9

SIP 180 Ringing—Gateway sends 180 Ringing back to the UAC
The SIP/H.323 gateway receives the SIP INVITE message from the UAC and sends it downstream. Assume the call signal reaches the end-point and a SIP 180 Ringing is sent from the gateway to the UAC.

Example
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 161.44.3.207:49489
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:50002@company.com;user=phone;phone-context=000000>
CSeq: 2 INVITE
Content-Length: 0
Step 10

SIP 200 OK—Gateway sends 200 OK to the calling UAC
The called party picks up the phone and the gateway sends 200 OK to the calling UAC.

Example
SIP/2.0 200 OK
Via: SIP/2.0/UDP 161.44.3.207:49489
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:50002@company.com;user=phone;phone-context=000000>
CSeq: 2 INVITE
Content-Length: 0
v=0
 o=CiscoSystemsSIP- Gateway 537556 235334 IN IP4 172.18.194.80
s=SIP Call
t=0 0
c=IN IP4 gateway.cisco.com
m=audio 5004 RTP/AVP 0 3
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
Step 11

SIP ACK—Calling UAC sends ACK to the gateway
Upon receiving the 200 OK message, the UAC opens the media port and responds with ACK to the gateway.

Example
SIP/2.0 ACK
Via: SIP/2.0/UDP 161.44.3.207:49489
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:50002@company.com;user=phone;phone-context=000000>
CSeq: 2 ACK
Step 12

SIP BYE—Gateway sends BYE to the calling UAC
User hangs up the phone. The gateway sends a BYE to the calling UAC.

Example
SIP/2.0 BYE sip:+19195550001@bounty.cisco.com
Via: SIP/2.0/UDP 172.18.194.80:43576
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: <sip:+1913650002@company.com;user=phone>
To: "555-0001" <sip:+19195550001@bounty.cisco.com>
CSeq: 1 BYE
Step 13

SIP 200 OK—Calling UAC returns a 200 OK to the gateway
Calling UAC receives the BYE from the gateway, it returns a 200 OK.

Example
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.18.194.80:43576
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: <sip:+19193650002@company.com;user=phone>
To: "555-0001" <sip:+19195550001@bounty.cisco.com>
CSeq: 1 BYE
SIP Phone-to-SIP/H.323 Gateway—Call via SIP Proxy Server with Record-Route Disabled (Call Failed with a 503 Service Unavailable Response)

Figure F-21 Call via SIP Proxy Server with Record-Route disabled (Call failed with a 503 Service Unavailable response)
Action

Description
Step 1

INVITE-SIP phone to SIP proxy server
SIP UAC sends an INVITE request to the SIP proxy server.

Example
INVITE sip:50002@proxy.cisco.com;user=phone;phone-context=000000 
SIP/2.0
Via: SIP/2.0/UDP 161.44.3.207:49489
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:50002@company.com;user=phone;phone-context=000000>
Date: Thu, 18 Mar 2000 04:48:28 UTC
Call-ID: 23-99990146-0-5894369F@161.44.3.207
Cisco-Guid: 428806444-2576941380-0-1486104925
User-Agent: Cisco IP Phone
CSeq:1 INVITE
Max-Forwards: 6
Timestamp: 732430108
Contact: <sip:+19195550001@bounty.cisco.com:49489;user=phone>
Expires: 5
Content-Type: application/sdp
v=0
o=CiscoSystemsSIP- UserAgent 8870 5284 IN IP4 172.18.193.101
s=SIP Call
t=0 0
c=IN IP4 172.18.193.101
m=audio 20354 RTP/AVP 0 3
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
The following applies:

•The phone number of called party is inserted in the Request-URI field in the form of a SIP URL.

•A unique numeric identifier is assigned to the call and is inserted in the Call-ID field.

•The transaction number within a single call leg is identified in the Cseq field.

The media capability the calling party is ready to receive is specified.
Step 2

100-Trying SIP Proxy sends to UAC
SIP proxy server sends 100-Trying response message to the upstream UAC upon receiving the INVITE in step 1.

Example
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 161.44.3.207:49489
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:50002@company.com;user=phone;phone-context=000000>
CSeq: 1 INVITE
Content-Length: 0
Step 3

RAS LRQ—SIP Proxy sends a RAS LRQ message to a DGK
SIP proxy server expands the 50002 number into a 9193650002 number but finds no static route to route the request. It then invokes the new routing module, creates an LRQ RAS message from the incoming INVITE SIP message, and sends the LRQ message to one of the DGK configured in the sipd.conf file.

SIP proxy server adds a technology prefix 002# to the expanded number and uses it to fill the destinationInfo field of the LRQ RAS message.

Example
value RasMessage ::= locationRequest :
{
        requestSeqNum 2519
        destinationInfo
        {
          e164 : "002#19193650002"
        }
        nonStandardData
        {
          nonStandardIdentifier h221NonStandard :
          {
            t35CountryCode 181
            t35Extension 0
            manufacturerCode 18
          }
data '8284901100ECAA98A025220008000000000E1963...'H
        }
        replyAddress ipAddress :
        {
          ip 'AC12C247'H
          port 1719
        }
        sourceInfo
        {
          h323-ID : {"genuity-sip1"}
        }
        canMapAlias TRUE
      }
Step 4

RAS RIP—H.323 DGK returns a RIP to the SIP proxy server
Upon receiving the RAS LRQ message from the SIP proxy server, the H.323 DGK can return a RIP with delay timer value. SIP server should adjust timer accordingly.

Example
value RasMessage ::= requestInProgress :
{
        requestSeqNum 2519
        delay 9000
         }
Step 5

RAS LCF—H.323 DGK returns a LCF to the SIP proxy server
The H.323 DGK forwards the request to the H.323 network and finds a SIP/H.323 gateway that can handle this particular call. It then returns a RAS LCF message to the SIP proxy server.

Example
value RasMessage ::= locationConfirm :
      {
        requestSeqNum 2519
        callSignalAddress ipAddress :
        {
          ip 'AC12C250'H
          port 1720
        }
        rasAddress ipAddress :
        {
          ip 'AC12C250'H
          port 56812
        }
        nonStandardData
        {
          nonStandardIdentifier h221NonStandard :
          {
            t35CountryCode 181
            t35Extension 0
            manufacturerCode 18
          }
          data '0002400900630033003600320030002D0032002D...'H
        }
 destinationType
        {
          gateway
          {
            protocol
            {
              voice :
              {
                supportedPrefixes
                {
              }
            }
          }
          mc FALSE
          undefinedNode FALSE
        }
      }
value LCFnonStandardInfo ::=
      {
        termAlias
        {
          h323-ID : {"c3620-2-gw"},
          e164 : "002#19193650002"
        }
        gkID {"c3620-1-gk"}
        gateways
        {
          {
            gwType voip : NULL
            gwAlias
            {
              h323-ID : {"c3620-2-gw"},
              e164 : "002#19193650002"
            }
            sigAddress
            {
              ip 'AC12C250'H
              port 1720
            }
            resources
            {
              maxDSPs 0
              inUseDSPs 0
              maxBChannels 0
              inUseBChannels 0
              activeCalls 0
              bandwidth 0
              inuseBandwidth 0
          }
        }
      }
}
Step 6

SIP INVITE—SIP proxy server forwards the INVITE to the gateway
SIP proxy server receives the RAS LCF message, decodes it, and obtains the gateway transport address (172.18.194.80) from the callSignalAddress ipAddress field of the LCF message. It then adds the SIP port number (5060) and forwards the INVITE to the gateway. Since the 002# tech-prefix flag is turned off in the sipd.conf file, the 002# string is stripped from the request-URI.

Example
INVITE sip: 19193650002@172.18.194.80:5060; 
user=phone;phone-context=000000 SIP/2.0
Via: SIP/2.0/UDP proxy.cisco.com:48754; branch=1
Via: SIP/2.0/UDP  161.44.3.207:49489
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:50002@company.com;user=phone;phone-context=000000>
Date: Thu, 18 Mar 2000 04:48:28 UTC
Call-ID: 23-99990146-0-5894369F@161.44.3.207
Cisco-Guid: 428806444-2576941380-0-1486104925
User-Agent: Cisco IP Phone
CSeq:1 INVITE
Max-Forwards: 6
Timestamp: 732430108
Contact: <sip:+19195550001@bounty.cisco.com:49489;user=phone>
Expires: 5
Content-Type: application/sdp
v=0
o=CiscoSystemsSIP- UserAgent 8870 5284 IN IP4 172.18.193.101
s=SIP Call
t=0 0
c=IN IP4 172.18.193.101
m=audio 20354 RTP/AVP 0 3
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
Step 7

SIP 100 Trying—Gateway sends 100 Trying back to the SIP proxy server
The SIP/H.323 gateway receives the forwarded SIP INVITE message from the SIP proxy server and sends 100-Trying back to the SIP proxy server.

Example
SIP/2.0 100 Trying
Via: SIP/2.0/UDP proxy.cisco.com:48754; branch=1
Via: SIP/2.0/UDP 161.44.3.207:49489
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:50002@company.com;user=phone;phone-context=000000>
CSeq: 1 INVITE
Content-Length: 0
Step 8

SIP 100-Trying—SIP proxy server forwards to the UAC
SIP proxy server receives the 100-Trying from the gateway. It finds the record in TCB and forwards the 100-Trying upstream to the UAC.

Example
SIP/2.0 100-Trying
Via: SIP/2.0/UDP proxy.cisco.com:48754; branch=1
Via: SIP/2.0/UDP 161.44.3.207:49489
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:50002@company.com;user=phone;phone-context=000000>
CSeq: 1 INVITE
Content-Length: 0
Step 9

SIP 503 Service Unavailable— Gateway sends 503 Service Unavailable to upstream SIP proxy server
The gateway overloaded and sends a 503 Service Unavailable to the upstream SIP proxy server.

Example
SIP/2.0 503 Service Unavailable
Via: SIP/2.0/UDP proxy.cisco.com:48754; branch=1
Via: SIP/2.0/UDP 161.44.3.207:49489
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:50002@company.com;user=phone;phone-context=000000>
CSeq: 1 INVITE
Content-Length: 0
Step 10

SIP 503 Service Unavailable—SIP proxy server forwards the 503 Service Unavailable to the calling UAC
SIP proxy server receives the 503 Service Unavailable from the gateway and forwards it upstream to the calling UAC.

Example
SIP/2.0 503 Service Unavailable
Via: SIP/2.0/UDP 161.44.3.207:49489
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:50002@company.com;user=phone;phone-context=000000>
CSeq: 1 INVITE
Content-Length: 0
Step 11

SIP ACK—Calling UAC sends ACK to the SIP proxy server
Upon receiving the 503 Service Unavailable message, the UAC responds with ACK to the SIP proxy server.

Example
SIP/2.0 ACK
Via: SIP/2.0/UDP 161.44.3.207:49489
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:50002@company.com;user=phone;phone-context=000000>
CSeq: 1 ACK
Step 12

SIP ACK—SIP proxy server sends ACK to the downstream gateway
Upon receiving the ACK from UAC, the SIP proxy server forwards the ACK to the downstream gateway.

Example
SIP/2.0 ACK
Via: SIP/2.0/UDP proxy.cisco.com:48754; branch=1
Via: SIP/2.0/UDP 161.44.3.207:49489
Call-ID: 23-99990146-0-5894369F@161.44.3.207
From: "555-0001" <sip:+19195550001@bounty.cisco.com>
To: <sip:50002@company.com;user=phone;phone-context=000000>
CSeq: 1 ACK