Summary:	ASTERISK-13762: Hangup cause 20 (subscriber absent), clearly an end user condition, is being used for unregistered trunks
Reporter:	David Woolley (davidw)	Labels:
Date Opened:	2009-03-17 07:50:47	Date Closed:	2011-06-07 14:07:55
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/Interoperability
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	In a similar context to ASTERISK-1452683, 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. ****** ADDITIONAL INFORMATION ****** The general problems with reporting end user conditions for trunks is that one has to treat genuine end user conditions as network problems and try a failover, wasting bandwidth, and risking hitting a real network problem, and therefore giving a false report to the end user. There is no obvious change in the source code in 1.6.0.6.
Comments:	By: Leif Madsen (lmadsen) 2009-03-17 09:02:37 my personal feeling here is that while this is not ideal behaviour, this is technically a feature request By: Olle Johansson (oej) 2009-03-17 09:05:46 You can check in the dialplan with the SIPPEER() function and by using hangup with an argument send any cause code you like - instead of sending a dial() to test the call. By: David Woolley (davidw) 2009-03-17 09:18:31 I wondered if it could be considered a feature request, but felt that the feature is compliance with the Q.805 cause codes, and that that feature already exists, but it is generating incorrect codes. SIPPEER would have to be used after Dial, as I doubt our marketing people would be happy with a race condition where SIPPEER shows OK but the dial fails without a failover being attempted. By: Olle Johansson (oej) 2009-03-17 09:40:26 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. By: David Woolley (davidw) 2009-03-17 10:30:02 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. By: Tilghman Lesher (tilghman) 2009-07-16 11:58:46 I agree with oej.  At this time, there is no change that we can make, because there is insufficient distinguishment between the two types.  Given future development, this might be possible, though, so I'm suspending this issue.