Hi Dave,
> 1) Sending the provisional response definitely seems to mark the message > for deletion, reclamation, whatever. I did a simple test of trying to send > a final response from the main loop right after sending a 100 Trying and got > the same "message could not be completed" message. So it has nothing to do > with threading, and it definitely seems that stateless mode allows only for > a single response. Is there any reason not to consider this a bug? Even > though we are not dealing with transactions in stateless mode, a request is > certainly able to have multiple provisional responses but only a single > final one. > Well, not sure. The provisional reply has a meaning in terms of transactions, and the stateless mode doesn't know anything about transactions... Pekka, any hint? > > 2) It does not appear that the stack automatically generates a 100 Trying > in this case. I tested as you suggested, with a 2 second sleep in my clone > task (allowing the main thread to continue running), but no 100 Trying was > generated. > > Maybe 2 seconds is not enough? Or maybe it will not do it as the 100 Trying is generated in-transaction, and the NTA is stateless? > 3) It appears that the main task must periodically yield the root object at > times in order for a clone task to obtain it. I tried sending the response > from my clone task, after first calling su_root_obtain, but the clone blocks > forever on that call. This must be because my main thread is calling > su_root_run and therefore has a lock/mutex on the root object. > Oh... in my case, the main thread actually does lots of things... I guess that putting a timeout function to be called every some ms is not enough, right? Pekka, any suggestion? > > 4) In stateless mode, any retransmitted INVITEs that are received are sent > up through the stack to my stateless callback, as expected. This means that > my code by default would process the INVITE twice -- no big deal if I could > generate 100 Trying responses since this would pretty much greatly mitigate > the chance of receiving retransmissions in all but the case of network > issues. > I really believe you need stateful approach... :-) > > Given point #3, what are the options for allowing clones to access the root > object? As I mentioned in my earlier email, I don't view it as a > particularly great solution if I have to release it every so many > milliseconds in my main thread, because even that slight delay keeps clone > tasks waiting to complete their work longer than necessary, and under > serious load that would degrade performance. I guess if there are no other > options I would keep with my current method of sending a reply message back > to the root task and having all sending done from the main thread, as that > seems to allow clones to perform more efficiently. > Yes, probably the only option... but let's see what Pekka and others says for this issue. > > As far as the choice of stateless vs stateful, I think I may play around > with a stateful version to see what it is like, but I think stateless would > be fine for my needs if I could figure out how to generate a 100 Trying. > I'm really not forming a dialog anyways since each INVITE gets a final > non-success response of one kind or another, so I'm not sure there is all > that much value of having the stack manage transactions for me. > > There aren't successful INVITEs? What is it exactly what your app is doing? 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
