[cisco-voip] SIP to iTSP best practices

Fri Feb 11 12:14:26 EST 2022

Oh yeah.. one more thing...

Test faxing!!!!  a fax test is a min of 10 pages, inbound call and 
out.... don't just do a page and say your good.  Check T38 if your using 
it... if you have to fail back because of T38 non-compliant, is G711 
working?  Does your faxing software do/support switchback to 711 if T38 
doesn't setup.

If you have a fax machine on a ATA or whater, test to it as well.

Isn't fax dead yet?     :)   good luck with your go live.

On 2/11/22 8:52 AM, Matthew Huff wrote:
>
> 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?
>
> Is it
>
> Voice service voip
>
>   Sip
>
>      Audio forced
>
> ?
>
> *Matthew Huff*| Director of Technical Operations | OTA Management LLC
>
> /Office: 914-460-4039/
>
> /mhuff at ox.com | //www.ox.com <http://www.ox.com>/
>
> *...........................................................................................................................................*
>
> *From:* Kent Roberts <dvxkid at gmail.com>
> *Sent:* Thursday, February 10, 2022 6:14 PM
> *To:* Matthew Huff <mhuff at ox.com>; cisco-voip at puck.nether.net
> *Subject:* Re: [cisco-voip] SIP to iTSP best practices
>
>
>
>     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.
>
>     Recommendations:
>
>     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.
>
>     Use dedicated dial peers setup exactly for each itsp SBC link  for
>     in and one for out.
>
>     Use something like the "voice class uri trunk(x) sip"  or
>     equivalent to bind to the dial peers for each SBC.
>
>         This will help if you have to add additional carriers, or say
>     acquire a company, or need to do special routing...
>
>     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)
>
>     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.
>
>     define your voice class codecs on the dialpeers... don't just
>     assume it will take the default, or work as you want without it.
>
>     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.
>
>     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.
>
>     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.
>
>     NEVER user debug ccsip all
>
>         debug CCSIP messages is safer, and unless your cube is peeked,
>     it won't add to much cpu.
>
>     make sure your CPU never exceeds 80% at the max possible peek of
>     routing.
>
>     Check how the calls work with MOH. Inbound and out.  make sure 2
>     way audio remains after the on hold event..
>
>     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)
>
>     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)
>
>         Some may allow calls to process not caring what the number is.
>
>         Some may allow you to provide a alternate billing number.
>
>         Some will just  603 decline the call if the ANI isn't in your
>     number poll assigned to you.
>
>             with a 603 the cube will try the next dial peer so you can
>     add a header to re-write this with your number.....
>
>     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.)
>
>     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.
>
>     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.
>
>     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.
>
>     define the FAX-relay, rats and protocols for T38
>
>     ask your carrier how they handle QOS. some don't since the trunk
>     to them might be dedicated.
>
>     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.
>
>     Setup the event manager applet.  have it email you on syslog
>     patterns for dialpeer status.  Then you will know if the link goes
>     down.
>
>     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.
>
>     Hope at least one thing here was helpful.
>
>     On 2/10/22 9:09 AM, Matthew Huff wrote:
>
>         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?
>
>         *Matthew Huff*| Director of Technical Operations | OTA
>         Management LLC
>
>         /Office: 914-460-4039/
>
>         /mhuff at ox.com | //www.ox.com <http://www.ox.com>/
>
>         *...........................................................................................................................................*
>
>
>
>         _______________________________________________
>
>         cisco-voip mailing list
>
>         cisco-voip at puck.nether.net
>
>         https://puck.nether.net/mailman/listinfo/cisco-voip
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20220211/cb21f634/attachment.htm>