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 Call with Diversion Header Added for Call-Diversion Output from GW1 Side
SIP Call with RSVP QoS Output from GW1 Side
SIP Call Using RFC2833 for DTMF-Relay Output from GW1 Side
SIP Provisional Response Output from GW1 Side
SIP T.38 Call with QoS Enabled Output

Note For an explanation of SIP functions, methods, and responses see
"Cisco SIP Compliance Reference Information" .

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 MUST appear in INVITE and REGISTER requests and in 200 responses. It can appear in ACK, and in other 1xx, 2xx, 3xx, 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 gateway uses Diversion header in initial outgoing messages.
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 MUST contain a tag. 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 service processing a request MUST always add a tag to To-header.
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. When the UAC creates a request, it MUST insert a Via into that request.

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

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.

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 gets the 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 488 Unacceptable Media 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 with attribute a = qos mandatory sendrecv in SDP body

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

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). After sending PRACK, gateway1 starts resource reservation on its end.

F5

200/PRACK—SIP Gateway 2 to SIP Gateway 1

The 200 OK/PRovisional ACKnowledgement (PRACK) indicates that gateway2 received PRACK, and gateway1 does not need to retransmit.

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.

Note: After IOS Release12.3(1)T, gateway also accepts an UPDATE.

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

200 OK to INVITE is sent when the callee answers the call, and gateway gets an isdn CONNECT.

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 <payload> 101command. The terminating gateway honors originator's choice of payload type, so payload type 115 is used for dtmf-relay.

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 115

a=rtpmap:18 G729/8000

a=rtpmap:115 telephone-event/8000

a=fmtp:115 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 115

a=rtpmap:18 G729/8000

a=rtpmap:115 telephone-event/8000

a=fmtp:115 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 115

a=rtpmap:18 G729/8000

a=rtpmap:115 telephone-event/8000

a=fmtp:115 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

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 RFC 3262.

(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 RSeq: 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 username.

The UAC indicates its support of reliable provisional response by adding a Supported: 100rel header to the INVITE.

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.

The UAS indicates its support of reliable provisional response by adding a Require header field containing the option tag 100rel, and an RSeq header field.

F4

PRACK—SIP Gateway 1 to
SIP Gateway 2

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

The UAC adds a RAck header in PRACK. RAck header consists of two numbers and a method tag. The first number is the value from the RSeq header in the provisional response that is being acknowledged. The second number and the method are copied from the CSeq in the response that is being acknowledged.

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 RFC 3262. 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.

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). After sending PRACK, gateway1 starts resource reservation on its end.

F5

200/PRACK—SIP Gateway 2 to SIP Gateway 1

The 200 OK/PRovisional ACKnowledgement (PRACK) indicates that gateway2 received PRACK, and gateway1 does not need to retransmit.

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.

Note: After IOS Release12.3(1)T, gateway also accepts an UPDATE.

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

Table of Contents