[cisco-voip] [External] Re: CUBE Config Dial Peers
Hunter Fuller
hf0002 at uah.edu
Tue Jun 16 16:21:34 EDT 2020
I am on team DPG but it definitely feels like I am rooting for the option
of less suckage, rather than the best option. There is a ton of cruft in
here!
Anyway I would love to participate in this thread, but we have had some
provider churn over the past 2-3 years, and our config is primarily
spaghetti held together by duct tape and dreams. Maybe I will catch
everyone on the next thread. I know I'm going to be referencing this when
we revamp our configs.
--
Hunter Fuller (they)
Router Jockey
VBH Annex B-5
+1 256 824 5331
Office of Information Technology
The University of Alabama in Huntsville
Network Engineering
On Tue, Jun 16, 2020 at 3:17 PM Anthony Holloway <
avholloway+cisco-voip at 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 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
>>
>> _______________________________________________
> 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/8b9e1c7f/attachment.htm>
More information about the cisco-voip
mailing list