This article describes the IP73 WLAN/WiFi wireless IP phone, differences to the deprecated IP62 Wireless IP phone and a list of compatible WLAN infrastructures.

==Applies To==
This information applies to:
*innovaphone IP73 (50-00073-001)

==Requirements==

To perform configuration changes on the IP73 device a desktop programming kit (IP62/IP64/IP65/IP73) (Art.No. 50-00060-021 / Prod.ID DP1-UAAA/1A1) is required. The programming kit enables to connect the IP73 handset to a PC in order the configuration changes can be done using WinPDM software.

==Feature Comparison==
This chapter describes the differences in the feature sets between old and new WiFi handsets.

{|border="2" cellspacing="4" cellpadding="3" rules="all" style="margin:1em 1em 1em 0; border:solid 1px #AAAAAA; border-collapse:collapse;empty-cells:show;"
|+ Handset Features Matrix
! Feature !! IP62 !! IP73 !! Description
|-
| Signaling Protocols || H.323/SIP || SIP only ||
|-
| Codecs || G.711, G.722, G.729 A || Opus Wideband, G.711, G.722, G.729 A/B/AB ||
|-
| Talk Time/ Standby Time || 15 h / 100 h || 10 h / 100 h || with U-APSD
|-
| WiFi Standards || 802.11 a/b/g/n || 802.11 a/b/g/n/ac, 802.11r, 802.11k || MCS 0-7 only, Fast BSS Transition (FT or 802.11r)
|-
| SSL Certificates || customer managed || preinstalled by innovaphone/customer managed ||
|-
| call diversion || ok || only with DTMF ||

|-

| Headset Connector || 2,5 mm || 3,5 mm ||

|}

Although the IP73 does not have access to a central LDAP phone book, the solution described in [[Reference9:PBX/Objects/Directory_Search]] can be used.

==WLAN Infrastructure Compatibility==

'''IMPORTANT''': Ask [mailto:presales_AT_innovaphone_D0T_com innovaphone Presales Team] for possible interop configuration recommendations and pitfalls before you order the WiFi equipment and start with the roll-out.

Note that availability and combinations of controllers and access points may be subject to change by the manufacturer and are not in the responsability of innovaphone. Errors and omissions excepted.

innovaphone does not support WLAN infrastructures not listed in this document.

{|border="2" cellspacing="4" cellpadding="3" rules="all" style="margin:1em 1em 1em 0; border:solid 1px #AAAAAA; border-collapse:collapse;empty-cells:show;"
|+ Certified WLAN Platforms
! Vendor !! AP Model(s) !! Controller Model(s) !! latest tested SW Version
|-
| Aruba ||AP 207, 214, 215, 224, 225, 275||7000/7200/9000/MX-VA-xxx||8.6.0.5
|-
| Aruba ||AP 304, 305, 314, 315, 324, 325, 334, 335, 344, 345, 504, 505, 514, 515, 534, 554, 555||7000/7200/9000/MX-VA-xxx|| 8.7.1.1
|-
| Cisco||AP 1702, 2702, 3702, 1832, 1852, 2802, 3802, 4800, 9115, 9117, 9120, 9130||3504, 5520, 8540, vWLC, Mobility Express Solution||8.10.105
|-
| Cisco||AP 1832, 1852, 2802, 3802, 4800, 9105, 9115, 9117, 9120, 9130||3504, 5520, 8540, vWLC, Mobility Express Solution||8.10.162
|-
| Cisco||AP 1702, 2702, 3702||Catalyst 9800||17.3.3
|-
| Cisco||AP 1832, 1852, 2802, 3802, 4800, 9115, 9117, 9120, 9130, 9136||Catalyst 9800||17.7.1
|-
| Cisco Meraki||MR20/MR30H/MR33/MR42/MR42E/MR52/MR53/MR53E/MR70/MR74/MR84 (802.11ac wave 2);MR36/MR44/MR46/MR46E/MR76/MR86 (802.11ax)||-||MR 27.7.1
|-
| Extreme Networks (Enterasys/IdentiFi) ||AP 3801, 3805, 3825, 3865, 3935|| Extreme Wireless C25, C35, C2110, C5110, C5210, v2110||10.51.10
|-
| Extreme Networks (Enterasys/IdentiFi) ||AP 122, 130, 230, 250, 550, 650|| Extreme Cloud ||AP 10.0r8, Cloud 20.1.1.3
|-
| Extreme Networks (Enterasys/IdentiFi) ||AP 310i/e, 410i/e, 505i/e, 510i/e, 360i/e, 460i/e, 560|| XCC Controllers E1120, E2120, E3120, VE6120/VE6125, VE6120H||05.16.01.0025
|-
| Extreme Networks (Enterasys/IdentiFi) || AP305c/cx, 410c, 460c, 510c/cx, 650|| Extreme Cloud C25, C35, C2110, C5110, C5210, v2110||AP 10.2.4.0, Cloud 20.1.1.3
|-
| Extreme Networks (Enterasys/IdentiFi) || AP310i/e, 410i/e, 460i/e, 510i/e, 650i|| Extreme WING NX 5500, 75xx, 9500, 9510, 9600, 9610, VX9000||7.5.2.0
|-
| Fortinet||AP1010/1014/1020/822/832, APU221EV/U223EV/U321EV/U323EV/U421EV/U423EV||MC1550/3x00/4x00/5000/6000 FortiWLC-50D ,200D, 500D, 1000D, 3000D FWC- VM-50, 200, 500, 1000, 3000||8.5-2-5
|-
| Ruckus||SmartZone ZF R300, R310, T300, T310, R500, R510, H510, R600, R610, R710, R720||SmartZone platform, vSZ-(H,E,D), SZ100/300||5.2.0.0.699

|}

as of February 2022.

=== DAS Compatibility ===
[http://en.wikipedia.org/wiki/Distributed_antenna_system Distributed Antenna Systems (DAS)] provide a cost-effective solution for extending radio coverage inside large facilities. Simply put, a DAS can be seen as a long cable starting at a base station or access point to which many antennas are connected. While the architecture can be utilized to mitigate certain coverage issues, the innovaphone IP73 was not designed to accommodate for such RF environments. Furthermore it is difficult to ascertain and ensure WLAN reliability in regard to interference, capacity, roaming, location-based services, and some important [http://en.wikipedia.org/wiki/IEEE_802.11n 802.11n] features, such as [http://en.wikipedia.org/wiki/Multiple-input_multiple-output MIMO]. As a consequence thereof, innovaphone will not endorse nor provide RF support for WiFi deployments over any Distributed Antenna System.

=== WPA3 Compatibility ===
The IP73 already supports the configuration option for ''WPA3''. However, this should not yet be actively used. 
''WPA3'' is currently only recommended for demo purposes. Support for ''WPA3'' is implemented, but no successful interoperability tests have been performed. WPA3 is not recommended being used except for demo purposes.

==Configuration==
IP73 configuration is done via WinPDM-application available at [https://store.innovaphone.com the Software section of the innovaphone App Store]. Use of desktop programming kit (IP62/IP64/IP65) (50-00060-021) is required.
===PBX Registration===
====Authentication via client certificate====
The recommended way to register an IP73 handset at the innovaphone PBX is SIP over TLS with authentication by a client certificate. The IP73 handset is delivered with a preinstalled device certificate already trusted by an innovaphone PBX.

Prerequisites on the PBX for such type of authentication are:

*The issuer of the IP73 client certificate is on the Trust List of the PBX gateway
*The CN of the client certificate used by IP73 equals the MAC address of the IP73 itself (alternatively other CN and registration identity can be used)
*User Object contains a Device with a Hardware Id matching the MAC address of the IP73

On the IP73 following settings must be configured:
*VoIP->SIP
**SIP TLS client certificate: <select certificate with MAC address as CN> or <Automatic if preinstalled certificate is used>
**SIP Transport: TLS
**Primary SIP proxy: <IP-address of the PBX>
**SIP proxy ID: <PBX system name>
**SIP proxy password: <no password is required>
**Registration and Authentication identity: MAC address

====Authentication via username/hardware id and password====
*VoIP->General->Endpoint ID: username or hardware id on User Object
*VoIP->SIP
**SIP Transport: TCP or UDP
**SIP proxy password: <password on the User Object or PBX System password, depending on Users Device configuration>
**Registration and Authentication identity: Endpoint ID

=== ICE/TURN ===
ICE is enabled by default. It is required to provide STUN and TURN server configuration under VoIP->General to secure correct negotiation of media channels.

=== Factory Reset ===
You can use the local ''Admin menu'' on the Phone or the WinPDM Software (Rightclick on the device) to make a Factory Reset.

==Troubleshooting==
Log Options can be configured in the WinPDM software, under Device->Log.

===Remote PCAP Tracing===
You can activate the remote PCAP interface and Trace flags directly in the phone configuration (Admin Menu :: Logging :: Mode) or via WinPDM under Device->Log->PCAP capturing: RPCAP.

Only IP traces are available via RPCAP, no innovaphone or device internal traces are logged.

===PCAP to file via USB Tracing===
It is possible to store PCAP trace file in the ''pcap'' folder on the handset by setting in the phone configuration (Admin Menu :: Logging :: Mode) or via WinPDM under Device->Log->PCAP capturing the option "PCAP to file".

To access the file set Device -> General -> USB behavior to "Ask" and select "File transfer", when connect the handset to the WinPDM. Navigate to the folder ''pcap'' on the ''Handset diagnostics'' drive.

===Trace Options===
Following additional trace options are available:

*WLAN Trace
*Configuration Trace
*GUI Trace
*GLI Trace
*Unite Trace
*VoIP Trace
*System Trace
*Protector Trace
*SaS Trace
*Bluetooth Trace

The resulting traces are available via USB file transfer and are encrypted. The encrypted log files can be encrypted by support only.

===Logging via Syslog, SFTP or logfile===

The handset can be configured to send Syslog messages to a Syslog server, an SFTP server or to a local logfile located in the folder ''tracelog''.

The configuration is available via WinPDM Device -> Log -> Syslog or SFTP.

===Handset Error Messages===

====No network====
The ''No network'' message indicates missing WLAN connection. It can be caused by wrong settings for SSID, Security, reg. domain and WLAN channels or lack of coverage.

====No access====
The ''No access'' message is caused by missing IP connectivity to the PBX or wrong configuration for authentication at the PBX.

== Shortcuts ==

There are additional hidden tools for information and analysing are available.

;Handset Device Information
:''*#34#'' in the main display

;RSSI Indicator
:''*#76#'' in the main display. Type again to exit.
: Here you find the following information in the display:
:* Line 1: SSID
:* Line 2: Current AP
:* Line 3: Current AP MAC
:* Line 4: Previous AP
:* Line 5: Previous AP MAC

;Site Survey Tool
:''*#77#'' in the main display.

;Admin Menu
: Go to the ''Settings menu'' and type in ''40022''

==Known Problems==

==Related Articles==
*[[IP73 Technical Data EN]]
*[[Reference:IP62 WLAN WiFi Wireless IP-Phone]]

Reference13r2:Concept Hardware Rental

2022-03-02T13:19:29Z

Gbe:

{{FIXME|reason=This article is still work in progress}}


==Applies To==
This information's applies to
* innovaphone gateways/phones from version 13r2 sr9
* App Devices version 13r2 sr9

==Requirements==
* a hardware rental contract
* special rental devices (can be ordered after conclusion of a rental contract inside the Portal my.innovaphone)
* innovaphone gateway/phone version 13r2 sr9 or higher
* App Devices with 13r2 sr9 and access to the Devices App

==Hardware rental program and payment method==
innovaphone uses iSC (innovaphone Service Credits) as a payment method for the flexible hardware rental program. The iSC are bound on a customer specific account to a specific domain. As soon as a hardware is activated for renting, the account balance starts decreasing.
* iSC can be ordered via the innovaphone sales channel and are managed through the myApps Platform. The delivery is realized in form of an activation key. Then iSC are loaded through the Devices App to a specific customer account to a specifc domain. The customer account is logically connected to [[Reference:My Innovaphone | My Innovaphone]]. Hardware rental however is exclusively managed via the Devices App.
* iSC are not just for hardware rental. An existing iSC balance can therefore be used flexibly by the same customer in the same domain to rent other licenses or services.
* The rental program is operational as long as a positive iSC balance is available on the customer account. The hardware rental functionality stops immediately when the iSC balance becomes zero. A negative iSC balance is not accepted.

===Hardware licenses===
* Hardware licenses are part of the hardware rental and must not be licensed separately.

===Technical aspects===
The rental duration is calculated on each change of hardware and license in the domain. Consequently, after each change in the configuration new licenses and hardware with a new duration are transferred to the gateways and also stored in the Devices App itself.
If the rental expires, the gateway reboots and the hardware is not operational anymore.
The licenses are also transferred after each reconnect of a gateway to the Devices App.
[[Remarks:]]
* The Devices App must be online and have access to my-app.innovaphone.com!

===Hardware rental device orders===
You can order hardware rental devices inside the Portal my.innovaphone after you have concluded a hardware rental contract. 
You must start the hardware rental within '''10 days''' after shipment at innovaphone! If you start it later, you must still pay the difference in iSCs.

====Returns/Defects====
If you want to return a device to innovaphone or if a device is defect, you must cancel the single hardware rental contract for this device inside your Devices App. 
The device must be received max '''10 days''' later by innovaphone. Otherwise, innovaphone is eligible to invoice the payable iSC.
If you want a replacement device, simply order a new device of the same type.

====Notifications====
You will receive email notifications if a device is not actively rented. Warning email addresses can be handed during the order process and the contract owner and orderer will receive these mails in addition too. 
Notifications are starting three working days before the period is over.

==Configuration==
 
* run and finish the normal install process on the special rental hardware.
 
* open the devices app[[image:devices-app.png|thumb|upright=5.0|right|devices]]
 
 
 
 
 
 
* select the right domain[[image:devices-domain.png|thumb|upright=5.0|right|devices-domain]]
 
 
 
 
 
 
 
 
 
 
* click on Customer Account[[image:kundenkonto.png|thumb|upright=5.0|right|Customer Account]]
 
 
 
 
 
 
 
 
* login with your my.innovaphone account and check that you see your hardware rental contract
* add phones and gateways by the standard provisioning process
 
 
 
* click on rental [[image:rental.png|thumb|upright=5.0|right|rental]]
** here you have the overview to your licenses, devices and the status of your iSCs.
 
 
 
 
 
 
 
 
* Tab Software [[image:miete-software.PNG|thumb|upright=5.0|right|Tab Software]]
** Add the licences you want to use [[Howto:Software_Rental]]
 
 
 
 
 
 
 
 
 
 
 
* Tab Hardware [[image:miete-hw.PNG|thumb|upright=5.0|right|Tab Hardware]]
** add and activate the listed devices to your hardware rental
** if you deactivate hardware rental here, you still need to pay iSCs for the time until you activate the rental again! But you can use this method to move a device between different Devices instances.
** provisioned devices are automatically added to hardware rental, you just need to manually add hardware which you connect manually to your Devices App
 
 
 
 
 
 
 
 
 
 
 
* Tab Rental contracts/Defects [[image:miete-contract.PNG|thumb|upright=5.0|right|Tab Rental contracts/Defects]]
** overview of your devices
** possibility to cancel a single hardware rental contract for a specific device
*** you can tell us here if you return a device because of a defect
*** if you need a new device as a replacement, simply order a new hardware rental device
*** you must return the cancelled device within 10 days to innovaphone
 
 
 
 
 
 
 
 
 
* Button History [[image:history.PNG|thumb|upright=5.0|right|Tab Contract]]
** you can download a excel sheet with history information
 
 
 
 
 
 
 

=Troubleshooting=


= Related Articles =
* [[Reference13r1:Concept Software Rental | Concept Software Rental]]
* [[Howto:Software_Rental]]
* [[Reference13r2:Concept App Service Devices | Concept App Service Devices]]
* [[Reference:My Innovaphone | My Innovaphone]]

[[Category:Concept|{{PAGENAME}}]]

File:Miete-hw.PNG

2022-03-02T13:17:48Z

Gbe:

Reference13r2:Concept Hardware Rental

2022-03-01T15:32:35Z

File:Kundenkonto.png

2022-03-01T12:03:05Z

Gbe:

File:Devices-domain.png

2022-03-01T12:02:50Z

Gbe:

2022-02-24T15:48:12Z

Gbe: New page: {{FIXME|reason=This article is still work in progress}}  ==Applies To== This information's applies to * innovaphone PBX from version 13r2 sr9 * App Platform version 13...

{{FIXME|reason=This article is still work in progress}}


==Applies To==
This information's applies to
* innovaphone PBX from version 13r2 sr9
* App Platform version 13r2 sr9

=Requirements=
* innovaphone PBX version 13r2 sr9 or higher
* a running App Platform and access to the Devices App

=Troubleshooting=


= Related Articles =

2019-10-21T10:42:17Z

Gbe:

==Applies To==
This information applies to

* all innovaphone devices



==More Information==

This article advises how to perform a quick ''health check'' on an innovaphone device. This may serve as guidance for routine checking of a PBX systems state as well as to start debugging when a device malfunctions.

===Overview===

To perform a device health check, the following steps are recommended

* Inspect the device alarm table
* Inspect the device event list
* Inspect performance counters
* Check volatile memory (RAM) usage
* Check CPU usage
* Check persistent memory (Flash) usage
* Check CF card usage
* Examine system log
* Check for efficient PBX configuration

Depending on the device type, some of the steps may or may not apply.

=== The Alarm Table ===
The systems [[Reference8:Administration/Diagnostics/Alarms|alarm table]] available under ''Administration/Diagnostics/Alarms'' should always be empty. If there are entries in it, examine them carefully and fix the problem so that the alarms disappears. The reason for this is pretty simple: if the alarm table is filled with entries that you already have checked but considered ''acceptable'', then it will not take long until a severe problem will hide itself in between the harmless entries. So make it a habit that your alarm table is empty always.

The alarms have a ''details page'' available in the ''Code'' columns. These sometimes show useful further information. Also, many of the error codes have a dedicated wiki help page, available through the details page ''Help'' button.

=== The Event List ===
The systems [[Reference8:Administration/Diagnostics/Events|events list]] available under ''Administration/Diagnostics/Events'' may contain a fair amount of entry types. As opposed to the alarm table, where the entry is removed when the problem is fixed, entries in the event list are not removed (except the list exceeds its allowable size in which case the oldest entries will be removed). As a result, your event list will likely rarely be empty. You need to work through the list and analyse each entry to determine if or if not it is still relevant. To avoid analysing entries again and again, you can clear the whole list when finished, or (from V8 on), you can declare it as ''already taken care of'' using the ''Mark'' button in the detail page (which will render the entries ''Code'' column in green instead of red).

As for alarms, it is important to take care of problems which frequently create entries in the event list, as otherwise you will most likely overlook severe problems in a crowded event list.

=== The Calls Screen ===
One important issue is consistently good voice quality. In a life system, you can do a quick check on voice quality simply by looking at the PBX's [[Reference:Administration/PBX/Calls | Administration/PBX/Calls ]] screen.

<pre>
Number Name Protocol Media Dir Number Name Protocol Media Uptime State
13 abc H323EFC:TRANSIT G711A (2,0,0) x >> 001730 H323EFC:TRANSIT G711A (2,0,0) x 0d 0h 29m 31s Connected SRTP
0017200 H323EFC:TRANSIT G711A (46,5,3) >> 37 cba H323EFC:TRANSIT G711A (39,8,29) 0d 0h 7m 2s Connected
</pre>

Have an eye on the values within round parentheses in the ''Media'' column, most notably the third ''packet loss'' value. These should be low, more than 5/minute for ''packet loss'' e.g. is a good reason to be worried (so in our example, the second call is still acceptable but on the lower end of satisfaction). More information about the call screen can be found in [[Howto:How_to_read_the_call_screen | How to read the call screen]].

==== Recent Call Data ====
While the calls screen is a good tool to see how your calls feel like right now, they do not allow you to review data for terminated calls. A rule of thumb however says that everything is fine as long as you look at it, but gets worse as soon as your end customers are left alone with the system. A nice tool to get at past data easily is the internal [[ Reference7:Administration/Gateway/CDR0 | Administration/Gateway/CDR0 ]] CDR logging. You can save call detail records on your local CF card (using the <code>LOCAL</code> ''Log Server Type'' which will save them to <code>/DRIVE/CF0/log/CDR*.txt</code>. You can open these files with any text editor and although they look a bit strange, you can search straight for entries like <code>&xcoder=G711A,30(0,10,0)&rcoder=G711A,30(0,0,0)</code>. The values in parentheses have the same meaning as in the PBX's calls screen.

=== The Performance Counters ===
The systems [[Reference8:Administration/Diagnostics/Counters | performance counters ]] available under ''Administration/Diagnostics/Counters'' are another valuable tool to determine its health status. These are graphs which show the status of certain resource over the last 24 hours (8 hours are shown, you can scroll through time using the arrow buttons). Each individual value on the x-axis is a 2-minutes average. Lets have look at the resource counters currently available:

==== CPU ====
This counter shows the total CPU usage. A system that runs near to 100% all the time is a candidate for unpleasant behaviour, obviously. However, running on 100% simply says that things are getting slow. It does not necessarily say that things don't work. But as a rule of life, demand is always increasing, not decreasing, so there are two options in such a situation:
* be prepared for an upgrade
* eliminate the reason for excessive CPU usage
We will discuss in a later section of this article how to determine who the CPU hog is.

We generally recommend to make sure CPU load is not more than two thirds in average. This of course is just a rule of thumb. You may well run with a system with higher load or you may experience problems with a system with lower load. Still, if your system continuously runs with more than 2/3 of its CPU power, you should ask yourself if this is expected behaviour.

Also, watch out for unusual peaks. When you have a system that has a healthy looking CPU load graph, see if there are perhaps thin peaks. These would indicate short time frames with high load. They do not look impressive in the graph, still they may create severely bad user experience. Suppose for example there is a CPU usage pattern which creates 100% CPU load for a minute every once in a while. This would look like a comfortable 50% value in the 2-minutes graph slice. The end user though may experience service outages, signalling time-outs, frustrating response times etc. during this period of time. Such patterns usually look like a sharp ''needle'' in the graph and you should pay attention if you observe such.

==== CPU-R ====
This counter shows the amount of ''reserved CPU'' time. As opposed to the CPU counter, this is not CPU load that actually is used, but CPU performance which needs to be reserved for real-time application. Sending/receiving RTP data is considered real-time, for example. As opposed to, say HTTP access, where missing CPU performance merely makes things running slower, missing CPU performance for transmission of RTP data results in voice drop-outs and thus is considered a failure. This is why calls are rejected right away when no CPU performance can be reserved. When your CPU-R counter runs near to 100% often, then your system is overloaded and needs to be upgraded. Note that real-time apps do not suffer from 100% CPU values though, as the innovaphone operating system features a very efficient real-time prioritization.

You can take a look over the used mips. With this command you get the exact information of the used mips in this moment. You can also use the CPU-R counter and move the cursor over the diagram. This method is a little bit inexact. This command is much faster than the CPU-R counter. The counter has a 5 Sec delay.
<pre>
ip-PBX/!mod cmd CPU mips-usage
</pre>

==== MEM ====
This counter shows the total volatile memory (RAM) usage. Memory usage is in fact more critical than the CPU usage, as a system with low or no CPU resources left will still run, albeit slowly. A system with no memory resources will stop working and re-boot instead! It is thus crucial to have an eye on memory usage. You may observe that the memory usage graph usually is flat, that is, the value never decreases and rarely increases, especially once the device ran for a while after a re-boot. This is because the memory allocation strategy eventually claims memory for a specific purpose if needed, but never de-allocates it further on. Instead, objects allocated but no longer used are marked as ''free'' and re-used when an object of the same type is needed later on. The memory allocation graph shows all allocated objects, including those which are used and those which are currently free (as they are not available for use by objects of other types).

If memory usage grows steadily, there is most likely a memory leak somehow. That is, a function in the device allocates objects and thus claims memory but fails to mark those objects as free when done. If this happens, each function invocation will result in lost memory and the only way to recover from this situation is to re-boot the system. We will discuss how to track down memory hogs in a later section.

==== PRIx / BRIx ====
These counters show the number of B-channels used on the respective ISDN interfaces. Its interpretation should be fairly straight forward.

=== Finding a CPU Hog ===
In the event that you observe excessive CPU load, you need to find out which function actually consumes it. Once you have done so, you can either try to re-configure the system so that the causing function is used less, or you can add an extra device and move this function to the new device. For example, if you find that your PBX runs out of CPU resources because of heavy load on the system's CF-card, you may want to move the CF card to a different device which has more CPU cycles left.

Unfortunately, you cannot determine which ''function'' takes your CPU cycles away easily. However, you can determine which ''module'' does. In our previous example, you won't be able to determine that it's excessive config save operations on the CF card that produces the load, but you will be able to determine that its the CF card that does.

A ''module'' is a piece of code in the devices firmware that performs a certain task. You can think of it as a ''thread'' in an operating system such as Windows or Linux. ''Modules'' are named and you can retrieve a list of modules currently running on your device using the <code>!mod</code> command. Assuming your device has the IP address 172.16.0.10, you would open [http://172.16.0.10/!mod http://172.16.0.10/!mod] with your browser. You will receive a list of modules such as this one:

[[Image:Debugging_check-list_1.png]]

In this table, the first column (modules) and the second column (ticks) are of interest. The second column shows the number of ticks used by the module since the counters were reset the last time. The system never resets the counters on its own. They will be reset if you add the <code>clr</code> option to the <code>mod</code> command ([http://172.16.0.10/!mod+clr http://172.16.0.10/!mod clr]). A ''tick'' by the way corresponds to some clock-tick found in the devices CPU (platform specific), so be prepared for large values.

For easier analysis, you may want to import this table into your favourite spread sheet application. In Microsoft's Excel (c) for example, you would highlight the whole table, copy it in to your copy&paste buffer, then use ''Inhalte einfügen / Paste Content'' with ''Quelle: Text / Source: Text'' so you get each column in a separate Excel column (you may need to use the ''Import Assistant'' then, later V8 and V9 firmware builds output a more excel friendly table format). After some cleanup (remove unused columns), your spread sheet should then look something like this:

[[Image:Device Health Check - mod-cmd-excel-1.png | Excel Import]]

You can then add a column (column D in our example) which relates the number of ticks used by a module to the total number of ticks used (<code>=B96/($D$98)</code>). This is the relative load imposed by a certain module. Finally, sort the table by this column and you get a list of CPU hog candidates:

[[Image:Device Health Check - mod-cmd-excel-2.png | Excel Analysis]]

Unfortunately, there is no list of ''which module has which name'', but a look at the module name will give a good indication of what it is. The typical scenario is that IP0 (the IP stack), ETHx (the ethernet drivers) and H323 (the H.323 signalling stack) will be on top. If the device is a gateway too, the DSP drivers (AC-DSPx) and SRTP encryption drivers (MV78X00_CRYPT) will be in the top 10 too. In our example, you can see that the compact flash driver (CFLASH) is also prominent. Compared to that, the PBX itself - accounting for 2% of the cycles consumed - is a side-note only in our example.

Be aware that these figures are counted from the last counter reset. To identify the source of a CPU resource problem, you would wait for the situation to happen (i.e. you would wait for a time the CPU usage is high) and then do the math. However, you should start the analysis by resetting the counters (<code>!mod clr</code>), then wait a significant amount of time (half a minute may be a good starter), then get the stats (<code>!mod</code>) and analyse. If you fail to reset the counters, your picture will be distorted as it is influenced by previous (and probably unknown) activity.

=== Finding a DRAM Memory Hog ===

The strategy to find a dram memory hog is pretty much similar to the one to find the CPU hog. However, rather than using the <code>!mod</code> command, you would use the <code>!mem</code> ([http://172.16.0.10/!mem http://172.16.0.10/!mem]) command. The output will look something like this (again, later builds have somewhat different layout, so excel import will be easier):

<pre>
Total Memory Usage = 1061428
name size used free usage
client_gui_button 64 0 0 0
client_gui_text 64 0 0 0
client_gui_break 60 0 0 0
client_gui_ruler 60 0 0 0
client_gui_list_element 60 0 0 0
client_gui_list 64 0 0 0
client_gui_table_cell 60 0 0 0
client_gui_table_row 60 0 0 0
client_gui_table 60 0 0 0
</pre>

The table has a line for each type of internal object (e.g. <code>client_gui_button</code>). The ''size'' column gives the size of a single instance, the ''used'' and ''free'' columns the number of allocated objects which are still in use or free for re-use again, while ''usage'' is <code>size * (used + free)</code>. So clearly, the ''usage'' column is what you are interested in. Again, we will do some spread-sheet math.

[[Image:Device Health Check - mem-cmd-excel-1.png | Excel Analysis]]

In our example, we relate the values in the ''usage'' column to the total allocatable memory size (column G) and the currently allocated memory (column F). The table is then sorted by column F, resulting in a list of memory using objects.

As for the modules, there is no ''which object type has which name'' list, but looking at the object names will give some indication on what kind of object it is and which function it may be related to. The screen-shot was taken from an idle system, this is why column G is all zero. In a life system, the result may look more like this:

<pre>
Name Size Used Free Sum % of allocated %of available
cmd_exec 376 36 74 41360 1% 0%
flashdir_item 120 418 0 50160 1% 0%
pbx_connector 508 67 47 57912 2% 0%
h323_call 552 67 46 62376 2% 0%
gk_map 448 176 1 79296 2% 0%
tcp_socket 408 150 176 133008 4% 0%
pbx_user 584 270 0 157680 4% 0%
packet 52 4997 488 285220 8% 0%
http_request 5472 33 75 590976 17% 0%
buffer 32 10437 8255 598144 17% 0%
ac_491 122648 6 0 735888 21% 0%
</pre>

As a rule of thumb, many systems tend to run out of CPU more likely than out of DRAM memory.

''packet'' and ''buffer'' are special, as they do not relate to a specific function. Whenever the system needs temporary, short lived memory - e.g. to carry a network packet - it will allocate a ''packet'' that carries one or more ''buffers''. Peak network load thus will allocate a huge amount of ''packets'' and ''buffers'' which might not be used again but still consume memory. When the number of ''packets'' or ''buffers'' increases over time, this is most likely an indication of a memory leak.

The bottom of the memory table includes a number of lines as follows:

<pre>
allocated: 1466608
free for malloc: 58580
total malloc space: 3149356
physcial memory: 8388608
Total memory usage: 3090776
Memory Load: 36%
</pre>

The ''allocated:'' line is the number of allocated objects. That is, the sum of the ''usage'' column. Please note that this include all free objects of a specific type, which can be used for allocation of new objects of this type.

The ''free for malloc:'' line is the amount of memory which can be allocated from. This will be used whenever an object is needed for which there is no previously allocated but now unused object space (as shown in the ''free'' column).

The ''total malloc space:'' is the value of ''free for malloc:'' when the system has booted.

The ''Total memory usage:'' is the memory already claimed from the malloc space (that is ''total malloc space:'' minus ''free for malloc''). It does ''not'' include static memory use such as decompressed firmware, stack, etc.

The ''Memory Load:'' finally relates the ''Total memory usage:'' to the ''physical memory:''. Please note though that the box will run out of memory as soon as ''free for malloc'' goes down to zero! It might be useful thus to relate ''free for malloc:'' to ''total malloc space:'', which is exactly what the ''MEM'' counter in ''Administration/Diagnostics'' displays.

==== Obtaining more Information about used Objects ====
Sometimes, object types - even though their meaning is pretty clear - cannot be related to functions easily. For example, if you see an entry like

<pre>
tcp_socket 376 15 64 29704
</pre>

it tells you that a number of sockets are used, but not what for. To see details of an object, some object types support the <code>mem-info</code> method. You would look at the detail properties of the objects of a certain type using e.g. <code>http//172.16.0.10/!mem info tcp_socket</code> ([http://172.16.0.10/!mem+info+tcp_socket http//172.16.0.10/!mem info tcp_socket]). The result list

<pre>
0(c0e09a0c): NAT_LISTEN: ports=0:0, state=0:INIT, ostate=5680, x-q=0, r-q=0
1(c0e1073c): PCAP_SOCK_LISTEN: ports=2002:0, state=0:INIT, ostate=0, x-q=0, r-q=0
2(c0e17174): HTTP_LISTEN: ports=80:0, state=0:INIT, ostate=0, x-q=0, r-q=0
3(c0e173d8): HTTPS_LISTEN: ports=443:0, state=0:INIT, ostate=23130, x-q=0, r-q=0
4(c0e181b8): T_USER: ports=23:0, state=0:INIT, ostate=0, x-q=0, r-q=0
5(c0e1fcd8): LSRV_SOCK_LISTEN: ports=389:0, state=0:INIT, ostate=0, x-q=0, r-q=0
6(c0e718f4): GK-LISTEN: ports=2049:0, state=0:INIT, ostate=-16053, x-q=0, r-q=0
7(c0e71b54): GK-LISTEN: ports=2050:0, state=0:INIT, ostate=0, x-q=0, r-q=0
8(c0e71e3c): GK-LISTEN: ports=2051:0, state=0:INIT, ostate=0, x-q=0, r-q=0
9(c0e72310): GK-LISTEN: ports=2052:0, state=0:INIT, ostate=0, x-q=0, r-q=0
10(c0e725f8): GK-LISTEN: ports=2053:0, state=0:INIT, ostate=1950, x-q=0, r-q=0
11(c0e728e0): GK-LISTEN: ports=2054:0, state=0:INIT, ostate=-16148, x-q=0, r-q=0
12(c0e72bc8): H323_LISTEN: ports=1720:0, state=0:INIT, ostate=-16027, x-q=0, r-q=0
</pre>

may include some useful hints. This is particularly useful for the ''packet'' data structure, as it is used by all classes: [http://172.16.0.10/!mem+info+packet http//172.16.0.10/!mem info packet] indicates the packet creator module:

<pre>
5717(c1d1d0b8): ETHIF,c0078b38 len=31
5719(c18197fc): H323_OUT,c0078b38 len=31
5725(c1cfb864): H323_ACCEPT,c0078b38 len=31
5728(c1d04670): ETHIF,c0078b38 len=31
5729(c1d56ac8): HTTP4_REQUEST,c00e228c len=113
5730(c1f09518): HTTP_SOCKET,c0078b38 len=240
</pre>

If there is a memory leak, the module causing it can easily be spotted.

==== Buffers ====
So far we have talked about ''objects'' in the operating system. However, there are also other users of dynamically allocated memory, the so-called ''buffers''. These are used for network packets for example. You can use <code>http://172.16.0.10/!buf</code> to get a list of used buffers.

<pre>
pool used free
0: 32 4129 2573 375312
1: 64 319 652 85448
2: 128 154 218 56544
3: 256 188 85 76440
4: 512 155 167 172592
5: 1024 24 6 31440
6: 2048 0 1 2072
7: 4096 120 4 510880
8: 8192 2 4 49296
1360024
</pre>

The second column shows the buffer size (buffers are always allocated in multiple-of-2 sizes). To see who has allocated the buffers, you can issue <code>http://172.16.0.10/!buf info size</code> where ''size'' is the one of the valid buffer sizes (32 to 8192).

<pre>
http://172.16.0.10/!buf info 8192
15c6e80: c=HTTP4_REQUEST(114988)
15c4e60: c=HTTP_GET(19838c)
15e8650: c=HTTP_GET(1983a0)
</pre>

This example shows that 3 buffers of size 8192 are used and all are somehow related to HTTP GET requests.

=== Finding a Flash Memory Hog ===
Unfortunately, there is no counter graph for flash memory usage. Still, there is a statistics page as for CPU and DRAM memory. It is retrieved using the <code>!mod cmd FLASHMAN0 info</code> command ([http://172.16.0.10/!mod+cmd+FLASHMAN0+info http://172.16.3.63/!mod cmd FLASHMAN0 info]):

<pre>
bottom 0xfe020000 base 0xfe020000 top 0xfffc0000 segsize 0x20000 segments 253
LDAP - used 128k avail 92k owned 1152k (max 3200k)
VARS - used 67k avail 95k owned 256k (max 256k)

0 0xfe020000 free(0x00) owner MINI(0x09) magic 0x666d order 0x00020031 usage 0x00000001
...
7 0xfe100000 free(0x00) owner FIRM(0x08) magic 0x666d order 0x0002002f usage 0x00000001
...
226 0xffc60000 free(0xff) owner 255 (0xff) magic 0xffff order 0xffffffff usage 0xffffffff
...
230 0xffce0000 used(0x80) owner VARS(0x06) magic 0x666d order 0x00000008 usage 0x00000001
231 0xffd00000 used(0x80) owner LDAP(0x04) magic 0x666d order 0x00000009 usage 0x00000001
</pre>

This table shows all allocated flash memory segments. Users include:
; MINI : the mini (rescue) firmware
; FIRM : the real firmware
; VARS : the storage for non-volatile configuration parameters
; LDAP : the directory storage (holds the PBX object configuration as well as call lists and personal user directories)

Each flash memory user has a fixed maximum quota. In our example, LDAP has set a maximum of 3200kB of which 1152kB are already claimed. In the current active flash segment (that is, the segment which is used to satisfy subsequent memory requests), 92kB are left for allocation. For the VARS flash user, all possible segments are claimed already (256kB of 256kB) and 95kB are left for allocation.

==== Wasting Memory by deleting Objects ====
When PBX objects are deleted, the GUID is kept in flash memory for a while with a note that the object has been deleted. This looks something like <code>mod cmd FLASHDIR0 add-item 101 (cn=object that will be deleted soon)(isDeleted=true)(guid;bin=3886C5ABE909D3119475009033290009)(usn=18243)</code>. Note that this sample entry still takes approximately 110 bytes flash memory. If you experience lack of flash memory and see lots of such entries, you might want to save the devices config, remove the lines with <code>(isDeleted=true)</code> and re-load the config to get rid of these entries. This typically happens when you turn on a new replication for a box that had a large PBX configuration before. These now obsolete PBX entries will be deleted from the configuration when the replication takes place.

=== Finding a Compact Flash Hog ===
Compact flash card space can easily be examined using the ''Info'' button available in [[ Reference7:Administration/Diagnostics/CF | Administration/Diagnostics/CF (up to V8) ]] or [[ Reference9:General/Compact-Flash/General | Reference9:General/Compact-Flash/General (from V9) ]]. The CF card's content can be examined using the ''Browse CF Content'' link on the same page.

=== Using Syslog ===
Many failures are listed in the ''Alarms'' and ''Events'' sections, as discussed above. However, some are not. It is a good habit therefore to take transcript of the systems log messages and browse through them in search of intermittent problems. This can easily be done by storing the syslog on the local CF card (as defined on [[ Reference8:Configuration/General/Logging | Configuration/General/Logging ]]). It is important to tick the check marks on [[ Reference8:Administration/Diagnostics/Logging | Administration/Diagnostics/Logging ]] in a sensible way in order not to flood the log with useless messages. As a starter, the following settings are recommended:

{|
| Category || recommended setting
|-
| TCP || off ||
|-
| PPP || off ||
|-
| PBX Calls || on ||
|-
| Gateway Calls || on ||
|-
| Gateway Routing || off ||
|-
| H.323 Registrations || on ||
|-
| SIP/UDP Registrations || off, unless you use SIP endpoints ||
|-
| SIP/TCP Registrations || off, unless you use SIP endpoints ||
|-
| SIP/TLS Registrations || off, unless you use SIP endpoints ||
|-
| H.323-NAT || off ||
|-
| Administration || off ||
|-
| TELx/PRIx/PPP || off, unless you use this interface ||
|-
|}
Please note that ''Administration'' might be a recommended setting if documentation of changes is an issue to you.

=== Resource sensitive PBX Configuration ===
Very often, resource issues are caused by inappropriate PBX configuration. Although there are of course a huge number of possibilities to do it wrong, here are a few prominent and easy to avoid things to keep in mind:

* do not use long identifiers. All PBX identifiers (user names, group names, ...) are stored in clear text in the PBX LDAP directory. Longer names use more flash space thus. If you deal with a 100 user PBX, you probably don't care. However, if you have 10.000 users structured in groups with a huge amount of members per group, calling a group <code>cti</code> instead of <code>Users with CTI Integration</code> does make a difference!
* do not put objects in to groups they do not need to belong to. You may be tempted to add users to certain groups ''by default'', thinking that it will make your life easier later on if the group assignment is in fact needed. However, group assignments not only consume flash space in the PBX's LDAP directory, but also consume in-core memory during run-time. Even more, doing so will make it more probably to exceed the maximum size of a single group (which is 2000 members currently). Having more than the allowed maximum of group members in a single group will result in strange behaviour which is difficult to track down.
* do not put objects as ''active'' members in to groups when they don't need to be active. ''Active'' group memberships consume additional DRAM memory as well as additional CPU cycles during run-time.
* do not configure [[Reference7:Administration/PBX/Objects#Object_Properties | group indications ]] when they are not needed. Group indications will result in additional memory and CPU consumption as well as network traffic. When group indications are configured, information is distributed to the respective group members regardless of if it is used there or not. So if no group indication is required, don't send it! If it is required, use the smallest group available to send them to. Do not re-use a group for this purpose just because it exists if it includes more members than required for the group indications. Rather create a new group and restrict it to the members required. One particular bad habit is to put all users in a single group, have them all be ''active'' and configure this group as the group used for ''group indications'' for all users. While this has the beauty that PBX functions which require group indications will always work (which to configure correctly may be a bit tedious sometimes), but it has the downside that each call to any of these users suffers from increased CPU and network load with each added user!
* do not create objects that aren't needed. Each PBX object consumes flash and DRAM memory, even if it is never used.
* do not put objects in to the group used by the TAPI service provider which are never monitored anyway. All activity information for all users in the tapi group is conveyed by the PBX to the TAPI service provider. If it is never used, this is a waste of resources and adds load both to the PBX and to the machine running the TSP.

=== Monitoring a multi-Device System ===
If your system consists of more than one relevant device, you may want to configure Alarm, Event and Syslog forwarding (as configured in [[ Reference8:Configuration/General/Logging | Configuration/General/Logging ]]) so you have this information in a single place to review.

=== Monitoring the Linux Application Platform (LAP) ===

To see the LAP's health status, first have a look at the ''Diagnostics/Status'' page.

==Related Articles==
* [[Howto:Config_size_Limitations]]

[[Category:Howto|{{PAGENAME}}]]