[cisco-voip] SIP to iTSP best practices

[Benjamin Turner]

Good advice Myron. I also do the same with my conversions from TDM to SIP

Sincerely,
Benjamin M. Turner
________________________________
From: cisco-voip <cisco-voip-bounces at puck.nether.net> on behalf of Myron Young <mdavid_young at hotmail.com>
Sent: Thursday, February 10, 2022 6:35:14 PM
To: Tim Smith <tim.smith at enject.com.au>
Cc: cisco-voip at puck.nether.net <cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] SIP to iTSP best practices

In addition to what everyone has already mentioned, you can review this video and blog for some easy clean config samples as starting points or final product.


https://ucpros.us13.list-manage.com/track/click?u=d7a33b0d260a8ff5a0e12e6d4&id=303c998291&e=69fd3c3172


https://ucpros.us13.list-manage.com/track/click?u=d7a33b0d260a8ff5a0e12e6d4&id=526d6d875a&e=69fd3c3172

On Feb 10, 2022, at 6:13 PM, Tim Smith <tim.smith at enject.com.au> wrote:


Make sure to use Server Groups, E164 pattern maps and dial peer groups.
Will allow you to create some very clean and simple config (without 1 million dial peers like we used to have) :)

Read everything Jonathan has written about CUBE and SIP - start here :)
https://afterthenumber.com/2015/12/07/implementing-loop-prevention-on-cube/

Depending on your ITSP choice.. check the Cisco interop portal - they do have some validated configs / designs with interop testing.
And of course check with your ITSP, some of them may have their own guides and testing.
Just be careful with what these guys provide - in Australia.. we find configs that work from our ITSP's... but they are typically very sloppy.
In this case, take the basic config and make adjustments.

Even via private link, it's still never a bad idea to use your VoIP trust lists to lock down the trusted hosts.
And it's also never a bad idea to have some ACL protection on that ITSP facing interface.

Make sure you have all your codecs covered and understand your DTMF requirements (particularly if you have IVR's, CCX, CCE etc)

Your biggest issue with SIP is now that often both far ends are IP based.. and you have to find common capabilities.
In Australia - telco's will do very little interworking.. so configs have to cater for this - i.e. trying to be flexible :)

Last thing I'd say..
Be explicit with your config
Do a final check and say.. do I understand everything I have in here, and why it is here
Be careful of those little copy paste nuggets that trip you up later :)

Feel free to share as you go, and maybe we can crowdsource.

Cheers,

Tim.


On Fri, 11 Feb 2022 at 07:08, Brian Meade <bmeade90 at vt.edu<mailto:bmeade90 at vt.edu>> wrote:
I'd do E.164 inbound/outbound on the CUBE side even if you don't do E.164 in CUCM.

On Thu, Feb 10, 2022 at 11:15 AM Matthew Huff <mhuff at ox.com<mailto:mhuff at ox.com>> 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<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
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/8cadfd48/attachment.htm>