Note

The features and/or parameters listed in this article may not be available from your telephone service provider.

Introduction

The supporter finds here instructions how to handle a user's level 2 telephony problems:

Best Practice for Handling an User Problem
Record the Customer's Data and Problem Description
Analyzing the Customer Problem
Solving the Customer Problem

Introduction Support Level 2

The level 2 support is the first instance where the user's telephony problems are handled that a user cannot solve himself. Additionally the level 2 supporter must be able to detect if the user problem is a "single" problem or if there is a large scale problem, that produces the same problem for multiple customers, e.g. data transfer problems in the Internet so that no VoIP call signaling is possible.

The level 2 supporter must be aware of the complexity of a VoIP system and the multitude of telephony solutions on the user side. Further he needs an understanding of:

IP networking
VoIP protocols SIP for signaling, SDP and RTP for speech transmission.

Overview of a VoIP system and the multitude of user telephony solutions:

The level 2 supporter faces problems with the following layers:

Equipment
IP data transfer
Telephony service

And each of this layer can be located into the following raw areas:

Customer/User site
Internet Service Provider ISP
Telephony Provider

This layer and dividing into areas produces a "3x3 Support Matrix":

Within this "3x3 Support Matrix" the supporter can:

advice the customer what to do when the problem is located in the nodes 1-T, 1-D and 1-E
check the customer configurations on the VoIP Switch, node 3-T, and, if he has operator rights, adjust configurations.

For the other cases the level 2 supporter must be able to identify if:

the user must contact his ISP, due to possible Internet access problems
the VoIP System administrator must be involved, due to possible telephony service problems

Hint:

These cases indicate mostly large scale problems within the VoIP system!

	Customer	Internet ISP	Telephony Provider
Telephony			Check via ConfigCenter: Does the telephone number exist? Is the telephone number valid? Is the user account valid? Actions: → Check why the account, telephone number doesn't exist or is disabled and activate if allowed.
Data Transfer
Equipment

	Customer	Internet ISP	Telephony Provider
Telephony			In the "Support Log" search for the device registration in the present and past time. Set the "Support Log" filters Insert at "Text" the account name Insert at "From" - "Until" a reasonable time span where registrations could be expected Select the category: "Registration" Start the search and find out according the results what is going wrong. If needed repeat the search with the telephone number in the "Text" or other time spans
Data Transfer
Equipment

	Customer	Internet ISP	Telephony Provider
Telephony
Data Transfer
Equipment	Check if the device correctly powered and shows basic activity? Is the power cable correctly plugged in? Is the power cable Does the device show power on indication, e.g. display on, LED on? Actions: → replace the power cable → replace defect device if the powering is ok but no working indication is displayed

	Customer	Internet ISP	Telephony Provider
Telephony			Check via ConfigCenter: In the "Call Data" search for the erroneous call: Set the "Call Data" filters: Insert at "Time" a reasonable time span where the erroneous call is to be expected. Set "Duration" to 00:00:00 Insert at "Called Number" the called number Start the search and identify the CDR of the erroneous call in the list If no CDR was found search for the "Calling Number"! Open the identified CDR and get the trace of the call, click the Button [ Trace ] Check if the called number in the "TO-Header" in all INVITE messages is correct: Is the called number correct? Often the users don't dial all digits or wrong digits or the configured number on a direct call key is incorrect. If the number is dialed correctly then it can be that the destination is not reachable. Outgoing calls from a vPBX can miss the public prefix Check the peers call cancel reason: SIP Failure Responses Actions: → Inform the user to dial the correct number. → Try to reach the called number via an alternative telephone network, e.g. from a mobile telephone. → Check with the support of the telephony provider why the called number is not reachable.
Data Transfer
Equipment

	Customer	Internet ISP	Telephony Provider
Telephony	Search in the "Call Data" for the erroneous call: Set the "Call Data" filters: Insert at "Time" a reasonable time span where the erroneous call is to be expected. Set "Duration" to 00:00:00 Insert at "Called Number" the called number Start the search and identify the CDR of the erroneous call in the list If no CDR was found search for the "Calling Number"! Open the identified CDR and check for the interruption reason: Was the connection released by a peer, A or B side? Check cancel reason in "State" ( SIP Failure Responses ) Actions: → Inform the user about the release reason, e.g. his own device or the peer device released the call regularly (but probably nor expected). Check if a call was released due to call supervision: Variant 1: Session Timer was not refreshed: Open the "Trace" of the connection and check if the connection was released due to missing RE-INVITE from the peers when the Session Timer run out. Variant 2: SIP INFO were not answered by the peer: Open the "Trace" of the connection and check if the connection was released due to not answered INFO messages that were sent from the VoIP Switch toward the peers. If activated the INFO's are sent usually every 120sec. Actions: → Inform the user that his device did not restart the Session Timer or did not answered INFO messages. The user must inspect the device configuration. Or the Variant 3: Missing RTP packets between the peers: Actions: → Inform the user about the release reason, e.g. his own device or the peer device released the call regularly (but probably nor expected). → Inform the user that his device did not restart the Session Timer or did not answered INFO messages. The user must inspect the device configuration. Or the
Data Transfer
Equipment

User Support Level 2

Contents

Introduction Support Level 2

Best Practice for Handling an User Problem

Record the Customer's Data and Problem Description

Get the Customer's Data

Identify the Customer's Use Case

Note the Customer's Problem Description

Cross Check the User Inputs

Check the Big Picture

Analyzing the Customer Problem

Use Case "Residential" Questioning

Solving the Customer Problem

Solve Problem Type: "Device / Network"

Solve Problem: Telephone Connections

Solve Problem: Disturbed Speech Transmission

Solve Problem: Disturbed FAX Transmission

Solve Problem: DECT Multi-Cell Handsets are not Working

Navigation menu

Search