<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<p>First off. if your cube is working and in production, don't just
disable video... you might be in for a surprise. It should be
done in a test window time where you can test phones/all software.<br>
</p>
<p><br>
</p>
<p>Jabber/webex supports video, are you using those? does your
carrier use/support it? Do they charge extra if you send them a
video call? (things to ponder)<br>
</p>
<p><br>
</p>
<p>This is a tricky one, and does, but does not have an easy
answer....</p>
<br>
First thing I would do is make sure the Retry Video Call as Audio
check box is (still) checked on your trunk.... (believe this is
default...)<br>
<p>On the cube:<br>
</p>
Cisco has a doc that calls out video suppression, two ways:<br>
globally (IOS release dependent, later releases (15.62T and
16.3.1)<br>
voice service voip<br>
sip<br>
audio forced <br>
<br>
dial-peer level<br>
voice-class sip audio forced<br>
<p><br>
</p>
<p>That was the easy side. You should be golden here....<br>
</p>
<p>But....<br>
</p>
<p>remember, your carrier may not like this..., so you might have to
look at sip-profiles instead. Use these to modify the data
in/out on the dial-peer to make your carrier happy, if you get 488
errors back. (or others) you might need the carriers help to
understand what the don't like.... (There is all kinds of SBC's
out there...) Most carriers do have decent equipment monitoring
there links, so you can always call them and ask, why are you
rejecting my call.... BUT keep in mind, the carriers don't
always have people trained in the area you need to help with this,
so asking them for a detailed SIP trace might be the best idea,
and call TAC for their thoughts on how to resolve.</p>
<p><br>
</p>
<p>sorry not exactly a straight answer, but if your not live yet, it
will be very easy to make happen..</p>
<p><br>
</p>
<p> </p>
<br>
<div class="moz-cite-prefix">On 2/11/22 8:52 AM, Matthew Huff wrote:<br>
</div>
<blockquote type="cite"
cite="mid:82314fb6d2e144ccab67d18efbd44454@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;}@font-face
{font-family:Consolas;
panose-1:2 11 6 9 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;}pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}span.EmailStyle22
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}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">Thanks for the recommendations. I have a
lot to dig into. Question about the video disable. We have no
video hardware, so think it would be good to disable it
before we go live. What’s the best way to disable it globally?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Is it <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Voice service voip<o:p></o:p></p>
<p class="MsoNormal"> Sip<o:p></o:p></p>
<p class="MsoNormal"> Audio forced<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>
<div>
<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" class="moz-txt-link-freetext">mhuff@ox.com</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">www.ox.com</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>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Kent Roberts
<a class="moz-txt-link-rfc2396E" href="mailto:dvxkid@gmail.com"><dvxkid@gmail.com></a> <br>
<b>Sent:</b> Thursday, February 10, 2022 6:14 PM<br>
<b>To:</b> Matthew Huff <a class="moz-txt-link-rfc2396E" href="mailto:mhuff@ox.com"><mhuff@ox.com></a>;
<a class="moz-txt-link-abbreviated" href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
<b>Subject:</b> Re: [cisco-voip] SIP to iTSP best
practices<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<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.<o:p></o:p></p>
<p>Recommendations:<o:p></o:p></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.<o:p></o:p></p>
<p>Use dedicated dial peers setup exactly for each itsp SBC
link for in and one for out.<o:p></o:p></p>
<p>Use something like the "voice class uri trunk(x) sip" or
equivalent to bind to the dial peers for each SBC.<o:p></o:p></p>
<p> This will help if you have to add additional carriers,
or say acquire a company, or need to do special routing...<o:p></o:p></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)<o:p></o:p></p>
<div>
<p class="MsoNormal">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.
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">define your voice class codecs on the
dialpeers... don't just assume it will take the default,
or work as you want without it.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">NEVER user debug ccsip all<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> debug CCSIP messages is safer, and
unless your cube is peeked, it won't add to much cpu.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">make sure your CPU never exceeds 80% at
the max possible peek of routing.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Check how the calls work with MOH.
Inbound and out. make sure 2 way audio remains after the
on hold event..<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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)
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> Some may allow calls to process not
caring what the number is.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> Some may allow you to provide a
alternate billing number.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> Some will just 603 decline the
call if the ANI isn't in your number poll assigned to you.
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> with a 603 the cube will try
the next dial peer so you can add a header to re-write
this with your number.....<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">define the FAX-relay, rats and
protocols for T38<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">ask your carrier how they handle QOS.
some don't since the trunk to them might be dedicated.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Setup the event manager applet. have
it email you on syslog patterns for dialpeer status. Then
you will know if the link goes down.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Hope at least one thing here was
helpful.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">On 2/10/22 9:09 AM, Matthew Huff wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<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</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:4.0pt;font-family:"Arial",sans-serif;color:#1F497D"
lang="EN-AU"> </span><o:p></o:p></p>
<p class="MsoNormal"><i><span
style="font-family:"Arial",sans-serif;color:#1F497D"
lang="EN-GB">Office: 914-460-4039</span></i><o:p></o:p></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" class="moz-txt-link-freetext">mhuff@ox.com</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">www.ox.com</a></span></i><o:p></o:p></p>
<p class="MsoNormal"><b><span
style="font-size:7.5pt;font-family:"Arial",sans-serif;color:gray">...........................................................................................................................................</span></b><o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<pre>_______________________________________________<o:p></o:p></pre>
<pre>cisco-voip mailing list<o:p></o:p></pre>
<pre><a href="mailto:cisco-voip@puck.nether.net" moz-do-not-send="true" class="moz-txt-link-freetext">cisco-voip@puck.nether.net</a><o:p></o:p></pre>
<pre><a href="https://puck.nether.net/mailman/listinfo/cisco-voip" moz-do-not-send="true" class="moz-txt-link-freetext">https://puck.nether.net/mailman/listinfo/cisco-voip</a><o:p></o:p></pre>
</blockquote>
</blockquote>
</div>
</blockquote>
</body>
</html>