Just to follow up on this. I modified the code to run in stateful mode and did not encounter the problems I had in stateless. I also see that in stateful mode the stack does generate a 100 Trying if the N1 timer expires, and that it also handles an incoming CANCEL of a transaction by sending a 200 OK to the CANCEL and a 487 to the INVITE, which is what I prefer. So I will probably stick with stateful mode. (I'm not all that sure what stateless mode would be really usable for given the apparent inability to send a provisional response followed by a final response).
The pattern I am using of using clone tasks to do database lookups and such and handling all incoming and outgoing messages via the main task, communicating both ways (main to clone, clone to main) with messages also seems to be working well, and lets me run a simple event loop in the main task. Dave 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 [email protected] https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
