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 <[email protected]> wrote: > > > Better yet, just keep a PRI for this. It’ll save you many headaches. > > From: cisco-voip <[email protected]> On Behalf Of Kent > Roberts > Sent: Friday, February 11, 2022 12:14 PM > To: Matthew Huff <[email protected]>; [email protected] > 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 > [email protected] | www.ox.com > ........................................................................................................................................... > > From: Kent Roberts <[email protected]> > Sent: Thursday, February 10, 2022 6:14 PM > To: Matthew Huff <[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 > ........................................................................................................................................... > > > > > _______________________________________________ > 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
