Summary:	ASTERISK-24132: Remote TLS server close connection. Dialstatus = CANCEL
Reporter:	Olle Johansson (oej)	Labels:
Date Opened:	2014-07-29 04:45:13	Date Closed:
Priority:	Minor	Regression?
Status:	Open/New	Components:	Channels/chan_sip/TCP-TLS
Versions:	1.8.29.0 13.18.4	Frequency of Occurrence	Constant
Related Issues:
Environment:	Linux Centos 6, Microsoft Lync	Attachments:
Description:	Call is set up, TLS connection opened. Microsoft Lync requires TLS client cert, Asterisk sends cert (automatically in OpenSSL I guess) and MS Lync doesn't approve. Lync close TCP connection, Asterisk sends SSL finish, then connection closes. TLS read now generates a read error on the socket, the TCP thread shuts down and app_dial can't read a frame during call setup, the call fails with CANCEL as dialstatus. I think it has to be CONGESTION. But can't figure out where to set that status in this chain of events. CANCEL is very wrong.
Comments:	By: Olle Johansson (oej) 2014-07-29 04:48:07.363-0500 This little patch reveals where in app_dial the call is hung up. Index: apps/app_dial.c =================================================================== --- apps/app_dial.c (revision 419680) +++ apps/app_dial.c (working copy) @@ -1494,6 +1494,7 @@ printf("Hangup received on %s\n", in->name); #endif if (!f || ((f->frametype == AST_FRAME_CONTROL) && (f->subclass.integer == AST_CONTROL_HANGUP))) { + ast_debug(8, " ===> Dial got hung up on %s\n", in->name); /* Got hung up */ *to = -1; strcpy(pa->status, "CANCEL"); By: Olle Johansson (oej) 2014-07-29 04:48:52.028-0500 I am pretty sure this affects all versions after 1.8 too. By: Matt Jordan (mjordan) 2014-07-29 07:25:44.241-0500 While "CANCEL" is the wrong status for your scenario, I don't think {{app_dial}} itself is wrong. From its perspective, it went to read a frame from the channel and didn't get one back. That's an indication that the calling channel hung up. The best it can infer from that is that the caller gave up, and so it cancels the dial. If we need to have a different status in this situation, then something should queue a hangup on the destination channel with the appropriate status code. It sounds like that didn't happen here; if it had, I would expect that we would have hung up the calling channel appropriately long before it got to this place. By: Olle Johansson (oej) 2014-07-29 07:32:32.865-0500 Congratulations! You've hit the exact spot where I'm confused. We don't issue a hangup on the sip_read and down in the TLS read we have no idea of a channel to issue a hangup to.  So maybe sip_read could check the state of the invite and say "oops - read error during call setup on tcp or tls propably means we failed setting up the call". If the call is in UP state (or hold) this is not the case, as a new TCP/TLS connection can be set up for that. Now if a connection dies in the middle of an in-dialog transaction, like MESSAGE or re-invite, we're in trouble. The transaction fails, but the call does not. This propably affects pjsip as well btw. /O