[Home]

Summary:ASTERISK-11744: Asterisk gives up on registration after receiving 408 Timeout response once
Reporter:voipdealer (voipdealer)Labels:
Date Opened:2008-03-28 09:11:18Date Closed:2008-05-08 19:10:58
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Registration
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:I have noticed the following behavior:
- Asterisk registers fine to SIP provider for days
- SIP provider sends one 408 response due to some temporary issue on their network
- Asterisk never attempts to register again, until it is restarted, resulting in loss of inbound service

Ideally, a 408 should never happen.  However, there are hundreds of possible reasons a provider may send a 408 for a few seconds (systems are failing over to backups, database is unavailable due to backup, whatever).  Asterisk should just reschedule registration as it does with all other 4xx errors.

****** ADDITIONAL INFORMATION ******

I believe this issue is due to the following lines in chan_sip.c:
14963   case 408: /* Request timeout */
14964     if (global_regattempts_max)
14965       p->registry->regattempts = global_regattempts_max+1;
14966     p->needdestroy = 1;
14967     r->call = NULL;
14968     AST_SCHED_DEL(sched, r->timeout);
14969     break;

This is the only place in chan_sip where the "give up" code (p->registry->regattempts = global_regattempts_max+1;) exists.  Removing lines 14964-14965 would stop Asterisk from giving up forever and resolve this issue.
Comments:By: voipdealer (voipdealer) 2008-04-01 09:15:33

Any chance of this bug fix making it in?  To clarify, this is not due to a client-side Asterisk configuration error that might cause other 4xx errors (like a wrong username/password).  This is due to a momentary glitch on the remote side, which causes them to properly send a 408 Timeout, so the client doesn't wait forever.  However, that doesn't mean the client shouldn't try again shortly.  

I suspect this is not a more visible issue because most ITSPs are letting Asterisk users connect to Asterisk servers, which, to my knowledge, never send a 408 regardless of how long the database lookup takes.  However, to interop with other SIP gateways, Asterisk should be able to gracefully process a timeout and just try again.

By: Joshua C. Colp (jcolp) 2008-04-01 10:38:08

oej: I've assigned this to you since you've got the experience. If you tell me what should be done I can take care of it.

By: voipdealer (voipdealer) 2008-04-07 14:11:16

Any word on this issue?  I don't believe the quick fix is a breaking change, RFC non-compliant, or technically incorrect.  I understand a more robust retry mechanism may be desired, but there's no compelling reason to hold off on this fix until that happens.

By: voipdealer (voipdealer) 2008-04-14 12:11:24

Any updates? file? oej?

By: Digium Subversion (svnbot) 2008-05-08 11:05:50

Repository: asterisk
Revision: 115561

U   branches/1.4/channels/chan_sip.c

------------------------------------------------------------------------
r115561 | russell | 2008-05-08 11:05:47 -0500 (Thu, 08 May 2008) | 3 lines

Don't give up on attempting an outbound registration if we receive a 408 Timeout.
(closes issue ASTERISK-11744)

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

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

By: Digium Subversion (svnbot) 2008-05-08 11:08:26

Repository: asterisk
Revision: 115562

_U  trunk/
U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r115562 | russell | 2008-05-08 11:08:20 -0500 (Thu, 08 May 2008) | 11 lines

Merged revisions 115561 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r115561 | russell | 2008-05-08 11:11:33 -0500 (Thu, 08 May 2008) | 3 lines

Don't give up on attempting an outbound registration if we receive a 408 Timeout.
(closes issue ASTERISK-11744)

........

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

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

By: Digium Subversion (svnbot) 2008-05-08 11:09:09

Repository: asterisk
Revision: 115563

_U  branches/1.6.0/
U   branches/1.6.0/channels/chan_sip.c

------------------------------------------------------------------------
r115563 | russell | 2008-05-08 11:09:07 -0500 (Thu, 08 May 2008) | 19 lines

Merged revisions 115562 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
r115562 | russell | 2008-05-08 11:14:08 -0500 (Thu, 08 May 2008) | 11 lines

Merged revisions 115561 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r115561 | russell | 2008-05-08 11:11:33 -0500 (Thu, 08 May 2008) | 3 lines

Don't give up on attempting an outbound registration if we receive a 408 Timeout.
(closes issue ASTERISK-11744)

........

................

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

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

By: Digium Subversion (svnbot) 2008-05-08 19:10:58

Repository: asterisk
Revision: 115574

_U  team/seanbright/res-jabber-astobj2/
U   team/seanbright/res-jabber-astobj2/channels/chan_h323.c
U   team/seanbright/res-jabber-astobj2/channels/chan_iax2.c
U   team/seanbright/res-jabber-astobj2/channels/chan_sip.c
U   team/seanbright/res-jabber-astobj2/channels/chan_zap.c
U   team/seanbright/res-jabber-astobj2/contrib/init.d/rc.debian.asterisk
U   team/seanbright/res-jabber-astobj2/contrib/scripts/asterisk.ldap-schema
U   team/seanbright/res-jabber-astobj2/contrib/scripts/asterisk.ldif
D   team/seanbright/res-jabber-astobj2/contrib/scripts/postgres_cdr.sql
_U  team/seanbright/res-jabber-astobj2/include/asterisk/dlinkedlists.h
U   team/seanbright/res-jabber-astobj2/main/pbx.c
U   team/seanbright/res-jabber-astobj2/main/sched.c
U   team/seanbright/res-jabber-astobj2/res/res_config_ldap.c
U   team/seanbright/res-jabber-astobj2/res/res_odbc.c
U   team/seanbright/res-jabber-astobj2/sounds/Makefile

------------------------------------------------------------------------
r115574 | seanbright | 2008-05-08 19:10:45 -0500 (Thu, 08 May 2008) | 243 lines

Merged revisions 115507,115509,115513,115515,115518-115519,115521,115523,115525,115535,115537,115546,115548,115552,115555,115558,115562,115566,115569 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

................
r115507 | file | 2008-05-07 09:41:25 -0400 (Wed, 07 May 2008) | 4 lines

Remove redundant header getting.
(closes issue ASTERISK-11984)
Reported by: hooi

................
r115509 | tilghman | 2008-05-07 09:49:15 -0400 (Wed, 07 May 2008) | 6 lines

Update typos in description fields
(closes issue ASTERISK-11985)
Reported by: suretec
Patches:
      asterisk_schema_changes.patch uploaded by suretec (license 70)

................
r115513 | russell | 2008-05-07 13:28:19 -0400 (Wed, 07 May 2008) | 19 lines

Merged revisions 115512 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

................
r115512 | russell | 2008-05-07 11:24:09 -0500 (Wed, 07 May 2008) | 11 lines

Merged revisions 115511 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2

........
r115511 | russell | 2008-05-07 11:22:49 -0500 (Wed, 07 May 2008) | 3 lines

Remove remnants of dlinkedlists.  I didn't actually use them in the final version
of my IAX2 improvements.

........

................

................
r115515 | russell | 2008-05-07 13:38:36 -0400 (Wed, 07 May 2008) | 2 lines

re-add dlinkedlists.h to trunk, oops!

................
r115518 | russell | 2008-05-07 14:17:43 -0400 (Wed, 07 May 2008) | 12 lines

Blocked revisions 115517 via svnmerge

........
r115517 | russell | 2008-05-07 13:17:19 -0500 (Wed, 07 May 2008) | 5 lines

Track peer references when stored in the sip_pvt struct as the peer related to
a qualify ping or a subscription.  This fixes some realtime related crashes.
(closes issue ASTERISK-11976)
(closes issue ASTERISK-11945)

........

................
r115519 | russell | 2008-05-07 14:24:51 -0400 (Wed, 07 May 2008) | 2 lines

Let chan_h323 build in dev mode

................
r115521 | russell | 2008-05-07 14:30:12 -0400 (Wed, 07 May 2008) | 7 lines

Use the default that the log output claims will be used for the basedn

(closes issue ASTERISK-11986)
Reported by: suretec
Patches:
     12599.patch uploaded by juggie (license 24)

................
r115523 | russell | 2008-05-07 14:33:50 -0400 (Wed, 07 May 2008) | 6 lines

Only save a password if a username exists.

(closes issue ASTERISK-11987)
Reported By: suretec
Patch by me

................
r115525 | tilghman | 2008-05-07 14:40:21 -0400 (Wed, 07 May 2008) | 2 lines

Don't free the object on destroy, as astobj2 takes care of that for you

................
r115535 | tilghman | 2008-05-07 16:22:09 -0400 (Wed, 07 May 2008) | 2 lines

Advance to next sounds release

................
r115537 | russell | 2008-05-07 17:11:33 -0400 (Wed, 07 May 2008) | 10 lines

Fix up a problem that was introduced into the scheduler when it was converted
to use doubly linked lists.  The schedule() function had an optimization that
had it try to guess which direction would be better for the traversal to insert
the task into the scheduler queue.  However, if the code chose the path where
it traversed the queue in reverse, and the result was that the task should be
at the head of the queue, then the code would actually put it at the tail,
instead.

(Problem found by bbryant, debugged and fixed by bbryant and me)

................
r115546 | russell | 2008-05-08 10:41:12 -0400 (Thu, 08 May 2008) | 12 lines

Merged revisions 115545 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r115545 | russell | 2008-05-08 09:40:53 -0500 (Thu, 08 May 2008) | 4 lines

Use the same method for executing Asterisk as the rest of the script.
(closes issue ASTERISK-11997)
Reported by: b_plessis

........

................
r115548 | mattf | 2008-05-08 11:04:45 -0400 (Thu, 08 May 2008) | 1 line

Remove unused code as well as demote an error message to a debug message
................
r115552 | russell | 2008-05-08 11:26:49 -0400 (Thu, 08 May 2008) | 12 lines

Merged revisions 115551 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r115551 | russell | 2008-05-08 10:24:54 -0500 (Thu, 08 May 2008) | 4 lines

Don't use a channel before checking for channel allocation failure.
(closes issue ASTERISK-11995)
Reported by: edantie

........

................
r115555 | russell | 2008-05-08 11:32:48 -0400 (Thu, 08 May 2008) | 11 lines

Merged revisions 115554 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r115554 | russell | 2008-05-08 10:32:08 -0500 (Thu, 08 May 2008) | 3 lines

Don't exit the script if Asterisk is not running.
(closes issue ASTERISK-11997)

........

................
r115558 | russell | 2008-05-08 11:38:27 -0400 (Thu, 08 May 2008) | 11 lines

Merged revisions 115557 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r115557 | russell | 2008-05-08 10:37:49 -0500 (Thu, 08 May 2008) | 3 lines

remove postgres_cdr.sql, as the CDR schema is in realtime_pgsql.sql, as well
(closes issue ASTERISK-9393)

........

................
r115562 | russell | 2008-05-08 12:14:08 -0400 (Thu, 08 May 2008) | 11 lines

Merged revisions 115561 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r115561 | russell | 2008-05-08 11:11:33 -0500 (Thu, 08 May 2008) | 3 lines

Don't give up on attempting an outbound registration if we receive a 408 Timeout.
(closes issue ASTERISK-11744)

........

................
r115566 | russell | 2008-05-08 15:17:04 -0400 (Thu, 08 May 2008) | 41 lines

Merged revisions 115565 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

................
r115565 | russell | 2008-05-08 14:15:25 -0500 (Thu, 08 May 2008) | 33 lines

Merged revisions 115564 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2

........
r115564 | russell | 2008-05-08 14:14:04 -0500 (Thu, 08 May 2008) | 25 lines

Fix a race condition that bbryant just found while doing some IAX2 testing.
He was running Asterisk trunk running IAX2 calls through a few Asterisk boxes,
however, the audio was extremely choppy.  We looked at a packet trace and saw
a storm of INVAL and VNAK frames being sent from one box to another.

It turned out that what had happened was that one box tried to send a CONTROL
frame before the 3 way handshake had completed.  So, that frame did not include
the destination call number, because it didn't have it yet.  Part of our recent
work for security issues included an additional check to ensure that frames that
are supposed to include the destination call number have the correct one.  This
caused the frame to be rejected with an INVAL.  The frame would get retransmitted
for forever, rejected every time ...

This race condition exists in all versions that got the security changes,
in theory.  However, it is really only likely that this would cause a problem in
Asterisk trunk.  There was a control frame being sent (SRCUPDATE) at the _very_
beginning of the call, which does not exist in 1.2 or 1.4.  However, I am fixing
all versions that could potentially be affected by the introduced race condition.

These changes are what bbryant and I came up with to fix the issue.  Instead of
simply dropping control frames that get sent before the handshake is complete,
the code attempts to wait a little while, since in most cases, the handshake
will complete very quickly.  If it doesn't complete after yielding for a little
while, then the frame gets dropped.

........

................

................
r115569 | russell | 2008-05-08 15:20:35 -0400 (Thu, 08 May 2008) | 10 lines

Merged revisions 115568 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r115568 | russell | 2008-05-08 14:19:50 -0500 (Thu, 08 May 2008) | 2 lines

Remove debug output.

........

................

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

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