>>There aren't successful INVITEs? What is it exactly what your app is doing?
Sorry, I was classifying any non-200 response as non-success. Mainly I am returning 300 Multiple Choices responses. On Jan 4, 2010, at 11:59 AM, Aleksander Morgado wrote: > 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
