[asterisk-dev] PRI Cause codes arriving during dial are lost

Stephen Davies stephen.l.davies at gmail.com
Fri Feb 17 03:33:44 MST 2006


Steve Davies here.

I'm at a customer today looking at trying to detect in as much detail
as possible the result of outbound calls.

So far as I can see, detailed PRI cause codes that arrive "during" a
dial attempt are lost.

In the example I looked out, we dial out with a SETUP, receive some
call progress messages and then receive a DISCONNECT.  Mostly cause
code 16, (normal_clearing), occasionally 28 (invalid_number) or 31

This is all before the call in answered.

HANDLE_CAUSE macro in app_dial processes these all the same -
resulting in the Dial returning CHANUNAVAIL.

This reminds me again that the returns from Dial are rather broadly defined...

Further, the actual PRI cause code that came back in the DISCONNECT
seems to be lost.  I'll need to test more, but ${HANGUPCAUSE} just
seems to be blank.

On the face of it that is strange - app_dial.c sets the hangupcause on
the calling channel, and that's what HANGUPCAUSE returns, so maybe
something else reset it, or my test was wrong somehow.

Anyway - what's my asterisk-dev questions...?

Are there opinions or a strategy to rework the Dial return codes?  Is
it just me who feels this isn't as complete as it could be?


More information about the asterisk-dev mailing list