<div dir="ltr"><div><div><div><div>I have another question on the same, even if use the media-proxy or not, i assume that DTLS message retransmissions need to be handled.<br></div>I would like some pointers on how can we handle retransmissions in asterisk.<br>
</div>P.S: I am not an expert on openssl library, so don't know much about how it functions internally.<br><br></div>Regards,<br></div>Nitesh<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jan 27, 2014 at 4:17 PM, Nitesh Bansal <span dir="ltr"><<a href="mailto:nitesh.bansal@gmail.com" target="_blank">nitesh.bansal@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div>Hello everyone,<br><br></div>Contining on the DTLS-SRTP, i need asterisk to be able to retry DTLS handshake in case there is no response from the peer for the first attempted handshake.<br>

</div>This is happening in case i use the media-proxy with asterisk, media-proxy is sending DTLS data before completing the ICE handshake, so DTLS messages are being <br>sent to an ICE candidate which is different from final selected ice candidate. In this case, i would like asterisk to attempt the DTLS handshake after a specific timeout?<br>

</div>Any pointers on how this can be done ( i can think of scheduling a timer) ?<br></div><div>P.S: With media-proxy, asterisk sees the de-iced SDP, media-proxy is handling the ICE handshake on its own.<br></div><div><br>

</div>Regards,<br></div>Nitesh Bansal<br><div><div><div><br></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On Fri, Jan 24, 2014 at 4:22 PM, Daniel Pocock <span dir="ltr"><<a href="mailto:daniel@pocock.com.au" target="_blank">daniel@pocock.com.au</a>></span> wrote:<br>

</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><div>
    <div>On 24/01/14 10:59, Lorenzo Miniero
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">Hi Daniel,
        <div><br>
        </div>
        <div>the "sha-2" error can be easily circumvented, and the
          dtlsverify=no needs an additional callback in the code to
          always return a success. Nitesh and I provided some patches
          here:</div>
        <div><br>
        </div>
        <div><a href="https://issues.asterisk.org/jira/browse/ASTERISK-22961" target="_blank">https://issues.asterisk.org/jira/browse/ASTERISK-22961</a><br>
        </div>
        <div><br>
        </div>
        <div>Mine was specifically targeted at getting Firefox to work,
          but I only tested incoming calls. I didn't test Nitesh's one,
          but apparently he managed to get it to work as well.</div>
        <div><br>
        </div>
      </div>
    </blockquote>
    <br></div>
    Thanks for this, I've tested with it<br>
    <br>
    Two things were necessary for success with Firefox:<br>
    a) I applied Nitish's patch to the latest 11.7 from Debian (it is on
    a branch dtls-srtp-patch), it builds on wheezy and appears to work<br>
<a href="http://anonscm.debian.org/gitweb/?p=pkg-voip/asterisk.git;a=shortlog;h=refs/heads/dtls-srtp-patch" target="_blank">http://anonscm.debian.org/gitweb/?p=pkg-voip/asterisk.git;a=shortlog;h=refs/heads/dtls-srtp-patch</a><br>


    Anybody wanting to test can clone from there and then<br>
      dpkg-buildpackage -rfakeroot -i.git <br>
    to build packages with the change.  This has not been uploaded in
    any official packages, I let the package maintainers decide if they
    want to support the patch.<br>
    <br>
    b) I had to work around the issue with the media descriptor protocol
    sub-field.  In JSCommunicator (using the branch "develop" from
    JsSIP), I look at the field in the outgoing and incoming INVITE and
    change it to/from the Asterisk format:<br>
<a href="https://github.com/opentelecoms-org/jscommunicator/commit/6980f8e1c3311c46154b3840d695f0ddc9c8c8ae" target="_blank">https://github.com/opentelecoms-org/jscommunicator/commit/6980f8e1c3311c46154b3840d695f0ddc9c8c8ae</a><br>


    <br>
    It can now be tested with the links at
    <a href="http://www.sip5060.net/test-calls" target="_blank">http://www.sip5060.net/test-calls</a> and/or from
    <a href="http://www.lumicall.org/drucall" target="_blank">http://www.lumicall.org/drucall</a> - both now appear to work from
    Firefox and it appears to maintain compatibility for calls between
    JSCommunicator users.<br>
    <br>
    However, I'd like to understand if I really should have the
    patch/hack in JSCommunicator at all - should Asterisk be willing to
    accept SDP specifying "RTP/SAVPF" alone?  If so, then I can cut out
    half the JSCommunicator patch.<br>
    <br>
    <br>
    <br>
    <br>
  </div>

<br></div></div><div class="im">--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
   <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br></div></blockquote></div><br></div>
</blockquote></div><br></div>