Step-by-step troubleshooting of CME/CUE GUI issues. This applies to: a. Cannot access the GUI. b. When we access the CUE GUI, a message is seen "lost contact to host" when accessing the extensions etc. c. A grey window while accessing the CME GUI with "view window" written on the screen. d. "Login to Call Manager Express failed" Steps: 1. Make sure that the following files are in flash: 80  -rw-        3987  Aug 28 2009 01:22:30 -05:00  admin_user.html    81  -rw-      650596  Aug 28 2009 01:22:34 -05:00  admin_user.js    82  -rw-        1029  Aug 28 2009 01:22:34 -05:00  CiscoLogo.gif    83  -rw-         617  Aug 28 2009 01:22:34 -05:00  CME_GUI_README.TXT    84  -rw-         953  Aug 28 2009 01:22:36 -05:00  Delete.gif    85  -rw-       16344  Aug 28 2009 01:22:36 -05:00  dom.js    86  -rw-         864  Aug 28 2009 01:22:36 -05:00  downarrow.gif    87  -rw-        6146  Aug 28 2009 01:22:38 -05:00  ephone_admin.html    88  -rw-        4558  Aug 28 2009 01:22:38 -05:00  logohome.gif    89  -rw-        3866  Aug 28 2009 01:22:38 -05:00  normal_user.html    90  -rw-       78428  Aug 28 2009 01:22:38 -05:00  normal_user.js    91  -rw-        1347  Aug 28 2009 01:22:40 -05:00  Plus.gif    92  -rw-         843  Aug 28 2009 01:22:40 -05:00  sxiconad.gif    93  -rw-         174  Aug 28 2009 01:22:40 -05:00  Tab.gif    94  -rw-        2431  Aug 28 2009 01:22:42 -05:00  telephony_service.html    95  -rw-         870  Aug 28 2009 01:22:42 -05:00  uparrow.gif    96  -rw-        9968  Aug 28 2009 01:22:42 -05:00  xml-test.html    97  -rw-        3412  Aug 28 2009 01:22:42 -05:00  xml.template    98  drw-           0  Jul 16 2009 08:43:58 -05:00  sn 2. The following commands should be there in the router configuration: ip http server ip http authentication local ip http secure-server ip http path flash: 3. Remove any ACLs that may be applied on the interfaces (in particular the ACLs applied on the Service Engine interface, the ip unnumbered interface and the voice/data vlans). Also remove an access group that MAY be applied on the router configuration. It should look like "ip http access-class". 4. Do a "show flash". If the GUI files are in a folder (usually called gui) then the last command in step 2 will need to be ip http path flash:/<folder name> 5. Check pings between the CME and the CUE and between the CUE and the computer in use. If required, you may need to add a static route on the computer in use. Given below is a sample configuration and the corresponding route that I needed to add on my computer in order to access the CUE GUI: interface Loopback0 description $FW_INSIDE$ ip address 10.1.10.2 255.255.255.252 ip virtual-reassembly ! interface Integrated-Service-Engine0/0 ip unnumbered Loopback0 ip virtual-reassembly service-module ip address 10.1.10.1 255.255.255.252 service-module ip default-gateway 10.1.10.2 ! telephony-service ip source-address 10.1.1.1 port 2000 secondary 192.168.4.80 My computer's IP address details: Ethernet adapter Wireless Network Connection 2:         Connection-specific DNS Suffix  . :         IP Address. . . . . . . . . . . . : 10.1.1.17         Subnet Mask . . . . . . . . . . . : 255.255.255.0         Default Gateway . . . . . . . . . : 10.1.1.1 Over here, pings to the CUE don't work and hence I cannot access the GUI: C:\>ping 10.1.10.1 Pinging 10.1.10.1 with 32 bytes of data: Request timed out. Request timed out. Request timed out. Request timed out. Ping statistics for 10.1.10.1:     Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), Hence, I added the following route on my computer and pings worked: C:\>route add 10.1.10.1 mask 255.255.255.255 10.1.1.1 -p C:\>ping 10.1.10.1 Pinging 10.1.10.1 with 32 bytes of data: Reply from 10.1.10.1: bytes=32 time=10ms TTL=63 Reply from 10.1.10.1: bytes=32 time=6ms TTL=63 Reply from 10.1.10.1: bytes=32 time=6ms TTL=63 Reply from 10.1.10.1: bytes=32 time=6ms TTL=63 Ping statistics for 10.1.10.1:     Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds:     Minimum = 6ms, Maximum = 10ms, Average = 7ms Similarly, make sure that you can ping from the CUE to the computer. 6. Make sure that the correct GUI file versions are being used. 7. Ensure that there isn't a firewall blocking traffic (ASA/PIX or a PC firewall). ... View more

A few things that can be done while troubleshooting issues with the wireless phones. (the factory reset procedure varies between the phone models, but the rest is applicable across phone types). 1. Factory default the phone by going to Settings - - -> Phone settings - - - > Pressing **2 - - -> Pressing the "yes" softkey. 2. Install the USB driver on a Windows XP PC. Connect the phone via a USB cable and browse to the Web page of the phone by going to https://192.168.1.100 AFTER going to Start - - > Run - - > ncpa.cpl - - > Right click on the “Wireless phone network connection” - - -> Properties - - -> TCP/IP - - - > Use the following IP address - - -> Entered 192.168.1.123 with a mask of 255.255.255.0 - - -> Clicked on OK and then OK again. (The IP address of the computer should be any IP address in the 192.168.1.[1-254] range EXCEPT 192.168.1.100 and any other IP address already being used in the network.) 3. Click on "phone upgrade" and entered admin/Cisco as the username/password. (note that the password has a capital "C") 4. Browse to the TAR file firmware version saved on the computer and upload the firmware on the phone. 5. Once the phone upgrade goes through, modify the Network profile and SSID details to register the phone. Be patient during the phone upgrade - it might take QUITE some time. 6. Add the line buttons through the GUI - only 1 line button seen. 7. Make sure that the IOS/CME and CUE versions are compatible and ensure that the correct GUI file versions have been loaded. This can be checked by going to help - - -> about on the GUI. Reset the phone if the versions are compatible and then check for the line buttons. ... View more

Here is a custom made guide which will help you through the upgrade process. This has been designed keeping a UC 520 in mind, but the basic procedure remains the same across platforms. PREREQUISITES ============ 1.        It is assumed that you have downloaded the UC520 – 7.0.2.zip file from the link which I had sent to you. 2.        You should have a TFTP AND an FTP server configured. The TFTP server can be downloaded at http://tftpd32.jounin.net/tftpd32_download.html. The TFTP server only needs to be started up and the files placed in the root directory for it to work. For the FTP server, I have attached a file entitled ConfigSFTP.zip which will walk you through the FTP server configuration process. Please make sure that the computer on which these are being installed can be pinged from the CME and the CUE. The FTP server is going to be used for the CUE upgrade and the TFTP server for everything else. 3.        Ensure that you have some down time for the upgrade and that there is enough memory in flash. To delete files in flash, use the command “delete flash:<full file name>” UPGRADING THE IOS ================= 1.        The .zip file that you downloaded for the UC520 has an IOS image in it (uc500-advipservicesk9-mz.124-20.T2). Place this file in the root directory of the TFTP server. 2.        Start a telnet session to the router. In privilege/enable mode, invoke the following command to copy this IOS image to the flash. An example is given below. If the file does not get copied to flash, look for the command "ip tftp source-interface" and negate it then try. This is usually placed by default on the UC520. Router#copy tftp flash 3.        Post this, you will be asked for the TFTP server IP address, the source and destination file name. In this case, the TFTP server IP address is your computers’ IP address. 4.        The files should now get copied to the flash. Once it is through, invoke the following command to point the router to this new IOS image: Router#config t Router(config)#boot system flash: uc500-advipservicesk9-mz.124-20.T2 Router(config)#do wr To check if there is any other IOS image reference over here, issue the following command: Router#show run | inc boot If there is an IOS image then negate the command to ensure that this IOS image gets the highest and only preference. The order of the commands is important over here. In the following example, 12.4(20)T2 has a higher preference than 12.4(15)T9 Router#show run | inc boot ! boot start-marker boot system flash:uc500-advipservicesk9-mz.124-20.T2 boot system flash:uc500-advipservicesk9-mz.124-15.T9.bin boot end-marker ! It is recommended that for the first time you keep the old IOS in the flash just in case the UC 520 does not take up the new IOS. In order to check if the IOS has been upgraded, you can invoke the “show version” and the “show telephony-service” command. “show version” should let you know that the IOS is 12.4(20)T2 (something similar) and the “show telephony-service” should give your CME version as 7.0.x (something similar). Once this has been verified, you can delete the old IOS from flash by using the “delete flash:” command. UPGRADING THE PHONE LOADS/FIRMWARE FILES ======================================= After downloading the files, follow these steps to upgrade the phone loads: 1.        Please untar the .tar file (CME-Phone-Loads-7.0.2.tar) using a program like Winrar. Only untar the phone loads for the specific phone types being used in your network. 2.        Start up a TFTP server program (like tftpd32). Make sure that the extracted files are in the root directory of the TFTP server. 3.        Telnet into the router and make sure that you are in exec mode. It should look like this: Router# 4.        Type the command “copy tftp flash:” (without the quotes) 5.        Put in the TFTP ip address when prompted for it. 6.        Put in the full file name (with the extension) when prompted for the source file name. 7.        Hit enter when prompted for the destination file name. The process should start. Please do this for every file that is there in the upgraded firmware. The steps remain the same, only the file name changes. Once done, please follow these steps to ensure that the phones point to the new load: 1.        Go to config mode. In config mode, put in the following commands  depending on the phone type being used. The commands given below are for the 7940 and 7960 phones. ROUTER(config)#tftp-server flash:P00308000500.bin ROUTER(config)#tftp-server flash:P00308000500.loads ROUTER(config)#tftp-server flash:P00308000500.sb2 ROUTER(config)#tftp-server flash:P00308000500.sbn 2.        Now, go under telephony-service and invoke the “load” command as shown below. ROUTER(config)#telephony-service ROUTER(config-telephony)# load 7960-7940 P00308000500                                                         <<<<<I am not sure about the syntax for this. Please use “?” to check it.    However, ensure that you put the file name exactly as it is given over here, depending on the phone load. As a rule of thumb, it is the initial part of the file which has a suffix of .loads. Else, it is the file with a suffix of .bin or .sbn. Now, under telephony-service itself, do a “no create cnf-files” and then a “create cnf-files”. If required, please reset the phone and it should update to the new phone load. UPGRADING THE CUE MODULE ======================== Before starting this process, please make sure that the FTP server has been configured according to the attached document and that it is running. Also, ensure that you can ping the FTP server from the CUE module. If you want to, you can backup and restore the CUE by following the instructions in the link given below. Any FTP server can be used for this purpose. If you are more comfortable with the Microsoft FTP server, then this link is right up your alley: http://www.cisco.com/en/US/products/sw/voicesw/ps5520/products_configuration_example09186a00802fb58d.shtml Here is the link for upgrading the CUE (This also has links for a backup and restore from the CLI): http://www.cisco.com/en/US/docs/voice_ip_comm/unity_exp/rel3_2/installation/guide_/upgrade32.html All the files needed by you for the upgrade are in the SCUE-UC520-3.2.1.zip within the UC 520 .zip file. No additional files need to be downloaded. The link above is a guide for the steps which need to be performed and is more applicable to the NM-CUE, NME-CUE and AIM-CUE. The UC520 uses an ISE-CUE and the procedure is identical, expect for the change in the file names. Also, please note that although this guide is by and large accurate, there may be a few minor changes which need to be made while actually performing these steps although as a whole, this should serve as a comprehensive guide. Personally, I always follow this order: 1. Upgrade the IOS 2. Upgrade the CME GUI files (place the GUI .tar file on the TFTP root and issue the command "archive tar /xtract t ftp:// <IP address of TFTP server>/<full file name> flash:) 3. Upgrade the phone loads 4. Upgrade the CUE ... View more

Here is a custom made guide for using translation rules/profiles. I have explained the concepts of the rules/profiles and then given some common uses of them.   TRANSLATION RULES/PROFILES ========================   Translation rules/profiles can be used to modify the calling/called number.   There are 3 steps involved:   1.       Create the master translation rule and sub rules. 2.       Create the translation profile and associate a master rule to it. 3.       Apply this translation profile to a dial peer or an interface.   Translation rules: These are created in the following format:   Voice translation-rule 1                                 <<<<Master rule 1 Rule 1 /9911/ /911/ Rule 2 /1234/ /7890/   Rule 1 and rule 2 under voice translation-rule 1 are sub-rules. For all intents and purposes, it is the Master rule which needs to be unique i.e. the “tag” of designating it as “master rule 1” means that there should not be any other rule with the same tag of “1”. Master rules can use any tag, as long as they are unique but sub rules will always begin at rule 1 and end at rule 15.   The “/” character that you see is called a delimiter which signals the start and end of the “match pattern” and the “replacement pattern”. Hence, in the examples given above, /9911/ and /1234/ are the match patterns. The replacement patterns are /911/ and /7890/. Hence, sub-rule 1 effectively means that if anyone dials 9911, it should be changed to 911 and then sent out. Rule 2 means that if anyone dials 1234, it should be changed to 7890 and then sent out.   Translation rules use wildcards and regular expressions. These have different meanings, some of which are given below:   ^             ->            This wildcard means “anything beginning with” .               ->            Means a single dialed digit *             ->            Means one or more instances of the previous character /              ->            As explained before, this is a delimiter \              ->            Means strip all the characters before this character. (1234\) ->            Place the characters within brackets in a set. This is a combination of () and \. T              ->            A wildcard which means any number of digits.   Examples:   /^9…/ /1234/     -> Means any number beginning with 9 and followed by 3 digits should be replaced by 1234. Hence if you dial 9555, it will be changed to 1234. /.*/ /2122/          -> Means any dialed number should be changed to 2122. Note that .* is a combination of 2 wildcards and combined they mean “any dialed digit”.   /^022\(…\)/ /2\1/            -> This wildcard requires some explanation. The (…\) in the match pattern means “any 3 dialed digits should be placed in a set, and it should be designated as Set 1”. The ^022\ means any number beginning with 022 should have 022 stripped off from it. Hence, taken together, the match pattern means “any number beginning with 022 and followed by 3 digits should have 022 stripped off from it and the remaining 3 digits taken as Set 1.”   In the replacement pattern, the \1 means place Set 1 over here. The 2 is a prefix to Set 1. Hence the replacement pattern means “keep set 1 as it is but prefix the number 2 before it and send the entire number out”.   Hence, if someone were to dial 022456, the 022 would be removed and 2456 would be sent out since we are prefixing the 2 before 456. Remember that there are multiple ways of getting the same end result. Use what works best for you.   TRANSLATION PROFILES ===================   A translation profile is nothing but a collection of master translation rules. The profile is created in the following way:   Voice translation-profile test Translate called 1 Translate calling 2   This means:   Create a translation profile and call it test. Look at master rule 1 and let the match pattern apply to the called number. Look at master rule 2 and let the match pattern apply to the calling number.   An example:   Voice translation-rule 1 Rule 1 /^9\(…….\)/ /408555\1/ Voice translation-rule 2 Rule 1 /.*/ /9194251234/ Voice translation-profile test Translate called 1 Translate calling 2   All this effectively means:   Under master rule 1, if there is any number that is beginning with a “9” and having 7 digits after it, strip the 9 off and place the 7 digits in Set 1. Prefix the 7 digits in set 1 with 408555 and send it out.   Under master rule 2, any number should be changed to 9194251234.   As is evident from the translation profile, the number being translated can be either the calling or the called number (there are more options, but we won’t get into those right now). Hence, in this scenario, we have let CME know that master rule 1 should be applied on the called number and master rule 2 should be applied on the calling number. Master rule 1 can be used if 7 digit dialing has been replaced by 10 digit dialing, but the users are still in the habit of dialing 7 digits and not 10. Master rule 2 is a common practice for outgoing caller ID.   APPLICATION OF TRANSLATION PROFILES =============================   Translation profiles need to applied for them to take effect. This is perhaps the most important step of all since application of the translation profiles should be correct in order to achieve the desired results. 90% of the time, translation profiles are applied to either a dial peer or an interface. Examples are given below:   Dial-peer voice 100 voip Translation-profile incoming test Dial-peer voice 101 voip Translation-profile outgoing test   Translation profiles can be applied in the incoming or the outgoing direction. This, along with the application of rules on the calling and called number serve as a powerful tool for digit manipulation. Permutations and combinations abound and to fully understand the use of translation rules/profiles one has to put them in use and learn through trial and error.   NOTE: You can create a rule and test it out before assigning it to a profile and applying it to an interface. The CLI command for that is “test voice translation-rule 1 XXXXXXX” where XXXXXXX is the number you want to test out.   A BRIEF EXPLANTION OF DIAL PEERS ============================   Dial peers are the brains of the phone system. A dial peer determines where should calls go and moreover, which dialed numbers to match. Digit manipulation can be done in dial peers through the use of translation rules/profiles. There are 2 types of dial peers which are generally used : Voip and pots. Perhaps these are best explained through examples:   Dial-peer voice 1 pots Destination-pattern 91[2-9]..[2-9]…… Forward-digits 11 Port 0/1/0   Explanation:   A pots dial-peer is created through the command “dial-peer voice XX pots” where XX is a tag assigned to this dial peer. It doesn’t really matter what the tag is as long as it is unique. Pots dial peers are used when connecting to any analog interface. Examples are: FXO and FXS ports, T1 links. T1 might be digital, but for the VoIP phone system, it represent a traditional telephony system and hence is designated as a Pots connection.   The “destination-pattern” is responsible for matching dialed digits. This uses wildcards as well, although some of the wildcards are different from the ones used in translation rules. In the example above, [2-9] means any digit between 2 and 9. Hence, the string 91[2-9]..[2-9]…… represents 11 digit dialing in the United States. The number 9 is used for an outside dial tone, 1 representing a Long Distance number and the remaining 10 digits.   The pots dial peers strip off any explicitly matched digits. Hence, in this example, 9 and 1 are digits which have been matched explicitly but the remaining are wildcards. The phone system will strip off 9 and 1 from the number by default and send the remaining numbers out. We want to strip the initial “9” off since that is just an outside access code, but we don’t want to strip the “1” off since the Service Provider is looking for that 1 to route the call. Hence we put in the “forward-digits 11” command which means forward the last 11 digits. This means that it will send out everything except the 9 since it is forwarding the LAST 11 digits.   Finally, we come to the “port” command which tells the phone system which port should it send the call out through. Calls can be sent out through FXO, FXS and T1 lines and all these have ports designated to them. T1 lines have ports in the format 0/1/0:23 whereas FXO and FXS ports are in the format 0/1/0. This is essential to tell the phone system which port to send the call out through.   There are a number of options under the dial peer configuration, but this is what is used most of the time. Let’s get to voip dial peers:   Dial-peer voice 10 voip Destination-pattern 9[2-9]..[2-9]…… Session target ipv4:<IP address> Codec g711ulaw   Explanation:   A voip dial peer is created in a similar way to a pots dial peer, except for the “voip” keyword at the end of the dial-peer voice XX command. Rules for the destination-pattern remain the same, but a VoIP dial peer DOES NOT strip off any digits before sending the number out. Hence translation rules/profiles need to be applied in order to strip the digits off. A simple rule of thumb – anything that is not POTS will generally be voip.   A voip dial peer does not have a port command associated with it since it does not relate to a port in any way. Instead, voip dial peers use IP addresses to route calls and these are routed using the “session target ipv4:” command. DNS can also be used for this with the command “session target dns:”.   Voip dial peers have an option of hard-coding the codec in use. By default, the CME system will use G729 as the codec, but circumstances might require you to manipulate the codec under the dial peers. A classic case of changing the codec under the dial peers is when sending calls to Unity Express. Unity understands the following parameters:   1.       SIP 2.       A codec of g711ulaw 3.       No VAD (Voice Activity Detection)’   To make a dial peer realize that it needs to use the SIP protocol, we use the command “session protocol sipv2”. To change the codec, we use “codec g711ulaw”. To turn off VAD, we use “no vad”.   SCENARIO:   Let’s discuss modifying the extension that is called i.e. we will configure incoming call routing:   Here are our ephone-dns:   Ephone-dn 1 Number 2000 Ephone-dn 2 Number 2001 Ephone-dn 3 Number 2002   We assume that the Provider has given us 3 DIDs – the numbers are 4805552000, 4805552010 and 4805552020. Here is the way a phone should ring when a call comes in:   4805552000 should ring extension 2000 4805552010 should ring extension 2001 4805552020 should ring extension 2002   Furthermore, we assume that the Provider is sending us the last 4 digits. Hence, the provider will send us 2000, 2010 and 2020.   Notice that for extension 2000, the last four digits match the digits that the Provider sends. Hence, we don’t need to apply translation rules/profiles for this.   For the 2010 and 2020 number, we apply the following translation:   Voice translation-rule 1 Rule 1 /2010/ /2001/ Rule 2 /2020/ /2002/ Voice translation-profile for_2001_2002 Translate called 1 Exit   Post this, we need to figure out which incoming dial-peer is getting hit. In most cases, this can be checked by the “debug voice ccapi inout” command and then running a search for “incoming dial-peer”. This will let us know the dial-peer that is getting hit and we apply the translation on that dial-peer as follows:   Dial-peer voice 100 pots Incoming called-number . Translation-profile incoming for_2001 Port 0/1/0:23   Remember that the translation rules will only come into effect if the correct dial peers are matched and the profile is placed on the same dial peer. Alternatively, the profile can be placed on the voice-port as well, but this will apply to the entire phone system. The command remains the same.   Depending on the number of digits sent by the Telco, we can modify the match pattern (i.e. the 2010 and 2020 portion) and have it ring the same extensions or any other extension that we choose.   (The best way to check how many digits are being sent by the Telco is to enable the “debug isdn q931” for a PRI and check the called number field)   FOR OUTGOING CALLER ID:   Let’s take the case where there are a total of ten DIDs given by the Service Provider (404-555-2000 to 404-555-2009). We want the last five DIDs to display their individual caller IDs but the rest of the DIDs should display the company number of 404-555-2000 while making an outgoing call. Here is the configuration:   Voice translation-rule 100 Rule 1 /\(200[56789]\)/ /404555\1/ Rule 2 /.*/ /4045552000/   Voice translation-profile outgoing_clid Translate calling 100   voice-port 0/1/0:23 Translation-profile outgoing outgoing_clid   Explanation:   In rule 1, [56789] means any ONE of the numbers given within the brackets. Hence, this rule encompasses 2005, 2006, 2007, 2008 and 2009 (i.e. the last 5 DIDs). It is assumed that the internal extensions are in the 2000-2009 range and hence, by default, the caller ID sent will be the extension itself. Therefore, this rule places the entire extension in SET 1 and prefixes 404555 before sending it out.   Rule 2 will be matched if rule 1 is not matched and this effectively means that if any other extension dials out, the caller ID will be 4045552000.   Hence, our requirement of the last 5 DIDs sending their own number and the rest sending the company number is satisfied.   ... View more

Problem: Call waiting does not work on a shared dual line ephone-dn. Detailed Explanation: We have the following setup: ephone-dn 1 dual-line number 1000 ephone 1 mac-address 1111.2222.3333 type 7961 button 1:1 ephone 2 mac-address 1234.1234.1234 type 7961 button 2:1 A call placed to Extension 1000 can be picked up on ephone 1 or ephone 2, placed on hold and then picked up from the other phone. However, if an active call on ephone-dn 1 (say on ephone 1) is placed on hold and another call comes in, ephone 2 is not notified of the call. Only ephone 1 gets a call waiting beep and the caller ID is displayed on ephone 1. In fact, the caller ID may flash for a moment on ephone 2 as well but the call cannot be picked from this ephone. Reason: Dual line ephone dns were created to mirror a call waiting feature along with the functionality to natively transfer/conference calls in CME. With the usage of shared lines, it is assumed that channel 2 of the ephone-dn is going to be used for picking up a call at another extension once it is placed on hold. Hence, this channel is reserved for the possibility of such a thing happening due to which a second call coming in at the same time will not ring on ephone 2. Resolution: The ephone-dn needs to be converted to an octo-line for the desired functionality to be achieved. This is supported in CME 7.0 +. ... View more

Problem: The 521/524 phones display an "SPCP token rejected" message while registering with a UC520. Explanation: The SPCP protocol differs from SCCP based on the "token" which has been added. This registration token ensures that the 521/524 phones register only with the UC520 series routers (and the recent SBCS solutions). Resolution: This is usually resolved by: 1. Ensuring that Auto Registration is enabled under "telephony-service". 2. Removing the "mac-address" entry under the specified ephone. 3. Reset the phone. ... View more

Problem: Test document creation . http://www.cisco.com ... View more