Currently, SipSubscribeClient provides a relatively simple service: When addSubscription() is called, it sends a SUBSCRIBE to the specified URI. All the subscriptions that result are tracked, but if any of those subscriptions fail, they are not restarted by the SipSubscribeClient.
Several places in the RLS (and probably in other servers), we need a more sophisticated service that will restore subscriptions that fail. Although we probably want to incorporate this into the SipSubscribeClient class, conceptually this function is a layer on top of what SipSubscribeClient provides. (Since SipSubscribeClient closely matches what an initial SUBSCRIBE provides in SIP, the current portion of the functionality of SipSubscribeClient is not subject to much change.) This message is to start a discussion on what this more sophisticated functionality should do. Assuming we insert the functionality into the SipSubscribeClient class, the change needs to be upward compatible. This requires adding a parameter to addSubscription, or adding a new method, to invoke the additional functionality. The process of restoring a subscription is not as simple as it seems. There is no reliable way to restore a single subscription dialog that was created by a SUBSCRIBE. This is because of the complexities of the route set -- there is no algorithmic way to create a SUBSCRIBE that is assured of reaching the same destination. (E.g., in sipX, the Record-Route headers carry authentication information bound to the specific dialog.) (If we're really careful, can we get around that?) So to restore a subscription, one needs to send a new SUBSCRIBE to the request-URI of the original SUBSCRIBE. This will most likely recreate the whole set of subscription dialogs, and so one might as well terminate the entire current set of subscription dialogs before sending the new initial SUBSCRIBE. The restoration process might fail in some way. If one destination among many is inaccessible, there is no good way to detect this. (Fortunately, in most practical cases, there is only one destination.) If a unique destination is inaccessible, or if all of the destinations are inaccessible, the SUBSCRIBE receives a failure response, which we can detect. In that case, what algorithm should we use for retrying? In a lot of cases, a backoff-and-retry approach seems to be best. But in certain circumstances, the application knows that the chance of reaching the destination has suddenly improved, and it should be able to force a restoration cycle. (Of course, phones must deal with this situation, and they run into the tradeoff between quickly restoring subscriptions and flooding the servers.) There are related issues about hardening SipSubscribeClient against transient network failures, which I will address in another message. Dale _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
