The important of two vBond Controllers

 Hi Guys

Just a quick note: if you only have one vBond controller, you are never going to be able to discover what kind of NAT you are behind, so don't get into the habit of using IP addresses in your system->vbond commands as this will mean that you're not going to be able to determine the NAT type.

If you do use a static "ip host" command, make sure you specify TWO addresses:

ip host vbond-9991397001.sdwan.cisco.com 1.9.151.47 27.155.41.205

use the "show sdwan control local-properties" to find your nat type:

 NAT TYPE: E -- indicates End-point independent mapping

           A -- indicates Address-port dependent mapping

           N -- indicates Not learned

           Note: Requires minimum two vbonds to learn the NAT type

session target loopback:rtp

Hi Everyone!

I came across a feature for Cisco CUBE called loopback RTP. 

It's a great way to test your CUBE SIP configuration by creating a dial-peer that, when matched, will provide a "Test call echo" type feature that simply echo's your voice. Very similar to a skype test call.

Here's a quick example of the configuration:

dial-peer voice 1000 voip

 session protocol sipv2

 destination-pattern 1000

 session target loopback:rtp

!

The feature can be configured on IOS 15 and above.

Check out the description of the feature and link below for additional info, including how to utilize it for testing incoming video calls too :)

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube_proto/configuration/15-mt/cube-proto-15-mt-book/voi-rtp-media.html

"RTP packets are looped back toward the source device when the RTP Media Loopback for SIP Calls feature is configured on a dial peer. The SIP RTP media loopback can be used during Cisco UBE deployments to make test calls to verify the media path between the endpoints and Cisco UBE. In a voice loopback call, an echo is heard at the device originating the call. In a video loopback call, the locally captured video and the audio echo must be rendered at the source device."

(Oh, and apologies for the lack of blog posts, You should see a lot more from me this year, with a lot of posts on SD-WAN coming up!)

The growing importance of DNS in your CUCM configs

Hi Guys!

It used to be that DNS was an afterthought for most CUCM deployments, many engineers advocated at one point or another just using an IP address rather than dealing with the system team who could either be extremely cooperative or extremely slow.

Those days are GONE, my friends. 

Every bit of UC software you use should be properly configured with DNS.

 Infact, anywhere you CAN use DNS, you should be using it.

The main driver for this is definitely Jabber, I can't count the number of things that can go wrong with Jabber if you do not have your DNS configured correctly.

If you absolutely must get a system up very rapidly and the sysadmin team have been very slow to get there side finished, you can use a router as a temporary DNS server:

The config for this is shown below:

conf t
 ip domain-name
ip  dns server
ip name-server 8.8.8.8 4.4.2.2

ip host _cisco-uds._tcp.ccierants.com srv 0 10 8443 cucm01.ccierants.com
ip host cucm01 192.168.1.10
ip host unity 192.168.1.20
ip host imp 192.168.1.30
ip host _cuplogin._tcp.ccierants.com srv 0 10 8443 imp.ccierants.com


As you can see from the example above, you can use the host command to specify manual DNS entries, you can even do SRV records etc, the only records i can't seem to see are CNAME records, but for our purposes this does not matter.

You can then point your UC servers to this router as there DNS server as a temporary workaround while you wait for the system administration team.

How to tell what dial-peers are being matched on an ALREADY ACTIVE call

Hey Guys!

Working out what dial-peers got matched after a call has already begun sometimes seems like a bit of a mystery. For me at least I could never quite work it out. I ran across this command and thought I would share:

maui-gwy-06#show call active voice brief

!--- This information was captured once the call was placed and active.
!---
!--- 
!--- Notice that in this case, default VoIP(keyword IP) dial-peer 0 was 
!--- matched inbound.
 
Total call-legs: 2
87   : 257583579hs.1 +105 pid:0 Answer  active

In the example above, Dial-peer:0 was matched for the incoming since it showed Originate,  answer will show for incoming

Here's an example of a complete call:

0    : 1008757 10:18:47.997 CST Fri Aug 14 2015.1 +2630 pid:9999 Originate 15552226550 connected
 dur 00:17:21 tx:52067/8327756 rx:52050/8328000
 IP 216.200.200.XXX:19296 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g711ulaw TextRelay: off
 media inactive detected:n media contrl rcvd:n/a timestamp:n/a
 long duration call detected:n long duration call duration:n/a timestamp:n/a

0    : 1008795 10:30:13.867 CST Fri Aug 14 2015.1 +11460 pid:99 Answer 5555921332 active
 dur 00:05:46 tx:17311/2769760 rx:17313/2770080
 IP 192.168.122.149:28152 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g711ulaw TextRelay: off
 media inactive detected:n media contrl rcvd:n/a timestamp:n/a
 long duration call detected:n long duration call duration:n/a timestamp:n/a
 

The important sections are in bold, pid:XXXX (where XXX is the dial-peer) the keyword answer or originate (depending on
if this is the incoming dial-peer or outbound dialpeeer) and then the number that has been rung.

I hope this helps!

More Info Here:
http://www.cisco.com/c/en/us/support/docs/voice/call-routing-dial-plans/14074-in-dial-peer-match.html

How to easily tell if a calling name is being sent

show call active voice  | inc CallerName