[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 09:40 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.
====================================================================== 

---------------------------------------------------------------------- 
 (0101870) oej (manager) - 2009-03-17 09:40
 http://bugs.digium.com/view.php?id=14684#c101870 
---------------------------------------------------------------------- 
SIPPEER after DIal doesn't make sense - why can't you use it before you
dial?

Yes, the race condition is always there. At this moment we have no
separation of the two peer types, so we can't set different causes for the
situations you describe here.

It's something we planned for the future. Feature requests can be filed on
http://www.asteriskideas.org, but not in the bug tracker which is for bugs
and new code. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-03-17 09:40 oej            Note Added: 0101870                          
======================================================================