> -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of > Lawrence, Scott (BL60:9D30) > Sent: Tuesday, September 29, 2009 10:02 AM > To: Pepin, Martin (CAR:9D80) > Cc: [email protected] > Subject: Re: [sipX-dev] Patch ready for XX-6589 and XX-6590 > > On Tue, 2009-09-29 at 09:49 -0400, Joly, Robert (CAR:9D30) wrote: > > > 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.c > > > om > > > > :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.c > > > om > > > > :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. > > a text picture is quite adequate for the moment, Robert - thank you. > > So - I go back to my original question but with revisions: > > * Why is PA asking sipXivr for the presence data when > that data is > owned and maintained by sipXopenfire? > * Wouldn't it be better to have PA register for updates > so that it > already knows the state when it need it? >
The PA is a sub-component of sipXivr. A thin wrapper class was added to sipXivr that does the XML-RPC work to get the presence data from sipXopenfire. In phase 1 it is ok to query the info when its required since we are using the info to add value to the missed calls and find commands so a bit of latency is ok. Agree that in phase n, when PA is in the call path, we need to add code to register for updates so the information is at the PA's fingertips. This point will be made explicity on the PA design wiki page (still on my todo list to write it). Peter _______________________________________________ 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/
