I don't see it as a problem for incoming calls. I do
not know pjsip internals, but I would imagine that in
the case of incoming calls, the call is not destroyed
when the callback finishes execution... It would make
more sense for the call to last as long as an internal
timer for accepting the call expires, the other side
hangs up, or the user chooses to answer/ignore the
call.
I have seen an issue when the remote party cancels the
call before the local party answers, but that is
really a separate thread.
Anyway, it works for me... I simply queue a message
and send it to the GUI thread. Then return from the
incoming callback, and then the GUI thread (once the
users chooses to answer or ignore) queues a message
back to my main processing loop to answer/abort call.
Works pretty well. And, the event queuing method I use
is simply a mutex guarded FIFO buffer (std::vector),
where in my main thread I simply go through the buffer
and send out events to registered listeners. I don't
think it really wise to lock yourself to using
somebody's else's queue (ie. Qt), when doing it
yourself is actually pretty simple. Though, I'm also
not a huge fan of using signals/slots, but that's just
me :)
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
