Calling SipStackImpl::createSipProvider() after SipStackImpl::start()

[kduncan99]

Documentation does not explicitly prohibit this. Perusing the code, it looks like it should work.
However, deleteSipProvider() has an odd bit of code which, when the last provider is removed, causes SipTransactionStack::stopStack() to be invoked.

This seems wrong - shouldn't deleteSipProvider() invoke the higher-level stop() instead?
More to the point, shouldn't deleteSipProvider() not even care about this?

I'm not sure what the expected behavior is, but I see two issues:

1. Either we should formally allow creation of SipProviders after the SipStack has been started (implying that we remove the call to stopStack() when the last SipProvider is deleted), or we should formally deny creation of SipProviders after the stack has been started.
2. If we really want to stop the SipStack when the last SipProvider is deleted, we need to ensure we invoke the right stop method (maybe super.stopStack() is the right thing... it just doesn't seem that way).

[vladimirralev]

Yes this is not ideal. I think it is best deleteSipProvider() not to care about the stack stop. But need to figure out if this can break some code. I can't remember adding and removing providers on the fly, so I am not sure if everything work out (leaks, state consistency). Have you done any tests with this, does it work sufficiently well? In any case it should be safe enough since most apps call stop stack anyway, but it will still need a proper test run.

[kduncan99]

Well, it does seem to work. We have other problems, so I cannot formally verify functionality.