[sr-dev] Suspended branch still active

[Jason Penton]

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 at 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 at 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 at 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 at 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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20150320/1b94fe19/attachment.html>