IMG 1010 - 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.

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

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

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.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: 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.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=a94c095b773be1dd6e8d

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: <sip:6170@10.129.39.123:5060>;tag=8262313b

From: <sip:unavailable@10.129.39.59>;tag=95ffcd055e0f78f7d5d397020e89288d2b07

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: <sip:10.129.39.59:5060>

Call-ID: 3355d752f5739754ZjIzZDY3ZjU4ODA3NmRhODdmNGI4Y2M0NGRmNTYyMTY.

From: "Boston"<sip:dtran@10.129.39.59>;tag=2816b75a

To: "999"<sip:999@10.129.39.59>;tag=a94c095b773be1dd6e8d668a785a9c84de15

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

Contact: <sip:10.129.39.59:5060>

Call-ID: 3355d752f5739754ZjIzZDY3ZjU4ODA3NmRhODdmNGI4Y2M0NGRmNTYyMTY.

From: "Boston"<sip:dtran@10.129.39.59>;tag=2816b75a

To: "999"<sip:999@10.129.39.59>;tag=a94c095b773be1dd6e8d668a785a9c84de15

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: <sip:1234@10.129.39.123:5060>;tag=d47d7510

From: <sip:1000@10.129.39.59>;tag=95ffcd055e0f78f7d5d397020e89288d708e

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: <sip:10.129.39.59:5060>

Call-ID: 1-1260@10.129.39.123

From: sipp <sip:1000@10.129.39.123:5070>;tag=1

To: sut <sip:1234@10.129.39.59:5060>;tag=a94c095b773be1dd6e8d668a785a9c84e50d

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: <sip:5088623500@10.129.45.107:5060>;tag=a94c095b773be1dd6e8d668a785a9c84089db2cd\r\n

From: <sip:000100@10.129.45.104>;tag=95ffcd055e0f78f7d5d397020e89288d4e3f1b4c\r\n

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

Return to Documentation Home I Return to Sangoma Support