[asterisk-dev] Memory failure - channels in meetme

[Olle E. Johansson]

2 nov 2011 kl. 14:57 skrev Kevin P. Fleming:

> On 10/31/2011 09:03 AM, Olle E. Johansson wrote:
>> Apologize for short memory. Kevin explained on #asterisk-dev the number of Dahdi channels involved in a meetme, but I forgot it and also forgot to copy his explanation. Can we please get the latest version for archives and memory refresh?
> 
> I'll try :-)
> 
> When a MeetMe conference is established (the first user joins), there is a DAHDI pseudo channel (not an Asterisk channel... no ast_channel structure here). This channel is used by MeetMe to retrieve the 'common' mixed audio to be sent to all non-talking members of the conference, rather than retrieving it individually for each non-talking member from their own conference channel. This allows for reduced encoding; if there are a number of non-talking conference members using the same codec, this audio can be encoded once and sent to all of them.
> 
> If the first user in the conference is any type of Asterisk channel *other than* DAHDI, then a second DAHDI pseudo channel is opened (again, no ast_channel involved). This is used to feed that user's audio into the conference, and when they are a talker, provide the audio feed that should be sent to them. This same step is performed for any additional users who subsequently join the conference and are not DAHDI native channels.

We currently see 71 meetme's and 818 file handles counted by lsof |grep dahdi|wc -l

You did not mention timer handles, but still if we have one or two participants per meetme, this doesn't make sense. Wonder if I can trust "lsof" to have unique handles - one per row.

This worries us quite a lot sicne we had issues with reaching the 1024 limit earlier. We haven't had a chance to replace the kernel drivers with the new ones, but wonder if it's a bug that causing these many file handles in DAHDI - way more than what should be expected from your description.

Any advice on how to debug this?
/O