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
