> Earlier, I asked:
>
> > I have a design question about this - why is PA making an
> XML RPC call
> > to sipXivr to get the presence status? Presence status is
> maintained
> > in sipXrls - this seems like an excessively complicated way to go
> > about this. Shouldn't PA get presence from sipXrls?
>
> Martin Pepin wrote:
>
> > As for the XML-RPC call, it is designed to query the "sip-presence"
> > field of UnifiedPresence. The sip-presence field is
> actually updated
> > by the Openfire plug-in which makes use of sipXrls to
> determine this
> > information.
> >
> >
> "2009-09-29T12:25:21.072000Z":2:sipXivr:INFO:bcmdesk2180.ca.nortel.com
> > :m ain:00000000:sipxivr:"Unified Presence: {status-code=ok,
> > sip-id=201, custom-presence-message=On the phone,
> > unified-presence=not-available,
> > [email protected], xmpp-presence=OFFLINE,
> > sip-presence=BUSY}"
> >
> >
> "2009-09-29T12:26:11.601000Z":2:sipXivr:INFO:bcmdesk2180.ca.nortel.com
> > :m ain:00000000:sipxivr:"Unified Presence: {status-code=ok,
> > sip-id=201, custom-presence-message=,
> > unified-presence=available-for-phone,
> > [email protected], xmpp-presence=OFFLINE,
> > sip-presence=IDLE}"
> >
> > When a user is on a call, sip-presence shows "BUSY". Otherwise,
> > sip-presence shows "IDLE" or "UNDETERMINED". This information is
> > required by the Personal Assistant feature.
>
> I guess I'd like a big-picture view of:
>
> * Which component 'owns' presence?
> * Which components affect it
> * Where they get the data
> * How they update the integrated/unified presence state
> * How that state is made available
>
> Can someone please draw this picture so we can all look at it
> and make sure that everyone agrees?
sipXopenfire owns the unified presence information. That component
generates the unified presence for every user on the system that has
both an IM and SIP ID by blending the XMPP presence provided by openfire
and the SIP state information provided by RLS. sipXopenfire makes the
unified presence available to any component that needs it via an XML-RPC
interface that it exposes. That interface works in both push and pull
modes. In support of the pull mode, sipXopenfire provides an XML-RPC
function to query the unified presence of a given SIP user and returns
it in the XML-RPC response. In the push mode, sipXopenfire provides an
XML-RPC function by which a component interested in asynchronous
notifications about unified presence changes can (un)register itself.
Once registered, that components will receive Unified Presence change
notifications via XML-RPC.
The 'Presence Routing' redirect plug-in is an example of a component
that uses the services of sipXopenfire (in pull mode) to stay informed
of current unified presence information required to make redirect
decisions.
I do not have a picture available right now.
_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/
