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..
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/
