[Home]

Summary:ASTERISK-04868: [patch] SIP INVITE with bad auth data results in dialplan hang
Reporter:John Todd (jtodd)Labels:
Date Opened:2005-08-21 13:38:59Date Closed:2008-01-15 15:45:23.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Interoperability
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) invitefail.txt
Description:When sending an INVITE which is refused due to authentication errors (bad password, no password, etc.) then it is the case that Asterisk (CVS-HEAD 2005-08-20) dialplans stop processing, despite the fact that the authentication error has been recognized in the logfile.  There needs to be a HANGUPCAUSE and/or DIALSTATUS set which indicates the authentication failure, and the dialplan needs to continue processing.  

As it stands now, the dialplan halts until the originating leg hangs up, which causes enormous grief for auto-failthrough SIP proxy chains (if A doesn't answer, go to B, if B doesn't answer... etc. - this model fails when certain failures modes of A or B cause the dialplan to stall.)

Here is an example, testing against a remote server for which I am unauthenticated for the call.  Note that even though this is a "forwarded" call, this happens with all types of calls (directly referred to remote SIP proxy or indirectly.)

[blah blah blah]
   -- Now forwarding SIP/2203-0040 to 'SIP/6175311000@mit.edu' (thanks to SIP/forward.testdomain.com-8952)
Aug 21 18:23:57 NOTICE[16105]: chan_sip.c:8707 handle_response: Failed to authenticate on INVITE to '"2203" <sip:2203@204.91.156.10>;tag=as44b90cb1'
[here Asterisk stops dead, and I wait... and wait... a full minute.  Nothing.  I hang up...]
 == Spawn extension (intern-post, 0126175311000*254, 1) exited non-zero on 'SIP/2203-0040'
ms1*CLI>


And a "tethereal host 18.7.21.118" on the same transaction (this is MIT's SIP proxy):

20.617416 204.91.156.10 -> 18.7.21.118  SIP/SDP Request: INVITE sip:6175311000@mit.edu, with session description
20.748999  18.7.21.118 -> 204.91.156.10 SIP Status: 100 Trying
20.764325  18.7.21.118 -> 204.91.156.10 SIP Status: 407 Proxy Authentication Required
20.764957 204.91.156.10 -> 18.7.21.118  SIP Request: ACK sip:6175311000@mit.edu
20.765470 204.91.156.10 -> 18.7.21.118  SIP/SDP Request: INVITE sip:6175311000@mit.edu, with session description
20.901295  18.7.21.118 -> 204.91.156.10 SIP Status: 100 Trying
20.917666  18.7.21.118 -> 204.91.156.10 SIP Status: 407 Proxy Authentication Required
20.918303 204.91.156.10 -> 18.7.21.118  SIP Request: ACK sip:6175311000@mit.edu
20.918774 204.91.156.10 -> 18.7.21.118  SIP/SDP Request: INVITE sip:6175311000@mit.edu, with session description
21.036619  18.7.21.118 -> 204.91.156.10 SIP Status: 100 Trying
21.053768  18.7.21.118 -> 204.91.156.10 SIP Status: 407 Proxy Authentication Required
21.054409 204.91.156.10 -> 18.7.21.118  SIP Request: ACK sip:6175311000@mit.edu

Comments:By: Olle Johansson (oej) 2005-08-22 00:54:30

If you add a qualify= to this SIP device in sip.conf, we will time out and return to the dial plan.

I think we should try to copy the outbound registration logic - try a number of times, then fail. Since the cause codes are based on ISDN cause codes, I don't think there's an auth error cause code. We could possibly forward the SIP error somehow to the dial plan.

The HTTP auth is kind of strange, it doesn't really tell us that "ok, that's enough. Three tries and you're out". We could keep trying forever.
By: John Todd (jtodd) 2005-08-22 13:58:57

I didn't know about the qualify= trick, but I suspect it will not work in this example case, for two reasons:
 1) The SIP peer is not in SIP.conf - it is only listed in the dialplan ("Dial(SIP/foo@bar.com)")
 2) The SIP peer is merely a redirector which provides "302 Redirect" answers.  Asterisk then takes the contents of the "302 Redirect" and tries to that host.  Some mis-configured remote hosts (or due to mis-configured destination addresses) will reply with an "authentication"-style response.

Regardless of the particlars of this example case, I still think it's a fairly major flaw.  Any glitch in authentication causes SIP calls to stop cold without any alternate path or failure method.

I think that after three times we should fail.  It does seem to do that already - the HTTP auth cycle only tries three times, and then stops (according to the network dump I enclosed, at least.)  However, the dialplan does not show this as aborted - it just hangs endlessly.  No more INVITEs are sent as far as I can see.

There is an ISDN cause code for authentication,it seems. Look at decimal value "57 - Bearer capability not authorized":

http://www.quintum.com/support/xplatform/network/Q931_Disconnect_Cause_Code_List.pdf
http://www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/dbook/disdn.htm
By: Olle Johansson (oej) 2005-08-23 04:23:57

Try this patch. Disclaimer on file.

If there is *no* available authentication, we fail immediately. If there is available authentication, we now try three times before we fail. We fail with congestion.

I am no ISDN expert, but just because cause code 57 contain the "authorized" word, I am not sure that the ISDN world would agree with us using that. Maybe no route or something.
By: John Todd (jtodd) 2005-08-23 12:41:14

Tested against CVS-HEAD of yesterday evening and the patch applied clealy.  Seems to work, but not quite with expected behavior.

Calls fail with "Congestion", which is fine with me as long as the dialplan proceeds.  HOWEVER it seems to be failing after only one request, which may bode poorly for normal authentication process:

[blahblahblah]
   -- Now forwarding SIP/2208-7e30 to 'SIP/16175551212@mit.edu' (thanks to SIP/isn.tello.com-0e22)
   -- SIP/mit.edu-5fd4 is circuit-busy
 == Everyone is busy/congested at this time (1:0/1/0)


tethereal on the same query:

11.196517 204.91.156.10 -> 66.28.153.11 SIP/SDP Request: INVITE sip:6175311000*254@isn.tello.com, with session description
11.377753 66.28.153.11 -> 204.91.156.10 SIP Status: 100 Trying
11.529590 66.28.153.11 -> 204.91.156.10 SIP Status: 302 Moved Temporarily
11.530445 204.91.156.10 -> 66.28.153.11 SIP Request: ACK sip:6175311000*254@isn.tello.com
11.726612 204.91.156.10 -> 18.7.21.118  SIP/SDP Request: INVITE sip:6175311000@mit.edu, with session description
11.834156  18.7.21.118 -> 204.91.156.10 SIP Status: 100 Trying
11.851943  18.7.21.118 -> 204.91.156.10 SIP Status: 407 Proxy Authentication Required
11.852614 204.91.156.10 -> 18.7.21.118  SIP Request: ACK sip:6175311000@mit.edu
[end of output]

To test this yourself, try sending a call to:

SIP/6175311000*254@isn.tello.com

This will create a 302 Redirect, which in turn will send you to one of the MIT gateways.  The gateway should then ask for Authentication, and you should be able to test exactly as I've done above.  Not sure why it isn't going through the three cycles...
By: Olle Johansson (oej) 2005-08-24 01:12:47

As stated above, if we get a challenge, but have *no* authentication we fail directly. No reason to even try if we can not come up with a username and secret to try with.

If we get a challenge and have authentication we try that three times before we fail. In current code, we only try once.
By: John Todd (jtodd) 2005-08-24 17:54:16

OK, sorry, didn't parse things correctly in reading your notes.  

This patch works as expected, and resolves the bug.  I've pushed 30 or 40 calls through with different failure cases without finding a problem with the patch.
By: John Todd (jtodd) 2005-08-24 17:54:27

PS: Olle is my hero.
By: Kevin P. Fleming (kpfleming) 2005-08-24 22:18:03

Committed to CVS HEAD, thanks!
By: Digium Subversion (svnbot) 2008-01-15 15:45:23.000-0600

Repository: asterisk
Revision: 6399

U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r6399 | kpfleming | 2008-01-15 15:45:23 -0600 (Tue, 15 Jan 2008) | 2 lines

handle INVITEs that are asking for authentication that we cannot supply more intelligently (issue ASTERISK-4868)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=6399