On Thu, 2009-05-28 at 21:22 -0400, Dale Worley wrote: > 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.
We don't seem to be using that class in very many places - might it be easier to just extend the functionality and update the usages to expect the new behavior? It seems to me that making the refresh/restoration of broken subscriptions part of the service provided by this class is something that most users of it really should have anyway (that is, anything that's not already handling failures is probably broken). I don't think we need to maintain backward compatibility with any use not in sipXecs (and not with any use in the current codebase that we're not actually using now). > 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. Could you just send a new SUBSCRIBE to the same URI you used originally, with the same call-id and from tag (no to tag), and a higher Cseq, might it look like a refresh to all the other forks? Alternatively, you could send the new SUBSCRIBE request to establish a new set, and then afterwards kill off one of any duplicates. > 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.) Using the usual exponential backoff (with a limit) seems prudent. You could add a method that the application could use to force the retry cycle to reset back to the initial retry time (500ms ?). _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
