On Sat, Apr 30, 2011 at 6:37 AM, Tony Graziano <[email protected] > wrote:
> > On Apr 29, 2011 8:39 PM, "Rama Krishnam Raju Pakalapati" < > [email protected]> wrote: > > > > On Wed, Apr 27, 2011 at 1:37 AM, Douglas Hubler <[email protected]> > wrote: > >> > >> 2011/4/26 Sven Evensen <[email protected]>: > >> > We are trying out the Pidgin client for corporate IM. We also want to > pick > >> > up phone presence, at least > >> > > >> > the users who have proper desk phones. But if a user logs off their IM > >> > client (thus showing status Offline), > >> > > >> > the “On the phone” presence does not work anymore. > >> > >> someone can confirm this, but I think it's a known issue. i cannot > >> seem to find tracker item though. > >> > >> I recently tried to figure out how unified presence to was designed > >> and it looked very complicated. The openfire plugin had the bulk of > >> the code along w/registrar plugin. Here's part of the puzzle > >> > >> http://wiki.sipfoundry.org/display/sipXecs/sipXopenfire+architecture > >> > >> Having an EXACT value of the EXACT state of a phone/user at all times > >> is also incredibly important to many parts of the system. So it lead > >> to conversation about looking into AMQP so various parts of the system > >> can help determine a user's state. > >> _______________________________________________ > >> sipx-users mailing list > >> [email protected] > >> List Archive: http://list.sipfoundry.org/archive/sipx-users/ > > > > > > > > The existing design supports the sip dialog-info (RFC 4235), so it is > must the user desk Phones should support this protocol spec. Without this IM > clients will not able to see the User Phone presence ( On the call/Phone) > states. > > > > This RFC 4235 only provides the call states, it does not provide the user > On-Iine/Off-Line states of desk Phone, which is one of drawbacks with the > existing design. At present the IM clients always see On-Line state, even > when the Desk Phone is not registered towards the sipxecs system. > > I don't believe this to be an accurate depiction. Rfc4235 is call states, > but online/offline from IM come from the xmpp client. > > >So in order to implement the User On-Line/Off-Line state, the sipXopenfire > server needs to implement the "reg-info" (RFC-3680) along with the RFC-4235 > and provide the Unified Presence towards the XMPP domain. > > > > > Really. RFC3680 doesn't really address presense except registered or not > registered. It alludes to presence ans sip registration states but does not > have the detail on states that rfc4235 does. > > > So if youbuse both rfc's within openfire, why does it become better > somehow? Because I means the hardphome user does not have to use xmpp to > publish registration status? If so, how does his callstate Feldman his phone > get published without his authorization (xmpp)? > > Not trying to be argumentative, but trying to understand "why" doing both > is better. > I am trying to consider a use case where, the User-A (Bob) would like know the present state of the User-B( Alice), so that he can make decision whether to call him or not. This is very much useful feature for the enterprise who are looking for Unified Presence and Unified Communication services. So in this case with RFC 4235, we always get state as IDLE, even though User-B is not registered. So if User-A trys to make a call to User-B and fails with reason User Not Available. > _______________________________________________ > > sipx-users mailing list > > [email protected] > > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > > _______________________________________________ > sipx-users mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users/ >
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
