cc/td/doc/product/software/ios122/rel_docs
hometocprevnextglossaryfeedbacksearchhelp
PDF

Table of Contents

Troubleshooting Tips for Call Flow Scenarios
 SIP Header Fields

Troubleshooting Tips for Call Flow Scenarios

This document shows the debug ccsip messages command traces the SIP messages exchanges between the SIP User Agent client and the gateway in the Cisco IOS Release 12.2(2)XB and Cisco IOS Release 12.2(8)T, including examples and explanations of the output generated.

SIP Header Fields

Header Field Definition

Call-ID

The Call-ID general-header field uniquely identifies a specific invitation or all registrations of a specific client. Note that a single multimedia conference can give rise to several calls with different Call-IDs. For example, if a user invites a single individual several times to the same (long-running) conference.

Contact

The Contact general-header field can appear in INVITE, ACK, and REGISTER requests, and in 1xx, 2xx, 3xx, and 485 responses. In general, it provides a URL where the user can be reached for further communications.

Content-Length

The Content-Length entity-header field indicates the size of the message-body, in decimal number of octets, sent to the recipient.

Content-Type

The Content-Type entity-header field indicates the media type of the message-body sent to the recipient.

Cseq

Users MUST add the CSeq (command sequence) general-header field to every request. A CSeq header field in a request contains the request method and a single decimal sequence number chosen by the requesting client, unique within a single value of Call-ID. The sequence number MUST be expressed as a 32-bit unsigned integer. The initial value of the sequence number is arbitrary, but MUST be less than 2**31. Consecutive requests that differ in request method, headers, or body, but have the same Call-ID MUST contain strictly monotonically increasing and contiguous sequence numbers; sequence numbers do not wrap around. Retransmissions of the same request carry the same sequence number, but an INVITE with a different message body or different header fields (a "re-invitation") acquires a new, higher sequence number. A server MUST echo the CSeq value from the request in its response. If the Method value is missing in the received CSeq header field, the server fills it in appropriately.

Date

Date is a general-header field. Its syntax is:

SIP-date = rfc1123-date

Note that unlike HTTP/1.1, SIP only supports the most recent RFC 1123 [29] formatting for dates.

Diversion

Note Note: Currently the CC-Diversion header is used but it will change to just Diversion. Values will not change though.

 

Expires

The Expires entity-header field gives the date and time after which the message content expires.

This header field is currently defined only for the REGISTER and INVITE methods. For REGISTER, it is a request and response-header field. In a REGISTER request, the client indicates how long it wants the registration to be valid. In the response, the server indicates the earliest expiration time of all registrations. The server MAYchoose a shorter time interval than that requested by the client, but SHOULD NOT choose a longer one.

From

Requests and responses MUST contain a From general-header field, indicating the initiator of the request. The From field MAY contain the "tag" parameter. The server copies the From header field from the request to the response. The optional "display-name" is meant to be rendered by a human-user interface. A system SHOULD use the display name "Anonymous" if the identity of the client is to remain hidden.

The SIP-URL MUST NOT contain the "transport-param", "maddr-param", "ttl-param", or "headers"elements. A server that receives a SIP-URL with these elements removes them before further processing.

Max-Forwards

The Max-Forwards request-header field may be used with any SIP method to limit the number of proxies or gateways that can forward the request to the next downstream server. This can also be useful when the client is attempting to trace a request chain which appears to be failing or looping in mid chain.

The Max-Forwards value is a decimal integer indicating the remaining number of times this request message is allowed to be forwarded.

Each proxy or gateway recipient of a request containing a Max-Forwards header field MUST check and update its value before forwarding the request. If the received value is zero (0), the recipient MUST NOT forward the request. Instead, for the OPTIONS and REGISTER methods, it MUST respond as the final recipient. For all other methods, the server returns 483 (too many hops).

If the received Max-Forwards value is greater than zero, then the forwarded message MUST contain an updated Max-Forwards field with a value decremented by one (1).

Require

The Require request-header field is used by clients to tell useragent servers about options that the client expects the server to support in order to properly process the request. If a server does not understand the option, it MUST respond by returning status code 420 (bad extension) and list those options it does not understand in the Unsupported header.

Server

The Server response-header field contains information about the software used by the user agent server to handle the request.

Timestamp

The timestamp general-header field describes when the client sent the request to the server. The value of the timestamp is of significance only to the client and it MAY use any time scale. The server MUST echo the exact same value and MAY, if it has accurate information about this, add a floating point number indicating the number of seconds that have elapsed since receiving the request. The timestamp is used by the client to compute the round-trip time to the server so that it can adjust the time out value for retransmissions.

To

The To general-header field specifies recipient of the request, with the same SIP URL syntax as the From field.

Requests and responses MUST contain a To general-header field, indicating the desired recipient of the request. The optional "display-name"is meant to be rendered by a human-user interface. The UAS or redirect server copies the To header field into its response, and MUST add a "tag" parameter if the request contained more than one Via header field.

User-Agent

The User-Agent general-header field contains information about the client user agent originating the request.

Via

The Via field indicates the path taken by the request so far. This prevents request looping and ensures replies take the same path as the requests, which assists in firewall traversal and other unusual routing situations.

SIP Call with Diversion Header Added for Call-Diversion Output from GW1 Side

RS = Redirect Server

GW1 ---INVITE---> RS (F1)
GW1 <----302----- RS (F2)
GW1 -----ACK----> RS (F3)
GW1 ---INVITE---> GW2(F4)
GW1 <----100----- GW2(F5)
GW1 <----183----- GW2(F6)
GW1 <---200OK---- GW2(F7)
GW1 -----ACK----> GW2(F8)
GW1 <----BYE----- GW2(F9)
GW1 ---200OK----> GW2(F10)

In this call the originator gets redirected to the terminator by a proxy. The proxy attaches the 'Diversion:' headers to the 3xx response that it sends to the originator. The 3xx response also has the contact header with the address of the terminator. This header is defined in IETF draft 'draft-levy-sip-diversion-02.txt', although the syntax is slightly different because of an implementation in IOS software before the draft being recognized by the IETF.

(F1)
Sent:
INVITE sip:3111100@64.102.17.80:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 172.18.193.98:5060
From: "36601"<sip:36601@172.18.193.98>
To: <sip:3111100@64.102.17.80;user=phone>
Date: Mon, 01 Mar 1993 00:40:08 GMT65
Call-ID: 232226D2-14F411CC-80279792-19DC655A@172.18.193.98
Cisco-Guid: 557120379-351539660-2149947282-433874266
User-Agent: Cisco-SIPGateway/IOS-12.x
CSeq: 101 INVITE
Max-Forwards: 6
Timestamp: 730946408
Contact: <sip:36601@172.18.193.98:5060;user=phone>
Expires: 180
Content-Type: application/sdp
Content-Length: 160
v=0
o=CiscoSystemsSIP-GW-UserAgent 4075 3837 IN IP4 172.18.193.98
s=SIP Call
c=IN IP4 172.18.193.98
t=0 0
m=audio 16526 RTP/AVP 18
a=rtpmap:18 G729/8000
(F2)
Received:
SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/UDP 172.18.193.98:5060
From: "36601"<sip:36601@172.18.193.98>
To: <sip:3111100@64.102.17.80;user=phone>
Date: Mon, 01 Mar 1993 00:40:08 GMT
Call-ID: 232226D2-14F411CC-80279792-19DC655A@172.18.193.98
Cisco-Guid: 557120379-351539660-2149947282-433874266
User-Agent: Cisco-SIPGateway/IOS-12.x
CSeq: 101 INVITE
CC-Diversion: <sip:36602@172.18.193.120>;reason=unconditional
CC-Diversion: <sip:33456@172.18.193.121>;reason=user-busy
CC-Diversion: <sip:36342@172.18.193.122>;reason=unconditional
CC-Diversion: <sip:23222@172.18.193.123>;reason=no-answer
Contact: Anonymous <sip:36602@172.18.193.120>
Contact: Anonymous <sip:36601@172.18.193.98>
Note   The Redirect Server sends back a 302 message, with a new Contact: address, and a Diversion: header added. The GW will now copy those headers into the new INVITE,
Courier New, Courier, mono; font-size: 9.5pt; font-style: normal; font-variant: normal; font-weight: normal; margin-bottom: 0pt; margin-right: 0pt; margin-top: 0pt; text-align: left; text-decoration: none; text-indent: 0pt; text-transform: none"> (F3)
00:40:08:
Sent:
ACK sip:3111100@64.102.17.80:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 172.18.193.98:5060
From: "36601"<sip:36601@172.18.193.98>
To: <sip:3111100@64.102.17.80;user=phone>
Date: Mon, 01 Mar 1993 00:40:08 GMTCall-ID: 232226D2-14F411CC-80279792-19DC655A@172.18.193.98
Max-Forwards: 6
Content-Length: 0
CSeq: 101 ACK
(F4)
00:40:08: Sent:
INVITE sip:36602@172.18.193.120:5060 SIP/2.0
Via: SIP/2.0/UDP 172.18.193.98:5060
From: "36601"<sip:36601@172.18.193.98>
To: <sip:3111100@64.102.17.80;user=phone>
Date: Mon, 01 Mar 1993 00:40:08 GMT
Call-ID: 23704587-14F411CC-80289792-19DC655A@172.18.193.98
Cisco-Guid: 557120379-351539660-2149947282-433874266
User-Agent: Cisco-SIPGateway/IOS-12.x
CSeq: 101 INVITE
Max-Forwards: 6
Timestamp: 730946408
Contact: <sip:36601@172.18.193.98:5060;user=phone>
CC-Diversion: <sip:36602@172.18.193.120>;reason=unconditional
CC-Diversion: <sip:33456@172.18.193.121>;reason=user-busy
CC-Diversion: <sip:36342@172.18.193.122>;reason=unconditional
CC-Diversion: <sip:23222@172.18.193.123>;reason=no-answer
Expires: 180
Content-Type: application/sdp
Content-Length: 160
v=0
o=CiscoSystemsSIP-GW-UserAgent 9443 2845 IN IP4 172.18.193.98
s=SIP Callc=IN IP4 172.18.193.98
t=0 0m=audio 18116 RTP/AVP 18
a=rtpmap:18 G729/8000
(F5)
Received:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 172.18.193.98:5060
From: "36601"<sip:36601@172.18.193.98>
To: <sip:3111100@64.102.17.80;user=phone>
Date: Mon, 01 Mar 1993 00:40:09 GMT
Call-ID: 23704587-14F411CC-80289792-19DC655A@172.18.193.98
Timestamp: 730946408
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 101 INVITEContent-Length: 0
(F6)
Received:
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 172.18.193.98:5060
From: "36601"<sip:36601@172.18.193.98>
To: <sip:3111100@64.102.17.80;user=phone>
Date: Mon, 01 Mar 1993 00:40:09 GMT
Call-ID: 23704587-14F411CC-80289792-19DC655A@172.18.193.98
Timestamp: 730946408
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 101 INVITE
Content-Type: application/sdp
Session: Media
Content-Length: 162
v=0
o=CiscoSystemsSIP-GW-UserAgent 2626 2857 IN IP4 172.18.193.120
s=SIP Call
c=IN IP4 172.18.193.120
t=0 0
m=audio 19030 RTP/AVP 18
a=rtpmap:18 G729/8000
(F7)
Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.18.193.98:5060
From: "36601"<sip:36601@172.18.193.98>
To: <sip:3111100@64.102.17.80;user=phone>;tag=24DE3C-1EBF
Date: Mon, 01 Mar 1993 00:40:09 GMT
Call-ID: 23704587-14F411CC-80289792-19DC655A@172.18.193.98
Timestamp: 730946408
Server: Cisco-SIPGateway/IOS-12.x
Contact: <sip:36602@172.18.193.120:5060;user=phone>
CSeq: 101 INVITE
Content-Type: application/sdp
Content-Length: 162
v=0
o=CiscoSystemsSIP-GW-UserAgent 2626 2857 IN IP4 172.18.193.120
s=SIP Call
c=IN IP4 172.18.193.120
t=0 0
m=audio 19030 RTP/AVP 18
a=rtpmap:18 G729/8000
(F8)
Sent:
ACK sip:36602@172.18.193.120:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 172.18.193.98:5060
From: "36601"<sip:36601@172.18.193.98>
To: <sip:3111100@64.102.17.80;user=phone>;tag=24DE3C-1EBF
Date: Mon, 01 Mar 1993 00:40:08 GMT
Call-ID: 23704587-14F411CC-80289792-19DC655A@172.18.193.98
Max-Forwards: 6
Content-Length: 0CSeq: 101 ACK
(F9)
Received:
BYE sip:36601@172.18.193.98:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 172.18.193.120:5060
From: <sip:3111100@64.102.17.80;user=phone>;tag=24DE3C-1EBF
To: "36601"<sip:36601@172.18.193.98>
Date: Mon, 01 Mar 1993 00:40:16 GMT
Call-ID: 23704587-14F411CC-80289792-19DC655A@172.18.193.98
User-Agent: Cisco-SIPGateway/IOS-12.x
Max-Forwards: 6
Timestamp: 730946416
CSeq: 101 BYE
Content-Length: 0
(F10)
00:40:15: Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.18.193.120:5060
From: <sip:3111100@64.102.17.80;user=phone>;tag=24DE3C-1EBF
To: "36601"<sip:36601@172.18.193.98>
Date: Mon, 01 Mar 1993 00:40:15 GMT
Call-ID: 23704587-14F411CC-80289792-19DC655A@172.18.193.98
Server: Cisco-SIPGateway/IOS-12.x
Timestamp: 730946416
Content-Length: 0
CSeq: 101 BYE

Figure C-1   SIP Gateway to SIP Gateway — Call Redirection with Diversion

Table C-1   SIP Call with Diversion Header Added for Call-Diversion Output from GW1 Side

Step Action Description

F1

INVITE—SIP Gateway 1 to
SIP Redirect Server

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

In the INVITE request:

  • The phone number of User B is inserted in the Request-URI field in the form of a SIP URL. The SIP URL identifies the address of User B and takes a form similar to an email address (user@host where user is the telephone number and host is either a domain name or a numeric network address). In this example, the Request-URI field in the INVITE request to User B appears as "INVITE sip:3111100@64.102.17.80:5060; user=phone". The "user=phone" parameter distinguishes that the Request-URI address is a telephone number rather than a username.
  • PBX A is identified as the call session initiator in the From field.
  • A unique numeric identifier is assigned to the call and is inserted in the Call-ID field.
  • The transaction number within a single call leg is identified in the CSeq field.
  • The media capability (designated by m=) that User A is ready to receive is specified. In this case m=audio 16526 RTP/AVP 18.
  • The port on which SIP gateway 1 is prepared to receive the RTP data is specified in the m= line.

F2

302 Moved Temporarily—
SIP Redirect Server to SIP Gateway 1

In this example the SIP redirect server sends a 302 Moved Temporarily response to SIP gateway 1. The 302 Moved Temporarily 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 user was no longer available at the specified location. The server provided an alternate location for User B in the header. This response indicates that the user is no longer available at the specified location. An alternate location is included in the Contact: header. The SIP redirect server returns the alternate address to SIP gateway 1 in the 302 Moved Temporarily response.

F3

ACK—SIP Gateway 1 to
SIP Redirect Server

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

F4

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 302 Moved Temporarily response as the new address gher transaction number in the CSeq field, and the same Call-ID as the first INVITE request.

F5

100 Trying—SIP Gateway 2 to SIP Gateway 1

SIP gateway 2 sends a 100 Trying response to the INVITE request sent by SIP gateway 1. The 100 Trying response indicates that the INVITE request has been received by SIP gateway 2 but that User B has not yet been located.

F6

183 Session Progress—SIP Gateway 2 to SIP Gateway 1

SIP gateway 2 sends a 183 Session Progress response to SIP gateway 1. The 183 Session Progress response indicates that SIP gateway 2 has located, and is trying to perform inband alerting for the caller.

F7

200 OK—SIP Gateway 2 to SIP Gateway 1

SIP gateway 2 sends a 200 OK response to SIP gateway 1. The 200 OK response notifies SIP gateway 1 that the connection has been made.

If User B supports the media capability advertised in the INVITE message sent by SIP gateway 1, it advertises the intersection of its own and User A's media capability in the 200 OK response. If User B does not support the media capability advertised by User A, it sends back a 400 Bad Request response with a 304 Warning header field.

F8

ACK—SIP Gateway 1 to SIP Gateway 2

SIP gateway 1 sends an ACKnowledge (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.

F9

BYE—SIP Gateway 2 to SIP Gateway 1

SIP gateway 2 sends a BYE request to SIP gateway 1. The BYE request indicates that User B wants to release the call. Because it is User B that wants to terminate the call, the Request-URI field is now replaced with PBX A's SIP URL and the From field contains User B's SIP URL.

F10

200 OK—SIP Gateway 1 to SIP Gateway 2

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

SIP Call with RSVP QoS Output from GW1 Side

GW1 ---INVITE---> GW2 (F1)
GW1 <-100Trying-- GW2 (F2)
GW1 <--183/QoS--- GW2 (F3)
GW1 ---PRACK----> GW2 (F4)
GW1 <-200/PRACK-- GW2 (F5)
GW1 ---COMET----> GW2 (F6)
GW1 <-200/COMET-- GW2 (F7)
GW1 <-183SesProg- GW2 (F8)
GW1 ---PRACK----> GW2 (F9)
GW1 <-200/PRACK-- GW2 (F10)
GW1 <--200/INV--- GW2 (F11)
GW1 -----ACK----> GW2 (F12)
GW1 -----BYE----> GW2 (F13)
GW1 <---200OK---- GW2 (F14)

Note   The call-flows and messaging is per the IETF draft 'draft-ietf-sip-manyfolks-resource-02.txt'.They show the GW integrating the messaging for SIP to use RSVP to signal the network for resources prior to a VoIP call being setup.
(F1)
Sent:
INVITE sip:36602@172.18.193.120;user=phone SIP/2.0
Via: SIP/2.0/UDP 172.18.193.98:5060
From: "36601"<sip:36601@172.18.193.98>;tag=136564-4EF
To: <sip:36602@172.18.193.120;user=phone>
Date: Mon, 01 Mar 1993 GMT
Call-ID: 7D5FB580-14F111CC-80109D18-7AB2874B@172.18.193.98
Supported: 100rel
Cisco-Guid: 2083424384-351343052-2148441368-2058520395
User-Agent: Cisco-SIPGateway/IOS-12.x
CSeq: 101 INVITE
Max-Forwards: 6
Timestamp: 730945271
Contact: <sip:36601@172.18.193.98:5060;user=phone>
Expires: 180
Content-Type: application/sdp
Content-Length: 211
v=0
o=CiscoSystemsSIP-GW-UserAgent 5800 3094 IN IP4 172.18.193.98
s=SIP Call
c=IN IP4 172.18.193.98
t=0 0
m=audio 17158 RTP/AVP 0 18
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=qos:mandatory sendrecv
Note   INVITE sent with QoS required. This is signaled in the Supported: header.
(F2)
Received:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 172.18.193.98:5060
From: "36601"<sip:36601@172.18.193.98>;tag=136564-4EF
To: <sip:36602@172.18.193.120;user=phone>;tag=12F5AC-268A
Date: Mon, 01 Mar 1993 00:20:42 GMT
Call-ID: 7D5FB580-14F111CC-80109D18-7AB2874B@172.18.193.98
Timestamp: 730945271
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 101 INVITE
Content-Length: 0
(F3)
Received:
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 172.18.193.98:5060
From: "36601"<sip:36601@172.18.193.98>;tag=136564-4EF
To: <sip:36602@172.18.193.120;user=phone>;tag=12F5AC-268A
Date: Mon, 01 Mar 1993 00:20:42 GMT
Call-ID: 7D5FB580-14F111CC-80109D18-7AB2874B@172.18.193.98
Timestamp: 730945271
Server: Cisco-SIPGateway/IOS-12.x
Contact: <sip:36602@172.18.193.120:5060;user=phone>
CSeq: 101 INVITE
Require: 100rel
RSeq: 8044
Content-Type: application/sdp
Content-Disposition: precondition;handling=required
Content-Length: 196
v=0
o=CiscoSystemsSIP-GW-UserAgent 1431 3084 IN IP4 172.18.193.120
s=SIP Call
c=IN IP4 172.18.193.120
t=0 0
m=audio 17030 RTP/AVP 18
a=rtpmap:18 G729/8000
a=qos:mandatory sendrecv confirm
Note   Response received with the QoS request acknowledged.
(F4)
Sent:
PRACK sip:36602@172.18.193.120:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 172.18.193.98:5060
From: "36601"<sip:36601@172.18.193.98>;tag=136564-4EF
To: <sip:36602@172.18.193.120;user=phone>;tag=12F5AC-268A
Date: Mon, 01 Mar 1993 GMT
Call-ID: 7D5FB580-14F111CC-80109D18-7AB2874B@172.18.193.98
CSeq: 102 PRACK
RAck: 8044 101 INVITE
Content-Length: 0
Note   Acknowledgement of the QoS request is received.
(F5)Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.18.193.98:5060
From: "36601"<sip:36601@172.18.193.98>;tag=136564-4EF
To: <sip:36602@172.18.193.120;user=phone>;tag=12F5AC-268A
Date: Mon, 01 Mar 1993 00:20:42 GMT
Call-ID: 7D5FB580-14F111CC-80109D18-7AB2874B@172.18.193.98
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 102 PRACK
Content-Length: 0
(F6)Sent:
COMET sip:36602@172.18.193.120:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 172.18.193.98:5060
From: "36601"<sip:36601@172.18.193.98>;tag=136564-4EF
To: <sip:36602@172.18.193.120;user=phone>;tag=12F5AC-268A
Date: Mon, 01 Mar 1993 GMT
Call-ID: 7D5FB580-14F111CC-80109D18-7AB2874B@172.18.193.98
CSeq: 103 COMET
Content-Type: application/sdp
Content-Length: 209
v=0
o=CiscoSystemsSIP-GW-UserAgent 5800 3094 IN IP4 172.18.193.98
s=SIP Call
c=IN IP4 172.18.193.98
t=0 0
m=audio 17158 RTP/AVP 0 18
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=qos:success sendrecv
Note   Bidirectional QoS is established. The RSVP signaling between the gateways and the IP network has been completed as well.
(F7)
Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.18.193.98:5060
From: "36601"<sip:36601@172.18.193.98>;tag=136564-4EF
To: <sip:36602@172.18.193.120;user=phone>;tag=12F5AC-268A
Date: Mon, 01 Mar 1993 00:20:42 GMT
Call-ID: 7D5FB580-14F111CC-80109D18-7AB2874B@172.18.193.98
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 103 COMET
Content-Length: 0
(F8)
Received:
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 172.18.193.98:5060
From: "36601"<sip:36601@172.18.193.98>;tag=136564-4EF
To: <sip:36602@172.18.193.120;user=phone>;tag=12F5AC-268A
Date: Mon, 01 Mar 1993 00:20:42 GMT
Call-ID: 7D5FB580-14F111CC-80109D18-7AB2874B@172.18.193.98
Timestamp: 730945271
Server: Cisco-SIPGateway/IOS-12.x
Contact: <sip:36602@172.18.193.120:5060;user=phone>
CSeq: 101 INVITE
Require: 100rel
RSeq: 8045
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 162
v=0
o=CiscoSystemsSIP-GW-UserAgent 1431 3084 IN IP4 172.18.193.120
s=SIP Call
c=IN IP4 172.18.193.120
t=0 0
m=audio 17030 RTP/AVP 18
a=rtpmap:18 G729/8000
(F9)
Sent:
PRACK sip:36602@172.18.193.120:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 172.18.193.98:5060
From: "36601"<sip:36601@172.18.193.98>;tag=136564-4EF
To: <sip:36602@172.18.193.120;user=phone>;tag=12F5AC-268A
Date: Mon, 01 Mar 1993 GMT
Call-ID: 7D5FB580-14F111CC-80109D18-7AB2874B@172.18.193.98
CSeq: 104 PRACK
RAck: 8045 101 INVITE
Content-Length: 0
(F10)
Received: SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.18.193.98:5060
From: "36601"<sip:36601@172.18.193.98>;tag=136564-4EF
To: <sip:36602@172.18.193.120;user=phone>;tag=12F5AC-268A
Date: Mon, 01 Mar 1993 00:20:42 GMT
Call-ID: 7D5FB580-14F111CC-80109D18-7AB2874B@172.18.193.98
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 104 PRACK
Content-Length: 0
(F11)
Recevied:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.18.193.98:5060
From: "36601"<sip:36601@172.18.193.98>;tag=136564-4EF
To: <sip:36602@172.18.193.120;user=phone>;tag=12F5AC-268A
Date: Mon, 01 Mar 1993 00:20:42 GMT
Call-ID: 7D5FB580-14F111CC-80109D18-7AB2874B@172.18.193.98
Timestamp: 730945271
Server: Cisco-SIPGateway/IOS-12.x
Contact: <sip:36602@172.18.193.120:5060;user=phone>
CSeq: 101 INVITE
Content-Type: application/sdp
Content-Length: 162
v=0
o=CiscoSystemsSIP-GW-UserAgent 1431 3084 IN IP4 172.18.193.120
s=SIP Call
c=IN IP4 172.18.193.120
t=0 0
m=audio 17030 RTP/AVP 18
a=rtpmap:18 G729/8000
(F12)
Sent:
ACK sip:36602@172.18.193.120:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 172.18.193.98:5060
From: "36601"<sip:36601@172.18.193.98>;tag=136564-4EF
To: <sip:36602@172.18.193.120;user=phone>;tag=12F5AC-268A
Date: Mon, 01 Mar 1993 GMT
Call-ID: 7D5FB580-14F111CC-80109D18-7AB2874B@172.18.193.98
Max-Forwards: 6
Content-Length: 0
CSeq: 101 ACK
(F13)
Sent:
BYE sip:36602@172.18.193.120:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 172.18.193.98:5060
From: "36601"<sip:36601@172.18.193.98>;tag=136564-4EF
To: <sip:36602@172.18.193.120;user=phone>;tag=12F5AC-268A
Date: Mon, 01 Mar 1993 GMT
Call-ID: 7D5FB580-14F111CC-80109D18-7AB2874B@172.18.193.98
User-Agent: Cisco-SIPGateway/IOS-12.x
Max-Forwards: 6
Timestamp: 730945310
CSeq: 105 BYE
Content-Length: 0
(F14)Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.18.193.98:5060
From: "36601"<sip:36601@172.18.193.98>;tag=136564-4EF
To: <sip:36602@172.18.193.120;user=phone>;tag=12F5AC-268A
Date: Mon, 01 Mar 1993 00:21:22 GMT
Call-ID: 7D5FB580-14F111CC-80109D18-7AB2874B@172.18.193.98
Server: Cisco-SIPGateway/IOS-12.x
Timestamp: 730945310
Content-Length: 0

Figure C-2   SIP Call with RSVP QoS

Table C-2  

Step Action Description

F1

INVITE—SIP Gateway 1 to SIP Gateway 2

SIP gateway 1 sends an INVITE request to SIP gateway 2. The INVITE request is an invitation to User B to participate in a call session.

In the INVITE request:

The phone number of User B is inserted in the Request-URI field in the form of a SIP URL. The SIP URL identifies the address of User B and takes a form similar to an email address (user@host where user is the telephone number and host is either a domain name or a numeric network address). In this example, the Request-URI field in the INVITE request to User B appears as "36602@172.18.193.120;user=phone". The "user=phone" parameter distinguishes that the Request-URI address is a telephone number rather than a username.

  • PBX A is identified as the call session initiator in the From field.
  • A unique numeric identifier is assigned to the call and is inserted in the Call-ID field.
  • The transaction number within a single call leg is identified in the CSeq field.
  • The media capability (designated by m=) User A is ready to receive is specified. In this case m=audio 17158 RTP/AVP 0 18.
  • The port on which SIP gateway 1 is prepared to receive the RTP data is specified.

F2

100 Trying—SIP Gateway 2 to SIP Gateway 1

SIP gateway 2 sends a 100 Trying response to the INVITE request sent by SIP gateway 1. The 100 Trying response indicates that the INVITE request has been received by SIP gateway 2 but that User B has not yet been located.

F3

183 Session Progress/QoS—SIP Gateway 2 to SIP Gateway 1

SIP gateway 2 sends a 183 Session Progress response to SIP gateway 1. The 183 Session Progress response indicates that SIP gateway 2 has located, and is trying to perform inband alerting for the caller.

Additionally Quality of Service (QoS) reserves sufficient network-layer resources to guarantee bandwidth and bounds on packet loss, delay, and jitter; thus ensuring that the called party's phone rings only after bandwidth required for the call has been successfully reserved.

F4

PRACK—SIP Gateway 1 to
SIP Gateway 2

SIP gateway 1 acknowledges the 183 Session Progress/QoS response with a PRovisional ACKnowledgement (PRACK).

F5

200/PRACK—SIP Gateway 2 to SIP Gateway 1

The 200 OK/PRovisional ACKnowledgement (PRACK) response notifies SIP gateway 1 that the connection has been made.

The SIP gateway generates this response when the PBX indicates that the connection has been made. On receiving this response, the gateway forwards the response to the corresponding party and responds with a PRACK.

F6

COMET—SIP Gateway 1 to
SIP Gateway 2

SIP gateway 1 sends a COnditions MET (COMET) response to SIP gateway 2 indicating that the preconditions have been met.

F7

200/COMET—SIP Gateway 2 to SIP Gateway 1

The 200 OK/COnditions MET (COMET) response notifies SIP gateway 1 that the conditions for the call have been met.

F8

183 Session Progress—
SIP Gateway 2 to SIP Gateway 1

The 183 Session Progress response is used to perform inband alerting for the caller.

F9

PRACK—SIP Gateway 1 to
SIP Gateway 2

SIP gateway 1 acknowledges the 183 Session Progress response with a PRovisional ACKnowledgement (PRACK).

F10

200/PRACK—SIP Gateway 2 to Gateway 1

The 200 OK/PRovisional ACKnowledgement (PRACK) response notifies SIP gateway 1 that the connection has been made.

The SIP gateway generates this response when the PBX indicates that the connection has been made. Upon receiving this response, the gateway forwards the response to the corresponding party and responds with a PRACK.

F11

200/INVITE—SIP Gateway 2 to SIP Gateway 1

The 200/INVITE response acknowledges that the connection has been made and SIP gateway 2 sends a new INVITE request to SIP gateway 1.

F12

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 SIP gateway 2.

F13

BYE—SIP Gateway 1 to
SIP Gateway 2

SIP gateway 1 sends a BYE request to SIP gateway 2. The BYE request indicates that User B wants to release the call. Because it is User B that wants to terminate the call, the Request-URI field is now replaced with PBX A's SIP URL and the From field contains User B's SIP URL.

F14

200 OK—SIP Gateway 2 to
SIP Gateway 1

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

SIP Call with RSVP QoS Output from GW1 Side

SIP Call Using RFC2833 for DTMF-Relay Output from GW1 Side

Call Trace with Different Payload Types:

In this trace both ends have been configured to use NTE dtmf relay mode. However the payload types for NTE packets have different values on both ends. The originator is configured to use value 115, terminator will use default value of 101. The payload value can be configured at the dial peer with
rtp payload-type nte 101command. Because 101 is default payload type and this value is not being used at the Originator for any other payload type, the two ends agree to use payload type 101.

GW1 ---INVITE---> GW2 (F1)
GW1 <-100Trying-- GW2 (F2)
GW1 <-183SesProg- GW2 (F3)
GW1 <---200OK---- GW2 (F4)
GW1 -----ACK----> GW2 (F5)
GW1 <----BYE----- GW2 (F6)
GW1 ---200OK----> GW2 (F7)
(F1)Sent:
INVITE sip:36602@172.18.193.120:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 172.18.193.98:5060
From: "36601"<sip:36601@172.18.193.98>
To: <sip:36602@172.18.193.120;user=phone>
Date: Mon, 01 Mar 1993 00:23:13 GMT
Call-ID: C6310C75-14F111CC-801D9792-19DC655A@172.18.193.98
Cisco-Guid: 3301622965-351343052-2149291922-433874266
User-Agent: Cisco-SIPGateway/IOS-12.x
CSeq: 101 INVITE
Max-Forwards: 6
Timestamp: 730945393
Contact: <sip:36601@172.18.193.98:5060;user=phone>
Expires: 180
Content-Type: application/sdp
Content-Length: 216
v=0
o=CiscoSystemsSIP-GW-UserAgent 6351 4261 IN IP4 172.18.193.98
s=SIP Call
c=IN IP4 172.18.193.98
t=0 0
m=audio 18720 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
Note   The INVITE is sent, and it requests that RFC 2833 be used for DTMF-Relay. This is communicated in the SDP body, in the m= and a= lines.
(F2)
Received:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 172.18.193.98:5060
From: "36601"<sip:36601@172.18.193.98>
To: <sip:36602@172.18.193.120;user=phone>
Date: Mon, 01 Mar 1993 00:23:14 GMT
Call-ID: C6310C75-14F111CC-801D9792-19DC655A@172.18.193.98
Timestamp: 730945393
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 101 INVITE
Content-Length: 0
(F3)
Received:
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 172.18.193.98:5060
From: "36601"<sip:36601@172.18.193.98>
To: <sip:36602@172.18.193.120;user=phone>
Date: Mon, 01 Mar 1993 00:23:14 GMT
Call-ID: C6310C75-14F111CC-801D9792-19DC655A@172.18.193.98
Timestamp: 730945393
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 101 INVITE
Content-Type: application/sdp
Session: Media
Content-Length: 217
v=0
o=CiscoSystemsSIP-GW-UserAgent 637 6719 IN IP4 172.18.193.120
s=SIP Call
c=IN IP4 172.18.193.120
t=0 0
m=audio 18210 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

Note   The Terminating GW responds back that it can support RFC 2833 for DTMF-Relay. It communicates this is in its SDP body, in the m= and a= lines.
(F4)
Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.18.193.98:5060
From: "36601"<sip:36601@172.18.193.98>
To: <sip:36602@172.18.193.120;user=phone>;tag=154C54-A4F
Date: Mon, 01 Mar 1993 00:23:14 GMT
Call-ID: C6310C75-14F111CC-801D9792-19DC655A@172.18.193.98
Timestamp: 730945393
Server: Cisco-SIPGateway/IOS-12.x
Contact: <sip:36602@172.18.193.120:5060;user=phone>
CSeq: 101 INVITE
Content-Type: application/sdp
Content-Length: 217
v=0
o=CiscoSystemsSIP-GW-UserAgent 637 6719 IN IP4 172.18.193.120
s=SIP Call
c=IN IP4 172.18.193.120
t=0 0
m=audio 18210 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
(F5)
Sent:
ACK sip:36602@172.18.193.120:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 172.18.193.98:5060
From: "36601"<sip:36601@172.18.193.98>
To: <sip:36602@172.18.193.120;user=phone>;tag=154C54-A4F
Date: Mon, 01 Mar 1993 00:23:13 GMT
Call-ID: C6310C75-14F111CC-801D9792-19DC655A@172.18.193.98
Max-Forwards: 6
Content-Length: 0
CSeq: 101 ACK
(F6)
Received:
BYE sip:36601@172.18.193.98:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 172.18.193.120:5060
From: <sip:36602@172.18.193.120;user=phone>;tag=154C54-A4F
To: "36601"<sip:36601@172.18.193.98>
Date: Mon, 01 Mar 1993 00:23:15 GMT
Call-ID: C6310C75-14F111CC-801D9792-19DC655A@172.18.193.98
User-Agent: Cisco-SIPGateway/IOS-12.x
Max-Forwards: 6
Timestamp: 730945400
CSeq: 101 BYE
Content-Length: 0
(F7)
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.18.193.120:5060
From: <sip:36602@172.18.193.120;user=phone>;tag=154C54-A4F
To: "36601"<sip:36601@172.18.193.98>
Date: Mon, 01 Mar 1993 00:23:19 GMT
Call-ID: C6310C75-14F111CC-801D9792-19DC655A@172.18.193.98
Server: Cisco-SIPGateway/IOS-12.x
Timestamp: 730945400
Content-Length: 0
CSeq: 101 BYE

Figure C-3   SIP Call Using RFC2833 for DTMF-Relay

Table C-3  

Step Action Description

F1

INVITE—SIP Gateway 1 to
SIP Gateway 2

SIP gateway 1 sends an INVITE request to SIP gateway 2. The INVITE request is an invitation to User B to participate in a call session.

In the INVITE request:

  • The phone number of User B is inserted in the Request-URI field in the form of a SIP URL. The SIP URL identifies the address of User B and takes a form similar to an e-mail address (user@host where user is the telephone number and host is either a domain name or a numeric network address). In this example, the Request-URI field in the INVITE request to User B appears as "INVITE sip:3111100@64.102.17.80:5060; user=phone." The "user=phone" parameter distinguishes that the Request-URI address is a telephone number rather than a username.
  • PBX A is identified as the call session initiator in the From field.
  • A unique numeric identifier is assigned to the call and is inserted in the Call-ID field.
  • The transaction number within a single call leg is identified in the CSeq field.
  • The media capability (designated by m=) User A is ready to receive is specified. In this case m=audio 17158 RTP/AVP 0 18.
  • The port on which SIP gateway 1 is prepared to receive the RTP data is specified.

F2

100 Trying—SIP Gateway 2 to SIP Gateway 1

SIP gateway 2 sends a 100 Trying response to the INVITE request sent by SIP gateway 1. The 100 Trying response indicates that the INVITE request has been received by SIP gateway 2 but that User B has not yet been located and that some unspecified action, such as a database consultation, is taking place.

F3

183 Session Progress/QoS—
SIP Gateway 2 to SIP Gateway 1

SIP gateway 2 sends a 183 Session Progress response to SIP gateway 1. The 183 Session Progress response indicates that SIP gateway 2 has located, and is trying to perform inband alerting for the caller.

Additionally Quality of Service (QoS) reserves sufficient network-layer resources to guarantee bandwidth and bounds on packet loss, delay, and jitter; thus ensuring that the called party's phone rings only after bandwidth required for the call has been successfully reserved.

F4

200 OK—SIP Gateway 2 to
SIP Gateway 1

SIP gateway 2 sends a 200 OK response to SIP gateway 1. The 200 OK response notifies SIP gateway 1 that the connection has been made.

If User B supports the media capability advertised in the INVITE message sent by SIP gateway 1, it advertises the intersection of its own and User A's media capability in the 200 OK response. If User B does not support the media capability advertised by User A, it sends back a 400 Bad Request response with a 304 Warning header field.

F5

ACK—SIP Gateway 1 to
SIP Gateway 2

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

F6

BYE—SIP Gateway 2 to
SIP Gateway 1

SIP Gateway 2 sends a BYE request to SIP gateway 1. The BYE request indicates that User B wants to release the call. Because it is User B that wants to terminate the call, the Request-URI field is now replaced with PBX A's SIP URL and the From field contains User B's SIP URL.

F7

200 OK—SIP Gateway 1 to
SIP Gateway 2

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

SIP Call Using RFC 2833 for DTMF-Relay Output from GW1 Side

SIP Provisional Response Output from GW1 Side

GW1 ---INVITE---> GW2 (F1)
GW1 <-100Trying-- GW2 (F2)
GW1 <-183SesProg- GW2 (F3)
GW1 ---PRACK----> GW2 (F4)
GW1 <-200/PRACK-- GW2 (F5)
GW1 <---200OK---- GW2 (F6)
GW1 -----ACK----> GW2 (F7)
GW1 <----BYE----- GW2 (F8)
GW1 ---200OK----> GW2 (F9)
Note   The call-flows and headers are per IETF draft 'draft-ietf-sip-100rel-03.txt'
(F1)
Sent:
INVITE sip:36602@172.18.193.120;user=phone SIP/2.0
Via: SIP/2.0/UDP 172.18.193.98:5060
From: "36601"<sip:36601@172.18.193.98>;tag=27900-D65
To: <sip:36602@172.18.193.120;user=phone>
Date: Mon, 01 Mar 1993 00:02:42 GMT
Call-ID: E85BBD00-14EE11CC-800B9D18-7AB2874B@172.18.193.98
Supported: 100rel
Cisco-Guid: 3878326272-351146444-2148113688-2058520395
User-Agent: Cisco-SIPGateway/IOS-12.x
CSeq: 101 INVITE
Max-Forwards: 6
Timestamp: 730944162
Contact: <sip:36601@172.18.193.98:5060;user=phone>
Expires: 180
Content-Type: application/sdp
Content-Length: 183
v=0
o=CiscoSystemsSIP-GW-UserAgent 531 2364 IN IP4 172.18.193.98
s=SIP Call
c=IN IP4 172.18.193.98
t=0 0
m=audio 18582 RTP/AVP 0 18
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
Note   The SIP INVITE is sent requesting support for Provisional Response messages. This is communicated in the Supported: header.
(F2)
Received:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 172.18.193.98:5060
From: "36601"<sip:36601@172.18.193.98>;tag=27900-D65
To: <sip:36602@172.18.193.120;user=phone>;tag=20B28-E2A
Date: Mon, 01 Mar 1993 00:02:13 GMT
Call-ID: E85BBD00-14EE11CC-800B9D18-7AB2874B@172.18.193.98
Timestamp: 730944162
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 101 INVITE
Content-Length: 0
(F3)
Received:
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 172.18.193.98:5060
From: "36601"<sip:36601@172.18.193.98>;tag=27900-D65
To: <sip:36602@172.18.193.120;user=phone>;tag=20B28-E2A
Date: Mon, 01 Mar 1993 00:02:13 GMT
Call-ID: E85BBD00-14EE11CC-800B9D18-7AB2874B@172.18.193.98
Timestamp: 730944162
Server: Cisco-SIPGateway/IOS-12.x
Contact: <sip:36602@172.18.193.120:5060;user=phone>
CSeq: 101 INVITE
Require: 100rel
RSeq: 8289
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 162
v=0
o=CiscoSystemsSIP-GW-UserAgent 8320 2989 IN IP4 172.18.193.120
s=SIP Call
c=IN IP4 172.18.193.120
t=0 0
m=audio 18036 RTP/AVP 18
a=rtpmap:18 G729/8000
Note   The terminating GW responds back that it supports Provisional Responses, but sending the Require: and Content-Disposition: header.
(F4)
Sent:
PRACK sip:36602@172.18.193.120:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 172.18.193.98:5060
From: "36601"<sip:36601@172.18.193.98>;tag=27900-D65
To: <sip:36602@172.18.193.120;user=phone>;tag=20B28-E2A
Date: Mon, 01 Mar 1993 00:02:42 GMT
Call-ID: E85BBD00-14EE11CC-800B9D18-7AB2874B@172.18.193.98
CSeq: 102 PRACK
RAck: 8289 101 INVITE
Content-Length: 0
Note    The originating gateway responds back to the Provisional Response with a PRACK message.
(F5)
Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.18.193.98:5060
From: "36601"<sip:36601@172.18.193.98>;tag=27900-D65
To: <sip:36602@172.18.193.120;user=phone>;tag=20B28-E2A
Date: Mon, 01 Mar 1993 00:02:13 GMT
Call-ID: E85BBD00-14EE11CC-800B9D18-7AB2874B@172.18.193.98
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 102 PRACK
Content-Length: 0
(F6)
Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.18.193.98:5060
From: "36601"<sip:36601@172.18.193.98>;tag=27900-D65
To: <sip:36602@172.18.193.120;user=phone>;tag=20B28-E2A
Date: Mon, 01 Mar 1993 00:02:13 GMT
Call-ID: E85BBD00-14EE11CC-800B9D18-7AB2874B@172.18.193.98
Timestamp: 730944162
Server: Cisco-SIPGateway/IOS-12.x
Contact: <sip:36602@172.18.193.120:5060;user=phone>
CSeq: 101 INVITE
Content-Type: application/sdp
Content-Length: 162
v=0
o=CiscoSystemsSIP-GW-UserAgent 8320 2989 IN IP4 172.18.193.120
s=SIP Call
c=IN IP4 172.18.193.120
t=0 0
m=audio 18036 RTP/AVP 18
a=rtpmap:18 G729/8000
(F7)
Sent:
ACK sip:36602@172.18.193.120:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 172.18.193.98:5060
From: "36601"<sip:36601@172.18.193.98>;tag=27900-D65
To: <sip:36602@172.18.193.120;user=phone>;tag=20B28-E2A
Date: Mon, 01 Mar 1993 00:02:42 GMT
Call-ID: E85BBD00-14EE11CC-800B9D18-7AB2874B@172.18.193.98
Max-Forwards: 6
Content-Length: 0
CSeq: 101 ACK
(F8)
Received:
BYE sip:36601@172.18.193.98:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 172.18.193.120:5060
From: <sip:36602@172.18.193.120;user=phone>;tag=20B28-E2A
To: "36601"<sip:36601@172.18.193.98>;tag=27900-D65
Date: Mon, 01 Mar 1993 00:02:28 GMT
Call-ID: E85BBD00-14EE11CC-800B9D18-7AB2874B@172.18.193.98
User-Agent: Cisco-SIPGateway/IOS-12.x
Max-Forwards: 6
Timestamp: 730944154
CSeq: 101 BYE
Content-Length: 0
(F9)
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.18.193.120:5060
From: <sip:36602@172.18.193.120;user=phone>;tag=20B28-E2A
To: "36601"<sip:36601@172.18.193.98>;tag=27900-D65
Date: Mon, 01 Mar 1993 00:03:03 GMT
Call-ID: E85BBD00-14EE11CC-800B9D18-7AB2874B@172.18.193.98
Server: Cisco-SIPGateway/IOS-12.x
Timestamp: 730944154
Content-Length: 0
CSeq: 101 BYE

Figure C-4   SIP Provisional Response

Table C-4  

Step Action Description

F1

INVITE—SIP Gateway 1 to
SIP Gateway 2

SIP gateway 1 sends an INVITE request to SIP gateway 2. The INVITE request is an invitation to User B to participate in a call session.

In the INVITE request:

  • The phone number of User B is inserted in the Request-URI field in the form of a SIP URL. The SIP URL identifies the address of User B and takes a form similar to an e-mail address (user@host where user is the telephone number and host is either a domain name or a numeric network address). In this example, the Request-URI field in the INVITE request to User B appears as "INVITE sip:3111100@64.102.17.80:5060; user=phone." The "user=phone" parameter distinguishes that the Request-URI address is a telephone number rather than a user name.
  • PBX A is identified as the call session initiator in the From field.
  • A unique numeric identifier is assigned to the call and is inserted in the Call-ID field.
  • The transaction number within a single call leg is identified in the CSeq field.
  • The media capability (designated by m=) User A is ready to receive is specified. In this case m=audio 17158 RTP/AVP 0 18.
  • The port on which SIP gateway 1 is prepared to receive the RTP data is specified.

F2

100 Trying—SIP Gateway 2 to SIP Gateway 1

SIP gateway 2 sends a 100 Trying response to the INVITE request sent by SIP gateway 1. The 100 Trying response indicates that the INVITE request has been received by SIP gateway 2 but that User B has not yet been located and that some unspecified action, such as a database consultation, is taking place.

F3

183 Session Progress/QoS—
SIP Gateway 2 to SIP Gateway 1

SIP gateway 2 sends a 183 Session Progress response to SIP gateway 1. The 183 Session Progress response indicates that SIP gateway 2 has located, and is trying to perform inband alerting for the caller.

Additionally Quality of Service (QoS) reserves sufficient network-layer resources to guarantee bandwidth and bounds on packet loss, delay, and jitter; thus ensuring that the called party's phone rings only after bandwidth required for the call has been successfully reserved.

F4

PRACK—SIP Gateway 1 to
SIP Gateway 2

SIP gateway 1 acknowledges the 183 Session Progress response with a PRovisional ACKnowledgement (PRACK).

F5

200/PRACK—SIP Gateway 2 to SIP Gateway 1

The 200 OK/PRovisional ACKnowledgement (PRACK) response notifies SIP gateway 1 that the connection has been made.

The SIP gateway generates this response when the PBX indicates that the connection has been made. On receiving this response, the gateway forwards the response to the corresponding party and responds with a PRACK.

F6

200 OK—SIP Gateway 2 to
SIP Gateway 1

SIP gateway 2 sends a 200 OK response to SIP gateway 1. The 200 OK response notifies SIP gateway 1 that the connection has been made.

If User B supports the media capability advertised in the INVITE message sent by SIP gateway 1, it advertises the intersection of its own and User A's media capability in the 200 OK response. If User B does not support the media capability advertised by User A, it sends back a 400 Bad Request response with a 304 Warning header field.

F7

ACK—SIP Gateway 1 to
SIP Gateway 2

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

F8

BYE—SIP Gateway 2 to
SIP Gateway 1

SIP gateway 2 sends a BYE request to SIP gateway 1. The BYE request indicates that User B wants to release the call. Because it is User B that wants to terminate the call, the Request-URI field is now replaced with PBX A's SIP URL and the From field contains User B's SIP URL.

F9

200 OK—SIP Gateway 1 to
SIP Gateway 2

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

SIP Provisional Response Output from GW1 Side

SIP T.38 Call with QoS Enabled Output

GW1 -----INV-----> GW2 (F1)
GW1 <--100 Trying- GW2 (F2)
GW1 <--183 QoS --- GW2 (F3)
GW1 ----PRACK----> GW2 (F4)
GW1 <--200/PRACK-- GW2 (F5)
GW1 ----COMET----> GW2 (F6)
GW1 <--200/COMET-- GW2 (F7)
GW1 <--183SesProg- GW2 (F8)
GW1 ----PRACK----> GW2 (F9)
GW1 <--200/PRACK-- GW2 (F10)
GW1 <---200OK----- GW2 (F11)
GW1 -----ACK-----> GW2 (F12)
GW1 <-reINVITE/FAX GW2 (F13)
GW1 ----200OK----> GW2 (F14)
GW1 <----ACK------ GW2 (F15)
GW1 -----BYE-----> GW2 (F16)
GW1 <---200OK----- GW2 (F17)
Note   T.38 support is per T.38 Annex-D and the IETF draft 'draft-mule-sip-t38callflows-01.txt'. The call-flow below shows a call between two SIP Gateways, which are connected (via TDM) to fax machines.
(F1)
Received:
INVITE sip:2000@172.18.193.135;user=phone SIP/2.0
Via: SIP/2.0/UDP 172.18.193.187:5060;branch=1
Via: SIP/2.0/UDP 172.18.193.196:5060
From: "1000"<sip:1000@172.18.193.196>;tag=14B99A90-269E
To: <sip:2000@172.18.193.187;user=phone>
Date: Mon, 14 May 2001 17:42:42 GMT
Call-ID: F8C02D00-47BE11D5-805FE64C-BD156232@172.18.193.196
Supported: 100rel
Cisco-Guid: 4143344000-1203638741-2153637452-3172295218
User-Agent: Cisco-SIPGateway/IOS-12.x
CSeq: 101 INVITE
Max-Forwards: 5
Timestamp: 989858562
Contact: <sip:1000@172.18.193.196:5060;user=phone>
Expires: 180
Content-Type: application/sdp
Content-Length: 244
v=0
o=CiscoSystemsSIP-GW-UserAgent 5535 1304 IN IP4 172.18.193.196
s=SIP Call
c=IN IP4 172.18.193.196
t=0 0
m=audio 16608 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=qos:optional sendrecv
Note   Initial call is received. QoS is requested.
(F2)
Sent:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 172.18.193.187:5060;branch=1,SIP/2.0/UDP 172.18.193.196:5060
From: "1000"<sip:1000@172.18.193.196>;tag=14B99A90-269E
To: <sip:2000@172.18.193.187;user=phone>;tag=14B968AC-2668
Date: Mon, 14 May 2001 17:42:42 GMT
Call-ID: F8C02D00-47BE11D5-805FE64C-BD156232@172.18.193.196
Timestamp: 989858562
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 101 INVITE
Content-Length: 0
(F3)
Sent:
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 172.18.193.187:5060;branch=1,SIP/2.0/UDP 172.18.193.196:5060
From: "1000"<sip:1000@172.18.193.196>;tag=14B99A90-269E
To: <sip:2000@172.18.193.187;user=phone>;tag=14B968AC-2668
Date: Mon, 14 May 2001 17:42:42 GMT
Call-ID: F8C02D00-47BE11D5-805FE64C-BD156232@172.18.193.196
Timestamp: 989858562
Server: Cisco-SIPGateway/IOS-12.x
Contact: <sip:2000@172.18.193.135:5060;user=phone>
CSeq: 101 INVITE
Require: 100rel
RSeq: 5700
Content-Type: application/sdp
Content-Disposition: precondition;handling=required
Content-Length: 247
v=0
o=CiscoSystemsSIP-GW-UserAgent 5201 1828 IN IP4 172.18.193.135
s=SIP Call
c=IN IP4 172.18.193.135
t=0 0
m=audio 18036 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101
a=qos:optional sendrecv confirm
Note   QoS is sent.
(F4)
Received:
PRACK sip:2000@172.18.193.135:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 172.18.193.196:5060
From: "1000"<sip:1000@172.18.193.196>;tag=14B99A90-269E
To: <sip:2000@172.18.193.187;user=phone>;tag=14B968AC-2668
Date: Mon, 14 May 2001 17:42:42 GMT
Call-ID: F8C02D00-47BE11D5-805FE64C-BD156232@172.18.193.196
CSeq: 102 PRACK
RAck: 5700 101 INVITE
Content-Length: 0
(F5)
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.18.193.196:5060
From: "1000"<sip:1000@172.18.193.196>;tag=14B99A90-269E
To: <sip:2000@172.18.193.187;user=phone>;tag=14B968AC-2668
Date: Mon, 14 May 2001 17:42:42 GMT
Call-ID: F8C02D00-47BE11D5-805FE64C-BD156232@172.18.193.196
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 102 PRACK
Content-Length: 0
(F6)
Received:
COMET sip:2000@172.18.193.135:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 172.18.193.196:5060
From: "1000"<sip:1000@172.18.193.196>;tag=14B99A90-269E
To: <sip:2000@172.18.193.187;user=phone>;tag=14B968AC-2668
Date: Mon, 14 May 2001 17:42:42 GMT
Call-ID: F8C02D00-47BE11D5-805FE64C-BD156232@172.18.193.196
CSeq: 103 COMET
Content-Type: application/sdp
Content-Length: 243
v=0
o=CiscoSystemsSIP-GW-UserAgent 5535 1304 IN IP4 172.18.193.196
s=SIP Call
c=IN IP4 172.18.193.196
t=0 0
m=audio 16608 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=qos:success sendrecv
Note   Bidirectional QoS has been confirmed.
(F7)
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.18.193.196:5060
From: "1000"<sip:1000@172.18.193.196>;tag=14B99A90-269E
To: <sip:2000@172.18.193.187;user=phone>;tag=14B968AC-2668
Date: Mon, 14 May 2001 17:42:42 GMT
Call-ID: F8C02D00-47BE11D5-805FE64C-BD156232@172.18.193.196
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 103 COMET
Content-Length: 0
(F8)
Sent:
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 172.18.193.187:5060;branch=1,SIP/2.0/UDP 172.18.193.196:5060
From: "1000"<sip:1000@172.18.193.196>;tag=14B99A90-269E
To: <sip:2000@172.18.193.187;user=phone>;tag=14B968AC-2668
Date: Mon, 14 May 2001 17:42:42 GMT
Call-ID: F8C02D00-47BE11D5-805FE64C-BD156232@172.18.193.196
Timestamp: 989858562
Server: Cisco-SIPGateway/IOS-12.x
Contact: <sip:2000@172.18.193.135:5060;user=phone>
CSeq: 101 INVITE
Require: 100rel
RSeq: 5701
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 214
v=0
o=CiscoSystemsSIP-GW-UserAgent 5201 1828 IN IP4 172.18.193.135
s=SIP Call
c=IN IP4 172.18.193.135
t=0 0
m=audio 18036 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101
(F9)
Received:
PRACK sip:2000@172.18.193.135:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 172.18.193.196:5060
From: "1000"<sip:1000@172.18.193.196>;tag=14B99A90-269E
To: <sip:2000@172.18.193.187;user=phone>;tag=14B968AC-2668
Date: Mon, 14 May 2001 17:42:42 GMT
Call-ID: F8C02D00-47BE11D5-805FE64C-BD156232@172.18.193.196
CSeq: 104 PRACK
RAck: 5701 101 INVITE
Content-Length: 0
(F10)
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.18.193.196:5060
From: "1000"<sip:1000@172.18.193.196>;tag=14B99A90-269E
To: <sip:2000@172.18.193.187;user=phone>;tag=14B968AC-2668
Date: Mon, 14 May 2001 17:42:42 GMT
Call-ID: F8C02D00-47BE11D5-805FE64C-BD156232@172.18.193.196
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 104 PRACK
Content-Length: 0
(F11)
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.18.193.187:5060;branch=1,SIP/2.0/UDP 172.18.193.196:5060
From: "1000"<sip:1000@172.18.193.196>;tag=14B99A90-269E
To: <sip:2000@172.18.193.187;user=phone>;tag=14B968AC-2668
Date: Mon, 14 May 2001 17:42:42 GMT
Call-ID: F8C02D00-47BE11D5-805FE64C-BD156232@172.18.193.196
Timestamp: 989858562
Server: Cisco-SIPGateway/IOS-12.x
Contact: <sip:2000@172.18.193.135:5060;user=phone>
CSeq: 101 INVITE
Content-Type: application/sdp
Content-Length: 214
v=0
o=CiscoSystemsSIP-GW-UserAgent 5201 1828 IN IP4 172.18.193.135
s=SIP Call
c=IN IP4 172.18.193.135
t=0 0
m=audio 18036 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101
(F12)
Received:
ACK sip:2000@172.18.193.135:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 172.18.193.196:5060
From: "1000"<sip:1000@172.18.193.196>;tag=14B99A90-269E
To: <sip:2000@172.18.193.187;user=phone>;tag=14B968AC-2668
Date: Mon, 14 May 2001 17:42:42 GMT
Call-ID: F8C02D00-47BE11D5-805FE64C-BD156232@172.18.193.196
Max-Forwards: 6
Content-Length: 0
CSeq: 101 ACK
(F13)
Sent:
INVITE sip:1000@172.18.193.196:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 172.18.193.135:5060
From: <sip:2000@172.18.193.187;user=phone>;tag=14B968AC-2668
To: "1000"<sip:1000@172.18.193.196>;tag=14B99A90-269E
Date: Mon, 14 May 2001 17:43:11 GMT
Call-ID: F8C02D00-47BE11D5-805FE64C-BD156232@172.18.193.196
Supported: 100rel
Cisco-Guid: 4143344000-1203638741-2153637452-3172295218
User-Agent: Cisco-SIPGateway/IOS-12.x
CSeq: 101 INVITE
Max-Forwards: 6
Timestamp: 989858591
Contact: <sip:2000@172.18.193.135:5060;user=phone>
Expires: 180
Content-Type: application/sdp
Content-Length: 403
v=0
o=CiscoSystemsSIP-GW-UserAgent 5201 1829 IN IP4 172.18.193.135
s=SIP Call
c=IN IP4 172.18.193.135
t=0 0
m=image 18036 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxFillBitRemoval:0
a=T38FaxTranscodingMMR:0
a=T38FaxTranscodingJBIG:0
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:200
a=T38FaxMaxDatagram:72
a=T38FaxUdpEC:t38UDPRedundancy
a=qos:optional sendrecv
Note   T.38 is signaled via a reINVITE message with the T.38 parameters defined in the SDP body.
(F14)
Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.18.193.135:5060
From: <sip:2000@172.18.193.187;user=phone>;tag=14B968AC-2668
To: "1000"<sip:1000@172.18.193.196>;tag=14B99A90-269E
Date: Mon, 14 May 2001 17:43:11 GMT
Call-ID: F8C02D00-47BE11D5-805FE64C-BD156232@172.18.193.196
Server: Cisco-SIPGateway/IOS-12.x
Contact: <sip:1000@172.18.193.196:5060;user=phone>
CSeq: 101 INVITE
Content-Type: application/sdp
Content-Length: 138
v=0
o=CiscoSystemsSIP-GW-UserAgent 5535 1305 IN IP4 172.18.193.196
s=SIP Call
c=IN IP4 172.18.193.196
t=0 0
m=image 16608 udptl t38
T.38 is acknowledged. At this point the FAX will be sent using UDPTL.
(F15)
Sent:
ACK sip:1000@172.18.193.196:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 172.18.193.135:5060
From: <sip:2000@172.18.193.187;user=phone>;tag=14B968AC-2668
To: "1000"<sip:1000@172.18.193.196>;tag=14B99A90-269E
Date: Mon, 14 May 2001 17:43:11 GMT
Call-ID: F8C02D00-47BE11D5-805FE64C-BD156232@172.18.193.196
Max-Forwards: 6
Content-Length: 0
CSeq: 101 ACK
(F16)
Received:
BYE sip:2000@172.18.193.135:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 172.18.193.196:5060
From: "1000"<sip:1000@172.18.193.196>;tag=14B99A90-269E
To: <sip:2000@172.18.193.187;user=phone>;tag=14B968AC-2668
Date: Mon, 14 May 2001 17:43:11 GMT
Call-ID: F8C02D00-47BE11D5-805FE64C-BD156232@172.18.193.196
User-Agent: Cisco-SIPGateway/IOS-12.x
Max-Forwards: 6
Timestamp: 989858617
CSeq: 105 BYE
Content-Length: 0
(F17)
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.18.193.196:5060
From: "1000"<sip:1000@172.18.193.196>;tag=14B99A90-269E
To: <sip:2000@172.18.193.187;user=phone>;tag=14B968AC-2668
Date: Mon, 14 May 2001 17:43:37 GMT
Call-ID: F8C02D00-47BE11D5-805FE64C-BD156232@172.18.193.196
Server: Cisco-SIPGateway/IOS-12.x
Timestamp: 989858617
Content-Length: 0
CSeq: 105 BYE

Figure C-5   
SIP T.38 Call with QoS Enabled

Table C-5  

Step Action Description

F1

INVITE—SIP Gateway 1 to
SIP Gateway 2

SIP gateway 1 sends an INVITE request to SIP gateway 2. The INVITE request is an invitation to User B to participate in a call session.

In the INVITE request:

  • The phone number of User B is inserted in the Request-URI field in the form of a SIP URL. The SIP URL identifies the address of User B and takes a form similar to an e-mail address (user@host where user is the telephone number and host is either a domain name or a numeric network address). In this example, the Request-URI field in the INVITE request to User B appears as "INVITE sip:3111100@64.102.17.80:5060; user=phone." The "user=phone" parameter distinguishes that the Request-URI address is a telephone number rather than a username.
  • PBX A is identified as the call session initiator in the From field.
  • A unique numeric identifier is assigned to the call and is inserted in the Call-ID field.
  • The transaction number within a single call leg is identified in the CSeq field.
  • The media capability (designated by m=) User A is ready to receive is specified. In this case m=audio 17158 RTP/AVP 0 18.
  • The port on which SIP gateway 1 is prepared to receive the RTP data is specified.

F2

100 Trying—SIP Gateway 2 to SIP Gateway 1

SIP gateway 2 sends a 100 Trying response to the INVITE request sent by SIP gateway 1. The 100 Trying response indicates that the INVITE request has been received by SIP gateway 2 but that User B has not yet been located and that some unspecified action, such as a database consultation, is taking place.

F3

183 Session Progress/QoS—
SIP Gateway 2 to SIP Gateway 1

SIP gateway 2 sends a 183 Session Progress response to SIP gateway 1. The 183 Session Progress response indicates that SIP gateway 2 has located, and is trying to perform inband alerting for the caller.

Additionally Quality of Service (QoS) reserves sufficient network-layer resources to guarantee bandwidth and bounds on packet loss, delay, and jitter; thus ensuring that the called party's phone rings only after bandwidth required for the call has been successfully reserved.

F4

PRACK—SIP Gateway 1 to
SIP Gateway 2

SIP gateway 1 acknowledges the 183 Session Progress response with a PRovisional ACKnowledgement (PRACK).

F5

200/PRACK—SIP Gateway 2 to SIP Gateway 1

The 200 OK/PRovisional ACKnowledgement (PRACK) response notifies SIP gateway 1 that the connection has been made.

The SIP gateway generates this response when the PBX indicates that the connection has been made. On receiving this response, the gateway forwards the response to the corresponding party and responds with a PRACK.

F6

COMET—SIP Gateway 1 to
SIP Gateway 2

SIP gateway 1 sends a COnditions MET (COMET) response to SIP gateway 2 indicating that the pre-conditions have been met.

F7

200/COMET—SIP Gateway 2 to SIP Gateway 1

SIP gateway 2 sends a COnditions MET (COMET) response to SIP gateway 1 indicating that the preconditions have been met.

F8

183 Session Progress—
SIP Gateway 2 to SIP Gateway 1

The 183 Session Progress response is used to perform inband alerting for the caller.

F9

PRACK—SIP Gateway 1 to
SIP Gateway 2

SIP gateway 1 acknowledges the 183 Session Progress response with a PRovisional ACKnowledgement (PRACK).

F10

200/PRACK—SIP Gateway 2 to SIP Gateway 1

The 200 OK/PRovisional ACKnowledgement (PRACK) response notifies SIP gateway 1 that the connection has been made.

The SIP gateway generates this response when the PBX indicates that the connection has been made. On receiving this response, the gateway forwards the response to the corresponding party and responds with a PRACK.

F11

200 OK—SIP Gateway 2 to
SIP Gateway 1

SIP gateway 2 sends a 200 OK response to SIP gateway 1. The 200 OK response notifies SIP gateway 1 that the connection has been made.

If User B supports the media capability advertised in the INVITE message sent by SIP gateway 1, it advertises the intersection of its own and User A's media capability in the 200 OK response. If User B does not support the media capability advertised by User A, it sends back a 400 Bad Request response with a 304 Warning header field.

F12

ACK—SIP Gateway 1 to
SIP Gateway 2

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

F13

reINVITE/FAX—
SIP Gateway 2 to SIP Gateway 1

SIP gateway 2 receives the initial Fax Tones (T4/T30). It sends a SIP reINVITE to negotiate the T.38 Fax-Relay capabilities.

F14

200 OK—SIP Gateway 1 to
SIP Gateway 2

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

F15

ACK—SIP Gateway 2 to
SIP Gateway 1

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

F16

BYE—SIP Gateway 1 to
SIP Gateway 2

SIP gateway 1 sends a BYE request to SIP gateway 2. The BYE request indicates that User B wants to release the call. Because it is User B that wants to terminate the call, the Request-URI field is now replaced with PBX A's SIP URL and the From field contains User B's SIP URL.

F17

200 OK—SIP Gateway 2 to
SIP Gateway 1

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

SIP T.38 Call with QoS Enabled Output


hometocprevnextglossaryfeedbacksearchhelp
Posted: Wed Jan 15 01:20:16 PST 2003
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.