[Home]

Summary:ASTERISK-01328: [Request] Can Hangup have a "cause" parameter
Reporter:revk (revk)Labels:
Date Opened:2004-04-02 07:57:07.000-0600Date Closed:2011-06-07 14:04:48
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:There is Congestion, Hangup and Busy which all do much the same thing it seems. Can one of them, or perhaps a new "Clear"  or "Release" application take a cause code parameter so that it is possible to send different Q.931 cause codes to the ISDN/PRI line.

****** ADDITIONAL INFORMATION ******

This would allow us to specificically indicate that numbers we do not currently use are "invalid" rather than just busy, etc, and so have the right recorded announcements or tones presented to the caller without having to answer the call.
Comments:By: twisted (twisted) 2004-04-02 23:31:41.000-0600

This should be listed as a [Request].  Modified to fit bug-reporting ettiqute. ;)
By: revk (revk) 2004-04-03 04:05:33.000-0600

Sorry. However the instructions say that a Severity of "feature" is "feature - requesting new feature". I'll put "[Request]" next time as well.
By: revk (revk) 2004-04-06 11:44:44

OK, I see there is an option to set the variable $PRI_CAUSE before calling hangup. This is obviously something of a bodge but appears to work, so the immediate request is handled and I suppose we could close this report.

This does mean that ISDN2 cards will end up with a different mechanism, so a "tidy" way to do this would be nice. Also there appear to be several different places where "cause codes" are relevant and have different numbering - e.g. the $HANGUPCAUSE uses 0-4 and not a Q.931 cause code!!!

Any chances of some consistency in all interfaces using the same set of numbers (e.g. Q.931 cause codes). Then an argument to "hangup" would be simpler to implement...

I'll go and play with PRI_CAUSE and HANGUPCAUSE now. Thanks guys.
By: revk (revk) 2004-04-06 12:31:17

Further tests with PRI_CAUSE suggests there may be an issue even with that solution. It appears that an incoming call will send ALERTING regardless. If the cause is unallocated number, etc, alerting should not really be sent. I suggest that the ZAP interface holds off sending alerting until a "Ringing" aplication is used (or "r" option in dial, etc) or the max time allowed before sending alerting is reached and it has no choice. Otherwise callers geting ringing then an unobtainable tone, or ringing and then busy, which will cause confusion. Also, it seems, many of the helpful messages one gets with various cause codes are not played if alerting is sent first. I will dig out a copy of Q.931 and check if you like, but I suspect changes are in order.
By: Mark Spencer (markster) 2004-05-21 22:59:47

We don't actually send alerting always now as it turns out.  this just got fixed fairly recently.
By: Paul Cadach (pcadach) 2004-05-22 13:46:49

Alerting message must be sent out from remote party and "bridged" to caller.
By: Mark Spencer (markster) 2004-05-30 19:32:18

I'm lost...