[Home]

Summary:ASTERISK-13972: RTP ports dont get closed with SIP over TCP
Reporter:Kristijan Vrban (vrban)Labels:
Date Opened:2009-04-16 20:02:34Date Closed:2009-04-20 12:11:42
Priority:MinorRegression?No
Status:Closed/CompleteComponents: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