Re: [cisco-voip] [External] Re: SIP to iTSP best practices
Pris are going up carriers don’t want to deal with them for the ease of sip We have a carrier that is raising the t1 price each month even on contract Messed up clocking can get you too on pris. Ah the good old days…. Kent > On Feb 11, 2022, at 13:47, Johnson, Tim wrote: > > > Better yet, just keep a PRI for this. It’ll save you many headaches. > > From: cisco-voip On Behalf Of Kent > Roberts > Sent: Friday, February 11, 2022 12:14 PM > To: Matthew Huff ; cisco-voip@puck.nether.net > Subject: [External] 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 > mh...@ox.com | www.ox.com > ... > > From: Kent Roberts > Sent: Thursday, February 10, 2022 6:14 PM > To: Matthew Huff ; cisco-voip@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
Re: [cisco-voip] [External] Re: SIP to iTSP best practices
Better yet, just keep a PRI for this. It’ll save you many headaches. From: cisco-voip On Behalf Of Kent Roberts Sent: Friday, February 11, 2022 12:14 PM To: Matthew Huff ; cisco-voip@puck.nether.net Subject: [External] 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 mh...@ox.com<mailto:mh...@ox.com> | www.ox.com<http://www.ox.com> ... From: Kent Roberts <mailto:dvx...@gmail.com> Sent: Thursday, February 10, 2022 6:14 PM To: Matthew Huff <mailto:mh...@ox.com>; cisco-voip@puck.nether.net<mailto:cisco-voip@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,
