<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 11/12/2013 10:34 AM, Damon Estep
      wrote:<br>
    </div>
    <blockquote
cite="mid:D8C00CFC8F35644EA777C796B2F8BBA72D9007F7@mail2.platinummbi.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <meta name="Generator" content="Microsoft Word 14 (filtered
        medium)">
      <style><!--
/* Font Definitions */
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
span.EmailStyle17
        {mso-style-type:personal-compose;
        font-family:"Calibri","sans-serif";
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri","sans-serif";}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
      <div class="WordSection1">
        <p class="MsoNormal">Originally posted to <a
            moz-do-not-send="true"
            href="https://issues.asterisk.org/jira/browse/ASTERISK-22841">https://issues.asterisk.org/jira/browse/ASTERISK-22841</a><o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">Feedback was that this is more of a dev
          discussion than a bug.<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">The definition of timer t1min is "Minimum
          roundtrip time for messages to monitored hosts" the key word
          is "monitored", which means qualify= is set to yes or a
          numeric value.<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">The value of t1min is being evaluated when
          the timert1 value for a non-monitored host is read from the
          configuration and a warning is logged and timert1 is set to
          global_timert1 if the configured timert1 value for the
          non-monitored host is less than t1min.<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">t1min should not apply to non-monitored
          hosts by definition and the user should be able to set a
          timer1 value that is less than t1min for a non-monitored host.<o:p></o:p></p>
      </div>
    </blockquote>
    <br>
    I can agree with this. The intention of the t1min setting should be
    to ensure that if a monitored host has a super-short roundtrip time
    that we do not end up setting the t1 timer to something ridiculously
    low. If you want to set the default t1 timer to something lower than
    t1min for non-monitored hosts, while I think it's a bit on the
    strange side, I think it should be allowed.<br>
    <br>
    <blockquote
cite="mid:D8C00CFC8F35644EA777C796B2F8BBA72D9007F7@mail2.platinummbi.com"
      type="cite">
      <div class="WordSection1">
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">If T1 is set in the config for a monitored
          host it should be used instead of the last qualify result.<o:p></o:p></p>
      </div>
    </blockquote>
    <br>
    I'm not quite so sure on this one. I imagine there are users of
    Asterisk out there that set timer t1 to some initial "base" value
    and then expect qualifies to "correct" that value if it turns out
    the RTT is greater or less than what is expected. Ignoring RTT for
    qualifies seems like something that, if it should be done at all,
    should be optional.<br>
    <br>
    <blockquote
cite="mid:D8C00CFC8F35644EA777C796B2F8BBA72D9007F7@mail2.platinummbi.com"
      type="cite">
      <div class="WordSection1">
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">A case where this is needed is when there
          is a SBC in front of the monitored host. The SBC may answer
          the OPTIONS query directly and not pass it to the host which
          is behind the SBC. In this case the lastms is set to the RTT
          to the SBC, which is not indicative of the actual RTT for an
          INVITE which is proxied to the host (which adds additional
          delay).<o:p></o:p></p>
      </div>
    </blockquote>
    <br>
    In this particular case, wouldn't the SBC also be the first
    responder to the INVITE (with a 100 Trying)? The way Asterisk works,
    once it has received a response to a request, it will not retransmit
    the request any further.<br>
    <br>
    <blockquote
cite="mid:D8C00CFC8F35644EA777C796B2F8BBA72D9007F7@mail2.platinummbi.com"
      type="cite">
      <div class="WordSection1">
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">Setting T1 to the last measured OPTIONS RTT
          is a problematic for another reason as well. Any amount of
          jitter in the network can result in unneeded retransmits. In
          practice T1 is set to the estimated RTT which is not always
          the last RTT but rather the average RTT plus an allowance for
          network jitter. There are many reasons when a user might want
          to adjust timer T1 on a peer by peer basis. They should not be
          forced to accept a global minimum or system calculated T1
          regardless of whether qualify is on. Qualify is used in other
          ways by many users, not just as a means of setting T1.<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">The current timer configuration could be
          improved by adding a T1 jitter configuration value (in
          addition to or in place of T1min, which would be added to
          lastms to set T1. For example, if the lastms for a peer was
          40ms and the T1jitter setting was 20, then T1 would be set to
          60ms.</p>
      </div>
    </blockquote>
    <br>
    This, on the other hand, sounds like something I can agree with.
    Setting T1 to a running average plus some jitter tolerance makes
    sense to me.<br>
    <br>
    <blockquote
cite="mid:D8C00CFC8F35644EA777C796B2F8BBA72D9007F7@mail2.platinummbi.com"
      type="cite">
      <div class="WordSection1">
        <p class="MsoNormal"><o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">Comments or thoughts?<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
    </blockquote>
    <br>
  </body>
</html>