From peter.dunkley@crocodile-rcs.com Wed Mar 28 16:52:38 2012 From: Peter Dunkley To: sr-dev@lists.kamailio.org Subject: Re: [sr-dev] Using t_suspend()/t_continue() multiple times on the same transaction Date: Wed, 28 Mar 2012 15:52:27 +0100 Message-ID: <1332946347.21388.17.camel@pd-laptop-linux> In-Reply-To: <1332945030.21388.10.camel@pd-laptop-linux> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1850403204==" --===============1850403204== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello again, I took a quick look at the code in dset.c:append_branch(). This appears to update the global variable nr_branches, but the check in t_suspend.c:t_continue() is against t->nr_of_outgoings. There are no calls into the tm module in the PRESENCE_DISTRIBUTE and PRESENCE_ENQUEUE routes except for t_suspend(), so I suspect that the call to append_branch() didn't work because the updated nr_branches value was not used to update t->nr_of_outgoings. Should this be what happens? Does this make sense? Is there a simple work-around for this? Thanks, Peter On Wed, 2012-03-28 at 15:30 +0100, Peter Dunkley wrote: > Hi, >=20 > The append_branch() hasn't helped. >=20 > Having looked a bit more closely, I think what I said at the end of my > last email was not quite right. >=20 > The t_continue() that kills the transaction is actually the first one. > However, it only kills the transaction (causing a 500 to be sent) > after it has been successfully suspended. What this means is that the > second t_continue() seems to manage to resume the transaction (despite > it having previously been killed), but at this point the presence APIs > go wrong because the transaction cannot be statefully replied to. > Here is some log content: >=20 > 1: Mar 28 12:02:28 pd-laptop-linux kamailio[16424]: INFO: >