<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Ditto. We have gone down this path but a few things to be aware of
    we have learned. <br>
    <br>
    1: When switching from UDP to TCP for sip you introduce a failure
    point on the access side (tcp session). Devices that are rebooted
    etc will begin a new TCP session and thus create a new registration.
    If you are using a forking proxy this will create an additional
    registration orphaning the previous. Depending on your network
    config rapid reboots of CPE can have subscribers hitting a cap on
    concurrent registrations where under UDP, after reboots they would
    have resumed the existing one since there wasnt session state to
    deal with. <br>
    <br>
    2: You can almost as effectively hide the sip traffic by using
    different ports (this also prevents your endpoints from getting
    slammed regularly by sipvicious)<br>
    <br>
    <div class="moz-cite-prefix">On 11/21/2013 10:15 AM, Paul Timmins
      wrote:<br>
    </div>
    <blockquote cite="mid:1385057720161596500@timmins.net" type="cite">
      <style id="axi-htmleditor-style" type="text/css">p { margin: 0px; }</style>I
      keep wanting to just deploy SIP/TLS and SRTP for this. You can't
      SIP ALG what you can't see.<br>
      <br>
      On Thu, 11/21/2013 12:55 PM, Matt Yaklin <a class="moz-txt-link-rfc2396E" href="mailto:myaklin@g4.net"><myaklin@g4.net></a>
      wrote:<br>
      <blockquote style="border-left: 2px solid rgb(00, 00, 204);
        padding-left: 4px; margin-left: 16px;">
        <div style="font-family: Arial; font-size: 10pt;">On Thu, 21 Nov
          2013, J. Oquendo wrote:<br>
          <br>
          > On Thu, 21 Nov 2013, Matt Yaklin wrote:<br>
          ><br>
          >><br>
          >><br>
          >> Will tunneling the sip/rtp packets be more common in
          the near future<br>
          >> for SIP phone providers?<br>
          >><br>
          >> matt<br>
          >><br>
          ><br>
          >> From the ITSP side (where we provide trunks). Tunnels
          would<br>
          > be a nightmare, so they are a no-no. Now you're throwing<br>
          > in too many variables (Aggressive, Main, set ups,
          different<br>
          > equipment). Not to mention the overhead it would add to
          an<br>
          > SBC.<br>
          ><br>
          >> From the Managed PBX side of the equation... NO, but
          before<br>
          > I ramble on, define tunneling. Tunneling as in VPN? If
          the<br>
          <br>
          <br>
          <br>
          Yes, a VPN tunnel that the CPE/SBC would have to handle<br>
          and connect back to a centralized location that the SIP<br>
          provider controls. Every SIP device behind the CPE/SBC would<br>
          have to go through the CPE/SBC.<br>
          <br>
          The reason I mention it was recent SBC installs I did at<br>
          customer sites had tunnel options but I am unsure at the
          moment<br>
          if it was for site to site (full mesh setup) connectivity for<br>
          security reasons or more for getting back to the provider<br>
          for alternative reasons.<br>
          <br>
          But the more I think about it... it does add complexity<br>
          that we would all like to avoid.<br>
          <br>
          matt<br>
          <br>
          <br>
          <br>
          > concern is security, TLS is suitable from the managed PBX<br>
          > side as we can firewall trusted CIDRs on the firewall to<br>
          > prevent recording/tampering.<br>
          ><br>
          > If you meant VPN tunneling... Would only work on a
          softphone<br>
          > because I have YET to see any VoIP device (phone, ATA,
          FXO,<br>
          > FXS) have any parameters to set up a tunnel. So I am
          unsure<br>
          > how one would truly call a VoIP Tunnel in a VPN sense,
          any<br>
          > kind of true tunneling. (Tunnel in Tunnel maybe, been a<br>
          > while since I dove into CCIP/IE like material.<br>
          ><br>
          > -- <br>
          >
          =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+<br>
          > J. Oquendo<br>
          > SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM<br>
          ><br>
          > "Where ignorance is our master, there is no possibility
          of<br>
          > real peace" - Dalai Lama<br>
          ><br>
          > 42B0 5A53 6505 6638 44BB 3943 2BF7 D83F 210A 95AF<br>
          > <a moz-do-not-send="true"
href="http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2BF7D83F210A95AF"
            target="_blank">http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2BF7D83F210A95AF</a><br>
          ><br>
          _______________________________________________<br>
          VoiceOps mailing list<br>
          <a moz-do-not-send="true" href="mailto:VoiceOps@voiceops.org"
            target="_blank">VoiceOps@voiceops.org</a><br>
          <a moz-do-not-send="true"
            href="https://puck.nether.net/mailman/listinfo/voiceops"
            target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
        </div>
      </blockquote>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
VoiceOps mailing list
<a class="moz-txt-link-abbreviated" href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a>
<a class="moz-txt-link-freetext" href="https://puck.nether.net/mailman/listinfo/voiceops">https://puck.nether.net/mailman/listinfo/voiceops</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>