[Freeswitch-dev] Dialog events: full vs partial

[Anthony Minessale]

The conference has it's own presence feature for the conference as a whole.

see conf/autoload_configs/conference.conf.xml

<configuration name="conference.conf" description="Audio Conference">
  <!-- Advertise certain presence on startup . -->
  <advertise>
    <room name="3001@$${domain}" status="FreeSWITCH"/>
  </advertise>

Then you can subscribe to conf+3001@<your domain>
And the presence is announced for the conference as a whole.




On Fri, Oct 15, 2010 at 10:16 AM, Beeton, Carolyn (Carolyn)
<cbeeton at avaya.com> wrote:
> I have started again on a fresh branch to investigate presence monitoring of
> conference extensions, and I think I have discovered another problem with
> the way that NOTIFYs containing dialog events are formulated.
>
> RFC4235 says:
> "state: This attribute indicates whether the document contains the
> full dialog information, or whether it contains only information
> on those dialogs that have changed since the previous document
> (partial)."
>
> and
>
> "Notifications do not normally contain full state; rather, they
> only indicate the state of the dialog(s) whose state has changed.
> The exceptions are a NOTIFY sent in response to a SUBSCRIBE, and a
> NOTIFY that contains no dialog elements.  These NOTIFYs contain
> the complete view of dialog state."
>
> But what I see the code doing is *never* sending a complete (full) list of
> dialogs, even if there are more than one, and marking all the presence event
> related NOTIFY events as "full" even though by the definition above, they
> are all "partial".
>
> One observable effect is if you are monitoring a conference extension.  The
> light will begin to flash when one person joins the conference, and goes
> solid when another joins, but then goes out when one person leaves, even
> though others are still in.  This is because the NOTIFY is sent with status
> "full" but only contains the one "terminated" dialog, and none of the others
> which are still "confirmed".
>
> I'm not sure yet what is the best way to solve this.  I think that
> sofia_presence_sub_callback is always generating "partial" updates, because
> it is always considering only the most recent event. I think that the
> sofia_presence_resub callback will have to generate one event, containing
> all the rows retrieved from the query, rather than what it does now (which
> is send a SWITCH_EVENT_PRESENCE_IN for each row, which is handled by the
> sofia_presence_sub_callback and thus results in a bunch of what are really
> "partial" NOTIFYs, instead of one "full" NOTIFY).
>
> Does this make sense?
>
> Carolyn
> _______________________________________________
> FreeSWITCH-dev mailing list
> FreeSWITCH-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
>
>



-- 
Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/
Twitter: http://twitter.com/FreeSWITCH_wire

AIM: anthm
MSN:anthony_minessale at hotmail.com
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org
googletalk:conf+888 at conference.freeswitch.org
pstn:+19193869900