The  aim of this blog post is to give our Voice customers the ability to resolve their issues in a quicker way which can be achieved by providing all the information that a TAC engineer would need which will help him in understanding the issue and will in turn assist in troubleshooting the issue in a minimum period of time. To speed the overall issue resolution time,I would recommend that customers and partners should include all of these information in any new case creation. Customers should provide following information at the beginning of the new case creation which will help the TAC engineer to work on the issue pro-actively. Please include the following information at the time of the case creation.the more you share, the better the case will start.  Clear and detailed case subject line. Clear and detailed problem description including router model, IOS Version etc. Serial number of the device that is having the issue.? ​"Show Tech" of the Gateway,CME,CUBE,CUE whichever is involved in the call flow. Call flow in which we are having the issue.?  For Example :IP Phone--SCCP-----CUCM----H323-----SiteA_CME---SCCP---IP Phone  Troubleshooting steps already performed if any. Is this issue intermittent or reproducible? Is this issue isolated to particular set of devices/users or across the cluster? If this is a new setup or was this Working before.? If it was working before, then was their any recent configur ation change done that might have caused the issue.? If the issue is related to call failure and based on the protocols used in the call flow, collect a set of relevant debugs and attach them to the case notes. When calling please provide the calling and the called number. Collect following debugs for instance. Debug voice ccapi inout Debug VPM signal (If FXO or T1 CAS involved) Debug isdn q931 (If PRI involved) Debug h225 asn1 (If H323 involved) Debug h245 asn1 (If H323 involved) Debug MGCP Packets (If MGCP involved) Debugs ccsip messages (If SIP involved) These are verbose debugs, so please collect them in the following manner: Router#configuration terminal Router(config)#no logging console Router(config)#no logging monitor Router(config)#service timestamps debug datetime msec Router(config)#logging buffered 1000000 debugging Router(config)#service sequence Router(config)#no logging rate-limit Router(config)#exit ​Router#clear log Router#term no mon <Enable debugs, then wait for issue to occur.> Router# term len 0 <Enable session capture to txt file in terminal program.> Router# Undebug all Router# sh log What is the severity of impact this problem is having on your business?   About case subject/headings: Please try to keep the subject heading as crisp and clear as possible while opening the case or while providing it to the CIN agent. Please use more specific titles. Please try not to open a case with vague subject line like "calls not working", "phone not ringing", "call failure" etc. Try to use a more elaborate subject line like "CME 10 - New setup - Inbound call failure", "Outbound calls failing during SRST", "78XX IP phone registration issue with CME" etc. Please do this regardless of opening the case online or through our 800 number so that we already know some details when the case come into our centers. If you follow the above procedure you will realize that the TAC engineer are able to assist you in a better efficient way.This helps the TAC engineer and ultimately you, our partners and end customers. I hope this post helps you in resolving your issues faster.   Regards, Mudit Mathur   ... View more

Introduction   Night service feature allow CME admin to define time periods which are considered as night service hours.  The phones which are participating in night service feature will receive special ringing tone during night service hours. Optionally, you can configure night service override code. This will allow phone user to toggle night service off during night service hours, i.e. the phone will receive traditional ringing tone.   Note: Entering override code at ephone participating in night service will toggle the service for all participating ephones  NOT only the ephone where code is entered.   For Night Serivce configuration on SCCP Phones, please refer to following document.   Admin Guide Night Sevice on SCCP Phone     Prerequisites   In CME version 3.0   Night service was introduced.   In CME Version 3.3   The behavior of the night-service code was changed. Previously, using the night-service code at a phone either enabled or disabled night service for the ephone-dns on that phone. Now, using the night-service code at a phone enables or disables night service for all night-service ephone-dns. i   In CME Version 4.0   The  night-service everyday ,  night-service weekday , and  night-service weekend  commands were introduced.   Components Used   Cisco 2811 Router.  IOS-:c2800nm-adventerprisek9_ivs-mz.151-4.M1.bin SIP  IP Phones SCCP  IP Phones   Configuration Night Service in SIP Phones Register a SIP Phone with CME.   voice register dn  2 number 3999 call-forward b2bua all 3998 ##Forward the call to dummy ephone-dn     Create a dummy ephone-dn   ephone-dn  35  dual-line ## Dummy ephone-dn number 3998 ##Dummy ephone no. call-forward all 1026 call-forward night-service 1025 ## Forward the call to the required dn during night service night-service bell       Create a dummy ephone   ephone  98 ###Dummy ephone device-security-mode none mac-address 1234.1234.1234 ##Provide a dummy mac address button  1:35 ##Associate dummy ephone-dn to this dummy ephone night-service bell   Now if we will make a call to 3999(SIP Phone) when night service is active then it will be redirected to 1025 otherwise the call will be forwarded to 1026 when night service is not active.   Summary  CME does not support Night Service for SIP Phones officially.   The official release of Night Service for SIP Phones is expected in CY 2015 ... View more

Introduction Following Document explain the Workaround on Xmedius FAX Server to Initiate Switchover to resolve the Outbound fax failure issue caused due to multiple m lines in the re-invite from the Provider. Outbound faxes fail if you receive multiple m lines from the provider as the CUBE does not understand multiple m lines. Following document explains the Workaround that can be implemented on Xmedius server to resolve the issue by forcing the Xmedius Server to Initiate Switchover.   Components Used CUBE Xmedius Server ITSP Provider SIP T.38 Fax Protocol   Network Diagram +---------------------+ +------------+ | | T.38 SIP | | SIP | XMedius FAX SERVER +--------------+ CUBE +----------------+ ITSP | | | | +---------------------+ +------------+   Issue  When the provider sends an INVITE to the CUBE during voice to fax switch-over, and the SDP contains 2 m lines, the original behavior was to reject the call with SIP 488. However, this behavior has changed. If the provider sends an SDP with   1. m=audio 2. m=image The call goes through and works fine.   If the provider sends an SDP with   1. m=image 2. m=audio The CUBE doesn't process this correctly, and sends a malformed SDP to the XMedius Server in the INVITE message. Therefore, all calls fail.   Bug associated with this issue is  CSCue70469 Configuration Changes on XMedius Server to force the Xmedius Server to Initiate Switchover. Go to Driver   Right click on Driver and select properties     To modify setting on Xmedius server for the CUBE, go to Peer list and click on properties     Go to T38 parameter and do a check on Send T.38 Reinvite     If you would like to add a new peer in the Xmedius Server, go to peer list and click on Add new   Once the peer is added, go to Dial-plan   Click on Add    Give in the Number pattern as  asterick and select preference    General setting tab for reference on a configured peer               ... View more