SIP Call-Flow Scenarios: Message Types

E-1
Cisco SIP Proxy Server Administrator Guide

A P P E N D I X E
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.
Contents
SIP Messages, page E-1
Call-Flow Scenarios for Successful Calls, page E-3
Call-Flow Scenarios for Failed Calls, page E-29
Call-Flow Scenarios with CLIR Support, page E-72
Note For more troubleshooting information, see Chapter 5, Troubleshooting.
SIP Messages
Message Types
All SIP messages are either requests from a server or client or responses to a request (see Table E-1).
Table E-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

E-2
Appendix E SIP Call-Flow Scenarios
SIP Messages
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.
Response SIP 1xx Informational
SIP 2xx Successful
SIP 3xx Redirection
SIP 4xx Client failure
SIP 5xx Server failure
SIP 6xx Global failure
Table E-1 SIP Message Types (continued)
Type Message Action or Indication

E-3

Call-Flow Scenarios for Successful Calls
This section describes call flows for the following successful-call scenarios:
SIP Gateway to SIP Gatewayvia SIP Redirect Server, page E-3
SIP Gateway to SIP Gatewayvia SIP Proxy Server, page E-6
SIP IP Phone to SIP IP PhoneCall Forward Unconditionally, page E-13
SIP IP Phone to SIP IP PhoneCall Forward on Busy, page E-17
SIP IP Phone to SIP IP PhoneCall Forward No Answer, page E-21
SIP IP Phone to SIP IP PhoneCall Forward Unavailable, page E-25
Note The messages shown are examples for reference only.
SIP Gateway to SIP Gatewayvia SIP Redirect Server
Figure E-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 Bs 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.

E-4
Figure E-1 SIP Gateway to SIP Gatewayvia SIP Redirect Server
Action Description
Step 1 SetupPBX 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 INVITESIP 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.
3. 300 Multiple
Choice
12. Alerting
2-way RTP channel
2-way voice
path
2-way voice
path
17. ACK
21.
Disconnect
1-way VP
15. Connect
7. Call
Proceeding
1. Setup
2. INVITE
4. ACK
PBX A
User A
GW1
RS
IP network GW2 PBX B
User B
19. Disconnect
13. Connect
9. Call
Proceeding
10. Alerting
6. Setup
1-way VP
18. Connect
ACK
22. Release
25. Release
Complete
8. 100 Trying
11. 180 Ringing
2-way RTP channel
20. BYE
5. INVITE
14. 200 OK
24. 200 OK
16. Connect
ACK
26. Release
Complete
23. Release
2
8
9
3
8

E-5

Step 3 300 Multiple ChoiceSIP
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 Bs 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 ACKSIP gateway 1 to SIP
redirect server
SIP gateway 1 acknowledges the 300 Multiple Choice response with an ACK.
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 SetupSIP gateway 2 to PBX B SIP gateway 2 receives the INVITE request from SIP gateway 1 and initiates a
call setup with user B via PBX B.
Step 7 Call ProceedingSIP 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 TryingSIP gateway 2 to
SIP gateway 1
SIP gateway 2 sends a 100 Trying response to the INVITE request sent by SIP
gateway 1. The response indicates that the INVITE request was received by SIP
gateway 2, but that user B is not yet located.
Step 9 Call ProceedingPBX B to SIP
gateway 2
PBX B sends a Call Proceeding message to SIP gateway 2 to acknowledge the
call-setup request.
Step 10 AlertingPBX B to SIP
gateway 2
PBX B locates user B and sends an Alert message to SIP gateway 2. User Bs
phone begins to ring.
Step 11 180 RingingSIP 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 AlertingSIP 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 ConnectPBX 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 OKSIP 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 As 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 ConnectSIP 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 ACKPBX A to SIP
gateway 1
PBX A acknowledges SIP gateway 1s Connect message.
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.
Action Description

E-6
SIP Gateway to SIP Gatewayvia SIP Proxy Server
Figure E-2 and Figure E-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 Bs phone number is 555-0002.
In the scenario illustrated by Figure E-2, the record route feature is enabled on the proxy server. In the
scenario illustrated by Figure E-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.
Step 18 Connect ACKSIP gateway 2
to PBX B
SIP gateway 2 acknowledges PBX Bs 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
Step 19 DisconnectPBX B to SIP
gateway 2
Once user B hangs up, PBX B sends a Disconnect message to SIP gateway 2. The
Disconnect message starts the call session termination process.
Step 20 BYESIP 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 As SIP URL and the From
field contains user Bs SIP URL.
Step 21 DisconnectSIP gateway 1 to
PBX A
SIP gateway 1 sends a Disconnect message to PBX A.
Step 22 ReleaseSIP gateway 2 to
PBX B
SIP gateway 2 sends a Release message to PBX B.
Step 23 ReleasePBX A to SIP
gateway 1
PBX A sends a Release message to SIP gateway 1.
gateway 2
SIP gateway 2 that SIP gateway 1 has received the BYE request.
Step 25 Release CompletePBX B to
SIP gateway 2
PBX B sends a Release Complete message to SIP gateway 2.
Step 26 Release CompleteSIP
gateway 1 to PBX A
SIP gateway 1 sends a Release Complete message to PBX A and the session is
terminated.
Action Description

E-7

Figure E-2 SIP Gateway to SIP Gatewayvia SIP Proxy Server: Record Route Enabled
2-way RTP channel
11. 180 Ringing
5. 100 Trying
15. 200 OK
1-way voice
path
7. 100 Trying
10. 180 Ringing
14. 200 OK
22. BYE
12. Alerting
2-way RTP channel
16. Connect
24.
Disconnect
3. Call
Proceeding
1. Setup
17. Connect
ACK
1-way voice
path
2-way voice
path
2-way voice
path
8. Call
Proceeding
9. Alerting
21. Disconnect
29. Release
Complete
13. Connect
6. Setup
25.Release
20. Connect
ACK
2. INVITE
18. ACK
27. 200 OK
PBX A
User A
GW1
Proxy
server IP network GW2
PBX B
User B
23. BYE
4. INVITE
19. ACK
28. 200 OK
30. Release
Complete
26. Release
2
8
9
4
2

E-8
Action Description
Step 2 INVITESIP 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:
of a SIP URL.
field.
to PBX A
call-setup request.
Step 4 INVITESIP 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 TryingSIP proxy server to
SIP gateway 1
SIP proxy server sends a 100 Trying response to SIP gateway 1.
Step 6 SetupSIP 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.
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.
gateway 2
call-setup request.
gateway 2
SIP proxy server
SIP gateway 2 sends a 180 Ringing response to the SIP proxy server.
Step 11 180 RingingSIP proxy server
to SIP gateway 1
SIP proxy server forwards the 180 Ringing response to SIP gateway 1.
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
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.

E-9

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.
the SIP proxy server, it advertises the intersection of its own and user As media
header field.
SIP proxy server must forward 200 OK responses upstream.
Step 15 200 OKSIP 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.
PBX A
gateway 1
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 ACKSIP 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 1s ACK response to SIP gateway 2.
to PBX B
SIP gateway 2 acknowledges PBX Bs 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.
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.
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 As SIP URL and the
From field contains user Bs SIP URL.
Step 23 BYESIP proxy server to SIP
gateway 1
SIP proxy server forwards the BYE request to SIP gateway 1.
PBX A
PBX B
After the call is completed, SIP gateway 2 sends a Release message to PBX B.
Action Description

E-10
Figure E-3 SIP Gateway to SIP Gatewayvia a Proxy Server: Record Route Disabled
gateway 1
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.
SIP gateway 2
SIP proxy server forwards the 200 OK response to SIP gateway 2.
SIP gateway 2
gateway 1 to PBX A
SIP gateway 1 sends a Release Complete message to PBX A and the call session
is terminated.
Action Description
3. Call Proceeding
12. Alerting
22. Disconnect
16. Connect
17. Connect ACK
6. Setup
23. Release
19. Connect
ACK
8. Call
Proceeding
26. Release
Complete
27. Release
Complete
9. Alerting
13. Connect
20. Disconnect
1. Setup
24. Release
PBX A PBX B
User A User B
GW1
Proxy
server
GW2 IP network
5. 100 Trying
15. 200 OK
18. ACK
21. BYE
10. 180 Ringing
7. 100 Trying
14. 200 OK
11. 180 Ringing
2. INVITE
2-way voice path
2-way RTP channel
2-way RTP channel
1-way voice path
1-way voice
path
2-way voice
path
4. INVITE
25. 200 OK
3
2
7
0
7

E-11

Action Description
proxy server
of a SIP URL.
field.
The media capability that A is ready to receive is specified.
to PBX A
call-setup request.
SIP gateway 2
SIP gateway 1
SIP proxy server
gateway 2
call-setup request.
gateway 2
SIP proxy server
SIP gateway 2 sends a 180 Ringing response to the SIP proxy server.
to SIP gateway 1
SIP proxy server forwards the 180 Ringing response to SIP gateway 1.
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
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.

E-12
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.
the SIP proxy server, it advertises the intersection of its own and user As media
header field.
SIP proxy server must forward 200 OK responses upstream.
SIP gateway 1
SIP proxy server forwards the 200 OK response that it received from SIP
gateway 2 to SIP gateway 1.
PBX A
gateway 1
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.
to PBX B
SIP gateway 2 acknowledges PBX Bs 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.
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.
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 As SIP URL and the From
field contains user Bs SIP URL.
PBX A
PBX B
After the call is completed, SIP gateway 2 sends a Release message to PBX B.
gateway 1
gateway 2
SIP gateway 2 that SIP gateway 1 has received the BYE request.
SIP gateway 2
gateway 1 to PBX A
is terminated.
Action Description

E-13

SIP IP Phone to SIP IP PhoneCall Forward Unconditionally
Figure E-4 and Figure E-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. Bobs calls are configured
to forward to Carol unconditionally. Figure E-4 illustrates the call as processed by a recursive proxy and
Figure E-5 illustrates the call as processed by a nonrecursive proxy.
Figure E-4 SIP IP Phone to SIP IP PhoneCall Forward Unconditionally via Recursive Proxy
IP IP IP
7. ACK
1. INVITE Bob@company.com
3. 180 Ringing
5. 200 OK
2-way RTP channel 1 between SIP IP phones A and C established
6. 200 OK
4. 180 Ringing
4
9
8
2
3
Proxy Server
(recursive)
IP Network
SIP IP
Phone A
Bob Carol Alice
SIP IP
Phone B
SIP IP
Phone C
2. INVITE Carol@IPphoneC.company.com
CC-Diversion: Bob@company.com, ;reason="unconditional"

E-14
Action Description
Step 1 INVITESIP IP phone A to SIP
proxy server
Alices 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:
Bobs 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.
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.
SIP IP phone C
SIP proxy server determines that Bobs 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 RingingSIP IP phone C to
SIP proxy server
Phone C sends a 180 Ringing response to the SIP proxy server.
to SIP IP phone A
SIP proxy server forwards the 180 Ringing response to phone A.
Step 5 200 OKSIP 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 As
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 ACKSIP IP phone A to SIP IP
phone C
Phone A sends an ACK to phone C. The ACK confirms that user As phone has
received the 200 OK response from user Cs phone.
Note At this point, a two-way RTP channel is established between SIP IP phone A and SIP IP phone C.

E-15

Figure E-5 SIP IP Phone to SIP IP PhoneCall Forward Unconditionally via Nonrecursive Proxy
Action Description
proxy server
URL.
field.
SDP.
Step 2 302 Moved TemporarilySIP
proxy server to SIP IP phone A
SIP proxy server determines that Bobs 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.
IP IP IP
2. 302 Moved Temporarily
6. ACK
4. 180 Ringing
5. 200 OK
4
9
8
2
2
Proxy Server
(non-recursive)
IP Network
SIP IP
Phone A
Bob Carol Alice
SIP IP
Phone B
SIP IP
Phone C
CC-Diversion: Bob@company.com, ;reason="unconditional"
Contact: Carol@IPphoneC.company.com
CC-Diversion: Bob@company.com,
;reason="unconditional"

E-16
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
SIP proxy server
Phone C sends a 180 Ringing response to phone A.
IP phone A
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.
Action Description

E-17

SIP IP Phone to SIP IP PhoneCall Forward on Busy
Figure E-6 and Figure E-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 Bs
calls are configured to forward to user C when user Bs SIP IP phone sends a 486 Busy Here response.
Figure E-6 illustrates the call as processed by a recursive proxy and Figure E-7 illustrates the call as
processed by a nonrecursive proxy.
Figure E-6 SIP IP Phone to SIP IP PhoneCall Forward on Busy via Recursive Proxy
IP IP IP
7 180 Ringing
10. ACK
3. 486 Busy Here
8. 200 OK
6. 180 Ringing
CC-Diversion: Bob@company.com, ;reason="user-busy"
2. INVITE Bob@IPphoneB.company.com
4. ACK
9. 200 OK
4
9
8
2
0
Proxy Server
(recursive)
IP Network
SIP IP
Phone A
Bob Carol Alice
SIP IP
Phone B
SIP IP
Phone C

E-18
Action Description
proxy server
URL.
field.
SDP.
SIP IP phone B
The proxy server forwards the INVITE request to Bob at phone B.
Step 3 486 Busy HereSIP 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.
SIP IP phone C
SIP proxy server sends an INVITE request to Carol at phone C to which Bobs
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.
SIP proxy server
to SIP IP phone A
SIP proxy server forwards the 180 Ringing response to phone A.
proxy server
Phone C sends a 200 OK response to phone A.
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).
phone C

E-19

Figure E-7 SIP IP Phone to SIP IP PhoneCall Forward on Busy via Nonrecursive Proxy
Action Description
proxy server
URL.
field.
SDP.
SIP IP phone B
SIP proxy server forwards the INVITE request to Bob at phone B.
IP IP IP
9. ACK
7. 180 Ringing
8. 200 OK
4
9
8
2
6
Proxy Server
(non-recursive)
IP Network
SIP IP
Phone A
Bob Carol Alice
SIP IP
Phone B
SIP IP
Phone C
CC-Diversion: Bob@company.com, ;reason="user-busy"
;reason="user-busy"
3. 486 Busy
4. ACK

E-20
Step 3 486 Busy HereSIP 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.
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.
SIP IP phone C
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.
SIP IP phone A
IP phone A
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.
phone C
Action Description

E-21

SIP IP Phone to SIP IP PhoneCall Forward No Answer
Figure E-8 and Figure E-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 Bs calls are configured to forward to user C when an response timeout occurs. Figure E-8
illustrates the call as processed by a recursive proxy and Figure E-9 illustrates the call as processed by
a nonrecursive proxy.
Figure E-8 SIP IP Phone to SIP IP PhoneCall Forward No Answer via Recursive Proxy
IP IP IP
8. ACK
5. 180 Ringing
6. 200 OK
7. 200 OK
4
9
8
2
5
Proxy Server
(recursive)
IP Network
SIP IP
Phone A
Bob Carol Alice
SIP IP
Phone B
SIP IP
Phone C
CC-Diversion: Bob@company.com, ;reason="no-answer"
Call forward no answer timeout occurs
3. 180 Ringing

E-22
Action Description
proxy server
URL.
field.
SDP.
SIP IP phone B
The proxy server forwards the INVITE request to Bob at phone B.
Step 3 180 RingingSIP 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 INVITESIP proxy server
phone to SIP IP phone C
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
SIP proxy server
proxy server
SIP IP phone A
phone A that Carol has answered the phone (for example, the handset went
off-hook).
phone C

E-23

Figure E-9 SIP IP Phone to SIP IP PhoneCall Forward No Answer via Nonrecursive Proxy
Action Description
proxy server
URL.
field.
SDP.
SIP IP phone B
IP IP IP
8. ACK
6. 180 Ringing
7. 200 OK
4
9
8
2
4
Proxy Server
(non-recursive)
IP Network
SIP IP
Phone A
Bob Carol Alice
SIP IP
Phone B
SIP IP
Phone C
CC-Diversion: Bob@company.com, ;reason="no-answer"
Call forward no answer timeout occurs
;reason="no-answer"
3. 180 Ringing

E-24
Step 3 180 RingingSIP 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.
IP phone C
Phone A sends an INVITE request to Carol at phone C to which Bobs 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.
SIP IP phone A
IP phone A
phone C
Action Description

E-25

SIP IP Phone to SIP IP PhoneCall Forward Unavailable
Figure E-10 and Figure E-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 Bs calls are configured to forward to user C when user B is unavailable.
Figure E-10 illustrates the call as processed by a recursive proxy and Figure E-11 illustrates the call as
processed by a nonrecursive proxy.
Figure E-10 SIP IP Phone to SIP IP PhoneCall Forward Unavailable via Recursive Proxy
IP IP IP
2. 100 Trying
10. ACK
8. 200 OK
7. 180 Ringing
Call forward unavailable timeout occurs
9. 200 OK
4
9
8
2
1
Proxy Server
(recursive)
IP Network
SIP IP
Phone A
Bob Carol Alice
SIP IP
Phone B
SIP IP
Phone C
CC-Diversion: Bob@company.com, ;reason="unavailable"

E-26
Action Description
proxy server
URL.
field.
SDP.
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 INVITEproxy server to SIP IP
phone B
Step 4
Step 5
Note Call forward unavailable timer expires.
SIP IP phone C
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
SIP proxy server
proxy server
SIP IP phone A
phone A that Carol has answered the phone (for example, the handset went
off-hook).
phone B

E-27

Figure E-11 SIP IP Phone to SIP IP PhoneCall Forward Unavailable via Nonrecursive Proxy
IP IP
2. 100 Trying
10. ACK
8. 180 Ringing
Call forward unavailable timeout occurs
9. 200 OK
Proxy Server
(non-recursive)
IP Network
SIP IP
Phone A
Bob Alice
SIP IP
Phone B
SI
Pho
CC-Diversion: Bob@company.com, ;reason="unavailable"
;reason="unavailable"

E-28
Action Description
proxy server
URL.
field.
SDP.
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 INVITEproxy server to SIP IP
phone B
Step 4
Step 5
Note Call forward unavailable timer expires.
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.
SIP IP phone A
IP phone A
phone C

E-29

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 ServerCalled User Is Busy, page E-29
SIP Gateway to SIP Gateway via SIP Redirect ServerCalled User Does Not Answer, page E-32
SIP Gateway to SIP Gateway via SIP Redirect ServerClient, Server, or Global Error, page E-34
SIP Gateway to SIP Gateway via SIP Proxy ServerCalled User Is Busy, page E-36
SIP Gateway to SIP Gateway via SIP Proxy ServerClient or Server Error, page E-38
SIP Gateway to SIP Gateway via SIP Proxy ServerGlobal Error, page E-40
SIP Phone to SIP/H.323 Gateway via SIP Proxy ServerRecord-Route Disabled, page E-42
SIP Phone to SIP/H.323 Gateway via SIP Proxy ServerRecord-Route Enabled, page E-50
SIP Phone to SIP/H.323 Gateway via SIP Redirect Server, page E-58
SIP Phone to SIP/H.323 Gateway via SIP Proxy ServerRecord-Route Disabled (Call Failed with
a 503 Service Unavailable Response), page E-65
Note The messages are provided as examples for reference only.
SIP Gateway to SIP Gateway via SIP Redirect ServerCalled User Is Busy
Figure E-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.

E-30
Figure E-12 SIP Gateway to SIP Gateway via SIP Redirect ServerCalled User Is Busy
3. 302 Moved
Temporarily
15. ACK
12.
Disconnect
(Busy)
6. Call
Proceeding
1. Setup
13. Release
2. INVITE
4. ACK
PBX A User A
GW1
RS
IP Network GW2
PBX B User B
10. Disconnect
(Busy)
17. Release
Complete
9. Call
Proceeding
7. Setup
14. Release
8. 100 Trying
5. INVITE
11. 486 Busy Here
16. Release
Complete
2
8
9
3
9

E-31

Action Description
redirect server
of a SIP URL.
field.
Step 3 302 Moved Temporarily SIP
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.
redirect server
SIP gateway 1 acknowledges the 302 Moved Temporarily response with an ACK.
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.
to PBX A
call-setup request.
Step 7 SetupSIP 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.
SIP gateway 1
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
gateway 2
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 HereSIP gateway 2
to SIP gateway 1
SIP gateway 2 maps the Release message cause code (Busy) to the 486 Busy
response and sends the response to SIP gateway 1. The response indicates that
user Bs 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.
gateway 1

E-32
SIP Gateway to SIP Gateway via SIP Redirect ServerCalled User Does Not
Answer
Figure E-13 illustrates an unsuccessful call in which user A initiates a call to user B but user B does not
answer.
Figure E-13 SIP Gateway to SIP Gateway via SIP Redirect ServerCalled User Does Not Answer
PBX B
SIP gateway 1 sends a Release message to PBX B.
gateway 2
Busy Here response has been received.
gateway 1 to PBX A
attempt is terminated.
SIP gateway 2
Action Description
3. 302 Moved
Temporarily
13. CANCEL
16.
Disconnect
12. Alerting
6. Call
Proceeding
1. Setup
2. INVITE
4. ACK
PBX A
User A
GW1 RS IP Network GW2 PBX B
User B
10. Alerting
9. Call
Proceeding
7. Setup
21. Release
18. Disconnect
8. 100 Trying
5. INVITE
14. 487
15. ACK
11. 180 Ringing
19. 200 OK
17. Release
20. Release
Complete

E-33

Action Description
redirect server
of a SIP URL.
field.
Step 3 302 Moved Temporarily SIP
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.
redirect server
SIP gateway 1 acknowledges the 302 Moved Temporarily response with an ACK.
gateway 2
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.
to PBX A
call-setup request.
Step 7 SetupSIP 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.
SIP gateway 1
gateway 1. The message indicates that the INVITE request has been received by
gateway 2
call-setup request.
gateway 2
PBX B sends an Alert message to SIP gateway 2. User Bs phone begins to ring.
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.
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.
PBX A

E-34
SIP Gateway to SIP Gateway via SIP Redirect ServerClient, Server, or Global
Error
Figure E-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 E-14 SIP Gateway to SIP Gateway via SIP Redirect ServerClient, Server, or Global Error
gateway 1
PBX B
SIP gateway 2 sends a Disconnect message to PBX B.
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 CompletePBX A to
SIP gateway 1
PBX A sends a Release Complete message to SIP gateway 1 and the call session
Step 19 ReleasePBX B to SIP
gateway 2
PBX B sends a Release message to SIP gateway 2.
gateway 2 to PBX B
SIP gateway 2 sends a Release Complete message to PBX B.
Action Description
3. 300 Multiple
Choice
11. ACK
9. Disconnect
6. Call
Proceeding
1. Setup
2. INVITE
4. ACK
PBX A
User A
GW1 RS IP Network GW2 PBX B
User B
7. 100 Trying
5. INVITE
8. 4xx/5xx/6xx Failure-404 Not Found
12. Release
Complete
11. Release
2
8
9
4
1

E-35

Action Description
redirect server
of a SIP URL.
PBX A is identified as the initiator in the From field.
field.
Step 3 300 Multiple ChoiceSIP
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 Bs 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.
redirect server
SIP gateway 1 acknowledges the 300 Multiple Choice response with an ACK.
gateway 2
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.
to SIP gateway 2
call-setup request.
SIP gateway 1
gateway 1. The message indicates that the INVITE request has been received by
Step 8 Class 4xx/5xx/6xx FailureSIP
gateway 2 to SIP gateway 1
SIP gateway 2 determines that user B does not exist at the domain specified in the
INVITE request sent by SIP gateway 1. SIP gateway 2 refuses the connection and
sends a 404 Not Found response to SIP gateway 1.
The 404 Not Found response is a class 4xx failure response. 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.

E-36
SIP Gateway to SIP Gateway via SIP Proxy ServerCalled User Is Busy
Figure E-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 E-15 SIP Gateway to SIP Gateway via SIP Proxy ServerCalled User Is Busy
PBX A
gateway 1
gateway 2
Not Found failure response has been received.
gateway 1 to PBX A
Action Description
12. 486 Busy Here
6. 100 Trying
7. 100 Trying
11. 486 Busy Here
13.
Disconnect
(Busy)
4. Call
Proceeding
17 Release
1. Setup
8. Disconnect
(Busy)
5. Setup
9. Release
10. Release
Complete
2. INVITE
15. ACK
PBX A User A
GW1
Proxy
Server IP Network GW2
PBX B User B
3. INVITE
16. ACK
14. Release

E-37

Action Description
proxy server
of a SIP URL.
field.
SIP gateway 2
to PBX A
call-setup request.
SIP gateway 1
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 HereSIP gateway 2
to SIP proxy server
SIP gateway 2 maps the Release message cause code (Busy) to the 486 Busy
response and sends the response to the SIP proxy server. The response indicates
that user Bs phone was successfully contacted but user B was either unwilling or
unable to take another call.
Step 10 486 Busy HereSIP 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
gateway 1
proxy server
SIP gateway 1 sends an SIP ACK to the SIP proxy server.

E-38
SIP Gateway to SIP Gateway via SIP Proxy ServerClient or Server Error
Figure E-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 E-16 SIP Gateway to SIP Gateway via SIP Proxy ServerClient or Server Error
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.
gateway 1 to PBX A
Action Description
Action Description
proxy server
of a SIP URL.
PBX A is identified as the initiator in the From field.
field.
8. 4xx/5xx/
Failure-503
Service
Unavailable
5. 100 Trying
6. 100 Trying
7. 4xx/5xx/ Failure-503
Service Unavailable
9. Disconnect
4. Call
Proceeding
13. Release
Complete
1. Setup
2. INVITE
11. ACK
PBX A
User A
GW1
Proxy
Server IP Network GW2 PBX B
User B
3. INVITE
12. ACK
10. Release
2
8
9
4
5

E-39

SIP gateway 2
to PBX A
call-setup request.
SIP gateway 1
SIP proxy server
SIP gateway 2 sends a 100 Trying response to the SIP proxy server.
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.
proxy server to SIP gateway 1
SIP proxy server forwards the SIP 503 Service Unavailable response to SIP
gateway 1.
PBX A
gateway 1
proxy server
SIP gateway 1 sends an ACK to the SIP proxy server.
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.
gateway 1 to PBX A
Action Description

E-40
SIP Gateway to SIP Gateway via SIP Proxy ServerGlobal Error
Figure E-17 illustrates an unsuccessful call in which user A initiates a call to user B and receives a class
6xx response.
Figure E-17 SIP Gateway to SIP Gateway via SIP Proxy ServerGlobal Error
Action Description
proxy server
of a SIP URL.
field.
to PBX A
call-setup request.
SIP gateway 2
12. 6xx Failure
7. 100 Trying
6. 100 Trying
11. 6xx Failure
13.
Disconnect
17. Release
C l
3. Call
Proceeding
1. Setup
14. Release
5. Setup
2. INVITE
15. ACK
PBX A
User A
GW1
Proxy
Server IP Network GW2 PBX B
User B
4. INVITE
16. ACK
8. Disconnect
(Busy)
9. Release
10. Release
Complete

E-41

SIP proxy server
SIP gateway 1
SIP proxy server forwards the 100 Trying response to SIP gateway 1.
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 FailureSIP 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 FailureSIP proxy server to
SIP gateway 1
SIP proxy server forwards the 6xx failure to SIP gateway 1.
PBX A
gateway 1
proxy server
SIP gateway 1 sends an ACK to the SIP proxy server.
gateway 2
SIP proxy server sends an ACK to SIP gateway 2. The ACK confirms that the 6xx
failure response has been received.
gateway 1 to PBX A
Action Description

E-42
SIP Phone to SIP/H.323 Gateway via SIP Proxy ServerRecord-Route Disabled
Figure E-18 SIP Phone to SIP/H.323 Gateway via SIP Proxy ServerRecord-Route Disabled
SIP Phone/UAC SIP Proxy Server SIP/H.323
Gateway
Directory
Gatekeeper
1. SIP INVITE
2. SIP 100 Trying
3. RAS LRQ
4. RAS RIP
5. RAS LCF
8. SIP 180 Ringing
10. SIP 200 OK
13. SIP 200 OK
11. SIP ACK
12. SIP BYE
2-way RTP Channel
Media cut-through
Media cut-through
6
8
5
1
6
6. SIP INVITE
6.x SIP 100 Trying
7. SIP 180 Ringing
9. SIP 200 OK

E-43

Action Description
Step 1 INVITESIP 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.
INVITESIP phone to SIP
proxy server
Example
SIP/2.0
Via: SIP/2.0/UDP 161.44.3.207:49489
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
CSeq:1 INVITE
Max-Forwards: 6

E-44
Step 2 100Trying 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 LRQSIP 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
}
Action Description

E-45

Step 4 RAS RIPH.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 LCFH.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
{
{
t35CountryCode 181
t35Extension 0
manufacturerCode 18
}
data '0002400900630033003600320030002D0032002D...'H
}
destinationType
{
gateway
{
protocol
{
voice :
{
supportedPrefixes
{
}
}
}
}
Action Description

E-46
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
}
}
}
}
Action Description

E-47

Step 6 SIP INVITESIP 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
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
Expires: 5
v=0
s=SIP Callt=0 0
c=IN IP4 172.18.193.101
a=rtpmap:3 GSM/8000
Step 7 SIP 180 RingingGateway
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 161.44.3.207:49489
Call-ID: 23-99990146-0-5894369F@161.44.3.207
CSeq: 1 INVITE
Content-Length: 0
Action Description

E-48
Step 8 SIP 180 RingingSIP 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
CSeq: 1 INVITE
Content-Length: 0
Step 9 SIP 200 OKGateway 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 161.44.3.207:49489
Call-ID: 23-99990146-0-5894369F@161.44.3.207
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
a=rtpmap:3 GSM/8000
Step 10 SIP 200 OKSIP 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
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
a=rtpmap:3 GSM/8000
Action Description

E-49

Step 11 SIP ACKCalling 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
CSeq: 1 ACK
Step 12 SIP BYEGateway 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
CSeq: 1 BYE
Step 13 SIP 200 OKCalling 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
CSeq: 1 BYE
Action Description

E-50
SIP Phone to SIP/H.323 Gateway via SIP Proxy ServerRecord-Route Enabled
Figure E-19 SIP Phone to SIP/H.323 Gateway via SIP Proxy ServerRecord-Route Enabled
Gateway
Directory
Gatekeeper
1. SIP INVITE
2. SIP 100 Trying
3. RAS LRQ
4. RAS RIP
5. RAS LCF
8. SIP 180 Ringing
14. SIP BYE
10. SIP 200 OK
11. SIP ACK
15. SIP 200 OK
2-way RTP Channel
Media cut-through
Media cut-through
6
8
5
1
8
6. SIP INVITE
12. SIP ACK
6.x SIP 100 Trying
7. SIP 180 Ringing
9. SIP 200 OK
13. SIP BYE
16. SIP 200 OK

E-51

Action Description
proxy server
Example
SIP/2.0
Via: SIP/2.0/UDP 161.44.3.207:49489
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
CSeq:1 INVITE
Max-Forwards: 6
Expires: 5
v=0
s=SIP Call
t=0 0
c=IN IP4 172.18.193.101
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 100Trying SIP Proxy sends to
UAC
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
CSeq: 1 INVITE
Content-Length: 0

E-52
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
{
requestSeqNum 2519
destinationInfo
{
e164 : "001#19193920002"
}
nonStandardData
{
{
t35CountryCode 181
t35Extension 0
manufacturerCode 18
}
data '8284901100ECAA98A025220008000000000E1963...'H
}
{
ip 'AC12C247'H
port 1719
}
sourceInfo
{
}
canMapAlias TRUE
}
Upon receiving the RAS LRQ message from the SIP proxy server, H.323 DGK
accordingly.
Example
{
requestSeqNum 2519
delay 9000
}
Action Description

E-53

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
{
ip 'AC12C250'H
port 1720
}
{
ip 'AC12C250'H
port 56812
}
nonStandardData
{
{
t35CountryCode 181
t35Extension 0
manufacturerCode 18
}
data '0002400900630033003600320030002D0032002D...'H
}
destinationType
{
gateway
{
protocol
{
voice :
{
supportedPrefixes
{
}
}
}
}
mc FALSE
undefinedNode FALSE
}
}
Action Description

E-54
{
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
}
}
}
}
gateway
SIP proxy server forwards the INVITE to the gateway.
Example
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
CSeq:1 INVITE
Max-Forwards: 6
Expires: 5
v=0
s=SIP Call
t=0 0
c=IN IP4 172.18.193.101
a=rtpmap:3 GSM/8000
Action Description

E-55

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 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
CSeq: 1 INVITE
Content-Length: 0
Step 8 SIP 180 RingingSIP proxy
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
CSeq: 1 INVITE
Content-Length: 0
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 161.44.3.207:49489
Call-ID: 23-99990146-0-5894369F@161.44.3.207
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
a=rtpmap:3 GSM/8000
Action Description

E-56
Step 10 SIP 200 OKSIP 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
CSeq: 1 INVITE
Contact: <sip:001#19193920002@172.18.194.80>
Content-Length: 0
v=0
s=SIP Call
t=0 0
a=rtpmap:3 GSM/8000
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
CSeq: 1 ACK
Step 12 SIP ACKSIP 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
CSeq: 1 ACK
Action Description

E-57

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 BYESIP 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
CSeq: 1 BYE
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
CSeq: 1 BYE
Step 16 SIP 200 OKSIP 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
CSeq: 1 BYE
Action Description

E-58
SIP Phone to SIP/H.323 Gateway via SIP Redirect Server
Figure E-20 SIP Phone to SIP/H.323 Gateway via SIP Redirect Server
SIP Phone/UAC SIP Redirect Server SIP/H.323
Gateway
Directory
Gatekeeper
1. SIP INVITE
7. SIP ACK
2. SIP 100 Trying
3. RAS LRQ
4. RAS RIP
5. RAS LCF
6. 302 Moved
Temporarily
13. SIP 200 OK
11. SIP ACK
12. SIP BYE
2-way RTP Channel
Media cut-through
Media cut-through
6
8
5
1
7
8. SIP INVITE
8.x SIP 100 Trying
9. SIP 180 Ringing
10. SIP 200 OK

E-59

Action Description
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
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
CSeq:1 INVITE
Max-Forwards: 6
Expires: 5
v=0
s=SIP Call
t=0 0
c=IN IP4 172.18.193.101
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.
Call-ID field.
The transaction number within a single call leg is identified in the Cseq field.
Step 2 100Trying SIP redirect server
returns 100 Trying to UAC
SIP redirect server sends 100-Trying response message to the upstream UAC upon
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
CSeq: 1 INVITE
Content-Length: 0

E-60
Step 3 RAS LRQSIP 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
{
requestSeqNum 2519
destinationInfo
{
e164 : "002#19193650002"
}
nonStandardData
{
{
t35CountryCode 181
t35Extension 0
manufacturerCode 18
}
data '8284901100ECAA98A025220008000000000E1963...'H
}
{
ip 'AC12C247'H
port 1719
}
sourceInfo
{
}
canMapAlias TRUE
}
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
{
requestSeqNum 2519
delay 9000
}
Action Description

E-61

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
to the SIP redirect server.
Example
{
requestSeqNum 2519
{
ip 'AC12C250'H
port 1720
}
{
ip 'AC12C250'H
port 56812
}
nonStandardData
{
{
t35CountryCode 181
t35Extension 0
manufacturerCode 18
}
data '0002400900630033003600320030002D0032002D...'H
}
destinationType
{
gateway
{
protocol
{
voice :
{
supportedPrefixes
{
}
}
}
}
mc FALSE
undefinedNode FALSE
}
}
Action Description

E-62
{
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
TemporarilySIP 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
CSeq: 1 INVITE
Contact: <sip:19193650002@172.18.194.80:5060>
Content-Length: 0
Action Description

E-63

Step 7 SIP ACKUAC 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
CSeq: 1 ACK
Step 8 SIP INVITEUAC sends
directly to the gateway
The UAC sends a new INVITE directly to the gateway.
Example
INVITE sip:19193650002@172.18.194.80:5060;
Via: SIP/2.0/UDP 161.44.3.207:49489
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
CSeq: 2 INVITE
Max-Forwards: 6
Expires: 5
v=0
s=SIP Call
t=0 0
c=IN IP4 172.18.193.101
a=rtpmap:3 GSM/8000
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
CSeq: 2 INVITE
Content-Length: 0
Action Description

E-64
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
CSeq: 2 INVITE
Content-Length: 0
v=0
s=SIP Call
t=0 0
a=rtpmap:3 GSM/8000
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
CSeq: 2 ACK
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
CSeq: 1 BYE
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
CSeq: 1 BYE
Action Description

E-65

SIP Phone to SIP/H.323 Gateway via SIP Proxy ServerRecord-Route Disabled
(Call Failed with a 503 Service Unavailable Response)
Figure E-21 SIP Phone to SIP/H.323 Gateway via SIP Proxy ServerRecord-Route Disabled
Gateway
Directory
Gatekeeper
1. SIP INVITE
10. SIP ACK
2. SIP 100 Trying
3. RAS LRQ
4. RAS RIP
5. RAS LCF
6
8
5
1
9
6. SIP INVITE
7. SIP 100 Trying
8. SIP 503 Service
Unavailable
9. SIP 503 Service
Unavailable
11. SIP ACK

E-66
Action Description
Step 1 INVITE-SIP phone to SIP proxy
server
Example
SIP/2.0
Via: SIP/2.0/UDP 161.44.3.207:49489
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
CSeq:1 INVITE
Max-Forwards: 6
Expires: 5
v=0
s=SIP Call
t=0 0
c=IN IP4 172.18.193.101
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.
Call-ID field.
The transaction number within a single call leg is identified in the Cseq field.
Step 2 100-Trying SIP Proxy sends to
UAC
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
CSeq: 1 INVITE
Content-Length: 0

E-67

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
{
requestSeqNum 2519
destinationInfo
{
e164 : "002#19193650002"
}
nonStandardData
{
{
t35CountryCode 181
t35Extension 0
manufacturerCode 18
}
data '8284901100ECAA98A025220008000000000E1963...'H
}
{
ip 'AC12C247'H
port 1719
}
sourceInfo
{
}
canMapAlias TRUE
}
Upon receiving the RAS LRQ message from the SIP proxy server, the H.323 DGK
accordingly.
Example
{
requestSeqNum 2519
delay 9000
}
Action Description

E-68
The H.323 DGK forwards the request to the H.323 network and finds a SIP/H.323
to the SIP proxy server.
Example
{
requestSeqNum 2519
{
ip 'AC12C250'H
port 1720
}
{
ip 'AC12C250'H
port 56812
}
nonStandardData
{
{
t35CountryCode 181
t35Extension 0
manufacturerCode 18
}
data '0002400900630033003600320030002D0032002D...'H
}
destinationType
{
gateway
{
protocol
{
voice :
{
supportedPrefixes
{
}
}
}
mc FALSE
undefinedNode FALSE
}
}
Action Description

E-69

{
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
}
}
}
}
Action Description

E-70
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;
Via: SIP/2.0/UDP 161.44.3.207:49489
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
CSeq:1 INVITE
Max-Forwards: 6
Expires: 5
v=0
s=SIP Call
t=0 0
c=IN IP4 172.18.193.101
a=rtpmap:3 GSM/8000
Step 7 SIP 100 TryingGateway 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 161.44.3.207:49489
Call-ID: 23-99990146-0-5894369F@161.44.3.207
CSeq: 1 INVITE
Content-Length: 0
Action Description

E-71

Step 8 SIP 100-TryingSIP proxy
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 161.44.3.207:49489
Call-ID: 23-99990146-0-5894369F@161.44.3.207
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 161.44.3.207:49489
Call-ID: 23-99990146-0-5894369F@161.44.3.207
CSeq: 1 INVITE
Content-Length: 0
Step 10 SIP 503 Service
UnavailableSIP 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
CSeq: 1 INVITE
Content-Length: 0
Action Description

E-72
Call-Flow Scenarios with CLIR Support
There are some typical or characteristic use cases where Calling Line Identity Restriction (CLIR) needs
to be supported. In a setup that has at least three ATA phones (A1, A2, and A3, untrusted upstream and
downstream), one SPS, one PSTN gateway (PGW) (trusted upstream and downstream), and two PSTN
phones (P1 and P2, accessed via the PGW), we can have the following call setups, assuming that the
initial call is anonymous and the second (forwarding) person, if any, is also set to anonymous when
redirecting with 302, or has CLIR enabled when call forwarding is invoked:
A1 call A2
A1 call P1
P1 call A1
A1 call A2 forward to A3
A1 call A2 forward to P1
P1 call A1 forward to A2
P1 call A1 forward to P2
The first three cases are covered by the last four cases, which add forwarding on top of them. The call
flows shown here correspond to the last four cases, and assume that privacy-related directives are set to
On, as follows:
PrivacyOn
PrivacyWithPAIOn
PrivacyWithRPIDOn
PrivacyWithDiversionOn
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
CSeq: 1 ACK
Step 12 SIP ACKSIP 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 161.44.3.207:49489
Call-ID: 23-99990146-0-5894369F@161.44.3.207
CSeq: 1 ACK
Action Description

E-73

Note that setting these directives all to Off causes SPS to behave in the same way as before CLIR is
supported.
For each of the four cases, there are two types of forwarding302 redirected or Call Forwarding invoked
in SPSand therefore we show two call flows for each case.
A1 Call A2 Forward to A3
Figure E-22 SetupA1 Call A2 Forward to A3
1
1
7
1
4
7
V
V
IP
PSTN
ATA
5001
1
2
3
4
SPS
PGW
ATA
5002
V
ATA
5003
Trust domain
4081112222
4083334444

E-74
Figure E-23 Call FlowA1 Call A2 Redirect to A3
Figure E-24 Call FlowA1 Call A2 Call Forward Busy to A3
1
1
7
1
5
2
ATA
5001
SPS
407
ATA
5002
ATA
5003
302 Moved
Contact: 5003
Div: Anonymous
privacy=full
INVITE 5003
From: Anonymous
Div: Anonymous
privacy=full
V V V
IP
INVITE 5002
From: Anonymous
INVITE 5002
From: Anonymous
Proxy-Auth: user=5002
INVITE 5002
From: Anonymous
INVITE 5002
From: Anonymous
INVITE 5002
From: Anonymous
INVITE 5002
From: Anonymous
1
1
7
1
4
9
ATA
5001
SPS
407
ATA
5002
ATA
5003
INVITE 5003
From: Anonymous
Div: Anonymous
privacy=full
V V V
IP
INVITE 5002
From: Anonymous
INVITE 5002
From: Anonymous
INVITE 5002
From: Anonymous
INVITE 5002
From: Anonymous
INVITE 5002
From: Anonymous
INVITE 5002
From: Anonymous
486 Busy
5002
CFB to
5003
5002 has CLIR
enabled

E-75

A1 Call A2 Forward to P1
Figure E-25 SetupA1 Call A2 Forward to P1
Figure E-26 Call FlowA1 Call A2 Redirect to P1
1
1
7
1
5
4
V
V
IP
PSTN
ATA
5001
1
2
3
4 5
6
SPS
PGW
ATA
5002
V
ATA
5003
Trust domain
4081112222
4083334444
1
1
7
1
5
5
ATA
5001
SPS
407
ATA
5002 PGW PSTN
302 Moved
Contact: 4081112222
Div: Anonymous
privacy=full
302 Moved
Contact: 4081112222
Div: Anonymous
privacy=full
V V
IP
INVITE 5002
From: Anonymous
INVITE 5002
From: Anonymous
INVITE 5002
From: Anonymous
INVITE 5002
From: Anonymous
INVITE 5002
From: Anonymous
INVITE 5002
From: Anonymous
Called: 4081112222
Caller: 5001
Redirect: 5002
Caller Privacy requested
Redirect Privacy requested
Called: 4081112222
Caller: 5001
Redirect: 5002
INVITE 4081112222
From: Anonymous
PAI: 5001@sps.com
Privacy: id
RPD: 5001@sps.com, privacy=full
Div: 5002, privacy=full
INVITE 4081112222
From: Anonymous
PAI: 5001@sps.com
Privacy: id

E-76
Figure E-27 Call FlowA1 Call A2 Call Forward Busy to P1
P1 Call A1 Forward to A2
Figure E-28 SetupP1 Call A1 Forward to A2
1
1
7
1
5
6
ATA
5001
SPS
407
486 Busy
ATA
5002 PGW PSTN
INVITE 5003
From: Anonymous
Div: Anonymous
privacy=full
V V
IP
INVITE 5002
From: Anonymous
INVITE 5002
From: Anonymous
INVITE 5002
From: Anonymous
INVITE 5002
From: Anonymous
INVITE 5002
From: Anonymous
INVITE 5002
From: Anonymous
5002
CFB to
4081112222
5002 has CLIR
enabled
INVITE 4081112222
From: Anonymous
PAI: 5001@sps.com
Privacy: id
INVITE 4081112222
From: Anonymous
PAI: 5001@sps.com
Privacy: id
Called: 4081112222
Caller: 5001
Redirect: 5002
Called: 4081112222
Caller: 5001
Redirect: 5002
1
1
7
1
5
7
V
V
IP
ATA
5001
4
5
6
3 2
1
SPS
PGW
ATA
5002
Trust domain
4081112222
4083334444
PSTN

E-77

Figure E-29 Call FlowP1 Call A1 Redirect to A2
Figure E-30 Call FlowP1 Call A1 Call Forward Busy to A2
1
1
7
1
5
8
ATA
5001
SPS ATA
5002 PGW PSTN
V V
IP
calling 5001
from 4081112222
requested privacy
302 Moved
Contact: 5002
Div: Anonymous
privacy=full
INVITE 5001
From: Anonymous
PAI: 4081112222
RPID: 4081112222
INVITE 5001
From: Anonymous
INVITE 5002
From: Anonymous
Div: Anonymous
privacy=full
INVITE 5001
From: Anonymous
PAI: 4081112222
RPID: 4081112222
INVITE 5001
From: Anonymous
INVITE 5002
From: Anonymous
Div: Anonymous
privacy=full
1
1
7
1
5
9
ATA
5001
SPS ATA
5002 PGW PSTN
V V
IP
calling 5001
from 4081112222
requested privacy
INVITE 5001
From: Anonymous
PAI: 4081112222
RPID: 4081112222
INVITE 5001
From: Anonymous
INVITE 5002
From: Anonymous
Div: Anonymous
privacy=full
INVITE 5001
From: Anonymous
PAI: 4081112222
RPID: 4081112222
INVITE 5001
From: Anonymous
INVITE 5002
From: Anonymous
Div: Anonymous
privacy=full
5002
CFB to
4081112222
5002 has CLIR
enabled
486 Busy

E-78
P1 Call A1 Forward to P2
Figure E-31 SetupP1 Call A1 Forward to P2
Figure E-32 Call FlowP1 Call A1 Redirect to P2
1
1
7
1
6
0
V
V
ATA
5001
4
5
6
3 2
7
1
8
SPS
PGW
ATA
5002
Trust domain
4081112222
4083334444
PSTN
IP
1
1
7
1
6
1
ATA
5001
SPS ATA
5002 PGW PSTN
V V
IP
calling 5001
from 4081112222
requested privacy
302 Moved
Contact: 4083334444
Div: Anonymous
privacy=full
INVITE 5001
From: Anonymous
PAI: 4081112222
RPID: 4081112222
INVITE 5001
From: Anonymous
INVITE 5001
From: Anonymous
PAI: 4081112222
RPID: 4081112222
INVITE 5001
From: Anonymous
Called: 4081112222
Caller: 5001
Redirect: 5002
Called: 4083334444
Caller: 4081112222
Redirect: 5001
INVITE 4083334444
From: Anonymous
PAI: 4081112222
RPID: 4081112222
INVITE 4083334444
From: Anonymous
PAI: 4081112222
RPID: 4081112222

E-79

Figure E-33 Call FlowP1 Call A1 Call Forward Busy to P2
1
1
7
1
6
2
ATA
5001
SPS ATA
5002 PGW PSTN
V V
IP
calling 5001
from 4081112222
requested privacy
INVITE 5001
From: Anonymous
PAI: 4081112222
RPID: 4081112222
INVITE 5001
From: Anonymous
INVITE 5001
From: Anonymous
PAI: 4081112222
RPID: 4081112222
INVITE 5001
From: Anonymous
Called: 4081112222
Caller: 5001
Redirect: 5002
Called: 4083334444
Caller: 4081112222
Redirect: 5001
INVITE 4083334444
From: Anonymous
PAI: 4081112222
RPID: 4081112222
INVITE 4083334444
From: Anonymous
PAI: 4081112222
RPID: 4081112222
486 Busy
5002
CFB to
4083334444
5002 has CLIR
enabled

E-80

SIP Call-Flow Scenarios: Message Types

Uploaded by

Document Informationclick to expand document information

Copyright:

Available Formats

SIP Call-Flow Scenarios: Message Types

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SIP Call-Flow Scenarios: Message Types

Uploaded by

Copyright:

Available Formats

E-1

Cisco SIP Proxy Server Administrator Guide

You might also like