I am not into the RFC's, so I am just coming from a user perspective.
Since IM is integrated with sipx, I would expect to see in call status to a user even if his IM client is logged out. (if that user has allowed presence of course) Another issue is that the status seen in Pidgin for an IM user who is on the phone is "Available, On the phone" while the icon shows the green circle, meaning available. It is obviously a tricky thing to combine telephony presence with IM presence. But that is what we want and the reason we are trying Pidgin and the sipx xmpp. Regards, Sven ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: 01 May 2011 07:05 To: Discussion list for users of sipXecs software Subject: Re: [sipx-users] IM client does not show presence May be we going in to different directions, see i have started my response considering the existing sipXopenfire design and how the presence state is maintained. >From My understanding it is designed to provides the Unified Presence based on the SIP and XMPP presence states. Consider the following combinations SIP State XMPP State Unified Presence Offline OnLine Offline OnLine OnLine OnLine Busy Online Busy (On the Phone) DND Online DND IDLE Online IDLE So here the first two presence states can be achieved using the RFC3680 (reg-Info) and remaining presence states are already implemented. So if we have enhance the existing sipXopenfire with the support of RFC-3680, then it would assume that it is supporting the Unified Presence functionality. On , Tony Graziano <[email protected]> wrote: > On Sat, Apr 30, 2011 at 7:54 AM, [email protected]> wrote: > > > Hi, > > > > > > I am considering the case where general enterprises normally use, like for > > > example we have MS OutLook and Office Communicator. I would general prefer > > > to dial the numbers from the MS Outlook (Click-to-Call), instead of opening > > > the Office Communicator and seeing the presence state.. > > You might consider using a web based click to call (php or iis > > application) for the click to call and see if the API/REST service > > exists to get this information. This would handle both, and could be > > used inside outlook as a feed. It is also much more extensible as it > > does not require outlook, zimbra, and could be deployed optionally as > > a desktop widget. > > > > There was a post here the other day showing how to do the click to > > call with curl. The question is whether the presence/state of the user > > is something that can be pulled. > > > > Perhaps an xhtml browser app that the phone can use to set xmpp > > presence to "available/away" in xmpp will allow you to set > > availability, and perhaps the web app can get call state. This way the > > phone does not have to have an IM client at all for this one > > function... > > > > > > I have tested this scenarios using the Bria Soft Client and Zimbra. I have > > > deployed the com_zimbra_email_plus.zip and com_zimbra_scs.zip zimlets. In > > > this case i am getting the User Presence state as IDLE, even though the Bria > > > SIP client is not yet registered towards the sipXecs System. > > > > > > I think in the Enterprises not every one will be acting as BOSSES, so we > > > should be able control the service on per user basis, in case if they don't > > > want to share presence. > > > > > > On , Tony Graziano [email protected]> wrote: > > >> On Fri, Apr 29, 2011 at 9:41 PM, Rama Krishnam Raju Pakalapati > > >> > > >> [email protected]> wrote: > > >> > > >> > > > >> > > >> > > > >> > > >> > 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. > > >> > > >> > > > >> > > >> In a corporate UC environment, the boss doesn't want to publish his > > >> > > >> state of status without knowing it. > > >> > > >> > > >> > > >> Have you fully read this? > > >> > > >> http://wiki.sipfoundry.org/pages/viewpage.action?pageId=6520862 > > >> > > >> > > >> > > >> I think you have a phone and xmpp client that are not working properly > > >> > > >> if the user shows online when xmpp is shut down. > > >> > > >> > > >> > > >> " If you use Spark or Pdigin and Bria it won't work to automatically > > >> > > >> publish your presence. What you will find is that it will "login", and > > >> > > >> the first time you use the phone it will change your stats to "On the > > >> > > >> phone" for others to see. What will not happen is the dialogue will > > >> > > >> not revert back to "available" after you hang up. Your presence gets > > >> > > >> into a stuck state and is not at all helpful, so don't do it that > > >> > > >> way." > > >> > > >> > > >> > > >> >> > > >> > > >> >> _______________________________________________ > > >> > > >> >> > 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/ > > >> > > >> > > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> -- > > >> > > >> ====================== > > >> > > >> Tony Graziano, Manager > > >> > > >> Telephone: 434.984.8430 > > >> > > >> sip: [email protected] > > >> > > >> Fax: 434.326.5325 > > >> > > >> > > >> > > >> Email: [email protected] > > >> > > >> > > >> > > >> LAN/Telephony/Security and Control Systems Helpdesk: > > >> > > >> Telephone: 434.984.8426 > > >> > > >> sip: [email protected] > > >> > > >> > > >> > > >> Helpdesk Contract Customers: > > >> > > >> http://support.myitdepartment.net > > >> > > >> Blog: > > >> > > >> http://blog.myitdepartment.net > > >> > > >> > > >> > > >> Linked-In Profile: http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 > > >> > > >> _______________________________________________ > > >> > > >> 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/ > > > > > > > > > > > -- > > ====================== > > Tony Graziano, Manager > > Telephone: 434.984.8430 > > sip: [email protected] > > Fax: 434.326.5325 > > > > Email: [email protected] > > > > LAN/Telephony/Security and Control Systems Helpdesk: > > Telephone: 434.984.8426 > > sip: [email protected] > > > > Helpdesk Contract Customers: > > http://support.myitdepartment.net > > Blog: > > http://blog.myitdepartment.net > > > > Linked-In Profile: http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 > > _______________________________________________ > > 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/
