On Fri, 2010-03-05 at 18:00 -0500, Dale Worley wrote: > When you construct a SipSubscribeServer, you need to provide it with > certain subordinate objects that carry out some of its processing: > SipUserAgent, SipPublishContentMgr, SipSubscriptionMgr, and > SipSubscibeServerEventHandler. > > For each event type that you want the Subscribe Server to process, you > have to call SipSubscribeServer::enableEventType. Within that call, you > can provide alternative subordinate objects for use when processing the > specified event type. > > This latter facility is used by no code in sipXecs. In addition, it is > problematic to implement, because at various points in processing > subscriptions, it is difficult for the code to know the event type > involved, so it must search through all the enabled event types > attempting to find the object that handles the subscription in question. > There are also design problems, in that the > SipSubscribeServerEventHandler's getKeys() method extracts the "real" > event type from the Event header field in an incoming SUBSCRIBE (usually > by deleting irrelevant event parameters), but finding the correct > SipSubscribeServerEventHandler requires (in principle) determining the > "real" event type. > > I am proposing to simplify this mess by deleting from > SipSubscribeServer::enableEventType() the ability to specify different > subordinate objects for different event types. (And as I said, no code > uses this facility.)
If it's an elaborate mechanism that's not in use, and removing it would help you solve a current problem, cut away. _______________________________________________ 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/
