Hi Lukas, Please see comments inline
> 1) Where have actions like phSubscribe and phDTMF gone? I do think those > are > important other actions that should not be eliminated from access. These actions will of course NOT be eliminated. For now, the new APIs are not yet complete. We will integrate these functions into the new phapi.h soon. > 2) I would suggest that the object free functions take a pointer to the > pointer so that the pointer can be set to NULL immediately inside the > function. This eliminates some types of reuse errors. In fact, it would > most > likely be best to adopt a "Handle" based architecture where the API does > not > give out the object (I'm not sure how feasible that is). All the APIs in the new phapi.h now function with "Handles". I agree that free functions should take a pointer to the pointer. > 3) on the same note, the callbacks could potentially be non-blocking in > the > case that they do not require a return value (a notify for example) so > that > the api keeps ticking even if the app is badly behaved. We will study this. It's good that the sip stack can continue ticking when app behaves badly. However, this must be considered carefully as it would cause more problems to a badly written application. (A new callback may be called while app is handling an other callback, for example). > 4) The eXosip stack does not accept NOTIFY without SUBSCRIBE. This is bad > when connecting to an asterisk box and wanting to get voicemail > notification > (asterisk sends regardless. This is handled lower in the eXosip stack of > course.) [I've made modifications to support the asterisk notify if > someone > wants to incorporate them]. The fact that Asterisk sends NOTIFY to all registered UA regardless of whether a SUBSCRIBE has been received is due to the incapability of Asterisk to handle SUBSCRIBE/NOTIFY correctly. However, as this behaviour is widely accepted now, it's worth supporting it. I think this should be done as an option (We should be able to ask eXosip to accept unsolicited NOTIFY or not). Regards, Minh _______________________________________________ Wengophone-devel mailing list [email protected] http://dev.openwengo.com/mailman/listinfo/wengophone-devel
