Summary: | ASTERISK-13972: RTP ports dont get closed with SIP over TCP | ||
Reporter: | Kristijan Vrban (vrban) | Labels: | |
Date Opened: | 2009-04-16 20:02:34 | Date Closed: | 2009-04-20 12:11:42 |
Priority: | Minor | Regression? | No |
Status: | Closed/Complete | Components: | Channels/chan_sip/TCP-TLS |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ( 0) hangup_tcp ( 1) hangup_udp | |
Description: | Iam using sipp to stress test chan_sip with a higher load of SIP over TCP calls. And i noticed that the RTP ports dont get closed. netstat shows 1000 open udp ports after 500 finished SIP over TCP calls. And they get only closed after i shutdown asterisk. Tu ensure this is TCP related i have done the same test with SIP over UDP. Then the RTP port get closed after the calls are done. | ||
Comments: | By: Kristijan Vrban (vrban) 2009-04-18 15:32:33 attached a to short log from a SIP over UDP and TCP hangup. As you can see, in TCP the two last lines: [Apr 18 22:29:52] DEBUG[27699]: chan_sip.c:5494 sip_destroy: Destroying SIP dialog 8001C372-C52A-DE11-8A54-00C09F5DAD7B@192.168.116.108 [Apr 18 22:29:52] DEBUG[27699]: rtp_engine.c:269 instance_destructor: Destroyed RTP instance '0x8805a30 are missing in the tcp hangup process By: Kristijan Vrban (vrban) 2009-04-18 21:47:05 it's changeset 114190 that introduced this error murf wrote in the r114190 changelog: "I've tested a number of scenarios like crazy" So for me it seems, that the quality control in chan_sip is mainly focused on SIP over UDP, and not TCP. Otherwise this issue must have been catched while testing this big changeset. So i suggest to include also tcp test routine to the quality control. for example: sipp uac -i 192.168.116.101 -t t1 192.168.116.104 -s 78 -trace_err -d 1s it's a great test tool to make high call volume stress tests for udp, tcp and tls. With this tool i notice this issue altogether. you can make 10000 or 100000 calls in just a few min. and if a changeset overcomes such a hight load of calls, then you can be sure the changeset is ok. By: Leif Madsen (lmadsen) 2009-04-19 12:03:23 I'm marking issue 14777 as related to this one, only because they sound so similar to each other. Some investigation will be required in order to determine if that is really the case. Thanks! By: Kristijan Vrban (vrban) 2009-04-19 20:54:06 SIP over TCP also creates a lot memleaks after r114190. If running asterisk with: valgrind --tool=memcheck --leak-check=full --show-reachable=yes asterisk "-c" a lot of memleaks are shown. By: Digium Subversion (svnbot) 2009-04-20 12:05:17 Repository: asterisk Revision: 189350 U trunk/channels/chan_sip.c ------------------------------------------------------------------------ r189350 | file | 2009-04-20 12:05:16 -0500 (Mon, 20 Apr 2009) | 10 lines Fix a bug with non-UDP connections that caused dialogs to not get freed. This issue crept up because of a reference count issue on non-UDP based dialogs. The dialog reference count was increased when transmitting a packet reliably but never decreased. This caused the dialog structure to hang around despite being unlinked from the dialogs container. (closes issue ASTERISK-13972) Reported by: vrban ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=189350 By: Digium Subversion (svnbot) 2009-04-20 12:06:21 Repository: asterisk Revision: 189351 _U branches/1.6.0/ ------------------------------------------------------------------------ r189351 | file | 2009-04-20 12:06:21 -0500 (Mon, 20 Apr 2009) | 16 lines Blocked revisions 189350 via svnmerge ........ r189350 | file | 2009-04-20 14:05:15 -0300 (Mon, 20 Apr 2009) | 10 lines Fix a bug with non-UDP connections that caused dialogs to not get freed. This issue crept up because of a reference count issue on non-UDP based dialogs. The dialog reference count was increased when transmitting a packet reliably but never decreased. This caused the dialog structure to hang around despite being unlinked from the dialogs container. (closes issue ASTERISK-13972) Reported by: vrban ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=189351 By: Digium Subversion (svnbot) 2009-04-20 12:08:27 Repository: asterisk Revision: 189352 _U branches/1.6.1/ U branches/1.6.1/channels/chan_sip.c ------------------------------------------------------------------------ r189352 | file | 2009-04-20 12:08:27 -0500 (Mon, 20 Apr 2009) | 17 lines Merged revisions 189350 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ........ r189350 | file | 2009-04-20 14:05:15 -0300 (Mon, 20 Apr 2009) | 10 lines Fix a bug with non-UDP connections that caused dialogs to not get freed. This issue crept up because of a reference count issue on non-UDP based dialogs. The dialog reference count was increased when transmitting a packet reliably but never decreased. This caused the dialog structure to hang around despite being unlinked from the dialogs container. (closes issue ASTERISK-13972) Reported by: vrban ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=189352 By: Digium Subversion (svnbot) 2009-04-20 12:11:42 Repository: asterisk Revision: 189353 _U branches/1.6.2/ U branches/1.6.2/channels/chan_sip.c ------------------------------------------------------------------------ r189353 | file | 2009-04-20 12:11:41 -0500 (Mon, 20 Apr 2009) | 17 lines Merged revisions 189350 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ........ r189350 | file | 2009-04-20 14:05:15 -0300 (Mon, 20 Apr 2009) | 10 lines Fix a bug with non-UDP connections that caused dialogs to not get freed. This issue crept up because of a reference count issue on non-UDP based dialogs. The dialog reference count was increased when transmitting a packet reliably but never decreased. This caused the dialog structure to hang around despite being unlinked from the dialogs container. (closes issue ASTERISK-13972) Reported by: vrban ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=189353 |