app_dial: Fix dial status regression.

ASTERISK_28638 caused a regression by incorrectly aborting
early and overwriting the status on certain calls.
This was exhibited by certain technologies such as DAHDI,
where DAHDI returns NULL for the request if a line is busy.
This caused the BUSY condition to be incorrectly treated
as CHANUNAVAIL because the DIALSTATUS was getting incorrectly
overwritten and call handling was aborted early.

This is fixed by instead checking if any valid peers have been
specified, as opposed to checking the list size of successful
requests. This is because the latter could be empty but this
does not indicate any kind of problem. This restores the
previous working behavior.

ASTERISK-29989 #close

Change-Id: I4d4b209b967816b1bc791534593ababa2b99bb88

Author: InterLinked1

apps/app_dial.c

@@ -2703,7 +2703,8 @@ static int dial_exec_full(struct ast_channel *chan, const char *data, struct ast
 
 		if (!tc) {
 			/* If we can't, just go on to the next call */
-			ast_log(LOG_WARNING, "Unable to create channel of type '%s' (cause %d - %s)\n",
+			/* Failure doesn't necessarily mean user error. DAHDI channels could be busy. */
+			ast_log(LOG_NOTICE, "Unable to create channel of type '%s' (cause %d - %s)\n",
 				tmp->tech, cause, ast_cause2str(cause));
 			handle_cause(cause, &num);
 			if (!rest) {
@@ -2841,7 +2842,9 @@ static int dial_exec_full(struct ast_channel *chan, const char *data, struct ast
 		AST_LIST_INSERT_TAIL(&out_chans, tmp, node);
 	}
 
-	if (AST_LIST_EMPTY(&out_chans)) {
+	/* As long as we attempted to dial valid peers, don't throw a warning. */
+	/* If a DAHDI peer is busy, out_chans will be empty so checking list size is misleading. */
+	if (!num_dialed) {
 		ast_verb(3, "No devices or endpoints to dial (technology/resource)\n");
 		if (continue_exec) {
 			/* There is no point in having RetryDial try again */