[OpenSIPS-Devel] Can't get 2.3 running with voiptests properly
Bogdan-Andrei Iancu
bogdan at opensips.org
Mon Aug 21 09:29:48 EDT 2017
Hi MAxim,
Could you validate this fix:
https://github.com/OpenSIPS/opensips/commit/4aa5fb91a0a8b06d886ef3f2a093c8f5526aaa4a
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
OpenSIPS Bootcamp 2017, Houston, US
http://opensips.org/training/OpenSIPS_Bootcamp_2017.html
On 08/21/2017 01:16 PM, Bogdan-Andrei Iancu wrote:
> Hi Maxim,
>
> Sorry for the delay, finally back on tracks after ClueCon,
>
> And thank you for your latest data (especially for the "trap" output)
> - I have a good lead on what might be the problem. Expect the fix soon.
>
> Best regards,
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developer
> http://www.opensips-solutions.com
>
> OpenSIPS Bootcamp 2017, Houston, US
> http://opensips.org/training/OpenSIPS_Bootcamp_2017.html
> On 08/19/2017 01:39 AM, Maxim Sobolev wrote:
>> Hi Bogdan, any luck looking into this issue? Looks like a serious
>> problem with 2.3 / master to me. Backing out the commit in question
>> fixes it for us.
>>
>> -Max
>>
>> On Mon, Aug 7, 2017 at 12:09 PM, Maxim Sobolev <sobomax at sippysoft.com
>> <mailto:sobomax at sippysoft.com>> wrote:
>>
>> Bogdan, I've collected some "opensipsctl trap" output here for
>> you, see line 2611 onwards:
>>
>> https://travis-ci.org/sippy/voiptests/jobs/261951017
>> <https://travis-ci.org/sippy/voiptests/jobs/261951017>
>>
>> This is 10 seconds after starting the test, CANCELs arrive at
>> about 2-3s mark, so it's well into "dead zone". Yet, I see some
>> CANCEL messages in the traces, so it looks like some locking
>> issue indeed.
>>
>> Please let me know if it helps or if you need any more debug. For
>> the time being, I am successfully running with 2.3 and master by
>> reverting change 1eb4ec0f78f43f6ff546de49bc72e513876fb86b
>>
>> -Max
>>
>> On Wed, Aug 2, 2017 at 8:03 AM, Bogdan-Andrei Iancu
>> <bogdan at opensips.org <mailto:bogdan at opensips.org>> wrote:
>>
>> Thank you Maxim for your troubleshooting.
>>
>> If you say this code makes a difference in your test, I have
>> the say that the newly added locking may do the "blocking" .
>> To see if this is true, while OpenSIPS is "blocked" could you
>> run several times the "opensipsctl trap" ?
>>
>> Best regards,
>>
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developer
>> http://www.opensips-solutions.com
>> <http://www.opensips-solutions.com>
>>
>> OpenSIPS Bootcamp 2017, Houston, US
>> http://opensips.org/training/OpenSIPS_Bootcamp_2017.html
>> <http://opensips.org/training/OpenSIPS_Bootcamp_2017.html>
>>
>> On 08/02/2017 03:59 AM, Maxim Sobolev wrote:
>>> Hi Bogdan & Co, I think I've narrowed down failure to a
>>> specific revision in the 2.3 branch, see
>>> https://travis-ci.org/sippy/voiptests/builds/260009545
>>> <https://travis-ci.org/sippy/voiptests/builds/260009545>:
>>>
>>> commit 1eb4ec0f78f43f6ff546de49bc72e513876fb86b
>>> Author: Bogdan-Andrei Iancu <bogdan at opensips.org
>>> <mailto:bogdan at opensips.org>>
>>> Date: Thu Mar 9 15:37:01 2017 +0200
>>>
>>> Added support for dynamic branch manipulation
>>>
>>> New functions were added to allow remote injecting of
>>> new branches into an ongoing transaction:
>>> * t_inject_branches(source, flags) - injects new branches;
>>> * t_wait_for_new_branches() - instruct transaction to
>>> wait more for possible new injections.
>>>
>>> Looking at the diff in question, the following piece of code
>>> looks suspicious, but it might be something else from that
>>> change:
>>>
>>> @@ -1244,7 +1301,18 @@ inline static int w_t_relay( struct
>>> sip_msg *p_msg , char *proxy, char *flags)
>>>
>>> update_cloned_msg_from_msg( t->uas.request, p_msg);
>>>
>>> - ret = t_forward_nonack( t, p_msg, p);
>>> + if (route_type==FAILURE_ROUTE) {
>>> + /* If called from failure route we
>>> need reset the branch counter to
>>> + * ignore the previous set of
>>> branches (already terminated) */
>>> + ret = t_forward_nonack( t, p_msg, p,
>>> 1/*reset*/);
>>> + } else {
>>> + /* if called from request route and
>>> the transaction was previously
>>> + * created, better lock here to
>>> avoid any overlapping with
>>> + * branch injection from other
>>> processes */
>>> + LOCK_REPLIES(t);
>>> + ret = t_forward_nonack( t, p_msg, p,
>>> 1/*reset*/);
>>> + UNLOCK_REPLIES(t);
>>> + }
>>> if (ret<=0 ) {
>>> LM_ERR("t_forward_nonack failed\n");
>>> ret = t_relay_inerr2scripterr();
>>> @@ -1262,7 +1330,8 @@ route_err:
>>>
>>> The revisions right before that work, none after does.
>>> Hopefully it will give you some clues. Let me know if any
>>> other info is needed.
>>>
>>> -Max
>>
>>
>>
>>
>> --
>> Maksym Sobolyev
>> Sippy Software, Inc.
>> Internet Telephony (VoIP) Experts
>> Tel (Canada): +1-778-783-0474 <tel:%28778%29%20783-0474>
>> Tel (Toll-Free): +1-855-747-7779 <tel:%28855%29%20747-7779>
>> Fax: +1-866-857-6942 <tel:%28866%29%20857-6942>
>> Web: http://www.sippysoft.com
>> MSN: sales at sippysoft.com <mailto:sales at sippysoft.com>
>> Skype: SippySoft
>>
>>
>>
>>
>> --
>> Maksym Sobolyev
>> Sippy Software, Inc.
>> Internet Telephony (VoIP) Experts
>> Tel (Canada): +1-778-783-0474
>> Tel (Toll-Free): +1-855-747-7779
>> Fax: +1-866-857-6942
>> Web: http://www.sippysoft.com
>> MSN: sales at sippysoft.com <mailto:sales at sippysoft.com>
>> Skype: SippySoft
>
>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20170821/ed18f90e/attachment-0001.html>
More information about the Devel
mailing list