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 > >> > >> > >> > > -- > 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
