If any issues arise as a result we will fix them accordingly.... possibly in pick branch code...
On Fri, 20 Mar 2015 at 11:41 Jason Penton jason.penton@gmail.com wrote:
Hey Daniel,
I have test with that setting restored so I suspect we may have fixed it somewhere else. You can put it back or would you like me to?
Cheers Jason
On Fri, 20 Mar 2015 at 10:40 Jason Penton jason.penton@gmail.com wrote:
Hey Daniel,
can't remember but I am going to test it out just now. Will have feedback soon
On Fri, 20 Mar 2015 at 10:28 Daniel-Constantin Mierla miconda@gmail.com wrote:
Hi Jason,
thinking more about it, maybe the replies higher than 500 were not forwarded, given the algorithm to select the winning reply. Can you remember more specifics from the case that made you let the suspended branch open?
Cheers, Daniel
On 20/03/15 09:07, Daniel-Constantin Mierla wrote:
Hi Jason,
a t_relay() creates a new branch, so the replies should be routed properly.
Maybe there is something that needs to be fixed for picked branch selection.
Cheers, Daniel
On 20/03/15 08:58, Jason Penton wrote:
Hey Daniel,
I added this code. My reasoning was because if you set the blind uac to 500, for some reason replies were not being forwarded after the t_relay (pick branch was failing IIRC) run some tests and get back to you. If I can restore I shall do so.
Is that ok?
Cheers Jason
On Fri, 20 Mar 2015 at 09:47 Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello Richard,
with the commit 16e763c32d7a2b9fc451185e028a90b3be758f65 you removed the setting of last_received code for the branch used for suspending the transaction (blind uac).
You added some comments:
/*we really don't need this next line anymoreotherwise we will
never be able to forward replies after a(t_relay) on this branch.
We want to try and treat this branch as 'normal'(as if it were a normal req, not async)' */
//t->uac[branch].last_received=500;But a t_relay() will create a new uac/branch, not reusing it.
Do you have some specific use cases reusing that suspended branch? If not, then I will revert the above change and set the last_received to make the branch inactive. If yes, we have to identify the case and set the last received for the rest.
On a report from Alex Balashov with a crash, the suspended branch is picked for handling cancel and apparently messes some stuff. There is another active branch due to a t_relay() after t_continue().
Cheers, Daniel
-- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://www.kamailioworld.com
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://www.kamailioworld.com
-- Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://www.kamailioworld.com