[Home]

Summary:ASTERISK-02483: Missing Curly braces appear to cause sip_reg_timeout problem (numerous SIP channels left open)
Reporter:blaine christian (blaine christian)Labels:
Date Opened:2004-09-27 13:26:42Date Closed:2008-01-15 15:08:20.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Not sure you care...  BUT, I wanted to share my lazy programmers way of dealing with an apparent problem with iconnect registration timeouts.  rtptimeout did not appear to fix this issue so I had to hack away.
I added the curly braces.... here within the transmit_register function

--------snip--------

       if (r->call) {
               if (!auth) {
                       ast_log(LOG_WARNING, "Already have a call??\n");
                       return 0;
               } else >>>>>>{
                       p = r->call;
>>>>                        }

---------end snip-----

And added a sip_destroy(p) within the sip_reg_timeout function HERE

-------------snip-----------

if (r->call) {
               /* Unlink us, destroy old call.  Locking is not relevent here because all this happens
                  in the single SIP manager thread. */
               p = r->call;
               p->registry = NULL;
               r->call = NULL;
               p->needdestroy = 1;
       >>>>>>>>sip_destroy(p);
       ast_log(LOG_NOTICE, "CALL ID FOR FAILED REG '%s'\n",p->callid);
       }
------------end snip-----------

I thought the else statement did not require the curly braces (being a single line and all) but I am mainly a perl progammer and my C is highly rusty.  I threw the curly braces in because the sip_reg_timeout application seemed to "not" have the appropriate call information.  I put the sip_destroy function within the sip_reg_timeout function since I was unsure of exactly when you intended to go through and do clean up based on the needdestroy variable and wanted to nail the little bastige down.

I would love to hear any feedback... as I said.  I do not write C for a living so feel free to point out how addled I was! <grin>
Comments:By: blaine christian (blaine christian) 2004-09-27 16:23:26

errrm,  this should be a minor not a feature...  my bad...
By: Mark Spencer (markster) 2004-09-27 18:27:07

Can you describe better what the problem is, what you do to cause it to occur, and what the side effects of its happening are?
By: blaine christian (blaine christian) 2004-09-27 18:51:30

Somehow iconnecthere began having occasional register timeouts.  This was all well and good and chan_sip.c handled reregistrations properly. However, the timeouts would leave a stale sip channel behind (sucking up UDP ports and leaving them open).  After a sip debug I could see that I would get a 100 trying message from iconnec but iconnect would not send any further messages.  I had to wait for the iconnect proxy server to fail to send me a response after the 100 trying message to reproduce the bug.  Every night I would get about 70 or so timeouts.  I am still getting the timeouts but now the stale channels are gone.  I am thinking there may still be a bug but since I get the trying message and nothing further I am blaming it on iconnect for now.

I put a log notice message within the sip_reg_timeout routine to determine what was going on with the sip channel and found that the p variable (within the sip_reg_timeout routine) was not even allocated when I reach that point (so it would be impossible to delete the channel).  I had to find out where r->call information was generated and sort of just walked my way through it with log messages.
By: blaine christian (blaine christian) 2004-09-27 20:13:53

Oh, I cvsup frequently so I am running something from the past couple weeks (I started upgrading when I noticed the stale sip channels).
By: Mark Spencer (markster) 2004-09-28 08:52:50

Ah, now the truth comes out.  I knew there had to be something strange about your setup and the 100 Trying coming back is definitely it.

Okay try latest CVS, see if that fixes it for you.
By: blaine christian (blaine christian) 2004-09-28 09:43:04

I will keep an eye on it (I just updated and reloaded).  The last failed registration happened at 0400 this morning so perhaps whatever was happening with iconnect has either slowed down or stopped as well (very frustrating for troubleshooting).

I saw you added a pretend ack to reg_timeout?  I am just curious what the problem was, or what you believe it might have been.
By: blaine christian (blaine christian) 2004-09-28 14:58:09

Just had about 25 timeouts in a row with no stale sip channels.  Whatever you did appears to have worked.  I am still curious what you did! But thank you, I am sure your solution will last longer than mine <grin>.
By: Mark Spencer (markster) 2004-09-28 16:40:23

Yay!
By: Digium Subversion (svnbot) 2008-01-15 15:08:20.000-0600

Repository: asterisk
Revision: 3848

U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r3848 | markster | 2008-01-15 15:08:20 -0600 (Tue, 15 Jan 2008) | 2 lines

On register timeout, pretend to ack any messages so that if they were 100 Trying and nothing else (e.g. certain iconnecthere failures), we still clean up. (bug ASTERISK-2483)

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

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