On Wed, 2009-09-16 at 07:44 -0400, Dale Worley wrote: > I would expand Scott's suggestion of implementing this functionality > by > subclassing SipSubscribeClient, but in this form: Modify > SipSubscribeClient to have a method that generates the response to a > received NOTIFY. The default method always generates a 200, of course. > But in the SAA usage, you generate either a 200 or the appropriate > failure response.
This might introduce a sequencing problem. Currently, SipSubscribeClient doesn't need to execute the callback to the application in order to generate the response to the NOTIFY. And though I don't think S.S.C. does it yet, I may soon modify it to call the application callback in a relatively slow way. But SA probably wants S.S.C. to call the app callback, and then based on return values or something from the callback, to generate the proper NOTIFY response. OK, I just looked at the S.S.C. code. The NOTIFY 200 is generated just after the app callback, at lines 1015-1023. I think those are the lines that should be bundled into the new method. That allows the subclass to create the response by a different method, or to pass the subscription "application data" pointer to the code that generates the response, or (what might be valuable if there are timing considerations), to combine the app callback and the generation of the response. 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 sipXecs IP PBX -- http://www.sipfoundry.org/
