SIP Reason Header
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.
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
Note: In case of multiple Reason Headers presented in the incoming SIP message, only the first Reason Header is decoded.
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
Call Trace
<--- [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.1 23
Contact:
Call-ID: 2b61265d2e589e06ZjIzZDY3ZjU4ODA3NmRhODdmNGI4Y2M0NGRmNTYyMTY.
From: "Boston"
To: "508"
CSeq: 1 INVITE
Server: Cantata-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 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
<--- [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.1 23
Contact:
Call-ID: 1c214262d2299f3cZjIzZDY3ZjU4ODA3NmRhODdmNGI4Y2M0NGRmNTYyMTY.
From: "Boston"
To: "508"
668a785a9c84c527
CSeq: 1 INVITE
Server: Cantata-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 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
<--- [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:
From:
User-Agent: Cantata-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 will reject the call and send a 404 Not Found to the SIP side.
Call Flow
Call Trace
<--- [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-47486a49a1277175-1--d87543-; rport;received=10.129.39.1
23
Contact:
Call-ID: 3355d752f5739754ZjIzZDY3ZjU4ODA3NmRhODdmNGI4Y2M0NGRmNTYyMTY.
From: "Boston"
To: "999"
CSeq: 1 INVITE
Server: Cantata-SIP/10.3.2.37 Boston 0
Reason: Q.850 ;cause=3 ; text="No route to destination"
Content-Length: 0
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
<--- [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-47486a49a1277175-1--d87543-; rport;received=10.129.39.1
23
Contact:
Call-ID: 3355d752f5739754ZjIzZDY3ZjU4ODA3NmRhODdmNGI4Y2M0NGRmNTYyMTY.
From: "Boston"
To: "999"
CSeq: 1 INVITE
Server: Cantata-SIP/10.3.2.37 Boston 0
Reason: Q.850 ;cause=1 ; text="Unallocated (unassigned) number"
Content-Length: 0
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
<--- [10.129.39.123, 5060 <- 10.129.39.59, 5060]
BYE sip:1234@10.129.39.123:5060 SIP/2.0
Via: SIP/2.0/UDP 10.129.39.59:5060; rport;branch=z9hG4bK-2701-1786-19997-394 Call-ID: 2a97-402-01197002928-Boston-0@10.129.39.59
CSeq: 2 BYE
Max-Forwards: 70
To:
From:
User-Agent: Cantata-SIP/10.3.2.37 Boston 0
Reason: SIP ;cause=16 ; text="Normal call clearing"
Content-Length: 0
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
<--- [10.129.39.123, 5070 <- 10.129.39.59, 5060]
SIP/2.0 487 Request Terminated
Via: SIP/2.0/UDP
10.129.39.123:5070;branch=z9hG4bK-675e-1160585843-19988-10-129-39-123;received=10.129.39.123 Contact:
Call-ID: 1-1260@10.129.39.123
From: sipp
To: sut
CSeq: 1 INVITE
Server: Cantata-SIP/10.3.2.37 Boston 0
Reason: SIP ;cause=487 ; text="Request Terminated"
Content-Length: 0
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
<--- [10.129.45.107, 5060 <- 10.129.45.104, 5060]
BYE sip:5088623500@10.129.45.107:5060 SIP/2.0\r\n
Via: SIP/2.0/UDP 10.129.45.104:5060;rport;branch=z9hG4bK-149e-1196263031-19999-118\r\n
Call-ID: 3109-400-10282007151646-Boston-0@10.129.45.104\r\n
CSeq: 2 BYE\r\n
Max-Forwards: 0\r\n
To:
User-Agent: Cantata-SIP/10.5.0.143 Boston 0\r\n
Reason: Q.850 ;cause=31 ;text="Normal, unspecified"\r\n
Content-Length: 0\r\n
\r\n