SIP_CAUSE always empty


I have the following dialplan, and when the hard sip account and she is uncredited, the variable ${DIALSTATUS} back as congested. Next get “Got SIP response 402” Payment Required "back from 1XX.1XX.1XX.1XX: 5060."
I’m trying to use $ {HASH (SIP_CAUSE, $ {CDR (dstchannel)})} to get the return code sip. But always come back empty.


exten => _XXXXXXXXXXX,1,Dial(SIP/7012815/${EXTEN}) exten => _XXXXXXXXXXX,n,Verbose(2,SIP return code : ${HASH(SIP_CAUSE,${CDR(dstchannel)})}) exten => _XXXXXXXXXXX,n,Hangup


-- Executing [06XXXXXXXX5@from-internal:1] Dial("SIP/95-00000004", "SIP/7012815/06XXXXXXXX5,120,grWjL(3600000)") in new stack -- Setting call duration limit to 3600.000 seconds. == Using SIP RTP CoS mark 5 -- Called SIP/7012815/06XXXXXXXX5 -- Got SIP response 402 "Payment Required" back from 1XX.1XX.1XX.1XX:5060 == Everyone is busy/congested at this time (1:0/0/1) -- Executing [06XXXXXXXX5@from-internal:2] Verbose("SIP/95-00000004", "2,SIP return code : ") in new stack == SIP return code : -- Executing [06XXXXXXXX5@from-internal:3] Hangup("SIP/95-00000004", "") in new stack == Spawn extension (from-internal, 06XXXXXXXX5, 3) exited non-zero on 'SIP/95-00000004'

Any tips?

OS: Debian 6 - Kernel 2.6.32

Best Regards,


I have also tried using the parameter use_q850_reason, but not solved. :frowning:

“After some internal discussion, we decided to consider disabling this feature by default in
future 1.8 versions. This would be an unexpected behavior change for
anyone depending on that SIP_CAUSE update in their dialplan” … 50626.html

You need to explicitly set storesipcause to true/yes.

it’s not working for me either.
I’m running asterisk and have added storesipcause=yes to my sip.conf.

sip show settings returns:

Q.850 Reason header: No Store SIP_CAUSE: Yes
My SIP_CAUSE var is always empty.


What am I missing ??

Why don’t you dump all keys from the table using HASHKEYS(SIP_CAUSE) and see if any of them matches ${CDR(dstchannel)} ?
Debugging 101 :wink:

Thanks Thor,
excellent advice! For some reason I wasn’t aware of the HASHKEYS function.

Turns out that approx. 1h after I added ‘storesipcause=yes’ and did sip reload the SIP_CAUSE var produced some output.
The same behaviour happened on my other server. Both servers are running

Anyway - problem is solved for me.