[prev in list] [next in list] [prev in thread] [next in thread]
List: cisco-voip
Subject: Re: [cisco-voip] [External] Re: CUBE Config Dial Peers
From: Hunter Fuller <hf0002 () uah ! edu>
Date: 2020-06-16 20:21:34
Message-ID: CAMFTxdQ=PXku_2tQddKLGE1SOUA2B_unO5jxcOn_GhOzd=xsHQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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@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> 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
>
[Attachment #5 (text/html)]
<div dir="ltr"><div>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!</div><div><br></div><div>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.<br></div><div><div><div dir="ltr" class="gmail_signature" \
data-smartmail="gmail_signature"><div dir="ltr"><div><div \
dir="ltr"><div><br>--<br>Hunter Fuller (they)<br>Router Jockey<br>VBH Annex B-5<br>+1 \
256 824 5331<br><br>Office of Information Technology<br>The University of Alabama in \
Huntsville<br>Network \
Engineering</div></div></div></div></div></div><br></div></div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 16, 2020 at 3:17 PM \
Anthony Holloway <<a \
href="mailto:avholloway%2Bcisco-voip@gmail.com">avholloway+cisco-voip@gmail.com</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div \
dir="ltr"><div dir="ltr">"I cannot stand DPG"</div><div dir="ltr">"I \
use cor-list"</div><div dir="ltr"><br></div><div>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.</div></div></div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 16, 2020 at 12:17 \
PM NateCCIE <<a href="mailto:nateccie@gmail.com" \
target="_blank">nateccie@gmail.com</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div><p class="MsoNormal">Well \
once Loren speaks up you know it's an interesting thread.<u></u><u></u></p><p \
class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">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.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p \
class="MsoNormal">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.<u></u><u></u></p><p \
class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">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 2<sup>nd</sup>, maybe 5X for CVP etc.<u></u><u></u></p><p \
class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">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.<u></u><u></u></p><p \
class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">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.<u></u><u></u></p><p \
class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Anyway, that's my 2 \
cents.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p \
class="MsoNormal"><u></u> <u></u></p><div><div style="border-color:rgb(225,225,225) \
currentcolor currentcolor;border-style:solid none none;border-width:1pt medium \
medium;padding:3pt 0in 0in"><p class="MsoNormal"><b>From:</b> cisco-voip <<a \
href="mailto:cisco-voip-bounces@puck.nether.net" \
target="_blank">cisco-voip-bounces@puck.nether.net</a>> <b>On Behalf Of </b>Loren \
Hillukka<br><b>Sent:</b> Tuesday, June 16, 2020 10:26 AM<br><b>To:</b> Anthony \
Holloway <<a href="mailto:avholloway%2Bcisco-voip@gmail.com" \
target="_blank">avholloway+cisco-voip@gmail.com</a>><br><b>Cc:</b> <a \
href="mailto:cisco-voip@puck.nether.net" \
target="_blank">cisco-voip@puck.nether.net</a><br><b>Subject:</b> Re: [cisco-voip] \
CUBE Config Dial Peers<u></u><u></u></p></div></div><p class="MsoNormal"><u></u> \
<u></u></p><p class="MsoNormal">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. <u></u><u></u></p><div><p \
class="MsoNormal">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. \
<u></u><u></u></p></div><div><p class="MsoNormal">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. <u></u><u></u></p></div><div><p \
class="MsoNormal">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. <u></u><u></u></p></div><div><p \
class="MsoNormal"><u></u> <u></u></p><div><p \
class="MsoNormal">Loren<u></u><u></u></p></div><div><p \
class="MsoNormal"><br><br><u></u><u></u></p><blockquote \
style="margin-top:5pt;margin-bottom:5pt"><p class="MsoNormal" \
style="margin-bottom:12pt">On Jun 16, 2020, at 10:55 AM, Anthony Holloway <<a \
href="mailto:avholloway+cisco-voip@gmail.com" \
target="_blank">avholloway+cisco-voip@gmail.com</a>> \
wrote:<u></u><u></u></p></blockquote></div><blockquote \
style="margin-top:5pt;margin-bottom:5pt"><div><p class="MsoNormal"> \
<u></u><u></u></p><div><p class="MsoNormal">Sorry, transmission failed. Try \
disabling NSF and re-sending. <u></u><u></u></p><div><p class="MsoNormal"><u></u> \
<u></u></p></div><div><p class="MsoNormal">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.<u></u><u></u></p></div></div><p class="MsoNormal"><u></u> \
<u></u></p><div><div><p class="MsoNormal">On Mon, Jun 15, 2020 at 11:31 PM Brian \
Meade <<a href="mailto:bmeade90@vt.edu" target="_blank">bmeade90@vt.edu</a>> \
wrote:<u></u><u></u></p></div><blockquote style="border-color:currentcolor \
currentcolor currentcolor rgb(204,204,204);border-style:none none none \
solid;border-width:medium medium medium 1pt;padding:0in 0in 0in \
6pt;margin-left:4.8pt;margin-right:0in"><div><p class="MsoNormal">Anthony, \
<u></u><u></u></p><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p \
class="MsoNormal">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.<u></u><u></u></p></div><div><p \
class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Using the \
destination-pattern ABC123 is a great idea to show that's not used as mentioned \
before.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> \
<u></u></p></div><div><p class="MsoNormal">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.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> \
<u></u></p></div><div><p class="MsoNormal">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.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> \
<u></u></p></div><div><p class="MsoNormal">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.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> \
<u></u></p></div><div><p class="MsoNormal">Looks like all you're missing is your \
fax config! I can fax that over to you! :)<u></u><u></u></p></div></div><p \
class="MsoNormal"><u></u> <u></u></p><div><div><p class="MsoNormal">On Fri, Jun 12, \
2020 at 8:53 PM Anthony Holloway <<a \
href="mailto:avholloway%2Bcisco-voip@gmail.com" \
target="_blank">avholloway+cisco-voip@gmail.com</a>> \
wrote:<u></u><u></u></p></div><blockquote style="border-color:currentcolor \
currentcolor currentcolor rgb(204,204,204);border-style:none none none \
solid;border-width:medium medium medium 1pt;padding:0in 0in 0in \
6pt;margin-left:4.8pt;margin-right:0in"><div><div><div><div><div><div><p \
class="MsoNormal">All great points, thanks for taking the time to respond. \
<u></u><u></u></p><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p \
class="MsoNormal">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.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> \
<u></u></p></div><div><p class="MsoNormal">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?<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> \
<u></u></p></div><div><p class="MsoNormal">Here's the one I use which I said was \
very similar to yours.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> \
<u></u></p></div><div><p class="MsoNormal">The first thing to note is the numeric \
structure of my tags.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> \
<u></u></p></div><div><p class="MsoNormal">1000 series numbers are the ITSP \
side<u></u><u></u></p></div><div><p class="MsoNormal">2000 series numbers are the \
CUCM side<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> \
<u></u></p></div><div><p class="MsoNormal">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.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> \
<u></u></p></div><div><p class="MsoNormal">The second digit is 1 for incoming and 2 \
for outgoing.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> \
<u></u></p></div><div><p class="MsoNormal">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.<u></u><u></u></p></div><div><p \
class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">This numbering \
structure allows me to do something like this:<u></u><u></u></p></div><div><p \
class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal"><span \
style="font-family:"Courier New"">show run | section \
12..</span><u></u><u></u></p></div><div><p class="MsoNormal"><u></u> \
<u></u></p></div><div><p class="MsoNormal">Which would then show me the following all \
at once: URI, Server Group, Profile and Dial Peers all pertaining to the outgoing \
ITSP leg.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> \
<u></u></p></div><div><p class="MsoNormal">Also, in this example, we pass +E164 \
through the gateway bi-directionally, so no digit manip \
needed.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> \
<u></u></p></div><div><div><p class="MsoNormal"><span \
style="font-family:"Courier New"">voice class uri 1100 \
sip</span><u></u><u></u></p></div><div><p class="MsoNormal"><span \
style="font-family:"Courier New""> host \
ipv4:8.8.8.8</span><u></u><u></u></p></div><div><p class="MsoNormal"><span \
style="font-family:"Courier New""> host \
ipv4:9.9.9.9</span><u></u><u></u></p></div><div><p class="MsoNormal"><span \
style="font-family:"Courier New"">!</span><u></u><u></u></p></div><div><p \
class="MsoNormal"><span style="font-family:"Courier New"">voice class \
server-group 1200</span><u></u><u></u></p></div><div><p class="MsoNormal"><span \
style="font-family:"Courier New""> description ITSP \
Peers</span><u></u><u></u></p></div><div><p class="MsoNormal"><span \
style="font-family:"Courier New""> ipv4 8.8.8.8 preference \
1</span><u></u><u></u></p></div><div><p class="MsoNormal"><span \
style="font-family:"Courier New""> ipv4 9.9.9.9 preference \
2</span><u></u><u></u></p></div><div><p class="MsoNormal"><span \
style="font-family:"Courier \
New"">!</span><u></u><u></u></p></div><div><div><p class="MsoNormal"><span \
style="font-family:"Courier New"">voice class sip-options-keepalive \
1200</span><u></u><u></u></p></div><div><p class="MsoNormal"><span \
style="font-family:"Courier New""> description ITSP Peers (Intentionally \
Left Blank)</span><u></u><u></u></p></div><div><p class="MsoNormal"><span \
style="font-family:"Courier \
New"">!</span><u></u><u></u></p></div></div><div><p class="MsoNormal"><span \
style="font-family:"Courier New"">voice class uri 2100 \
sip</span><u></u><u></u></p></div><div><p class="MsoNormal"><span \
style="font-family:"Courier New""> host \
ipv4:10.1.1.2</span><u></u><u></u></p></div><div><p class="MsoNormal"><span \
style="font-family:"Courier New""> host \
ipv4:10.1.1.3</span><u></u><u></u></p></div><div><p class="MsoNormal"><span \
_______________________________________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net" \
target="_blank">cisco-voip@puck.nether.net</a><br> <a \
href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="noreferrer" \
target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br> \
</blockquote></div>
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic