Re: [Sip-implementors] Achieving up to date presence info without PUBLISH

[David Stuart]

I was thinking along this line as well, but this just confirms my 
suspicions..

Thanks again.

Adam Roach wrote:

The ephemeral nature of endpoint B's connectivity
is a pretty good indicator that peer-to-peer isn't
an appropriate model for what you are trying to do.
/a

 

-----Original Message-----
From: David Stuart [mailto:[EMAIL PROTECTED]
Sent: Monday, August 25, 2003 12:22
To: Adam Roach
Cc: SIP Implementors
Subject: Re: [Sip-implementors] Achieving up to date presence info
without PUBLISH
OK,

So I understand the need for the subscription migration; but 
let's take 
this a step further. Let's say there's no registrar. We're talking 
straight peer-to-peer. Is this a valid scenario, or is this 
why most UAs 
basically FORCE the user to register before doing presence?



Adam Roach wrote:

From the mile-high view, the way you would make such
   

a system work is this:

1) A registers with the registrar and sends a SUBSCRIBE message to B
2) B is not registered, so the registrar "parks" the subscribe. That
 is, the registrar accepts the subscription and sends a presence
 document for "B" indicating "closed." (Note that the 
     

registrar isn't
   

 really acting as a presence server here; it is just acting as a
 parking lot for subscriptions).
3) B starts and registers with the registrar
4) The registrar sends a NOTIFY to A with a 
     

"Subscription-State" header
   

 of "terminated", and a reason parameter of "deactivated".
5) A sends a SUBSCRIBE message to B
6) B accepts the registrations, and things go forward normally.
This is the *precise* scenario that motivates all the text in
RFC 3265 surrounding migration.
/a



     

-----Original Message-----
From: David Stuart [mailto:[EMAIL PROTECTED]
Sent: Monday, August 25, 2003 10:20
To: SIP Implementors
Subject: [Sip-implementors] Achieving up to date presence 
       

info without
   

PUBLISH

Hi All,

I have a question about the manner in which presence info is 
kept up to 
date, assuming that the PUBLISH draft is not in the picture. 
Basically 
just assume peer to peer presence for the purpose of this question.

Say I have two user agents, A and B.

1) A registers with the registrar and sends a SUBSCRIBE message to B
2) B is not running, so B does not receive the SUBSCRIBE message
3) A sets a presence of "closed" or "unknown" (or something 
similar) for B
4) B starts and registers with the registrar

result:  A has an incorrect current presence for B.

What I am wondering is, how can you avoid this situation? 
Does A have to 
"poll" periodically for B (i.e. a "fetch")? Without any 
       

help from an 
   

intermediary presence server (which is running 24/7) it seems 
that you 
would always need to poll.

What is the usual agreed upon polling interval? An hour? 10 
minutes? 1 
minute? 2 seconds?

Any help would be appreciated.

Thanks,
       

--
David Stuart, SIPquest
Email: dave (at) sipquest (dot) com
Phone: 254-8886 x234  Web: http://www.sipquest.com/
Address: 106 - 350 Terry Fox Drive, Kanata Ontario, K2K 2P5


_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors