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/
/[email protected] | //www.ox.com <http://www.ox.com>/
*...........................................................................................................................................*
*From:* Kent Roberts <[email protected]>
*Sent:* Friday, February 11, 2022 12:14 PM
*To:* Matthew Huff <[email protected]>; [email protected]
*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/
/[email protected] | //www.ox.com <http://www.ox.com>/
*...........................................................................................................................................*
*From:* Kent Roberts <[email protected]> <mailto:[email protected]>
*Sent:* Thursday, February 10, 2022 6:14 PM
*To:* Matthew Huff <[email protected]> <mailto:[email protected]>;
[email protected]
*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/
/[email protected] | //www.ox.com <http://www.ox.com>/
*...........................................................................................................................................*
_______________________________________________
cisco-voip mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/cisco-voip
