Course12:Basic - Operations

From innovaphone wiki
Jump to navigation Jump to search
There are also other versions of this article available: Course11 | Course10 | Course12 (this version)

Explains how to setup an innovaphone PBX system so that it can be maintained smoothly.

Monitoring and Debugging

Sometimes some things do not work or not just as expected. To make sure your installations run smoothly, you need to
  • make sure you notice problems before your end users do
  • gather as much information to understand the nature and cause of any problems
The innovaphone devices provides several integrated tools to help solving these tasks.


If you not yet have done so, load Operational_Basics start configurations to your devices now. This will install a PBX that should look familiar to you from the previous topics.

Events

An Event as shown on the fish-help.png Maintenance/Diagnostics/Events page of any innovaphone devices is a notification of an incidence that should receive the administrators attention.

There are a fish-help.png number of events defined.
Some of them indicate bad user behaviour such as fish-help.png 0x00020003 which indicates an external call transfer while the system configuration does not allow it.
Others may indicate a misconfiguration of the system such as fish-help.png 0x00010002 which brings a failing registration to your attention.
Yet others will likely report hardware problems such as fish-help.png 0x00090001 which notifies a damaged compact flash card.
Also, temporary performance problems in your network could create an event, such as fish-help.png 0x00050002, indicating loss of data while transmitting RTP media data.

In any case, events shown in the event log must be examined carefully and it needs to be determined if they indicate a problem that need to be fixed.
Clicking on the event-code listed in the Code column will open a popup window with some useful context information. For example, for the aforementioned type 0x00010002,

Protocol SIP
AOR <sip:a@x>
Comment Timeout

will be shown.

    Alarms

    An Alarm as shown on the fish-help.png Maintenance/Diagnostics/Alarms page of any innovaphone device is a notification of a persisting problem that needs to be corrected by the administrator. Alarms are always triggered by a corresponding event. Also, when the error condition goes away, the alarm is removed, but the event list will include a new event reporting the clearance of the alarm.

    In a managed installation, there should be no entries in the alarm list at any time!

    The event and alarm list is always kept in local flash memory(not on the FLASH drive, SSD or CF-card). The number of entries to keep can be configured in the fish-help.png Services/Logging tab. You should rather not configure values that deviate from the defaults. The reason for this is that flash memory available to store events is rather limited. If you need to configure larger values, make sure you check flash memory availability in the VARS flash segment (use mod cmd FLASHMAN0 info and look at the VARS line).

    All alarms are sent via SNMP traps. The SNMP trap delivers: code,severity,txt (e.g interface down) and alarm–source (e.g IP0/ETH1). This can be useful if the customers has a SNMP network management tool in use.




    Let us simulate a problem and see how it is reflected in the events and alarm logging. For this,

    The event list will show you a list of recent events. However, if you look at the Maintenance / Diagnostics / Alarms, only the screenshot.png alarms which currently are raised will be shown.


    OK, lets fix the problem
    • plug the ISDN cable in to the BRI1 interface of your IP411LEFT (the other end of this cable should be plugged in to BRI3 of your IP811)
    • the BRI1 LED of your IP411LEFT should light now and ...
    • ... there is a new event saying that screenshot.png the alarm is cleared
    • also, in the Alarms list, the cleared alarm disappeared

    Syslog

    The syslog (found on the fish-help.png Maintenance/Diagnostics/Logging tab) is a first point you should look at if you have a problem. Syslog provides you real-time information about things like:
    • PBX/Gateway Calls - calls and their flow in the PBX or Gateway
    • Gateway Routing - number mapping and call routing in Relay
    • H.323/SIP-Registrations - endpoint/interface registration successes or fails
    • Administration - configuration changes performed on the device
    • and more
    So when you are able to reproduce the problem, you should turn on the relevant (and only those) check marks on the fish-help.png logging tab, repro the problem and examine the syslog.

    (Further Hints) Support will always ask you for a log demonstrating the problem. To reduce the number of turnarounds required for them to understand the problem, make sure your log includes the maximum of relevant information and the minimum of irrelevant information. To do so
    • tick on all logging check marks that relate to information relevant to the problem
    • tick off any logging check mark that creates irrelevant information
    • try to trim down the log so that it fully captures the reproduced problem but nothing else
    • clearly indicate the situation captured in the syslog (not: there is a problem, see syslog. Rather: in the syslog, there is a call coming from TEL1, calling party is xyz, called party is abc. It is sent to extension -xx and terminates with cause code 21. Expected behaviour though is for the call to alert at the phone registered with user efg)
    Capture the sylog as .txt file!
    • do not put it into a MS Word or MS Excel file
    • do not send a screen shot of the syslog screen
    • You can easily save the syslog with copy and paste and send it as a text file



    OK, let's try this and create a problem smile
    • unplug the BRI1 ISDN cable from your IP411LEFT
    • open Maintenance / Diagnostics / Logging
    • tick the Gateway Calls check-mark and click OK
    • click on syslog, the page will show you all log entries in real time
    • now call 0123 from your IP232 (Edward Hyde)
    • you should see a channel not free message on the phone and hear
    • tone

    At this point, a number of log entries will appear in your browser window.

    • copy the syslog in a file

    It should look similar to this one. There is in fact a good deal of useful information in it:

    20160122-074142 PBX0 7 Edward Hyde(14:edward.hyde) setup-> (0123)
    Edward calls 0123

    20160122-074142 PBX0 8 Trunk() peer-> Edward Hyde(14:edward.hyde)
    Call is routed to the Trunk

    20160122-074142 PBX0 8 Trunk(0123) <-setup Edward Hyde(14:edward.hyde)
    20160122-074142 CALL 0 Alloc
    Call is sent to the gateway layer (relay)

    20160122-074142 CALL 0 A:Call -> / RB1::->*::
    It origins from interface RB1 (which is BRI1's registration at Trunk)

    20160122-074142 CALL 0 B:Call 14:edward.hyde@class.innovaphone.com->123 / RB1:14:Trunk->TONE:123:
    Sent to the TONE interface to provide dial-tone if necessary

    20160122-074142 PBX0 8 Trunk(0123) call-proc-> Edward Hyde(14:edward.hyde)
    20160122-074142 PBX0 7 Edward Hyde(14:edward.hyde) <-call-proc (0123)
    20160122-074142 CALL 0 B:Rel 14:edward.hyde@class.innovaphone.com->123 / RB1:14:Trunk->TONE:123: Cause: Resources unavailable, unspecified
    rejected by the TONE interface (as we already have further dialled digits, no dial-tone is necessary)

    20160122-074142 CALL 0 B:Call 070317300914:edward.hyde@class.innovaphone.com->123 / RB1:14:Trunk->BRI1:123:
    so it is routed to BRI1

    20160122-074142 CALL 0 B:Rel 070317300914:edward.hyde@class.innovaphone.com->123 / RB1:14:Trunk->BRI1:123: Cause: Requested circuit/channel not available
    rejected by BRI1, as there is no channel available (cause code)

    20160122-074142 CALL 0 A:Rel 070317300914:edward.hyde@class.innovaphone.com->123 / RB1:14:Trunk->BRI1:123:
    as there are no other lines configured which could be tried, the call is rejected

    20160122-074142 CALL 0 Free
    20160122-074142 PBX0 8 Trunk(0123) rel-> Edward Hyde(14:edward.hyde)
    20160122-074142 PBX0 7 Edward Hyde(14:edward.hyde) <-rel (0123)


    So, log entries are not for the nerd only wink they often carry useful information for the PBX administrator too!

    Tracing encrypted Signalling

    Nowadays, most installations run encrypted signalling and media (SRTP).

    In such installations, you can also get traces for trouble shooting (either with text trace or wireshark) and send them to us for analysis. However, as they are encrypted, we cannot read them! (no, there is no manufacturer back-door)

    While we usually have no intention to listen to your talks (so SRTP is not a problem), we usually do want to analyze you call signalling. As a result, traces from encrypted communication are useless to us. To circumvent this problem, you must tick the All IPv4 TLS Traffic (or All IPv6 TLS Traffic) check-mark in the tracing page when obtaining traces. This will enclose an uncrypted copy of the trace signalling data.

    screenshot.png Encrypted Tracing



    If you want to see the encrypted signalling messages in Wireshark, you can mark a specific packet and apply the www.png Wireshark-Option: Analyze ? Decode As….-> Do not decode on this packet/ports. To find the encrypted message, you should filter for the fish-help.png used port - e.g. for H323/TLS it would be TCP port 1300(or as wireshark filter tcp.port==1300)

    Traces

    A trace (found in the fish-help.png Maintenance/Diagnostics/Tracing) tab is a kind of advanced syslog, that provides significantly more information for debugging purposes. It is usually needed if the information in syslog is not enough.

    As opposed to syslog, traces are permanently saved into an in-core ring buffer. This implies that
    • you can obtain information about events that happened before you obtain the trace (provided you obtain it before they get overridden in the ring buffer)
    • when you reproduce a problem and then obtain the trace, the trace will include information prior to your reproduction of the problem (which is probably not useful)
    • tracing always consumes CPU resources, not only while obtaining a trace
    The trace buffer is cleared whenever it has been retrieved. In order to capture a problem with a trace, best practice is
    • obtain the trace, thereby clearing the trace buffer
    • reproduce the problem
    • obtain the trace again

    Trace is also a simple text based tool and the notes made about obtaining and providing it to support made for the syslog do apply here too.

    Trace Levels


    Like for logging messages, trace messages can be configured. This is done in fish-help.png Maintenance/Diagnostics/Tracing. Tick the check-marks which may be related to the issue you want to debug.

    Some more exotic trace flags are available on a special, hidden page. You can reach it using the special URL http://x.x.x.x/debug.xml.

    (Further Hints) The trace ring buffer is of limited size. So you should make sure that you uncheck all irrelevant check marks. Also, when you are done with trouble shooting, it is a good idea to turn all tracing off.

    Tracing and CPU Load


    Tracing does consume CPU cycles. More tracing consumes more CPU cycles.

    (Further Hints) Extensive tracing can consume a considerable amount of CPU power

    Be sure to turn of any tracing check-marks both in fish-help.png Maintenance/Diagnostics/Tracing and http://x.x.x.x/debug.xml for normal operation!

    Trap Traces


    Writing to the trace ring buffer is disabled when the device traps. Also, the trace ring buffer is not cleared on a re-start. Thus, after a re-start, you can obtain the trace from before the re-start, showing the trap situation.

    When your device traps, you can be sure that support will ask for the trap trace!

    When tracing is disabled due to a previous trap, the pre-trap trace buffer is kept until the next reboot. For this reason, you can obtain it even days later. However, it is important that you copy the trap trace immediately. As soon as you have retrieved the trap trace for the first time, the trace buffer is cleared and normal tracing commences.

    (Further Hints) Keep the trap trace when you first obtain it - otherwise it will be lost!

    Wireshark

    One of the disadvantages of the trace mechanism is that it can be difficult or impossible to capture a reproduced problem in a life installation.

    From V6 SR2, the trace mechanism was greatly enhanced by the fish-help.png PCAP trace based on Wireshark (you can download it from download.png the courses download page). This allows any innovaphone device to work as remote capture driver for Wireshark. This works much like the rpcapd on a windows or linux system.

    When the Enable RPCAP check mark is ticked in the fish-help.png tracing tab, the device will allow wireshark to connect and obtain packet captures. Wireshark will do so if you specify something like rpcap://172.16.15.4/trace as Capture Interface.

    Usually, you will also tick All TCP/UDP Traffic and All IPv4 TLS Traffic in the tracing tab, so that Wireshark will capture all network traffic from and to the device. However, wireshark will also capture all other trace information too. Wireshark's advanced filtering and analysis capabilities allow to capture even huge traces in a life system and drill down the information so that the problem reproed can be isolated from all the irrelevant information. To begin with, try to capture a normal call, then look at Telephony / Voip Calls.

    It is generally important to tick the All IPv4 TLS Traffic check-mark, as nowadays, most of the signalling is (or at least should be) encrypted. Setting this option will include the decrypted version of this traffic within the trace. Encrypted signalling traffic traces are useless when it comes to trouble shooting!

    Recommended Version


    There has been a big wireshark rewrite lately (version 2.x), but at the time of this writing, it is quite buggy still. We therefore recommended to use the last stable version 1.x release (this is the one linked to on our download.png course download page).

    The innovaphone DLL


    innovaphone provides a so-called plug-in for wireshark, the innovaphone-dll. This dll provides support for innovaphone trace messages in a wireshark capture.

    It is part of the V6 Voice Mail, TAPI, SoftwarePhone, Operator download on download.png download.innovaphone.com: ice/6.00/. The dll is part of the tools.zip package. For your convenience, it is also linked as Tools Package on the download.png course download page.

    You must screenshot.png copy the appropriate version (innovaphone_win32.dll or innovaphone_win64.dll, depending on your operating system) to wireshark's plug-in directory (which is something like C:\Program Files\Wireshark\plugins\1.12.9) before you start wireshark.


    Using the rpcap Interface

    Let us play with Wireshark a little!
    You will now see screenshot.png packet dumps passing by all the time. Note the Protocol column. INNOVAPHONE is the pseudo-protocol for innovaphone trace messages. Wireshark understands this protocol type thanks to the innovaphone dll you installed earlier.

    While Wireshark still captures packets, we will simulate an issue (the same as before). So

    You will now see even more captured packet traces in Wireshark and you may get totally confused. Fortunately, Wireshark cannot only display captured packets. It can do some fair amount of analysis.

    So let us dig out the call information from all this packets!

    • select screenshot.png Telephony / VoIP Calls
    • scroll down in the list until you find the call that is towards 0123 (which is what we have called in our test call)
    • You will find a call to 0123 followed by a call to 123 (this is the same call, when it is passed to the gateway level (where the trunk access code is already stripped)
    • select both and screenshot.png click on Flow
    This is a quite useful tool. Wireshark has condensed all those packets to the ones relevant to you. Just cli8ck on the message you are interested in and wireshark will position directly on this packet in his packet list.

    screenshot.png Wireshark Call Flow Analysis



    You don't think you will ever understand all this stuff?
    No problem! Simply make sure the call that you want to debug is actually part of the trace, then screenshot.png save the trace in to a file and submit it to support!

          Storing and Consolidating Syslog and Events

          While alarms, events, syslog and traces are great tools to trouble shoot an installation, administrators often have a big problem: when they are made aware of a problem (either by users or events), they are often unable to reproduce the problem. It is thus clearly desirable, to capture and save syslogs permanently for later perusal.

          Also, in a distributed system such as a VoIP PBX, it is often difficult to determine where the problem actually would be logged. For this reason, it is clearly desirable to consolidate all events, alarms and sylogs to a single place. You can do this by relaying this type of information to a single web server for storage. This will usually be one of your innovaphone devices that has a CF card installed.

          Relaying is configured in the fish-help.png Services/Logging tab. To setup a central storage, you would configure Log Server Type LOCAL on the central device. On all other devices, you would configure Log Server Type HTTP with Method Standard and specify the central device's IP address. On the central device, you would leave Alarm and Event Forward Server empty. On all other devices you would configure the Method Standard, again using the central device's IP address.

          This way, all events, alarms and syslog entries are permanently sent to the central device. All events and alarms will show up in the fish-help.png Maintenance/Diagnostics/Events tab of this device and all syslog information will be stored on the central devices CF card in the /log directory (e.g. \\x.x.x.x\drive\CF0\log) in files LOG0.0 to LOG0.3.

          Remote events and alarms are not stored in the Flash memory of the receiving device (i.e. your central event/alarm server). If the central event server is restarted, all remote events are lost. Alarms are retransmitted by the generating device (2 minutes after reboot and every 30 minutes), updating the alarms list on the central device. If you have to reboot the central event/alarm server, make sure to use the Save option to store the Event-list.


          To practice, configure all your device to send events and alarms to your IP411RIGHT (or - if you are in on-site class - to the IP411RIGHT of your trainer)!

          Using DHCP for basic Configuration

          Some configuration options may be required to set up a working VoIP PBX system. Some of them have to be configured on the devices itself (as opposed to the PBX for example). Taking into account that such a system can easily include hundreds of devices (e.g. phones), configuring such options manually (either by phone menu or web interface) is often not an option.

          innovaphone devices thus feature a number of configuration options that can be fish-help.png deployed via DHCP. This includes, amongst others, things like the user interface language for phones, the local time zone and clock type, the dial tone type and much more. This mechanism allows to set many options without touching the devices. This not only saves a lot of deployment time, but makes later replacements easier.

          Generally, when a devices receives an option via DHCP, it overwrites the configuration found in the device itself. This makes it possible to overwrite default options. The options received by DHCP are shown in each devices Current Lease area in the fish-help.png IP4/ETH/DHCP tab.

          Which DHCP Server to use?

          Most configuration options are sent to the DHCP client as DHCP vendor options. These are vendor specific options that need to be made known to the DHCP server before it can handle them. All relevant details on fish-help.png how to configure 3rd party DHCP servers such as on Windows or Linux can be found in the wiki.

          Much easier however is to use innovaphone's fish-help.png built-in DHCP server! This is a fully fledged DHCP server that can replace the standard server. It already knows about all innovaphone vendor options and is thus easily configured. Also, as opposed to most other DHCP server implementations, it supports the dynamic update of configuration options to clients that have already obtained a lease. This is done by clicking the Renew button in the fish-help.png IP4/ETH/DHCP-Server tab.

          Running a "private" DHCP Server

          In some scenarios, it is not an option to use the innovaphone DHCP server as a replacement for an existing DHCP server. Also, sometimes there is no DHCP server available at all and the local network policy does not allow a DHCP server to offer IP leases in the network.

          In such cases, the innovaphone DHCP server can be used to serve innovaphone clients only. This is enforced by setting the Reserved and same Vendor Clients only check mark on the fish-help.png IP4/ETH/DHCP tab of the device running the DHCP server. As innovaphone clients (e.g. phone) will by default wait up to 8 seconds for an innovaphone DHCP server lease offer (even if they meanwhile receive another one), they usually do not need to be configured specifically for this to work.

          Please note that it is usually not required to set the Server Identifier or Selected Server only field.

          How to find correct option values

          Most innovaphone vendor specific DHCP options are actually used by the phones only. To deploy these option you need to find out how to translate settings you would normally do using the web user interface into DHCP option values.

          To help with this, you can have a look at the fish-help.png Phone/State/DHCP-Options page in the phone. It will show the relevant DHCP option values you would need to supply if the phone would be configured via DHCP.

          To find out the right settings, you would thus
          • turn off DHCP client mode in the phone (to make sure there are no settings received with DHCP)
          • configure the phone according to your needs using the phone menus or the web user interface
          • copy the DHCP option values from fish-help.png Phone/State/DHCP-Options to your DHCP option settings
          To verify your settings, reset your phone to factory defaults and it should behave correctly.

          It is also possible to use fish-help.png IP4/ETH/DHCP-Custom in order to determine the DHCP-server vendor specific information.
          The vendor class identifier and the vendor options can be entered as character strings or in hex representation.

          Creating Announcements

          Announcement files are used in various places for the innovaphone PBX. Most notable, they are used in PBX Waiting Queue objects and as Music on Hold for the PBX.

          There have been a number of methods to create audio files for announcements, including /DRIVE/CFX or the softcod.exe utility. However, the only recommended method now is the audio converter link_intern.png www.innovaphone.com: en/support/convert.html (you have already learned how to use it in the Lesson on Flash Memory Drives).

          Creating good Source Audio Files for Announcements


          For best results, you have to create high quality source (.wav) audio files before conversion.

          For quick (and dirty) creation of voice-only announcements, you can simply use the phone and here is how fish-help.png Record an announcement by phone.

          If you need to produce high-quality announcements, here is your source of advice: fish-help.png Creating fine announcements and music on hold.

          However, there are of course also commercial suppliers of high-quality custom announcements. See fish-help.png 3rdParty Professional Announcements for examples.