Hi Guys
If my complete lack of posts has got you down, there is loads of good info over at my good Friend Paul Tursans blog, you can find it here:
http://chilli-net.blogspot.com/
Easily test an FXO Port:
To change on-off hook status
#test voice port 0/3/1 relay loop on
this will force the port to answer.
#test voice port 0/3/1 relay loop on
this will force the port to answer.
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.
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:
Here's an example of a complete call:
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
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
Subscribe to:
Comments (Atom)