SIP Reason Header

1 Configuration
2 Call Tracing
3 Implementation (Message propagates from SIP to SIP)
- 3.1 CASE #1 - SIP to SIP
- 3.2 CASE #2 - 487 Message
4 Implementation (Message propagates from SIP to TDM)
- 4.1 CASE #1 - Cause Number

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.

The SIP Reason Header is interworked/propagated from both SIP to TDM and TDM to SIP. The Reason Header indicates why a SIP request or response was issued. 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 also gives the customer the ability to propagate cause code information from SIP to TDM and TDM to SIP without having to configure SIP-T.

In case of multiple Reason Headers presented in the incoming SIP message, only the first Reason Header is decoded.

Configuration

Interworking of incoming SIP messages containing a SIP Reason header is configured with the Incoming Reason Header Cause Code field in the SIP Profile - Advanced Settings object

Call Tracing

You can enable Call Tracing on the IMG 2020. Once this is accomplished all Reason Header information will be printed out for the messages displayed above. Below are Call Flows and their corresponding Call Traces. For reference purposes, the Reason Header field is displayed in red.

CASE #1 - Cause Number 1 (404 message)

A call is generated from SIP to SS7. The IMG 2020 receives an INVITE message and transmits the IAM. The SS7 leg sends a release with cause code of 1 (unallocated Number). The IMG 2020 sends 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.

<--- [10.129.39.123, 5060 <- 10.129.39.59, 5060]
SIP/2.0 404 Not Found Call processing released
Via: SIP/2.0/UDP 10.129.39.123:5060;branch=z9hG4bK-d87543-672bb759901c9e2a-1--d87543-; rport;received=10.129.39.123
Contact: <sip:10.129.39.59:5060>
Call-ID: 2b61265d2e589e06ZjIzZDY3ZjU4ODA3NmRhODdmNGI4Y2M0NGRmNTYyMTY.
From: "Boston"<sip:dtran@10.129.39.59>;tag=f818c458
To: "508"<sip:508@10.129.39.59>;tag=a94c095b773be1dd6e8d668a785a9c8449dc
CSeq: 1 INVITE
Server: Dialogic-SIP/10.3.2.22 Boston 0
Reason: Q.850 ;cause=1 ; text="Unallocated (unassigned) number"
Content-Length: 0

CASE #2 - Cause Number 17 (486 message)

A call is generated from SIP to SS7. The IMG 2020 receives the INVITE message and transmits the IAM to SS7 side. The SS7 leg sends a release with cause code of 17 (User Busy). The IMG 2020 sends 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

<--- [10.129.39.123, 5060 <- 10.129.39.59, 5060]
SIP/2.0 486 Busy Here Call processing released
Via: SIP/2.0/UDP 10.129.39.123:5060;branch=z9hG4bK-d87543-af44ae69a320e04a-1--d87543-; rport;received=10.129.39.123
Contact: <sip:10.129.39.59:5060>
Call-ID: 1c214262d2299f3cZjIzZDY3ZjU4ODA3NmRhODdmNGI4Y2M0NGRmNTYyMTY.
From: "Boston"<sip:dtran@10.129.39.59>;tag=244d4425
To: "508"<sip:508@10.129.39.59>;tag=a94c095b773be1dd6e8d668a785a9c84c527
CSeq: 1 INVITE
Server: Dialogic-SIP/10.3.2.22 Boston 0
Reason: Q.850 ;cause=17 ; text="User busy"
Content-Length: 0

CASE #3 - Cause Number 16 (BYE message)

A call is generated from the SS7 to SIP. The IMG 2020 receives the IAM and transmits the INVITE message to SIP side. The SIP side then responds with a 180 ringing. The SIP side then transmits 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 2020 sends 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.

<--- [10.129.39.123, 5060 <- 10.129.39.59, 5060]
BYE sip:6170@10.129.39.123:5060 SIP/2.0
Via: SIP/2.0/UDP 10.129.39.59:5060; rport;branch=z9hG4bK-3a95-46623-19995-361
Call-ID: aa2-404-01197012570-Boston-0@10.129.39.59
CSeq: 2 BYE
Max-Forwards: 70
To: <sip:6170@10.129.39.123:5060>;tag=8262313b
From: <sip:unavailable@10.129.39.59>;tag=95ffcd055e0f78f7d5d397020e89288d2b07
User-Agent: Dialogic-SIP/10.3.2.22 Boston 0
Reason: Q.850 ;cause=16 ; text="Normal call clearing"
Content-Length: 0

CASE #4 - Cause Number 3 (404 message)

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

CASE #5 - Cause Number 1 (404 message)

The user dials correct number but incoming translation table has wrong number, the IMG 2020 would reject the call and send a 404 response which is Not Found to the SIP side.

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.

CASE #2 - 487 Message

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

Implementation (Message propagates from SIP to TDM)

CASE #1 - Cause Number

A call is generated from SS7 protocol and sent to the IMG 2020 A. The IMG 2020 A converts from SS7 to SIP protocol. Call is then sent to IMG 2020 B where it converts the SIP messaging back to SS7. The call goes out of IMG 2020 B 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.

Dialogic Integrated Media Gateways