>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 > _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
