[asterisk-bugs] [Asterisk 0014684]: Hangup cause 20 (subscriber absent), clearly an end user condition, is being used for unregistered trunks

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=14684 
====================================================================== 
Reported By:                davidw
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   14684
Category:                   Channels/chan_sip/Interoperability
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
Asterisk Version:           1.6.0.1 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-03-17 07:50 CDT
Last Modified:              2009-03-17 10:30 CDT
====================================================================== 
Summary:                    Hangup cause 20 (subscriber absent), clearly an end
user condition, is being used for unregistered trunks
Description: 
In a similar context to http://bugs.digium.com/view.php?id=14683, calls to
trunks which are unavailable due
to a qualify failure are being given hangup cause 20 (subscriber absent). 
This is clearly intended to cover mobile subscribers currently off the
network, and unregistered SIP phones, which are not conditions that will
succumb to immediate retries over a different route.

3 (no route to destination) or 38 (network out of order) would seem more
appropriate for a trunk, although I think that would also require some
mechanism to distinguish trunks from leaf connnections.
====================================================================== 

---------------------------------------------------------------------- 
 (0101874) davidw (reporter) - 2009-03-17 10:30
 http://bugs.digium.com/view.php?id=14684#c101874 
---------------------------------------------------------------------- 
If I use it before Dial, the qualify may fail between the SIPPEER and the
Dial, and I would probably be told that I must failover the call in that
case, so I would have to repeat the SIPPEER to distinguish the two cases. 
(Actually, if one is working round this in the dialplan, one doesn't need
to use SIPPEER, as nothing downstream can generate this on a SIP trunk and
one knows whether one has a trunk or a subscriber.)

I would suggest, if you can't distinguish the causes, it is more useful to
report a network problem (which may result in an upstream switch trying an
alternative route) rather than a subscriber problem, which should cause a
failed call.

On the feature request issue, I consider it to be very borderline, for the
reasons already given; I wouldn't have raised it here if I felt it was a
clear feature request.  However, as AST_CAUSE_UNREGISTERED cannot be
created as the result of an incoming SIP status, and we know we are dealing
with a trunk, I know it could only be the result of a problem with that
trunk, so whilst I think it is a violation of the standard, treating it as
really meaning trunk down won't cause a problem for our application, even
if the split is made in the future. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-03-17 10:30 davidw         Note Added: 0101874                          
======================================================================