> -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of > Worley, Dale (BL60:9D30) > Sent: Friday, June 12, 2009 5:12 PM > To: sipX-dev > Subject: [sipX-dev] XX-4591 When an established subscription > ends,the RLS should resubscribe > > Proposed behavior for SipSubscribeClient to allow automatic > re-creation of failed subscriptions: > > When addSubscription is called, appropriate state is created > for the "subscription set". An out-of-dialog SUBSCRIBE is > sent to the specified URI. All received NOTIFYs establish > state for a subscription. > > If the out-of-dialog SUBSCRIBE receives a failure response, > and if no NOTIFY is received for it before the retry > interval, then the out-of-dialog SUBSCRIBE is retried at > increasing intervals (with new Call-Id each time). > > Each subscription is refreshed based on the expiration times > given in NOTIFY requests. > > When a re-SUBSCRIBE receives a transient error response, it > is retried at increasing intervals. Transient errors are: > > 408 > 482 > > (To receive a 482 response, some other fork of the SUBSCRIBE > must have reached the UAS, presumably due to selecting an > alternative transport due to lost messages.) > > When a re-SUBSCRIBE receives an error response that is not a > transient error response, we terminate all the subscriptions > in the subscription set and send a new out-of-dialog SUBSCRIBE. > > Resend schedule: > > initial resend interval: 1 second > doubling each time until > maximum resend interval: 5 minutes >
The implementation of an Appearance Agent (for Bridged or Shared Line Appearances) that I am currently working on uses the SipSubscribeClient in a way similar to the RLS. Part of the BLA I-D (http://tools.ietf.org/html/draft-anil-sipping-bla-02) says (section 8): "the State Agent MUST SUBSCRIBE with a shorter expiration (expiration interval not smaller than 300 seconds is RECOMMENDED) following the notification of a 'confirmed' dialog or when a Event Agent honors a 'trying' for call origination, with the user agents that notified it of this information." (the purpose being to avoid tying up a shared line if one set dies while holding it). To support this, I was planning to add an interface to the SipSubscribeClient and the SipRefreshManager to change the subscribe timeout. I am not sure how this would interact with what is proposed here. I would want to see a failure response right away, so that the shared line could be freed for other users. The I-D goes on to describe an alternate method (even though the paragraph quoted above was a MUST) - where the UA is responsible for reducing the expiry period of subscriptions to it - Polycom does not appear to be doing this. Once again, I might be misinterpreting this draft... Carolyn _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
