<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>5 sep 2013 kl. 17:22 skrev Alex Villací­s Lasso &lt;<a href="mailto:a_villacis@palosanto.com">a_villacis@palosanto.com</a>&gt;:</div><br class="Apple-interchange-newline"><blockquote type="cite">
  
    <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
  
  <div text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">El 05/09/13 03:57, Olle E. Johansson
      escribió:<br>
    </div>
    <blockquote cite="mid:73624C63-C171-4D11-A264-BC65A2784610@edvina.net" type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <a moz-do-not-send="true" href="https://issues.asterisk.org/jira/browse/ASTERISK-17899">https://issues.asterisk.org/jira/browse/ASTERISK-17899</a>
      <div><br>
      </div>
      <div>
        <div apple-content-edited="true"><span class="Apple-style-span" style="border-collapse: separate; font-size: 12px;
            border-spacing: 0px; ">
            <div>I've done a lot of research about this and find a
              worrysome amount of pages where people explain that this
              is a bug in Asterisk and a few different patches floating
              around. That's not a good situation. It does break
              communication in a customer platform I'm working with.</div>
            <div><br>
            </div>
            <div>The story is this:</div>
            <div><br>
            </div>
            <div>In SDES we send master crypto keys in clear text (don't
              laugh, please). The keys can have attributes for the
              lifetime - number of packets we can use this key for - and
              a master key index. In asterisk, if someone sends us this
              attribute which quite a lot of servers and phones seems to
              do, we break the call and do not accept - even if the
              lifetime is 2^31 packets which is quite a long call,
              spanning decades, with a rate of 50 packets per second.</div>
            <div><br>
            </div>
            <div>We do not have to answer with any attributes on our
              key. The key attributes are just declarative, not an
              offer/answer item.</div>
            <div><br>
            </div>
          </span>
          <div style="font-size: 12px; ">I consider this a bug that we
            need to fix in all release versions. There's a correct way
            of solving it - using packet counters and forcing a
            re-invite and a key reset beforehand or a quick and dirty
            where we accept all lifetimes above a treshold, like 2^20
            and assume no calls will be that long or that if they are,
            the other end will start a key reset.</div>
          <div style="font-size: 12px; "><br>
          </div>
        </div>
        My questions to the esteemed reader of this list:</div>
      <div>- can we agree that the current behaviour is a bug?</div>
      <div>- which solution should we code for?</div>
      <br>
    </blockquote>
    If I understand correctly, the SRTP lifetime is the same issue
    covered in <a class="moz-txt-link-freetext" href="https://issues.asterisk.org/jira/browse/ASTERISK-20233">https://issues.asterisk.org/jira/browse/ASTERISK-20233</a> ,
    and that bug was closed as "Not A Bug", since this was a "feature
    request" and therefore better discussed in the mailing list.<br>
  </div></blockquote>THere are a lot of bug reports in the tracker related to this, but since 17899 is the lowest number I can find, I started with that.</div><div><br></div><div>And yes, this is the mailing list, so feel free to discuss now! The floor is open!</div><div><br></div><div>/O</div><br></body></html>