[asterisk-dev] Memory failure - channels in meetme
Kevin P. Fleming
kpfleming at digium.com
Wed Nov 2 08:57:49 CDT 2011
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
> 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
More information about the asterisk-dev