Mailing List Archive

Hi Jason,

If you go through the below cisco live slides it has simple examples to configure the dial peers for your requirement.

https://www.ciscolive.com/c/dam/r/ciscolive/emea/docs/2019/pdf/BRKCOL-2125.pdf


Thanks!

Jinto

________________________________
From: cisco-voip <cisco-voip-bounces@puck.nether.net> on behalf of JASON BURWELL via cisco-voip <cisco-voip@puck.nether.net>
Sent: Friday, June 12, 2020 3:06 PM
To: cisco-voip@puck.nether.net <cisco-voip@puck.nether.net>
Subject: [cisco-voip] CUBE Config Dial Peers


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


Does anyone have a good, straightforward reference doc to configuring CUBE dial peers? I have what I would have thought should be a fairly basic config but I?m having trouble getting everything to work properly. I?ve had some assistance but it seems like a whole lot of configuration to do what little I really need to do. Basically, I just need to send whatever comes from CUCM- either 10, 11 or 3 digits in the SIP invite for outbound and for inbound calls the provider sends me 10 digits in the invite, I just need to strip off the first 6 and send the last 4 to CUCM to route. I have a lot of adding and stripping digits going on between CUCM and CUBE to make this work. Just trying to find reference docs to see if any of this can be cleaned up. Thanks

Best thing to do is separate out the ins and outs by addresses. Set up a set for in/out with the carrier. Like 1..2..3... and set up a set for your cucm. 10..11..12. Do you have a config that your working on?


Kent

> On Jun 12, 2020, at 13:12, JASON BURWELL via cisco-voip <cisco-voip@puck.nether.net> wrote:
>
> ?
> Does anyone have a good, straightforward reference doc to configuring CUBE dial peers? I have what I would have thought should be a fairly basic config but I’m having trouble getting everything to work properly. I’ve had some assistance but it seems like a whole lot of configuration to do what little I really need to do. Basically, I just need to send whatever comes from CUCM- either 10, 11 or 3 digits in the SIP invite for outbound and for inbound calls the provider sends me 10 digits in the invite, I just need to strip off the first 6 and send the last 4 to CUCM to route. I have a lot of adding and stripping digits going on between CUCM and CUBE to make this work. Just trying to find reference docs to see if any of this can be cleaned up. Thanks
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip

I've been trying to make a standardized CUBE configuration using a lot of
the newer features like dial-peer groups.

This is what I have now. It's an inbound dial-peer for CUCM matching the
CUCM IP's via Via header. Then an inbound dial-peer for the ISP. Then an
outbound dial-peer to CUCM and an outbound dial-peer to the ISP. If you
have more IP's for the ISP or CUCM, you can easily add them.
destination-pattern .T is not used at all due to using dial-peer group
matching. This doesn't account for bindings that must be done per
dial-peer. It also doesn't show translation-profiles/rules.

This gives you 4 total dial-peers to match any number.

If it comes in from CUCM, it will route to the SIP carrier. If it comes in
from the SIP carrier, it will route to CUCM.

voice class uri ISP sip
host ipv4:8.8.8.8

voice class uri CUCM sip
host ipv4:192.168.100.100
host ipv4:192.168.100.200

voice class server-group 100
ipv4 8.8.8.8 port 5060

voice class server-group 200
ipv4 192.168.100.100 port 5060
ipv4 192.168.100.200 port 5060 preference 1

voice class dpg 100

voice class dpg 200

dial-peer voice 100 voip
description Incoming Dial-peer from ISP
translation-profile incoming ISPInbound
session protocol sipv2
session transport udp
destination dpg 200
incoming uri via ISP
voice-class codec 1
dtmf-relay rtp-nte sip-kpml
fax-relay ecm disable
fax rate 9600

dial-peer voice 200 voip
description Incoming Dial-peer from CUCM
session protocol sipv2
destination dpg 100
incoming uri via CUCM
voice-class codec 1
dtmf-relay rtp-nte sip-kpml
fax-relay ecm disable
fax rate 9600

dial-peer voice 300 voip
description Outbound to ISP
translation-profile outgoing ISPOutbound
destination-pattern .T
session protocol sipv2
session transport udp
session server-group 100
voice-class codec 1
dtmf-relay rtp-nte sip-kpml
fax-relay ecm disable
fax rate 9600

dial-peer voice 400 voip
description Outbound to CUCM
destination-pattern .T
session protocol sipv2
session server-group 200
voice-class codec 1
dtmf-relay rtp-nte sip-kpml
fax-relay ecm disable
fax rate 9600

voice class dpg 100
dial-peer 300

voice class dpg 200
dial-peer 400

On Fri, Jun 12, 2020 at 3:12 PM JASON BURWELL via cisco-voip <
cisco-voip@puck.nether.net> wrote:

> Does anyone have a good, straightforward reference doc to configuring CUBE
> dial peers? I have what I would have thought should be a fairly basic
> config but I’m having trouble getting everything to work properly. I’ve had
> some assistance but it seems like a whole lot of configuration to do what
> little I really need to do. Basically, I just need to send whatever comes
> from CUCM- either 10, 11 or 3 digits in the SIP invite for outbound and for
> inbound calls the provider sends me 10 digits in the invite, I just need to
> strip off the first 6 and send the last 4 to CUCM to route. I have a lot of
> adding and stripping digits going on between CUCM and CUBE to make this
> work. Just trying to find reference docs to see if any of this can be
> cleaned up. Thanks
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>

Brian,

Nice and clean, I like it! Very similar to what I do. I'd like to
comment/question yours a bit.

1. While I like that you can give a uri profile a name like ISP, I much
prefer to stick with numbers, since for most things, you must use numbers
when naming, so this keeps it consistent.
2. I don't specify the port in my server groups, since 5060 is default, but
I can see how it might help be more explicit for some people
3. Speaking of being explicit though, if that is your intention, I would
recommend pref 1 and pref 2, instead of implied pref 0 and pref 1
4. Why didn't you should your translation profiles and rules too?
5. I don't specify UDP as the transport, since it's the default, but again,
being explicit doesn't hurt anything
6. I like the extra dtmf on there. too many configs are limited to rtp-nte
only and mtps are being invoked for every call to UCCX as one example
7. Why do you drop your fax rate down from 14400 to 9600 as a standard? I
might learn something here, as faxing is not my strongest area.
8. Since you're doing DPGs, you don't need the destination-pattern .T
command on the outbound DPs.
9a. Why are you not doing sip options ping? I would, and in which
case you need
a voice class sip options-keepalive profile
<https://community.cisco.com/t5/telepresence-and-video/sip-options-ping-and-session-server-group-on-dial-peer/td-p/2994584>
since you're using server groups.
9b. Also, if you do end up turning on options, you do in fact need a
destination-pattern command, and in which case, since it's not being used
for call routing, I just use like ABC123 as the pattern to ensure it never
can be used, but also, mildly clear it's not supposed to be used

I'll post a config as well, in a bit, and please feel free to
comment/question mine.




On Fri, Jun 12, 2020 at 3:20 PM Brian Meade <bmeade90@vt.edu> wrote:

> I've been trying to make a standardized CUBE configuration using a lot of
> the newer features like dial-peer groups.
>
> This is what I have now. It's an inbound dial-peer for CUCM matching the
> CUCM IP's via Via header. Then an inbound dial-peer for the ISP. Then an
> outbound dial-peer to CUCM and an outbound dial-peer to the ISP. If you
> have more IP's for the ISP or CUCM, you can easily add them.
> destination-pattern .T is not used at all due to using dial-peer group
> matching. This doesn't account for bindings that must be done per
> dial-peer. It also doesn't show translation-profiles/rules.
>
> This gives you 4 total dial-peers to match any number.
>
> If it comes in from CUCM, it will route to the SIP carrier. If it comes
> in from the SIP carrier, it will route to CUCM.
>
> voice class uri ISP sip
> host ipv4:8.8.8.8
>
> voice class uri CUCM sip
> host ipv4:192.168.100.100
> host ipv4:192.168.100.200
>
> voice class server-group 100
> ipv4 8.8.8.8 port 5060
>
> voice class server-group 200
> ipv4 192.168.100.100 port 5060
> ipv4 192.168.100.200 port 5060 preference 1
>
> voice class dpg 100
>
> voice class dpg 200
>
> dial-peer voice 100 voip
> description Incoming Dial-peer from ISP
> translation-profile incoming ISPInbound
> session protocol sipv2
> session transport udp
> destination dpg 200
> incoming uri via ISP
> voice-class codec 1
> dtmf-relay rtp-nte sip-kpml
> fax-relay ecm disable
> fax rate 9600
>
> dial-peer voice 200 voip
> description Incoming Dial-peer from CUCM
> session protocol sipv2
> destination dpg 100
> incoming uri via CUCM
> voice-class codec 1
> dtmf-relay rtp-nte sip-kpml
> fax-relay ecm disable
> fax rate 9600
>
> dial-peer voice 300 voip
> description Outbound to ISP
> translation-profile outgoing ISPOutbound
> destination-pattern .T
> session protocol sipv2
> session transport udp
> session server-group 100
> voice-class codec 1
> dtmf-relay rtp-nte sip-kpml
> fax-relay ecm disable
> fax rate 9600
>
> dial-peer voice 400 voip
> description Outbound to CUCM
> destination-pattern .T
> session protocol sipv2
> session server-group 200
> voice-class codec 1
> dtmf-relay rtp-nte sip-kpml
> fax-relay ecm disable
> fax rate 9600
>
> voice class dpg 100
> dial-peer 300
>
> voice class dpg 200
> dial-peer 400
>
> On Fri, Jun 12, 2020 at 3:12 PM JASON BURWELL via cisco-voip <
> cisco-voip@puck.nether.net> wrote:
>
>> Does anyone have a good, straightforward reference doc to configuring
>> CUBE dial peers? I have what I would have thought should be a fairly basic
>> config but I’m having trouble getting everything to work properly. I’ve had
>> some assistance but it seems like a whole lot of configuration to do what
>> little I really need to do. Basically, I just need to send whatever comes
>> from CUCM- either 10, 11 or 3 digits in the SIP invite for outbound and for
>> inbound calls the provider sends me 10 digits in the invite, I just need to
>> strip off the first 6 and send the last 4 to CUCM to route. I have a lot of
>> adding and stripping digits going on between CUCM and CUBE to make this
>> work. Just trying to find reference docs to see if any of this can be
>> cleaned up. Thanks
>> _______________________________________________
>> 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
>

Anthony,

Thanks for the feedback. I'll definitely take a look at yours as well.

Here's some answers on mine:
1. While I like that you can give a uri profile a name like ISP, I much
prefer to stick with numbers, since for most things, you must use numbers
when naming, so this keeps it consistent.
So I usually replace this with the name of the actual SIP carrier. This
seems to make it easier for customers to understand but I understand so
many other things are number tags only.
2. I don't specify the port in my server groups, since 5060 is default, but
I can see how it might help be more explicit for some people
Yea, I've never tried it without specifying the port. I've got a lot of
SIP carriers with weird SIP ports so making it stand out in the template
helps to know where to change this.
3. Speaking of being explicit though, if that is your intention, I would
recommend pref 1 and pref 2, instead of implied pref 0 and pref 1
That's a good idea. I actually exported this from a customer not realizing
what it looks like when I use pref 0 and 1. Making it 1 and 2 would make
that look cleaner.
4. Why didn't you should your translation profiles and rules too?
These seem to be so customer/SIP carrier specific that I didn't think it
was worth it. My most recent one had 80 rules in it because the carrier
really cares about 10-digit/11-digit calling for the local area code. So
we actually had to split it up for different NPA-NXX whether or not we
added a 1.
5. I don't specify UDP as the transport, since it's the default, but again,
being explicit doesn't hurt anything
I also make UDP my default but it is nice to have it called out in a
template so people know where to change it if needed.
6. I like the extra dtmf on there. too many configs are limited to rtp-nte
only and mtps are being invoked for every call to UCCX as one example
Yea, I always add both to make sure we never have to pull in an MTP. I'm
not aware of a way to do this globally but would be nice.
7. Why do you drop your fax rate down from 14400 to 9600 as a standard? I
might learn something here, as faxing is not my strongest area.
I'm always debugging faxing it seems like. Disabling ECM and reducing
speed to 9600 has seemed to help a lot over the years. It's slower but
seems to work more reliably with every source/destination fax device. And
people don't expect their fax to send quickly anyways.
8. Since you're doing DPGs, you don't need the destination-pattern .T
command on the outbound DPs.
It seems like IOS-XE will show a dial-peer as down and skip it if there is
no destination-pattern configured. This looks to be called out as
explicitely required here even though it isn't used-
https://cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/multiple-outbound-dial-peer.html

Using something like ABC123 for the destination-pattern may make more sense
to not confuse anyone. Good call.
9a. Why are you not doing sip options ping? I would, and in which
case you need
a voice class sip options-keepalive profile
<https://community.cisco.com/t5/telepresence-and-video/sip-options-ping-and-session-server-group-on-dial-peer/td-p/2994584>
since
you're using server groups.
I've never been a fan of SIP Options ping. I've always used SIP timers for
failover instead. I guess I've had a few outages where waiting for Options
Ping to come back up after we fixed the underlying issue added
additional delay. For monitoring purposes though, it probably is a good
idea to get back into doing that for customers where we're monitoring their
CUBEs.
9b. Also, if you do end up turning on options, you do in fact need a
destination-pattern command, and in which case, since it's not being used
for call routing, I just use like ABC123 as the pattern to ensure it never
can be used, but also, mildly clear it's not supposed to be used
I like that idea and referenced it in 8 above.



On Fri, Jun 12, 2020 at 6:29 PM Anthony Holloway <
avholloway+cisco-voip@gmail.com> wrote:

> Brian,
>
> Nice and clean, I like it! Very similar to what I do. I'd like to
> comment/question yours a bit.
>
> 1. While I like that you can give a uri profile a name like ISP, I much
> prefer to stick with numbers, since for most things, you must use numbers
> when naming, so this keeps it consistent.
> 2. I don't specify the port in my server groups, since 5060 is default,
> but I can see how it might help be more explicit for some people
> 3. Speaking of being explicit though, if that is your intention, I would
> recommend pref 1 and pref 2, instead of implied pref 0 and pref 1
> 4. Why didn't you should your translation profiles and rules too?
> 5. I don't specify UDP as the transport, since it's the default, but
> again, being explicit doesn't hurt anything
> 6. I like the extra dtmf on there. too many configs are limited to
> rtp-nte only and mtps are being invoked for every call to UCCX as one
> example
> 7. Why do you drop your fax rate down from 14400 to 9600 as a standard? I
> might learn something here, as faxing is not my strongest area.
> 8. Since you're doing DPGs, you don't need the destination-pattern .T
> command on the outbound DPs.
> 9a. Why are you not doing sip options ping? I would, and in which case
> you need a voice class sip options-keepalive profile
> <https://community.cisco.com/t5/telepresence-and-video/sip-options-ping-and-session-server-group-on-dial-peer/td-p/2994584>
> since you're using server groups.
> 9b. Also, if you do end up turning on options, you do in fact need a
> destination-pattern command, and in which case, since it's not being used
> for call routing, I just use like ABC123 as the pattern to ensure it never
> can be used, but also, mildly clear it's not supposed to be used
>
> I'll post a config as well, in a bit, and please feel free to
> comment/question mine.
>
>
>
>
> On Fri, Jun 12, 2020 at 3:20 PM Brian Meade <bmeade90@vt.edu> wrote:
>
>> I've been trying to make a standardized CUBE configuration using a lot of
>> the newer features like dial-peer groups.
>>
>> This is what I have now. It's an inbound dial-peer for CUCM matching the
>> CUCM IP's via Via header. Then an inbound dial-peer for the ISP. Then an
>> outbound dial-peer to CUCM and an outbound dial-peer to the ISP. If you
>> have more IP's for the ISP or CUCM, you can easily add them.
>> destination-pattern .T is not used at all due to using dial-peer group
>> matching. This doesn't account for bindings that must be done per
>> dial-peer. It also doesn't show translation-profiles/rules.
>>
>> This gives you 4 total dial-peers to match any number.
>>
>> If it comes in from CUCM, it will route to the SIP carrier. If it comes
>> in from the SIP carrier, it will route to CUCM.
>>
>> voice class uri ISP sip
>> host ipv4:8.8.8.8
>>
>> voice class uri CUCM sip
>> host ipv4:192.168.100.100
>> host ipv4:192.168.100.200
>>
>> voice class server-group 100
>> ipv4 8.8.8.8 port 5060
>>
>> voice class server-group 200
>> ipv4 192.168.100.100 port 5060
>> ipv4 192.168.100.200 port 5060 preference 1
>>
>> voice class dpg 100
>>
>> voice class dpg 200
>>
>> dial-peer voice 100 voip
>> description Incoming Dial-peer from ISP
>> translation-profile incoming ISPInbound
>> session protocol sipv2
>> session transport udp
>> destination dpg 200
>> incoming uri via ISP
>> voice-class codec 1
>> dtmf-relay rtp-nte sip-kpml
>> fax-relay ecm disable
>> fax rate 9600
>>
>> dial-peer voice 200 voip
>> description Incoming Dial-peer from CUCM
>> session protocol sipv2
>> destination dpg 100
>> incoming uri via CUCM
>> voice-class codec 1
>> dtmf-relay rtp-nte sip-kpml
>> fax-relay ecm disable
>> fax rate 9600
>>
>> dial-peer voice 300 voip
>> description Outbound to ISP
>> translation-profile outgoing ISPOutbound
>> destination-pattern .T
>> session protocol sipv2
>> session transport udp
>> session server-group 100
>> voice-class codec 1
>> dtmf-relay rtp-nte sip-kpml
>> fax-relay ecm disable
>> fax rate 9600
>>
>> dial-peer voice 400 voip
>> description Outbound to CUCM
>> destination-pattern .T
>> session protocol sipv2
>> session server-group 200
>> voice-class codec 1
>> dtmf-relay rtp-nte sip-kpml
>> fax-relay ecm disable
>> fax rate 9600
>>
>> voice class dpg 100
>> dial-peer 300
>>
>> voice class dpg 200
>> dial-peer 400
>>
>> On Fri, Jun 12, 2020 at 3:12 PM JASON BURWELL via cisco-voip <
>> cisco-voip@puck.nether.net> wrote:
>>
>>> Does anyone have a good, straightforward reference doc to configuring
>>> CUBE dial peers? I have what I would have thought should be a fairly basic
>>> config but I’m having trouble getting everything to work properly. I’ve had
>>> some assistance but it seems like a whole lot of configuration to do what
>>> little I really need to do. Basically, I just need to send whatever comes
>>> from CUCM- either 10, 11 or 3 digits in the SIP invite for outbound and for
>>> inbound calls the provider sends me 10 digits in the invite, I just need to
>>> strip off the first 6 and send the last 4 to CUCM to route. I have a lot of
>>> adding and stripping digits going on between CUCM and CUBE to make this
>>> work. Just trying to find reference docs to see if any of this can be
>>> cleaned up. Thanks
>>> _______________________________________________
>>> 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
>>
>

All great points, thanks for taking the time to respond.

The only one I think that I need to reply to is the DPG and
destination-pattern one. I was actually troubleshooting a customer CUBE
wherein this exact scenario was in place and the only negative was getting
options to work. Otherwise, it was routing the call just fine. Granted, I
couldn't tell you what version that was, as it was like a year or so ago,
but either way, I always put a destination-pattern on because you need one
for options to function.

I guess I could reply to one more, and that has to do with tweaking retries
from 6 to 2 AND using options. Why stick to one, when you can do both?

Here's the one I use which I said was very similar to yours.

The first thing to note is the numeric structure of my tags.

1000 series numbers are the ITSP side
2000 series numbers are the CUCM side

I would expand this to 3000, 4000, etc., for additional integrations like
PRIs, FXO, second ITSP, second PBX, etc. Most I ever had was 6
integrations into a single CUBE i think.

The second digit is 1 for incoming and 2 for outgoing.

The 4rd and fourth digit are generally not used, unless I need additional
dial-peers for the same peer and direction, but doing something slightly
different. Most I ever used was like 15 i think. E.g., 2215 But that was
not using IP addresses in the matching and DPGs, that was using phone
number matching, and I was using steering codes.

This numbering structure allows me to do something like this:

show run | section 12..

Which would then show me the following all at once: URI, Server Group,
Profile and Dial Peers all pertaining to the outgoing ITSP leg.

Also, in this example, we pass +E164 through the gateway bi-directionally,
so no digit manip needed.

voice class uri 1100 sip
host ipv4:8.8.8.8
host ipv4:9.9.9.9
!
voice class server-group 1200
description ITSP Peers
ipv4 8.8.8.8 preference 1
ipv4 9.9.9.9 preference 2
!
voice class sip-options-keepalive 1200
description ITSP Peers (Intentionally Left Blank)
!
voice class uri 2100 sip
host ipv4:10.1.1.2
host ipv4:10.1.1.3
!
voice class server-group 2200
description CUCM Nodes
ipv4 10.1.1.2 preference 1
ipv4 10.1.1.3 preference 2
!
voice class sip-options-keepalive 2200
description CUCM Nodes (Intentionally Left Blank)
!
voice class dpg 1200
dial-peer 1200
!
voice class dpg 2200
dial-peer 2200
!
dial-peer voice 1100 voip
description Incoming ITSP Call Leg
session protocol sipv2
incoming uri via 1100
destination dpg 2200
dtmf-relay rtp-nte ; ITSP only supports one dtmf relay
codec g711ulaw ; ITSP only supports one codec
ip qos dscp cs3 signaling
no vad
!
dial-peer voice 1200 voip
description Outgoing ITSP Call Leg
destination-pattern ABC123
session protocol sipv2
session server-group 1200
voice-class sip options-keepalive profile 1200
dtmf-relay rtp-nte
codec g711ulaw
ip qos dscp cs3 signaling
no vad
!
dial-peer voice 2100 voip
description Incoming CUCM Call Leg
session protocol sipv2
incoming uri via 2100
destination dpg 1200
dtmf-relay sip-kpml rtp-nte ; we support both in- and out-of-band
internally and cube interworks dtmf
codec g711ulaw
ip qos dscp cs3 signaling
no vad
!
dial-peer voice 2200 voip
description Outgoing CUCM Call Leg
session protocol sipv2
session server-group 2200
destination-pattern ABC123
voice-class sip options-keepalive profile 2200
dtmf-relay sip-kpml rtp-nte
codec g711ulaw
ip qos dscp cs3 signaling
no vad
!
! a little something extra here at the end
alias exec attra show call active voice | in
PeerAddr|PeerId|RemoteS|RemoteM|Dtmf|Coder|VAD
alias exec attrh show call history voice | in
PeerAddr|PeerId|RemoteS|RemoteM|Dtmf|Coder|VAD

On Fri, Jun 12, 2020 at 6:36 PM Brian Meade <bmeade90@vt.edu> wrote:

> Anthony,
>
> Thanks for the feedback. I'll definitely take a look at yours as well.
>
> Here's some answers on mine:
> 1. While I like that you can give a uri profile a name like ISP, I much
> prefer to stick with numbers, since for most things, you must use numbers
> when naming, so this keeps it consistent.
> So I usually replace this with the name of the actual SIP carrier. This
> seems to make it easier for customers to understand but I understand so
> many other things are number tags only.
> 2. I don't specify the port in my server groups, since 5060 is default,
> but I can see how it might help be more explicit for some people
> Yea, I've never tried it without specifying the port. I've got a lot of
> SIP carriers with weird SIP ports so making it stand out in the template
> helps to know where to change this.
> 3. Speaking of being explicit though, if that is your intention, I would
> recommend pref 1 and pref 2, instead of implied pref 0 and pref 1
> That's a good idea. I actually exported this from a customer not
> realizing what it looks like when I use pref 0 and 1. Making it 1 and 2
> would make that look cleaner.
> 4. Why didn't you should your translation profiles and rules too?
> These seem to be so customer/SIP carrier specific that I didn't think it
> was worth it. My most recent one had 80 rules in it because the carrier
> really cares about 10-digit/11-digit calling for the local area code. So
> we actually had to split it up for different NPA-NXX whether or not we
> added a 1.
> 5. I don't specify UDP as the transport, since it's the default, but
> again, being explicit doesn't hurt anything
> I also make UDP my default but it is nice to have it called out in a
> template so people know where to change it if needed.
> 6. I like the extra dtmf on there. too many configs are limited to
> rtp-nte only and mtps are being invoked for every call to UCCX as one
> example
> Yea, I always add both to make sure we never have to pull in an MTP. I'm
> not aware of a way to do this globally but would be nice.
> 7. Why do you drop your fax rate down from 14400 to 9600 as a standard? I
> might learn something here, as faxing is not my strongest area.
> I'm always debugging faxing it seems like. Disabling ECM and reducing
> speed to 9600 has seemed to help a lot over the years. It's slower but
> seems to work more reliably with every source/destination fax device. And
> people don't expect their fax to send quickly anyways.
> 8. Since you're doing DPGs, you don't need the destination-pattern .T
> command on the outbound DPs.
> It seems like IOS-XE will show a dial-peer as down and skip it if there is
> no destination-pattern configured. This looks to be called out as
> explicitely required here even though it isn't used-
> https://cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/multiple-outbound-dial-peer.html
>
> Using something like ABC123 for the destination-pattern may make more
> sense to not confuse anyone. Good call.
> 9a. Why are you not doing sip options ping? I would, and in which case
> you need a voice class sip options-keepalive profile
> <https://community.cisco.com/t5/telepresence-and-video/sip-options-ping-and-session-server-group-on-dial-peer/td-p/2994584> since
> you're using server groups.
> I've never been a fan of SIP Options ping. I've always used SIP timers
> for failover instead. I guess I've had a few outages where waiting for
> Options Ping to come back up after we fixed the underlying issue added
> additional delay. For monitoring purposes though, it probably is a good
> idea to get back into doing that for customers where we're monitoring their
> CUBEs.
> 9b. Also, if you do end up turning on options, you do in fact need a
> destination-pattern command, and in which case, since it's not being used
> for call routing, I just use like ABC123 as the pattern to ensure it never
> can be used, but also, mildly clear it's not supposed to be used
> I like that idea and referenced it in 8 above.
>
>
>
> On Fri, Jun 12, 2020 at 6:29 PM Anthony Holloway <
> avholloway+cisco-voip@gmail.com> wrote:
>
>> Brian,
>>
>> Nice and clean, I like it! Very similar to what I do. I'd like to
>> comment/question yours a bit.
>>
>> 1. While I like that you can give a uri profile a name like ISP, I much
>> prefer to stick with numbers, since for most things, you must use numbers
>> when naming, so this keeps it consistent.
>> 2. I don't specify the port in my server groups, since 5060 is default,
>> but I can see how it might help be more explicit for some people
>> 3. Speaking of being explicit though, if that is your intention, I would
>> recommend pref 1 and pref 2, instead of implied pref 0 and pref 1
>> 4. Why didn't you should your translation profiles and rules too?
>> 5. I don't specify UDP as the transport, since it's the default, but
>> again, being explicit doesn't hurt anything
>> 6. I like the extra dtmf on there. too many configs are limited to
>> rtp-nte only and mtps are being invoked for every call to UCCX as one
>> example
>> 7. Why do you drop your fax rate down from 14400 to 9600 as a standard?
>> I might learn something here, as faxing is not my strongest area.
>> 8. Since you're doing DPGs, you don't need the destination-pattern .T
>> command on the outbound DPs.
>> 9a. Why are you not doing sip options ping? I would, and in which case
>> you need a voice class sip options-keepalive profile
>> <https://community.cisco.com/t5/telepresence-and-video/sip-options-ping-and-session-server-group-on-dial-peer/td-p/2994584>
>> since you're using server groups.
>> 9b. Also, if you do end up turning on options, you do in fact need a
>> destination-pattern command, and in which case, since it's not being used
>> for call routing, I just use like ABC123 as the pattern to ensure it never
>> can be used, but also, mildly clear it's not supposed to be used
>>
>> I'll post a config as well, in a bit, and please feel free to
>> comment/question mine.
>>
>>
>>
>>
>> On Fri, Jun 12, 2020 at 3:20 PM Brian Meade <bmeade90@vt.edu> wrote:
>>
>>> I've been trying to make a standardized CUBE configuration using a lot
>>> of the newer features like dial-peer groups.
>>>
>>> This is what I have now. It's an inbound dial-peer for CUCM matching
>>> the CUCM IP's via Via header. Then an inbound dial-peer for the ISP. Then
>>> an outbound dial-peer to CUCM and an outbound dial-peer to the ISP. If you
>>> have more IP's for the ISP or CUCM, you can easily add them.
>>> destination-pattern .T is not used at all due to using dial-peer group
>>> matching. This doesn't account for bindings that must be done per
>>> dial-peer. It also doesn't show translation-profiles/rules.
>>>
>>> This gives you 4 total dial-peers to match any number.
>>>
>>> If it comes in from CUCM, it will route to the SIP carrier. If it comes
>>> in from the SIP carrier, it will route to CUCM.
>>>
>>> voice class uri ISP sip
>>> host ipv4:8.8.8.8
>>>
>>> voice class uri CUCM sip
>>> host ipv4:192.168.100.100
>>> host ipv4:192.168.100.200
>>>
>>> voice class server-group 100
>>> ipv4 8.8.8.8 port 5060
>>>
>>> voice class server-group 200
>>> ipv4 192.168.100.100 port 5060
>>> ipv4 192.168.100.200 port 5060 preference 1
>>>
>>> voice class dpg 100
>>>
>>> voice class dpg 200
>>>
>>> dial-peer voice 100 voip
>>> description Incoming Dial-peer from ISP
>>> translation-profile incoming ISPInbound
>>> session protocol sipv2
>>> session transport udp
>>> destination dpg 200
>>> incoming uri via ISP
>>> voice-class codec 1
>>> dtmf-relay rtp-nte sip-kpml
>>> fax-relay ecm disable
>>> fax rate 9600
>>>
>>> dial-peer voice 200 voip
>>> description Incoming Dial-peer from CUCM
>>> session protocol sipv2
>>> destination dpg 100
>>> incoming uri via CUCM
>>> voice-class codec 1
>>> dtmf-relay rtp-nte sip-kpml
>>> fax-relay ecm disable
>>> fax rate 9600
>>>
>>> dial-peer voice 300 voip
>>> description Outbound to ISP
>>> translation-profile outgoing ISPOutbound
>>> destination-pattern .T
>>> session protocol sipv2
>>> session transport udp
>>> session server-group 100
>>> voice-class codec 1
>>> dtmf-relay rtp-nte sip-kpml
>>> fax-relay ecm disable
>>> fax rate 9600
>>>
>>> dial-peer voice 400 voip
>>> description Outbound to CUCM
>>> destination-pattern .T
>>> session protocol sipv2
>>> session server-group 200
>>> voice-class codec 1
>>> dtmf-relay rtp-nte sip-kpml
>>> fax-relay ecm disable
>>> fax rate 9600
>>>
>>> voice class dpg 100
>>> dial-peer 300
>>>
>>> voice class dpg 200
>>> dial-peer 400
>>>
>>> On Fri, Jun 12, 2020 at 3:12 PM JASON BURWELL via cisco-voip <
>>> cisco-voip@puck.nether.net> wrote:
>>>
>>>> Does anyone have a good, straightforward reference doc to configuring
>>>> CUBE dial peers? I have what I would have thought should be a fairly basic
>>>> config but I’m having trouble getting everything to work properly. I’ve had
>>>> some assistance but it seems like a whole lot of configuration to do what
>>>> little I really need to do. Basically, I just need to send whatever comes
>>>> from CUCM- either 10, 11 or 3 digits in the SIP invite for outbound and for
>>>> inbound calls the provider sends me 10 digits in the invite, I just need to
>>>> strip off the first 6 and send the last 4 to CUCM to route. I have a lot of
>>>> adding and stripping digits going on between CUCM and CUBE to make this
>>>> work. Just trying to find reference docs to see if any of this can be
>>>> cleaned up. Thanks
>>>> _______________________________________________
>>>> 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
>>>
>>

Anthony,

I like the config. Definitely is nice to have some standardization on the
dial-peer tags. I've usually done all my inbound dial-peers in the 1XX
range but have gone outside of that lately with separating inbound ITSP and
inbound CUCM dial-peers to make them more obvious but I like the idea of
having more structure like yours.

Using the destination-pattern ABC123 is a great idea to show that's not
used as mentioned before.

I try to always use voice-class codec for every dial-peer even if I've only
got 1 codec configured there just to make it easier to change if ever
needed but that was in the past when I had separate local/long
distance/911/international/10-digit dial-peers. Simplifying it down to a
single inbound/outbound dial-peer with the ITSP makes it a toss-up if that
helps anymore.

I've tried to keep KPML on my ITSP facing dial-peers just in case they
happen to support it. I've found some say they don't but actually do use
it if you advertise it. No harm in advertising it from our side.

I like the aliases you've got there as well. I feel like I'm always on
some random customer's box so not sure I'd remember to always put them in
first but definitely nice to have when you make the full CUBE config.

Looks like all you're missing is your fax config! I can fax that over to
you! :)

On Fri, Jun 12, 2020 at 8:53 PM Anthony Holloway <
avholloway+cisco-voip@gmail.com> wrote:

> All great points, thanks for taking the time to respond.
>
> The only one I think that I need to reply to is the DPG and
> destination-pattern one. I was actually troubleshooting a customer CUBE
> wherein this exact scenario was in place and the only negative was getting
> options to work. Otherwise, it was routing the call just fine. Granted, I
> couldn't tell you what version that was, as it was like a year or so ago,
> but either way, I always put a destination-pattern on because you need one
> for options to function.
>
> I guess I could reply to one more, and that has to do with tweaking
> retries from 6 to 2 AND using options. Why stick to one, when you can do
> both?
>
> Here's the one I use which I said was very similar to yours.
>
> The first thing to note is the numeric structure of my tags.
>
> 1000 series numbers are the ITSP side
> 2000 series numbers are the CUCM side
>
> I would expand this to 3000, 4000, etc., for additional integrations like
> PRIs, FXO, second ITSP, second PBX, etc. Most I ever had was 6
> integrations into a single CUBE i think.
>
> The second digit is 1 for incoming and 2 for outgoing.
>
> The 4rd and fourth digit are generally not used, unless I need additional
> dial-peers for the same peer and direction, but doing something slightly
> different. Most I ever used was like 15 i think. E.g., 2215 But that was
> not using IP addresses in the matching and DPGs, that was using phone
> number matching, and I was using steering codes.
>
> This numbering structure allows me to do something like this:
>
> show run | section 12..
>
> Which would then show me the following all at once: URI, Server Group,
> Profile and Dial Peers all pertaining to the outgoing ITSP leg.
>
> Also, in this example, we pass +E164 through the gateway bi-directionally,
> so no digit manip needed.
>
> voice class uri 1100 sip
> host ipv4:8.8.8.8
> host ipv4:9.9.9.9
> !
> voice class server-group 1200
> description ITSP Peers
> ipv4 8.8.8.8 preference 1
> ipv4 9.9.9.9 preference 2
> !
> voice class sip-options-keepalive 1200
> description ITSP Peers (Intentionally Left Blank)
> !
> voice class uri 2100 sip
> host ipv4:10.1.1.2
> host ipv4:10.1.1.3
> !
> voice class server-group 2200
> description CUCM Nodes
> ipv4 10.1.1.2 preference 1
> ipv4 10.1.1.3 preference 2
> !
> voice class sip-options-keepalive 2200
> description CUCM Nodes (Intentionally Left Blank)
> !
> voice class dpg 1200
> dial-peer 1200
> !
> voice class dpg 2200
> dial-peer 2200
> !
> dial-peer voice 1100 voip
> description Incoming ITSP Call Leg
> session protocol sipv2
> incoming uri via 1100
> destination dpg 2200
> dtmf-relay rtp-nte ; ITSP only supports one dtmf relay
> codec g711ulaw ; ITSP only supports one codec
> ip qos dscp cs3 signaling
> no vad
> !
> dial-peer voice 1200 voip
> description Outgoing ITSP Call Leg
> destination-pattern ABC123
> session protocol sipv2
> session server-group 1200
> voice-class sip options-keepalive profile 1200
> dtmf-relay rtp-nte
> codec g711ulaw
> ip qos dscp cs3 signaling
> no vad
> !
> dial-peer voice 2100 voip
> description Incoming CUCM Call Leg
> session protocol sipv2
> incoming uri via 2100
> destination dpg 1200
> dtmf-relay sip-kpml rtp-nte ; we support both in- and out-of-band
> internally and cube interworks dtmf
> codec g711ulaw
> ip qos dscp cs3 signaling
> no vad
> !
> dial-peer voice 2200 voip
> description Outgoing CUCM Call Leg
> session protocol sipv2
> session server-group 2200
> destination-pattern ABC123
> voice-class sip options-keepalive profile 2200
> dtmf-relay sip-kpml rtp-nte
> codec g711ulaw
> ip qos dscp cs3 signaling
> no vad
> !
> ! a little something extra here at the end
> alias exec attra show call active voice | in
> PeerAddr|PeerId|RemoteS|RemoteM|Dtmf|Coder|VAD
> alias exec attrh show call history voice | in
> PeerAddr|PeerId|RemoteS|RemoteM|Dtmf|Coder|VAD
>
> On Fri, Jun 12, 2020 at 6:36 PM Brian Meade <bmeade90@vt.edu> wrote:
>
>> Anthony,
>>
>> Thanks for the feedback. I'll definitely take a look at yours as well.
>>
>> Here's some answers on mine:
>> 1. While I like that you can give a uri profile a name like ISP, I much
>> prefer to stick with numbers, since for most things, you must use numbers
>> when naming, so this keeps it consistent.
>> So I usually replace this with the name of the actual SIP carrier. This
>> seems to make it easier for customers to understand but I understand so
>> many other things are number tags only.
>> 2. I don't specify the port in my server groups, since 5060 is default,
>> but I can see how it might help be more explicit for some people
>> Yea, I've never tried it without specifying the port. I've got a lot of
>> SIP carriers with weird SIP ports so making it stand out in the template
>> helps to know where to change this.
>> 3. Speaking of being explicit though, if that is your intention, I would
>> recommend pref 1 and pref 2, instead of implied pref 0 and pref 1
>> That's a good idea. I actually exported this from a customer not
>> realizing what it looks like when I use pref 0 and 1. Making it 1 and 2
>> would make that look cleaner.
>> 4. Why didn't you should your translation profiles and rules too?
>> These seem to be so customer/SIP carrier specific that I didn't think it
>> was worth it. My most recent one had 80 rules in it because the carrier
>> really cares about 10-digit/11-digit calling for the local area code. So
>> we actually had to split it up for different NPA-NXX whether or not we
>> added a 1.
>> 5. I don't specify UDP as the transport, since it's the default, but
>> again, being explicit doesn't hurt anything
>> I also make UDP my default but it is nice to have it called out in a
>> template so people know where to change it if needed.
>> 6. I like the extra dtmf on there. too many configs are limited to
>> rtp-nte only and mtps are being invoked for every call to UCCX as one
>> example
>> Yea, I always add both to make sure we never have to pull in an MTP. I'm
>> not aware of a way to do this globally but would be nice.
>> 7. Why do you drop your fax rate down from 14400 to 9600 as a standard?
>> I might learn something here, as faxing is not my strongest area.
>> I'm always debugging faxing it seems like. Disabling ECM and reducing
>> speed to 9600 has seemed to help a lot over the years. It's slower but
>> seems to work more reliably with every source/destination fax device. And
>> people don't expect their fax to send quickly anyways.
>> 8. Since you're doing DPGs, you don't need the destination-pattern .T
>> command on the outbound DPs.
>> It seems like IOS-XE will show a dial-peer as down and skip it if there
>> is no destination-pattern configured. This looks to be called out as
>> explicitely required here even though it isn't used-
>> https://cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/multiple-outbound-dial-peer.html
>>
>> Using something like ABC123 for the destination-pattern may make more
>> sense to not confuse anyone. Good call.
>> 9a. Why are you not doing sip options ping? I would, and in which case
>> you need a voice class sip options-keepalive profile
>> <https://community.cisco.com/t5/telepresence-and-video/sip-options-ping-and-session-server-group-on-dial-peer/td-p/2994584> since
>> you're using server groups.
>> I've never been a fan of SIP Options ping. I've always used SIP timers
>> for failover instead. I guess I've had a few outages where waiting for
>> Options Ping to come back up after we fixed the underlying issue added
>> additional delay. For monitoring purposes though, it probably is a good
>> idea to get back into doing that for customers where we're monitoring their
>> CUBEs.
>> 9b. Also, if you do end up turning on options, you do in fact need a
>> destination-pattern command, and in which case, since it's not being used
>> for call routing, I just use like ABC123 as the pattern to ensure it never
>> can be used, but also, mildly clear it's not supposed to be used
>> I like that idea and referenced it in 8 above.
>>
>>
>>
>> On Fri, Jun 12, 2020 at 6:29 PM Anthony Holloway <
>> avholloway+cisco-voip@gmail.com> wrote:
>>
>>> Brian,
>>>
>>> Nice and clean, I like it! Very similar to what I do. I'd like to
>>> comment/question yours a bit.
>>>
>>> 1. While I like that you can give a uri profile a name like ISP, I much
>>> prefer to stick with numbers, since for most things, you must use numbers
>>> when naming, so this keeps it consistent.
>>> 2. I don't specify the port in my server groups, since 5060 is default,
>>> but I can see how it might help be more explicit for some people
>>> 3. Speaking of being explicit though, if that is your intention, I would
>>> recommend pref 1 and pref 2, instead of implied pref 0 and pref 1
>>> 4. Why didn't you should your translation profiles and rules too?
>>> 5. I don't specify UDP as the transport, since it's the default, but
>>> again, being explicit doesn't hurt anything
>>> 6. I like the extra dtmf on there. too many configs are limited to
>>> rtp-nte only and mtps are being invoked for every call to UCCX as one
>>> example
>>> 7. Why do you drop your fax rate down from 14400 to 9600 as a standard?
>>> I might learn something here, as faxing is not my strongest area.
>>> 8. Since you're doing DPGs, you don't need the destination-pattern .T
>>> command on the outbound DPs.
>>> 9a. Why are you not doing sip options ping? I would, and in which case
>>> you need a voice class sip options-keepalive profile
>>> <https://community.cisco.com/t5/telepresence-and-video/sip-options-ping-and-session-server-group-on-dial-peer/td-p/2994584>
>>> since you're using server groups.
>>> 9b. Also, if you do end up turning on options, you do in fact need a
>>> destination-pattern command, and in which case, since it's not being used
>>> for call routing, I just use like ABC123 as the pattern to ensure it never
>>> can be used, but also, mildly clear it's not supposed to be used
>>>
>>> I'll post a config as well, in a bit, and please feel free to
>>> comment/question mine.
>>>
>>>
>>>
>>>
>>> On Fri, Jun 12, 2020 at 3:20 PM Brian Meade <bmeade90@vt.edu> wrote:
>>>
>>>> I've been trying to make a standardized CUBE configuration using a lot
>>>> of the newer features like dial-peer groups.
>>>>
>>>> This is what I have now. It's an inbound dial-peer for CUCM matching
>>>> the CUCM IP's via Via header. Then an inbound dial-peer for the ISP. Then
>>>> an outbound dial-peer to CUCM and an outbound dial-peer to the ISP. If you
>>>> have more IP's for the ISP or CUCM, you can easily add them.
>>>> destination-pattern .T is not used at all due to using dial-peer group
>>>> matching. This doesn't account for bindings that must be done per
>>>> dial-peer. It also doesn't show translation-profiles/rules.
>>>>
>>>> This gives you 4 total dial-peers to match any number.
>>>>
>>>> If it comes in from CUCM, it will route to the SIP carrier. If it
>>>> comes in from the SIP carrier, it will route to CUCM.
>>>>
>>>> voice class uri ISP sip
>>>> host ipv4:8.8.8.8
>>>>
>>>> voice class uri CUCM sip
>>>> host ipv4:192.168.100.100
>>>> host ipv4:192.168.100.200
>>>>
>>>> voice class server-group 100
>>>> ipv4 8.8.8.8 port 5060
>>>>
>>>> voice class server-group 200
>>>> ipv4 192.168.100.100 port 5060
>>>> ipv4 192.168.100.200 port 5060 preference 1
>>>>
>>>> voice class dpg 100
>>>>
>>>> voice class dpg 200
>>>>
>>>> dial-peer voice 100 voip
>>>> description Incoming Dial-peer from ISP
>>>> translation-profile incoming ISPInbound
>>>> session protocol sipv2
>>>> session transport udp
>>>> destination dpg 200
>>>> incoming uri via ISP
>>>> voice-class codec 1
>>>> dtmf-relay rtp-nte sip-kpml
>>>> fax-relay ecm disable
>>>> fax rate 9600
>>>>
>>>> dial-peer voice 200 voip
>>>> description Incoming Dial-peer from CUCM
>>>> session protocol sipv2
>>>> destination dpg 100
>>>> incoming uri via CUCM
>>>> voice-class codec 1
>>>> dtmf-relay rtp-nte sip-kpml
>>>> fax-relay ecm disable
>>>> fax rate 9600
>>>>
>>>> dial-peer voice 300 voip
>>>> description Outbound to ISP
>>>> translation-profile outgoing ISPOutbound
>>>> destination-pattern .T
>>>> session protocol sipv2
>>>> session transport udp
>>>> session server-group 100
>>>> voice-class codec 1
>>>> dtmf-relay rtp-nte sip-kpml
>>>> fax-relay ecm disable
>>>> fax rate 9600
>>>>
>>>> dial-peer voice 400 voip
>>>> description Outbound to CUCM
>>>> destination-pattern .T
>>>> session protocol sipv2
>>>> session server-group 200
>>>> voice-class codec 1
>>>> dtmf-relay rtp-nte sip-kpml
>>>> fax-relay ecm disable
>>>> fax rate 9600
>>>>
>>>> voice class dpg 100
>>>> dial-peer 300
>>>>
>>>> voice class dpg 200
>>>> dial-peer 400
>>>>
>>>> On Fri, Jun 12, 2020 at 3:12 PM JASON BURWELL via cisco-voip <
>>>> cisco-voip@puck.nether.net> wrote:
>>>>
>>>>> Does anyone have a good, straightforward reference doc to configuring
>>>>> CUBE dial peers? I have what I would have thought should be a fairly basic
>>>>> config but I’m having trouble getting everything to work properly. I’ve had
>>>>> some assistance but it seems like a whole lot of configuration to do what
>>>>> little I really need to do. Basically, I just need to send whatever comes
>>>>> from CUCM- either 10, 11 or 3 digits in the SIP invite for outbound and for
>>>>> inbound calls the provider sends me 10 digits in the invite, I just need to
>>>>> strip off the first 6 and send the last 4 to CUCM to route. I have a lot of
>>>>> adding and stripping digits going on between CUCM and CUBE to make this
>>>>> work. Just trying to find reference docs to see if any of this can be
>>>>> cleaned up. Thanks
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>

Sorry, transmission failed. Try disabling NSF and re-sending.

Back to the point of ABC123, it would be so nice if we could add comments
to the show run. Second best is to keep a commented copy of the config off
box in your documentation repository.

On Mon, Jun 15, 2020 at 11:31 PM Brian Meade <bmeade90@vt.edu> wrote:

> Anthony,
>
> I like the config. Definitely is nice to have some standardization on the
> dial-peer tags. I've usually done all my inbound dial-peers in the 1XX
> range but have gone outside of that lately with separating inbound ITSP and
> inbound CUCM dial-peers to make them more obvious but I like the idea of
> having more structure like yours.
>
> Using the destination-pattern ABC123 is a great idea to show that's not
> used as mentioned before.
>
> I try to always use voice-class codec for every dial-peer even if I've
> only got 1 codec configured there just to make it easier to change if ever
> needed but that was in the past when I had separate local/long
> distance/911/international/10-digit dial-peers. Simplifying it down to a
> single inbound/outbound dial-peer with the ITSP makes it a toss-up if that
> helps anymore.
>
> I've tried to keep KPML on my ITSP facing dial-peers just in case they
> happen to support it. I've found some say they don't but actually do use
> it if you advertise it. No harm in advertising it from our side.
>
> I like the aliases you've got there as well. I feel like I'm always on
> some random customer's box so not sure I'd remember to always put them in
> first but definitely nice to have when you make the full CUBE config.
>
> Looks like all you're missing is your fax config! I can fax that over to
> you! :)
>
> On Fri, Jun 12, 2020 at 8:53 PM Anthony Holloway <
> avholloway+cisco-voip@gmail.com> wrote:
>
>> All great points, thanks for taking the time to respond.
>>
>> The only one I think that I need to reply to is the DPG and
>> destination-pattern one. I was actually troubleshooting a customer CUBE
>> wherein this exact scenario was in place and the only negative was getting
>> options to work. Otherwise, it was routing the call just fine. Granted, I
>> couldn't tell you what version that was, as it was like a year or so ago,
>> but either way, I always put a destination-pattern on because you need one
>> for options to function.
>>
>> I guess I could reply to one more, and that has to do with tweaking
>> retries from 6 to 2 AND using options. Why stick to one, when you can do
>> both?
>>
>> Here's the one I use which I said was very similar to yours.
>>
>> The first thing to note is the numeric structure of my tags.
>>
>> 1000 series numbers are the ITSP side
>> 2000 series numbers are the CUCM side
>>
>> I would expand this to 3000, 4000, etc., for additional integrations like
>> PRIs, FXO, second ITSP, second PBX, etc. Most I ever had was 6
>> integrations into a single CUBE i think.
>>
>> The second digit is 1 for incoming and 2 for outgoing.
>>
>> The 4rd and fourth digit are generally not used, unless I need additional
>> dial-peers for the same peer and direction, but doing something slightly
>> different. Most I ever used was like 15 i think. E.g., 2215 But that was
>> not using IP addresses in the matching and DPGs, that was using phone
>> number matching, and I was using steering codes.
>>
>> This numbering structure allows me to do something like this:
>>
>> show run | section 12..
>>
>> Which would then show me the following all at once: URI, Server Group,
>> Profile and Dial Peers all pertaining to the outgoing ITSP leg.
>>
>> Also, in this example, we pass +E164 through the gateway
>> bi-directionally, so no digit manip needed.
>>
>> voice class uri 1100 sip
>> host ipv4:8.8.8.8
>> host ipv4:9.9.9.9
>> !
>> voice class server-group 1200
>> description ITSP Peers
>> ipv4 8.8.8.8 preference 1
>> ipv4 9.9.9.9 preference 2
>> !
>> voice class sip-options-keepalive 1200
>> description ITSP Peers (Intentionally Left Blank)
>> !
>> voice class uri 2100 sip
>> host ipv4:10.1.1.2
>> host ipv4:10.1.1.3
>> !
>> voice class server-group 2200
>> description CUCM Nodes
>> ipv4 10.1.1.2 preference 1
>> ipv4 10.1.1.3 preference 2
>> !
>> voice class sip-options-keepalive 2200
>> description CUCM Nodes (Intentionally Left Blank)
>> !
>> voice class dpg 1200
>> dial-peer 1200
>> !
>> voice class dpg 2200
>> dial-peer 2200
>> !
>> dial-peer voice 1100 voip
>> description Incoming ITSP Call Leg
>> session protocol sipv2
>> incoming uri via 1100
>> destination dpg 2200
>> dtmf-relay rtp-nte ; ITSP only supports one dtmf relay
>> codec g711ulaw ; ITSP only supports one codec
>> ip qos dscp cs3 signaling
>> no vad
>> !
>> dial-peer voice 1200 voip
>> description Outgoing ITSP Call Leg
>> destination-pattern ABC123
>> session protocol sipv2
>> session server-group 1200
>> voice-class sip options-keepalive profile 1200
>> dtmf-relay rtp-nte
>> codec g711ulaw
>> ip qos dscp cs3 signaling
>> no vad
>> !
>> dial-peer voice 2100 voip
>> description Incoming CUCM Call Leg
>> session protocol sipv2
>> incoming uri via 2100
>> destination dpg 1200
>> dtmf-relay sip-kpml rtp-nte ; we support both in- and out-of-band
>> internally and cube interworks dtmf
>> codec g711ulaw
>> ip qos dscp cs3 signaling
>> no vad
>> !
>> dial-peer voice 2200 voip
>> description Outgoing CUCM Call Leg
>> session protocol sipv2
>> session server-group 2200
>> destination-pattern ABC123
>> voice-class sip options-keepalive profile 2200
>> dtmf-relay sip-kpml rtp-nte
>> codec g711ulaw
>> ip qos dscp cs3 signaling
>> no vad
>> !
>> ! a little something extra here at the end
>> alias exec attra show call active voice | in
>> PeerAddr|PeerId|RemoteS|RemoteM|Dtmf|Coder|VAD
>> alias exec attrh show call history voice | in
>> PeerAddr|PeerId|RemoteS|RemoteM|Dtmf|Coder|VAD
>>
>> On Fri, Jun 12, 2020 at 6:36 PM Brian Meade <bmeade90@vt.edu> wrote:
>>
>>> Anthony,
>>>
>>> Thanks for the feedback. I'll definitely take a look at yours as well.
>>>
>>> Here's some answers on mine:
>>> 1. While I like that you can give a uri profile a name like ISP, I much
>>> prefer to stick with numbers, since for most things, you must use numbers
>>> when naming, so this keeps it consistent.
>>> So I usually replace this with the name of the actual SIP carrier. This
>>> seems to make it easier for customers to understand but I understand so
>>> many other things are number tags only.
>>> 2. I don't specify the port in my server groups, since 5060 is default,
>>> but I can see how it might help be more explicit for some people
>>> Yea, I've never tried it without specifying the port. I've got a lot of
>>> SIP carriers with weird SIP ports so making it stand out in the template
>>> helps to know where to change this.
>>> 3. Speaking of being explicit though, if that is your intention, I would
>>> recommend pref 1 and pref 2, instead of implied pref 0 and pref 1
>>> That's a good idea. I actually exported this from a customer not
>>> realizing what it looks like when I use pref 0 and 1. Making it 1 and 2
>>> would make that look cleaner.
>>> 4. Why didn't you should your translation profiles and rules too?
>>> These seem to be so customer/SIP carrier specific that I didn't think it
>>> was worth it. My most recent one had 80 rules in it because the carrier
>>> really cares about 10-digit/11-digit calling for the local area code. So
>>> we actually had to split it up for different NPA-NXX whether or not we
>>> added a 1.
>>> 5. I don't specify UDP as the transport, since it's the default, but
>>> again, being explicit doesn't hurt anything
>>> I also make UDP my default but it is nice to have it called out in a
>>> template so people know where to change it if needed.
>>> 6. I like the extra dtmf on there. too many configs are limited to
>>> rtp-nte only and mtps are being invoked for every call to UCCX as one
>>> example
>>> Yea, I always add both to make sure we never have to pull in an MTP.
>>> I'm not aware of a way to do this globally but would be nice.
>>> 7. Why do you drop your fax rate down from 14400 to 9600 as a standard?
>>> I might learn something here, as faxing is not my strongest area.
>>> I'm always debugging faxing it seems like. Disabling ECM and reducing
>>> speed to 9600 has seemed to help a lot over the years. It's slower but
>>> seems to work more reliably with every source/destination fax device. And
>>> people don't expect their fax to send quickly anyways.
>>> 8. Since you're doing DPGs, you don't need the destination-pattern .T
>>> command on the outbound DPs.
>>> It seems like IOS-XE will show a dial-peer as down and skip it if there
>>> is no destination-pattern configured. This looks to be called out as
>>> explicitely required here even though it isn't used-
>>> https://cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/multiple-outbound-dial-peer.html
>>>
>>> Using something like ABC123 for the destination-pattern may make more
>>> sense to not confuse anyone. Good call.
>>> 9a. Why are you not doing sip options ping? I would, and in which case
>>> you need a voice class sip options-keepalive profile
>>> <https://community.cisco.com/t5/telepresence-and-video/sip-options-ping-and-session-server-group-on-dial-peer/td-p/2994584> since
>>> you're using server groups.
>>> I've never been a fan of SIP Options ping. I've always used SIP timers
>>> for failover instead. I guess I've had a few outages where waiting for
>>> Options Ping to come back up after we fixed the underlying issue added
>>> additional delay. For monitoring purposes though, it probably is a good
>>> idea to get back into doing that for customers where we're monitoring their
>>> CUBEs.
>>> 9b. Also, if you do end up turning on options, you do in fact need a
>>> destination-pattern command, and in which case, since it's not being used
>>> for call routing, I just use like ABC123 as the pattern to ensure it never
>>> can be used, but also, mildly clear it's not supposed to be used
>>> I like that idea and referenced it in 8 above.
>>>
>>>
>>>
>>> On Fri, Jun 12, 2020 at 6:29 PM Anthony Holloway <
>>> avholloway+cisco-voip@gmail.com> wrote:
>>>
>>>> Brian,
>>>>
>>>> Nice and clean, I like it! Very similar to what I do. I'd like to
>>>> comment/question yours a bit.
>>>>
>>>> 1. While I like that you can give a uri profile a name like ISP, I much
>>>> prefer to stick with numbers, since for most things, you must use numbers
>>>> when naming, so this keeps it consistent.
>>>> 2. I don't specify the port in my server groups, since 5060 is default,
>>>> but I can see how it might help be more explicit for some people
>>>> 3. Speaking of being explicit though, if that is your intention, I
>>>> would recommend pref 1 and pref 2, instead of implied pref 0 and pref 1
>>>> 4. Why didn't you should your translation profiles and rules too?
>>>> 5. I don't specify UDP as the transport, since it's the default, but
>>>> again, being explicit doesn't hurt anything
>>>> 6. I like the extra dtmf on there. too many configs are limited to
>>>> rtp-nte only and mtps are being invoked for every call to UCCX as one
>>>> example
>>>> 7. Why do you drop your fax rate down from 14400 to 9600 as a
>>>> standard? I might learn something here, as faxing is not my strongest area.
>>>> 8. Since you're doing DPGs, you don't need the destination-pattern .T
>>>> command on the outbound DPs.
>>>> 9a. Why are you not doing sip options ping? I would, and in which case
>>>> you need a voice class sip options-keepalive profile
>>>> <https://community.cisco.com/t5/telepresence-and-video/sip-options-ping-and-session-server-group-on-dial-peer/td-p/2994584>
>>>> since you're using server groups.
>>>> 9b. Also, if you do end up turning on options, you do in fact need a
>>>> destination-pattern command, and in which case, since it's not being used
>>>> for call routing, I just use like ABC123 as the pattern to ensure it never
>>>> can be used, but also, mildly clear it's not supposed to be used
>>>>
>>>> I'll post a config as well, in a bit, and please feel free to
>>>> comment/question mine.
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Jun 12, 2020 at 3:20 PM Brian Meade <bmeade90@vt.edu> wrote:
>>>>
>>>>> I've been trying to make a standardized CUBE configuration using a lot
>>>>> of the newer features like dial-peer groups.
>>>>>
>>>>> This is what I have now. It's an inbound dial-peer for CUCM matching
>>>>> the CUCM IP's via Via header. Then an inbound dial-peer for the ISP. Then
>>>>> an outbound dial-peer to CUCM and an outbound dial-peer to the ISP. If you
>>>>> have more IP's for the ISP or CUCM, you can easily add them.
>>>>> destination-pattern .T is not used at all due to using dial-peer group
>>>>> matching. This doesn't account for bindings that must be done per
>>>>> dial-peer. It also doesn't show translation-profiles/rules.
>>>>>
>>>>> This gives you 4 total dial-peers to match any number.
>>>>>
>>>>> If it comes in from CUCM, it will route to the SIP carrier. If it
>>>>> comes in from the SIP carrier, it will route to CUCM.
>>>>>
>>>>> voice class uri ISP sip
>>>>> host ipv4:8.8.8.8
>>>>>
>>>>> voice class uri CUCM sip
>>>>> host ipv4:192.168.100.100
>>>>> host ipv4:192.168.100.200
>>>>>
>>>>> voice class server-group 100
>>>>> ipv4 8.8.8.8 port 5060
>>>>>
>>>>> voice class server-group 200
>>>>> ipv4 192.168.100.100 port 5060
>>>>> ipv4 192.168.100.200 port 5060 preference 1
>>>>>
>>>>> voice class dpg 100
>>>>>
>>>>> voice class dpg 200
>>>>>
>>>>> dial-peer voice 100 voip
>>>>> description Incoming Dial-peer from ISP
>>>>> translation-profile incoming ISPInbound
>>>>> session protocol sipv2
>>>>> session transport udp
>>>>> destination dpg 200
>>>>> incoming uri via ISP
>>>>> voice-class codec 1
>>>>> dtmf-relay rtp-nte sip-kpml
>>>>> fax-relay ecm disable
>>>>> fax rate 9600
>>>>>
>>>>> dial-peer voice 200 voip
>>>>> description Incoming Dial-peer from CUCM
>>>>> session protocol sipv2
>>>>> destination dpg 100
>>>>> incoming uri via CUCM
>>>>> voice-class codec 1
>>>>> dtmf-relay rtp-nte sip-kpml
>>>>> fax-relay ecm disable
>>>>> fax rate 9600
>>>>>
>>>>> dial-peer voice 300 voip
>>>>> description Outbound to ISP
>>>>> translation-profile outgoing ISPOutbound
>>>>> destination-pattern .T
>>>>> session protocol sipv2
>>>>> session transport udp
>>>>> session server-group 100
>>>>> voice-class codec 1
>>>>> dtmf-relay rtp-nte sip-kpml
>>>>> fax-relay ecm disable
>>>>> fax rate 9600
>>>>>
>>>>> dial-peer voice 400 voip
>>>>> description Outbound to CUCM
>>>>> destination-pattern .T
>>>>> session protocol sipv2
>>>>> session server-group 200
>>>>> voice-class codec 1
>>>>> dtmf-relay rtp-nte sip-kpml
>>>>> fax-relay ecm disable
>>>>> fax rate 9600
>>>>>
>>>>> voice class dpg 100
>>>>> dial-peer 300
>>>>>
>>>>> voice class dpg 200
>>>>> dial-peer 400
>>>>>
>>>>> On Fri, Jun 12, 2020 at 3:12 PM JASON BURWELL via cisco-voip <
>>>>> cisco-voip@puck.nether.net> wrote:
>>>>>
>>>>>> Does anyone have a good, straightforward reference doc to configuring
>>>>>> CUBE dial peers? I have what I would have thought should be a fairly basic
>>>>>> config but I’m having trouble getting everything to work properly. I’ve had
>>>>>> some assistance but it seems like a whole lot of configuration to do what
>>>>>> little I really need to do. Basically, I just need to send whatever comes
>>>>>> from CUCM- either 10, 11 or 3 digits in the SIP invite for outbound and for
>>>>>> inbound calls the provider sends me 10 digits in the invite, I just need to
>>>>>> strip off the first 6 and send the last 4 to CUCM to route. I have a lot of
>>>>>> adding and stripping digits going on between CUCM and CUBE to make this
>>>>>> work. Just trying to find reference docs to see if any of this can be
>>>>>> cleaned up. Thanks
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>

Nice to see the examples and explanations - thank you! I really like the naming structure to allow simple a show command to pull everything related to one side of the call flow.
URI matching broke down in UCCE environments as uri match overrides all other matching. I needed to match some ingress numbers from the ITSP to apply CVP .tcl scripts too and wasn’t able to when matching all inbound from ITSP via URI. So the config gets a bit longer in UCCE environments due to this.
I ended up using e164-pattern-maps as another means of collapsing dial-peers, with uri match for calls from CUCM, and also server-groups to reduce outbound peers.
Based on the configs from Brian and Anthony, you wouldn’t need e164-pattern-maps in those environments. Curious what direction others have taken to simplify dial-peers with UCCE in play.

Loren

On Jun 16, 2020, at 10:55 AM, Anthony Holloway <avholloway+cisco-voip@gmail.com> wrote:

?
Sorry, transmission failed. Try disabling NSF and re-sending.

Back to the point of ABC123, it would be so nice if we could add comments to the show run. Second best is to keep a commented copy of the config off box in your documentation repository.

On Mon, Jun 15, 2020 at 11:31 PM Brian Meade <bmeade90@vt.edu<mailto:bmeade90@vt.edu>> wrote:
Anthony,

I like the config. Definitely is nice to have some standardization on the dial-peer tags. I've usually done all my inbound dial-peers in the 1XX range but have gone outside of that lately with separating inbound ITSP and inbound CUCM dial-peers to make them more obvious but I like the idea of having more structure like yours.

Using the destination-pattern ABC123 is a great idea to show that's not used as mentioned before.

I try to always use voice-class codec for every dial-peer even if I've only got 1 codec configured there just to make it easier to change if ever needed but that was in the past when I had separate local/long distance/911/international/10-digit dial-peers. Simplifying it down to a single inbound/outbound dial-peer with the ITSP makes it a toss-up if that helps anymore.

I've tried to keep KPML on my ITSP facing dial-peers just in case they happen to support it. I've found some say they don't but actually do use it if you advertise it. No harm in advertising it from our side.

I like the aliases you've got there as well. I feel like I'm always on some random customer's box so not sure I'd remember to always put them in first but definitely nice to have when you make the full CUBE config.

Looks like all you're missing is your fax config! I can fax that over to you! :)

On Fri, Jun 12, 2020 at 8:53 PM Anthony Holloway <avholloway+cisco-voip@gmail.com<mailto:avholloway%2Bcisco-voip@gmail.com>> wrote:
All great points, thanks for taking the time to respond.

The only one I think that I need to reply to is the DPG and destination-pattern one. I was actually troubleshooting a customer CUBE wherein this exact scenario was in place and the only negative was getting options to work. Otherwise, it was routing the call just fine. Granted, I couldn't tell you what version that was, as it was like a year or so ago, but either way, I always put a destination-pattern on because you need one for options to function.

I guess I could reply to one more, and that has to do with tweaking retries from 6 to 2 AND using options. Why stick to one, when you can do both?

Here's the one I use which I said was very similar to yours.

The first thing to note is the numeric structure of my tags.

1000 series numbers are the ITSP side
2000 series numbers are the CUCM side

I would expand this to 3000, 4000, etc., for additional integrations like PRIs, FXO, second ITSP, second PBX, etc. Most I ever had was 6 integrations into a single CUBE i think.

The second digit is 1 for incoming and 2 for outgoing.

The 4rd and fourth digit are generally not used, unless I need additional dial-peers for the same peer and direction, but doing something slightly different. Most I ever used was like 15 i think. E.g., 2215 But that was not using IP addresses in the matching and DPGs, that was using phone number matching, and I was using steering codes.

This numbering structure allows me to do something like this:

show run | section 12..

Which would then show me the following all at once: URI, Server Group, Profile and Dial Peers all pertaining to the outgoing ITSP leg.

Also, in this example, we pass +E164 through the gateway bi-directionally, so no digit manip needed.

voice class uri 1100 sip
host ipv4:8.8.8.8
host ipv4:9.9.9.9
!
voice class server-group 1200
description ITSP Peers
ipv4 8.8.8.8 preference 1
ipv4 9.9.9.9 preference 2
!
voice class sip-options-keepalive 1200
description ITSP Peers (Intentionally Left Blank)
!
voice class uri 2100 sip
host ipv4:10.1.1.2
host ipv4:10.1.1.3
!
voice class server-group 2200
description CUCM Nodes
ipv4 10.1.1.2 preference 1
ipv4 10.1.1.3 preference 2
!
voice class sip-options-keepalive 2200
description CUCM Nodes (Intentionally Left Blank)
!
voice class dpg 1200
dial-peer 1200
!
voice class dpg 2200
dial-peer 2200
!
dial-peer voice 1100 voip
description Incoming ITSP Call Leg
session protocol sipv2
incoming uri via 1100
destination dpg 2200
dtmf-relay rtp-nte ; ITSP only supports one dtmf relay
codec g711ulaw ; ITSP only supports one codec
ip qos dscp cs3 signaling
no vad
!
dial-peer voice 1200 voip
description Outgoing ITSP Call Leg
destination-pattern ABC123
session protocol sipv2
session server-group 1200
voice-class sip options-keepalive profile 1200
dtmf-relay rtp-nte
codec g711ulaw
ip qos dscp cs3 signaling
no vad
!
dial-peer voice 2100 voip
description Incoming CUCM Call Leg
session protocol sipv2
incoming uri via 2100
destination dpg 1200
dtmf-relay sip-kpml rtp-nte ; we support both in- and out-of-band internally and cube interworks dtmf
codec g711ulaw
ip qos dscp cs3 signaling
no vad
!
dial-peer voice 2200 voip
description Outgoing CUCM Call Leg
session protocol sipv2
session server-group 2200
destination-pattern ABC123
voice-class sip options-keepalive profile 2200
dtmf-relay sip-kpml rtp-nte
codec g711ulaw
ip qos dscp cs3 signaling
no vad
!
! a little something extra here at the end
alias exec attra show call active voice | in PeerAddr|PeerId|RemoteS|RemoteM|Dtmf|Coder|VAD
alias exec attrh show call history voice | in PeerAddr|PeerId|RemoteS|RemoteM|Dtmf|Coder|VAD

On Fri, Jun 12, 2020 at 6:36 PM Brian Meade <bmeade90@vt.edu<mailto:bmeade90@vt.edu>> wrote:
Anthony,

Thanks for the feedback. I'll definitely take a look at yours as well.

Here's some answers on mine:
1. While I like that you can give a uri profile a name like ISP, I much prefer to stick with numbers, since for most things, you must use numbers when naming, so this keeps it consistent.
So I usually replace this with the name of the actual SIP carrier. This seems to make it easier for customers to understand but I understand so many other things are number tags only.
2. I don't specify the port in my server groups, since 5060 is default, but I can see how it might help be more explicit for some people
Yea, I've never tried it without specifying the port. I've got a lot of SIP carriers with weird SIP ports so making it stand out in the template helps to know where to change this.
3. Speaking of being explicit though, if that is your intention, I would recommend pref 1 and pref 2, instead of implied pref 0 and pref 1
That's a good idea. I actually exported this from a customer not realizing what it looks like when I use pref 0 and 1. Making it 1 and 2 would make that look cleaner.
4. Why didn't you should your translation profiles and rules too?
These seem to be so customer/SIP carrier specific that I didn't think it was worth it. My most recent one had 80 rules in it because the carrier really cares about 10-digit/11-digit calling for the local area code. So we actually had to split it up for different NPA-NXX whether or not we added a 1.
5. I don't specify UDP as the transport, since it's the default, but again, being explicit doesn't hurt anything
I also make UDP my default but it is nice to have it called out in a template so people know where to change it if needed.
6. I like the extra dtmf on there. too many configs are limited to rtp-nte only and mtps are being invoked for every call to UCCX as one example
Yea, I always add both to make sure we never have to pull in an MTP. I'm not aware of a way to do this globally but would be nice.
7. Why do you drop your fax rate down from 14400 to 9600 as a standard? I might learn something here, as faxing is not my strongest area.
I'm always debugging faxing it seems like. Disabling ECM and reducing speed to 9600 has seemed to help a lot over the years. It's slower but seems to work more reliably with every source/destination fax device. And people don't expect their fax to send quickly anyways.
8. Since you're doing DPGs, you don't need the destination-pattern .T command on the outbound DPs.
It seems like IOS-XE will show a dial-peer as down and skip it if there is no destination-pattern configured. This looks to be called out as explicitely required here even though it isn't used- https://cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/multiple-outbound-dial-peer.html

Using something like ABC123 for the destination-pattern may make more sense to not confuse anyone. Good call.
9a. Why are you not doing sip options ping? I would, and in which case you need a voice class sip options-keepalive profile<https://community.cisco.com/t5/telepresence-and-video/sip-options-ping-and-session-server-group-on-dial-peer/td-p/2994584> since you're using server groups.
I've never been a fan of SIP Options ping. I've always used SIP timers for failover instead. I guess I've had a few outages where waiting for Options Ping to come back up after we fixed the underlying issue added additional delay. For monitoring purposes though, it probably is a good idea to get back into doing that for customers where we're monitoring their CUBEs.
9b. Also, if you do end up turning on options, you do in fact need a destination-pattern command, and in which case, since it's not being used for call routing, I just use like ABC123 as the pattern to ensure it never can be used, but also, mildly clear it's not supposed to be used
I like that idea and referenced it in 8 above.



On Fri, Jun 12, 2020 at 6:29 PM Anthony Holloway <avholloway+cisco-voip@gmail.com<mailto:avholloway%2Bcisco-voip@gmail.com>> wrote:
Brian,

Nice and clean, I like it! Very similar to what I do. I'd like to comment/question yours a bit.

1. While I like that you can give a uri profile a name like ISP, I much prefer to stick with numbers, since for most things, you must use numbers when naming, so this keeps it consistent.
2. I don't specify the port in my server groups, since 5060 is default, but I can see how it might help be more explicit for some people
3. Speaking of being explicit though, if that is your intention, I would recommend pref 1 and pref 2, instead of implied pref 0 and pref 1
4. Why didn't you should your translation profiles and rules too?
5. I don't specify UDP as the transport, since it's the default, but again, being explicit doesn't hurt anything
6. I like the extra dtmf on there. too many configs are limited to rtp-nte only and mtps are being invoked for every call to UCCX as one example
7. Why do you drop your fax rate down from 14400 to 9600 as a standard? I might learn something here, as faxing is not my strongest area.
8. Since you're doing DPGs, you don't need the destination-pattern .T command on the outbound DPs.
9a. Why are you not doing sip options ping? I would, and in which case you need a voice class sip options-keepalive profile<https://community.cisco.com/t5/telepresence-and-video/sip-options-ping-and-session-server-group-on-dial-peer/td-p/2994584> since you're using server groups.
9b. Also, if you do end up turning on options, you do in fact need a destination-pattern command, and in which case, since it's not being used for call routing, I just use like ABC123 as the pattern to ensure it never can be used, but also, mildly clear it's not supposed to be used

I'll post a config as well, in a bit, and please feel free to comment/question mine.




On Fri, Jun 12, 2020 at 3:20 PM Brian Meade <bmeade90@vt.edu<mailto:bmeade90@vt.edu>> wrote:
I've been trying to make a standardized CUBE configuration using a lot of the newer features like dial-peer groups.

This is what I have now. It's an inbound dial-peer for CUCM matching the CUCM IP's via Via header. Then an inbound dial-peer for the ISP. Then an outbound dial-peer to CUCM and an outbound dial-peer to the ISP. If you have more IP's for the ISP or CUCM, you can easily add them. destination-pattern .T is not used at all due to using dial-peer group matching. This doesn't account for bindings that must be done per dial-peer. It also doesn't show translation-profiles/rules.

This gives you 4 total dial-peers to match any number.

If it comes in from CUCM, it will route to the SIP carrier. If it comes in from the SIP carrier, it will route to CUCM.

voice class uri ISP sip
host ipv4:8.8.8.8

voice class uri CUCM sip
host ipv4:192.168.100.100
host ipv4:192.168.100.200

voice class server-group 100
ipv4 8.8.8.8 port 5060

voice class server-group 200
ipv4 192.168.100.100 port 5060
ipv4 192.168.100.200 port 5060 preference 1

voice class dpg 100

voice class dpg 200

dial-peer voice 100 voip
description Incoming Dial-peer from ISP
translation-profile incoming ISPInbound
session protocol sipv2
session transport udp
destination dpg 200
incoming uri via ISP
voice-class codec 1
dtmf-relay rtp-nte sip-kpml
fax-relay ecm disable
fax rate 9600

dial-peer voice 200 voip
description Incoming Dial-peer from CUCM
session protocol sipv2
destination dpg 100
incoming uri via CUCM
voice-class codec 1
dtmf-relay rtp-nte sip-kpml
fax-relay ecm disable
fax rate 9600

dial-peer voice 300 voip
description Outbound to ISP
translation-profile outgoing ISPOutbound
destination-pattern .T
session protocol sipv2
session transport udp
session server-group 100
voice-class codec 1
dtmf-relay rtp-nte sip-kpml
fax-relay ecm disable
fax rate 9600

dial-peer voice 400 voip
description Outbound to CUCM
destination-pattern .T
session protocol sipv2
session server-group 200
voice-class codec 1
dtmf-relay rtp-nte sip-kpml
fax-relay ecm disable
fax rate 9600

voice class dpg 100
dial-peer 300

voice class dpg 200
dial-peer 400

On Fri, Jun 12, 2020 at 3:12 PM JASON BURWELL via cisco-voip <cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>> wrote:
Does anyone have a good, straightforward reference doc to configuring CUBE dial peers? I have what I would have thought should be a fairly basic config but I’m having trouble getting everything to work properly. I’ve had some assistance but it seems like a whole lot of configuration to do what little I really need to do. Basically, I just need to send whatever comes from CUCM- either 10, 11 or 3 digits in the SIP invite for outbound and for inbound calls the provider sends me 10 digits in the invite, I just need to strip off the first 6 and send the last 4 to CUCM to route. I have a lot of adding and stripping digits going on between CUCM and CUBE to make this work. Just trying to find reference docs to see if any of this can be cleaned up. Thanks
_______________________________________________
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

Well once Loren speaks up you know it’s an interesting thread.



My two cents, I cannot stand DPG. Its crazy that it completely ignores destination pattern. If you have two destinations in the group, it just round-robins them. I got burned not understanding that DPG didn’t look at destination pattern and I swore I would never use them again.



I use cor-list to restrict the SP inbound dial-peer to the cucm outbound dial-peer, and vice versa. Matching the inbound dial-peer by URI works great, I started with matching “FROM” but that fell apart in some cases, so I use VIA by default now, and that has been solid.



My numbering is usually 1X for CUCM, with the 0 for inbound in each range, then 2X for the first SIP provider and 3X for the 2nd, maybe 5X for CVP etc.



I always localize on the CUBE, sending a full +E.164 from CUCM and then use translation profiles to format to how the specific country/carrier wants to see the calls. The exception is US 11D/10D determination is done by the CUCM because I find it easier to load all of the local NPA-NXX into CUCM route filters via AXL, but then sometimes I am doing TEHO and have to control which outbound dial-peer it chooses.



I also never let the CUBE choose the carrier, I think mostly because a long time ago I had the same carrier spread over multiple gateways along with multiple carriers in each gateway, and I wanted CUCM to re-route to the other gateway same carrier before CUBE used a less preferred route because it was local. So when there is multiple carriers I usually will prefix 1#* or 2#* on up for each carrier.



Anyway, that’s my 2 cents.





From: cisco-voip <cisco-voip-bounces@puck.nether.net> On Behalf Of Loren Hillukka
Sent: Tuesday, June 16, 2020 10:26 AM
To: Anthony Holloway <avholloway+cisco-voip@gmail.com>
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] CUBE Config Dial Peers



Nice to see the examples and explanations - thank you! I really like the naming structure to allow simple a show command to pull everything related to one side of the call flow.

URI matching broke down in UCCE environments as uri match overrides all other matching. I needed to match some ingress numbers from the ITSP to apply CVP .tcl scripts too and wasn’t able to when matching all inbound from ITSP via URI. So the config gets a bit longer in UCCE environments due to this.

I ended up using e164-pattern-maps as another means of collapsing dial-peers, with uri match for calls from CUCM, and also server-groups to reduce outbound peers.

Based on the configs from Brian and Anthony, you wouldn’t need e164-pattern-maps in those environments. Curious what direction others have taken to simplify dial-peers with UCCE in play.



Loren





On Jun 16, 2020, at 10:55 AM, Anthony Holloway <avholloway+cisco-voip@gmail.com <mailto:avholloway+cisco-voip@gmail.com> > wrote:

?

Sorry, transmission failed. Try disabling NSF and re-sending.



Back to the point of ABC123, it would be so nice if we could add comments to the show run. Second best is to keep a commented copy of the config off box in your documentation repository.



On Mon, Jun 15, 2020 at 11:31 PM Brian Meade <bmeade90@vt.edu <mailto:bmeade90@vt.edu> > wrote:

Anthony,



I like the config. Definitely is nice to have some standardization on the dial-peer tags. I've usually done all my inbound dial-peers in the 1XX range but have gone outside of that lately with separating inbound ITSP and inbound CUCM dial-peers to make them more obvious but I like the idea of having more structure like yours.



Using the destination-pattern ABC123 is a great idea to show that's not used as mentioned before.



I try to always use voice-class codec for every dial-peer even if I've only got 1 codec configured there just to make it easier to change if ever needed but that was in the past when I had separate local/long distance/911/international/10-digit dial-peers. Simplifying it down to a single inbound/outbound dial-peer with the ITSP makes it a toss-up if that helps anymore.



I've tried to keep KPML on my ITSP facing dial-peers just in case they happen to support it. I've found some say they don't but actually do use it if you advertise it. No harm in advertising it from our side.



I like the aliases you've got there as well. I feel like I'm always on some random customer's box so not sure I'd remember to always put them in first but definitely nice to have when you make the full CUBE config.



Looks like all you're missing is your fax config! I can fax that over to you! :)



On Fri, Jun 12, 2020 at 8:53 PM Anthony Holloway <avholloway+cisco-voip@gmail.com <mailto:avholloway%2Bcisco-voip@gmail.com> > wrote:

All great points, thanks for taking the time to respond.



The only one I think that I need to reply to is the DPG and destination-pattern one. I was actually troubleshooting a customer CUBE wherein this exact scenario was in place and the only negative was getting options to work. Otherwise, it was routing the call just fine. Granted, I couldn't tell you what version that was, as it was like a year or so ago, but either way, I always put a destination-pattern on because you need one for options to function.



I guess I could reply to one more, and that has to do with tweaking retries from 6 to 2 AND using options. Why stick to one, when you can do both?



Here's the one I use which I said was very similar to yours.



The first thing to note is the numeric structure of my tags.



1000 series numbers are the ITSP side

2000 series numbers are the CUCM side



I would expand this to 3000, 4000, etc., for additional integrations like PRIs, FXO, second ITSP, second PBX, etc. Most I ever had was 6 integrations into a single CUBE i think.



The second digit is 1 for incoming and 2 for outgoing.



The 4rd and fourth digit are generally not used, unless I need additional dial-peers for the same peer and direction, but doing something slightly different. Most I ever used was like 15 i think. E.g., 2215 But that was not using IP addresses in the matching and DPGs, that was using phone number matching, and I was using steering codes.



This numbering structure allows me to do something like this:



show run | section 12..



Which would then show me the following all at once: URI, Server Group, Profile and Dial Peers all pertaining to the outgoing ITSP leg.



Also, in this example, we pass +E164 through the gateway bi-directionally, so no digit manip needed.



voice class uri 1100 sip

host ipv4:8.8.8.8

host ipv4:9.9.9.9

!

voice class server-group 1200

description ITSP Peers

ipv4 8.8.8.8 preference 1

ipv4 9.9.9.9 preference 2

!

voice class sip-options-keepalive 1200

description ITSP Peers (Intentionally Left Blank)

!

voice class uri 2100 sip

host ipv4:10.1.1.2

host ipv4:10.1.1.3

!

voice class server-group 2200

description CUCM Nodes

ipv4 10.1.1.2 preference 1

ipv4 10.1.1.3 preference 2

!

voice class sip-options-keepalive 2200

description CUCM Nodes (Intentionally Left Blank)

!

voice class dpg 1200

dial-peer 1200

!

voice class dpg 2200

dial-peer 2200

!

dial-peer voice 1100 voip

description Incoming ITSP Call Leg

session protocol sipv2

incoming uri via 1100

destination dpg 2200

dtmf-relay rtp-nte ; ITSP only supports one dtmf relay

codec g711ulaw ; ITSP only supports one codec

ip qos dscp cs3 signaling

no vad

!

dial-peer voice 1200 voip

description Outgoing ITSP Call Leg

destination-pattern ABC123

session protocol sipv2

session server-group 1200

voice-class sip options-keepalive profile 1200

dtmf-relay rtp-nte

codec g711ulaw

ip qos dscp cs3 signaling

no vad

!

dial-peer voice 2100 voip

description Incoming CUCM Call Leg

session protocol sipv2

incoming uri via 2100

destination dpg 1200

dtmf-relay sip-kpml rtp-nte ; we support both in- and out-of-band internally and cube interworks dtmf

codec g711ulaw

ip qos dscp cs3 signaling

no vad

!

dial-peer voice 2200 voip

description Outgoing CUCM Call Leg

session protocol sipv2

session server-group 2200

destination-pattern ABC123

voice-class sip options-keepalive profile 2200

dtmf-relay sip-kpml rtp-nte

codec g711ulaw

ip qos dscp cs3 signaling

no vad

!

! a little something extra here at the end

alias exec attra show call active voice | in PeerAddr|PeerId|RemoteS|RemoteM|Dtmf|Coder|VAD

alias exec attrh show call history voice | in PeerAddr|PeerId|RemoteS|RemoteM|Dtmf|Coder|VAD



On Fri, Jun 12, 2020 at 6:36 PM Brian Meade <bmeade90@vt.edu <mailto:bmeade90@vt.edu> > wrote:

Anthony,



Thanks for the feedback. I'll definitely take a look at yours as well.



Here's some answers on mine:

1. While I like that you can give a uri profile a name like ISP, I much prefer to stick with numbers, since for most things, you must use numbers when naming, so this keeps it consistent.

So I usually replace this with the name of the actual SIP carrier. This seems to make it easier for customers to understand but I understand so many other things are number tags only.

2. I don't specify the port in my server groups, since 5060 is default, but I can see how it might help be more explicit for some people

Yea, I've never tried it without specifying the port. I've got a lot of SIP carriers with weird SIP ports so making it stand out in the template helps to know where to change this.

3. Speaking of being explicit though, if that is your intention, I would recommend pref 1 and pref 2, instead of implied pref 0 and pref 1

That's a good idea. I actually exported this from a customer not realizing what it looks like when I use pref 0 and 1. Making it 1 and 2 would make that look cleaner.

4. Why didn't you should your translation profiles and rules too?

These seem to be so customer/SIP carrier specific that I didn't think it was worth it. My most recent one had 80 rules in it because the carrier really cares about 10-digit/11-digit calling for the local area code. So we actually had to split it up for different NPA-NXX whether or not we added a 1.

5. I don't specify UDP as the transport, since it's the default, but again, being explicit doesn't hurt anything

I also make UDP my default but it is nice to have it called out in a template so people know where to change it if needed.

6. I like the extra dtmf on there. too many configs are limited to rtp-nte only and mtps are being invoked for every call to UCCX as one example

Yea, I always add both to make sure we never have to pull in an MTP. I'm not aware of a way to do this globally but would be nice.

7. Why do you drop your fax rate down from 14400 to 9600 as a standard? I might learn something here, as faxing is not my strongest area.

I'm always debugging faxing it seems like. Disabling ECM and reducing speed to 9600 has seemed to help a lot over the years. It's slower but seems to work more reliably with every source/destination fax device. And people don't expect their fax to send quickly anyways.

8. Since you're doing DPGs, you don't need the destination-pattern .T command on the outbound DPs.

It seems like IOS-XE will show a dial-peer as down and skip it if there is no destination-pattern configured. This looks to be called out as explicitely required here even though it isn't used- https://cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/multiple-outbound-dial-peer.html



Using something like ABC123 for the destination-pattern may make more sense to not confuse anyone. Good call.

9a. Why are you not doing sip options ping? I would, and in which case you need a voice class sip options-keepalive profile <https://community.cisco.com/t5/telepresence-and-video/sip-options-ping-and-session-server-group-on-dial-peer/td-p/2994584> since you're using server groups.

I've never been a fan of SIP Options ping. I've always used SIP timers for failover instead. I guess I've had a few outages where waiting for Options Ping to come back up after we fixed the underlying issue added additional delay. For monitoring purposes though, it probably is a good idea to get back into doing that for customers where we're monitoring their CUBEs.

9b. Also, if you do end up turning on options, you do in fact need a destination-pattern command, and in which case, since it's not being used for call routing, I just use like ABC123 as the pattern to ensure it never can be used, but also, mildly clear it's not supposed to be used

I like that idea and referenced it in 8 above.







On Fri, Jun 12, 2020 at 6:29 PM Anthony Holloway <avholloway+cisco-voip@gmail.com <mailto:avholloway%2Bcisco-voip@gmail.com> > wrote:

Brian,



Nice and clean, I like it! Very similar to what I do. I'd like to comment/question yours a bit.



1. While I like that you can give a uri profile a name like ISP, I much prefer to stick with numbers, since for most things, you must use numbers when naming, so this keeps it consistent.

2. I don't specify the port in my server groups, since 5060 is default, but I can see how it might help be more explicit for some people

3. Speaking of being explicit though, if that is your intention, I would recommend pref 1 and pref 2, instead of implied pref 0 and pref 1

4. Why didn't you should your translation profiles and rules too?

5. I don't specify UDP as the transport, since it's the default, but again, being explicit doesn't hurt anything

6. I like the extra dtmf on there. too many configs are limited to rtp-nte only and mtps are being invoked for every call to UCCX as one example

7. Why do you drop your fax rate down from 14400 to 9600 as a standard? I might learn something here, as faxing is not my strongest area.

8. Since you're doing DPGs, you don't need the destination-pattern .T command on the outbound DPs.

9a. Why are you not doing sip options ping? I would, and in which case you need a voice class sip options-keepalive profile <https://community.cisco.com/t5/telepresence-and-video/sip-options-ping-and-session-server-group-on-dial-peer/td-p/2994584> since you're using server groups.

9b. Also, if you do end up turning on options, you do in fact need a destination-pattern command, and in which case, since it's not being used for call routing, I just use like ABC123 as the pattern to ensure it never can be used, but also, mildly clear it's not supposed to be used



I'll post a config as well, in a bit, and please feel free to comment/question mine.









On Fri, Jun 12, 2020 at 3:20 PM Brian Meade <bmeade90@vt.edu <mailto:bmeade90@vt.edu> > wrote:

I've been trying to make a standardized CUBE configuration using a lot of the newer features like dial-peer groups.



This is what I have now. It's an inbound dial-peer for CUCM matching the CUCM IP's via Via header. Then an inbound dial-peer for the ISP. Then an outbound dial-peer to CUCM and an outbound dial-peer to the ISP. If you have more IP's for the ISP or CUCM, you can easily add them. destination-pattern .T is not used at all due to using dial-peer group matching. This doesn't account for bindings that must be done per dial-peer. It also doesn't show translation-profiles/rules.



This gives you 4 total dial-peers to match any number.



If it comes in from CUCM, it will route to the SIP carrier. If it comes in from the SIP carrier, it will route to CUCM.

voice class uri ISP sip
host ipv4:8.8.8.8

voice class uri CUCM sip
host ipv4:192.168.100.100
host ipv4:192.168.100.200

voice class server-group 100
ipv4 8.8.8.8 port 5060

voice class server-group 200
ipv4 192.168.100.100 port 5060
ipv4 192.168.100.200 port 5060 preference 1



voice class dpg 100

voice class dpg 200



dial-peer voice 100 voip
description Incoming Dial-peer from ISP
translation-profile incoming ISPInbound
session protocol sipv2
session transport udp
destination dpg 200
incoming uri via ISP
voice-class codec 1
dtmf-relay rtp-nte sip-kpml
fax-relay ecm disable
fax rate 9600

dial-peer voice 200 voip
description Incoming Dial-peer from CUCM
session protocol sipv2
destination dpg 100
incoming uri via CUCM
voice-class codec 1
dtmf-relay rtp-nte sip-kpml
fax-relay ecm disable
fax rate 9600



dial-peer voice 300 voip
description Outbound to ISP
translation-profile outgoing ISPOutbound
destination-pattern .T
session protocol sipv2
session transport udp
session server-group 100
voice-class codec 1
dtmf-relay rtp-nte sip-kpml
fax-relay ecm disable
fax rate 9600

dial-peer voice 400 voip
description Outbound to CUCM
destination-pattern .T
session protocol sipv2
session server-group 200
voice-class codec 1
dtmf-relay rtp-nte sip-kpml
fax-relay ecm disable
fax rate 9600



voice class dpg 100
dial-peer 300

voice class dpg 200
dial-peer 400



On Fri, Jun 12, 2020 at 3:12 PM JASON BURWELL via cisco-voip <cisco-voip@puck.nether.net <mailto:cisco-voip@puck.nether.net> > wrote:

Does anyone have a good, straightforward reference doc to configuring CUBE dial peers? I have what I would have thought should be a fairly basic config but I’m having trouble getting everything to work properly. I’ve had some assistance but it seems like a whole lot of configuration to do what little I really need to do. Basically, I just need to send whatever comes from CUCM- either 10, 11 or 3 digits in the SIP invite for outbound and for inbound calls the provider sends me 10 digits in the invite, I just need to strip off the first 6 and send the last 4 to CUCM to route. I have a lot of adding and stripping digits going on between CUCM and CUBE to make this work. Just trying to find reference docs to see if any of this can be cleaned up. Thanks

_______________________________________________
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 <mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

"I cannot stand DPG"
"I use cor-list"

I bet you also are a sadist and use 9.@ too. You and Lelio should form a
posse and fight Brian and I. The losers must convert to the other's design.

On Tue, Jun 16, 2020 at 12:17 PM NateCCIE <nateccie@gmail.com> wrote:

> Well once Loren speaks up you know it’s an interesting thread.
>
>
>
> My two cents, I cannot stand DPG. Its crazy that it completely ignores
> destination pattern. If you have two destinations in the group, it just
> round-robins them. I got burned not understanding that DPG didn’t look at
> destination pattern and I swore I would never use them again.
>
>
>
> I use cor-list to restrict the SP inbound dial-peer to the cucm outbound
> dial-peer, and vice versa. Matching the inbound dial-peer by URI works
> great, I started with matching “FROM” but that fell apart in some cases, so
> I use VIA by default now, and that has been solid.
>
>
>
> My numbering is usually 1X for CUCM, with the 0 for inbound in each range,
> then 2X for the first SIP provider and 3X for the 2nd, maybe 5X for CVP
> etc.
>
>
>
> I always localize on the CUBE, sending a full +E.164 from CUCM and then
> use translation profiles to format to how the specific country/carrier
> wants to see the calls. The exception is US 11D/10D determination is done
> by the CUCM because I find it easier to load all of the local NPA-NXX into
> CUCM route filters via AXL, but then sometimes I am doing TEHO and have to
> control which outbound dial-peer it chooses.
>
>
>
> I also never let the CUBE choose the carrier, I think mostly because a
> long time ago I had the same carrier spread over multiple gateways along
> with multiple carriers in each gateway, and I wanted CUCM to re-route to
> the other gateway same carrier before CUBE used a less preferred route
> because it was local. So when there is multiple carriers I usually will
> prefix 1#* or 2#* on up for each carrier.
>
>
>
> Anyway, that’s my 2 cents.
>
>
>
>
>
> *From:* cisco-voip <cisco-voip-bounces@puck.nether.net> *On Behalf Of *Loren
> Hillukka
> *Sent:* Tuesday, June 16, 2020 10:26 AM
> *To:* Anthony Holloway <avholloway+cisco-voip@gmail.com>
> *Cc:* cisco-voip@puck.nether.net
> *Subject:* Re: [cisco-voip] CUBE Config Dial Peers
>
>
>
> Nice to see the examples and explanations - thank you! I really like the
> naming structure to allow simple a show command to pull everything related
> to one side of the call flow.
>
> URI matching broke down in UCCE environments as uri match overrides all
> other matching. I needed to match some ingress numbers from the ITSP to
> apply CVP .tcl scripts too and wasn’t able to when matching all inbound
> from ITSP via URI. So the config gets a bit longer in UCCE environments
> due to this.
>
> I ended up using e164-pattern-maps as another means of collapsing
> dial-peers, with uri match for calls from CUCM, and also server-groups to
> reduce outbound peers.
>
> Based on the configs from Brian and Anthony, you wouldn’t need
> e164-pattern-maps in those environments. Curious what direction others
> have taken to simplify dial-peers with UCCE in play.
>
>
>
> Loren
>
>
>
> On Jun 16, 2020, at 10:55 AM, Anthony Holloway <
> avholloway+cisco-voip@gmail.com> wrote:
>
> ?
>
> Sorry, transmission failed. Try disabling NSF and re-sending.
>
>
>
> Back to the point of ABC123, it would be so nice if we could add comments
> to the show run. Second best is to keep a commented copy of the config off
> box in your documentation repository.
>
>
>
> On Mon, Jun 15, 2020 at 11:31 PM Brian Meade <bmeade90@vt.edu> wrote:
>
> Anthony,
>
>
>
> I like the config. Definitely is nice to have some standardization on the
> dial-peer tags. I've usually done all my inbound dial-peers in the 1XX
> range but have gone outside of that lately with separating inbound ITSP and
> inbound CUCM dial-peers to make them more obvious but I like the idea of
> having more structure like yours.
>
>
>
> Using the destination-pattern ABC123 is a great idea to show that's not
> used as mentioned before.
>
>
>
> I try to always use voice-class codec for every dial-peer even if I've
> only got 1 codec configured there just to make it easier to change if ever
> needed but that was in the past when I had separate local/long
> distance/911/international/10-digit dial-peers. Simplifying it down to a
> single inbound/outbound dial-peer with the ITSP makes it a toss-up if that
> helps anymore.
>
>
>
> I've tried to keep KPML on my ITSP facing dial-peers just in case they
> happen to support it. I've found some say they don't but actually do use
> it if you advertise it. No harm in advertising it from our side.
>
>
>
> I like the aliases you've got there as well. I feel like I'm always on
> some random customer's box so not sure I'd remember to always put them in
> first but definitely nice to have when you make the full CUBE config.
>
>
>
> Looks like all you're missing is your fax config! I can fax that over to
> you! :)
>
>
>
> On Fri, Jun 12, 2020 at 8:53 PM Anthony Holloway <
> avholloway+cisco-voip@gmail.com> wrote:
>
> All great points, thanks for taking the time to respond.
>
>
>
> The only one I think that I need to reply to is the DPG and
> destination-pattern one. I was actually troubleshooting a customer CUBE
> wherein this exact scenario was in place and the only negative was getting
> options to work. Otherwise, it was routing the call just fine. Granted, I
> couldn't tell you what version that was, as it was like a year or so ago,
> but either way, I always put a destination-pattern on because you need one
> for options to function.
>
>
>
> I guess I could reply to one more, and that has to do with tweaking
> retries from 6 to 2 AND using options. Why stick to one, when you can do
> both?
>
>
>
> Here's the one I use which I said was very similar to yours.
>
>
>
> The first thing to note is the numeric structure of my tags.
>
>
>
> 1000 series numbers are the ITSP side
>
> 2000 series numbers are the CUCM side
>
>
>
> I would expand this to 3000, 4000, etc., for additional integrations like
> PRIs, FXO, second ITSP, second PBX, etc. Most I ever had was 6
> integrations into a single CUBE i think.
>
>
>
> The second digit is 1 for incoming and 2 for outgoing.
>
>
>
> The 4rd and fourth digit are generally not used, unless I need additional
> dial-peers for the same peer and direction, but doing something slightly
> different. Most I ever used was like 15 i think. E.g., 2215 But that was
> not using IP addresses in the matching and DPGs, that was using phone
> number matching, and I was using steering codes.
>
>
>
> This numbering structure allows me to do something like this:
>
>
>
> show run | section 12..
>
>
>
> Which would then show me the following all at once: URI, Server Group,
> Profile and Dial Peers all pertaining to the outgoing ITSP leg.
>
>
>
> Also, in this example, we pass +E164 through the gateway bi-directionally,
> so no digit manip needed.
>
>
>
> voice class uri 1100 sip
>
> host ipv4:8.8.8.8
>
> host ipv4:9.9.9.9
>
> !
>
> voice class server-group 1200
>
> description ITSP Peers
>
> ipv4 8.8.8.8 preference 1
>
> ipv4 9.9.9.9 preference 2
>
> !
>
> voice class sip-options-keepalive 1200
>
> description ITSP Peers (Intentionally Left Blank)
>
> !
>
> voice class uri 2100 sip
>
> host ipv4:10.1.1.2
>
> host ipv4:10.1.1.3
>
> !
>
> voice class server-group 2200
>
> description CUCM Nodes
>
> ipv4 10.1.1.2 preference 1
>
> ipv4 10.1.1.3 preference 2
>
> !
>
> voice class sip-options-keepalive 2200
>
> description CUCM Nodes (Intentionally Left Blank)
>
> !
>
> voice class dpg 1200
>
> dial-peer 1200
>
> !
>
> voice class dpg 2200
>
> dial-peer 2200
>
> !
>
> dial-peer voice 1100 voip
>
> description Incoming ITSP Call Leg
>
> session protocol sipv2
>
> incoming uri via 1100
>
> destination dpg 2200
>
> dtmf-relay rtp-nte ; ITSP only supports one dtmf relay
>
> codec g711ulaw ; ITSP only supports one codec
>
> ip qos dscp cs3 signaling
>
> no vad
>
> !
>
> dial-peer voice 1200 voip
>
> description Outgoing ITSP Call Leg
>
> destination-pattern ABC123
>
> session protocol sipv2
>
> session server-group 1200
>
> voice-class sip options-keepalive profile 1200
>
> dtmf-relay rtp-nte
>
> codec g711ulaw
>
> ip qos dscp cs3 signaling
>
> no vad
>
> !
>
> dial-peer voice 2100 voip
>
> description Incoming CUCM Call Leg
>
> session protocol sipv2
>
> incoming uri via 2100
>
> destination dpg 1200
>
> dtmf-relay sip-kpml rtp-nte ; we support both in- and out-of-band
> internally and cube interworks dtmf
>
> codec g711ulaw
>
> ip qos dscp cs3 signaling
>
> no vad
>
> !
>
> dial-peer voice 2200 voip
>
> description Outgoing CUCM Call Leg
>
> session protocol sipv2
>
> session server-group 2200
>
> destination-pattern ABC123
>
> voice-class sip options-keepalive profile 2200
>
> dtmf-relay sip-kpml rtp-nte
>
> codec g711ulaw
>
> ip qos dscp cs3 signaling
>
> no vad
>
> !
>
> ! a little something extra here at the end
>
> alias exec attra show call active voice | in
> PeerAddr|PeerId|RemoteS|RemoteM|Dtmf|Coder|VAD
>
> alias exec attrh show call history voice | in
> PeerAddr|PeerId|RemoteS|RemoteM|Dtmf|Coder|VAD
>
>
>
> On Fri, Jun 12, 2020 at 6:36 PM Brian Meade <bmeade90@vt.edu> wrote:
>
> Anthony,
>
>
>
> Thanks for the feedback. I'll definitely take a look at yours as well.
>
>
>
> Here's some answers on mine:
>
> 1. While I like that you can give a uri profile a name like ISP, I much
> prefer to stick with numbers, since for most things, you must use numbers
> when naming, so this keeps it consistent.
>
> So I usually replace this with the name of the actual SIP carrier. This
> seems to make it easier for customers to understand but I understand so
> many other things are number tags only.
>
> 2. I don't specify the port in my server groups, since 5060 is default,
> but I can see how it might help be more explicit for some people
>
> Yea, I've never tried it without specifying the port. I've got a lot of
> SIP carriers with weird SIP ports so making it stand out in the template
> helps to know where to change this.
>
> 3. Speaking of being explicit though, if that is your intention, I would
> recommend pref 1 and pref 2, instead of implied pref 0 and pref 1
>
> That's a good idea. I actually exported this from a customer not
> realizing what it looks like when I use pref 0 and 1. Making it 1 and 2
> would make that look cleaner.
>
> 4. Why didn't you should your translation profiles and rules too?
>
> These seem to be so customer/SIP carrier specific that I didn't think it
> was worth it. My most recent one had 80 rules in it because the carrier
> really cares about 10-digit/11-digit calling for the local area code. So
> we actually had to split it up for different NPA-NXX whether or not we
> added a 1.
>
> 5. I don't specify UDP as the transport, since it's the default, but
> again, being explicit doesn't hurt anything
>
> I also make UDP my default but it is nice to have it called out in a
> template so people know where to change it if needed.
>
> 6. I like the extra dtmf on there. too many configs are limited to
> rtp-nte only and mtps are being invoked for every call to UCCX as one
> example
>
> Yea, I always add both to make sure we never have to pull in an MTP. I'm
> not aware of a way to do this globally but would be nice.
>
> 7. Why do you drop your fax rate down from 14400 to 9600 as a standard? I
> might learn something here, as faxing is not my strongest area.
>
> I'm always debugging faxing it seems like. Disabling ECM and reducing
> speed to 9600 has seemed to help a lot over the years. It's slower but
> seems to work more reliably with every source/destination fax device. And
> people don't expect their fax to send quickly anyways.
>
> 8. Since you're doing DPGs, you don't need the destination-pattern .T
> command on the outbound DPs.
>
> It seems like IOS-XE will show a dial-peer as down and skip it if there is
> no destination-pattern configured. This looks to be called out as
> explicitely required here even though it isn't used-
> https://cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/multiple-outbound-dial-peer.html
>
>
>
> Using something like ABC123 for the destination-pattern may make more
> sense to not confuse anyone. Good call.
>
> 9a. Why are you not doing sip options ping? I would, and in which case
> you need a voice class sip options-keepalive profile
> <https://community.cisco.com/t5/telepresence-and-video/sip-options-ping-and-session-server-group-on-dial-peer/td-p/2994584> since
> you're using server groups.
>
> I've never been a fan of SIP Options ping. I've always used SIP timers
> for failover instead. I guess I've had a few outages where waiting for
> Options Ping to come back up after we fixed the underlying issue added
> additional delay. For monitoring purposes though, it probably is a good
> idea to get back into doing that for customers where we're monitoring their
> CUBEs.
>
> 9b. Also, if you do end up turning on options, you do in fact need a
> destination-pattern command, and in which case, since it's not being used
> for call routing, I just use like ABC123 as the pattern to ensure it never
> can be used, but also, mildly clear it's not supposed to be used
>
> I like that idea and referenced it in 8 above.
>
>
>
>
>
>
>
> On Fri, Jun 12, 2020 at 6:29 PM Anthony Holloway <
> avholloway+cisco-voip@gmail.com> wrote:
>
> Brian,
>
>
>
> Nice and clean, I like it! Very similar to what I do. I'd like to
> comment/question yours a bit.
>
>
>
> 1. While I like that you can give a uri profile a name like ISP, I much
> prefer to stick with numbers, since for most things, you must use numbers
> when naming, so this keeps it consistent.
>
> 2. I don't specify the port in my server groups, since 5060 is default,
> but I can see how it might help be more explicit for some people
>
> 3. Speaking of being explicit though, if that is your intention, I would
> recommend pref 1 and pref 2, instead of implied pref 0 and pref 1
>
> 4. Why didn't you should your translation profiles and rules too?
>
> 5. I don't specify UDP as the transport, since it's the default, but
> again, being explicit doesn't hurt anything
>
> 6. I like the extra dtmf on there. too many configs are limited to
> rtp-nte only and mtps are being invoked for every call to UCCX as one
> example
>
> 7. Why do you drop your fax rate down from 14400 to 9600 as a standard? I
> might learn something here, as faxing is not my strongest area.
>
> 8. Since you're doing DPGs, you don't need the destination-pattern .T
> command on the outbound DPs.
>
> 9a. Why are you not doing sip options ping? I would, and in which case
> you need a voice class sip options-keepalive profile
> <https://community.cisco.com/t5/telepresence-and-video/sip-options-ping-and-session-server-group-on-dial-peer/td-p/2994584>
> since you're using server groups.
>
> 9b. Also, if you do end up turning on options, you do in fact need a
> destination-pattern command, and in which case, since it's not being used
> for call routing, I just use like ABC123 as the pattern to ensure it never
> can be used, but also, mildly clear it's not supposed to be used
>
>
>
> I'll post a config as well, in a bit, and please feel free to
> comment/question mine.
>
>
>
>
>
>
>
>
>
> On Fri, Jun 12, 2020 at 3:20 PM Brian Meade <bmeade90@vt.edu> wrote:
>
> I've been trying to make a standardized CUBE configuration using a lot of
> the newer features like dial-peer groups.
>
>
>
> This is what I have now. It's an inbound dial-peer for CUCM matching the
> CUCM IP's via Via header. Then an inbound dial-peer for the ISP. Then an
> outbound dial-peer to CUCM and an outbound dial-peer to the ISP. If you
> have more IP's for the ISP or CUCM, you can easily add them.
> destination-pattern .T is not used at all due to using dial-peer group
> matching. This doesn't account for bindings that must be done per
> dial-peer. It also doesn't show translation-profiles/rules.
>
>
>
> This gives you 4 total dial-peers to match any number.
>
>
>
> If it comes in from CUCM, it will route to the SIP carrier. If it comes
> in from the SIP carrier, it will route to CUCM.
>
> voice class uri ISP sip
> host ipv4:8.8.8.8
>
> voice class uri CUCM sip
> host ipv4:192.168.100.100
> host ipv4:192.168.100.200
>
> voice class server-group 100
> ipv4 8.8.8.8 port 5060
>
> voice class server-group 200
> ipv4 192.168.100.100 port 5060
> ipv4 192.168.100.200 port 5060 preference 1
>
>
>
> voice class dpg 100
>
> voice class dpg 200
>
>
>
> dial-peer voice 100 voip
> description Incoming Dial-peer from ISP
> translation-profile incoming ISPInbound
> session protocol sipv2
> session transport udp
> destination dpg 200
> incoming uri via ISP
> voice-class codec 1
> dtmf-relay rtp-nte sip-kpml
> fax-relay ecm disable
> fax rate 9600
>
> dial-peer voice 200 voip
> description Incoming Dial-peer from CUCM
> session protocol sipv2
> destination dpg 100
> incoming uri via CUCM
> voice-class codec 1
> dtmf-relay rtp-nte sip-kpml
> fax-relay ecm disable
> fax rate 9600
>
>
>
> dial-peer voice 300 voip
> description Outbound to ISP
> translation-profile outgoing ISPOutbound
> destination-pattern .T
> session protocol sipv2
> session transport udp
> session server-group 100
> voice-class codec 1
> dtmf-relay rtp-nte sip-kpml
> fax-relay ecm disable
> fax rate 9600
>
> dial-peer voice 400 voip
> description Outbound to CUCM
> destination-pattern .T
> session protocol sipv2
> session server-group 200
> voice-class codec 1
> dtmf-relay rtp-nte sip-kpml
> fax-relay ecm disable
> fax rate 9600
>
>
>
> voice class dpg 100
> dial-peer 300
>
> voice class dpg 200
> dial-peer 400
>
>
>
> On Fri, Jun 12, 2020 at 3:12 PM JASON BURWELL via cisco-voip <
> cisco-voip@puck.nether.net> wrote:
>
> Does anyone have a good, straightforward reference doc to configuring CUBE
> dial peers? I have what I would have thought should be a fairly basic
> config but I’m having trouble getting everything to work properly. I’ve had
> some assistance but it seems like a whole lot of configuration to do what
> little I really need to do. Basically, I just need to send whatever comes
> from CUCM- either 10, 11 or 3 digits in the SIP invite for outbound and for
> inbound calls the provider sends me 10 digits in the invite, I just need to
> strip off the first 6 and send the last 4 to CUCM to route. I have a lot of
> adding and stripping digits going on between CUCM and CUBE to make this
> work. Just trying to find reference docs to see if any of this can be
> cleaned up. Thanks
>
> _______________________________________________
> 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
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>

Yeah so in that case, ditch the URI matching and go with phone numbers.
That's perfectly fine. I don't think anyone was saying that it's the only
way to do it. It's just the simplest, for the simplest cases. More
complex environment require more complex configurations. You may even end
up mixing the solutions within the same CUBE, as you've articulated with
using URI matching for CUCM peers.

You might have noticed in my reply this commentary:

"Most I ever used was like 15 i think. E.g., 2215 But that was not using
IP addresses in the matching and DPGs, that was using phone number
matching, and I was using steering codes."

This is clearly an indication that the design must match the requirements,
and there's not a one size fits all approach.

On Tue, Jun 16, 2020 at 11:26 AM Loren Hillukka <lchillukka@hotmail.com>
wrote:

> Nice to see the examples and explanations - thank you! I really like the
> naming structure to allow simple a show command to pull everything related
> to one side of the call flow.
> URI matching broke down in UCCE environments as uri match overrides all
> other matching. I needed to match some ingress numbers from the ITSP to
> apply CVP .tcl scripts too and wasn’t able to when matching all inbound
> from ITSP via URI. So the config gets a bit longer in UCCE environments
> due to this.
> I ended up using e164-pattern-maps as another means of collapsing
> dial-peers, with uri match for calls from CUCM, and also server-groups to
> reduce outbound peers.
> Based on the configs from Brian and Anthony, you wouldn’t need
> e164-pattern-maps in those environments. Curious what direction others
> have taken to simplify dial-peers with UCCE in play.
>
> Loren
>
> On Jun 16, 2020, at 10:55 AM, Anthony Holloway <
> avholloway+cisco-voip@gmail.com> wrote:
>
> ?
> Sorry, transmission failed. Try disabling NSF and re-sending.
>
> Back to the point of ABC123, it would be so nice if we could add comments
> to the show run. Second best is to keep a commented copy of the config off
> box in your documentation repository.
>
> On Mon, Jun 15, 2020 at 11:31 PM Brian Meade <bmeade90@vt.edu> wrote:
>
>> Anthony,
>>
>> I like the config. Definitely is nice to have some standardization on
>> the dial-peer tags. I've usually done all my inbound dial-peers in the 1XX
>> range but have gone outside of that lately with separating inbound ITSP and
>> inbound CUCM dial-peers to make them more obvious but I like the idea of
>> having more structure like yours.
>>
>> Using the destination-pattern ABC123 is a great idea to show that's not
>> used as mentioned before.
>>
>> I try to always use voice-class codec for every dial-peer even if I've
>> only got 1 codec configured there just to make it easier to change if ever
>> needed but that was in the past when I had separate local/long
>> distance/911/international/10-digit dial-peers. Simplifying it down to a
>> single inbound/outbound dial-peer with the ITSP makes it a toss-up if that
>> helps anymore.
>>
>> I've tried to keep KPML on my ITSP facing dial-peers just in case they
>> happen to support it. I've found some say they don't but actually do use
>> it if you advertise it. No harm in advertising it from our side.
>>
>> I like the aliases you've got there as well. I feel like I'm always on
>> some random customer's box so not sure I'd remember to always put them in
>> first but definitely nice to have when you make the full CUBE config.
>>
>> Looks like all you're missing is your fax config! I can fax that over to
>> you! :)
>>
>> On Fri, Jun 12, 2020 at 8:53 PM Anthony Holloway <
>> avholloway+cisco-voip@gmail.com> wrote:
>>
>>> All great points, thanks for taking the time to respond.
>>>
>>> The only one I think that I need to reply to is the DPG and
>>> destination-pattern one. I was actually troubleshooting a customer CUBE
>>> wherein this exact scenario was in place and the only negative was getting
>>> options to work. Otherwise, it was routing the call just fine. Granted, I
>>> couldn't tell you what version that was, as it was like a year or so ago,
>>> but either way, I always put a destination-pattern on because you need one
>>> for options to function.
>>>
>>> I guess I could reply to one more, and that has to do with tweaking
>>> retries from 6 to 2 AND using options. Why stick to one, when you can do
>>> both?
>>>
>>> Here's the one I use which I said was very similar to yours.
>>>
>>> The first thing to note is the numeric structure of my tags.
>>>
>>> 1000 series numbers are the ITSP side
>>> 2000 series numbers are the CUCM side
>>>
>>> I would expand this to 3000, 4000, etc., for additional integrations
>>> like PRIs, FXO, second ITSP, second PBX, etc. Most I ever had was 6
>>> integrations into a single CUBE i think.
>>>
>>> The second digit is 1 for incoming and 2 for outgoing.
>>>
>>> The 4rd and fourth digit are generally not used, unless I need
>>> additional dial-peers for the same peer and direction, but doing something
>>> slightly different. Most I ever used was like 15 i think. E.g., 2215 But
>>> that was not using IP addresses in the matching and DPGs, that was using
>>> phone number matching, and I was using steering codes.
>>>
>>> This numbering structure allows me to do something like this:
>>>
>>> show run | section 12..
>>>
>>> Which would then show me the following all at once: URI, Server Group,
>>> Profile and Dial Peers all pertaining to the outgoing ITSP leg.
>>>
>>> Also, in this example, we pass +E164 through the gateway
>>> bi-directionally, so no digit manip needed.
>>>
>>> voice class uri 1100 sip
>>> host ipv4:8.8.8.8
>>> host ipv4:9.9.9.9
>>> !
>>> voice class server-group 1200
>>> description ITSP Peers
>>> ipv4 8.8.8.8 preference 1
>>> ipv4 9.9.9.9 preference 2
>>> !
>>> voice class sip-options-keepalive 1200
>>> description ITSP Peers (Intentionally Left Blank)
>>> !
>>> voice class uri 2100 sip
>>> host ipv4:10.1.1.2
>>> host ipv4:10.1.1.3
>>> !
>>> voice class server-group 2200
>>> description CUCM Nodes
>>> ipv4 10.1.1.2 preference 1
>>> ipv4 10.1.1.3 preference 2
>>> !
>>> voice class sip-options-keepalive 2200
>>> description CUCM Nodes (Intentionally Left Blank)
>>> !
>>> voice class dpg 1200
>>> dial-peer 1200
>>> !
>>> voice class dpg 2200
>>> dial-peer 2200
>>> !
>>> dial-peer voice 1100 voip
>>> description Incoming ITSP Call Leg
>>> session protocol sipv2
>>> incoming uri via 1100
>>> destination dpg 2200
>>> dtmf-relay rtp-nte ; ITSP only supports one dtmf relay
>>> codec g711ulaw ; ITSP only supports one codec
>>> ip qos dscp cs3 signaling
>>> no vad
>>> !
>>> dial-peer voice 1200 voip
>>> description Outgoing ITSP Call Leg
>>> destination-pattern ABC123
>>> session protocol sipv2
>>> session server-group 1200
>>> voice-class sip options-keepalive profile 1200
>>> dtmf-relay rtp-nte
>>> codec g711ulaw
>>> ip qos dscp cs3 signaling
>>> no vad
>>> !
>>> dial-peer voice 2100 voip
>>> description Incoming CUCM Call Leg
>>> session protocol sipv2
>>> incoming uri via 2100
>>> destination dpg 1200
>>> dtmf-relay sip-kpml rtp-nte ; we support both in- and out-of-band
>>> internally and cube interworks dtmf
>>> codec g711ulaw
>>> ip qos dscp cs3 signaling
>>> no vad
>>> !
>>> dial-peer voice 2200 voip
>>> description Outgoing CUCM Call Leg
>>> session protocol sipv2
>>> session server-group 2200
>>> destination-pattern ABC123
>>> voice-class sip options-keepalive profile 2200
>>> dtmf-relay sip-kpml rtp-nte
>>> codec g711ulaw
>>> ip qos dscp cs3 signaling
>>> no vad
>>> !
>>> ! a little something extra here at the end
>>> alias exec attra show call active voice | in
>>> PeerAddr|PeerId|RemoteS|RemoteM|Dtmf|Coder|VAD
>>> alias exec attrh show call history voice | in
>>> PeerAddr|PeerId|RemoteS|RemoteM|Dtmf|Coder|VAD
>>>
>>> On Fri, Jun 12, 2020 at 6:36 PM Brian Meade <bmeade90@vt.edu> wrote:
>>>
>>>> Anthony,
>>>>
>>>> Thanks for the feedback. I'll definitely take a look at yours as well.
>>>>
>>>> Here's some answers on mine:
>>>> 1. While I like that you can give a uri profile a name like ISP, I much
>>>> prefer to stick with numbers, since for most things, you must use numbers
>>>> when naming, so this keeps it consistent.
>>>> So I usually replace this with the name of the actual SIP carrier.
>>>> This seems to make it easier for customers to understand but I understand
>>>> so many other things are number tags only.
>>>> 2. I don't specify the port in my server groups, since 5060 is default,
>>>> but I can see how it might help be more explicit for some people
>>>> Yea, I've never tried it without specifying the port. I've got a lot
>>>> of SIP carriers with weird SIP ports so making it stand out in the template
>>>> helps to know where to change this.
>>>> 3. Speaking of being explicit though, if that is your intention, I
>>>> would recommend pref 1 and pref 2, instead of implied pref 0 and pref 1
>>>> That's a good idea. I actually exported this from a customer not
>>>> realizing what it looks like when I use pref 0 and 1. Making it 1 and 2
>>>> would make that look cleaner.
>>>> 4. Why didn't you should your translation profiles and rules too?
>>>> These seem to be so customer/SIP carrier specific that I didn't think
>>>> it was worth it. My most recent one had 80 rules in it because the carrier
>>>> really cares about 10-digit/11-digit calling for the local area code. So
>>>> we actually had to split it up for different NPA-NXX whether or not we
>>>> added a 1.
>>>> 5. I don't specify UDP as the transport, since it's the default, but
>>>> again, being explicit doesn't hurt anything
>>>> I also make UDP my default but it is nice to have it called out in a
>>>> template so people know where to change it if needed.
>>>> 6. I like the extra dtmf on there. too many configs are limited to
>>>> rtp-nte only and mtps are being invoked for every call to UCCX as one
>>>> example
>>>> Yea, I always add both to make sure we never have to pull in an MTP.
>>>> I'm not aware of a way to do this globally but would be nice.
>>>> 7. Why do you drop your fax rate down from 14400 to 9600 as a
>>>> standard? I might learn something here, as faxing is not my strongest area.
>>>> I'm always debugging faxing it seems like. Disabling ECM and reducing
>>>> speed to 9600 has seemed to help a lot over the years. It's slower but
>>>> seems to work more reliably with every source/destination fax device. And
>>>> people don't expect their fax to send quickly anyways.
>>>> 8. Since you're doing DPGs, you don't need the destination-pattern .T
>>>> command on the outbound DPs.
>>>> It seems like IOS-XE will show a dial-peer as down and skip it if there
>>>> is no destination-pattern configured. This looks to be called out as
>>>> explicitely required here even though it isn't used-
>>>> https://cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/multiple-outbound-dial-peer.html
>>>>
>>>> Using something like ABC123 for the destination-pattern may make more
>>>> sense to not confuse anyone. Good call.
>>>> 9a. Why are you not doing sip options ping? I would, and in which case
>>>> you need a voice class sip options-keepalive profile
>>>> <https://community.cisco.com/t5/telepresence-and-video/sip-options-ping-and-session-server-group-on-dial-peer/td-p/2994584> since
>>>> you're using server groups.
>>>> I've never been a fan of SIP Options ping. I've always used SIP timers
>>>> for failover instead. I guess I've had a few outages where waiting for
>>>> Options Ping to come back up after we fixed the underlying issue added
>>>> additional delay. For monitoring purposes though, it probably is a good
>>>> idea to get back into doing that for customers where we're monitoring their
>>>> CUBEs.
>>>> 9b. Also, if you do end up turning on options, you do in fact need a
>>>> destination-pattern command, and in which case, since it's not being used
>>>> for call routing, I just use like ABC123 as the pattern to ensure it never
>>>> can be used, but also, mildly clear it's not supposed to be used
>>>> I like that idea and referenced it in 8 above.
>>>>
>>>>
>>>>
>>>> On Fri, Jun 12, 2020 at 6:29 PM Anthony Holloway <
>>>> avholloway+cisco-voip@gmail.com> wrote:
>>>>
>>>>> Brian,
>>>>>
>>>>> Nice and clean, I like it! Very similar to what I do. I'd like to
>>>>> comment/question yours a bit.
>>>>>
>>>>> 1. While I like that you can give a uri profile a name like ISP, I
>>>>> much prefer to stick with numbers, since for most things, you must use
>>>>> numbers when naming, so this keeps it consistent.
>>>>> 2. I don't specify the port in my server groups, since 5060 is
>>>>> default, but I can see how it might help be more explicit for some people
>>>>> 3. Speaking of being explicit though, if that is your intention, I
>>>>> would recommend pref 1 and pref 2, instead of implied pref 0 and pref 1
>>>>> 4. Why didn't you should your translation profiles and rules too?
>>>>> 5. I don't specify UDP as the transport, since it's the default, but
>>>>> again, being explicit doesn't hurt anything
>>>>> 6. I like the extra dtmf on there. too many configs are limited to
>>>>> rtp-nte only and mtps are being invoked for every call to UCCX as one
>>>>> example
>>>>> 7. Why do you drop your fax rate down from 14400 to 9600 as a
>>>>> standard? I might learn something here, as faxing is not my strongest area.
>>>>> 8. Since you're doing DPGs, you don't need the destination-pattern .T
>>>>> command on the outbound DPs.
>>>>> 9a. Why are you not doing sip options ping? I would, and in which
>>>>> case you need a voice class sip options-keepalive profile
>>>>> <https://community.cisco.com/t5/telepresence-and-video/sip-options-ping-and-session-server-group-on-dial-peer/td-p/2994584>
>>>>> since you're using server groups.
>>>>> 9b. Also, if you do end up turning on options, you do in fact need a
>>>>> destination-pattern command, and in which case, since it's not being used
>>>>> for call routing, I just use like ABC123 as the pattern to ensure it never
>>>>> can be used, but also, mildly clear it's not supposed to be used
>>>>>
>>>>> I'll post a config as well, in a bit, and please feel free to
>>>>> comment/question mine.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Jun 12, 2020 at 3:20 PM Brian Meade <bmeade90@vt.edu> wrote:
>>>>>
>>>>>> I've been trying to make a standardized CUBE configuration using a
>>>>>> lot of the newer features like dial-peer groups.
>>>>>>
>>>>>> This is what I have now. It's an inbound dial-peer for CUCM matching
>>>>>> the CUCM IP's via Via header. Then an inbound dial-peer for the ISP. Then
>>>>>> an outbound dial-peer to CUCM and an outbound dial-peer to the ISP. If you
>>>>>> have more IP's for the ISP or CUCM, you can easily add them.
>>>>>> destination-pattern .T is not used at all due to using dial-peer group
>>>>>> matching. This doesn't account for bindings that must be done per
>>>>>> dial-peer. It also doesn't show translation-profiles/rules.
>>>>>>
>>>>>> This gives you 4 total dial-peers to match any number.
>>>>>>
>>>>>> If it comes in from CUCM, it will route to the SIP carrier. If it
>>>>>> comes in from the SIP carrier, it will route to CUCM.
>>>>>>
>>>>>> voice class uri ISP sip
>>>>>> host ipv4:8.8.8.8
>>>>>>
>>>>>> voice class uri CUCM sip
>>>>>> host ipv4:192.168.100.100
>>>>>> host ipv4:192.168.100.200
>>>>>>
>>>>>> voice class server-group 100
>>>>>> ipv4 8.8.8.8 port 5060
>>>>>>
>>>>>> voice class server-group 200
>>>>>> ipv4 192.168.100.100 port 5060
>>>>>> ipv4 192.168.100.200 port 5060 preference 1
>>>>>>
>>>>>> voice class dpg 100
>>>>>>
>>>>>> voice class dpg 200
>>>>>>
>>>>>> dial-peer voice 100 voip
>>>>>> description Incoming Dial-peer from ISP
>>>>>> translation-profile incoming ISPInbound
>>>>>> session protocol sipv2
>>>>>> session transport udp
>>>>>> destination dpg 200
>>>>>> incoming uri via ISP
>>>>>> voice-class codec 1
>>>>>> dtmf-relay rtp-nte sip-kpml
>>>>>> fax-relay ecm disable
>>>>>> fax rate 9600
>>>>>>
>>>>>> dial-peer voice 200 voip
>>>>>> description Incoming Dial-peer from CUCM
>>>>>> session protocol sipv2
>>>>>> destination dpg 100
>>>>>> incoming uri via CUCM
>>>>>> voice-class codec 1
>>>>>> dtmf-relay rtp-nte sip-kpml
>>>>>> fax-relay ecm disable
>>>>>> fax rate 9600
>>>>>>
>>>>>> dial-peer voice 300 voip
>>>>>> description Outbound to ISP
>>>>>> translation-profile outgoing ISPOutbound
>>>>>> destination-pattern .T
>>>>>> session protocol sipv2
>>>>>> session transport udp
>>>>>> session server-group 100
>>>>>> voice-class codec 1
>>>>>> dtmf-relay rtp-nte sip-kpml
>>>>>> fax-relay ecm disable
>>>>>> fax rate 9600
>>>>>>
>>>>>> dial-peer voice 400 voip
>>>>>> description Outbound to CUCM
>>>>>> destination-pattern .T
>>>>>> session protocol sipv2
>>>>>> session server-group 200
>>>>>> voice-class codec 1
>>>>>> dtmf-relay rtp-nte sip-kpml
>>>>>> fax-relay ecm disable
>>>>>> fax rate 9600
>>>>>>
>>>>>> voice class dpg 100
>>>>>> dial-peer 300
>>>>>>
>>>>>> voice class dpg 200
>>>>>> dial-peer 400
>>>>>>
>>>>>> On Fri, Jun 12, 2020 at 3:12 PM JASON BURWELL via cisco-voip <
>>>>>> cisco-voip@puck.nether.net> wrote:
>>>>>>
>>>>>>> Does anyone have a good, straightforward reference doc to
>>>>>>> configuring CUBE dial peers? I have what I would have thought should be a
>>>>>>> fairly basic config but I’m having trouble getting everything to work
>>>>>>> properly. I’ve had some assistance but it seems like a whole lot of
>>>>>>> configuration to do what little I really need to do. Basically, I just need
>>>>>>> to send whatever comes from CUCM- either 10, 11 or 3 digits in the SIP
>>>>>>> invite for outbound and for inbound calls the provider sends me 10 digits
>>>>>>> in the invite, I just need to strip off the first 6 and send the last 4 to
>>>>>>> CUCM to route. I have a lot of adding and stripping digits going on between
>>>>>>> CUCM and CUBE to make this work. Just trying to find reference docs to see
>>>>>>> if any of this can be cleaned up. Thanks
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>>
>>>>> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>

I believe you have described Nate to a “T” (no . included) ????

Loren

On Jun 16, 2020, at 2:56 PM, Anthony Holloway <avholloway+cisco-voip@gmail.com> wrote:

?
"I cannot stand DPG"
"I use cor-list"

I bet you also are a sadist and use 9.@ too. You and Lelio should form a posse and fight Brian and I. The losers must convert to the other's design.

On Tue, Jun 16, 2020 at 12:17 PM NateCCIE <nateccie@gmail.com<mailto:nateccie@gmail.com>> wrote:
Well once Loren speaks up you know it’s an interesting thread.

My two cents, I cannot stand DPG. Its crazy that it completely ignores destination pattern. If you have two destinations in the group, it just round-robins them. I got burned not understanding that DPG didn’t look at destination pattern and I swore I would never use them again.

I use cor-list to restrict the SP inbound dial-peer to the cucm outbound dial-peer, and vice versa. Matching the inbound dial-peer by URI works great, I started with matching “FROM” but that fell apart in some cases, so I use VIA by default now, and that has been solid.

My numbering is usually 1X for CUCM, with the 0 for inbound in each range, then 2X for the first SIP provider and 3X for the 2nd, maybe 5X for CVP etc.

I always localize on the CUBE, sending a full +E.164 from CUCM and then use translation profiles to format to how the specific country/carrier wants to see the calls. The exception is US 11D/10D determination is done by the CUCM because I find it easier to load all of the local NPA-NXX into CUCM route filters via AXL, but then sometimes I am doing TEHO and have to control which outbound dial-peer it chooses.

I also never let the CUBE choose the carrier, I think mostly because a long time ago I had the same carrier spread over multiple gateways along with multiple carriers in each gateway, and I wanted CUCM to re-route to the other gateway same carrier before CUBE used a less preferred route because it was local. So when there is multiple carriers I usually will prefix 1#* or 2#* on up for each carrier.

Anyway, that’s my 2 cents.


From: cisco-voip <cisco-voip-bounces@puck.nether.net<mailto:cisco-voip-bounces@puck.nether.net>> On Behalf Of Loren Hillukka
Sent: Tuesday, June 16, 2020 10:26 AM
To: Anthony Holloway <avholloway+cisco-voip@gmail.com<mailto:avholloway%2Bcisco-voip@gmail.com>>
Cc: cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
Subject: Re: [cisco-voip] CUBE Config Dial Peers

Nice to see the examples and explanations - thank you! I really like the naming structure to allow simple a show command to pull everything related to one side of the call flow.
URI matching broke down in UCCE environments as uri match overrides all other matching. I needed to match some ingress numbers from the ITSP to apply CVP .tcl scripts too and wasn’t able to when matching all inbound from ITSP via URI. So the config gets a bit longer in UCCE environments due to this.
I ended up using e164-pattern-maps as another means of collapsing dial-peers, with uri match for calls from CUCM, and also server-groups to reduce outbound peers.
Based on the configs from Brian and Anthony, you wouldn’t need e164-pattern-maps in those environments. Curious what direction others have taken to simplify dial-peers with UCCE in play.

Loren


On Jun 16, 2020, at 10:55 AM, Anthony Holloway <avholloway+cisco-voip@gmail.com<mailto:avholloway+cisco-voip@gmail.com>> wrote:
?
Sorry, transmission failed. Try disabling NSF and re-sending.

Back to the point of ABC123, it would be so nice if we could add comments to the show run. Second best is to keep a commented copy of the config off box in your documentation repository.

On Mon, Jun 15, 2020 at 11:31 PM Brian Meade <bmeade90@vt.edu<mailto:bmeade90@vt.edu>> wrote:
Anthony,

I like the config. Definitely is nice to have some standardization on the dial-peer tags. I've usually done all my inbound dial-peers in the 1XX range but have gone outside of that lately with separating inbound ITSP and inbound CUCM dial-peers to make them more obvious but I like the idea of having more structure like yours.

Using the destination-pattern ABC123 is a great idea to show that's not used as mentioned before.

I try to always use voice-class codec for every dial-peer even if I've only got 1 codec configured there just to make it easier to change if ever needed but that was in the past when I had separate local/long distance/911/international/10-digit dial-peers. Simplifying it down to a single inbound/outbound dial-peer with the ITSP makes it a toss-up if that helps anymore.

I've tried to keep KPML on my ITSP facing dial-peers just in case they happen to support it. I've found some say they don't but actually do use it if you advertise it. No harm in advertising it from our side.

I like the aliases you've got there as well. I feel like I'm always on some random customer's box so not sure I'd remember to always put them in first but definitely nice to have when you make the full CUBE config.

Looks like all you're missing is your fax config! I can fax that over to you! :)

On Fri, Jun 12, 2020 at 8:53 PM Anthony Holloway <avholloway+cisco-voip@gmail.com<mailto:avholloway%2Bcisco-voip@gmail.com>> wrote:
All great points, thanks for taking the time to respond.

The only one I think that I need to reply to is the DPG and destination-pattern one. I was actually troubleshooting a customer CUBE wherein this exact scenario was in place and the only negative was getting options to work. Otherwise, it was routing the call just fine. Granted, I couldn't tell you what version that was, as it was like a year or so ago, but either way, I always put a destination-pattern on because you need one for options to function.

I guess I could reply to one more, and that has to do with tweaking retries from 6 to 2 AND using options. Why stick to one, when you can do both?

Here's the one I use which I said was very similar to yours.

The first thing to note is the numeric structure of my tags.

1000 series numbers are the ITSP side
2000 series numbers are the CUCM side

I would expand this to 3000, 4000, etc., for additional integrations like PRIs, FXO, second ITSP, second PBX, etc. Most I ever had was 6 integrations into a single CUBE i think.

The second digit is 1 for incoming and 2 for outgoing.

The 4rd and fourth digit are generally not used, unless I need additional dial-peers for the same peer and direction, but doing something slightly different. Most I ever used was like 15 i think. E.g., 2215 But that was not using IP addresses in the matching and DPGs, that was using phone number matching, and I was using steering codes.

This numbering structure allows me to do something like this:

show run | section 12..

Which would then show me the following all at once: URI, Server Group, Profile and Dial Peers all pertaining to the outgoing ITSP leg.

Also, in this example, we pass +E164 through the gateway bi-directionally, so no digit manip needed.

voice class uri 1100 sip
host ipv4:8.8.8.8
host ipv4:9.9.9.9
!
voice class server-group 1200
description ITSP Peers
ipv4 8.8.8.8 preference 1
ipv4 9.9.9.9 preference 2
!
voice class sip-options-keepalive 1200
description ITSP Peers (Intentionally Left Blank)
!
voice class uri 2100 sip
host ipv4:10.1.1.2
host ipv4:10.1.1.3
!
voice class server-group 2200
description CUCM Nodes
ipv4 10.1.1.2 preference 1
ipv4 10.1.1.3 preference 2
!
voice class sip-options-keepalive 2200
description CUCM Nodes (Intentionally Left Blank)
!
voice class dpg 1200
dial-peer 1200
!
voice class dpg 2200
dial-peer 2200
!
dial-peer voice 1100 voip
description Incoming ITSP Call Leg
session protocol sipv2
incoming uri via 1100
destination dpg 2200
dtmf-relay rtp-nte ; ITSP only supports one dtmf relay
codec g711ulaw ; ITSP only supports one codec
ip qos dscp cs3 signaling
no vad
!
dial-peer voice 1200 voip
description Outgoing ITSP Call Leg
destination-pattern ABC123
session protocol sipv2
session server-group 1200
voice-class sip options-keepalive profile 1200
dtmf-relay rtp-nte
codec g711ulaw
ip qos dscp cs3 signaling
no vad
!
dial-peer voice 2100 voip
description Incoming CUCM Call Leg
session protocol sipv2
incoming uri via 2100
destination dpg 1200
dtmf-relay sip-kpml rtp-nte ; we support both in- and out-of-band internally and cube interworks dtmf
codec g711ulaw
ip qos dscp cs3 signaling
no vad
!
dial-peer voice 2200 voip
description Outgoing CUCM Call Leg
session protocol sipv2
session server-group 2200
destination-pattern ABC123
voice-class sip options-keepalive profile 2200
dtmf-relay sip-kpml rtp-nte
codec g711ulaw
ip qos dscp cs3 signaling
no vad
!
! a little something extra here at the end
alias exec attra show call active voice | in PeerAddr|PeerId|RemoteS|RemoteM|Dtmf|Coder|VAD
alias exec attrh show call history voice | in PeerAddr|PeerId|RemoteS|RemoteM|Dtmf|Coder|VAD

On Fri, Jun 12, 2020 at 6:36 PM Brian Meade <bmeade90@vt.edu<mailto:bmeade90@vt.edu>> wrote:
Anthony,

Thanks for the feedback. I'll definitely take a look at yours as well.

Here's some answers on mine:
1. While I like that you can give a uri profile a name like ISP, I much prefer to stick with numbers, since for most things, you must use numbers when naming, so this keeps it consistent.
So I usually replace this with the name of the actual SIP carrier. This seems to make it easier for customers to understand but I understand so many other things are number tags only.
2. I don't specify the port in my server groups, since 5060 is default, but I can see how it might help be more explicit for some people
Yea, I've never tried it without specifying the port. I've got a lot of SIP carriers with weird SIP ports so making it stand out in the template helps to know where to change this.
3. Speaking of being explicit though, if that is your intention, I would recommend pref 1 and pref 2, instead of implied pref 0 and pref 1
That's a good idea. I actually exported this from a customer not realizing what it looks like when I use pref 0 and 1. Making it 1 and 2 would make that look cleaner.
4. Why didn't you should your translation profiles and rules too?
These seem to be so customer/SIP carrier specific that I didn't think it was worth it. My most recent one had 80 rules in it because the carrier really cares about 10-digit/11-digit calling for the local area code. So we actually had to split it up for different NPA-NXX whether or not we added a 1.
5. I don't specify UDP as the transport, since it's the default, but again, being explicit doesn't hurt anything
I also make UDP my default but it is nice to have it called out in a template so people know where to change it if needed.
6. I like the extra dtmf on there. too many configs are limited to rtp-nte only and mtps are being invoked for every call to UCCX as one example
Yea, I always add both to make sure we never have to pull in an MTP. I'm not aware of a way to do this globally but would be nice.
7. Why do you drop your fax rate down from 14400 to 9600 as a standard? I might learn something here, as faxing is not my strongest area.
I'm always debugging faxing it seems like. Disabling ECM and reducing speed to 9600 has seemed to help a lot over the years. It's slower but seems to work more reliably with every source/destination fax device. And people don't expect their fax to send quickly anyways.
8. Since you're doing DPGs, you don't need the destination-pattern .T command on the outbound DPs.
It seems like IOS-XE will show a dial-peer as down and skip it if there is no destination-pattern configured. This looks to be called out as explicitely required here even though it isn't used- https://cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/multiple-outbound-dial-peer.html

Using something like ABC123 for the destination-pattern may make more sense to not confuse anyone. Good call.
9a. Why are you not doing sip options ping? I would, and in which case you need a voice class sip options-keepalive profile<https://community.cisco.com/t5/telepresence-and-video/sip-options-ping-and-session-server-group-on-dial-peer/td-p/2994584> since you're using server groups.
I've never been a fan of SIP Options ping. I've always used SIP timers for failover instead. I guess I've had a few outages where waiting for Options Ping to come back up after we fixed the underlying issue added additional delay. For monitoring purposes though, it probably is a good idea to get back into doing that for customers where we're monitoring their CUBEs.
9b. Also, if you do end up turning on options, you do in fact need a destination-pattern command, and in which case, since it's not being used for call routing, I just use like ABC123 as the pattern to ensure it never can be used, but also, mildly clear it's not supposed to be used
I like that idea and referenced it in 8 above.



On Fri, Jun 12, 2020 at 6:29 PM Anthony Holloway <avholloway+cisco-voip@gmail.com<mailto:avholloway%2Bcisco-voip@gmail.com>> wrote:
Brian,

Nice and clean, I like it! Very similar to what I do. I'd like to comment/question yours a bit.

1. While I like that you can give a uri profile a name like ISP, I much prefer to stick with numbers, since for most things, you must use numbers when naming, so this keeps it consistent.
2. I don't specify the port in my server groups, since 5060 is default, but I can see how it might help be more explicit for some people
3. Speaking of being explicit though, if that is your intention, I would recommend pref 1 and pref 2, instead of implied pref 0 and pref 1
4. Why didn't you should your translation profiles and rules too?
5. I don't specify UDP as the transport, since it's the default, but again, being explicit doesn't hurt anything
6. I like the extra dtmf on there. too many configs are limited to rtp-nte only and mtps are being invoked for every call to UCCX as one example
7. Why do you drop your fax rate down from 14400 to 9600 as a standard? I might learn something here, as faxing is not my strongest area.
8. Since you're doing DPGs, you don't need the destination-pattern .T command on the outbound DPs.
9a. Why are you not doing sip options ping? I would, and in which case you need a voice class sip options-keepalive profile<https://community.cisco.com/t5/telepresence-and-video/sip-options-ping-and-session-server-group-on-dial-peer/td-p/2994584> since you're using server groups.
9b. Also, if you do end up turning on options, you do in fact need a destination-pattern command, and in which case, since it's not being used for call routing, I just use like ABC123 as the pattern to ensure it never can be used, but also, mildly clear it's not supposed to be used

I'll post a config as well, in a bit, and please feel free to comment/question mine.




On Fri, Jun 12, 2020 at 3:20 PM Brian Meade <bmeade90@vt.edu<mailto:bmeade90@vt.edu>> wrote:
I've been trying to make a standardized CUBE configuration using a lot of the newer features like dial-peer groups.

This is what I have now. It's an inbound dial-peer for CUCM matching the CUCM IP's via Via header. Then an inbound dial-peer for the ISP. Then an outbound dial-peer to CUCM and an outbound dial-peer to the ISP. If you have more IP's for the ISP or CUCM, you can easily add them. destination-pattern .T is not used at all due to using dial-peer group matching. This doesn't account for bindings that must be done per dial-peer. It also doesn't show translation-profiles/rules.

This gives you 4 total dial-peers to match any number.

If it comes in from CUCM, it will route to the SIP carrier. If it comes in from the SIP carrier, it will route to CUCM.

voice class uri ISP sip
host ipv4:8.8.8.8

voice class uri CUCM sip
host ipv4:192.168.100.100
host ipv4:192.168.100.200

voice class server-group 100
ipv4 8.8.8.8 port 5060

voice class server-group 200
ipv4 192.168.100.100 port 5060
ipv4 192.168.100.200 port 5060 preference 1

voice class dpg 100

voice class dpg 200

dial-peer voice 100 voip
description Incoming Dial-peer from ISP
translation-profile incoming ISPInbound
session protocol sipv2
session transport udp
destination dpg 200
incoming uri via ISP
voice-class codec 1
dtmf-relay rtp-nte sip-kpml
fax-relay ecm disable
fax rate 9600

dial-peer voice 200 voip
description Incoming Dial-peer from CUCM
session protocol sipv2
destination dpg 100
incoming uri via CUCM
voice-class codec 1
dtmf-relay rtp-nte sip-kpml
fax-relay ecm disable
fax rate 9600

dial-peer voice 300 voip
description Outbound to ISP
translation-profile outgoing ISPOutbound
destination-pattern .T
session protocol sipv2
session transport udp
session server-group 100
voice-class codec 1
dtmf-relay rtp-nte sip-kpml
fax-relay ecm disable
fax rate 9600

dial-peer voice 400 voip
description Outbound to CUCM
destination-pattern .T
session protocol sipv2
session server-group 200
voice-class codec 1
dtmf-relay rtp-nte sip-kpml
fax-relay ecm disable
fax rate 9600

voice class dpg 100
dial-peer 300

voice class dpg 200
dial-peer 400

On Fri, Jun 12, 2020 at 3:12 PM JASON BURWELL via cisco-voip <cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>> wrote:
Does anyone have a good, straightforward reference doc to configuring CUBE dial peers? I have what I would have thought should be a fairly basic config but I’m having trouble getting everything to work properly. I’ve had some assistance but it seems like a whole lot of configuration to do what little I really need to do. Basically, I just need to send whatever comes from CUCM- either 10, 11 or 3 digits in the SIP invite for outbound and for inbound calls the provider sends me 10 digits in the invite, I just need to strip off the first 6 and send the last 4 to CUCM to route. I have a lot of adding and stripping digits going on between CUCM and CUBE to make this work. Just trying to find reference docs to see if any of this can be cleaned up. Thanks
_______________________________________________
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<mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

No more 9.@, I use \+.@ now. I think having NPA/NXX route patterns would be just too much to look at. I do wish that route filters could be longer than 1024 characters.



But I just don’t see the point of completely ignoring the call routing engine in CUBE and just say if it comes in this dial-peer send it out any random one of these. It doesn’t work with anything but the simplest of configs, and I really appreciate a base config that works for everything and can be expanded upon. More and more when I keep things consistent between deployments, I am quicker at figuring out what’s broken and can fix it quickly, and customers are amazed that I remembered their system.









From: Anthony Holloway <avholloway+cisco-voip@gmail.com>
Sent: Tuesday, June 16, 2020 1:56 PM
To: NateCCIE <nateccie@gmail.com>
Cc: Loren Hillukka <lchillukka@hotmail.com>; Cisco VoIP Group <cisco-voip@puck.nether.net>
Subject: Re: [cisco-voip] CUBE Config Dial Peers



"I cannot stand DPG"

"I use cor-list"



I bet you also are a sadist and use 9.@ too. You and Lelio should form a posse and fight Brian and I. The losers must convert to the other's design.



On Tue, Jun 16, 2020 at 12:17 PM NateCCIE <nateccie@gmail.com <mailto:nateccie@gmail.com> > wrote:

Well once Loren speaks up you know it’s an interesting thread.



My two cents, I cannot stand DPG. Its crazy that it completely ignores destination pattern. If you have two destinations in the group, it just round-robins them. I got burned not understanding that DPG didn’t look at destination pattern and I swore I would never use them again.



I use cor-list to restrict the SP inbound dial-peer to the cucm outbound dial-peer, and vice versa. Matching the inbound dial-peer by URI works great, I started with matching “FROM” but that fell apart in some cases, so I use VIA by default now, and that has been solid.



My numbering is usually 1X for CUCM, with the 0 for inbound in each range, then 2X for the first SIP provider and 3X for the 2nd, maybe 5X for CVP etc.



I always localize on the CUBE, sending a full +E.164 from CUCM and then use translation profiles to format to how the specific country/carrier wants to see the calls. The exception is US 11D/10D determination is done by the CUCM because I find it easier to load all of the local NPA-NXX into CUCM route filters via AXL, but then sometimes I am doing TEHO and have to control which outbound dial-peer it chooses.



I also never let the CUBE choose the carrier, I think mostly because a long time ago I had the same carrier spread over multiple gateways along with multiple carriers in each gateway, and I wanted CUCM to re-route to the other gateway same carrier before CUBE used a less preferred route because it was local. So when there is multiple carriers I usually will prefix 1#* or 2#* on up for each carrier.



Anyway, that’s my 2 cents.





From: cisco-voip <cisco-voip-bounces@puck.nether.net <mailto:cisco-voip-bounces@puck.nether.net> > On Behalf Of Loren Hillukka
Sent: Tuesday, June 16, 2020 10:26 AM
To: Anthony Holloway <avholloway+cisco-voip@gmail.com <mailto:avholloway%2Bcisco-voip@gmail.com> >
Cc: cisco-voip@puck.nether.net <mailto:cisco-voip@puck.nether.net>
Subject: Re: [cisco-voip] CUBE Config Dial Peers



Nice to see the examples and explanations - thank you! I really like the naming structure to allow simple a show command to pull everything related to one side of the call flow.

URI matching broke down in UCCE environments as uri match overrides all other matching. I needed to match some ingress numbers from the ITSP to apply CVP .tcl scripts too and wasn’t able to when matching all inbound from ITSP via URI. So the config gets a bit longer in UCCE environments due to this.

I ended up using e164-pattern-maps as another means of collapsing dial-peers, with uri match for calls from CUCM, and also server-groups to reduce outbound peers.

Based on the configs from Brian and Anthony, you wouldn’t need e164-pattern-maps in those environments. Curious what direction others have taken to simplify dial-peers with UCCE in play.



Loren



On Jun 16, 2020, at 10:55 AM, Anthony Holloway <avholloway+cisco-voip@gmail.com <mailto:avholloway+cisco-voip@gmail.com> > wrote:

?

Sorry, transmission failed. Try disabling NSF and re-sending.



Back to the point of ABC123, it would be so nice if we could add comments to the show run. Second best is to keep a commented copy of the config off box in your documentation repository.



On Mon, Jun 15, 2020 at 11:31 PM Brian Meade <bmeade90@vt.edu <mailto:bmeade90@vt.edu> > wrote:

Anthony,



I like the config. Definitely is nice to have some standardization on the dial-peer tags. I've usually done all my inbound dial-peers in the 1XX range but have gone outside of that lately with separating inbound ITSP and inbound CUCM dial-peers to make them more obvious but I like the idea of having more structure like yours.



Using the destination-pattern ABC123 is a great idea to show that's not used as mentioned before.



I try to always use voice-class codec for every dial-peer even if I've only got 1 codec configured there just to make it easier to change if ever needed but that was in the past when I had separate local/long distance/911/international/10-digit dial-peers. Simplifying it down to a single inbound/outbound dial-peer with the ITSP makes it a toss-up if that helps anymore.



I've tried to keep KPML on my ITSP facing dial-peers just in case they happen to support it. I've found some say they don't but actually do use it if you advertise it. No harm in advertising it from our side.



I like the aliases you've got there as well. I feel like I'm always on some random customer's box so not sure I'd remember to always put them in first but definitely nice to have when you make the full CUBE config.



Looks like all you're missing is your fax config! I can fax that over to you! :)



On Fri, Jun 12, 2020 at 8:53 PM Anthony Holloway <avholloway+cisco-voip@gmail.com <mailto:avholloway%2Bcisco-voip@gmail.com> > wrote:

All great points, thanks for taking the time to respond.



The only one I think that I need to reply to is the DPG and destination-pattern one. I was actually troubleshooting a customer CUBE wherein this exact scenario was in place and the only negative was getting options to work. Otherwise, it was routing the call just fine. Granted, I couldn't tell you what version that was, as it was like a year or so ago, but either way, I always put a destination-pattern on because you need one for options to function.



I guess I could reply to one more, and that has to do with tweaking retries from 6 to 2 AND using options. Why stick to one, when you can do both?



Here's the one I use which I said was very similar to yours.



The first thing to note is the numeric structure of my tags.



1000 series numbers are the ITSP side

2000 series numbers are the CUCM side



I would expand this to 3000, 4000, etc., for additional integrations like PRIs, FXO, second ITSP, second PBX, etc. Most I ever had was 6 integrations into a single CUBE i think.



The second digit is 1 for incoming and 2 for outgoing.



The 4rd and fourth digit are generally not used, unless I need additional dial-peers for the same peer and direction, but doing something slightly different. Most I ever used was like 15 i think. E.g., 2215 But that was not using IP addresses in the matching and DPGs, that was using phone number matching, and I was using steering codes.



This numbering structure allows me to do something like this:



show run | section 12..



Which would then show me the following all at once: URI, Server Group, Profile and Dial Peers all pertaining to the outgoing ITSP leg.



Also, in this example, we pass +E164 through the gateway bi-directionally, so no digit manip needed.



voice class uri 1100 sip

host ipv4:8.8.8.8

host ipv4:9.9.9.9

!

voice class server-group 1200

description ITSP Peers

ipv4 8.8.8.8 preference 1

ipv4 9.9.9.9 preference 2

!

voice class sip-options-keepalive 1200

description ITSP Peers (Intentionally Left Blank)

!

voice class uri 2100 sip

host ipv4:10.1.1.2

host ipv4:10.1.1.3

!

voice class server-group 2200

description CUCM Nodes

ipv4 10.1.1.2 preference 1

ipv4 10.1.1.3 preference 2

!

voice class sip-options-keepalive 2200

description CUCM Nodes (Intentionally Left Blank)

!

voice class dpg 1200

dial-peer 1200

!

voice class dpg 2200

dial-peer 2200

!

dial-peer voice 1100 voip

description Incoming ITSP Call Leg

session protocol sipv2

incoming uri via 1100

destination dpg 2200

dtmf-relay rtp-nte ; ITSP only supports one dtmf relay

codec g711ulaw ; ITSP only supports one codec

ip qos dscp cs3 signaling

no vad

!

dial-peer voice 1200 voip

description Outgoing ITSP Call Leg

destination-pattern ABC123

session protocol sipv2

session server-group 1200

voice-class sip options-keepalive profile 1200

dtmf-relay rtp-nte

codec g711ulaw

ip qos dscp cs3 signaling

no vad

!

dial-peer voice 2100 voip

description Incoming CUCM Call Leg

session protocol sipv2

incoming uri via 2100

destination dpg 1200

dtmf-relay sip-kpml rtp-nte ; we support both in- and out-of-band internally and cube interworks dtmf

codec g711ulaw

ip qos dscp cs3 signaling

no vad

!

dial-peer voice 2200 voip

description Outgoing CUCM Call Leg

session protocol sipv2

session server-group 2200

destination-pattern ABC123

voice-class sip options-keepalive profile 2200

dtmf-relay sip-kpml rtp-nte

codec g711ulaw

ip qos dscp cs3 signaling

no vad

!

! a little something extra here at the end

alias exec attra show call active voice | in PeerAddr|PeerId|RemoteS|RemoteM|Dtmf|Coder|VAD

alias exec attrh show call history voice | in PeerAddr|PeerId|RemoteS|RemoteM|Dtmf|Coder|VAD



On Fri, Jun 12, 2020 at 6:36 PM Brian Meade <bmeade90@vt.edu <mailto:bmeade90@vt.edu> > wrote:

Anthony,



Thanks for the feedback. I'll definitely take a look at yours as well.



Here's some answers on mine:

1. While I like that you can give a uri profile a name like ISP, I much prefer to stick with numbers, since for most things, you must use numbers when naming, so this keeps it consistent.

So I usually replace this with the name of the actual SIP carrier. This seems to make it easier for customers to understand but I understand so many other things are number tags only.

2. I don't specify the port in my server groups, since 5060 is default, but I can see how it might help be more explicit for some people

Yea, I've never tried it without specifying the port. I've got a lot of SIP carriers with weird SIP ports so making it stand out in the template helps to know where to change this.

3. Speaking of being explicit though, if that is your intention, I would recommend pref 1 and pref 2, instead of implied pref 0 and pref 1

That's a good idea. I actually exported this from a customer not realizing what it looks like when I use pref 0 and 1. Making it 1 and 2 would make that look cleaner.

4. Why didn't you should your translation profiles and rules too?

These seem to be so customer/SIP carrier specific that I didn't think it was worth it. My most recent one had 80 rules in it because the carrier really cares about 10-digit/11-digit calling for the local area code. So we actually had to split it up for different NPA-NXX whether or not we added a 1.

5. I don't specify UDP as the transport, since it's the default, but again, being explicit doesn't hurt anything

I also make UDP my default but it is nice to have it called out in a template so people know where to change it if needed.

6. I like the extra dtmf on there. too many configs are limited to rtp-nte only and mtps are being invoked for every call to UCCX as one example

Yea, I always add both to make sure we never have to pull in an MTP. I'm not aware of a way to do this globally but would be nice.

7. Why do you drop your fax rate down from 14400 to 9600 as a standard? I might learn something here, as faxing is not my strongest area.

I'm always debugging faxing it seems like. Disabling ECM and reducing speed to 9600 has seemed to help a lot over the years. It's slower but seems to work more reliably with every source/destination fax device. And people don't expect their fax to send quickly anyways.

8. Since you're doing DPGs, you don't need the destination-pattern .T command on the outbound DPs.

It seems like IOS-XE will show a dial-peer as down and skip it if there is no destination-pattern configured. This looks to be called out as explicitely required here even though it isn't used- https://cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/multiple-outbound-dial-peer.html



Using something like ABC123 for the destination-pattern may make more sense to not confuse anyone. Good call.

9a. Why are you not doing sip options ping? I would, and in which case you need a voice class sip options-keepalive profile <https://community.cisco.com/t5/telepresence-and-video/sip-options-ping-and-session-server-group-on-dial-peer/td-p/2994584> since you're using server groups.

I've never been a fan of SIP Options ping. I've always used SIP timers for failover instead. I guess I've had a few outages where waiting for Options Ping to come back up after we fixed the underlying issue added additional delay. For monitoring purposes though, it probably is a good idea to get back into doing that for customers where we're monitoring their CUBEs.

9b. Also, if you do end up turning on options, you do in fact need a destination-pattern command, and in which case, since it's not being used for call routing, I just use like ABC123 as the pattern to ensure it never can be used, but also, mildly clear it's not supposed to be used

I like that idea and referenced it in 8 above.







On Fri, Jun 12, 2020 at 6:29 PM Anthony Holloway <avholloway+cisco-voip@gmail.com <mailto:avholloway%2Bcisco-voip@gmail.com> > wrote:

Brian,



Nice and clean, I like it! Very similar to what I do. I'd like to comment/question yours a bit.



1. While I like that you can give a uri profile a name like ISP, I much prefer to stick with numbers, since for most things, you must use numbers when naming, so this keeps it consistent.

2. I don't specify the port in my server groups, since 5060 is default, but I can see how it might help be more explicit for some people

3. Speaking of being explicit though, if that is your intention, I would recommend pref 1 and pref 2, instead of implied pref 0 and pref 1

4. Why didn't you should your translation profiles and rules too?

5. I don't specify UDP as the transport, since it's the default, but again, being explicit doesn't hurt anything

6. I like the extra dtmf on there. too many configs are limited to rtp-nte only and mtps are being invoked for every call to UCCX as one example

7. Why do you drop your fax rate down from 14400 to 9600 as a standard? I might learn something here, as faxing is not my strongest area.

8. Since you're doing DPGs, you don't need the destination-pattern .T command on the outbound DPs.

9a. Why are you not doing sip options ping? I would, and in which case you need a voice class sip options-keepalive profile <https://community.cisco.com/t5/telepresence-and-video/sip-options-ping-and-session-server-group-on-dial-peer/td-p/2994584> since you're using server groups.

9b. Also, if you do end up turning on options, you do in fact need a destination-pattern command, and in which case, since it's not being used for call routing, I just use like ABC123 as the pattern to ensure it never can be used, but also, mildly clear it's not supposed to be used



I'll post a config as well, in a bit, and please feel free to comment/question mine.









On Fri, Jun 12, 2020 at 3:20 PM Brian Meade <bmeade90@vt.edu <mailto:bmeade90@vt.edu> > wrote:

I've been trying to make a standardized CUBE configuration using a lot of the newer features like dial-peer groups.



This is what I have now. It's an inbound dial-peer for CUCM matching the CUCM IP's via Via header. Then an inbound dial-peer for the ISP. Then an outbound dial-peer to CUCM and an outbound dial-peer to the ISP. If you have more IP's for the ISP or CUCM, you can easily add them. destination-pattern .T is not used at all due to using dial-peer group matching. This doesn't account for bindings that must be done per dial-peer. It also doesn't show translation-profiles/rules.



This gives you 4 total dial-peers to match any number.



If it comes in from CUCM, it will route to the SIP carrier. If it comes in from the SIP carrier, it will route to CUCM.

voice class uri ISP sip
host ipv4:8.8.8.8

voice class uri CUCM sip
host ipv4:192.168.100.100
host ipv4:192.168.100.200

voice class server-group 100
ipv4 8.8.8.8 port 5060

voice class server-group 200
ipv4 192.168.100.100 port 5060
ipv4 192.168.100.200 port 5060 preference 1



voice class dpg 100

voice class dpg 200



dial-peer voice 100 voip
description Incoming Dial-peer from ISP
translation-profile incoming ISPInbound
session protocol sipv2
session transport udp
destination dpg 200
incoming uri via ISP
voice-class codec 1
dtmf-relay rtp-nte sip-kpml
fax-relay ecm disable
fax rate 9600

dial-peer voice 200 voip
description Incoming Dial-peer from CUCM
session protocol sipv2
destination dpg 100
incoming uri via CUCM
voice-class codec 1
dtmf-relay rtp-nte sip-kpml
fax-relay ecm disable
fax rate 9600



dial-peer voice 300 voip
description Outbound to ISP
translation-profile outgoing ISPOutbound
destination-pattern .T
session protocol sipv2
session transport udp
session server-group 100
voice-class codec 1
dtmf-relay rtp-nte sip-kpml
fax-relay ecm disable
fax rate 9600

dial-peer voice 400 voip
description Outbound to CUCM
destination-pattern .T
session protocol sipv2
session server-group 200
voice-class codec 1
dtmf-relay rtp-nte sip-kpml
fax-relay ecm disable
fax rate 9600



voice class dpg 100
dial-peer 300

voice class dpg 200
dial-peer 400



On Fri, Jun 12, 2020 at 3:12 PM JASON BURWELL via cisco-voip <cisco-voip@puck.nether.net <mailto:cisco-voip@puck.nether.net> > wrote:

Does anyone have a good, straightforward reference doc to configuring CUBE dial peers? I have what I would have thought should be a fairly basic config but I’m having trouble getting everything to work properly. I’ve had some assistance but it seems like a whole lot of configuration to do what little I really need to do. Basically, I just need to send whatever comes from CUCM- either 10, 11 or 3 digits in the SIP invite for outbound and for inbound calls the provider sends me 10 digits in the invite, I just need to strip off the first 6 and send the last 4 to CUCM to route. I have a lot of adding and stripping digits going on between CUCM and CUBE to make this work. Just trying to find reference docs to see if any of this can be cleaned up. Thanks

_______________________________________________
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 <mailto:cisco-voip@puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

Getting a little off the “cube config” topic... if there are others with Best practices, tried and true config snippets it’d be nice to see. If you don’t like server groups to reduce dial-peers you can resort to dns srv (even local!)

But I have to say the first time I saw Nate’s CUCM/GW design I thought he was crazy. Route filters???? My first experience with them in 2003 wasn’t pleasant. However, the method used to build, insert, and update them is what changed my thinking from “you’re crazy” to appreciating the logic behind the final product.
I would never want to build something with that extensive NPA/NXX dialing/TEHO out by hand...

Loren

On Jun 16, 2020, at 4:31 PM, Anthony Holloway <avholloway+cisco-voip@gmail.com> wrote:

?
I don't know what it is, but COR list people are also @ route filter people. Nailed it.

"I think having NPA/NXX route patterns would be just too much to look at."

<image.png>


There's a reason the SRND/PA/CVD isn't based off of the @ macro.

"But I just don’t see the point of completely ignoring the call routing engine in CUBE"

So, you must be against matching incoming legs on Via header too, as opposed to incoming called number?

Lastly, you should know that you're wrong about these two points you made:

"If you have two destinations in the group, it just round-robins them"
"...and just say if it comes in this dial-peer send it out any random one of these"

<image.png>


On Tue, Jun 16, 2020 at 4:05 PM NateCCIE <nateccie@gmail.com<mailto:nateccie@gmail.com>> wrote:
No more 9.@, I use \+.@ now. I think having NPA/NXX route patterns would be just too much to look at. I do wish that route filters could be longer than 1024 characters.

But I just don’t see the point of completely ignoring the call routing engine in CUBE and just say if it comes in this dial-peer send it out any random one of these. It doesn’t work with anything but the simplest of configs, and I really appreciate a base config that works for everything and can be expanded upon. More and more when I keep things consistent between deployments, I am quicker at figuring out what’s broken and can fix it quickly, and customers are amazed that I remembered their system.

<image005.png>
<image006.png>

From: Anthony Holloway <avholloway+cisco-voip@gmail.com<mailto:avholloway%2Bcisco-voip@gmail.com>>
Sent: Tuesday, June 16, 2020 1:56 PM
To: NateCCIE <nateccie@gmail.com<mailto:nateccie@gmail.com>>
Cc: Loren Hillukka <lchillukka@hotmail.com<mailto:lchillukka@hotmail.com>>; Cisco VoIP Group <cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>>
Subject: Re: [cisco-voip] CUBE Config Dial Peers

"I cannot stand DPG"
"I use cor-list"

I bet you also are a sadist and use 9.@ too. You and Lelio should form a posse and fight Brian and I. The losers must convert to the other's design.

On Tue, Jun 16, 2020 at 12:17 PM NateCCIE <nateccie@gmail.com<mailto:nateccie@gmail.com>> wrote:
Well once Loren speaks up you know it’s an interesting thread.

My two cents, I cannot stand DPG. Its crazy that it completely ignores destination pattern. If you have two destinations in the group, it just round-robins them. I got burned not understanding that DPG didn’t look at destination pattern and I swore I would never use them again.

I use cor-list to restrict the SP inbound dial-peer to the cucm outbound dial-peer, and vice versa. Matching the inbound dial-peer by URI works great, I started with matching “FROM” but that fell apart in some cases, so I use VIA by default now, and that has been solid.

My numbering is usually 1X for CUCM, with the 0 for inbound in each range, then 2X for the first SIP provider and 3X for the 2nd, maybe 5X for CVP etc.

I always localize on the CUBE, sending a full +E.164 from CUCM and then use translation profiles to format to how the specific country/carrier wants to see the calls. The exception is US 11D/10D determination is done by the CUCM because I find it easier to load all of the local NPA-NXX into CUCM route filters via AXL, but then sometimes I am doing TEHO and have to control which outbound dial-peer it chooses.

I also never let the CUBE choose the carrier, I think mostly because a long time ago I had the same carrier spread over multiple gateways along with multiple carriers in each gateway, and I wanted CUCM to re-route to the other gateway same carrier before CUBE used a less preferred route because it was local. So when there is multiple carriers I usually will prefix 1#* or 2#* on up for each carrier.

Anyway, that’s my 2 cents.


From: cisco-voip <cisco-voip-bounces@puck.nether.net<mailto:cisco-voip-bounces@puck.nether.net>> On Behalf Of Loren Hillukka
Sent: Tuesday, June 16, 2020 10:26 AM
To: Anthony Holloway <avholloway+cisco-voip@gmail.com<mailto:avholloway%2Bcisco-voip@gmail.com>>
Cc: cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
Subject: Re: [cisco-voip] CUBE Config Dial Peers

Nice to see the examples and explanations - thank you! I really like the naming structure to allow simple a show command to pull everything related to one side of the call flow.
URI matching broke down in UCCE environments as uri match overrides all other matching. I needed to match some ingress numbers from the ITSP to apply CVP .tcl scripts too and wasn’t able to when matching all inbound from ITSP via URI. So the config gets a bit longer in UCCE environments due to this.
I ended up using e164-pattern-maps as another means of collapsing dial-peers, with uri match for calls from CUCM, and also server-groups to reduce outbound peers.
Based on the configs from Brian and Anthony, you wouldn’t need e164-pattern-maps in those environments. Curious what direction others have taken to simplify dial-peers with UCCE in play.

Loren

On Jun 16, 2020, at 10:55 AM, Anthony Holloway <avholloway+cisco-voip@gmail.com<mailto:avholloway+cisco-voip@gmail.com>> wrote:
?
Sorry, transmission failed. Try disabling NSF and re-sending.

Back to the point of ABC123, it would be so nice if we could add comments to the show run. Second best is to keep a commented copy of the config off box in your documentation repository.

On Mon, Jun 15, 2020 at 11:31 PM Brian Meade <bmeade90@vt.edu<mailto:bmeade90@vt.edu>> wrote:
Anthony,

I like the config. Definitely is nice to have some standardization on the dial-peer tags. I've usually done all my inbound dial-peers in the 1XX range but have gone outside of that lately with separating inbound ITSP and inbound CUCM dial-peers to make them more obvious but I like the idea of having more structure like yours.

Using the destination-pattern ABC123 is a great idea to show that's not used as mentioned before.

I try to always use voice-class codec for every dial-peer even if I've only got 1 codec configured there just to make it easier to change if ever needed but that was in the past when I had separate local/long distance/911/international/10-digit dial-peers. Simplifying it down to a single inbound/outbound dial-peer with the ITSP makes it a toss-up if that helps anymore.

I've tried to keep KPML on my ITSP facing dial-peers just in case they happen to support it. I've found some say they don't but actually do use it if you advertise it. No harm in advertising it from our side.

I like the aliases you've got there as well. I feel like I'm always on some random customer's box so not sure I'd remember to always put them in first but definitely nice to have when you make the full CUBE config.

Looks like all you're missing is your fax config! I can fax that over to you! :)

On Fri, Jun 12, 2020 at 8:53 PM Anthony Holloway <avholloway+cisco-voip@gmail.com<mailto:avholloway%2Bcisco-voip@gmail.com>> wrote:
All great points, thanks for taking the time to respond.

The only one I think that I need to reply to is the DPG and destination-pattern one. I was actually troubleshooting a customer CUBE wherein this exact scenario was in place and the only negative was getting options to work. Otherwise, it was routing the call just fine. Granted, I couldn't tell you what version that was, as it was like a year or so ago, but either way, I always put a destination-pattern on because you need one for options to function.

I guess I could reply to one more, and that has to do with tweaking retries from 6 to 2 AND using options. Why stick to one, when you can do both?

Here's the one I use which I said was very similar to yours.

The first thing to note is the numeric structure of my tags.

1000 series numbers are the ITSP side
2000 series numbers are the CUCM side

I would expand this to 3000, 4000, etc., for additional integrations like PRIs, FXO, second ITSP, second PBX, etc. Most I ever had was 6 integrations into a single CUBE i think.

The second digit is 1 for incoming and 2 for outgoing.

The 4rd and fourth digit are generally not used, unless I need additional dial-peers for the same peer and direction, but doing something slightly different. Most I ever used was like 15 i think. E.g., 2215 But that was not using IP addresses in the matching and DPGs, that was using phone number matching, and I was using steering codes.

This numbering structure allows me to do something like this:

show run | section 12..

Which would then show me the following all at once: URI, Server Group, Profile and Dial Peers all pertaining to the outgoing ITSP leg.

Also, in this example, we pass +E164 through the gateway bi-directionally, so no digit manip needed.

voice class uri 1100 sip
host ipv4:8.8.8.8
host ipv4:9.9.9.9
!
voice class server-group 1200
description ITSP Peers
ipv4 8.8.8.8 preference 1
ipv4 9.9.9.9 preference 2
!
voice class sip-options-keepalive 1200
description ITSP Peers (Intentionally Left Blank)
!
voice class uri 2100 sip
host ipv4:10.1.1.2
host ipv4:10.1.1.3
!
voice class server-group 2200
description CUCM Nodes
ipv4 10.1.1.2 preference 1
ipv4 10.1.1.3 preference 2
!
voice class sip-options-keepalive 2200
description CUCM Nodes (Intentionally Left Blank)
!
voice class dpg 1200
dial-peer 1200
!
voice class dpg 2200
dial-peer 2200
!
dial-peer voice 1100 voip
description Incoming ITSP Call Leg
session protocol sipv2
incoming uri via 1100
destination dpg 2200
dtmf-relay rtp-nte ; ITSP only supports one dtmf relay
codec g711ulaw ; ITSP only supports one codec
ip qos dscp cs3 signaling
no vad
!
dial-peer voice 1200 voip
description Outgoing ITSP Call Leg
destination-pattern ABC123
session protocol sipv2
session server-group 1200
voice-class sip options-keepalive profile 1200
dtmf-relay rtp-nte
codec g711ulaw
ip qos dscp cs3 signaling
no vad
!
dial-peer voice 2100 voip
description Incoming CUCM Call Leg
session protocol sipv2
incoming uri via 2100
destination dpg 1200
dtmf-relay sip-kpml rtp-nte ; we support both in- and out-of-band internally and cube interworks dtmf
codec g711ulaw
ip qos dscp cs3 signaling
no vad
!
dial-peer voice 2200 voip
description Outgoing CUCM Call Leg
session protocol sipv2
session server-group 2200
destination-pattern ABC123
voice-class sip options-keepalive profile 2200
dtmf-relay sip-kpml rtp-nte
codec g711ulaw
ip qos dscp cs3 signaling
no vad
!
! a little something extra here at the end
alias exec attra show call active voice | in PeerAddr|PeerId|RemoteS|RemoteM|Dtmf|Coder|VAD
alias exec attrh show call history voice | in PeerAddr|PeerId|RemoteS|RemoteM|Dtmf|Coder|VAD

On Fri, Jun 12, 2020 at 6:36 PM Brian Meade <bmeade90@vt.edu<mailto:bmeade90@vt.edu>> wrote:
Anthony,

Thanks for the feedback. I'll definitely take a look at yours as well.

Here's some answers on mine:
1. While I like that you can give a uri profile a name like ISP, I much prefer to stick with numbers, since for most things, you must use numbers when naming, so this keeps it consistent.
So I usually replace this with the name of the actual SIP carrier. This seems to make it easier for customers to understand but I understand so many other things are number tags only.
2. I don't specify the port in my server groups, since 5060 is default, but I can see how it might help be more explicit for some people
Yea, I've never tried it without specifying the port. I've got a lot of SIP carriers with weird SIP ports so making it stand out in the template helps to know where to change this.
3. Speaking of being explicit though, if that is your intention, I would recommend pref 1 and pref 2, instead of implied pref 0 and pref 1
That's a good idea. I actually exported this from a customer not realizing what it looks like when I use pref 0 and 1. Making it 1 and 2 would make that look cleaner.
4. Why didn't you should your translation profiles and rules too?
These seem to be so customer/SIP carrier specific that I didn't think it was worth it. My most recent one had 80 rules in it because the carrier really cares about 10-digit/11-digit calling for the local area code. So we actually had to split it up for different NPA-NXX whether or not we added a 1.
5. I don't specify UDP as the transport, since it's the default, but again, being explicit doesn't hurt anything
I also make UDP my default but it is nice to have it called out in a template so people know where to change it if needed.
6. I like the extra dtmf on there. too many configs are limited to rtp-nte only and mtps are being invoked for every call to UCCX as one example
Yea, I always add both to make sure we never have to pull in an MTP. I'm not aware of a way to do this globally but would be nice.
7. Why do you drop your fax rate down from 14400 to 9600 as a standard? I might learn something here, as faxing is not my strongest area.
I'm always debugging faxing it seems like. Disabling ECM and reducing speed to 9600 has seemed to help a lot over the years. It's slower but seems to work more reliably with every source/destination fax device. And people don't expect their fax to send quickly anyways.
8. Since you're doing DPGs, you don't need the destination-pattern .T command on the outbound DPs.
It seems like IOS-XE will show a dial-peer as down and skip it if there is no destination-pattern configured. This looks to be called out as explicitely required here even though it isn't used- https://cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/multiple-outbound-dial-peer.html

Using something like ABC123 for the destination-pattern may make more sense to not confuse anyone. Good call.
9a. Why are you not doing sip options ping? I would, and in which case you need a voice class sip options-keepalive profile<https://community.cisco.com/t5/telepresence-and-video/sip-options-ping-and-session-server-group-on-dial-peer/td-p/2994584> since you're using server groups.
I've never been a fan of SIP Options ping. I've always used SIP timers for failover instead. I guess I've had a few outages where waiting for Options Ping to come back up after we fixed the underlying issue added additional delay. For monitoring purposes though, it probably is a good idea to get back into doing that for customers where we're monitoring their CUBEs.
9b. Also, if you do end up turning on options, you do in fact need a destination-pattern command, and in which case, since it's not being used for call routing, I just use like ABC123 as the pattern to ensure it never can be used, but also, mildly clear it's not supposed to be used
I like that idea and referenced it in 8 above.



On Fri, Jun 12, 2020 at 6:29 PM Anthony Holloway <avholloway+cisco-voip@gmail.com<mailto:avholloway%2Bcisco-voip@gmail.com>> wrote:
Brian,

Nice and clean, I like it! Very similar to what I do. I'd like to comment/question yours a bit.

1. While I like that you can give a uri profile a name like ISP, I much prefer to stick with numbers, since for most things, you must use numbers when naming, so this keeps it consistent.
2. I don't specify the port in my server groups, since 5060 is default, but I can see how it might help be more explicit for some people
3. Speaking of being explicit though, if that is your intention, I would recommend pref 1 and pref 2, instead of implied pref 0 and pref 1
4. Why didn't you should your translation profiles and rules too?
5. I don't specify UDP as the transport, since it's the default, but again, being explicit doesn't hurt anything
6. I like the extra dtmf on there. too many configs are limited to rtp-nte only and mtps are being invoked for every call to UCCX as one example
7. Why do you drop your fax rate down from 14400 to 9600 as a standard? I might learn something here, as faxing is not my strongest area.
8. Since you're doing DPGs, you don't need the destination-pattern .T command on the outbound DPs.
9a. Why are you not doing sip options ping? I would, and in which case you need a voice class sip options-keepalive profile<https://community.cisco.com/t5/telepresence-and-video/sip-options-ping-and-session-server-group-on-dial-peer/td-p/2994584> since you're using server groups.
9b. Also, if you do end up turning on options, you do in fact need a destination-pattern command, and in which case, since it's not being used for call routing, I just use like ABC123 as the pattern to ensure it never can be used, but also, mildly clear it's not supposed to be used

I'll post a config as well, in a bit, and please feel free to comment/question mine.




On Fri, Jun 12, 2020 at 3:20 PM Brian Meade <bmeade90@vt.edu<mailto:bmeade90@vt.edu>> wrote:
I've been trying to make a standardized CUBE configuration using a lot of the newer features like dial-peer groups.

This is what I have now. It's an inbound dial-peer for CUCM matching the CUCM IP's via Via header. Then an inbound dial-peer for the ISP. Then an outbound dial-peer to CUCM and an outbound dial-peer to the ISP. If you have more IP's for the ISP or CUCM, you can easily add them. destination-pattern .T is not used at all due to using dial-peer group matching. This doesn't account for bindings that must be done per dial-peer. It also doesn't show translation-profiles/rules.

This gives you 4 total dial-peers to match any number.

If it comes in from CUCM, it will route to the SIP carrier. If it comes in from the SIP carrier, it will route to CUCM.

voice class uri ISP sip
host ipv4:8.8.8.8

voice class uri CUCM sip
host ipv4:192.168.100.100
host ipv4:192.168.100.200

voice class server-group 100
ipv4 8.8.8.8 port 5060

voice class server-group 200
ipv4 192.168.100.100 port 5060
ipv4 192.168.100.200 port 5060 preference 1

voice class dpg 100

voice class dpg 200

dial-peer voice 100 voip
description Incoming Dial-peer from ISP
translation-profile incoming ISPInbound
session protocol sipv2
session transport udp
destination dpg 200
incoming uri via ISP
voice-class codec 1
dtmf-relay rtp-nte sip-kpml
fax-relay ecm disable
fax rate 9600

dial-peer voice 200 voip
description Incoming Dial-peer from CUCM
session protocol sipv2
destination dpg 100
incoming uri via CUCM
voice-class codec 1
dtmf-relay rtp-nte sip-kpml
fax-relay ecm disable
fax rate 9600

dial-peer voice 300 voip
description Outbound to ISP
translation-profile outgoing ISPOutbound
destination-pattern .T
session protocol sipv2
session transport udp
session server-group 100
voice-class codec 1
dtmf-relay rtp-nte sip-kpml
fax-relay ecm disable
fax rate 9600

dial-peer voice 400 voip
description Outbound to CUCM
destination-pattern .T
session protocol sipv2
session server-group 200
voice-class codec 1
dtmf-relay rtp-nte sip-kpml
fax-relay ecm disable
fax rate 9600

voice class dpg 100
dial-peer 300

voice class dpg 200
dial-peer 400

On Fri, Jun 12, 2020 at 3:12 PM JASON BURWELL via cisco-voip <cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>> wrote:
Does anyone have a good, straightforward reference doc to configuring CUBE dial peers? I have what I would have thought should be a fairly basic config but I’m having trouble getting everything to work properly. I’ve had some assistance but it seems like a whole lot of configuration to do what little I really need to do. Basically, I just need to send whatever comes from CUCM- either 10, 11 or 3 digits in the SIP invite for outbound and for inbound calls the provider sends me 10 digits in the invite, I just need to strip off the first 6 and send the last 4 to CUCM to route. I have a lot of adding and stripping digits going on between CUCM and CUBE to make this work. Just trying to find reference docs to see if any of this can be cleaned up. Thanks
_______________________________________________
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<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

There's literally no single best practice. You build it how you need to.

No matter what you build, I bet someone could pick it apart. The only
question you need to ask yourself is: does it meet the requirements? If it
does, then great. If not, change it.

Nothing needs to be built initially for the highest optimizations or
biggest scale or longest survivability. It's ok for designs to evolve over
time.

On Tue, Jun 16, 2020 at 5:13 PM Loren Hillukka <lchillukka@hotmail.com>
wrote:

> Getting a little off the “cube config” topic... if there are others with
> Best practices, tried and true config snippets it’d be nice to see. If you
> don’t like server groups to reduce dial-peers you can resort to dns srv
> (even local!)
>
> But I have to say the first time I saw Nate’s CUCM/GW design I thought he
> was crazy. Route filters???? My first experience with them in 2003 wasn’t
> pleasant. However, the method used to build, insert, and update them is
> what changed my thinking from “you’re crazy” to appreciating the logic
> behind the final product.
> I would never want to build something with that extensive NPA/NXX
> dialing/TEHO out by hand...
>
> Loren
>
> On Jun 16, 2020, at 4:31 PM, Anthony Holloway <
> avholloway+cisco-voip@gmail.com> wrote:
>
> ?
> I don't know what it is, but COR list people are also @ route filter
> people. Nailed it.
>
> *"I think having NPA/NXX route patterns would be just too much to look
> at."*
>
> <image.png>
>
>
> There's a reason the SRND/PA/CVD isn't based off of the @ macro.
>
> *"But I just don’t see the point of completely ignoring the call routing
> engine in CUBE"*
>
> So, you must be against matching incoming legs on Via header too, as
> opposed to incoming called number?
>
> Lastly, you should know that you're wrong about these two points you made:
>
> *"If you have two destinations in the group, it just round-robins them"*
> *"...and just say if it comes in this dial-peer send it out any random one
> of these"*
>
> <image.png>
>
>
> On Tue, Jun 16, 2020 at 4:05 PM NateCCIE <nateccie@gmail.com> wrote:
>
>> No more 9.@, I use \+.@ now. I think having NPA/NXX route patterns
>> would be just too much to look at. I do wish that route filters could be
>> longer than 1024 characters.
>>
>>
>>
>> But I just don’t see the point of completely ignoring the call routing
>> engine in CUBE and just say if it comes in this dial-peer send it out any
>> random one of these. It doesn’t work with anything but the simplest of
>> configs, and I really appreciate a base config that works for everything
>> and can be expanded upon. More and more when I keep things consistent
>> between deployments, I am quicker at figuring out what’s broken and can fix
>> it quickly, and customers are amazed that I remembered their system.
>>
>>
>>
>> <image005.png>
>>
>> <image006.png>
>>
>>
>>
>> *From:* Anthony Holloway <avholloway+cisco-voip@gmail.com>
>> *Sent:* Tuesday, June 16, 2020 1:56 PM
>> *To:* NateCCIE <nateccie@gmail.com>
>> *Cc:* Loren Hillukka <lchillukka@hotmail.com>; Cisco VoIP Group <
>> cisco-voip@puck.nether.net>
>> *Subject:* Re: [cisco-voip] CUBE Config Dial Peers
>>
>>
>>
>> "I cannot stand DPG"
>>
>> "I use cor-list"
>>
>>
>>
>> I bet you also are a sadist and use 9.@ too. You and Lelio should form
>> a posse and fight Brian and I. The losers must convert to the other's
>> design.
>>
>>
>>
>> On Tue, Jun 16, 2020 at 12:17 PM NateCCIE <nateccie@gmail.com> wrote:
>>
>> Well once Loren speaks up you know it’s an interesting thread.
>>
>>
>>
>> My two cents, I cannot stand DPG. Its crazy that it completely ignores
>> destination pattern. If you have two destinations in the group, it just
>> round-robins them. I got burned not understanding that DPG didn’t look at
>> destination pattern and I swore I would never use them again.
>>
>>
>>
>> I use cor-list to restrict the SP inbound dial-peer to the cucm outbound
>> dial-peer, and vice versa. Matching the inbound dial-peer by URI works
>> great, I started with matching “FROM” but that fell apart in some cases, so
>> I use VIA by default now, and that has been solid.
>>
>>
>>
>> My numbering is usually 1X for CUCM, with the 0 for inbound in each
>> range, then 2X for the first SIP provider and 3X for the 2nd, maybe 5X
>> for CVP etc.
>>
>>
>>
>> I always localize on the CUBE, sending a full +E.164 from CUCM and then
>> use translation profiles to format to how the specific country/carrier
>> wants to see the calls. The exception is US 11D/10D determination is done
>> by the CUCM because I find it easier to load all of the local NPA-NXX into
>> CUCM route filters via AXL, but then sometimes I am doing TEHO and have to
>> control which outbound dial-peer it chooses.
>>
>>
>>
>> I also never let the CUBE choose the carrier, I think mostly because a
>> long time ago I had the same carrier spread over multiple gateways along
>> with multiple carriers in each gateway, and I wanted CUCM to re-route to
>> the other gateway same carrier before CUBE used a less preferred route
>> because it was local. So when there is multiple carriers I usually will
>> prefix 1#* or 2#* on up for each carrier.
>>
>>
>>
>> Anyway, that’s my 2 cents.
>>
>>
>>
>>
>>
>> *From:* cisco-voip <cisco-voip-bounces@puck.nether.net> *On Behalf Of *Loren
>> Hillukka
>> *Sent:* Tuesday, June 16, 2020 10:26 AM
>> *To:* Anthony Holloway <avholloway+cisco-voip@gmail.com>
>> *Cc:* cisco-voip@puck.nether.net
>> *Subject:* Re: [cisco-voip] CUBE Config Dial Peers
>>
>>
>>
>> Nice to see the examples and explanations - thank you! I really like the
>> naming structure to allow simple a show command to pull everything related
>> to one side of the call flow.
>>
>> URI matching broke down in UCCE environments as uri match overrides all
>> other matching. I needed to match some ingress numbers from the ITSP to
>> apply CVP .tcl scripts too and wasn’t able to when matching all inbound
>> from ITSP via URI. So the config gets a bit longer in UCCE environments
>> due to this.
>>
>> I ended up using e164-pattern-maps as another means of collapsing
>> dial-peers, with uri match for calls from CUCM, and also server-groups to
>> reduce outbound peers.
>>
>> Based on the configs from Brian and Anthony, you wouldn’t need
>> e164-pattern-maps in those environments. Curious what direction others
>> have taken to simplify dial-peers with UCCE in play.
>>
>>
>>
>> Loren
>>
>>
>>
>> On Jun 16, 2020, at 10:55 AM, Anthony Holloway <
>> avholloway+cisco-voip@gmail.com> wrote:
>>
>> ?
>>
>> Sorry, transmission failed. Try disabling NSF and re-sending.
>>
>>
>>
>> Back to the point of ABC123, it would be so nice if we could add comments
>> to the show run. Second best is to keep a commented copy of the config off
>> box in your documentation repository.
>>
>>
>>
>> On Mon, Jun 15, 2020 at 11:31 PM Brian Meade <bmeade90@vt.edu> wrote:
>>
>> Anthony,
>>
>>
>>
>> I like the config. Definitely is nice to have some standardization on
>> the dial-peer tags. I've usually done all my inbound dial-peers in the 1XX
>> range but have gone outside of that lately with separating inbound ITSP and
>> inbound CUCM dial-peers to make them more obvious but I like the idea of
>> having more structure like yours.
>>
>>
>>
>> Using the destination-pattern ABC123 is a great idea to show that's not
>> used as mentioned before.
>>
>>
>>
>> I try to always use voice-class codec for every dial-peer even if I've
>> only got 1 codec configured there just to make it easier to change if ever
>> needed but that was in the past when I had separate local/long
>> distance/911/international/10-digit dial-peers. Simplifying it down to a
>> single inbound/outbound dial-peer with the ITSP makes it a toss-up if that
>> helps anymore.
>>
>>
>>
>> I've tried to keep KPML on my ITSP facing dial-peers just in case they
>> happen to support it. I've found some say they don't but actually do use
>> it if you advertise it. No harm in advertising it from our side.
>>
>>
>>
>> I like the aliases you've got there as well. I feel like I'm always on
>> some random customer's box so not sure I'd remember to always put them in
>> first but definitely nice to have when you make the full CUBE config.
>>
>>
>>
>> Looks like all you're missing is your fax config! I can fax that over to
>> you! :)
>>
>>
>>
>> On Fri, Jun 12, 2020 at 8:53 PM Anthony Holloway <
>> avholloway+cisco-voip@gmail.com> wrote:
>>
>> All great points, thanks for taking the time to respond.
>>
>>
>>
>> The only one I think that I need to reply to is the DPG and
>> destination-pattern one. I was actually troubleshooting a customer CUBE
>> wherein this exact scenario was in place and the only negative was getting
>> options to work. Otherwise, it was routing the call just fine. Granted, I
>> couldn't tell you what version that was, as it was like a year or so ago,
>> but either way, I always put a destination-pattern on because you need one
>> for options to function.
>>
>>
>>
>> I guess I could reply to one more, and that has to do with tweaking
>> retries from 6 to 2 AND using options. Why stick to one, when you can do
>> both?
>>
>>
>>
>> Here's the one I use which I said was very similar to yours.
>>
>>
>>
>> The first thing to note is the numeric structure of my tags.
>>
>>
>>
>> 1000 series numbers are the ITSP side
>>
>> 2000 series numbers are the CUCM side
>>
>>
>>
>> I would expand this to 3000, 4000, etc., for additional integrations like
>> PRIs, FXO, second ITSP, second PBX, etc. Most I ever had was 6
>> integrations into a single CUBE i think.
>>
>>
>>
>> The second digit is 1 for incoming and 2 for outgoing.
>>
>>
>>
>> The 4rd and fourth digit are generally not used, unless I need additional
>> dial-peers for the same peer and direction, but doing something slightly
>> different. Most I ever used was like 15 i think. E.g., 2215 But that was
>> not using IP addresses in the matching and DPGs, that was using phone
>> number matching, and I was using steering codes.
>>
>>
>>
>> This numbering structure allows me to do something like this:
>>
>>
>>
>> show run | section 12..
>>
>>
>>
>> Which would then show me the following all at once: URI, Server Group,
>> Profile and Dial Peers all pertaining to the outgoing ITSP leg.
>>
>>
>>
>> Also, in this example, we pass +E164 through the gateway
>> bi-directionally, so no digit manip needed.
>>
>>
>>
>> voice class uri 1100 sip
>>
>> host ipv4:8.8.8.8
>>
>> host ipv4:9.9.9.9
>>
>> !
>>
>> voice class server-group 1200
>>
>> description ITSP Peers
>>
>> ipv4 8.8.8.8 preference 1
>>
>> ipv4 9.9.9.9 preference 2
>>
>> !
>>
>> voice class sip-options-keepalive 1200
>>
>> description ITSP Peers (Intentionally Left Blank)
>>
>> !
>>
>> voice class uri 2100 sip
>>
>> host ipv4:10.1.1.2
>>
>> host ipv4:10.1.1.3
>>
>> !
>>
>> voice class server-group 2200
>>
>> description CUCM Nodes
>>
>> ipv4 10.1.1.2 preference 1
>>
>> ipv4 10.1.1.3 preference 2
>>
>> !
>>
>> voice class sip-options-keepalive 2200
>>
>> description CUCM Nodes (Intentionally Left Blank)
>>
>> !
>>
>> voice class dpg 1200
>>
>> dial-peer 1200
>>
>> !
>>
>> voice class dpg 2200
>>
>> dial-peer 2200
>>
>> !
>>
>> dial-peer voice 1100 voip
>>
>> description Incoming ITSP Call Leg
>>
>> session protocol sipv2
>>
>> incoming uri via 1100
>>
>> destination dpg 2200
>>
>> dtmf-relay rtp-nte ; ITSP only supports one dtmf relay
>>
>> codec g711ulaw ; ITSP only supports one codec
>>
>> ip qos dscp cs3 signaling
>>
>> no vad
>>
>> !
>>
>> dial-peer voice 1200 voip
>>
>> description Outgoing ITSP Call Leg
>>
>> destination-pattern ABC123
>>
>> session protocol sipv2
>>
>> session server-group 1200
>>
>> voice-class sip options-keepalive profile 1200
>>
>> dtmf-relay rtp-nte
>>
>> codec g711ulaw
>>
>> ip qos dscp cs3 signaling
>>
>> no vad
>>
>> !
>>
>> dial-peer voice 2100 voip
>>
>> description Incoming CUCM Call Leg
>>
>> session protocol sipv2
>>
>> incoming uri via 2100
>>
>> destination dpg 1200
>>
>> dtmf-relay sip-kpml rtp-nte ; we support both in- and out-of-band
>> internally and cube interworks dtmf
>>
>> codec g711ulaw
>>
>> ip qos dscp cs3 signaling
>>
>> no vad
>>
>> !
>>
>> dial-peer voice 2200 voip
>>
>> description Outgoing CUCM Call Leg
>>
>> session protocol sipv2
>>
>> session server-group 2200
>>
>> destination-pattern ABC123
>>
>> voice-class sip options-keepalive profile 2200
>>
>> dtmf-relay sip-kpml rtp-nte
>>
>> codec g711ulaw
>>
>> ip qos dscp cs3 signaling
>>
>> no vad
>>
>> !
>>
>> ! a little something extra here at the end
>>
>> alias exec attra show call active voice | in
>> PeerAddr|PeerId|RemoteS|RemoteM|Dtmf|Coder|VAD
>>
>> alias exec attrh show call history voice | in
>> PeerAddr|PeerId|RemoteS|RemoteM|Dtmf|Coder|VAD
>>
>>
>>
>> On Fri, Jun 12, 2020 at 6:36 PM Brian Meade <bmeade90@vt.edu> wrote:
>>
>> Anthony,
>>
>>
>>
>> Thanks for the feedback. I'll definitely take a look at yours as well.
>>
>>
>>
>> Here's some answers on mine:
>>
>> 1. While I like that you can give a uri profile a name like ISP, I much
>> prefer to stick with numbers, since for most things, you must use numbers
>> when naming, so this keeps it consistent.
>>
>> So I usually replace this with the name of the actual SIP carrier. This
>> seems to make it easier for customers to understand but I understand so
>> many other things are number tags only.
>>
>> 2. I don't specify the port in my server groups, since 5060 is default,
>> but I can see how it might help be more explicit for some people
>>
>> Yea, I've never tried it without specifying the port. I've got a lot of
>> SIP carriers with weird SIP ports so making it stand out in the template
>> helps to know where to change this.
>>
>> 3. Speaking of being explicit though, if that is your intention, I would
>> recommend pref 1 and pref 2, instead of implied pref 0 and pref 1
>>
>> That's a good idea. I actually exported this from a customer not
>> realizing what it looks like when I use pref 0 and 1. Making it 1 and 2
>> would make that look cleaner.
>>
>> 4. Why didn't you should your translation profiles and rules too?
>>
>> These seem to be so customer/SIP carrier specific that I didn't think it
>> was worth it. My most recent one had 80 rules in it because the carrier
>> really cares about 10-digit/11-digit calling for the local area code. So
>> we actually had to split it up for different NPA-NXX whether or not we
>> added a 1.
>>
>> 5. I don't specify UDP as the transport, since it's the default, but
>> again, being explicit doesn't hurt anything
>>
>> I also make UDP my default but it is nice to have it called out in a
>> template so people know where to change it if needed.
>>
>> 6. I like the extra dtmf on there. too many configs are limited to
>> rtp-nte only and mtps are being invoked for every call to UCCX as one
>> example
>>
>> Yea, I always add both to make sure we never have to pull in an MTP. I'm
>> not aware of a way to do this globally but would be nice.
>>
>> 7. Why do you drop your fax rate down from 14400 to 9600 as a standard?
>> I might learn something here, as faxing is not my strongest area.
>>
>> I'm always debugging faxing it seems like. Disabling ECM and reducing
>> speed to 9600 has seemed to help a lot over the years. It's slower but
>> seems to work more reliably with every source/destination fax device. And
>> people don't expect their fax to send quickly anyways.
>>
>> 8. Since you're doing DPGs, you don't need the destination-pattern .T
>> command on the outbound DPs.
>>
>> It seems like IOS-XE will show a dial-peer as down and skip it if there
>> is no destination-pattern configured. This looks to be called out as
>> explicitely required here even though it isn't used-
>> https://cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/multiple-outbound-dial-peer.html
>>
>>
>>
>> Using something like ABC123 for the destination-pattern may make more
>> sense to not confuse anyone. Good call.
>>
>> 9a. Why are you not doing sip options ping? I would, and in which case
>> you need a voice class sip options-keepalive profile
>> <https://community.cisco.com/t5/telepresence-and-video/sip-options-ping-and-session-server-group-on-dial-peer/td-p/2994584> since
>> you're using server groups.
>>
>> I've never been a fan of SIP Options ping. I've always used SIP timers
>> for failover instead. I guess I've had a few outages where waiting for
>> Options Ping to come back up after we fixed the underlying issue added
>> additional delay. For monitoring purposes though, it probably is a good
>> idea to get back into doing that for customers where we're monitoring their
>> CUBEs.
>>
>> 9b. Also, if you do end up turning on options, you do in fact need a
>> destination-pattern command, and in which case, since it's not being used
>> for call routing, I just use like ABC123 as the pattern to ensure it never
>> can be used, but also, mildly clear it's not supposed to be used
>>
>> I like that idea and referenced it in 8 above.
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Jun 12, 2020 at 6:29 PM Anthony Holloway <
>> avholloway+cisco-voip@gmail.com> wrote:
>>
>> Brian,
>>
>>
>>
>> Nice and clean, I like it! Very similar to what I do. I'd like to
>> comment/question yours a bit.
>>
>>
>>
>> 1. While I like that you can give a uri profile a name like ISP, I much
>> prefer to stick with numbers, since for most things, you must use numbers
>> when naming, so this keeps it consistent.
>>
>> 2. I don't specify the port in my server groups, since 5060 is default,
>> but I can see how it might help be more explicit for some people
>>
>> 3. Speaking of being explicit though, if that is your intention, I would
>> recommend pref 1 and pref 2, instead of implied pref 0 and pref 1
>>
>> 4. Why didn't you should your translation profiles and rules too?
>>
>> 5. I don't specify UDP as the transport, since it's the default, but
>> again, being explicit doesn't hurt anything
>>
>> 6. I like the extra dtmf on there. too many configs are limited to
>> rtp-nte only and mtps are being invoked for every call to UCCX as one
>> example
>>
>> 7. Why do you drop your fax rate down from 14400 to 9600 as a standard?
>> I might learn something here, as faxing is not my strongest area.
>>
>> 8. Since you're doing DPGs, you don't need the destination-pattern .T
>> command on the outbound DPs.
>>
>> 9a. Why are you not doing sip options ping? I would, and in which case
>> you need a voice class sip options-keepalive profile
>> <https://community.cisco.com/t5/telepresence-and-video/sip-options-ping-and-session-server-group-on-dial-peer/td-p/2994584>
>> since you're using server groups.
>>
>> 9b. Also, if you do end up turning on options, you do in fact need a
>> destination-pattern command, and in which case, since it's not being used
>> for call routing, I just use like ABC123 as the pattern to ensure it never
>> can be used, but also, mildly clear it's not supposed to be used
>>
>>
>>
>> I'll post a config as well, in a bit, and please feel free to
>> comment/question mine.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Jun 12, 2020 at 3:20 PM Brian Meade <bmeade90@vt.edu> wrote:
>>
>> I've been trying to make a standardized CUBE configuration using a lot of
>> the newer features like dial-peer groups.
>>
>>
>>
>> This is what I have now. It's an inbound dial-peer for CUCM matching the
>> CUCM IP's via Via header. Then an inbound dial-peer for the ISP. Then an
>> outbound dial-peer to CUCM and an outbound dial-peer to the ISP. If you
>> have more IP's for the ISP or CUCM, you can easily add them.
>> destination-pattern .T is not used at all due to using dial-peer group
>> matching. This doesn't account for bindings that must be done per
>> dial-peer. It also doesn't show translation-profiles/rules.
>>
>>
>>
>> This gives you 4 total dial-peers to match any number.
>>
>>
>>
>> If it comes in from CUCM, it will route to the SIP carrier. If it comes
>> in from the SIP carrier, it will route to CUCM.
>>
>> voice class uri ISP sip
>> host ipv4:8.8.8.8
>>
>> voice class uri CUCM sip
>> host ipv4:192.168.100.100
>> host ipv4:192.168.100.200
>>
>> voice class server-group 100
>> ipv4 8.8.8.8 port 5060
>>
>> voice class server-group 200
>> ipv4 192.168.100.100 port 5060
>> ipv4 192.168.100.200 port 5060 preference 1
>>
>>
>>
>> voice class dpg 100
>>
>> voice class dpg 200
>>
>>
>>
>> dial-peer voice 100 voip
>> description Incoming Dial-peer from ISP
>> translation-profile incoming ISPInbound
>> session protocol sipv2
>> session transport udp
>> destination dpg 200
>> incoming uri via ISP
>> voice-class codec 1
>> dtmf-relay rtp-nte sip-kpml
>> fax-relay ecm disable
>> fax rate 9600
>>
>> dial-peer voice 200 voip
>> description Incoming Dial-peer from CUCM
>> session protocol sipv2
>> destination dpg 100
>> incoming uri via CUCM
>> voice-class codec 1
>> dtmf-relay rtp-nte sip-kpml
>> fax-relay ecm disable
>> fax rate 9600
>>
>>
>>
>> dial-peer voice 300 voip
>> description Outbound to ISP
>> translation-profile outgoing ISPOutbound
>> destination-pattern .T
>> session protocol sipv2
>> session transport udp
>> session server-group 100
>> voice-class codec 1
>> dtmf-relay rtp-nte sip-kpml
>> fax-relay ecm disable
>> fax rate 9600
>>
>> dial-peer voice 400 voip
>> description Outbound to CUCM
>> destination-pattern .T
>> session protocol sipv2
>> session server-group 200
>> voice-class codec 1
>> dtmf-relay rtp-nte sip-kpml
>> fax-relay ecm disable
>> fax rate 9600
>>
>>
>>
>> voice class dpg 100
>> dial-peer 300
>>
>> voice class dpg 200
>> dial-peer 400
>>
>>
>>
>> On Fri, Jun 12, 2020 at 3:12 PM JASON BURWELL via cisco-voip <
>> cisco-voip@puck.nether.net> wrote:
>>
>> Does anyone have a good, straightforward reference doc to configuring
>> CUBE dial peers? I have what I would have thought should be a fairly basic
>> config but I’m having trouble getting everything to work properly. I’ve had
>> some assistance but it seems like a whole lot of configuration to do what
>> little I really need to do. Basically, I just need to send whatever comes
>> from CUCM- either 10, 11 or 3 digits in the SIP invite for outbound and for
>> inbound calls the provider sends me 10 digits in the invite, I just need to
>> strip off the first 6 and send the last 4 to CUCM to route. I have a lot of
>> adding and stripping digits going on between CUCM and CUBE to make this
>> work. Just trying to find reference docs to see if any of this can be
>> cleaned up. Thanks
>>
>> _______________________________________________
>> 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
>>
>> _______________________________________________
>> 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
>
>