In Asterisk 1.6.0.6 I noticed that after the first member has entered
into meetme conference MEETMEUNIQUEID variable is set to the uniqueid of
the first member. Even when the first member left the conference
MEETMEUNIQUEID still points to his uniqueid for the new members joining
the conference.
Is it supposed to be so? I would expect to see the uniqueid of the
pseudo channel, which is the "base" of meetme conference.
So the change would be in app_meetme.c:
pbx_builtin_setvar_helper(chan, "MEETMEUNIQUEID", conf->uniqueid);
to
pbx_builtin_setvar_helper(chan, "MEETMEUNIQUEID",
conf->chan->uniqueid);
--
Grigoriy Puzankin
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
Posted: Thu Apr 23, 2009 8:42 am Post subject: [asterisk-dev] MeetMe, setting MEETMEUNIQUEID
In article <49EDFFFE.6020501@gmail.com>,
Grigoriy Puzankin <gpuzankin@gmail.com> wrote:
Quote:
Hi,
In Asterisk 1.6.0.6 I noticed that after the first member has entered
into meetme conference MEETMEUNIQUEID variable is set to the uniqueid of
the first member. Even when the first member left the conference
MEETMEUNIQUEID still points to his uniqueid for the new members joining
the conference.
Is it supposed to be so? I would expect to see the uniqueid of the
pseudo channel, which is the "base" of meetme conference.
So the change would be in app_meetme.c:
pbx_builtin_setvar_helper(chan, "MEETMEUNIQUEID", conf->uniqueid);
to
pbx_builtin_setvar_helper(chan, "MEETMEUNIQUEID",
conf->chan->uniqueid);
The value of MEETMEUNIQUEID is not intended to be used to find the original
channel whose Unique ID it contains. It is just an opaque value that will
be common to all calls that participate in that conference, so that they
can easily be related to each other. The unique ID of the creating channel
was just a convenient value to use. The unique ID of the pseudo channel
would be just as good, but no better, IMHO.
In article <49EDFFFE.6020501@gmail.com>,
Grigoriy Puzankin <gpuzankin@gmail.com> wrote:
> Hi,
>
> In Asterisk 1.6.0.6 I noticed that after the first member has entered
> into meetme conference MEETMEUNIQUEID variable is set to the uniqueid of
> the first member. Even when the first member left the conference
> MEETMEUNIQUEID still points to his uniqueid for the new members joining
> the conference.
>
> Is it supposed to be so? I would expect to see the uniqueid of the
> pseudo channel, which is the "base" of meetme conference.
>
> So the change would be in app_meetme.c:
>
> pbx_builtin_setvar_helper(chan, "MEETMEUNIQUEID", conf->uniqueid);
> to
> pbx_builtin_setvar_helper(chan, "MEETMEUNIQUEID",
> conf->chan->uniqueid);
The value of MEETMEUNIQUEID is not intended to be used to find the original
channel whose Unique ID it contains. It is just an opaque value that will
be common to all calls that participate in that conference, so that they
can easily be related to each other. The unique ID of the creating channel
was just a convenient value to use. The unique ID of the pseudo channel
would be just as good, but no better, IMHO.
Cheers
Tony
Actually, I could see some value for using the pseudo channel's unique ID
instead. The reason is that there could be some oddball dialplan that allows for
the same channel to create multiple conferences. In such a case, would the
MEETMEUNIQUEID be the same for all conferences created by the same channel?
However, using the pseudo channel's unique ID doesn't seem like a good universal
solution either. The problem with using the pseudo channel's unique ID is that,
iirc, a conference can actually run even if the pseudo channel is not created
properly. For example, app_meetme can run even if chan_dahdi is not loaded.
A simple way of uniquely identifying all conferences would be to use a
monotonically-increasing static int.
Mark Michelson
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
In article <49F08058.9050407@digium.com>,
Mark Michelson <mmichelson@digium.com> wrote:
Quote:
Tony Mountifield wrote:
> In article <49EDFFFE.6020501@gmail.com>,
> Grigoriy Puzankin <gpuzankin@gmail.com> wrote:
>> Hi,
>>
>> In Asterisk 1.6.0.6 I noticed that after the first member has entered
>> into meetme conference MEETMEUNIQUEID variable is set to the uniqueid of
>> the first member. Even when the first member left the conference
>> MEETMEUNIQUEID still points to his uniqueid for the new members joining
>> the conference.
>>
>> Is it supposed to be so? I would expect to see the uniqueid of the
>> pseudo channel, which is the "base" of meetme conference.
>>
>> So the change would be in app_meetme.c:
>>
>> pbx_builtin_setvar_helper(chan, "MEETMEUNIQUEID", conf->uniqueid);
>> to
>> pbx_builtin_setvar_helper(chan, "MEETMEUNIQUEID",
>> conf->chan->uniqueid);
>
> The value of MEETMEUNIQUEID is not intended to be used to find the original
> channel whose Unique ID it contains. It is just an opaque value that will
> be common to all calls that participate in that conference, so that they
> can easily be related to each other. The unique ID of the creating channel
> was just a convenient value to use. The unique ID of the pseudo channel
> would be just as good, but no better, IMHO.
Actually, I could see some value for using the pseudo channel's unique ID
instead. The reason is that there could be some oddball dialplan that allows for
the same channel to create multiple conferences. In such a case, would the
MEETMEUNIQUEID be the same for all conferences created by the same channel?
Yes, it would, and that is a good point. I guess something like Vicidial,
which uses conferences as a convenient way to bridge channels, could create
several conferences in succession on the same channel as calls get redirected.
Quote:
However, using the pseudo channel's unique ID doesn't seem like a good universal
solution either. The problem with using the pseudo channel's unique ID is that,
iirc, a conference can actually run even if the pseudo channel is not created
properly. For example, app_meetme can run even if chan_dahdi is not loaded.
Yes, I think Meetme can run without chan_zap/chan_dahdi provided you don't
want to do recording, or possibly play username intros. If it can't request
a Zap channel it falls back to opening /dev/zaptel/pseudo directly, to get
an fd for playing the enter and leave sounds on.
Quote:
A simple way of uniquely identifying all conferences would be to use a
monotonically-increasing static int.
Except that this wouldn't make them unique across reboots. You probably
need to use the same scheme as for channel unique IDs - construct it from
the current time_t and a sequence number.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum