From peter.dunkley@crocodile-rcs.com Thu Mar 29 11:31:21 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: Thu, 29 Mar 2012 10:31:10 +0100 Message-ID: <1333013470.2772.1.camel@pd-laptop-linux> In-Reply-To: <4F7424E7.1080006@iptel.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0329650144==" --===============0329650144== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, I have tried the fix and it worked. I tried it both with and without the append_branch() call, and both cases worked. Is this what you would expect? Thanks, Peter On Thu, 2012-03-29 at 11:01 +0200, Miklos Tirpak wrote: > Hi, >=20 > I think the problem was in the check made by t_continue() which verifies=20 > whether or not a new branch was added, the check ignored the pending=20 > "blind UAC", i.e. the new branch added by the subsequent t_suspend(). > This explains why the first t_continue() killed the transaction and why=20 > after the second t_suspend(). Thanks a lot for the logs! >=20 > I have committed a fix into master=20 > (9ae149ba25ee6467da1d95dd435995b9a59166a3), could you please try it? >=20 > Miklos >=20 > On 03/28/2012 04:52 PM, Peter Dunkley wrote: > > 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, > >> > >> The append_branch() hasn't helped. > >> > >> Having looked a bit more closely, I think what I said at the end of my > >> last email was not quite right. > >> > >> 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: > >> > >> 1: Mar 28 12:02:28 pd-laptop-linux kamailio[16424]: INFO: > >>