[Freeswitch-dev] Dialog events: full vs partial

Fri Oct 15 10:19:04 PDT 2010

Same answer as before.

We are open to improvements but you cannot break any existing
functionality and it cannot make FreeSWITCH slow an inflexible just
because some RFC wants it.

I think most of the presence implementations in SIP are fool hearty to
begin with but we are trying to also normalize presence into an
abstraction and we currently do not support one entity sending back
multiple presence informations so that concept would need to go into
the core abstraction before it could be realized into the sip
endpoint.

On Fri, Oct 15, 2010 at 11:59 AM, Beeton, Carolyn (Carolyn)
<cbeeton at avaya.com> wrote:
> That's interesting, but I'm not sure that it addresses the entire issue.
>
> I first observed this problem when working on another feature, where I want to monitor calls being handled by a Freeswitch app at a certain extension.  I was not getting the full list there, either.
>
> If Freeswitch was returning a proper "full" list and proper "partial" updates, conferences wouldn't need to be handled as a special case.  Doesn't the mismatch between the RFC and the behaviour warrant some investigation?
>
> Carolyn
>
>> -----Original Message-----
>> From: freeswitch-dev-bounces at lists.freeswitch.org
>> [mailto:freeswitch-dev-bounces at lists.freeswitch.org] On
>> Behalf Of Anthony Minessale
>> Sent: Friday, October 15, 2010 11:29 AM
>> To: freeswitch-dev at lists.freeswitch.org
>> Subject: Re: [Freeswitch-dev] Dialog events: full vs partial
>>
>> 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
>>
>> _______________________________________________
>> 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
>>
> _______________________________________________
> 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