[cisco-voip] SIP to iTSP best practices

Thu Feb 10 18:14:29 EST 2022

> 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 <mailto: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/20220210/d2a98167/attachment.htm>