<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <br>
    <blockquote type="cite"
      cite="mid:13597221-c280-575d-274c-c563b7056a53@gmail.com">
      <p>I was part of the team that starting a large scale sip
        migration almost 10 years ago.  Have moved thousand's of DID
        since then.  Run multiple gig circuits into the cube.</p>
      <p>Recommendations:</p>
      <p>on the link to your provider, use address outside of the route
        able block for your company.  (say you use 10.x.x.x  then use
        172.16 or 192.168)      If you can, don't route the itsp
        connections on your company network, go direct to the routers
        supporting those links.  (BGP peers I would guess depending on
        carrier/build)   If you can use a dedicated router, unless is a
        small site....  This is important if you wind up doing any kind
        of call recording, or if you have to enable debugs during the
        day.</p>
      <p>Use dedicated dial peers setup exactly for each itsp SBC link 
        for in and one for out.</p>
      <p>Use something like the "voice class uri trunk(x) sip"  or
        equivalent to bind to the dial peers for each SBC.</p>
      <p>    This will help if you have to add additional carriers, or
        say acquire a company, or need to do special routing...<br>
      </p>
      <p>use full E164 to and from the carrier, they may only want to do
        10 digit in/out, but that is easy enough.  (uri trunkx will help
        here, as the inbound number will be at the cube, then you can
        route to cucm with outbound dial peer)<br>
      </p>
      <div class="moz-cite-prefix">From your CUCM still send the 9 or 8
        or whatever for outbound, then strip on match in the dialpeer to
        Itsp.   This will keep call looping etc.  <br>
      </div>
      <div class="moz-cite-prefix"><br>
      </div>
      <div class="moz-cite-prefix">define your voice class codecs on the
        dialpeers... don't just assume it will take the default, or work
        as you want without it.<br>
      </div>
      <div class="moz-cite-prefix"><br>
      </div>
      <div class="moz-cite-prefix">if the cube will never see VIDEO,
        disable the options.  The cube software likes to release bugs
        that cause the cube to go south with video errors.<br>
      </div>
      <div class="moz-cite-prefix"><br>
      </div>
      <div class="moz-cite-prefix">Depending on your carrier, you may
        need to force G729 or G711 first, even if its not your preferred
        codec, have seen were the SBC will not negotiate a call, if the
        codecs aren't in the order the carriers SBC wants.</div>
      <div class="moz-cite-prefix"><br>
      </div>
      <div class="moz-cite-prefix">do not assume the carriers network
        will normalize the calls.  For instance, if the destination is
        on the same carrier, its a direct ip route via the SBC.  If that
        end side can't accept say G729 (cheaper sbc)  the call will just
        fail.<br>
      </div>
      <div class="moz-cite-prefix"><br>
      </div>
      <div class="moz-cite-prefix">NEVER user debug ccsip all</div>
      <div class="moz-cite-prefix">    debug CCSIP messages is safer,
        and unless your cube is peeked, it won't add to much cpu.</div>
      <div class="moz-cite-prefix"><br>
      </div>
      <div class="moz-cite-prefix">make sure your CPU never exceeds 80%
        at the max possible peek of routing.<br>
      </div>
      <div class="moz-cite-prefix"><br>
      </div>
      <div class="moz-cite-prefix">Check how the calls work with MOH.  
        Inbound and out.  make sure 2 way audio remains after the on
        hold event..</div>
      <div class="moz-cite-prefix"><br>
      </div>
      <div class="moz-cite-prefix">Do you need to force early offer?  
        (yes sounds silly, but have run into issues where some phones
        had no audio unless this was set)<br>
      </div>
      <div class="moz-cite-prefix"><br>
      </div>
      <div class="moz-cite-prefix">Ask your carrier, how they handle
        TFNs outbound, if you pass the ANI from a 3rd party. (this is
        all billing stuff to the TFN owner)   <br>
      </div>
      <div class="moz-cite-prefix">    Some may allow calls to process
        not caring what the number is.</div>
      <div class="moz-cite-prefix">    Some may allow you to provide a
        alternate billing number.<br>
      </div>
      <div class="moz-cite-prefix">    Some will just  603 decline the
        call if the ANI isn't in your number poll assigned to you. <br>
      </div>
      <div class="moz-cite-prefix">        with a 603 the cube will try
        the next dial peer so you can add a header to re-write this with
        your number.....</div>
      <div class="moz-cite-prefix"><br>
      </div>
      <div class="moz-cite-prefix">Diversion headers exist, however most
        carriers pass them through to the destination, and IVRs or Voice
        Mail systems on the far side will try to process that
        information, and do unexpected things.  (the party your calling
        doesn't exist for example.)<br>
      </div>
      <div class="moz-cite-prefix"><br>
      </div>
      <div class="moz-cite-prefix">define the default sip control/media
        source interface, this will be your destination from cucm.   The
        URI trucks will define the sip control/media on the ITSP side.</div>
      <div class="moz-cite-prefix"><br>
      </div>
      <div class="moz-cite-prefix">If you use firewalls any where in
        your company, that will pass voip...   Set the rtp-port range on
        the cube match the smaller range of what your going to use. 
        (say the old days 16384-32767) don't assume the firewall will
        pass all the UDP ports by default.</div>
      <div class="moz-cite-prefix"><br>
      </div>
      <div class="moz-cite-prefix">speaking of firewalls, check, double
        check, and triple check, then do your own research if you will
        use them, when it comes to SIP inspection.   Some FW's have
        options that need to be tweeked and defined, for the SIP port.  
        (this may control anything from timeouts, which media ports
        engage)    This is especially true with expressway in the DMZ.  
        It might be safer to not use sip inspection and just pass the
        port.  But for some FWs this is not true.  <br>
      </div>
      <div class="moz-cite-prefix"><br>
      </div>
      <div class="moz-cite-prefix">define the FAX-relay, rats and
        protocols for T38</div>
      <div class="moz-cite-prefix"><br>
      </div>
      <div class="moz-cite-prefix">ask your carrier how they handle
        QOS.  some don't since the trunk to them might be dedicated.</div>
      <div class="moz-cite-prefix"><br>
      </div>
      <div class="moz-cite-prefix">use option pings on the dial peers,
        so if the SBC goes away that dialpeer disables.  The sbc side
        just has to respond, even if its an error saying what is this...
        that will keep the peer up.</div>
      <div class="moz-cite-prefix"><br>
      </div>
      <div class="moz-cite-prefix">Setup the event manager applet.  have
        it email you on syslog patterns for dialpeer status.  Then you
        will know if the link goes down.</div>
      <div class="moz-cite-prefix"><br>
      </div>
      <div class="moz-cite-prefix">if you can get a bug scrub on the
        version of IOS, don't be determined to use the newest code. 
        newest is not always best.<br>
      </div>
      <div class="moz-cite-prefix"><br>
      </div>
      <div class="moz-cite-prefix">Hope at least one thing here was
        helpful.</div>
      <div class="moz-cite-prefix"><br>
      </div>
      <div class="moz-cite-prefix"><br>
      </div>
      <div class="moz-cite-prefix"><br>
      </div>
      <div class="moz-cite-prefix"><br>
      </div>
      <div class="moz-cite-prefix"><br>
      </div>
      <div class="moz-cite-prefix">On 2/10/22 9:09 AM, Matthew Huff
        wrote:<br>
      </div>
      <blockquote type="cite"
        cite="mid:6e3a800d480346c9895bc2c5fced7b41@ox.com">
        <meta http-equiv="Content-Type" content="text/html;
          charset=UTF-8">
        <meta name="Generator" content="Microsoft Word 15 (filtered
          medium)">
        <style>@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}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:#0563C1;
        text-decoration:underline;}a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:#954F72;
        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;}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">We are in the process of migrating for a
            legacy PTSN voice gateway (PRI) to a new CUBE based SIP
            connection to a iTSP connected via a private metro ethernet
            (not Internet based). Does anyone have a good source for
            recipes / dial-plans recommendations / best practices for
            this?<o:p></o:p></p>
          <p class="MsoNormal"><o:p> </o:p></p>
          <p class="MsoNormal"><o:p> </o:p></p>
          <p class="MsoNormal"><o:p> </o:p></p>
          <p class="MsoNormal"><b><span
                style="font-family:"Arial",sans-serif;color:#1F497D"
                lang="EN-GB">Matthew Huff</span></b><span
              style="font-family:"Arial",sans-serif;color:#1F497D"
              lang="EN-GB"> | Director of Technical Operations | OTA
              Management LLC<o:p></o:p></span></p>
          <p class="MsoNormal"><span
style="font-size:4.0pt;font-family:"Arial",sans-serif;color:#1F497D"
              lang="EN-AU"><o:p> </o:p></span></p>
          <p class="MsoNormal"><i><span
                style="font-family:"Arial",sans-serif;color:#1F497D"
                lang="EN-GB">Office: 914-460-4039<o:p></o:p></span></i></p>
          <p class="MsoNormal"><i><span
                style="font-family:"Arial",sans-serif;color:#1F497D"
                lang="EN-GB"><a href="mailto:mhuff@ox.com"
                  moz-do-not-send="true"><span style="color:#0563C1">mhuff@ox.com</span></a>
                | </span></i><i><span
                style="font-family:"Arial",sans-serif"
                lang="EN-GB"><a href="http://www.ox.com"
                  moz-do-not-send="true"><span style="color:#0563C1">www.ox.com</span></a><span
                  style="color:#1F497D"><o:p></o:p></span></span></i></p>
          <p class="MsoNormal"><b><span
style="font-size:7.5pt;font-family:"Arial",sans-serif;color:gray">...........................................................................................................................................<o:p></o:p></span></b></p>
          <p class="MsoNormal"><o:p> </o:p></p>
        </div>
        <br>
        <fieldset class="moz-mime-attachment-header"></fieldset>
        <pre class="moz-quote-pre" wrap="">_______________________________________________
cisco-voip mailing list
<a class="moz-txt-link-abbreviated moz-txt-link-freetext" href="mailto:cisco-voip@puck.nether.net" moz-do-not-send="true">cisco-voip@puck.nether.net</a>
<a class="moz-txt-link-freetext" href="https://puck.nether.net/mailman/listinfo/cisco-voip" moz-do-not-send="true">https://puck.nether.net/mailman/listinfo/cisco-voip</a>
</pre>
      </blockquote>
    </blockquote>
  </body>
</html>