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.pen...@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.pen...@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 <mico...@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 <mico...@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 anymore >>>> otherwise 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 >>> >>>
_______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
