On Fri, 2009-06-12 at 17:12 -0400, Dale Worley wrote: > 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 > > Notifications to the upper layer: > > The SipSubscribeClient machinery now sends notifications to its > application when subscriptions are created and when they end. These > will remain, and can be monitored by the application to determine > whether creating subscriptions was successful. > > Forked subscriptions: > > Although the SipSubscribeClient machinery can handle forked > subscriptions, in almost all of the cases we care about, there will be > only one UAS for each call of addSubscription. As a result, the > visible handling of failed subscriptions is much simpler than the > descriptions above: If the subscription fails, retry it. > > If multiple subscriptions are generated, and one of them fails, it > appears to be a waste to terminate subscriptions that haven't failed. > But it significantly simplifies the logic to do so, and the new > SUBSCRIBE should reach any UASs whose subscriptions have not already > failed. > > > Comments?
Looks good to me. I agree that the additional complexity to optimize the resubscribe for failure of one subscription created by a forked request is not worth it. _______________________________________________ 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/
