Thanks Aleksander, I had actually seen your thread from some time ago and it
was what inspired me to take this general approach. So thanks twice!
I have figured out some of my problem, and also have a few questions about some
of the suggestions below. First, after fiddling with my code, I see that the
problem only occurs if my main thread sends a 100 Trying using msg_treply().
What I was doing is having the main thread receive the message, discard it if
is was an ACK or a response, respond with a final 501 response if it was
anything other than an INVITE, and if it was an INVITE then first send a 100
Trying and then hand it off to a clone task via su_msg_send. If I remove the
sending of the 100 trying then everything works (i.e., later the main thread is
able to send a final response). The line where I send the 100 trying in my
main thread is simply:
nta_msg_treply( nta, msg, SIP_100_TRYING, TAG_END() ) ;
Is there any reason that sending a 100 Trying should prevent me from later
being able to send a final response on that same message object?
BTW, I would prefer to have the stack automatically send a 100 Trying to all
INVITEs, but I can't see how to do this with nta (I do see that there are some
nua tags that do this, but I assume I can't used those in nta). Is there a way
to do this?
Aleksander, I think I will try some of your suggestions, but had a few
questions:
1) In terms of obtaining and then releasing the root object from the clone, you
mention a scenario where the main thread should release/obtain if it is doing
other non-nta related stuff. In my case it is not doing any such other stuff,
just su_root_run(). Does that mean the clone will never be able to obtain the
root object, or that I need to do something to periodically release the root
object from the main thread (and that wouldn't be so great if the clone had to
wait even 100ms or so when it wanted to obtain the root).
2) I chose stateless only because it seemed a bit simpler, but I may change to
using stateful. In your implementation did you simply create a single default
leg to use in the stateful mode, or did you explicitly create a leg for each
transaction?
3) How does stateless mode handle an incoming CANCEL? Does nta itself reply
with a 200 OK to the CANCEL and a 487 Request Terminated, or does the
application need to do that?
Thanks
Dave
On Jan 4, 2010, at 4:09 AM, Aleksander Morgado wrote:
> HI Dave,
>
>
> I am writing a fairly simply stateless redirect server. It is multithreaded,
> where the main thread creates the root task and runs the thread loop, and
> receives incoming SIP invites. If I simply respond to the INVITE with
> nta_msg_treply in the main thread, everything works. However, if from the
> main thread I send a message (su_msg_send) to a clone task, with the message
> containing the msg_t and sip_t, and then from the clone do the lookup of the
> contact header I want to use, and (finally) then from the clone task send a
> reply message back to the main thread.....now when the main thread calls
> nta_msg_treply I get either a log message saying "mreply: cannot complete
> message", or it crashes. This is the case even if I simply try to send a 404
> Not Found (i.e. ignoring the contact the worker thread is bringing back).
>
> It seems like passing the msg_t and sip_t objects out of the main thread --
> and using them beyond the lifespan of the sip message callback -- is the only
> difference I can see between the two scenarios. So my question is, do I need
> to do something to be able to continue to have access to the parameters
> passed to me in the stateless callback function after the time when that
> function returns? Or am I doing something else wrong?
>
>
> I was actually using more or less same approach as yours in my app. Also
> multi-threaded application with NTA, but I was using stateful approach, not
> stateless. In my stateful application, I pass the sip_t and nta_incoming_t
> objects to the clone task using su_msg_send(), but then I do not pass them
> back to the main thread. When I want to reply from the clone task. I just do:
>
> su_root_obtain(root_object);
> {
> nta_incoming_treply(....) --> Would be nta_msg_treply() in your case
> here
> }
> su_root_release(root_object);
>
> Obtaining/Releasing the root object is like locking/unlocking the NTA agent,
> so you can just reply from the clone task after you make sure the main thread
> (or any other thread) doesn't use the NTA agent for anything. BTW, if your
> main thread also does other things apart from receiving incoming requests,
> like callback executions on timeouts which don't use the NTA agent, you can
> su_root_release() at the beginning of the callback and su_root_obtain()
> before exiting the callback, so that the clone tasks can reply themselves
> while the main thread is doing other things not NTA-agent related.
>
> About the specific problem you have, I really can't help much, as I didn't
> see it before. But your way of doing it is quite similar to my way, with the
> only difference of the stateless/stateful approaches, so maybe you can give
> it a try.
>
>
> Also, once I do generate a final response, is it my responsibility to do
> anything to clear the memory associated with the objects related to that
> message (the sip_t and msg_t parameters I got from the stateless callback)
>
>
> No, you don't need anything else. When you call either nta_msg_treply(),
> nta_msg_tsend() or nta_msg_discard(), the request is marked as processed in
> the NTA agent, and will be freed by the agent internals after some time.
>
>
> Pekka, please correct me if anything wrong.
>
> Cheers,
> -Aleksander
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Sofia-sip-devel mailing list
Sofia-sip-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
