|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:59||Date Closed:||2008-01-15 15:45:23.000-0600|
|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 'SIPfirstname.lastname@example.org' (thanks to SIP/forward.testdomain.com-8952)
Aug 21 18:23:57 NOTICE: chan_sip.c:8707 handle_response: Failed to authenticate on INVITE to '"2203" <sip:email@example.com>;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'
And a "tethereal host 184.108.40.206" on the same transaction (this is MIT's SIP proxy):
20.617416 220.127.116.11 -> 18.104.22.168 SIP/SDP Request: INVITE sip:firstname.lastname@example.org, with session description
20.748999 22.214.171.124 -> 126.96.36.199 SIP Status: 100 Trying
20.764325 188.8.131.52 -> 184.108.40.206 SIP Status: 407 Proxy Authentication Required
20.764957 220.127.116.11 -> 18.104.22.168 SIP Request: ACK sip:email@example.com
20.765470 22.214.171.124 -> 126.96.36.199 SIP/SDP Request: INVITE sip:firstname.lastname@example.org, with session description
20.901295 188.8.131.52 -> 184.108.40.206 SIP Status: 100 Trying
20.917666 220.127.116.11 -> 18.104.22.168 SIP Status: 407 Proxy Authentication Required
20.918303 22.214.171.124 -> 126.96.36.199 SIP Request: ACK sip:email@example.com
20.918774 188.8.131.52 -> 184.108.40.206 SIP/SDP Request: INVITE sip:firstname.lastname@example.org, with session description
21.036619 220.127.116.11 -> 18.104.22.168 SIP Status: 100 Trying
21.053768 22.214.171.124 -> 126.96.36.199 SIP Status: 407 Proxy Authentication Required
21.054409 188.8.131.52 -> 184.108.40.206 SIP Request: ACK sip:email@example.com
|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(SIPfirstname.lastname@example.org)")
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":
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:
-- Now forwarding SIP/2208-7e30 to 'SIPemail@example.com' (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 220.127.116.11 -> 18.104.22.168 SIP/SDP Request: INVITE sip:firstname.lastname@example.org, with session description
11.377753 22.214.171.124 -> 126.96.36.199 SIP Status: 100 Trying
11.529590 188.8.131.52 -> 184.108.40.206 SIP Status: 302 Moved Temporarily
11.530445 220.127.116.11 -> 18.104.22.168 SIP Request: ACK sip:email@example.com
11.726612 22.214.171.124 -> 126.96.36.199 SIP/SDP Request: INVITE sip:firstname.lastname@example.org, with session description
11.834156 188.8.131.52 -> 184.108.40.206 SIP Status: 100 Trying
11.851943 220.127.116.11 -> 18.104.22.168 SIP Status: 407 Proxy Authentication Required
11.852614 22.214.171.124 -> 126.96.36.199 SIP Request: ACK sip:email@example.com
[end of output]
To test this yourself, try sending a call to:
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
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)