Presence and IntComm WG

[Stephen Kingham <>]

Hi

Steve Blair wrote:

> Jeremy George wrote:
>
> >   I've been doing some rough drafting on PIC history for the generic
> > template.  Most of the early stuff is pretty straightforward to detail.
> > Lessons learned is different.  I realize we've never discussed nor
> > set down on paper exactly what we think we've learned.  Beyond the
> > generic template, we've discussed the value of a 'lessons learned'
> > paper on its own.
> >
> >   I'd like to crank up at least of list of learned items we
> > mostly agree on and solutions where the items represent problems, if
> > possible.  So, here are ten to start.  More?
> >
> > - Jeremy
> >
> >
> > 1)    802.11 is problematic for VoIP.
>           True, however, getting the demo to work for 802.11 clients
>          would be a big win.


My 2c worth is that 802.11 is very important and critical if you have 
any demonstration at a conference must work over 802.11.

So problematic?  I assume you just refer to the problem of providing 
garanteed QoS and not something else?

> > 2)    Much better, more net friendly codecs (e.g., iLBC) are needed.
>            Agreed.
>
> > 3)    We want to locate the user, not a communications device.  So,
> >     the scanned device needs to be worn or always carried (e.g.,
> >     a PDA, a cell/wifi phone.)
>         I agree with the statement about locating the person not the 
> device. I
>       would like to also incorporate location  identification into the 
> soft client
>       for those people using a PDA, or as an option for people who 
> only want to
>       be tracked when they are online. Does this sound reasonable?
>
> > 4)    The ideal target device may not be a laptop.
>         Yipee! I'd really like to see at least some of the demo 
> functionality
>         make it's way into at least a Palm or Pocket PC handheld.
>
> > 5)    There is a critical need for a high quality, open source SIP UA.
>           If you say so. I'll go along with you. I can see why such a 
> client
>           would be helpful but I wouldn't want to out-develop the 
> software
>           vendors. I think getting some functionality into mainstream 
> clients
>           would be better.
>
> > 6)    Fine grained, high quality weather reports would be highly
> >     valuable.
>           I like this idea. The only question I have is how the report 
> is presented
>          to the user. Do we develop the interface such that the 
> weather report is
>          always present and current then leave the user to determine 
> if current
>          weather conditions are acceptable for the operation they are 
> about to perform
>          or do we pop-up (sorry to use that word) the report when the 
> user attempts
>          an operation that we think is inappropriate for current 
> conditions? Did I
>          clearly define the difference?
>
> > 7)    Line item portals and maps have complementary values.
>            Not sure what this is.
>
> > 8)    Versioning is important.
>            It is although I don't think we need a formal revision 
> control system unless
>           we plan on distributing a packaged server.
>
> > 9)    Initially, users really have no idea how to deal with PIC/ALS.
> >     The dominant reaction is confusion.
>            and inconsistency from what I heard. I think we are a 
> victim of our
>           own initial success. Early demo users returned to each MM 
> expecting
>           certain functionality. It seems that some participants felt 
> changing the
>           focus of the demo created a little confusion.
>
> > 10)    Wired headsets aren't ideal.
>
>
>             I'm unaware of any issue with the wired headsets. I'll 
> take your word
>           on this one.
>
> Thanks for starting the this list Jeremy. Please let me know if my 
> comments
> are unclear or seem off base.
>
> Thanks,Steve


--
Stephen Kingham, MIT, BSc, E&C Cert
Project Manager and Consulting Engineer 
mailto:
Telephone +61 2 6222 3575 (office)
         +61 419 417 471 (mobile)
Voice and Video over IP
for The Australian Academic Research Network (AARNet) and
http://www.aarnet.edu.au