> -----Original Message----- > From: Worley, Dale (BL60:9D30) > Sent: Wednesday, September 16, 2009 7:59 AM > > 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 > The application might not be ready to produce a response in-line in the callback (in the SAA case, a message is posted and handled asynchronously). However, the application can commit to sending a response. Therefore I propose to convert the SSC::NotifyEventCallback to return a boolean indicating whether the SSC should send the response or the app will. All existing users except the SAA will return true in their notifyCallbacks. The SAA will return false and MUST then respond to the NOTIFY (since it is provided with the entire notifyRequest in the callback, it has all the info it needs to reply)
Carolyn _______________________________________________ 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/
