[cisco-voip] CUBE Config Dial Peers

[Anthony Holloway]

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
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200616/b9fbc3a7/attachment.htm>