[cisco-voip] CUBE Config Dial Peers
Anthony Holloway
avholloway+cisco-voip at gmail.com
Tue Jun 16 17:28:18 EDT 2020
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: 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: image.png]
On Tue, Jun 16, 2020 at 4:05 PM NateCCIE <nateccie at 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.
>
>
>
>
>
> *From:* Anthony Holloway <avholloway+cisco-voip at gmail.com>
> *Sent:* Tuesday, June 16, 2020 1:56 PM
> *To:* NateCCIE <nateccie at gmail.com>
> *Cc:* Loren Hillukka <lchillukka at hotmail.com>; Cisco VoIP Group <
> cisco-voip at 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 at 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 at puck.nether.net> *On Behalf Of *Loren
> Hillukka
> *Sent:* Tuesday, June 16, 2020 10:26 AM
> *To:* Anthony Holloway <avholloway+cisco-voip at gmail.com>
> *Cc:* cisco-voip at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200616/eedd69f9/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.png
Type: image/png
Size: 59295 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200616/eedd69f9/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image006.png
Type: image/png
Size: 477141 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200616/eedd69f9/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 10924 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200616/eedd69f9/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 556031 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200616/eedd69f9/attachment-0007.png>
More information about the cisco-voip
mailing list