Thevonly softohone supported for presence extensions with xmpp is Bria. Only a hardphone supporting rfc4235 with a properly configured phone and xmpp client with both registering to sipx work in the current configuration.
I understand what you are "trying" to do, however the framework is not designed for a generic softphone and an independent xmpp client. I don't particularly think extending the registration data only will do much for anyone. It might be good to post your thoughts on this within the sipx-dev list though. I still think true corporate presence should be delivered in an XML fashion so it can ultimately be used as a feed, web page, widget or gadget and not have the entire framework rewritten or leveraged for a single use case... On May 1, 2011 11:13 AM, <[email protected]> wrote: > Hi Sven, > > This could be problem with the Pidgin Client, because in general "On the > Phone" presence state indicate the User Busy, so the icon is controlled on > the Pidgin client. > > I have tested with Bria Soft Client, and it shows the in RED color > indicating the User phone is busy!! > > On , Sven Evensen <[email protected]> wrote: > > > > >> 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 > >> > > >> >%
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
