[asterisk-dev] Dahdi file descriptors and meetme

[Tony Mountifield]

In article <77842CDC-E00D-4752-A15C-8BC8D8AB5F81 at edvina.net>,
Olle E. Johansson <oej at edvina.net> wrote:
> It seems that we have an issue with Asterisk 1.4 and meetme using DAHDI pseudochannels and timers.
> 
> With one participant in a single meetme, I see 5 file descriptors using lsof. With two
> partipants in the same meetme, I see ten channels. After meetme exits, I can some time see
> 30 file handles that disappear quickly.
> 
> Dahdi has a maximum of 1024 "channels" so we're hitting the limit after 200 meetme's, which is bad. 
> 
> I don't know the dahdi interface code, but have problems understanding why we need this
> amount of open file handles. Anyone that understands what's going on?

Is this using SIP channels or hardware TDM channels? My guess would be SIP.
If you can do the same test with hardware TDM channels, that would be a
useful data point.

I assume you are measuring this on a test setup with a simple dialplan. Try
putting a Wait(30) or something before calling Meetme, so that you have time
to see which FDs are purely to do with the SIP channel and which ones then
appear at the time you join the conference.

When a SIP channel joins a Meetme conference, Meetme needs to create a
pseudo channel to participate in the DAHDI mixing engine as a proxy for
the SIP channel. The conf_run loop then passes frames in both directions
between the SIP channel and the pseudo channel.

When the conference is created due to the first member joining, a pseudo
channel is created for playing announcements to the conference.

Also, when Meetme plays an announcement to the user, or puts them in MoH,
an FD will be opened for the audio stream, but this should only be for
the duration of the announcement.

It's an interesting question...

Cheers
Tony
-- 
Tony Mountifield
Work: tony at softins.co.uk - http://www.softins.co.uk
Play: tony at mountifield.org - http://tony.mountifield.org