Re: [asterisk-dev] Idle Timers and Keep-Alives

[Ludovic Gasc]

2018-01-26 12:39 GMT+01:00 Alexander Traud :

> > You'd be OK with keeping an idle timeout it as long as you can turn
> > it off at runtime.
>
> Yes, I do not need it.
>
> I do not use keep-alive for SIP-over-TCP (or TLS), neither
> - within the TCP layer (via its own mechanism), nor
> - on the TCP layer (via CRLN).
> Even short SIP-Register must be used carefully as explained by the author
> of Zoiper:  and .
> Although the videos are 2 x 45 minutes long, I recommend them, to
> understand the frustrations of us mobile VoIPers.
>

>From my experience, tcp keepalive is complementary with OPTIONS, because
some routers can close silently a TCP connection without data, even if the
tcp keep-alive is enabled.
I have found an issue in Chromium about that:
https://bugs.chromium.org/p/chromium/issues/detail?id=27400
Moreover, in this article:
https://blog.stephencleary.com/2009/05/detection-of-half-open-dropped.html
The paragraph "Manipulate the TCP/IP keepalive packet settings" tries to
explain the advantages and problems.

As explained on: http://blogs.asterisk.org/2018/01/27/wanted-dead-or-alive/
TCP keep-alive should help to decrease the frequency of OPTIONS, but it
needs to be measured on a production environment to be sure.
When the new release of Asterisk will be ready with these changes, we will
do some tests.


> > At what level of granularity would it need to be?
> > System, transport, endpoint?
>
> System, in my case.
>

Theoretically, endpoint level is the best in term of customization :-)
Nevertheless, in this specific use case, I think we will also use system
level: We have also permanent connections with WebSockets not related with
Asterisk from our customers, we will put a value that we will work on any
TCP connection between them and us.

Have a nice week.
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Jira: Create issue: Required field: Component

[Joshua Colp]

On Sun, Jan 28, 2018, at 7:59 AM, Joshua Colp wrote:
> On Sun, Jan 28, 2018, at 5:00 AM, Alexander Traud wrote:
> > In Jira, when I create a new issue, the fields Summary and Description 
> > are marked with a red asterisk. I guess, that indicates a required 
> > field. However, for an external contributor like me, the fields 
> > Component, Affects Version, Severity, and Issue Guidelines are required 
> > as well. This is inconsistent usage of this red asterisk and therefore 
> > confusing.
> > 
> > What about
> > A) asterisk the remaining required fields as well or
> > B) if there are several user groups with different required fields, what 
> > about removing the existing two asterisks?
> 
> The red asterisk is from JIRA itself and indicates it is a required 
> field for it to work. There's no way that I found to mark the other 
> fields as required to make them appear like the JIRA ones. Instead they 
> use a validator in JIRA which runs before the issue is created to verify 
> they exist. I can't add my own non-red asterisk either because 
> Components is a JIRA field, not a custom field that can be edited.
> 
> They either have to be as they are now, or they aren't required. So far 
> I haven't seen any complaints across the various places about it and the 
> quality of issue reports has actually gone up as a result (generally the 
> only back and forth now seems to be to get backtraces, config 
> information, or environment information).

Actually I was able to find the right stuff in JIRA to make them marked the 
same way. This is now done!

-- 
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Jira: Create issue: Required field: Component

[Joshua Colp]

On Sun, Jan 28, 2018, at 5:00 AM, Alexander Traud wrote:
> In Jira, when I create a new issue, the fields Summary and Description 
> are marked with a red asterisk. I guess, that indicates a required 
> field. However, for an external contributor like me, the fields 
> Component, Affects Version, Severity, and Issue Guidelines are required 
> as well. This is inconsistent usage of this red asterisk and therefore 
> confusing.
> 
> What about
> A) asterisk the remaining required fields as well or
> B) if there are several user groups with different required fields, what 
> about removing the existing two asterisks?

The red asterisk is from JIRA itself and indicates it is a required field for 
it to work. There's no way that I found to mark the other fields as required to 
make them appear like the JIRA ones. Instead they use a validator in JIRA which 
runs before the issue is created to verify they exist. I can't add my own 
non-red asterisk either because Components is a JIRA field, not a custom field 
that can be edited.

They either have to be as they are now, or they aren't required. So far I 
haven't seen any complaints across the various places about it and the quality 
of issue reports has actually gone up as a result (generally the only back and 
forth now seems to be to get backtraces, config information, or environment 
information).

-- 
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] Jira: Create issue: Required field: Component

[Alexander Traud]

In Jira, when I create a new issue, the fields Summary and Description are 
marked with a red asterisk. I guess, that indicates a required field. However, 
for an external contributor like me, the fields Component, Affects Version, 
Severity, and Issue Guidelines are required as well. This is inconsistent usage 
of this red asterisk and therefore confusing.

What about
A) asterisk the remaining required fields as well or
B) if there are several user groups with different required fields, what about 
removing the existing two asterisks?



-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev