Call Logs Analyzing

download Call Logs Analyzing

of 7

description

call logs

Transcript of Call Logs Analyzing

  • 5/24/2018 Call Logs Analyzing

    1/7

    SDI and SDL Trace:==================SDI Trace Logs CCM trace files provide information about call processing eventsand all messages exchanged between Skinny,MGCP, and H.323 endpoints.

    SDL traces describe the events occurring in the CallManager software at a code level.

    Trace Configuration:--------------------

    You configure a CCM trace in Cisco CallManager Serviceability (Trace > Configuration).

    Detailed:Provides detailed debug information and highly repetitive messages thatare primarily used for debugging, including KeepAlives and responses

    Arbitrary:If you are not troubleshooting problems related to missed KeepAlives,this level is good for day-to-day troubleshooting.

    SignificantProvides traces for media layer events.

    ErrorProvides traces generated in abnormal conditions, such as coding errors.

    SpecialProvides traces for all informational, non-repetitive messages such as process startup messages, registration messages, and so on.

    StationInit : Indicates message from the phone.(StationInit means that an inbound Transmission Control Protocol (TCP) message from a Skinny station reached CallManager)

    StationD:It means the call manager sending the message to the Phone.

    E.g call log

    StationInit: 1a3e8b54 OffHook

    TCP Handle:===========

    Here 1a3e8b54 -->It is called a TCP handle and it represents a unique value thatidentifies a specific IP phone registered to this CallManager server.

    With the TCP handle, you can follow every message to and from that IP phone andsee the full series of messages exchanged between CallManager and thephone

    one more e.g:-------------

    If you want to find the TCP handle for a particular IP phone do the following:------------------------------------------------------------------------------

    Get the MAC address of the phone and search it in the logs and you will find thecorresponding TCP Handle.

    StationInit - InboundStim - KeepAliveMessage Send KeepAlive to Device Controller. DeviceName=SEP003094C2D11F,TCPHandle=1a3e8b54, IPAddr=10.80.1.147, Port=51763,

  • 5/24/2018 Call Logs Analyzing

    2/7

    Device Controller=[2,89,2992]

    StationD: It means the call manager sending the message to the Phone.

    StartTone --> message with tone=33(InsideDialTone) tells the IP phone to start playing dial tone

    callReference ID--> A callReference ID is created for each participant in a calland you can use this ID to track a particular call through a CCM trace

    A new callReference ID is created for each participant in a call and when some f

    eatures are invoked, such as transfer and conference.

    Each leg of a call gets its own callReference ID assigned, so in a call betweentwo IP phones, each phone gets assigned a separate callReferenceID

    KeypadButton kpButton=3--->Indicates the number dialed or pressed in the phone.

    Note:the digit * is shown in a trace as the letter e and a # is shown as f

    Calling search space in the Logs:---------------------------------

    Here fqcn

    Digit analysis:match(fqcn=3000, cn=3000, pss=IPMA:PA:Line1, dd=3001)

    Digit Analysis:===============

    Whenever digit analysis makes a match for a call, it displays the digit analysisresults in the CCM trace. For example

    Digit analysis: analysis results| PretransformCallingPartyNumber=3000

    | CallingPartyNumber=3000| DialingPartition=Line1| DialingPattern=3001| DialingRoutePatternRegularExpression=(3001)| DialingWhere=| PatternType=Enterprise| PotentialMatches=NoPotentialMatchesExist| DialingSdlProcessId=(2,34,3500)| PretransformDigitString=3001| PretransformTagsList=SUBSCRIBER| PretransformPositionalMatchList=3001| CollectedDigits=3001| UnconsumedDigits=

    | TagsList=SUBSCRIBER| PositionalMatchList=3001| VoiceMailbox=| VoiceMailCallingSearchSpace=IPMA:PA:Line1| VoiceMailPilotNumber=5678| DisplayName=James| RouteBlockFlag=RouteThisPattern| InterceptPartition=| InterceptPattern=| InterceptWhere=

  • 5/24/2018 Call Logs Analyzing

    3/7

    | InterceptSdlProcessId=(0,0,0)| InterceptSsType=0| InterceptSsKey=0| WithTags=| WithValues=| CgpnPresentation=NotSelected| CallManagerDeviceType=UserDevice

    Audio Logs:===========

    RTP flow using SCCP:--------------------

    Callmanager sends the devices the OpenReceive Channel.

    Then device responds with openReceive ACk giving the port numbers.

    Once it receives the ACK it sends the start media transmission to the other device.

    Skinny uses Real-Time Transport Protocol (RTP) streams over User Datagram Protocol (UDP) packets to send and receive Voice over IP (VoIP) samples.

    A logical channel is a unidirectional RTP stream, so to have a two-way conversation, you must have two logical channels opened.

    CallManager asks the IP phone to open a connection to receive RTP streams. CallManager asks the IP phone for specific parameters for this connection,including the codec and packet size.

    OpenLogicalChannel messages from CallManager to each IP phone requesting that they open a connection to receive RTP packets using G.711.

    e.g :

    StationD: 1a3e8b54 OpenReceiveChannel conferenceID=0passThruPartyID=17 millisecondPacketSize=20compressionType=4(Media_Payload_G711Ulaw64k)qualifierIn=?. myIP: 3eee1cac (172.28.238.62)

    Upon receiving an OpenReceiveChannel message, the IP phone selects the UDP portnumber it wants to use to receive RTP packets and reports this information backtoCallManager in an OpenReceiveChannelAck message.

    e.g : StationInit: 1a3e8b54 OpenReceiveChannelAckStatus=0, IpAddr=0x3eee1cac, Port=20096, PartyID=17.

    Once CallManager receives the port number in the OpenReceiveChannelAck message from Phone A, it sendsa StartMediaTransmission message to Phone B giving it the IP address and port number of Phone A along with information about which voice codec to use.

    StationD: 1a3e8af0 StartMediaTransmissionconferenceID=0 passThruPartyID=33remoteIpAddress=3eee1cac(172.28.238.62)remotePortNumber=20096 milliSecondPacketSize=20

  • 5/24/2018 Call Logs Analyzing

    4/7

    compressType=4(Media_Payload_G711Ulaw64k)qualifierOut=?. myIP: 2fee1cac (172.28.238.

    MGCP PRI Troubleshooting:-------------------------

    Whenever an H.323 or Q.931 call is made, you will see a section of trace similarto thefollowing outgoing ISDN setup message.

    Out Message -- PriSetupMsg -- Protocol= PriNi2Protocol.Ie - Ni2BearerCapabilityIe IEData= 04 03 80 90 A2Ie - Q931ChannelIdIe IEData= 18 03 A9 83 97Ie - Q931CallingPartyIe IEData= 6C 06 00 80 33 30 30 30Ie - Q931CalledPartyIe IEData= 70 05 80 33 30 30 31MMan_Id= 0. (iep= 0 dsl= 0 sapi= 0 ces= 0 IpAddr=a4e81cac IpPort=2427)IsdnMsgData2= 08 02 00 09 05 04 03 80 90 A2 18 03 A9 83 97 6C 06 00 80 33 30 3030 70 05 80 33 30 30 31

    When viewing an ISDN trace, look at the IsdnMsgData2 line to find the call reference ID.

    IsdnMsgData or IsdnMsgData1 instead of IsDNMsgData2.

    for e.g in the above log IsdnMsgData2= 08 02 00 09 05 04 03 80 90 A2 18 03 A9 8397 6C 06 00 80 33 30 30

    here Ignore the first two numbers (usually 08). The next two numbers are the call reference length (02), and the next four are the call reference value (00 09)

    lines in the middle that begin with Ie are ISDN Q.931 information elements.

    Q.931 Disconnect Message:=========================

    The following is a sample of a CCM trace showing a Q.931 DISCONNECT message:Out Message -- PriDisconnectMsg -- Protocol= Pri250ProtocolIe - Q931CauseIe IEData= 08 02 80 81MMan_Id= 0. (iep= 0 dsl= 0 sapi= 0 ces= 0 IpAddr=a86a12ac IpPort=2427)IsdnMsgData2= 08 01 AA 45 08 02 80 81.

    You can see that the hex representation of the data in the Q931CauseIe is 08 0280 81

    Skinny Client Registration:===========================

    The question, then, is what do you do when you encounter an IP phone that doesnt

    register properly with CallManager?Step 1

    Check for inline power issues.

    Step 2Check IP addressing and DHCP.

    Step 3Check for IP network connectivity.

  • 5/24/2018 Call Logs Analyzing

    5/7

    Step 4Check for Trivial File Transfer Protocol (TFTP) problems.

    Step 5Check for CallManager issues

    Troubleshooting inline power:=============================

    Catalyst 6000 series, 4006, 4224, 4500 series, and 3524XL-PWR switches all havean Automode that indicates that the phone discovery mechanism is in operation.

    The Catalyst 6000 series, 4500 series and 4006 have an Off mode. The Catalyst 3524XL-PWR and 4224 havea Never mode that is equivalent to the Off mode.

    If you are using a Catalyst switch, one important thing to check is whether or not the switch actually hasenough power available to provide power to an IP Phone

    show environment power ---->Show Current Power Status on a Catalyst 6509

    Note: If the card status shows partial-deny or deny this indicates there is notenough power to either power up the module or to provide power to one or more ports on the module.

    To see exactly how much power a particular IP Phone is using, issue the command--------------------------------------------------------------------------------show port inlinepower or show port inlinepower mod/port for a specific port

    If you run out of power on the switch, you should see a message logged to the console, as--------------------------------------------------------------------------------

    ----------well as your Syslog server if you have one configured, that states

    %SYS-3-PORT_NOPOWERAVAIL:Device on port 5/12 will remain unpowered

    a defective IP Phone causes this type of behavior, although cabling problems cancause problems like this as wellespecially cable runs that exceed the Ethernet maximum distance of 100 meters.

    If the switch provides power to a port but does not detect the link within fiveseconds, youwill see this message:--------------------------------------------------------------------------------

    -----------------------------------

    %SYS-3-PORT_DEVICENOLINK:Device on port 5/26 powered but no link up

    STEPS NEED TO BE FOLLOWED WHEN INLINE POWER ISSUE:--------------------------------------------------

    In review, it is important to follow this basic procedure when troubleshooting inline power issues:

  • 5/24/2018 Call Logs Analyzing

    6/7

    Step 1If you suspect that the IP Phone doesnt work, plug it into a known good port.

    Step 2If you suspect that the port or cable might be bad, plug in a known good IP Phone.

    Step 3With this information, investigate any physical layer possibilities, such as cables not being plugged in, damaged cables, or cables not patched

    through correctly to the switch port.

    Step 4

    Check configuration and power issues on the switch itself. Make sure that the switch is in Auto mode and that the port in question hasnt been setto Off. Also check that sufficient power is available for the IP Phone. Once theIP Phone is powered up, ensure the IP addressing information on the IP Phone iscorrect.

    2)Troubleshooting Network Connectivity and Skinny Registration:================================================================

    1) Verify the VLAN in the phone.

    2)Once the IP Phone has determined the proper VLAN ID for voice packets, it mustobtain the IP addressing information.This can be accomplished by either statically configuring all the IP addressingparameters or via DHCP.

    UNABLE TO GET THE IP ADDRESS FOR THE PHONE:--------------------------------------------

    If your IP phone is not able to obtain an IP address via DHCP, check for any network

    connectivity problems between the IP phone and the DHCP server.

    If the DHCP server is not on the same subnet as the IP phone voice VLAN, ensurethat you have properlyconfigured an IP helper address on the local router (using the command ip helper-address x.x.x.x on the LAN interface)

    If your IP Phone is still unable to obtain an IP address via DHCP, the next thing to try is toreset the phone to its factory default configuration and then hard-code (manually enter) all the necessary IP parameters

    TFTP TROUBLESHOOTING:=====================

    Note:

    The first thing the IP Phone does after it has its IP addressing information isrequest a file from the TFTP server called OS79XX.txt.

    The file OS79XX.txt conatins the name of the phone firmware to be loaded for e.g

  • 5/24/2018 Call Logs Analyzing

    7/7

    P0S30100 (without the extension .bin)

    P0S30100.binThis is the SIP image( Here P denotes the phone, 0 means that it is acombined image (application and DSP), S for SIP 0 for SCCP M for MGCP, 3-ARM Processor)

    The above file is used to determine whether to boot up as a Session Initiation Protocol (SIP), Media Gateway Control Protocol (MGCP), or Skinny protocol phone