"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 <[email protected]> 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 <[email protected]> *On Behalf Of *Loren > Hillukka > *Sent:* Tuesday, June 16, 2020 10:26 AM > *To:* Anthony Holloway <[email protected]> > *Cc:* [email protected] > *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 < > [email protected]> 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 <[email protected]> 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 < > [email protected]> 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 <[email protected]> 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 < > [email protected]> 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 <[email protected]> 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 < > [email protected]> 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 > [email protected] > https://puck.nether.net/mailman/listinfo/cisco-voip > > _______________________________________________ > cisco-voip mailing list > [email protected] > https://puck.nether.net/mailman/listinfo/cisco-voip > > _______________________________________________ > cisco-voip mailing list > [email protected] > https://puck.nether.net/mailman/listinfo/cisco-voip > >
_______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip
