This is a real test device, created by a real client with a serious issue.
Drinking straw dispenser, aluminum foil, paper clip, permanent marker...
I hope you're as impressed by the elegance as I was.
Diary of technical happenstance, simple Internet accessible scratchpad, and brain dump to save myself later
Wednesday, September 14, 2011
Tuesday, August 23, 2011
Cisco debug commands for FXS troubleshooting
A short list of some basic IOS debug commands used during some FXS troubleshooting and why...
debug mgcp [packets]
Use to view the complete MGCP packets exchanged between CUCM and router.
debug vpm signal
Use to view the on−hook and off−hook signaling for the voice port.
debug vtsp dsp
Use to view digits collection performed on the router.
debug vtsp tone
Use to view any tone generated by the router (dial tone, busy signal, fastbusy, etc)
To save logs to the VG224, router, switch, etc., check the logging command and show logging to verify what is set now.
logging buffered debugging
Log debug messages to an internal buffer with a default size
debug mgcp [packets]
Use to view the complete MGCP packets exchanged between CUCM and router.
debug vpm signal
Use to view the on−hook and off−hook signaling for the voice port.
debug vtsp dsp
Use to view digits collection performed on the router.
debug vtsp tone
Use to view any tone generated by the router (dial tone, busy signal, fastbusy, etc)
To save logs to the VG224, router, switch, etc., check the logging command and show logging to verify what is set now.
logging buffered debugging
Log debug messages to an internal buffer with a default size
Monday, August 15, 2011
Cisco WLC physically find AP by making LED flash
So you need to physically find a deployed AP that is controlled by a WLC but don't have a physical map...
(You can find this information in the Cisco Wireless LAN Controller Configuration Guide. Reposted here because it's easier than finding it there.)
To enable the controller to send commands to the access point from its CLI, enter this command
debug ap enable your_access_point_name
To cause a specific access point to flash its LEDs for a specified number of seconds, enter this command:
debug ap command "led flash seconds" your_access_point_name
You can enter a value between 1 and 3600 seconds for the seconds parameter.
To disable LED flashing for a specific access point, enter this command:
debug ap command "led flash disable" your_access_point_name
I believe you can still also issue the led flash commands on the local APs but that requires telnetting or SSHing to individual devices.
(You can find this information in the Cisco Wireless LAN Controller Configuration Guide. Reposted here because it's easier than finding it there.)
To enable the controller to send commands to the access point from its CLI, enter this command
debug ap enable your_access_point_name
To cause a specific access point to flash its LEDs for a specified number of seconds, enter this command:
debug ap command "led flash seconds" your_access_point_name
You can enter a value between 1 and 3600 seconds for the seconds parameter.
To disable LED flashing for a specific access point, enter this command:
debug ap command "led flash disable" your_access_point_name
I believe you can still also issue the led flash commands on the local APs but that requires telnetting or SSHing to individual devices.
Tuesday, June 14, 2011
CUCM disconnects and CDR SQL
Please see this post for original content: http://smbitsolutions.wordpress.com/2010/06/11/dropped-call-troubleshooting-in-cucm/
Call disconnect CDR cause codes can be found here: http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/service/7_0_1/car/carsrch.html#wp1085459
For datetimeorigination conversions, use: http://www.onlineconversion.com/unix_time.htm
My customer's complaint was that user at DN 1129 called DN 1194 and was immediately disconnected. The user at 1129 then called 1194 back and was able to complete the call normally. The users were power users and their descriptions of their symptoms weren't doubted.
They have an ISI call accounting system that was capable of supplying a report verifying 2 calls were made between these lines as described, and the disconnecting cause code was 16 (normal).
A little CUCM investigation showed that DN 1194 actually existed on 2 devices, only one of which is typically used. It was the second DN on another device in a remote maintenance area used occasionally by IT vendors.
I imagine the CUCM administrator may have been able to decipher this via the ISI reports, but they asked me to investigate the disconnect report (without access to ISI). I suspected the issue may simply be user error by the IT vendor.
Assuming originator is DN 1129 on SEP001794668C3D, disconnect code is 16, and destination is DN 1194 on SEP0017596ECEEA (good user):
run sql select datetimeorigination,callingpartynumber,origdevicename,destdevicename,finalcalledpartynumber,orignodeid,origlegcallidentifier,destnodeid,destlegidentifier from car:tbl_billing_data where destcause_value=16 and origdevicename='SEP001794668C3D' and destdevicename='SEP0017596ECEEA'
returns:
datetimeorigination callingpartynumber origdevicename destdevicename finalcalledpartynumber orignodeid origlegcallidentifier destnodeid destlegidentifier
=================== ================== =============== =============== ====================== ========== ===================== ========== =================
1307710272 1129 SEP0017946683DC SEP0017596ECEEA 1194 2 44890976 2 44890977
The 1307710272 time converts to Fri, 10 Jun 2011 12:51:12 UTC, one completed call in question.
Assuming originator is DN 1129 on SEP0017946683DC, disconnect code is 16, and destination is DN 1194 on SEP40F4ECEFAE38 (IT vendor device):
run sql select datetimeorigination,callingpartynumber,origdevicename,destdevicename,finalcalledpartynumber,orignodeid,origlegcallidentifier,destnodeid,destlegidentifier from car:tbl_billing_data where destcause_value=16 and origdevicename='SEP0017946683DC' and destdevicename='SEP40F4ECEFAE38'
datetimeorigination callingpartynumber origdevicename destdevicename finalcalledpartynumber orignodeid origlegcallidentifier destnodeid destlegidentifier
=================== ================== =============== =============== ====================== ========== ===================== ========== =================
1307710258 1129 SEP0017946683DC SEP40F4ECEFAE38 1194 2 44890956 2 44890957
The 1307710258 time converts to Fri, 10 Jun 2011 12:50:58 UTC, the one disconnected call in question.
Other interesting CDR SQL:
!
! identify common disconnect cause codes
! by originating cause
!
run sql select count(*) as count,origcause_value from car:tbl_billing_data where origcause_value not in (0,16,126,128,393216,458752) group by origcause_value order by count asc
!
! identify common disconnect cause codes
! by destination cause
!
run sql select count(*) as count,destcause_value from car:tbl_billing_data where destcause_value not in (0,16,126,128,393216,458752) group by destcause_value order by count asc
!
! identify endpoints associated with disconnect cause codes
!
run sql select count(*) as count,origdevicename from car:tbl_billing_data where origcause_value = 47 group by origdevicename order by count asc
Call disconnect CDR cause codes can be found here: http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/service/7_0_1/car/carsrch.html#wp1085459
For datetimeorigination conversions, use: http://www.onlineconversion.com/unix_time.htm
My customer's complaint was that user at DN 1129 called DN 1194 and was immediately disconnected. The user at 1129 then called 1194 back and was able to complete the call normally. The users were power users and their descriptions of their symptoms weren't doubted.
They have an ISI call accounting system that was capable of supplying a report verifying 2 calls were made between these lines as described, and the disconnecting cause code was 16 (normal).
A little CUCM investigation showed that DN 1194 actually existed on 2 devices, only one of which is typically used. It was the second DN on another device in a remote maintenance area used occasionally by IT vendors.
I imagine the CUCM administrator may have been able to decipher this via the ISI reports, but they asked me to investigate the disconnect report (without access to ISI). I suspected the issue may simply be user error by the IT vendor.
Assuming originator is DN 1129 on SEP001794668C3D, disconnect code is 16, and destination is DN 1194 on SEP0017596ECEEA (good user):
run sql select datetimeorigination,callingpartynumber,origdevicename,destdevicename,finalcalledpartynumber,orignodeid,origlegcallidentifier,destnodeid,destlegidentifier from car:tbl_billing_data where destcause_value=16 and origdevicename='SEP001794668C3D' and destdevicename='SEP0017596ECEEA'
returns:
datetimeorigination callingpartynumber origdevicename destdevicename finalcalledpartynumber orignodeid origlegcallidentifier destnodeid destlegidentifier
=================== ================== =============== =============== ====================== ========== ===================== ========== =================
1307710272 1129 SEP0017946683DC SEP0017596ECEEA 1194 2 44890976 2 44890977
The 1307710272 time converts to Fri, 10 Jun 2011 12:51:12 UTC, one completed call in question.
Assuming originator is DN 1129 on SEP0017946683DC, disconnect code is 16, and destination is DN 1194 on SEP40F4ECEFAE38 (IT vendor device):
run sql select datetimeorigination,callingpartynumber,origdevicename,destdevicename,finalcalledpartynumber,orignodeid,origlegcallidentifier,destnodeid,destlegidentifier from car:tbl_billing_data where destcause_value=16 and origdevicename='SEP0017946683DC' and destdevicename='SEP40F4ECEFAE38'
datetimeorigination callingpartynumber origdevicename destdevicename finalcalledpartynumber orignodeid origlegcallidentifier destnodeid destlegidentifier
=================== ================== =============== =============== ====================== ========== ===================== ========== =================
1307710258 1129 SEP0017946683DC SEP40F4ECEFAE38 1194 2 44890956 2 44890957
The 1307710258 time converts to Fri, 10 Jun 2011 12:50:58 UTC, the one disconnected call in question.
Other interesting CDR SQL:
!
! identify common disconnect cause codes
! by originating cause
!
run sql select count(*) as count,origcause_value from car:tbl_billing_data where origcause_value not in (0,16,126,128,393216,458752) group by origcause_value order by count asc
!
! identify common disconnect cause codes
! by destination cause
!
run sql select count(*) as count,destcause_value from car:tbl_billing_data where destcause_value not in (0,16,126,128,393216,458752) group by destcause_value order by count asc
!
! identify endpoints associated with disconnect cause codes
!
run sql select count(*) as count,origdevicename from car:tbl_billing_data where origcause_value = 47 group by origdevicename order by count asc
Thursday, May 26, 2011
Cisco H.323 gateway with FXS port transfer via TCL script
Ultimately, I want to accept hookflash transfers on a T1 CAS fxs-loop-start trunk connected to an older IVR with a Dialogic T1 card. Before I test in production, I wanted to verify this script version reliability and configuration options. Here I am simply using an analog telephone on an VIC2-FXS card, rather than a VWIC2-1MFT-T1/E1 port connected to the Dialogic card.
Using app-h450-transfer.2.0.0.10.tcl, etc. from Cisco's site.
H.323 gateway at 192.168.1.45 is on CUCM at 10.199.2.1. It's a Cisco 2811 with VIC2-2FXS port installed at 0/1/0 with IOS version c2800nm-ipvoicek9-mz.124-22.YB2.bin
!
! NOTE: the entries here are case sensitive.
! Run "show flash:" to verify the directory and TCL script name
!
! The WORD "transfer" below is defined by me and could be any friendly name
! It's used on dial-peers later.
!
! The "param delay-time 0" entry defines how long to wait for the consultation setup
! The script default is 2 seconds.
! Here I've chosen to require no setup time.
! This requires no time between the when the XTO digits are dialed and the XOR hangs up.
!
application
service transfer flash:app-h450-transfer.2.0.0.10.tcl
paramspace english index 0
paramspace english language en
paramspace english location flash:/PROMPTS/EN/
paramspace english prefix en
param delay-time 0
!
! Just binding H.323 to the Ethernet interface.
!
interface FastEthernet0/0
ip address 192.168.1.45 255.255.255.0
duplex full
speed auto
no mop enabled
h323-gateway voip interface
h323-gateway voip bind srcaddr 192.168.1.45
!
! NOTE: here I adjust what an acceptable hookflash duration is from the XOR
!
voice-port 0/1/0
timing hookflash-in 750 150
description *** XOR ***
!
! NOTE: here we associate the service called transfer that is defined above with the incoming voip dial-peer.
! Now a the CUCM knows what to do with a hookflash signal when sending the gateway a call to 1300.
!
dial-peer voice 100 voip
service transfer
voice-class h323 1
incoming called-number 1300
dtmf-relay h245-alphanumeric
codec g711ulaw
no vad
!
! NOTE: here we look for 1300 and send the call to port 0/1/0.
!
dial-peer voice 12 pots
destination-pattern 1300
port 0/1/0
forward-digits 0
!
! NOTE: here we allow the XOR to dial [1-8]... on CUCM to transfer to.
!
dial-peer voice 101 voip
destination-pattern [1-8]...
voice-class h323 1
session target ipv4:10.199.2.1
dtmf-relay h245-alphanumeric
codec g711ulaw
no vad
Now when CUCM user dials 1300 and call is sent to this H.323 gateway, the analog phone at port 0/1/0 rings. The 1300 user can answer, hookflash, dial any other 4 digits and hang up. The callee hears MoH from flash momentarily and is transfered to whatever was dialed.
!
! For reference, here is the "show flash" output
!
-#- --length-- -----date/time------ path
1 47509252 Jun 08 2009 15:44:12 c2800nm-ipvoicek9-mz.124-22.YB2.bin
2 92882 Mar 13 2008 14:18:32 app-h450-transfer.2.0.0.10.tcl
3 0 May 25 2011 16:38:20 PROMPTS
4 0 May 25 2011 16:38:20 PROMPTS/EN
5 21108 Sep 29 2003 15:05:06 PROMPTS/EN/en_author_fail_alaw.au
6 21108 Sep 29 2003 15:05:02 PROMPTS/EN/en_author_fail_ulaw.au
7 96024 Sep 29 2003 15:05:10 PROMPTS/EN/en_busy_tone_alaw.au
8 96024 Sep 29 2003 15:05:04 PROMPTS/EN/en_busy_tone_ulaw.au
9 54172 Sep 29 2003 15:05:02 PROMPTS/EN/en_dest_blocked_alaw.au
10 54172 Sep 29 2003 15:05:08 PROMPTS/EN/en_dest_blocked_ulaw.au
11 42484 Sep 29 2003 15:05:06 PROMPTS/EN/en_dest_busy_alaw.au
12 42484 Sep 29 2003 15:05:02 PROMPTS/EN/en_dest_busy_ulaw.au
13 12668 Sep 29 2003 15:05:08 PROMPTS/EN/en_disconnected_alaw.au
14 12668 Sep 29 2003 15:05:02 PROMPTS/EN/en_disconnected_ulaw.au
15 19512 Sep 29 2003 15:05:06 PROMPTS/EN/en_enter_dest_alaw.au
16 19512 Sep 29 2003 15:05:00 PROMPTS/EN/en_enter_dest_ulaw.au
17 31832 Sep 29 2003 15:05:02 PROMPTS/EN/en_fast_busy_tone_alaw.au
18 31832 Sep 29 2003 15:05:00 PROMPTS/EN/en_fast_busy_tone_ulaw.au
19 496521 Sep 29 2003 15:05:00 PROMPTS/EN/en_music_xferee_alaw.au
20 496521 Sep 29 2003 15:05:08 PROMPTS/EN/en_music_xferee_ulaw.au
21 496521 Sep 29 2003 15:05:10 PROMPTS/EN/en_music_xferto_alaw.au
22 496521 Sep 29 2003 15:05:04 PROMPTS/EN/en_music_xferto_ulaw.au
23 35456 Sep 29 2003 15:05:06 PROMPTS/EN/en_no_dest_entered_alaw.au
24 35456 Sep 29 2003 15:05:02 PROMPTS/EN/en_no_dest_entered_ulaw.au
25 23506 Sep 29 2003 15:05:06 PROMPTS/EN/en_no_service_available_alaw.au
26 23506 Sep 29 2003 15:05:00 PROMPTS/EN/en_no_service_available_ulaw.au
27 42484 Sep 29 2003 15:05:04 PROMPTS/EN/en_operator_is_busy_alaw.au
28 42484 Sep 29 2003 15:05:00 PROMPTS/EN/en_operator_is_busy_ulaw.au
29 17159 Sep 29 2003 15:05:02 PROMPTS/EN/en_reenter_dest_alaw.au
30 17167 Sep 29 2003 15:05:10 PROMPTS/EN/en_reenter_dest_ulaw.au
31 200024 Sep 29 2003 15:05:08 PROMPTS/EN/en_ringback_tone_alaw.au
32 200024 Sep 29 2003 15:05:04 PROMPTS/EN/en_ringback_tone_ulaw.au
Using app-h450-transfer.2.0.0.10.tcl, etc. from Cisco's site.
H.323 gateway at 192.168.1.45 is on CUCM at 10.199.2.1. It's a Cisco 2811 with VIC2-2FXS port installed at 0/1/0 with IOS version c2800nm-ipvoicek9-mz.124-22.YB2.bin
!
! NOTE: the entries here are case sensitive.
! Run "show flash:" to verify the directory and TCL script name
!
! The WORD "transfer" below is defined by me and could be any friendly name
! It's used on dial-peers later.
!
! The "param delay-time 0" entry defines how long to wait for the consultation setup
! The script default is 2 seconds.
! Here I've chosen to require no setup time.
! This requires no time between the when the XTO digits are dialed and the XOR hangs up.
!
application
service transfer flash:app-h450-transfer.2.0.0.10.tcl
paramspace english index 0
paramspace english language en
paramspace english location flash:/PROMPTS/EN/
paramspace english prefix en
param delay-time 0
!
! Just binding H.323 to the Ethernet interface.
!
interface FastEthernet0/0
ip address 192.168.1.45 255.255.255.0
duplex full
speed auto
no mop enabled
h323-gateway voip interface
h323-gateway voip bind srcaddr 192.168.1.45
!
! NOTE: here I adjust what an acceptable hookflash duration is from the XOR
!
voice-port 0/1/0
timing hookflash-in 750 150
description *** XOR ***
!
! NOTE: here we associate the service called transfer that is defined above with the incoming voip dial-peer.
! Now a the CUCM knows what to do with a hookflash signal when sending the gateway a call to 1300.
!
dial-peer voice 100 voip
service transfer
voice-class h323 1
incoming called-number 1300
dtmf-relay h245-alphanumeric
codec g711ulaw
no vad
!
! NOTE: here we look for 1300 and send the call to port 0/1/0.
!
dial-peer voice 12 pots
destination-pattern 1300
port 0/1/0
forward-digits 0
!
! NOTE: here we allow the XOR to dial [1-8]... on CUCM to transfer to.
!
dial-peer voice 101 voip
destination-pattern [1-8]...
voice-class h323 1
session target ipv4:10.199.2.1
dtmf-relay h245-alphanumeric
codec g711ulaw
no vad
Now when CUCM user dials 1300 and call is sent to this H.323 gateway, the analog phone at port 0/1/0 rings. The 1300 user can answer, hookflash, dial any other 4 digits and hang up. The callee hears MoH from flash momentarily and is transfered to whatever was dialed.
!
! For reference, here is the "show flash" output
!
-#- --length-- -----date/time------ path
1 47509252 Jun 08 2009 15:44:12 c2800nm-ipvoicek9-mz.124-22.YB2.bin
2 92882 Mar 13 2008 14:18:32 app-h450-transfer.2.0.0.10.tcl
3 0 May 25 2011 16:38:20 PROMPTS
4 0 May 25 2011 16:38:20 PROMPTS/EN
5 21108 Sep 29 2003 15:05:06 PROMPTS/EN/en_author_fail_alaw.au
6 21108 Sep 29 2003 15:05:02 PROMPTS/EN/en_author_fail_ulaw.au
7 96024 Sep 29 2003 15:05:10 PROMPTS/EN/en_busy_tone_alaw.au
8 96024 Sep 29 2003 15:05:04 PROMPTS/EN/en_busy_tone_ulaw.au
9 54172 Sep 29 2003 15:05:02 PROMPTS/EN/en_dest_blocked_alaw.au
10 54172 Sep 29 2003 15:05:08 PROMPTS/EN/en_dest_blocked_ulaw.au
11 42484 Sep 29 2003 15:05:06 PROMPTS/EN/en_dest_busy_alaw.au
12 42484 Sep 29 2003 15:05:02 PROMPTS/EN/en_dest_busy_ulaw.au
13 12668 Sep 29 2003 15:05:08 PROMPTS/EN/en_disconnected_alaw.au
14 12668 Sep 29 2003 15:05:02 PROMPTS/EN/en_disconnected_ulaw.au
15 19512 Sep 29 2003 15:05:06 PROMPTS/EN/en_enter_dest_alaw.au
16 19512 Sep 29 2003 15:05:00 PROMPTS/EN/en_enter_dest_ulaw.au
17 31832 Sep 29 2003 15:05:02 PROMPTS/EN/en_fast_busy_tone_alaw.au
18 31832 Sep 29 2003 15:05:00 PROMPTS/EN/en_fast_busy_tone_ulaw.au
19 496521 Sep 29 2003 15:05:00 PROMPTS/EN/en_music_xferee_alaw.au
20 496521 Sep 29 2003 15:05:08 PROMPTS/EN/en_music_xferee_ulaw.au
21 496521 Sep 29 2003 15:05:10 PROMPTS/EN/en_music_xferto_alaw.au
22 496521 Sep 29 2003 15:05:04 PROMPTS/EN/en_music_xferto_ulaw.au
23 35456 Sep 29 2003 15:05:06 PROMPTS/EN/en_no_dest_entered_alaw.au
24 35456 Sep 29 2003 15:05:02 PROMPTS/EN/en_no_dest_entered_ulaw.au
25 23506 Sep 29 2003 15:05:06 PROMPTS/EN/en_no_service_available_alaw.au
26 23506 Sep 29 2003 15:05:00 PROMPTS/EN/en_no_service_available_ulaw.au
27 42484 Sep 29 2003 15:05:04 PROMPTS/EN/en_operator_is_busy_alaw.au
28 42484 Sep 29 2003 15:05:00 PROMPTS/EN/en_operator_is_busy_ulaw.au
29 17159 Sep 29 2003 15:05:02 PROMPTS/EN/en_reenter_dest_alaw.au
30 17167 Sep 29 2003 15:05:10 PROMPTS/EN/en_reenter_dest_ulaw.au
31 200024 Sep 29 2003 15:05:08 PROMPTS/EN/en_ringback_tone_alaw.au
32 200024 Sep 29 2003 15:05:04 PROMPTS/EN/en_ringback_tone_ulaw.au
Subscribe to:
Posts (Atom)
