Hi,
Could anyone give me a pointer to the "correct" way to shutdown the resip stack, and more importantly, to know when it is shutdown? I'm running the stack within StackThread, and I'm not using dum for this app. I'm using the shutdown() and join() methods and that all works, but I'm looking for a cleaner overall shutdown that those seem to give.
The key functionality I'm looking for is to "wait" until all SIP response messages in the queue have been pushed onto the wire.
The specific questions I have are:
1. Should the TransactionUser be shutdown before or after SipStack?
Before. That'll ensure that any messages that need to be processed by the TU will be processed. Once you've called requestTransactionUserShutdown(), the stack will start rejecting new requests that would otherwise be routed to your TU.
2. How do I know when SipStack is shutdown? The shutdown() method comments says it sends a ShutdownMessage to the TU, but which TU? And how can I receive that if the TU is already shutdown?
It sends them to all TUs that have not yet been marked as shutting down.
3. How can I query to see if there are any queued outgoing messages within SipStack?
When calling SipStack::shutdown(), we service queued requests until there aren't any left, and reject all incoming requests.
4. Is ShowdownMessage sent to TU after queued messages are sent, or are queued messages just deleted?
After queued messages are sent (it gets put at the back of the queue, and no new stuff is added to the queue thereafter).
5. The ideal clean shutdown would be to tell stack to stop dealing with new stuff, wait for existing stuff to finish, and then let app know. Does this interface exist?
It does that, sort of. Since the stack only knows about transactions, it can't do something like allow traffic for an existing dialog to continue, but reject other requests (although I suppose we could add something like this that just looks at the presence of tags...). It'll finish the transactions it has already started though, I think.
Any pointers, especially to demo code would be appreciated. I looked for but couldn't find any good examples in the test code, while repro seems to use a fixed wait, not event-driven.
DUM uses the more graceful method, I think.