On Fri, 2009-05-29 at 11:04 -0400, Scott Lawrence wrote: > 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).
Good point. The files that reference it now are: sipXcallLib/src/cp/LinePresenceMonitor.cpp sipXcallLib/src/tapi/sipXtapi.cpp sipXcallLib/src/tapi/sipXtapiInternal.cpp sipXpbx/sipXrls/src/SubscriptionSet.cpp sipXpbx/sipXrls/src/ResourceListMsg.cpp sipXpbx/sipXrls/src/ResourceListTask.cpp sipXpbx/sipXrls/src/ResourceListSet.cpp sipXpbx/sipXrls/src/ContactSet.cpp sipXtackLib/dialogwatch/dialogwatch.cpp sipXtackLib/src/net/SipDialogMonitor.cpp sipXtackLib/src/net/SipSubscribeClient.cpp sipXtackLib/src/test/net/SipSubscribeTestSupport.cpp sipXtackLib/src/test/net/SipDialogTest.cpp sipXtackLib/src/test/net/SipSubscribeClientTest.cpp Outside of test code, the implementation of the class, the RLS, and sipXtapi, there are only 3 "other" references. > > 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? If we can persuade SipUserAgent to carry it correctly, that would work. (Also, copy the route set.) Although being really clever about this might not be worth the effort, since in almost all cases there will be only one destination. > Alternatively, you could send the new SUBSCRIBE request to establish a > new set, and then afterwards kill off one of any duplicates. There is an odd semantic problem, which is what happens if the set of intended destinations for the URI has changed. > 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 ?). It seems like there should be a way to report to the application that the subscription attempt has really, truly failed. But if the class is doing backoff, this isn't really possible. Though the reality is that we can never tell if resubscribing has permanently failed. Hmmm... I think I need to look at the users of SipSubscribeClient to see what their needs are. 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
