Presence and IntComm WG

[Michael Van Norman <>]

I think we have to support multiple device logins.  In fact this is 
already a common feature of AIM, Skype, etc.  I haven't played 
extensively with Skype in this area, but I believe AIM targets messages 
to the non-Away clients if there are available clients logged in.  I 
would guess Skype does the same.  Maybe a presense enabled SIP 
environment should do the same: send INVITEs to the available clients 
and ignore the non-available clients (in other words, only INVITE open 
presentities).  In this model, the PA should send a single NOTIFY with 
the "best" info it has.  Although that model would end up dropping 
custom presence states ...

This is not likely to be an easily solved problem.

/Mike

Candace Holman wrote:
> Well, they do not have the same Contact header (the ip address will be 
> different), so the subscriber will get updates from both the Contacts.  
> These updates will be performed on a single URI in the subscriber's 
> contact list, so the client is acting as the merging process for the 
> updates.  The server doesn't know whether you are actually switching 
> from away to available between the two machines, or whether you are 
> logged in twice.
> The client doesn't know that you have a split presence-personality 
> unless you register with a different URI at different devices.  Do you 
> consider this is a bug or a feature?  If we could put in a feature 
> request to allow multiple device logins, would you like it to be 
> something that we could configure on the server?  Or on the client?
>
> Candace
>
> Michael Van Norman wrote:
>
> > I was not seeing the 481s.  I am running with the default 3600 second 
> > interval (I am going to watch it for a while and see what happens).
> >
> > I have however noticed something else: what should happen when you 
> > have multiple clients using the same URI?  Right now, the presence 
> > "flops" between them.  If I am away at my desk, but available on my 
> > laptop, a subscriber seems to get the two states alternating.
> >
> > /Mike
> >
> >
> > Candace Holman wrote:
> >
> > > Hi all,
> > >
> > > In testing with David from UPenn, we discovered a problem on the 
> > > client that will have a BIG impact on your testing.  Do not set the 
> > > EyeBeam Presence Agent Refresh Interval to 10 seconds, set it to 
> > > something much larger like 86400 seconds.  My apologies.  I will 
> > > update the web site.  If you were having problems with presence only 
> > > working for a little while (10 seconds?), try this change and you 
> > > should see continuous presence updates every 30 seconds or so!
> > >
> > > I wrote that you should set the Presence Agent Refresh Interval to 10 
> > > seconds.  I assumed that this was the same as the refresh rate for 
> > > presence updates, but it is not.  This is actually the maximum time 
> > > that you will remain subscribed to do presence updates with your 
> > > server.  If you try to send presence updates after the refresh 
> > > interval terminates, in the Diagnostic Log you will see a header 
> > > like: *Subscription-State: terminated;reason=timeout* and then the 
> > > reply from the server will say: *SIP/2.0 481 Call/Transaction Does 
> > > Not Exist*   The only thing that will cause your client to SUBSCRIBE 
> > > again is to disable and re-enable the account registration.  But 
> > > setting the refresh interval to 86400 will make the subscription last 
> > > for 24 hours.
> > >
> > > Candace