Revision as of 07:24, 19 October 2010

In some cases, network tracing is not sufficient to pinpoint a problem. Although the network message flow is correct, the phone might still not work as expected.

However, OpenStage phones provide a tracing facility for internal processes which may prove helpful in such situations.

In addition to this article, a HowTo document is available for download:   Service_Info_How_to_trace_OST_SIP.

Preconditions

Ensure that the phone is configured with a working SNTP server so that the trace logs indicate the correct time. If no SNTP server is available, the time can be adjusted manually. casino en ligne

If the internal phone trace logs are to be combined with other trace results (e.g. from Wireshark), the tracing processes must be synchronized. Therefore, both the machine used for tracing and the phone must be connected to the same SNTP server. If no SNTP server is available, ensure that you have configured the same time on all tracing devices.

Phone Tracing

Activate Internal Tracing

1. Login to the administrator pages at the WBM.

2. In the admin menu, select Diagnostics > Fault trace configuration.

3. Set the Trace timeout to 0. This disables the trace timeout.

4. Set the File size according to the phone type:

• OS 15/20 : 500.000 bytes
• OS 40 : 1500.000 bytes
• OS 60/80 : 2500.000 bytes

5. Activate Automatic clear before start.

6. Select the trace level for the relevant components.

7. Click Submit.

Traceable Components

• Administration
  

This deals with the changing and setting of parameters within the phone database, from both the User and Admin menus.

• Application framework
  

All applications within the phone e.g. Call view, Call log or Phonebook are run within the application framework. It is responsible for the switching between different applications and bringing them into and out of focus as appropriate.

• Application Menu
  

This is where applications to be run on the phone can be started and stopped.

• Bluetooth Service
  

This handles the Bluetooth interactions between external Bluetooth devices and the phone.

• Call log
  

This deals with the Call log application which displays the call history of the phone.

• Call view
  

This handles the representation of telephony calls on the phone screen.

• Certificate management
  

This service handles the verification and exchange of certificates for security and verification purposes.

• Communications
  

This is involved in the passing of call related information and signaling to and from the CSTA service.

• Component registrar
  

This handles data relating to the type of phone, e.g HFA/SIP, or Workpoint Hi/Workpoint Lo.

• CSTA service
  

Any CSTA messages, are handled by this service. CSTA messages are used within the phone by all services as a common call progression and control protocol.

• Data Access service
  

This service allows other services to access the data held within the phone database.

• Desktop
  

The desktop service is responsible for the shared parts of the phone display. Primarily these are the status bar at the top of the screen and the FPK labels.

• Digit Analysis service
  

This analyses and modifies digit streams which are sent and received by the phone e.g. canonical conversion.

• Directory service
  

This performs a look up service for data in the phonebook, trying to match incoming and outgoing numbers with entries in the phonebook.

• DLS Client management
  

Interactions with the Deployment and licencing server are handled by this service.

• Health service
  

This monitors other parts of the phone for diagnostic purposes and provides a logging interface for the other services in the phone.

• Help
  

The help function is handled by this service.

• Instrumentation service
  

This is used by the Husim phone tester to exchange data with the phone for remote control, testing and monitoring purposes.

• Java
  

Any Java applications run on the phone will be run in the Java sandbox controlled by the Java service.

• Journal service
  

The Journal service is responsible for saving and retrieving call history information which is used by the Call log application.

• Media control service
  

This service provides the control of media streams (voice, tones, ringing etc.) within the phone.

• Media Processing service
  

This is a layer of software between the media control service and the tone generation and voice engine services. It is also involved in switching of :audio devices such as the handset and loudspeaker.

• Mobility service
  

This handles the mobility feature whereby users can log onto different phones and have them configured to their own profile.

• OBEX service
  

This is involved with Bluetooth accesses to the phone.

• Openstage Client Management
  

This provides a means by which other services within the phone can interact with the database.

• Phonebook
  

This is responsible for the phonebook application within the phone.

• POT service
  

This service is supposed to take over control of basic telephony if the callview application fails.

• Password management service
  

This is used to verify passwords used in the phone.

• Physical interface service
  

This handles any interactions with the phone via the keypad, mode keys, fixed feature buttons, clickwheel and slider.

• Service framework
  

This is the environment within which other phone services operate. It is involved in the starting and stopping of services.

• Service registry
  

This keeps a record of all services which are currently running inside the phone.

• Sidecar service
  

This handles interactions between the phone and any attached sidecars.

• SIP call control
  

This is contains the call model for the phone and is associated with telephony and call handling.

• SIP Messages
  

This traces the SIP messages which are exchanged by the phone. Activating the SIP messages trace requires a reboot of the device.

• SIP signalling
  

This is involved in the creation and parsing of SIP messages and communicates directly with the SIP stack.

• Team Service
  

This is primarily concerned with Keyset operation.

• Tone generation
  

This service handles the generation of the tones and ringers on the phone.

• Transport service
  

The transport service provides the IP (LAN) interface between the phone and the outside world.

• vCard parser service
  

This trace is for sending/recieving vCards via the Bluetooth interface.

• Voice engine
  

This provides a switching mechanism for voice streams within the phone. It is also involved in QDC, Music on Hold and voice instrumentation.

• Voice mail
  

This trace monitors the integrated Voice mail application of the phone.

• Web Server service
  

This provides the web access to the phone.

• USB Backup service
  

This is for the backup/restore feature via USB devices.

• Voice recognition
  

The Voice recognition service is for the voice dialling feature.

• 802.1x service
  

This is for port security (802.1x).

Read out the Internal Phone Traces

1. Login to the administrator pages at the WBM.

2. In the admin menu, select Diagnostics > Fault trace configuration.

3. Now you can download resp. view the desired trace files. The trace files available are described in the following.

• trace file
  

The trace data according to the settings specified for the services.

• old trace file
  

The trace file is stored permanent memory. When the file has reached its size limit, it will be saved as old trace file, and the current exception file is emptied for future messages.

• saved trace file
  

Normally, the trace file is saved only in the phone RAM. When the phone restarts in a controlled manner, the trace file will be saved in permanent memory

• upgrade trace file
  

The trace log created during a software upgrade.

• upgrade error file
  

The error messages created during a software upgrade.

• exception file (V2R1 onwards)
  

If an exceptions occurs in a process running on the phone, a message is written to this file (this file is important to check the memory management).

• old exception file (V2R1 onwards)
  

The exception file is stored permanent memory. When the file has reached its size limit, it will be saved as old exception file, and the current exception file is emptied for future messages.

• syslog file
  

Contains system messages (eg. Dhcp requests,boot,network changes,ntpclient,kernel,LLDP).

• old syslog file
  

The syslog file is stored permanent memory. When the file has reached its size limit, it will be saved as old syslog file, and the current syslog file is emptied for future messages.

• saved syslog file
  

Normally, the trace file is saved only in the phone RAM. When the phone restarts in a controlled manner, the trace file will be saved in permanent memory.

• Database file (V2R1 onwards)
  

Phone Database.

• HPT remote service log
  

HTP message created during login/usage.

• Dial plan (V2R1 onwards)

Dial plan configuration.

Core Dump

If enabled (default), a core dump will be initiated in case of a severe error. The core dump will be saved to a file.

1. Login to the administrator pages at the WBM.

2. In the admin menu, select Diagnostics > Miscellaneous > Core Dump.

3. In the Core Dump screen, make sure that Enable core dump is activated.