[Home]

Summary:ASTERISK-03894: RTP port allocation fails
Reporter:Roy Sigurd Karlsbakk (rkarlsba)Labels:
Date Opened:2005-04-08 04:04:20Date Closed:2011-06-07 14:10:44
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) siprtp.txt
( 1) Bilde_3.png
( 2) bug3986_patch.diff
( 3) bug3986_patch2.diff
( 4) bug3986_patch3.patch
( 5) chan_sip_20051011_fromorig.diff
( 6) chan_sip_rtp_allocation_and_sanity.diff
( 7) chan_sip_sanity_rtp_patch.diff
( 8) crash_patch.diff
( 9) mrtg-comparison.jpg
(10) rtp_sanity_patch.diff
(11) rtp-alloc-failure.patch
(12) rtpsocket.patch
(13) rtpweek20051010.png
(14) show_channels_and_sip_show_channels.txt
Description:I keep getting these on our SIP server. This happens regularly after a week or so. rtp.conf specifies RTP ports 10000 through 11990 and this should suffice as the number of concurrent calls are less than one tenth of the 1991 ports available.

Apr  7 14:47:43 WARNING[8637]: No RTP ports remaining
Apr  7 14:47:43 WARNING[8637]: Unable to create RTP session: Address already in use
Apr  7 14:47:43 WARNING[8637]: No RTP ports remaining
Apr  7 14:47:43 WARNING[8637]: No RTP ports remaining
Apr  7 14:47:43 WARNING[8637]: Unable to create RTP session: Address already in use
Apr  7 14:47:43 WARNING[8637]: No RTP ports remaining
Apr  7 14:47:43 WARNING[8637]: No RTP ports remaining
Apr  7 14:47:43 WARNING[8637]: Unable to create RTP session: Address already in use
Comments:By: Roy Sigurd Karlsbakk (rkarlsba) 2005-04-08 04:18:07

Please note that this issue has come up somewhere between 1.0.3 and 1.0.6, although I don't know how to research this any closer since the bug only happenes once a week or so.

roy
By: Brian West (bkw918) 2005-04-08 11:57:32

sip subscribe going on?
By: coredump (coredump) 2005-04-08 14:02:25

Am seeing the same on CVS-HEAD ( Asterisk CVS-HEAD-03/30/05-15:22:55 ).

With 16,000 RTP ports.  ~300 registered subs.  Happening after < 1 hour in service time.
By: Mark Spencer (markster) 2005-04-08 15:07:57

What happens when you do sip show channels and/or sip history on any left over channels?
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-04-09 03:38:04

sip show channels shows a couple of hundered channels with codec unknown and I know these aren't active channels

What do you mean by history on left over channels?

roy
By: Mark Spencer (markster) 2005-04-09 13:32:53

1) Restart Asterisk.

2) Run "sip history"

3) When you have a bunch of left over channels type "sip show history <callid>" and see what the transactions were that left them up.  I assume "show channels" shows nothing similar.
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-04-09 15:06:20

What do you mean by left over channels?
Those with unknown codec?
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-04-10 19:48:44

while the system was idle, or at least no active calls according to "show channels", sip show channels showed 95 active ones with codec "unknown". This is one of them

sipgw1*CLI>
 * SIP Call
 Direction:              Incoming
 Call-ID:                y9yiV0-Vww0X3f2@firstmile.no
 Our Codec Capability:   286
 Non-Codec Capability:   0
 Their Codec Capability:   0
 Joint Codec Capability:   0
 Format                  unknown
 Theoretical Address:    192.168.1.34:5060
 Received Address:       82.214.70.152:11394
 NAT Support:            Always
 Our Tag:                1452048505
 Their Tag:              Pog2-mgYqF
 SIP User agent:         100/000004
 Need Destroy:           0
 Last Message:           Rx: REGISTER
 Promiscuous Redir:      No
 Route:                  N/A
 DTMF Mode:              info
By: Mark Spencer (markster) 2005-04-10 20:45:53

is there anyone else having this problem?
By: Terry Wilson (twilson) 2005-04-11 11:19:06

Do you have qualify set in sip.conf?  I seem to remember that sip show channels would always show a channel for qualify OPTIONS packets.  I don't remember, but possibly registrations as well.  You might also add a ulimt -n 10000 to your safe_asterisk script (if you use it).  I seem to remember getting a "No RTP ports remaining" error when I was running out of available open files.
By: Brian West (bkw918) 2005-04-14 12:38:21

rkarlsba their is no codec on a REGISTER.  What you show is normal.

/b
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-04-14 14:48:41

the fact that we run out of rtp ports should be less than normal imho.
By: Mark Spencer (markster) 2005-04-15 01:05:26

Again, is there any one else that has this issue?
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-04-15 02:22:53

coredump says so..
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-04-18 03:37:16

This no longer seems to happen with the same traffic load, after turning off qualify.

roy
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-04-29 08:24:22

The just happened again. I had to just restart asterisk to get it up again. Can someone please take a look at this?
By: Olle Johansson (oej) 2005-04-29 10:11:36

Hmmm. I see RTP ports opening at outbound registration in chan_sip with a jitterbuffer patch. Will try to trace it.
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-04-29 10:19:03

FYI: I only use inbound SIP registrations
By: Kevin P. Fleming (kpfleming) 2005-04-29 10:49:21

This issue is still present in 1.0.7 and/or CVS-1-0? If so, let's update the bug header to reflect that, please.
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-04-29 15:25:53

This is 1.0.6
Has there been any relevant patches since 1.0.6 that could touch this bug?
By: Michael Jerris (mikej) 2005-04-29 15:34:43

That was a request to test with 1.0.7 and verify if it is also the case in head still if possible.
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-04-30 18:32:55

The server in question is in production, so upgrading and restarting the system is somethig that can't be done in a hurry.
Are there any new fixes that should be relevant in fixing this bug in 1.0.7?
By: Brian West (bkw918) 2005-05-01 09:38:36

I am not seeing this on CVS-HEAD.. I even did 628 calls with media(ulaw) on a 3ghz P4 with ht... and 5551 with signalling only on the same machine.   So it sounds like a cvs-stable issue.. that might have been fixed already.

/b
By: Olle Johansson (oej) 2005-05-01 13:24:46

Looking into CVS head, we're allocating RTP ports for just about anything... Working on a patch to test for CVS head.
By: Olle Johansson (oej) 2005-05-01 13:58:11

Try this patch for CVS head. It's a first step. I will fix the next step later, it involves another patch for SIP REGISTER with pedantic that I have in the queue. You will see when we allocate RTP in the log messages if you have debug set to at least 1.

Disclaimer on file.
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-05-01 15:25:16

Do you think you can make a patch for stable as well? We cannot use HEAD on this box as it is in production, and some of the features, as mysqlsupfriends, are depreciated in HEAD. We also haven't been able to reproduce the error in the lab.

best regards

roy
By: Olle Johansson (oej) 2005-05-01 15:45:25

Since this patch is for CVS head, I don't know if it fixes the reporters problems, but it sure does remove a lot of un-needed RTP allocations. There must be similar problems in CVS stable and I will look into that if I get positive feedback on this patch.
By: Olle Johansson (oej) 2005-05-01 15:46:02

...since it can't be solved in the same way in cvs stable, due to the lack of sipmethods.
By: Kevin P. Fleming (kpfleming) 2005-05-01 21:08:41

Darn, I committed a slightly different fix before I looked over your patch... take a look and tell me what you think :-)
By: Olle Johansson (oej) 2005-05-02 12:20:32

Small cosmetic change - mostly the debug output which I like...
By: Kevin P. Fleming (kpfleming) 2005-05-02 22:26:49

OK, I've committed that patch to CVS HEAD. I'll leave this one assigned to you to look into doing something similar for CVS STABLE if possible.
By: Olle Johansson (oej) 2005-06-02 10:58:00

Waiting for your fix...
By: Michael Jerris (mikej) 2005-06-02 11:44:25

oej, Am I missing somthing or are you and kevin waiting for each others fix on this?  Do we have a clean fix for 1.0?
By: Olle Johansson (oej) 2005-06-02 13:40:58

Sorry, MikeJ, I just tried moving to "Pending Stable" and sent a reminder to myself. I am waiting for myself on this patch. :-)

Me, Myself and I - we are all developing Asterisk SIP as a team effort...
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-06-14 11:18:59

sorry for stressing this, but is there a patch available that i can test? i just had a rather ugly crash because of this
By: Michael Jerris (mikej) 2005-06-14 11:29:12

All 3 of him are running astricon right now.  Don't expect movement on this this week.
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-06-24 05:34:16

and another crash
is this coming to stable soon?
By: Russell Bryant (russell) 2005-06-24 17:09:14

Can you provide a "sip show history" for one of those channels that stay around, please?
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-06-25 05:59:01

I'll do so next time this happens
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-06-25 08:21:55

btw is this still 'pending stable' or do we need more info?
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-07-01 07:27:08

surveying UDP ports in use with  a simple `netstat -ln --udp|wc` with mrtg shows an extreme increase at even normal traffic. right now, after just a few days uptime, it's already >2k ports 'listening'

roy
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-07-03 15:13:03

is this still in 'pending stable'?
can someone please fix it?
last time my server died it had only been up for a little more than three days, and with 10k rtp ports available
By: Michael Jerris (mikej) 2005-07-03 15:19:19

still waiting on a response from RoyK on drumkilla's question.  Also, does this only occour when qualify is turned on?  From the bug notes it appears not to have happend for some time with qualify turned off, but then you had a crash, it does not indicate if you turned qualify back on.
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-07-04 05:10:41

still waiting on a response from RoyK on drumkilla's question.  Also, does
this only occour when qualify is turned on?  From the bug notes it appears
not to have happend for some time with qualify turned off, but then you had
a crash, it does not indicate if you turned qualify back on.

firstly, this only happens on a production system, meaning possibilities for debugging and other troubleshooting is very limited. secondly, there were no active channels left after last crash, thirdly i don't think this is relevant to qualify, since I'm using mysql sipfriends and that doesn't support qualify at all.

also, doesn't 'pending stable' mean there is a patch available for me to test?

roy
By: Michael Jerris (mikej) 2005-07-04 08:35:54

Pending stable means this is an issue in stable, not that there is a patch for stable.  In bugnote 25963 you said this no longer happens with qualify off, then in the following bugnote you said it happend again.  Did it happen with or without qualify on?
By: Olle Johansson (oej) 2005-07-04 08:50:14

I think this bug report is waiting for me to provide a fix. Since I am back from holiday, I've added this to my to-do list again :-)
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-07-04 18:03:25

see attached patch
it seems there is some bad logic in rtp.c
with linux 2.6 i get the following while surveying udp allocations

sipgw1:~ # lsof -p 10546 | grep -w UDP| cut -c34- | sort -n|tail -1 && sleep 10 && lsof -p 10546 | grep -w UDP| cut -c34- | sort -n|tail -1
199728557                UDP *:13369
199747285                UDP *:11681

...so it seems like growing rapidly, and therefore the attached patch could mend this

thanks to pino for pointing out this

roy


By: Roy Sigurd Karlsbakk (rkarlsba) 2005-07-04 18:39:18

mikej: please read my reports. we're using mysql sipfriends, and that means qualify is off whatever what we set in sip.conf
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-07-04 18:45:37

To explain what pino hinted on:
"if socket fd's are allocated sequencially, merely checking if a socket id is negative might be wrong"

Firstly, checking if a socket is negative to make sure if it's failed, is wrong, according to the specs. socket() only returns -1 on error.

Secondly, linux 2.6 seems to somehow allocate socket identifiers more in sequence than 2.4, and as i've documented here, it's FDs just grows on and on. I've not, however, been able to reproduce that without asterisk. Still I hope this might help me out on this one.

roy
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-07-06 03:27:44

After a a day and 8 hours of run time with that patch, RTP/UDP port allocations seems to have stabilized. compared to before this patch, that was enough time to allocate a few thousand ports.
By: Russell Bryant (russell) 2005-07-07 10:48:34

If this patch helps you, then there are some serious issues going on with your system.  The only way that this would help is if socket() returned a valid value that was less than -1 - which is bogus behavior.
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-07-07 16:55:55

socket() may return an int > 2G, meaning it'll be negative
By: Russell Bryant (russell) 2005-07-07 18:51:34

Can you make the modificaiton like the one I made in the patch I just uploaded?

Then, if anything prints out, please report it here.  From what I understand, the only reason socket() returns a signed integer, is so that it can return -1 on an error.
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-07-08 02:20:31

Can't you just accept my patch here? My patch fixes the asterisk code so it complies with the socket manual (2)

RETURN VALUES
      -1 is returned if an error occurs;  otherwise  the  return
      value is a descriptor referencing the socket.

also, see the output from lsof below to see the socket FDs increase

roy
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-07-08 02:27:43

Please note that this patch does not fix the main allocation problem.

I beleive there are two bugs, one that kicks off if s < -1 and one creepy bastard that just leaks a little now and then

Now, with System uptime: 3 days, 7 hours, 44 minutes, 18 seconds
some 220 udp ports are allocated while system is almost idle. this number is constantly climbing

roy
By: Russell Bryant (russell) 2005-07-08 09:48:51

What OS are you using?
By: Matthew Fredrickson (mattf) 2005-07-08 10:32:35

I just traced the socket code from the C-library into the kernel and it appears that the practice of accepting any negative value (other than -1) would be incorrect and broken behavior.  I don't know why the man page explicitly states -1, but (in linux at least) it can have other negative return values that are NOT valid socket descriptors.  I would say that the current behavior is correct until someone else can disprove it.  If you can demonstrate that you receive valid socket descriptors of a value less than negative one, we can reopen that as a potential fix.  Otherwise, it looks like you're probably accepting various kernel error codes as socket descriptors.
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-07-08 17:45:15

Why not just stick to the docs and check for what they say, instead of obscuring things ?
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-07-11 02:57:35

I'm on linux 2.6.11, official kernel.org release.
By: Matthew Fredrickson (mattf) 2005-07-11 09:30:54

Well, I looked in 2.6.12 (and I doubt that much has changed in that part of the code between 2.6.11).  

If you're up for a test, I'll bet that if you did an analysis on the return socket values, that a lot of them will be similar (i.e. error codes).

My only concern about this code is that it is allowing negative error codes to be taken as socket descriptors.  I do not think that the man page is absolutely correct from looking through the socket library code and (linux) kernel socket code.  It looked like there were return error codes returned by the kernel that could be negative as well.  If you can show me a valid situation in which it returns a valid negative valued socket, I would feel a lot better abou taccepting this code.
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-07-14 03:39:24

The last uploaded file shows part of an MRTG graph with the number of UDP ports allocated steadily climbing.

Please remark that this is not related to the < 0 vs != -1 case discussed below. there is a leak somewhere...

roy
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-08-01 07:42:55

There's something strange happening when about 1000 ports have been allocated - it looks like it goes berserk and climbes like fuck...
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-08-01 09:35:00

I found some lost AGI processes where each of them had some 40-50 UDP ports allocated. Killing the bunch helped clean up some of the lost ports, but only some, so I guess this was just another nonrelated bug :(
By: Olle Johansson (oej) 2005-08-01 10:26:54

I think we more or less agreed that this issue is not easily fixed in the stable chan_sip source code and a new release version that fixes this is arriving soon.

This issue is fixed in 1.2 and there's a patch for killing AGI zombies in the bug tracker as well.
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-08-01 11:01:58

so then all I have to do is wait another six months or so for 1.2 to release and then rewrite my other software around asterisk to interface with the new version, stuff like database interfaces, which are quite a lot and all that? that looks a really nice job.

if asterisk is meant to be stable, can't you please fix this if you know where the error is?

roy
By: Olle Johansson (oej) 2005-08-02 04:15:35

Asterisk 1.2 is not six months away, please read available information!

And if you really want me to fix it now and in the old source, please contact me off line for a consultancy assignment.

/O
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-08-09 03:30:51

If this is fixed in 1.2, can someone please point me out where the fix is? is there a patch I can study?

roy
By: Olle Johansson (oej) 2005-08-25 14:35:38

In 1.2, we've re-written a large part of the code so there's not a simple patch to backport unless you want to re-write a very large part of chan_sip in stable. There is a structure sip_methods that indicate for each method supported whether we should allocate RTP or not for a dialog.
By: Olle Johansson (oej) 2005-08-25 14:36:14

Please re-open this issue report when we have a patch for stable.
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-09-09 02:47:17

since this is clearly a problem with current stable track, perhaps this should be left open? closing it will not really attract anyone trying to fix it

roy
By: Michael Jerris (mikej) 2005-09-09 08:38:44

Set back to pending stable as this is not an issue in head.
By: Olle Johansson (oej) 2005-09-09 08:49:51

Since no one is willing to pay for fixing this or code this freely, since it requires a lot of changes I think we should keep it closed until we have someone that is working on it.
By: timrobinson (timrobinson) 2005-09-10 08:33:12

I also see this issue with 1.0.9 Stable.  When I receive a call from my SIP provider, the RTP session is established, but when the inbound call hangs up I see no SIP BYE message from the SIP media gateway (a Cisco)

The only hint I get that a call is cleared is  an RTP BYE message and then RTP packets stop coming.  Asterisk still thinks the call is up and never times out.

I think Asterisk needs to clear a call if it gets an RTP BYE message...could this explain the issue?  I have full traces of this if anyone is interested in looking at it.
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-09-11 02:38:46

I just uploaded a file showing the output from 'show channels' and 'sip show channels', and just like Tim states, lots of SIP channels seems to be 'hanging'. Perhaps this may be the problem?

roy
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-09-12 04:41:18

FYI: I've setup a new box for another project, also running SIP termination, with slightly more traffic than the one experiencing this problem. The new one is running CVS HEAD, and does not have this problem.

roy
By: Olle Johansson (oej) 2005-09-12 10:15:21

We have stated the fact several times now that CVS head handles this much, much better...
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-09-13 03:56:29

sure, but I somehow start to doubt this is an RTP bug after all
take a look at show_channels_and_sip_show_channels.txt and see for yourself. this might just as well be a regular chan_sip bug.

roy
By: Terry Wilson (twilson) 2005-09-13 09:31:38

If you have qualify on, then you will see a lot of extra sip channels sitting around...  just noticed that you said you were using sipfriends, but if you have rtcachefriends set up qualify could still be on.  (or if there were some static entries left in sip.conf I suppose).  Of course if you are using 1.0 don't think rtcachefriends is an option... so maybe this post doesn't help you a lot.  :-)


By: Roy Sigurd Karlsbakk (rkarlsba) 2005-09-21 04:53:58

$1k bounty for this: http://www.voip-info.org/tiki-index.php?page=Bug+3986+Bounty
By: xrobau (xrobau) 2005-09-21 06:33:24

Possibly it may be a better use of your $1000 to employ a consultant to re-write your legacy applications to work with Asterisk 1.2, rather than beat the dead horse that is 1.0.
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-09-21 06:35:54

right
asterisk 1.2 isn't stable. i've tried some high-load testing and have had several crashes. using it for production is insane
By: cherso (cherso) 2005-09-21 07:29:37

No reason to keep open the RTP media when something goes wrong

This should fix your RTP port problem
cd asterisk*7
cd channels
patch < bug3986_patch.diff
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-09-21 07:49:24

patch installed
the sip show channels still show vast amounts of 'dead' channels (see show_channels_and_sip_show_channels.txt), but that might perhaps be another bug??? or another side of the same bug?
By: cherso (cherso) 2005-09-21 07:52:45

the dead sip channels is another bug or maybe sip device issue.

The patch fix the rtp problem as requested.
Use the netstat stuff and monitor the udp ports, you should not see any pending rtp port.


By: cherso (cherso) 2005-09-21 08:55:52

ok, the crash_patch is for a null p->rtp passed to ast_rtp_pt_clear
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-09-21 08:59:47

bug3986_patch2.diff adds some sanity checks to rtp.c to avoid a crash. it's doing the same as crash_patch, only another place (i think that's better)
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-09-21 09:30:25

bug3986_patch3.patch is like patch2, only it adds sanity checks for all functions where rtp is sent as an argument. simply check if it's null, and if it is, report a warning and return instead of dereferencing it and crash...

this should perhaps be rewritten as a macro....
By: cherso (cherso) 2005-09-21 09:39:24

I'm uploading the chan_sip and rtp sanity checks and the rtp udp port fix
Apply it to a clean 1.0.7 asterisk tarball


By: Roy Sigurd Karlsbakk (rkarlsba) 2005-09-21 09:46:54

chan_sip_sanity_rtp_patch has all the checks in chan_sip.c. is it just me, or is bug3986_patch3.patch doing this better with moving the checks into rtp.c and then reporting WARNINGs if a NULL is sent?

roy
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-09-21 17:35:11

it seems the problem still persists after patching up asterisj with bug3986_patch.diff

behaviour is still the same

MARK: Only a few of these allocated ports are freed with a 'RESTART NOW'. To free them all, i need to stop asterisk totally and then restart it

roy
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-09-21 18:11:15

Please note that the 'sip show channels' does not seem related to this bug ATM. For what I've heard, that comes from sessions being registered at SIP REGISTER and then freed as a batch job in asterisk or something.
By: cherso (cherso) 2005-09-22 03:10:11

chan_sip_rtp_allocation_and_sanity.diff

the RTP allocation is moved out from the sip_alloc. I see no reason to allocate the RTP struct for all channels.
This patch allocate the RTP struct only on real incoming and outgoing calls.

it does apply to the 1.0.7 original chan_sip.c


By: Roy Sigurd Karlsbakk (rkarlsba) 2005-09-23 04:15:21

the system has now been running stably for
sipgw1*CLI> show uptime
System uptime: 20 hours, 13 minutes, 33 seconds
and the rtp leak is magically gone :)

please leave this open until cherso and I have agreed on the bounty, since the code still belongs to him, and that by now, it's up to him to decide what to do with it.

roy
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-09-23 05:14:26

the file mrtg-comparison.jpg shows three graphs put on top of one another. green fill measures IAX2 channels, blue line measures SIP channels and red line shows the output from `netstat -rn --udp | wc -l`. it works :)
By: cherso (cherso) 2005-09-23 08:20:25

the graph looks good after the patch. If the patch is stable after a week I will also write the patch for the newer asterisk versions
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-09-23 08:22:01

you mean asterisk cvs head does this the same way?
By: cherso (cherso) 2005-09-23 08:44:26

well, the RTP allocation is still in the sip_alloc but now there's a method to verify if the RTP struct is needed. I didn't investigate the CVS HEAD code to much, but I'm not sure that the RTP struct will be deallocated if the client start the session with an INVITE


By: Roy Sigurd Karlsbakk (rkarlsba) 2005-09-23 09:52:27

I apologise my ignorance, but does this mean it's fixed or not?
By: cherso (cherso) 2005-09-23 10:15:08

I need time to look into the code, I just saw that the sip_alloc will create the RTP struct only under certain circumstance... a SIP INVITE request for example, but I did not verify if the RTP is destroyed when the INVITE is not followed by a real call. So the reponse is: yes it could burn RTP ports too
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-09-29 05:15:03

system has now been running stably for about a week

System uptime: 6 days, 21 hours, 15 minutes, 42 seconds

i consider this fix good
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-09-29 11:01:53

I dunno if cherso has posted any disclaimers, but if so, perhaps this should go into stable?
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-10-10 04:30:52

it seems there's more
see attached file rtpweek20051010.png

any idea how to debug this?
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-10-13 05:53:44

note that with the last leak, I had to stop asterisk and start it again to release the ports. a 'restart now' only released a small fraction of them, so it looks like there might be two leaks left....
By: cherso (cherso) 2005-10-15 15:17:55

restart now is like a reload, not a real restart
it just run the reload routines, so the open ports are not closed.

You don't need to restart asterisk. You just need to
unload chan_sip.so
load chan_sip.so
By: cherso (cherso) 2005-10-21 06:48:21

I'm uploading chan_sip_20051011_fromorig.diff
The last and complete patch for the original chan_sip.c (1.0.7)
It does include also a patched sip show channels. It does show the allocated RTP port number and the total number of the allocated RTP ports (for debugging)


By: Russell Bryant (russell) 2005-11-15 14:04:58.000-0600

If anyone is still seeing any problems in cvs head or 1.2, please open a new bug.
By: Digium Subversion (svnbot) 2008-01-15 15:32:51.000-0600

Repository: asterisk
Revision: 5548

U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r5548 | kpfleming | 2008-01-15 15:32:51 -0600 (Tue, 15 Jan 2008) | 2 lines

attempt to not allocate RTP ports for SIP private structures unless they are needed (bug ASTERISK-3894)

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

http://svn.digium.com/view/asterisk?view=rev&revision=5548
By: Digium Subversion (svnbot) 2008-01-15 15:33:00.000-0600

Repository: asterisk
Revision: 5557

U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r5557 | kpfleming | 2008-01-15 15:32:59 -0600 (Tue, 15 Jan 2008) | 2 lines

use symbolic constants for RTP method flags, and add debugging output to sip_alloc to indicate when RTP is/is not allocated (bug ASTERISK-3894)

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

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