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/
