Mailing List Archive

SIP to iTSP best practices
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@ox.com<mailto:mhuff@ox.com> | www.ox.com<http://www.ox.com>
...........................................................................................................................................
Re: SIP to iTSP best practices [ In reply to ]
The only thing I’ve heard and would probably keep is a couple of PRIs for facing until you’ve ironed out everything else.

Sent from my iPhone

On Feb 10, 2022, at 11:14 AM, Matthew Huff <mhuff@ox.com> wrote:

?

CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to IThelp@uoguelph.ca

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@ox.com<mailto:mhuff@ox.com> | www.ox.com<http://www.ox.com>
...........................................................................................................................................

_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
Re: SIP to iTSP best practices [ In reply to ]
That’s the plan. Slow migration. Setup test inbound DID and use a different # to dial outbound for testing via SIP. Once everything is confirmed then migrate routing and port inbound DIDs.



Matthew Huff | Director of Technical Operations | OTA Management LLC

Office: 914-460-4039
mhuff@ox.com<mailto:mhuff@ox.com> | www.ox.com<http://www.ox.com>
...........................................................................................................................................

From: Lelio Fulgenzi <lelio@uoguelph.ca>
Sent: Thursday, February 10, 2022 1:43 PM
To: Matthew Huff <mhuff@ox.com>
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] SIP to iTSP best practices


The only thing I’ve heard and would probably keep is a couple of PRIs for facing until you’ve ironed out everything else.
Sent from my iPhone


On Feb 10, 2022, at 11:14 AM, Matthew Huff <mhuff@ox.com<mailto:mhuff@ox.com>> wrote:
?
CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to IThelp@uoguelph.ca<mailto:IThelp@uoguelph.ca>

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@ox.com<mailto:mhuff@ox.com> | www.ox.com<http://www.ox.com>
...........................................................................................................................................

_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
Re: SIP to iTSP best practices [ In reply to ]
Oh. And to expect long delays as numbers (don’t) get ported. ?


From: Matthew Huff <mhuff@ox.com>
Sent: Thursday, February 10, 2022 1:44 PM
To: Lelio Fulgenzi <lelio@uoguelph.ca>
Cc: cisco-voip@puck.nether.net
Subject: RE: [cisco-voip] SIP to iTSP best practices

CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to IThelp@uoguelph.ca<mailto:IThelp@uoguelph.ca>

That’s the plan. Slow migration. Setup test inbound DID and use a different # to dial outbound for testing via SIP. Once everything is confirmed then migrate routing and port inbound DIDs.



Matthew Huff | Director of Technical Operations | OTA Management LLC

Office: 914-460-4039
mhuff@ox.com<mailto:mhuff@ox.com> | www.ox.com<http://www.ox.com>
...........................................................................................................................................

From: Lelio Fulgenzi <lelio@uoguelph.ca<mailto:lelio@uoguelph.ca>>
Sent: Thursday, February 10, 2022 1:43 PM
To: Matthew Huff <mhuff@ox.com<mailto:mhuff@ox.com>>
Cc: cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
Subject: Re: [cisco-voip] SIP to iTSP best practices


The only thing I’ve heard and would probably keep is a couple of PRIs for facing until you’ve ironed out everything else.
Sent from my iPhone

On Feb 10, 2022, at 11:14 AM, Matthew Huff <mhuff@ox.com<mailto:mhuff@ox.com>> wrote:
?
CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to IThelp@uoguelph.ca<mailto:IThelp@uoguelph.ca>

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@ox.com<mailto:mhuff@ox.com> | www.ox.com<http://www.ox.com>
...........................................................................................................................................

_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
Re: SIP to iTSP best practices [ In reply to ]
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@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@ox.com <mhuff@ox.com> | **www.ox.com <http://www.ox.com>*
>
>
> *...........................................................................................................................................*
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
Re: SIP to iTSP best practices [ In reply to ]
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@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@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@ox.com <mhuff@ox.com> | **www.ox.com <http://www.ox.com>*
>>
>>
>> *...........................................................................................................................................*
>>
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
Re: SIP to iTSP best practices [ In reply to ]
> 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@ox.com <mailto:mhuff@ox.com> | //www.ox.com <http://www.ox.com>/
>>
>> *...........................................................................................................................................*
>>
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
Re: SIP to iTSP best practices [ In reply to ]
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@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@vt.edu<mailto:bmeade90@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@ox.com<mailto:mhuff@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@ox.com<mailto:mhuff@ox.com> | www.ox.com<http://www.ox.com>
...........................................................................................................................................

_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
Re: SIP to iTSP best practices [ In reply to ]
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@puck.nether.net> on behalf of Myron Young <mdavid_young@hotmail.com>
Sent: Thursday, February 10, 2022 6:35:14 PM
To: Tim Smith <tim.smith@enject.com.au>
Cc: cisco-voip@puck.nether.net <cisco-voip@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@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@vt.edu<mailto:bmeade90@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@ox.com<mailto:mhuff@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@ox.com<mailto:mhuff@ox.com> | www.ox.com<http://www.ox.com>

...........................................................................................................................................



_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
Re: SIP to iTSP best practices [ In reply to ]
This was fantastic Kent. I wish I could flag this. Maybe I will enter the following tags so when I go to markmail I will find it.

SIP LELIO READ THIS

lol

From: cisco-voip <cisco-voip-bounces@puck.nether.net> On Behalf Of Kent Roberts
Sent: Thursday, February 10, 2022 6:14 PM
To: Matthew Huff <mhuff@ox.com>; cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] SIP to iTSP best practices

CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to IThelp@uoguelph.ca<mailto:IThelp@uoguelph.ca>




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@ox.com<mailto:mhuff@ox.com> | www.ox.com<http://www.ox.com>
...........................................................................................................................................




_______________________________________________

cisco-voip mailing list

cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>

https://puck.nether.net/mailman/listinfo/cisco-voip
Re: SIP to iTSP best practices [ In reply to ]
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
mhuff@ox.com<mailto:mhuff@ox.com> | www.ox.com<http://www.ox.com>
...........................................................................................................................................

From: Kent Roberts <dvxkid@gmail.com>
Sent: Thursday, February 10, 2022 6:14 PM
To: Matthew Huff <mhuff@ox.com>; 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, 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@ox.com<mailto:mhuff@ox.com> | www.ox.com<http://www.ox.com>
...........................................................................................................................................




_______________________________________________

cisco-voip mailing list

cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>

https://puck.nether.net/mailman/listinfo/cisco-voip
Re: SIP to iTSP best practices [ In reply to ]
Hope it’s helpful. I can post more but didn’t want to overwhelm…..

It’s amazing how fast you learn tricks when something gets messed up. (Usually the carriers doing changes and not telling you. This happens A LOT!!!!)

And other tricks learned when hundreds of calls get dumped. Or the surprising finds after a3 day p1 and learning that everyone follows the RFCs (right?) and doesn’t include checks, that cause overflows and cores all active and standby blades in a HA hardware platform designed to never ever go down

You learn a lot!

Have lots of stories. Just not a good blogger

Kent

> On Feb 11, 2022, at 07:56, Lelio Fulgenzi <lelio@uoguelph.ca> wrote:
>
> ?
> This was fantastic Kent. I wish I could flag this. Maybe I will enter the following tags so when I go to markmail I will find it.
>
> SIP LELIO READ THIS
>
> lol
>
> From: cisco-voip <cisco-voip-bounces@puck.nether.net> On Behalf Of Kent Roberts
> Sent: Thursday, February 10, 2022 6:14 PM
> To: Matthew Huff <mhuff@ox.com>; cisco-voip@puck.nether.net
> Subject: Re: [cisco-voip] SIP to iTSP best practices
>
> CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to IThelp@uoguelph.ca
>
>
>
> 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@ox.com | www.ox.com
> ...........................................................................................................................................
>
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
Re: SIP to iTSP best practices [ In reply to ]
First off.  if your cube is working and in production, don't just
disable video... you might be in for a surprise.   It should be done in
a test window time where you can test phones/all software.


Jabber/webex supports video, are you using those?  does your carrier
use/support it?   Do they charge extra if you send them a video call?   
(things to ponder)


This is a tricky one, and does, but does not have an easy answer....


First thing I would do is make sure the Retry Video Call as Audio check
box is (still) checked on your trunk....  (believe this is default...)

On the cube:

Cisco has a doc that calls out video suppression,  two ways:
    globally  (IOS release dependent, later releases (15.62T and 16.3.1)
        voice service voip
            sip
                audio forced

    dial-peer level
        voice-class sip audio forced


That was the easy side.  You should be golden here....

But....

remember, your carrier may not like this..., so you might have to look
at sip-profiles instead.   Use these to modify the data in/out on the
dial-peer to make your carrier happy, if you get 488 errors back.  (or
others) you might need the carriers help to understand what the don't
like....  (There is all kinds of SBC's out there...)  Most carriers do
have decent equipment monitoring there links, so you can always call
them and ask, why are you rejecting my call....   BUT keep in mind, the
carriers don't always have people trained in the area you need to help
with this, so asking them for a detailed SIP trace might be the best
idea, and call TAC for their thoughts on how to resolve.


sorry not exactly a straight answer, but if your not live yet, it will
be very easy to make happen..



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/
>
> /mhuff@ox.com | //www.ox.com <http://www.ox.com>/
>
> *...........................................................................................................................................*
>
> *From:* Kent Roberts <dvxkid@gmail.com>
> *Sent:* Thursday, February 10, 2022 6:14 PM
> *To:* Matthew Huff <mhuff@ox.com>; 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, 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@ox.com | //www.ox.com <http://www.ox.com>/
>
> *...........................................................................................................................................*
>
>
>
> _______________________________________________
>
> cisco-voip mailing list
>
> cisco-voip@puck.nether.net
>
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
Re: SIP to iTSP best practices [ In reply to ]
One more that is missing ... DTMF. Check it both ways . You may be suprised how different ITSP's are handling those and tricks you need to get them working (even getting PVDM just for it if you don't use transcoders or creating DTMF map).

For video disabled, we handle it (more than 90 countries) by region in CUCM to VGW where we have only Audio possible (G711Only). Of course there are other possibilities directly on VGW.

W dniu 11 lut 2022, 16:58, o 16:58, u?ytkownik Matthew Huff <mhuff@ox.com> napisa?:
>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
>mhuff@ox.com<mailto:mhuff@ox.com> | www.ox.com<http://www.ox.com>
>...........................................................................................................................................
>
>From: Kent Roberts <dvxkid@gmail.com>
>Sent: Thursday, February 10, 2022 6:14 PM
>To: Matthew Huff <mhuff@ox.com>; 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, 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@ox.com<mailto:mhuff@ox.com> | www.ox.com<http://www.ox.com>
>...........................................................................................................................................
>
>
>
>
>_______________________________________________
>
>cisco-voip mailing list
>
>cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
>
>https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>cisco-voip mailing list
>cisco-voip@puck.nether.net
>https://puck.nether.net/mailman/listinfo/cisco-voip
Re: SIP to iTSP best practices [ In reply to ]
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/
>
> /mhuff@ox.com | //www.ox.com <http://www.ox.com>/
>
> *...........................................................................................................................................*
>
> *From:* Kent Roberts <dvxkid@gmail.com>
> *Sent:* Thursday, February 10, 2022 6:14 PM
> *To:* Matthew Huff <mhuff@ox.com>; 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, 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@ox.com | //www.ox.com <http://www.ox.com>/
>
> *...........................................................................................................................................*
>
>
>
> _______________________________________________
>
> cisco-voip mailing list
>
> cisco-voip@puck.nether.net
>
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
Re: SIP to iTSP best practices [ In reply to ]
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
mhuff@ox.com<mailto:mhuff@ox.com> | www.ox.com<http://www.ox.com>
...........................................................................................................................................

From: Kent Roberts <dvxkid@gmail.com>
Sent: Friday, February 11, 2022 12:14 PM
To: Matthew Huff <mhuff@ox.com>; cisco-voip@puck.nether.net
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
mhuff@ox.com<mailto:mhuff@ox.com> | www.ox.com<http://www.ox.com>
...........................................................................................................................................

From: Kent Roberts <dvxkid@gmail.com><mailto:dvxkid@gmail.com>
Sent: Thursday, February 10, 2022 6:14 PM
To: Matthew Huff <mhuff@ox.com><mailto:mhuff@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, 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@ox.com<mailto:mhuff@ox.com> | www.ox.com<http://www.ox.com>
...........................................................................................................................................





_______________________________________________

cisco-voip mailing list

cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>

https://puck.nether.net/mailman/listinfo/cisco-voip
Re: SIP to iTSP best practices [ In reply to ]
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/
>
> /mhuff@ox.com | //www.ox.com <http://www.ox.com>/
>
> *...........................................................................................................................................*
>
> *From:* Kent Roberts <dvxkid@gmail.com>
> *Sent:* Friday, February 11, 2022 12:14 PM
> *To:* Matthew Huff <mhuff@ox.com>; cisco-voip@puck.nether.net
> *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/
>
> /mhuff@ox.com | //www.ox.com <http://www.ox.com>/
>
> *...........................................................................................................................................*
>
> *From:* Kent Roberts <dvxkid@gmail.com> <mailto:dvxkid@gmail.com>
> *Sent:* Thursday, February 10, 2022 6:14 PM
> *To:* Matthew Huff <mhuff@ox.com> <mailto:mhuff@ox.com>;
> 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, 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@ox.com | //www.ox.com <http://www.ox.com>/
>
> *...........................................................................................................................................*
>
>
>
>
> _______________________________________________
>
> cisco-voip mailing list
>
> cisco-voip@puck.nether.net
>
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
Re: [External] Re: SIP to iTSP best practices [ In reply to ]
Better yet, just keep a PRI for this. It’ll save you many headaches.

From: cisco-voip <cisco-voip-bounces@puck.nether.net> On Behalf Of Kent Roberts
Sent: Friday, February 11, 2022 12:14 PM
To: Matthew Huff <mhuff@ox.com>; 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
mhuff@ox.com<mailto:mhuff@ox.com> | www.ox.com<http://www.ox.com>
...........................................................................................................................................

From: Kent Roberts <dvxkid@gmail.com><mailto:dvxkid@gmail.com>
Sent: Thursday, February 10, 2022 6:14 PM
To: Matthew Huff <mhuff@ox.com><mailto:mhuff@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, 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@ox.com<mailto:mhuff@ox.com> | www.ox.com<http://www.ox.com>
...........................................................................................................................................





_______________________________________________

cisco-voip mailing list

cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>

https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [External] Re: SIP to iTSP best practices [ In reply to ]
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 <johns10t@cmich.edu> wrote:
>
> ?
> Better yet, just keep a PRI for this. It’ll save you many headaches.
>
> From: cisco-voip <cisco-voip-bounces@puck.nether.net> On Behalf Of Kent Roberts
> Sent: Friday, February 11, 2022 12:14 PM
> To: Matthew Huff <mhuff@ox.com>; 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
> mhuff@ox.com | www.ox.com
> ...........................................................................................................................................
>
> From: Kent Roberts <dvxkid@gmail.com>
> Sent: Thursday, February 10, 2022 6:14 PM
> To: Matthew Huff <mhuff@ox.com>; 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, 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@ox.com | www.ox.com
> ...........................................................................................................................................
>
>
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
Re: SIP to iTSP best practices [ In reply to ]
If you can just go with E-faxing, do that because it will save you lots of headaches as well.

On Feb 11, 2022, at 12:43 PM, Matthew Huff <mhuff@ox.com> 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
mhuff@ox.com<mailto:mhuff@ox.com> | www.ox.com<http://www.ox.com>
...........................................................................................................................................

From: Kent Roberts <dvxkid@gmail.com>
Sent: Friday, February 11, 2022 12:14 PM
To: Matthew Huff <mhuff@ox.com>; cisco-voip@puck.nether.net
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
mhuff@ox.com<mailto:mhuff@ox.com> | www.ox.com<http://www.ox.com>
...........................................................................................................................................

From: Kent Roberts <dvxkid@gmail.com><mailto:dvxkid@gmail.com>
Sent: Thursday, February 10, 2022 6:14 PM
To: Matthew Huff <mhuff@ox.com><mailto:mhuff@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, 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@ox.com<mailto:mhuff@ox.com> | www.ox.com<http://www.ox.com>
...........................................................................................................................................





_______________________________________________

cisco-voip mailing list

cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>

https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
Re: SIP to iTSP best practices [ In reply to ]
We have a few fax phone numbers that have been used for 20+ years. They are in corporate documents and regulatory filings. Since there is a just a few, I bought a couple of ATA and can play around with them and move them over time. For personal faxing, we already use e-faxing.

Matthew Huff | Director of Technical Operations | OTA Management LLC

Office: 914-460-4039
mhuff@ox.com<mailto:mhuff@ox.com> | www.ox.com<http://www.ox.com>
...........................................................................................................................................

From: Myron Young <mdavid_young@hotmail.com>
Sent: Friday, February 11, 2022 5:31 PM
To: Matthew Huff <mhuff@ox.com>
Cc: Kent Roberts <dvxkid@gmail.com>; cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] SIP to iTSP best practices

If you can just go with E-faxing, do that because it will save you lots of headaches as well.


On Feb 11, 2022, at 12:43 PM, Matthew Huff <mhuff@ox.com<mailto:mhuff@ox.com>> 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
mhuff@ox.com<mailto:mhuff@ox.com> | www.ox.com<http://www.ox.com>
...........................................................................................................................................

From: Kent Roberts <dvxkid@gmail.com<mailto:dvxkid@gmail.com>>
Sent: Friday, February 11, 2022 12:14 PM
To: Matthew Huff <mhuff@ox.com<mailto:mhuff@ox.com>>; cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
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
mhuff@ox.com<mailto:mhuff@ox.com> | www.ox.com<http://www.ox.com>
...........................................................................................................................................

From: Kent Roberts <dvxkid@gmail.com><mailto:dvxkid@gmail.com>
Sent: Thursday, February 10, 2022 6:14 PM
To: Matthew Huff <mhuff@ox.com><mailto:mhuff@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, 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@ox.com<mailto:mhuff@ox.com> | www.ox.com<http://www.ox.com>
...........................................................................................................................................






_______________________________________________

cisco-voip mailing list

cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>

https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip