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@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@lists.freeswitch.org [mailto:freeswitch-dev-bounces@lists.freeswitch.org] On Behalf Of Anthony Minessale Sent: Friday, October 15, 2010 11:29 AM To: freeswitch-dev@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire
AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@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@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@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900