[cisco-voip] SIP to iTSP best practices
Kent Roberts
dvxkid at gmail.com
Fri Feb 11 12:45:55 EST 2022
if your going to do faxing at some point, I would test it now. Its
easier to play with the fax commands on the cube not worrying about
breaking things later.
Geesh, I could take all this info and probably build one heck of a doc....
On 2/11/22 10:34 AM, Matthew Huff wrote:
>
> Thanks.
>
> Our new SIP voice gateway is separate and not in production so I have
> plenty of freedom to play.
>
> We have copper based FAX lines, not going over our PRI currently. This
> is something we are looking into though after this conversion is done.
>
> *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:* Friday, February 11, 2022 12:14 PM
> *To:* Matthew Huff <mhuff at ox.com>; cisco-voip at puck.nether.net
> *Subject:* Re: [cisco-voip] SIP to iTSP best practices
>
> 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> <mailto:dvxkid at gmail.com>
> *Sent:* Thursday, February 10, 2022 6:14 PM
> *To:* Matthew Huff <mhuff at ox.com> <mailto: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/b14efa6c/attachment.htm>
More information about the cisco-voip
mailing list