<div dir="ltr">Anthony,<div><br></div><div>Thanks for the feedback. I'll definitely take a look at yours as well.</div><div><br></div><div>Here's some answers on mine:</div><div><div>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.</div><div><font color="#ff0000">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.</font></div><div>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</div><div><font color="#ff0000">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.</font></div><div>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</div><div><font color="#ff0000">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.</font></div><div>4. Why didn't you should your translation profiles and rules too?</div><div><font color="#ff0000">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.</font></div><div>5. I don't specify UDP as the transport, since it's the default, but again, being explicit doesn't hurt anything</div><div><font color="#ff0000">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.</font></div><div>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</div><div><font color="#ff0000">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.</font></div><div>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.</div><div><font color="#ff0000">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.</font></div><div>8. Since you're doing DPGs, you don't need the destination-pattern .T command on the outbound DPs.</div><div><font color="#ff0000">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- <a href="https://cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/multiple-outbound-dial-peer.html">https://cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/multiple-outbound-dial-peer.html</a></font></div><div><font color="#ff0000"><br></font></div><div><font color="#ff0000">Using something like ABC123 for the destination-pattern may make more sense to not confuse anyone. Good call.</font></div><div>9a. Why are you not doing sip options ping? I would, and in which case you <a href="https://community.cisco.com/t5/telepresence-and-video/sip-options-ping-and-session-server-group-on-dial-peer/td-p/2994584" target="_blank">need a voice class sip options-keepalive profile</a> since you're using server groups.</div><div><font color="#ff0000">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.</font></div><div>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</div></div><div><font color="#ff0000">I like that idea and referenced it in 8 above.</font></div><div><font color="#ff0000"><br></font></div><div><font color="#ff0000"><br></font></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 12, 2020 at 6:29 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">Brian,<div><br></div><div>Nice and clean, I like it! Very similar to what I do. I'd like to comment/question yours a bit.</div><div><br></div><div>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.</div><div>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</div><div>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</div><div>4. Why didn't you should your translation profiles and rules too?</div><div>5. I don't specify UDP as the transport, since it's the default, but again, being explicit doesn't hurt anything</div><div>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</div><div>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.</div><div>8. Since you're doing DPGs, you don't need the destination-pattern .T command on the outbound DPs.</div><div>9a. Why are you not doing sip options ping? I would, and in which case you <a href="https://community.cisco.com/t5/telepresence-and-video/sip-options-ping-and-session-server-group-on-dial-peer/td-p/2994584" target="_blank">need a voice class sip options-keepalive profile</a> since you're using server groups.</div><div>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</div><div><br></div><div>I'll post a config as well, in a bit, and please feel free to comment/question mine.</div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 12, 2020 at 3:20 PM Brian Meade <<a href="mailto:bmeade90@vt.edu" target="_blank">bmeade90@vt.edu</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">I've been trying to make a standardized CUBE configuration using a lot of the newer features like dial-peer groups.<div><br></div><div>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. </div><div><br></div><div>This gives you 4 total dial-peers to match any number.</div><div><br></div><div>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.<br><br>voice class uri ISP sip<br> host ipv4:8.8.8.8<br><br>voice class uri CUCM sip<br> host ipv4:192.168.100.100<br> host ipv4:192.168.100.200<br><br>voice class server-group 100<br> ipv4 8.8.8.8 port 5060<br><br>voice class server-group 200<br> ipv4 192.168.100.100 port 5060<br> ipv4 192.168.100.200 port 5060 preference 1<br></div><div><br></div><div>voice class dpg 100<br><br>voice class dpg 200<br></div><div><br></div><div>dial-peer voice 100 voip<br> description Incoming Dial-peer from ISP<br> translation-profile incoming ISPInbound<br> session protocol sipv2<br> session transport udp<br> destination dpg 200<br> incoming uri via ISP<br> voice-class codec 1<br> dtmf-relay rtp-nte sip-kpml<br> fax-relay ecm disable<br> fax rate 9600<br><br>dial-peer voice 200 voip<br> description Incoming Dial-peer from CUCM<br> session protocol sipv2<br> destination dpg 100<br> incoming uri via CUCM<br> voice-class codec 1<br> dtmf-relay rtp-nte sip-kpml<br> fax-relay ecm disable<br> fax rate 9600<br></div><div><br></div><div>dial-peer voice 300 voip<br> description Outbound to ISP<br> translation-profile outgoing ISPOutbound<br> destination-pattern .T<br> session protocol sipv2<br> session transport udp<br> session server-group 100<br> voice-class codec 1<br> dtmf-relay rtp-nte sip-kpml<br> fax-relay ecm disable<br> fax rate 9600<br><br>dial-peer voice 400 voip<br> description Outbound to CUCM<br> destination-pattern .T<br> session protocol sipv2<br> session server-group 200<br> voice-class codec 1<br> dtmf-relay rtp-nte sip-kpml<br> fax-relay ecm disable<br> fax rate 9600<br></div><div><br></div><div>voice class dpg 100<br> dial-peer 300<br><br>voice class dpg 200<br> dial-peer 400<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 12, 2020 at 3:12 PM JASON BURWELL via cisco-voip <<a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</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">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<u></u><u></u></p>
</div>
</div>
_______________________________________________<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>
_______________________________________________<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>
</blockquote></div>