[Asterisk-Dev] Re: Presence /* Moved to -dev */

Clif Jones ctjones at earthlink.net
Wed Apr 14 13:40:12 MST 2004


I have implemented a SIMPLE presence server for my current employer and 
might be
able to throw some useful tidbits into this discussion.  See below...

Olle E. Johansson wrote:

> John,
> I've added your excellent summary to the wiki as work-in-progress, 
> brainstorm. Just to keep it
> somewhere as a basis for discussion:
> http://www.voip-info.org/tiki-index.php?page=Asterisk+presence+jtodd
>
> On the road to presence there are at least two paths to choose from.
> Let me brainstorm for a while...
>
> * One thing is to check whether an *extension* is busy or not within 
> Asterisk
> -- We have that within the SIP channel with SUBCRIBE/NOTIFY

SIMPLE takes advantage of RFC3265 Subscribe/Notify which Microsoft Messenger
now supports.  Other messaging clients either support this to some 
degree or are
considering it.

>
> * Another thing is to check the status of a USER
> -- That's something we really don't have in asterisk
> -- And that's what everyone at Von was talking about

My company's solution put the Presence server as a independent system.  
SIMPLE
has a notion of "tuples" which we used to define "phone-presence" and 
"user-presence"
if needed.  Our "phone-presence" would basically let you know if the 
phone was registered,
in-use or idle.  This is great for attendant consoles and conference 
applications.  The "user-presence"
could hold the presence information from an IM client.  Two different 
tuples for two different types
of presence.

>
> So as I see it, we have two paths to follow.
>
> * Make Asterisk the presence solution
> * Make Asterisk work together with another platform
> -- SIMPLE
> -- Jabber/XMPP

I would like to see an API in Asterisk to receive low-level presence 
events for the phones.
(i.e. REGISTER/De-REGISTER, in-use, idle)  The problem with presence 
servers is that
the message overhead can really cause a scaling issue which makes me 
desire a different
server (or servers) to handle that load.  Imagine if all phone users 
want to see the status of all
other users at any given time.  Look at the SIMPLE message flows to see 
what I mean.

>
> Since the phone status is only one part of the whole picture, I'm 
> kind-of heading towards
> path 2. A user running a SIMPLE or Jabber software should be able see 
> other users' status
> - away, available, in-the-bar, drunk, meeting, on-the-phone etc. As 
> you see, the phone's
> status is only one piece of the puzzle. Mark's bluetooth software is 
> another interesting
> piece of the puzzle.
>
> Asterisk can handle text messages *within* the context of a call, not 
> outside
> the context of a call. Another reason to use another platform and 
> adopt Asterisk to it,
> delivering data.

You can use the PUBLISH method to have Asterisk push out the phone 
change events
(similar to CDRs but different info) and have the presence server store 
and manage the
subscriptions to the data.

>
> So where are we?
> I haven't found any open source SIMPLE platforms, please correct me if 
> I'm wrong.
> SER has some integration to Jabber, haven't had time to implement and 
> test that.
>
> I have a Jabber2 server up and running that we can test if you want 
> to. It's easy to
> create scripts to do Jabber things. Guess one can easily set up an AGI 
> script to
> check presence in jabber and base telephone busy/not busy decisions on 
> that.
> See http://www.reinvented.net/labs/article/1832 for ideas!
>
> Other ideas
> * You could send messages to a Jabber conference room to match a 
> Meetme conference.
> * Deliver voicemail notifications with jabber
> * Change jabber status when a user answers phone call
>
> In order to do anything like this we need to decide the 'person' 
> entitiy in regards to asterisk
> extensions/users/peers.
> * An extension is not a user, some extensions may follow one person, 
> some extensions serve many persons
> * A user/peer/friend is a phone - persons may move between phones in 
> some configurations

Our SIP solution supports forking which adds another dimension to this 
problem.  What we did was allow
one to associate a "presence ID" to a subscriber number.  We also have 
to look at how many calls a particular
subscriber is involved with (call waiting, etc.).  We send presence 
events out for a particular subscriber to
the presence server and then it looks up the presence ID and updates the 
"phone-event" tuple which is
independent of other types of presence such as an IM client.  Hopefully 
this stirs some thought.

>
> To end my brainstorm, I agree fully that this is needed. We need a 
> presence solution that
> works with Asterisk. I'm not sure it has to be within Asterisk, but it 
> has to be
> integrated to Asterisk in some way - maybe through the manager API.
>
> It's late night and I'm writing as thoughts pop up, but, well, anyway, 
> just another
> view on this to add to the brew... :-)
> /O
> _______________________________________________
> Asterisk-Dev mailing list
> Asterisk-Dev at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-dev
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>



More information about the asterisk-dev mailing list