DIALSTATUS Vs HANGUPCAUSE

Home » Asterisk Users » DIALSTATUS Vs HANGUPCAUSE
Asterisk Users 4 Comments

Hello list, Hope all doing well!

I’ve been checking some cases when a Dial fails and dialplan execution continues to handle this. I am finding it a little confusing how we should handle the DIALSTATUS and the HANGUPCAUSE in this situation…. More specifically, I am facing a case in version 13.6.0 where I am getting a DIALSTATUS=BUSY and HANGUPCAUSE after receiving a 480 SIP error. Seems wrong to me, since 480 should be converted to HANGUPCAUSE and DIALSTATUS
= NOANSWER (https://wiki.asterisk.org/wiki/display/AST/Hangup+Cause+Mappings). Anyway I am thinking about actually not checking the DIALSTATUS anymore and just rely on the HANGUPCAUSE, which seems more powerful. Looks like for a pure SIP environment the HANGUPCAUSE would have a more accurate information about the error. So question is can I always use this info and completely ignore what the DIALSTATUS is?
Or does someone knows exactly where is more suitable to use one over the other?

Thanks, Kind regards, Patrick Wakano

4 thoughts on - DIALSTATUS Vs HANGUPCAUSE

  • Thanks Dovid!
    Indeed looks a bug but regardless of this, this problem made me think that the HANGUPCAUSE could be used for this purpose with benefits. I couldn’t find an explanation about when DIALSTATUS would actually be better. The HANGUPCAUSE was reworked in version 11 (
    https://wiki.asterisk.org/wiki/display/AST/Hangup+Cause) but I didn’t find someone actually stating it is a better alternative or replacement to the DIALSTATUS or something similar.

    Cheers, Patrick Wakano

  • In article , Patrick Wakano wrote:

    I think you should always check DIALSTATUS, as that will be set regardless of the way in which a dial fails. I believe HANGUPCAUSE is set to the Q.931 code received from PRI or SIP when a call is rejected or terminated. However, there could be other mechanisms for failure (such as failure to create a channel within Asterisk, or an attempt to send to an unreachable peer), that may set DIALSTATUS without setting HANGUPCAUSE.

    So HANGUPCAUSE should be considered as extra detail, rather than a replacement or alternative to DIALSTATUS.

    Cheers Tony

  • That’s really good info Tony!
    Thanks very much for the response!
    I will consider this to implement a better approach for the failed cases!

    Cheers, Patrick Wakano