[asterisk-dev] Memory failure - channels in meetme

[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.

> A related issue is why I need chan_dahdi for meetme? What's the difference between loading chan_dahdi and using Meetme without it (still using Dahdi kernel modules)?

MeetMe creates a chan_dahdi channel into the conference (so there is an 
ast_channel structure involved) in order to be able to record the 
conference or to play various kinds of audio (recorded conference user 
names, etc.) into the conference. This is necessary for two reasons: 
these items can't be played into the conference using the channel 
associated with any specific conference user (because then they wouldn't 
hear the announcement), and they can't be played into the conference 
using the shared pseudo channel because it doesn't have an ast_channel 
structure associated with it and the Asterisk APIs that do file 
recording and playback only work on ast_channel instances.

This usage of chan_dahdi is not mandatory; if the conference does not 
use any of the 'i', 'I', or 'r' options, there is no need for the 
chan_dahdi channel driver to be loaded, although right now app_meetme 
always tries to use it even if those options weren't specified. It's 
possible this could be optimized, but it would require changing the 
order that some steps are performed in app_meetme (parsing options 
before calling build_conf(), and telling build_conf() whether the 
chan_dahdi channel is going to be needed or not).

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming at digium.com | SIP: kpfleming at digium.com | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org