Overview

The Reason Header field for SIP is included in each of the following messages. (ITU-T Recommendation Q.850)

• BYE

• CANCEL

• 4xx, 5xx, and 6xx messages

Up till software 10.3.3 the IMG had the ability to propagate the Reason Header in each of the above messages from the TDM leg of the call to the SIP leg of the call. The Reason Header would indicate why a SIP request or response was issued. In software 10.5.0 the ability to propagate the Reason Header from the SIP leg of a call to the TDM side of the call was added. The Reason Header Field in each of the SIP messages is used primarily for debugging problems in a circuit. Clients and servers are free to ignore this header field as it has no impact on protocol processing. The Reason Header Field satisfies RFC 3326. The Reason Header field now gives the customer the ability to propagate cause code information from SIP to TDM and TDM to SIP without having to configure SIP-T.

As of software 10.5.3 SP4.3 a feature was added which takes the cause code parameter added to the SS7 ACM (Answer Complete) or CPG (Call Progress) message and inter-works it into a SIP Reason Header in the 183 Session Progress message. See Call Flow diagram below. There is no extra configuration needed for the call flow below to occur

Open

Call Tracing

Support Personnel can enable Call Tracing on the IMG. Once this is accomplished all Reason Header information will be printed out for the following messages:

• BYE

• CANCEL

• 4xx, 5xx, and 6xx messages

Benefits:

This feature is useful for debugging purpose, particularly if there is a call failure in SIP to SS7 traffic. Below are Call Flows and their corresponding Call Traces. Note that for reference the Reason Header field is shown in red.

Implementation (Message propagates from TDM to SIP)

CASE #1 - Cause Number 1 (404 message)

A call is generated from the SIP side to the IMG. The IMG then converts to an SS7 network and receives the IAM message. The SS7 leg sends a release with cause code of 1 (Unallocated Number). The IMG then would send a SIP 404 message with the cause code in the Reason Header indicating the problem is an Unallocated (unassigned) number. See Call Flow and Call Trace below

Call Flow

Open

Call Trace

CASE #2 - Cause Number 17 (486 message)

A call is generated from the SIP side to the IMG. The IMG then converts to an SS7 network and receives the IAM message. The SS7 leg sends a release with cause code of 17 (User Busy). The IMG then would send a SIP 486 message with the cause code in the Reason Header indicating the problem is User Busy. See Call Flow and Call Trace below

Call Flow

Call Trace

CASE #3 - Cause Number 16 (BYE message)

A call is generated from the SS7 side to the IMG. The IMG then converts to a SIP network and receives the INVITE message. The SIP side then sends a 180 ringing response. The SIP side then sends a 200 OK message and the call gets connected. After a while the phone is hung up and the SS7 leg sends a RELEASE with cause code of 16 (Normal Clearing). The IMG then would send a SIP BYE message with the cause code in the Reason Header indicating the problem is a Normal Clearing. See Call Flow and Call Trace below

Call Flow

Call Trace

CASE #4 - Cause Number 3 (404 message)

If the user dials an incorrect number that is not in the route table the IMG will reject the call and send a 404 Not Found to the SIP side.

Call Flow

Call Trace

CASE #5 - Cause Number 1 (404 message)

In case the user dials correct number but incoming translation table has wrong number, then IMG would reject the call and send a 404 Not Found to the SIP side.

Call Flow

Call Trace

Implementation  (Message propagates from SIP to SIP)

CASE #1 - SIP to SIP

In the case of SIP to SIP traffic, the Reason header field is usually not needed in responses because the status code and the reason phrase already provide sufficient information, according to RFC 3326.  However, the Reason Header is included for BYE, 4xx, 5xx, and 6xx.  Please note that CANCEL message in the SIP to SIP traffic does not include the Reason header field.

Call Flow

Call Trace

CASE #2 - 487 Message

In the case below, where SIP sends an INVITE message and then sends CANCEL, the IMG sends a 487 Request Terminated in response to the CANCEL message.

Call Flow

Call Trace

Implementation  (Message propagates from SIP to TDM)

CASE #1:

Cause Number

A call is generated from SS7 protocol and sent to the IMG. IMG1 converts from SS7 to SIP. Call is then sent to IMG2 where it converts the SIP messaging back to SS7 and the call goes out of IMG2 using SS7 protocol. The call is then release by hanging phone up or any such normal call release scenario. Note the RELEASE message has the reason header information. Below is Call Flow.

Call Trace