Latest revision as of 09:21, 9 October 2017

Note

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

Home Support

Download PDF

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

1 Introduction Support Level 2
2 Best Practice for Handling an User Problem
3 Step 1: Record the Customer's Data and Problem Description
- 3.1 Get the Customer's Data
- 3.2 Write down the Customer's Problem Description
4 Step 2: Cross Check the User Inputs
5 Step 3: Evaluate the User's VoIP Setup
6 Step 4: Check the "Big Picture"
7 Step 5: Solve the Customer Problem

→ Top

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!

→ Top

Best Practice for Handling an User Problem

Best Practice

Record the customer's data and problem description:
- Get the customer data
- Get the problem description from the customer
Show me how ...
Cross check the user input against the VoIP switch configuration and logs.
Via ConfigCenter check the users account configuration:
- Telephone number registration
- TopStop
- RuleSet
- Consult the "Call Data" for the last connection attempts and connections longer than 2min
Show me how ...
Evaluate the user's VoIP setup:
- For questioning and analyzing the user's problem it is necessary that the supporter is aware of the VoIP setup of the user.
Show me how ...
Check the big picture:
- If you are sure that the problem is "single" one continue with the next step "Solve the customer problem"
- If you suspect that the customer is not the only one with this problem within a short time range, e.g. 30min, then contact the VoIP switch administrator/operator if there is known issue in the VoIP system that causes this type of problem.
Show me how ...
Solve the customer's problem:
- You have now enough basic information for solving the customer's problem
Show me how ...
If you are not able to solve this problem then contact the provider support. Have ready all collected information and what you have done and found out until now.

The supporter shall record the user information and the results of the own research:

Note

This information is most welcome if the supporter needs the support of the provider and has to inform him about the case.

→ Top

Step 1: Record the Customer's Data and Problem Description

→ Top

Get the Customer's Data

From the customer get:

Name of the caller
Telephone number of the caller
if applicable the company name

→ Top

Write down the Customer's Problem Description

From the customer get:

Date and time of the issue
The involved telephone numbers
The problem description

If the customer doesn't know then identify via the ConfigCenter the telephone number and its associated account.

→ Top

Step 2: Cross Check the User Inputs

With this cross check the supporter can validate the user information, gets an impression of the state of the account and will probably find the reason for the user problem...

Via ConfigCenter check the users status and account configuration on the VoIP Switch:

Check "Validity":
Check if the user account and its addresses are existing and "valid".
Check the telephone number registration status.
If there is no registration you can proceed directly with The user device is not registered ...
Check "TopStop":
Check if a TopStop in the account or address prevents the user from doing outgoing calls.
Check "RuleSet":
Check if a selected RuleSet in the account or address configuration prevents the user from doing outgoing or receiving calls.
Check "Call Forwards" or "Call Rejecting":
Check if a "Call Forwards" or "Call Rejecting" in the account prevents the user from doing outgoing or receiving calls.
Check "Call Data":
Consult the "Call Data" for the last connection attempts and connections longer than 2min of the user.

→ Top

Step 3: Evaluate the User's VoIP Setup

For questioning and analyzing the user's problem it is necessary that the supporter is aware of the VoIP setup of the user.

The experienced supporter knows of the user's VoIP setup after the cross check . If not here the supporter finds the most implemented VoIP setup's.

→ Top

VoIP Setup: Residential

Characteristics:

Private household
Single or few telephone number
Each telephone number registers individually

Most common problems:

Account or telephone number blocked on the VoIP switch
Telephone number not correctly ported to the telephony provider
Telephone not correctly configured
Telephone, cables defect
Internet access fails

Overview VoIP Setup:

→ Top

VoIP Setup: Legacy ISDN PBX

Characteristics:

Company PBX
The ISDN PBX is connected via BRI or PRI to an ISDN-SIP Gateway
One or more telephone number ranges
The telephone numbers are registered via a main number
The telephone number of incoming calls are signaled with only a few digits

Most common problems:

Account or telephone numbers blocked on the VoIP switch
Telephone number ranges not correctly ported to the telephony provider
Telephone number ranges not completely configured on the VoIP Switch
Wrong incoming telephone number signaling
Internet access fails
The company Firewall VoIP ALG interferes with the SIP signaling or needed IP ports are blocked.
QoS problems for speech, Fax, DECT

Overview VoIP Setup:

→ Top

VoIP Setup: IP PBX

Characteristics:

Company PBX
The IP PBX is connected directly or via SBC to the VoIP Switch
One or more telephone number ranges
The telephone numbers are registered via a main number

Most common problems:

Account or telephone numbers blocked on the VoIP switch
Telephone number ranges not correctly ported to the telephony provider
Telephone number ranges not completely configured on the VoIP Switch
The company Firewall and/or SBC VoIP ALG interferes with the SIP signaling or needed IP ports are blocked.
Internet access fails
QoS problems for speech

Overview VoIP Setup:

→ Top

VoIP Setup: vPBX

Characteristics:

Company PBX
The IP Phones are connected directly to the VoIP Switch
One or more telephone number ranges

Most common problems:

Public account and/or public telephone numbers blocked on the VoIP switch
Public telephone number ranges not correctly ported to the telephony provider
Telephone number ranges not completely configured on the VoIP Switch
Private account and/or private telephone numbers blocked on the VoIP switch
Provisioning of the SIP devices out of the AdminCenter
The company or home office Firewalls and/or SBCs VoIP policies or ALG interferes with the SIP signaling or needed IP ports are blocked.
Company/home office Internet access fails
QoS problems for speech, FAX, DECT

Overview VoIP Setup:

→ Top

Step 4: Check the "Big Picture"

At this point the supporter should get aware if the problem is limited to this user or if it could be large scale problem within the VoIP System.

If the supporter suspects a large scale problem, due to a great amount of the same ore similar user complains then he should contact the telephony provider support or emergency organization.

If the supporter has enough privileges he can check:

The VoIP Switch component status
This will show if the VoIP Switch itself has a problem.
The VoIP System monitor
Here you can check if:
- The registrations dropped in a large scale
- The calls dropped in a large scale
- The IP connectivity somewhere in the VoIP system failed

At any rate the supporter must inform the VoIP system administrator!

→ Top

Step 5: Solve the Customer Problem

→ Top

Solve "Device / Network / Configuration / Registration" Problems

This problem type covers the following erroneous conditions:

The device doesn't start
The device doesn't integrate into the IP network
The device is not correctly configured
The device doesn't register at the VoIP Switch

Note

If the device is connected to an IP-PBX then these problems must be solved with the responsible of the IP-PBX.

→ Top

Solve "Device Hardware & Firmware" Problem

1 Step: Is the device powered on, not defect?

	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 not defect? 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

Warning

Defect power cables must be replaced!
Faulty power cables can be life-threatening!

2 Step: Is the device connected to the IP network?

	Customer	Internet ISP	Telephony Provider
Telephony
Data Transfer
Equipment	Is the device correctly connected to the IP network? Is the patch cable correctly plugged in? Is the patch cable not defect? Are there LED flashing or glow next to the network plug on the device or at the peer device (access router, IP switch)? Actions: → Replace the patch cable → Plug in the patch cable at a different port at the peer device (access router, IP switch) → Replace defect device if the patch cable and peer port is ok but no working indication is displayed at the device port.

3 Step: Has the device a reasonable firmware loaded?

	Customer	Internet ISP	Telephony Provider
Telephony
Data Transfer
Equipment	Has the device a reasonable firmware loaded? The user must check the loaded firmware Actions: → Replace the firmware if outdated or important bugs are fixed

→ Top

Solve "Device Network" Problem

1 Step: Has the device an IP address and can access the Internet?

	Customer	Internet ISP	Telephony Provider
Telephony
Data Transfer	Has the device got an IP address? Check on the device if it has received an IP address, e.g. via display or maintenance GUI. Actions: If no IP address was assigned the user must: → Check if the device is really connected to the IP network! → Check if the device is configured with a fixed IP address! If it has a fixed IP does it match with the IP subnet? Is the default GW and DNS entry configured? → Check if the device is configured to use DHCP! if the DHCP service in the IP network is running If the user cannot check the DHCP service he must contact the company IT responsible or the responsible of maintaining the access router. Has the device access toward the VoIp Switch? Check if the device makes contact with the VoIP Switch via Internet or any private IP Link. Actions: → If the device shall connect via the Internet: Connect a PC to the Ethernet port where the device usually is connected and try to connect to any public Web site. → If the device shall connect via an private network check with the IT responsible if the access to the VoIP Switch is guaranteed.
Equipment

→ Top

Solve "Registration" Problem

1 Step: Review the account and telephone number configuration

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

2 Step: Where REGISTER messages received from the device on the VoIP Switch?

	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 Check the log results see below Actions: see below
Data Transfer
Equipment

Failed registrations due to disabled account or address:

2017-09-15-07:56:49.553 Registration failed, disabled account aan1-00093 tried to register number 0449980010

Actions:

Check why the account is disabled and activate if allowed.

Failed registrations due to wrong SIP credentials:

2017-09-15-08:05:38.117 Registration failed, invalid credentials for account acc-01 2017-09-15-08:05:39.112 Registration failed, unknown username 'myusername' tried to register '0123456789' 2017-09-15-08:05:38.377 Registration failed, unknown number '0987654321' tried to register for account acc-01

Actions:

The user must manually adjust the SIP credentials on the device
The user must re-configure the device via AdminCenter

The device didn't refresh its registration:

2017-09-15-07:59:00.862 RegID989961 ended for 0987654321 ip=111.111.111.111:65398 ua=my-device v1.0

Actions:

Order the user to check if the device is really on-line!
Order the user to check if the device is defect? powered on? patch? IP address? → see below

For information a successful registration:

2017-09-15-07:59:30.383 RegID989965 started for 0987654321 ip=111.111.111.111:65398 ua=my-device v1.0

Hint:
The supporter might try to find REGISTER messages from the device in the "Trace" . This gives the certainty that the message was received by the VoIP switch. The supporter can filter for the telephone number. If the IP address is needed then the customer must be able to tell or evaluate it, e.g.:

https://www.whatismyip.com/

3 Step: Is the device correctly configured for registration??

	Customer	Internet ISP	Telephony Provider
Telephony	For a manually configured device, check that the device has the correct configuration for: Telephone number SIP credentials VoIP Switch domain configuration Actions: → The user must manually check the device configuration and if needed adjust its configuration of the telephone number, SIP credentials and VoIP Switch domain for registration For a automatically via AdminCenter configured device check that: the selected device type in the AdminCenter is identical to the physical one. Actions: → If not the same type then the user must re-configure the device via AdminCenter For a automatically via AdminCenter configured device check that: the user device has downloaded its configuration. Actions: → If the configuration is not downloaded then it must be checked if the device: has got an IP address in the local IP network has access to the Internet has access to the configuration download of the Telephony Provider. By default this is the IP address of the VoIP Switch domain and uses the protocol HTTPS on TCP port 443. Check with the Telephone provider or via ConfigCenter > Menu "System" > "Zone Profiles" → The user must check if the Firewall, SBC or Access Router doesn't block HTTPS traffic to and from the configuration download of the Telephony Provider
Data Transfer
Equipment

→ Top

Solve "Connection" Problems

This problem type covers the following erroneous conditions:

Incoming or outgoing calls are not working
Wrong called number
Call supervision
User device not registered
User device not correct configured
SIP signaling in general

Note

If the device is connected to an IP-PBX then these problems must be solved with the responsible of the IP-PBX.

1 Step: Review the account and telephone number configuration / registration?

	Customer	Internet ISP	Telephony Provider
Telephony			Do this check for the A and/or B telephone number if they are on-net numbers of the VoIP SWitch. Check via ConfigCenter: Does the telephone number exist? Is the telephone number valid? Is the user account valid? Is the telephone number correctly registered Actions: → Check why the account, telephone number doesn't exist or is disabled and activate if allowed. → Check why the device is not registered at the VoIP Switch
Data Transfer
Equipment

Hint:

If the device is not registered outgoing calls might be working but NO incoming call will work.

2 Step: Was the called number correctly transmitted to the peer?

	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

3 Step: What is the reason of an interrupted connection?

	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 release or reject 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. Actions: → Inform the user that his device did not restart the Session Timer. The device configuration must be inspected an adjusted if needed. 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 answered INFO messages. It must be checke with the support of the device manufacturer if the device doesn't send 200 ACK when an empty INFO message was received ("SIP ping"). Variant 3: Missing RTP packets between the peers: This type of problem is a difficult one and hard to check and solve! It must be handled like a QoS problem. Media transferring devices as the MediaServer of the VoIP Switch, SBCs, SS7-Gateways, SIP-Trunks supervise the media stream of RTP packets. If after a certain time no RTP packets are transferred in a connection then such an instance can release the call. Typically after 30secs a connection is released if no RTP streams are detected. Open the "Media Trace" of the connection and check if there are remarkable differences between the amount of sent and received or lost RTP packets. Actions: See "Quality of Service QoS problem" below.
Data Transfer
Equipment

→ Top

Solve "Quality of Service QoS" QoS-Problems

→ Top

Introduction to QoS-Problems

Note

In most cases, QoS-problems can only be found and solved by means of an exclusion procedure.

It is paramount that the customer/user knows that QoS-problems are difficult to track down and to solve. It's nerve-wracking and it is time consuming.

Solving QoS-problems often requires the cooperation and active co-testing from the customer/user with the support personnel! The active help of the customer/user is needed in most cases, e.g. by executing test connections.

The QoS-problem type covers the following erroneous conditions:

No voice transmission in one or both directions from the beginning of the connection
Bad voice quality during the connection

Naming and characteristics of QoS-problem:

One/No-Way Connection:

There is no speech transmission in one or both directions from beginning of the connection:

Silence (Possible reason: Mostly due to no or blocked RTP data transmission)

Glitch Connection:

There is speech transmission but it is disturbed:

Crackle, clicking (Possible reason: small packet loss, jitter)
Short interruption (Possible reason: bigger packet loss)
Ouw-ing (Possible reason: jitter, transcoding)
Echo (Possible reason: jitter, big delay)

The source of the QoS-problems are all too often somewhere in the data transmission "D Data Transfer" layer (but sometimes they are surprisingly simple):

The microphone or loadspeaker in the telephone handset defect
Volume configuration in the telephone set wrong
Telephone defect
The company Intranet is not made ready for VoIP
Any device in the "D - Data Transfer" layer

→ Top

1st Step: Interview the User

1 Step: Interview the user carefully and identify the type of QoS-problem

Get all information from the user:

Occurs the the QoS-problem with all peers or just with the given B peer?
Hint:

If the problem occurs only with the B peer then this is a strong indication that something is wrong on the B side!
Is there no voice transmission, neither from A->B nor B->A?
→ Type of QoS-problem: "No-Way Connection"
Is there voice transmission from A->B (B hears you) but none from B->A (you don't hear B)?
→ Type of QoS-problem: "One-Way Connection A->B"
Is there voice transmission from B->A (you hear B) but none from A->B (B doesn't hear you)?
→ Type of QoS-problem: "One-Way Connection B->A"
Are there during the connection crackle, clicking, short interruptions, uow-ing in the voice transmission for both sides?
→ Type of QoS-problem: "Glitch Connection"
Are there during the connection crackle, clicking, short interruptions, uow-ing in the voice transmission from A->B?
→ Type of QoS-problem: "Glitch Connection A->B"
Are there during the connection crackle, clicking, short interruptions, uow-ing in the voice transmission from B->A?
→ Type of QoS-problem: "Glitch Connection B->A"
Uses the user an ISDN or DECT telephone behind an ISDN-PBX? Does the user have sharp clicking glitches in a regular or irregular interval? Do experience all users behind this ISDN-PBX this clicking?
Remember :

This points to a synchronization problem of the ISDN-PBX!
Is one peer A or B a mobile user?
Remember:

Mobile networks often have QoS-problems on the wireless links between the base station and the mobile device!

Action:

→ Cross check the users information by checking the media transfer statistics of the affected connection, see "2 Step" below!

→ Top

2nd Step: Localize the QoS-Problem

Note

It is very important that the supporter is aware of of the localization of the problem.
QoS-problems in the range of the "2 Internet Service Provider ISP" or "3 Telephony Provider" will affect usually a lot of users immediately.

1 Step: Check the "Big Picture"

	Customer	Internet ISP	Telephony Provider
Telephony
Data Transfer	Check with the ISP where the user is connected to if there are outages in: the ISP IP network Actions: → Inform immediately the Telephone providers support or alarming organization. → If yes, just wait until the outage is solved	Check with the ISP where the VoIP System is connected to if there are outages in: the ISP IP network relevant national and/or international IP network Actions: → Inform immediately the Telephone providers support or alarming organization. → If yes, just wait until the outage is solved	Check with the IT responsible of the IP network where the VoIP System is attached to: Are there known outages in the IP network where the VoIP System is attached to? Is there a large scale QoS-problem? Are users affected which are located: in a certain private IP network of the telephony provider? at a definable tenant? Actions: → Inform immediately the Telephone providers support or alarming organization. → If the VoIP System is located in a pure private IP network then contact immediately the IT responsible or IT emergency organization. → If yes, just wait until the outage is solved
Equipment

2 Step: Identify the disturbed transmission direction from the VoIP Switch's view

This identification bases upon the VoIP System setting that all media streams are routed via the MediaServer of the VoIP Switch. The MediaServer collects statistic information about all media stream that are routed through it. These statistics can help to identify the source of the QoS-problem.

Search in the "Call Data" the CDR of 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
Get the RTP statistics of this connection, click Button [ Media Trace ]
If there are no data in the "Media Trace" contained then the media stream is not routed via the MediaServer of the VoIP Switch. See below how to force the routing via the MediaServer.

Depending of the identified QoS-problem type analyze the RTP statistics detail, see below

If the media stream are not routed by default via MediaServer the supporter can force it for an account via the ConfigCenter:

Menu "Account"

Select the customers account

Tab "Advanced"

Set "Use always MediaServer" to "Yes"

Note

By forcing the media stream through the MediaServer the routing of the RTP packets through the IP networks changes!
If the QoS-problem disappears when forced via MediaServer and reappears when switched back then this is a strong indication that something is wrong in the direct IP routing path between the customer/user and the peer device.

→ Top

Localize "No-Way Connection" and Possible Actions

"No-Way Connection":

No voice transmission, neither from A->B nor B->A

Knowhow background:

May occur during commissioning of the customer connection for VoIP
May occur when the telephony provider introduce now IP networks for new telephony users
May occur when the Internet service provider or telephony provider modify the IP routing
Customer firewall policies block IP range or UDP port range
The peer devices negotiate not the same codec
May occur when IP devices are defect
User device defect

	Customer	Internet ISP	Telephony Provider
Telephony
Data Transfer			Assumption: The problem reporting user/customer shall be the A leg. 1st: Check if the negotiated "codec" are correct for both peers. Check in the SDP information if the selected codec of the leg B side is in the offered list of leg A The B side codec must be within the codec list of side A Possible problems: ouw-ing, No-Way or One-Way connection Actions: → If the B side codec is not within the codec list of side A then check the configuration of the peer device B. → Check the configuration of the device A why the codec of side B is not in its list. → Consider a firmware upgrade of either device! 2nd: Check if the negotiated IP address and UDP ports are not blocked by any firewall. Check in the SDP information if the displayed IP addresses and UDP ports of the leg A and B are not blocked by any firewall Possible problems: No-Way or One-Way connection Actions: → Adjust the customers firewall policies → Adjust the usable UDP port range in the customer peer device 3rd: Check the `"rtp data"` records if the RTP transfer from and to the user/customer is not working: Are there are no (or few) received packets from the user? Are there packets sent toward the user? → If `Leg A "rec"=0` and `Leg A "snt">0`: no packets received from A but packets were sent toward A. Actions: → If there is a gateway on the user/customer side which is provided from the Telephony provider then check the correct working of this gateway. → The user or customer IT responsible must check if the Internet or access to the Telephony network is ok. → The user or customer IT responsible must check if the access router or Firewall are ok (no blocking policies, VoIP ALG off, ...). → The user or customer IT responsible must check if its IT infrastructure is ok (no faulty IP switches, routers, ...). → The user or customer PBX responsible must check if the ISDN- or IP-PBX is working correctly. → The user must check if the telephone device is ok. 4th: Check the `"rtp data"` records if the RTP transfer from and to the PSTN is not working: Are there are no (or few) received packets from the PSTN? → Are there packets sent toward the PSTN? → If `Leg B "rec"=0` and `Leg B "snt">0`: no packets received from B but packets were sent toward B Actions: → The supporter must inform immediately the telephony provider support or IT emergency organization. 5th: Check the `"rtp data"` records if the RTP handling in the VoIP Switch MediaServer is not working: Are there are packets received from the PSTN but not sent toward the user? → If `Leg B "rec">0` and `Leg A "snt"=0`: packets from B received but no packets sent toward A Are there are packets received from the user but not sent toward the PSTN? → If `Leg A "rec">0` and `Leg B "snt"=0`: packets from A received but no packets sent toward B Actions: → The supporter must inform immediately the telephony provider support!
Equipment

→ Top

Localize "One-Way Connection `A->B`" and Possible Actions

"One-Way Connection A->B":

B hears A but A doesn't hear B

Knowhow background:

May occur during commissioning of the customer connection for VoIP
May occur when the telephony provider introduce now IP networks for new telephony users
May occur when the Internet service provider or telephony provider modify the IP routing
Customer firewall policies block IP range or UDP port range
The peer devices negotiate not the same codec
May occur when IP devices are defect
User device defect

	Customer	Internet ISP	Telephony Provider
Telephony
Data Transfer			Assumption: The problem reporting user/customer shall be the A leg. 1st: Check if the negotiated "codec" are correct for both peers. Check in the SDP information if the selected codec of the leg B side is in the offered list of leg A The B side codec must be within the codec list of side A Possible problems: ouw-ing, No-Way or One-Way connection Actions: → If the B side codec is not within the codec list of side A then check the configuration of the peer device B. → Check the configuration of the device A why the codec of side B is not in its list. → Consider a firmware upgrade of either device! 2nd: Check if the negotiated IP address and UDP ports are not blocked by any firewall. Check in the SDP information if the displayed IP addresses and UDP ports of the leg A and B are not blocked by any firewall Possible problems: No-Way or One-Way connection Actions: → Adjust the customers firewall policies → Adjust the usable UDP port range in the customer peer device 3rd: Check the `"rtp data"` records if the RTP transfer from the PSTN is not working: Are there are no (or few) received packets from the PSTN? → If `Leg B "rec"=0`: no packets received from the PSTN. Actions: → The supporter must inform immediately the telephony provider support or IT emergency organization. 4th: Check the `"rtp data"` records if the RTP transfer to the user/customer is working: Are there are received packets from the PSTN and sent toward the user? → If `Leg B "rec">0` and `Leg A "snt">0`: packets were received from the PSTN and sent toward the user. Actions: → If there is a gateway on the user/customer side which is provided from the Telephony provider then check the correct working of this gateway. → The user or customer IT responsible must check if the Internet or access to the Telephony network is ok. → The user or customer IT responsible must check if the access router or Firewall are ok (no blocking policies, VoIP ALG off, ...). → The user or customer IT responsible must check if its IT infrastructure is ok (no faulty IP switches, routers, ...). → The user or customer PBX responsible must check if the ISDN- or IP-PBX is working correctly. → The user must check if the telephone device is ok. 5th: Check the `"rtp data"` records if the RTP handling in the VoIP Switch MediaServer is not working: Are there are packets received from the PSTN but not sent toward the user? → If `Leg B "rec">0` and `Leg A "snt"=0`: packets were received from the PSTN but not sent toward the user Actions: → The supporter must inform immediately the telephony provider support!
Equipment

→ Top

Localize "One-Way Connection `B->A`" and Possible Actions

"One-Way Connection B->A":

A hears B but B doesn't hear A

Knowhow background:

May occur during commissioning of the customer connection for VoIP
May occur when the telephony provider introduce now IP networks for new telephony users
May occur when the Internet service provider or telephony provider modify the IP routing
Customer firewall policies block IP range or UDP port range
The peer devices negotiate not the same codec
May occur when IP devices are defect
User device defect

	Customer	Internet ISP	Telephony Provider
Telephony
Data Transfer			Assumption: The problem reporting user/customer shall be the A leg. 1st: Check if the negotiated "codec" are correct for both peers. Check in the SDP information if the selected codec of the leg B side is in the offered list of leg A The B side codec must be within the codec list of side A Possible problems: ouw-ing, No-Way or One-Way connection Actions: → If the B side codec is not within the codec list of side A then check the configuration of the peer device B. → Check the configuration of the device A why the codec of side B is not in its list. → Consider a firmware upgrade of either device! 2nd: Check if the negotiated IP address and UDP ports are not blocked by any firewall. Check in the SDP information if the displayed IP addresses and UDP ports of the leg A and B are not blocked by any firewall Possible problems: No-Way or One-Way connection Actions: → Adjust the customers firewall policies → Adjust the usable UDP port range in the customer peer device 3rd: Check the `"rtp data"` records if the RTP transfer from the user is not working: Are there are no (or few) received packets from the user? → If `Leg A "rec"=0`: no packets received from the user Actions: → If there is a gateway on the user/customer side which is provided from the Telephony provider then check the correct working of this gateway. → The user or customer IT responsible must check if the Internet or access to the Telephony network is ok. → The user or customer IT responsible must check if the access router or Firewall are ok (no blocking policies, VoIP ALG off, ...). → The user or customer IT responsible must check if its IT infrastructure is ok (no faulty IP switches, routers, ...). → The user or customer PBX responsible must check if the ISDN- or IP-PBX is working correctly. → The user must check if the telephone device is ok. 4th: Check the `"rtp data"` records if the RTP transfer to the PSTN is not working: Are there packets sent toward the PSTN? → If `Leg A "rec">0` and `Leg B "snt">0`: packets were received from the user but not sent toward the PSTN Actions: → The supporter must inform immediately the telephony provider support or IT emergency organization. 5th: Check the `"rtp data"` records if the RTP handling in the VoIP Switch MediaServer is not working: Are there are packets received from the user but not sent toward the PSTN? → If `Leg A "snt">0` and `Leg B "snt"=0`, Actions: → The supporter must inform immediately the telephony provider support!
Equipment

→ Top

Localize "Glitch Connection" and Possible Actions

"Glitch Connection":

The voice transmission from A->B and B->A is disturbed

Knowhow background:

May occur when the customers Intranet is not optimized for VoIP
The peer devices negotiate not the same codec
May occur when IP devices are defect
User device defect

	Customer	Internet ISP	Telephony Provider
Telephony
Data Transfer			Assumption: The problem reporting user/customer shall be the A leg. 1st: Check if the negotiated "codec" are correct for both peers. Check in the SDP information if the selected codec of the leg B side is in the offered list of leg A: The B side codec must be within the codec list of side A Possible problems: ouw-ing, No-Way or One-Way connection Actions: → If the B side codec is not within the codec list of side A then check the configuration of the peer device B. → Check the configuration of the device A why the codec of side B is not in its list. → Consider a firmware upgrade of either device! 2nd: Check the `"rtcp data"` and `"rtp data"` records from and to the user/customer: Check the `"rtcp data"` (statistical data delivered from the device): `"lost>0"`: Device A claimed not to receive all packets Possible problems: crackle, short interruptions `"jitter>0"`: Device A claimed to receive packets delayed or wavering (if the jitter values are different then wavering) Possible problems: crackle, short interruptions, echo, ouw-ing Check the `"rtp data"` (statistical data from the VoIP Switch): `"rec"` not equal `"snt"`: The numbers of received `"rec"` and sent `"snt"` must be more or less equal since the last report. Possible problems: crackle, short interruptions `"cpkl>0.1"`: The cumulated packet loss `"cpkl"` should be smaller than `"<0.1"`. Possible problems: crackle, bigger interruptions Actions: → If there is a gateway on the user/customer side which is provided from the Telephony provider then check the correct working of this gateway. → The user or customer IT responsible must check if the Internet or access to the Telephony network is ok. → The user or customer IT responsible must check if its IT infrastructure is ok (no faulty IP switches, routers, ...). → The user or customer PBX responsible must check if IP-PBX is working correctly. → The user must check if the telephone device is ok. 3rd: Check the `"rtcp data"` and `"rtp data"`records from and to the PSTN is not working: Check the `"rtcp data"` (statistical data delivered from the device): `"lost>0"`: Device B claimed not to receive all packets. Possible problems: crackle, short interruptions `"jitter>0"`: Device B claimed to receive packets delayed or wavering (if the jitter values are different then wavering). Possible problems: crackle, short interruption, echo, ouw-ing Check the `"rtp data"` (statistical data from the VoIP Switch): `"rec"` not equal `"snt"`: The numbers of received `"rec"` and sent `"snt"` must be more or less equal since the last report Possible problems: crackle, short interruption `"cpkl>0.1"`: The cumulated packet loss `"cpkl"` should be smaller than `"<0.1"` Possible problems: crackle, bigger interruptions Actions: → If there are no similar problems in the big picture then the problem lies presumably in the network of side B. → If there are similar problems in the big picture then the supporter must inform immediately the telephony provider support or IT emergency organization.
Equipment

→ Top

Localize "Glitch Connection `A->B`" and Possible Actions

"Glitch Connection A->B":

The voice transmission from A->B is disturbed. B claims to hear A with bad quality.

Knowhow background:

May occur when the customers Intranet is not optimized for VoIP
May occur when IP devices are defect
User device defect

	Customer	Internet ISP	Telephony Provider
Telephony
Data Transfer			Assumption: The problem reporting user/customer shall be the A leg. 1st: Check if the negotiated "codec" are correct for both peers. Check in the SDP information if the selected codec of the leg B side is in the offered list of leg A: The B side codec must be within the codec list of side A Possible problems: ouw-ing, No-Way or One-Way connection Actions: → If the B side codec is not within the codec list of side A then check the configuration of the peer device B. → Check the configuration of the device A why the codec of side B is not in its list. → Consider a firmware upgrade of either device! 2nd: Check the `"rtp data"` records if the RTP transfer to the PSTN is correctly working: Check the `"rtp data"` (statistical data from the VoIP Switch) toward the PSTN: `Leg A "rec"` not equal `Leg B "snt"`: The numbers of received `"rec"` and sent `"snt"` must be more or less equal since the last report. Possible problems: crackle, short interruptions Actions: → If the received packets are very different to the sent ones then the supporter must inform immediately the telephony provider support or IT emergency organization. → If the received packets are quite equal to the sent ones then the problem must be on the B side
Equipment

→ Top

Localize "Glitch Connection `B->A`" and Possible Actions

"Glitch Connection B->A":

The voice transmission from B->A is disturbed. A claims to hear B with bad quality.

Knowhow background:

May occur when the customers Intranet is not optimized for VoIP
May occur when IP devices are defect
User device defect

	Customer	Internet ISP	Telephony Provider
Telephony
Data Transfer			Assumption: The problem reporting user/customer shall be the A leg. 1st: Check if the negotiated "codec" are correct for both peers. Check in the SDP information if the selected codec of the leg B side is in the offered list of leg A: The B side codec must be within the codec list of side A Possible problems: ouw-ing, No-Way or One-Way connection Actions: → If the B side codec is not within the codec list of side A then check the configuration of the peer device B. → Check the configuration of the device A why the codec of side B is not in its list. → Consider a firmware upgrade of either device! 2nd: Check the `"rtp data"` records if the RTP transfer to the user/customer is correctly working: Check the `"rtp data"` (statistical data from the VoIP Switch) toward the user/customer: `Leg B "rec"` not equal `Leg A "snt"`: The numbers of received `"rec"` and sent `"snt"` must be more or less equal since the last report. Possible problems: crackle, short interruptions Actions: → If the received packets are very different to the sent ones then the supporter must inform immediately the telephony provider support or IT emergency organization. 3rd: Check the `"rtcp data"` records from the user/customer: Check the `"rtcp data"` (statistical data delivered from the device): `"lost>0"`: Device A claimed not to receive all packets Possible problems: crackle, short interruptions `"jitter>0"`: Device A claimed to receive packets delayed or wavering (if the jitter values are different then wavering) Possible problems: crackle, short interruptions, echo, ouw-ing Actions: → If there is a gateway on the user/customer side which is provided from the Telephony provider then check the correct working of this gateway. → The user or customer IT responsible must check if the Internet or access to the Telephony network is ok. → The user or customer IT responsible must check if its IT infrastructure is ok (no faulty IP switches, routers, ...). → The user or customer PBX responsible must check if IP-PBX is working correctly. → The user must check if the telephone device is ok.
Equipment

→ Top

Solve "Voice Glitches with ISDN-PBX" Problem

This problem type covers the following erroneous conditions:

Bad speech quality in an ISDN-PBX environment
Glitches in the voice transmission, it "clicks"

ISDN-PBX environment usually provide an excellent voice quality. In an VoIP environment this excellent voice quality can be only maintained if the ISDN-PBX can synchronize with high precision clock source.

1 Step: Check the ISDN reference clock

	Customer	Internet ISP	Telephony Provider
Telephony
Data Transfer
Equipment	Checks: Does the ISDN-PBX take its clock reference from a high precision clock? Actions: → Make sure the ISDN-PBX takes its reference clock from a high precision source. → Use an ISDN-Gateway which provides a high precision clock.

→ Top

Solve "Special Telephony" Problem

→ Top

Solve "FAX Transmission" Problem

This problem type covers the following erroneous conditions:

FAX transmission doesn't start
FAX transmission is dropped
The transmitted document is incomplete

Note

If the FAX is connected to an IP-PBX then FAX problems must be solved with the responsible of the IP-PBX.

In a VoIP environment FAX no longer achieve the same degree of reliability as before in an analogue or ISDN one. The FAX reliability depends on various factors such as the type of device, device settings and the way the device is connected to the IP network. It depends also on the quality of the transmitter and receiver of the peer FAX devices. Getting all these factors together a transmission may not even start or dropped unexpectedly. The transmitted documents may be incomplete.

The users must expect increasing difficulties in the future, especially for international transmissions.

1 Step: Check the FAX device configuration

	Customer	Internet ISP	Telephony Provider
Telephony
Data Transfer
Equipment	Check: the configuration of the FAX device Actions: → Adjust the FAX device configuration: Reduce the transmission speed to max. 9600bds. Switch OFF the error correction as e.g. EMC If the device offers a "VoIP mode" then experiment with it and check if the results are better.

2 Step: Check the FAX transmission configuration of the gateway

	Customer	Internet ISP	Telephony Provider
Telephony
Data Transfer
Equipment	Depending on the quality of the IP network the supporter and/or administrator of the gateway can experiment with the FAX transmission protocol of the gateway device. Checks: Check with the Telephony provider if there are recommendations or directives which type of FAX transmission protocols are to use, e.g.: In band transmission with codec G.711alaw or G.711ulaw Out band transmission with T.38 Check the configuration of the gateway device Actions: → If the user/customer has a good quality IP network and the Telephone provider allows it then try: "In band transmission with codec G.711" → If the user/customer has a lower quality IP network and the Telephone provider allows it then try: "Out band transmission with T.38"

→ Top

Solve "DECT Multi-Cell with ISDN-PBX" Problem

This problem type covers the following erroneous conditions:

Hand over from cell to cell is not working
Bad speech quality

Note

If the DECT Multi-Cell system is connected to an IP-PBX then DECT problems must be solved with the responsible of the IP-PBX.

DECT-Multi-Cell systems connected to an ISDN-PBX which is working with in a VoIP environment experience special issues. Most issues are interconnected with accuracy of the synchronization clock of the ISDN-PBX. If this synchronization clock is not especially precise then the reference clock of the DECT-Multi-Cell system will have problems as described above.

1 Step: Check the ISDN reference clock

	Customer	Internet ISP	Telephony Provider
Telephony
Data Transfer
Equipment	Checks: Does the ISDN-PBX take its clock reference from a high precision clock? Actions: → Make sure the ISDN-PBX takes its reference clock from a high precision source. → Use an ISDN-Gateway which provides a high precision clock.

→ Top

@@ Line 155: / Line 155: @@
 #:
 # Check "RuleSet":
-#: Check if a RuleSet in the account or address prevents the user from doing outgoing or receiving calls.
+#: Check if a selected RuleSet in the account or address configuration prevents the user from doing outgoing or receiving calls.
 #:
 # Check "Call Forwards" or "Call Rejecting":
@@ Line 210: / Line 210: @@
 :* Account or telephone numbers blocked on the VoIP switch
 :* Telephone number ranges not correctly ported to the telephony provider
+:* Telephone number ranges not completely configured on the VoIP Switch
 :* Wrong incoming telephone number signaling
 :* Internet access fails
@@ Line 235: / Line 236: @@
 :* Account or telephone numbers blocked on the VoIP switch
 :* Telephone number ranges not correctly ported to the telephony provider
+:* Telephone number ranges not completely configured on the VoIP Switch
 :* The company Firewall and/or SBC VoIP ALG interferes with the SIP signaling or needed IP ports are blocked.
 :* Internet access fails
@@ Line 258: / Line 260: @@
 :* Public account and/or public telephone numbers blocked on the VoIP switch
 :* Public telephone number ranges not correctly ported to the telephony provider
+:* Telephone number ranges not completely configured on the VoIP Switch
 :* Private account and/or private telephone numbers blocked on the VoIP switch
 :* Provisioning of the SIP devices out of the AdminCenter
@@ Line 273: / Line 276: @@
 {{ToTop | SupportUserProblemBigPicture }} <!-------------------------------------------------------->
-= Step 4: Check the Big Picture =
+= Step 4: Check the "Big Picture" =
 At this point the supporter should get aware if the problem is limited to this user or if it could be large scale problem within the VoIP System.
@@ Line 630: / Line 633: @@
 {{ToTop | SupportUserProblemQos }} <!-------------------------------------------------------------->
-== Solve "Quality of Service QoS" Problem ==
+== Solve "Quality of Service QoS" QoS-Problems ==
-This problem type covers the following erroneous conditions:
-:* Bad voice quality due to glitches, interruptions, clicking, uow-ing during the connection
-:* No voice transmission in one direction from the beginning of the connection
-:* No voice transmission in both directions from the beginning of the connection
-"Quality of Service QoS" problems are nasty ones and often difficult to fix. The source of the problems is all too often somewhere in the data transmission "D Data Transfer" layer (but sometimes they are surprisingly simple):
+{{ToTop | SupportUserProblemQosIntroduction }} <!-------------------------------------------------->
+=== Introduction to QoS-Problems ===
+{{Note |
+In most cases, QoS-problems can only be found and solved by means of an exclusion procedure.
+It is paramount that the customer/user knows that QoS-problems are difficult to track down and to solve. It's nerve-wracking and it is time consuming.
+Solving QoS-problems often requires the cooperation and active co-testing from the customer/user with the support personnel! The active help of the customer/user is needed in most cases, e.g. by executing test connections.
+}}
+The QoS-problem type covers the following erroneous conditions:
+:* No voice transmission in one or both directions from the beginning of the connection
+:* Bad voice quality during the connection
+Naming and characteristics of QoS-problem:<br>
+: '''One/No-Way Connection''':
+:: There is no speech transmission in one or both directions from beginning of the connection:
+::* Silence (Possible reason: Mostly due to no or blocked RTP data transmission)
+::
+: '''Glitch Connection''':
+:: There is speech transmission but it is disturbed:
+::* Crackle, clicking (Possible reason: small packet loss, jitter)
+::* Short interruption (Possible reason: bigger packet loss)
+::* Ouw-ing (Possible reason: jitter, transcoding)
+::* Echo (Possible reason: jitter, big delay)
+The source of the QoS-problems are all too often somewhere in the data transmission "D Data Transfer" layer (but sometimes they are surprisingly simple):
 :* The microphone or loadspeaker in the telephone handset defect
 :* Volume configuration in the telephone set wrong
@@ Line 644: / Line 676: @@
 :* The company Intranet is not made ready for VoIP
 :* Any device in the "D - Data Transfer" layer
-{{Note |
-Solving QoS-problems often requires the cooperation and active co-testing from the customer/user with the support personnel!<br>
-It is paramount that the customer/user knows that QoS-problems are difficult to track down and to solve. And it is time consuming.
-}}
@@ Line 661: / Line 687: @@
 Get all information from the user:<br>
 # Occurs the the QoS-problem with all peers or just with the given B peer?
-#: Remember :
+#: Hint:
 #: If the problem occurs only with the B peer then this is a strong indication that something is wrong on the B side!
 #:
 #:
 # Is there no voice transmission, neither from <tt>A->B</tt> nor <tt>B->A</tt>?
-#: &rarr; Type of QoS-problem: "No-Way Connection"
+#: &rarr; Type of QoS-problem: [[#SupportUserProblemQosLocalizeNoWay | "No-Way Connection" ]]
 #:
 #:
 # Is there voice transmission from <tt>A->B</tt> (B hears you) but none from <tt>B->A</tt> (you don't hear B)?
-#: &rarr; Type of QoS-problem: "One-Way Connection <tt>A->B</tt>"
+#: &rarr; Type of QoS-problem: [[#SupportUserProblemQosLocalizeOneWayAB | "One-Way Connection <tt>A->B</tt>" ]]
 #:
 #:
 # Is there voice transmission from <tt>B->A</tt> (you hear B) but none from <tt>A->B</tt> (B doesn't hear you)?
-#: &rarr; Type of QoS-problem:  "One-Way Connection <tt>B->A</tt>"
+#: &rarr; Type of QoS-problem:  [[#SupportUserProblemQosLocalizeOneWayBA | "One-Way Connection <tt>B->A</tt>"]]
 #:
 #:
-# Are there during the connection glitches, interruptions, clicking, uow-ing in the voice transmission for both sides?
+# Are there during the connection crackle, clicking, short interruptions, uow-ing in the voice transmission for both sides?
-#: &rarr; Type of QoS-problem: "Glitch Connection"
+#: &rarr; Type of QoS-problem: [[#SupportUserProblemQosLocalizeGlitch | "Glitch Connection" ]]
-#: Remember :
-#: Glitch : Packet loss, jitter
-#: Interruption: Packet loss
-#: ouw-ing : jitter, transcoding
 #:
 #:
-# Are there during the connection glitches, interruptions, clicking, uow-ing in the voice transmission from <tt>A->B</tt>?
+# Are there during the connection crackle, clicking, short interruptions, uow-ing in the voice transmission from <tt>A->B</tt>?
-#: &rarr; Type of QoS-problem: "Glitch Connection <tt>A->B</tt>"
+#: &rarr; Type of QoS-problem: [[#SupportUserProblemQosLocalizeGlitchAB | "Glitch Connection <tt>A->B</tt>" ]]
 #:
 #:
-# Are there during the connection glitches, interruptions, clicking, uow-ing in the voice transmission from <tt>B->A</tt>?
+# Are there during the connection crackle, clicking, short interruptions, uow-ing in the voice transmission from <tt>B->A</tt>?
-#: &rarr;  Type of QoS-problem: "Glitch Connection <tt>B->A</tt>"
+#: &rarr;  Type of QoS-problem: [[#SupportUserProblemQosLocalizeGlitchBA | "Glitch Connection <tt>B->A</tt>" ]]
 #:
 #:
-# Uses the user an ISDN or DECT telephone behind an ISDN-PBX? Does the user have sharp clicking glitches in a regular or irregular interval? Do have all users behind this ISDN-PBX those glitches?
+# Uses the user an ISDN or DECT telephone behind an ISDN-PBX? Does the user have sharp clicking glitches in a regular or irregular interval? Do experience all users behind this ISDN-PBX this clicking?
 #: Remember :
 #: This points to a [[#SupportUserProblemQosIsdnPbx | synchronization problem of the ISDN-PBX!]]
@@ Line 699: / Line 721: @@
 #:
 # Is one peer A or B a mobile user?
-#: Remember :
+#: Remember:
-#: That Mobile networks often have QoS-problems on the wireless links between the base station and the mobile device!
+#: Mobile networks often have QoS-problems on the wireless links between the base station and the mobile device!
+#:
+#:
 #:
 #:
 Action:
-:: &rarr; Cross check the users information by checking the media transfer statistics, see "2 Step" below
+:: &rarr; Cross check the users information by checking the media transfer statistics of the affected connection, see "2 Step" below!
@@ Line 712: / Line 736: @@
 === 2nd Step: Localize the QoS-Problem ===
-{{Note:
+{{Note |
-It is very important that the supporter is aware of of the localization of the problem. QoS-problems in the range of the "2 Internet Service Provider ISP" or "3 Telephony Provider" will affect usually a lot of users immediately.
+It is very important that the supporter is aware of of the localization of the problem.
+<br>
+QoS-problems in the range of the "2 Internet Service Provider ISP" or "3 Telephony Provider" will affect usually a lot of users immediately.
 }}
-{{Support_Step_Title | 1 | Check the Big Picture }}
+{{Support_Step_Title | 1 | Check the "Big Picture" }}
 {{Support_3x3
@@ Line 766: / Line 792: @@
 # Open the identified CDR
 #:
-# Get the RTP statistics of this connection: click {{Dialog_Button | Media Trace }}
+# Get the RTP statistics of this connection, click {{Dialog_Button | Media Trace }}
 #: If there are no data in the "Media Trace" contained then the media stream is not routed via the MediaServer of the VoIP Switch. See below how to force the routing via the MediaServer.
 #:
@@ Line 777: / Line 803: @@
 {{Navigation_List | 3 | Tab "Advanced" }}
 {{Navigation_List | 4 | Set "Use always MediaServer" to <tt>"Yes"</tt> }}
-Note:
+{{ Note |
 :* By forcing the media stream through the MediaServer the routing of the RTP packets through the IP networks changes!
-:* If the QoS-problem disappears when forced via MediaServer and reappears when switched back then this is a strong indication that something is wrong in the direct IP routing path between the users and the peer device.
+:* If the QoS-problem disappears when forced via MediaServer and reappears when switched back then this is a strong indication that something is wrong in the direct IP routing path between the customer/user and the peer device.
+}}
@@ Line 785: / Line 814: @@
 {{ToTop | SupportUserProblemQosLocalizeNoWay }} <!------------------------------------------------->
-==== Localize "No-Way Connection" ====
+==== Localize "No-Way Connection" and Possible Actions ====
+"No-Way Connection":<br>
+:* No voice transmission, neither from A->B nor B->A
+Knowhow background:<br>
+:* May occur during commissioning of the customer connection for VoIP
+:* May occur when the telephony provider introduce now IP networks for new telephony users
+:* May occur when the Internet service provider or telephony provider modify the IP routing
+:* Customer firewall policies block IP range or UDP port range
+:* The peer devices negotiate not the same codec
+:* May occur when IP devices are defect
+:* User device defect
 {{Support_3x3
 |width1=75 | width2=75 | width3=725 <!--max 875-->
 | d3=
-"No-Way Connection": No voice transmission, neither from A->B nor B->A
+Assumption:<br>
+The problem reporting user/customer shall be the A leg.
+<section begin=1stCodecCheck />
+'''1st:''' Check if the negotiated "codec" are correct for both peers.
+:* Check in the SDP information if the selected codec of the leg B side is in the offered list of leg A
+::* The B side codec must be within the codec list of side A
+::: Possible problems: ouw-ing, No-Way or One-Way connection
+: Actions:<br>
+: &rarr; If the B side codec is not within the codec list of side A then check the configuration of the peer device B.
+: &rarr; Check the configuration of the device A why the codec of side B is not in its list.
+: &rarr; Consider a firmware upgrade of either device!
+<section end=1stCodecCheck />
+<section begin=1stIpAddressPortCheck />
+'''2nd:''' Check if the negotiated IP address and UDP ports are not blocked by any firewall.
+:* Check in the SDP information if the displayed IP addresses and UDP ports of the leg A and B are not blocked by any firewall
+::: Possible problems: No-Way or One-Way connection
+: Actions:<br>
+: &rarr; Adjust the customers firewall policies
+: &rarr; Adjust the usable UDP port range in the customer peer device
+<section end=1stIpAddressPortCheck />
-(The user/customer shall be the A leg!)
-st: Check the <tt>"rtp data"</tt> records if the RTP transfer from and to the user/customer is not working:
+'''3rd:''' Check the <tt>"rtp data"</tt> records if the RTP transfer from and to the user/customer is not working:
 :* Are there are no (or few) received packets from the user?
 :* Are there packets sent toward the user?
 :: &rarr; If <tt>Leg A "rec"=0</tt> and <tt>Leg A "snt">0</tt>: no packets received from A but packets were sent toward A.
-Actions:<br>
+: Actions:<br>
 : &rarr; If there is a gateway on the user/customer side which is provided from the Telephony provider then check the correct working of this gateway.
 : &rarr; The user or customer IT responsible must check if the Internet or access to the Telephony network is ok.
@@ Line 807: / Line 873: @@
-nd: Check the <tt>"rtp data"</tt> records if the RTP transfer from and to the PSTN is not working:
+'''4th:''' Check the <tt>"rtp data"</tt> records if the RTP transfer from and to the PSTN is not working:
 :* Are there are no (or few) received packets from the PSTN? &rarr;
 :* Are there packets sent toward the PSTN?
 :: &rarr; If <tt>Leg B "rec"=0</tt> and <tt>Leg B "snt">0</tt>: no packets received from B but packets were sent toward B
-Actions:<br>
+: Actions:<br>
 : &rarr; The supporter must inform immediately the telephony provider support or IT emergency organization.
-rd: Check the <tt>"rtp data"</tt> records if the RTP handling in the VoIP Switch MediaServer is not working:
+'''5th:''' Check the <tt>"rtp data"</tt> records if the RTP handling in the VoIP Switch MediaServer is not working:
 :* Are there are packets received from the PSTN but not sent toward the user?
 :: &rarr; If <tt>Leg B "rec">0</tt> and <tt>Leg A "snt"=0</tt>: packets from B received but no packets sent toward A
 :* Are there are packets received from the user but not sent toward the PSTN?
 :: &rarr; If <tt>Leg A "rec">0</tt> and <tt>Leg B "snt"=0</tt>: packets from A received but no packets sent toward B
-Actions:<br>
+: Actions:<br>
 : &rarr; The supporter must inform immediately the telephony provider support!
 }}
@@ Line 828: / Line 894: @@
 {{ToTop | SupportUserProblemQosLocalizeOneWayAB }} <!---------------------------------------------->
-==== Localize "One-Way Connection <tt>A->B</tt> ====
+==== Localize "One-Way Connection <tt>A->B</tt>" and Possible Actions ====
+"One-Way Connection <tt>A->B</tt>":<br>
+:* B hears A but A doesn't hear B
+Knowhow background:<br>
+:* May occur during commissioning of the customer connection for VoIP
+:* May occur when the telephony provider introduce now IP networks for new telephony users
+:* May occur when the Internet service provider or telephony provider modify the IP routing
+:* Customer firewall policies block IP range or UDP port range
+:* The peer devices negotiate not the same codec
+:* May occur when IP devices are defect
+:* User device defect
 {{Support_3x3
 |width1=75 | width2=75 | width3=725 <!--max 875-->
 | d3=
-"One-Way Connection <tt>A->B</tt>": B hears A but A doesn't hear B
+Assumption:<br>
+The problem reporting user/customer shall be the A leg.
-(The user/customer shall be the A leg!)<br>
-st: Check the <tt>"rtp data"</tt> records if the RTP transfer from the PSTN is not working:
+<section begin=1stCodecCheck />
+'''1st:''' Check if the negotiated "codec" are correct for both peers.
+:* Check in the SDP information if the selected codec of the leg B side is in the offered list of leg A
+::* The B side codec must be within the codec list of side A
+::: Possible problems: ouw-ing, No-Way or One-Way connection
+: Actions:<br>
+: &rarr; If the B side codec is not within the codec list of side A then check the configuration of the peer device B.
+: &rarr; Check the configuration of the device A why the codec of side B is not in its list.
+: &rarr; Consider a firmware upgrade of either device!
+<section end=1stCodecCheck />
+<section begin=1stIpAddressPortCheck />
+'''2nd:''' Check if the negotiated IP address and UDP ports are not blocked by any firewall.
+:* Check in the SDP information if the displayed IP addresses and UDP ports of the leg A and B are not blocked by any firewall
+::: Possible problems: No-Way or One-Way connection
+: Actions:<br>
+: &rarr; Adjust the customers firewall policies
+: &rarr; Adjust the usable UDP port range in the customer peer device
+<section end=1stIpAddressPortCheck />
+'''3rd:''' Check the <tt>"rtp data"</tt> records if the RTP transfer from the PSTN is not working:
 :* Are there are no (or few) received packets from the PSTN?
 :: &rarr; If <tt>Leg B "rec"=0</tt>: no packets received from the PSTN.
-Actions:<br>
+: Actions:<br>
 : &rarr; The supporter must inform immediately the telephony provider support or IT emergency organization.
-nd: Check the <tt>"rtp data"</tt> records if the RTP transfer to the user/customer is working:
+'''4th:''' Check the <tt>"rtp data"</tt> records if the RTP transfer to the user/customer is working:
 :* Are there are received packets from the PSTN and sent toward the user?
 :: &rarr; If <tt>Leg B "rec">0</tt> and <tt>Leg A "snt">0</tt>: packets were received from the PSTN and sent toward the user.
-Actions:<br>
+: Actions:<br>
 : &rarr; If there is a gateway on the user/customer side which is provided from the Telephony provider then check the correct working of this gateway.
 : &rarr; The user or customer IT responsible must check if the Internet or access to the Telephony network is ok.
@@ Line 856: / Line 958: @@
-rd: Check the <tt>"rtp data"</tt> records if the RTP handling in the VoIP Switch MediaServer is not working:
+'''5th:''' Check the <tt>"rtp data"</tt> records if the RTP handling in the VoIP Switch MediaServer is not working:
 :* Are there are packets received from the PSTN but not sent toward the user?
 :: &rarr; If <tt>Leg B "rec">0</tt> and <tt>Leg A "snt"=0</tt>: packets were received from the PSTN but not sent toward the user
-Actions:<br>
+: Actions:<br>
 : &rarr; The supporter must inform immediately the telephony provider support!
 }}
@@ Line 867: / Line 969: @@
 {{ToTop | SupportUserProblemQosLocalizeOneWayBA }} <!---------------------------------------------->
-==== Localize "One-Way Connection <tt>B->A</tt> ====
+==== Localize "One-Way Connection <tt>B->A</tt>" and Possible Actions ====
+"One-Way Connection <tt>B->A</tt>":<br>
+:* A hears B but B doesn't hear A
+Knowhow background:<br>
+:* May occur during commissioning of the customer connection for VoIP
+:* May occur when the telephony provider introduce now IP networks for new telephony users
+:* May occur when the Internet service provider or telephony provider modify the IP routing
+:* Customer firewall policies block IP range or UDP port range
+:* The peer devices negotiate not the same codec
+:* May occur when IP devices are defect
+:* User device defect
 {{Support_3x3
 |width1=75 | width2=75 | width3=725 <!--max 875-->
 | d3=
-"One-Way Connection <tt>B->A</tt>": A hears B but B doesn't hear A
+Assumption:<br>
+The problem reporting user/customer shall be the A leg.
+<section begin=1stCodecCheck />
+'''1st:''' Check if the negotiated "codec" are correct for both peers.
+:* Check in the SDP information if the selected codec of the leg B side is in the offered list of leg A
+::* The B side codec must be within the codec list of side A
+::: Possible problems: ouw-ing, No-Way or One-Way connection
+: Actions:<br>
+: &rarr; If the B side codec is not within the codec list of side A then check the configuration of the peer device B.
+: &rarr; Check the configuration of the device A why the codec of side B is not in its list.
+: &rarr; Consider a firmware upgrade of either device!
+<section end=1stCodecCheck />
-(The user/customer shall be the A leg!)<br>
-st: Check the <tt>"rtp data"</tt> records if the RTP transfer from the user is not working:
+<section begin=1stIpAddressPortCheck />
+'''2nd:''' Check if the negotiated IP address and UDP ports are not blocked by any firewall.
+:* Check in the SDP information if the displayed IP addresses and UDP ports of the leg A and B are not blocked by any firewall
+::: Possible problems: No-Way or One-Way connection
+: Actions:<br>
+: &rarr; Adjust the customers firewall policies
+: &rarr; Adjust the usable UDP port range in the customer peer device
+<section end=1stIpAddressPortCheck />
+'''3rd:''' Check the <tt>"rtp data"</tt> records if the RTP transfer from the user is not working:
 :* Are there are no (or few) received packets from the user?
 :: &rarr; If <tt>Leg A "rec"=0</tt>: no packets received from the user
-Actions:<br>
+: Actions:<br>
 : &rarr; If there is a gateway on the user/customer side which is provided from the Telephony provider then check the correct working of this gateway.
 : &rarr; The user or customer IT responsible must check if the Internet or access to the Telephony network is ok.
@@ Line 888: / Line 1,026: @@
-nd: Check the <tt>"rtp data"</tt> records if the RTP transfer to the PSTN is not working:
+'''4th:''' Check the <tt>"rtp data"</tt> records if the RTP transfer to the PSTN is not working:
 :* Are there packets sent toward the PSTN?
 :: &rarr; If <tt>Leg A "rec">0</tt> and <tt>Leg B "snt">0</tt>: packets were received from the user but not sent toward the PSTN
-Actions:<br>
+: Actions:<br>
 : &rarr; The supporter must inform immediately the telephony provider support or IT emergency organization.
-rd: Check the <tt>"rtp data"</tt> records if the RTP handling in the VoIP Switch MediaServer is not working:
+'''5th:''' Check the <tt>"rtp data"</tt> records if the RTP handling in the VoIP Switch MediaServer is not working:
 :* Are there are packets received from the user but not sent toward the PSTN?
 :: &rarr; If <tt>Leg A "snt">0</tt> and <tt>Leg B "snt"=0</tt>,
-Actions:<br>
+: Actions:<br>
 : &rarr; The supporter must inform immediately the telephony provider support!
 }}
@@ Line 906: / Line 1,044: @@
 {{ToTop | SupportUserProblemQosLocalizeGlitch }} <!------------------------------------------------>
-==== Localize "Glitch" ====
+==== Localize "Glitch Connection" and Possible Actions ====
+"Glitch Connection":<br>
+:* The voice transmission from A->B and B->A is disturbed
+Knowhow background:<br>
+:* May occur when the customers Intranet is not optimized for VoIP
+:* The peer devices negotiate not the same codec
+:* May occur when IP devices are defect
+:* User device defect
 {{Support_3x3
 |width1=75 | width2=75 | width3=725 <!--max 875-->
 | d3=
+Assumption:<br>
+The problem reporting user/customer shall be the A leg.
-}}
+'''1st:''' Check if the negotiated "codec" are correct for both peers.
+:* Check in the SDP information if the selected codec of the leg B side is in the offered list of leg A:
+:: The B side codec must be within the codec list of side A
+::: Possible problems: ouw-ing, No-Way or One-Way connection
+: Actions:<br>
+: &rarr; If the B side codec is not within the codec list of side A then check the configuration of the peer device B.
+: &rarr; Check the configuration of the device A why the codec of side B is not in its list.
+: &rarr; Consider a firmware upgrade of either device!
+'''2nd:''' Check the <tt>"rtcp data"</tt> and <tt>"rtp data"</tt> records from and to the user/customer:
+:* Check the <tt>"rtcp data"</tt> (statistical data delivered from the device):
+:: <tt>"lost>0"</tt>: Device A claimed not to receive all packets
+::: Possible problems: crackle, short interruptions
+:: <tt>"jitter>0"</tt>: Device A claimed to receive packets delayed or wavering (if the jitter values are different then wavering)
+::: Possible problems: crackle, short interruptions, echo, ouw-ing
+:
+:* Check the <tt>"rtp data"</tt> (statistical data from the VoIP Switch):
+:: <tt>"rec"</tt> not equal <tt>"snt"</tt>: The numbers of received <tt>"rec"</tt> and sent <tt>"snt"</tt> must be more or less equal since the last report.
+::: Possible problems: crackle, short interruptions
+::  <tt>"cpkl>0.1"</tt>: The cumulated packet loss <tt>"cpkl"</tt> should be smaller than <tt>"<0.1"</tt>.
+::: Possible problems: crackle, bigger interruptions
+:
+: Actions:<br>
+: &rarr; If there is a gateway on the user/customer side which is provided from the Telephony provider then check the correct working of this gateway.
+: &rarr; The user or customer IT responsible must check if the Internet or access to the Telephony network is ok.
+: &rarr; The user or customer IT responsible must check if its IT infrastructure is ok (no faulty IP switches, routers, ...).
+: &rarr; The user or customer PBX responsible must check if IP-PBX is working correctly.
+: &rarr; The user must check if the telephone device is ok.
-{{ToTop | SupportUserProblemQosLocalizeGlitchAB }} <!---------------------------------------------->
-==== Localize "Glitch <tt>A->B</tt>" ====
-{{Support_3x3
+'''3rd:''' Check the <tt>"rtcp data"</tt> and <tt>"rtp data"</tt>records from and to the PSTN is not working:
-|width1=75 | width2=75 | width3=725 <!--max 875-->
+:* Check the <tt>"rtcp data"</tt> (statistical data delivered from the device):
-| d3=
+:: <tt>"lost>0"</tt>: Device B claimed not to receive all packets.
+::: Possible problems: crackle, short interruptions
+:: <tt>"jitter>0"</tt>: Device B claimed to receive packets delayed or wavering (if the jitter values are different then wavering).
+::: Possible problems: crackle, short interruption, echo, ouw-ing
+:
+:* Check the <tt>"rtp data"</tt> (statistical data from the VoIP Switch):
+:: <tt>"rec"</tt> not equal <tt>"snt"</tt>: The numbers of received <tt>"rec"</tt> and sent <tt>"snt"</tt> must be more or less equal since the last report
+::: Possible problems: crackle, short interruption
+:: <tt>"cpkl>0.1"</tt>: The cumulated packet loss <tt>"cpkl"</tt> should be smaller than <tt>"<0.1"</tt>
+::: Possible problems: crackle, bigger interruptions
+:
+: Actions:<br>
+: &rarr; If there are '''no''' similar problems in the big picture then the problem lies presumably in the network of side B.
+: &rarr; If there are '''similar''' problems in the big picture then the supporter must inform immediately the telephony provider support or IT emergency organization.
 }}
@@ Line 929: / Line 1,117: @@
-{{ToTop | SupportUserProblemQosLocalizeGlitchBA }} <!---------------------------------------------->
+{{ToTop | SupportUserProblemQosLocalizeGlitchAB }} <!---------------------------------------------->
-==== Localize "Glitch <tt>B->A</tt>" ====
+==== Localize "Glitch Connection <tt>A->B</tt>" and Possible Actions ====
+"Glitch Connection <tt>A->B</tt>":<br>
+:* The voice transmission from A->B is disturbed. B claims to hear A with bad quality.
+Knowhow background:<br>
+:* May occur when the customers Intranet is not optimized for VoIP
+:* May occur when IP devices are defect
+:* User device defect
 {{Support_3x3
 |width1=75 | width2=75 | width3=725 <!--max 875-->
 | d3=
+Assumption:<br>
+The problem reporting user/customer shall be the A leg.
+'''1st:''' Check if the negotiated "codec" are correct for both peers.
+:* Check in the SDP information if the selected codec of the leg B side is in the offered list of leg A:
+:: The B side codec must be within the codec list of side A
+::: Possible problems: ouw-ing, No-Way or One-Way connection
+:
+: Actions:<br>
+: &rarr; If the B side codec is not within the codec list of side A then check the configuration of the peer device B.
+: &rarr; Check the configuration of the device A why the codec of side B is not in its list.
+: &rarr; Consider a firmware upgrade of either device!
-}}
+'''2nd:''' Check the <tt>"rtp data"</tt> records if the RTP transfer to the PSTN is correctly working:
+:* Check the <tt>"rtp data"</tt> (statistical data from the VoIP Switch) toward the PSTN:
+:: <tt>Leg A "rec"</tt> not equal <tt>Leg B "snt"</tt>: The numbers of received <tt>"rec"</tt> and sent <tt>"snt"</tt> must be more or less equal since the last report.
+::: Possible problems: crackle, short interruptions
+:
+: Actions:<br>
+: &rarr; If the received packets are very different to the sent ones then the supporter must inform immediately the telephony provider support or IT emergency organization.
+: &rarr; If the received packets are quite equal to the sent ones then the problem must be on the B side
+}}
+{{ToTop | SupportUserProblemQosLocalizeGlitchBA }} <!---------------------------------------------->
+==== Localize "Glitch Connection <tt>B->A</tt>" and Possible Actions ====
+"Glitch Connection <tt>B->A</tt>":<br>
+:* The voice transmission from B->A is disturbed. A claims to hear B with bad quality.
+Knowhow background:<br>
+:* May occur when the customers Intranet is not optimized for VoIP
+:* May occur when IP devices are defect
+:* User device defect
-{{ToTop | SupportUserProblemQos }} <!----------------------------------------->
-=== Solve "" Problem ===
-{{Support_Step_Title | 1 | ???? }}
 {{Support_3x3
 |width1=75 | width2=75 | width3=725 <!--max 875-->
-| t3=
+| d3=
-Intro
+Assumption:<br>
+The problem reporting user/customer shall be the A leg.
-Check via ConfigCenter:
+'''1st:''' Check if the negotiated "codec" are correct for both peers.
-:* Does ?
+:* Check in the SDP information if the selected codec of the leg B side is in the offered list of leg A:
-:*
+:: The B side codec must be within the codec list of side A
-Actions:<br>
+::: Possible problems: ouw-ing, No-Way or One-Way connection
-:: &rarr;  Check
-:: &rarr; [[#SupportUserProblemDeviceNetwork | Check  ]]
 :
-}}
+: Actions:<br>
+: &rarr; If the B side codec is not within the codec list of side A then check the configuration of the peer device B.
+: &rarr; Check the configuration of the device A why the codec of side B is not in its list.
+: &rarr; Consider a firmware upgrade of either device!
+'''2nd:''' Check the <tt>"rtp data"</tt> records if the RTP transfer to the user/customer is correctly working:
+:* Check the <tt>"rtp data"</tt> (statistical data from the VoIP Switch) toward the user/customer:
+:: <tt>Leg B "rec"</tt> not equal <tt>Leg A "snt"</tt>: The numbers of received <tt>"rec"</tt> and sent <tt>"snt"</tt> must be more or less equal since the last report.
+::: Possible problems: crackle, short interruptions
+:
+: Actions:<br>
+: &rarr; If the received packets are very different to the sent ones then the supporter must inform immediately the telephony provider support or IT emergency organization.
+'''3rd:''' Check the <tt>"rtcp data"</tt> records from the user/customer:
+:* Check the <tt>"rtcp data"</tt> (statistical data delivered from the device):
+:: <tt>"lost>0"</tt>: Device A claimed not to receive all packets
+::: Possible problems: crackle, short interruptions
+:: <tt>"jitter>0"</tt>: Device A claimed to receive packets delayed or wavering (if the jitter values are different then wavering)
+::: Possible problems: crackle, short interruptions, echo, ouw-ing
+:
+: Actions:<br>
+: &rarr; If there is a gateway on the user/customer side which is provided from the Telephony provider then check the correct working of this gateway.
+: &rarr; The user or customer IT responsible must check if the Internet or access to the Telephony network is ok.
+: &rarr; The user or customer IT responsible must check if its IT infrastructure is ok (no faulty IP switches, routers, ...).
+: &rarr; The user or customer PBX responsible must check if IP-PBX is working correctly.
+: &rarr; The user must check if the telephone device is ok.
+}}

Difference between revisions of "Support user level2"

Latest revision as of 09:21, 9 October 2017

Contents

Introduction Support Level 2

Best Practice for Handling an User Problem

Step 1: Record the Customer's Data and Problem Description

Get the Customer's Data

Write down the Customer's Problem Description

Step 2: Cross Check the User Inputs

Step 3: Evaluate the User's VoIP Setup

VoIP Setup: Residential

VoIP Setup: Legacy ISDN PBX

VoIP Setup: IP PBX

VoIP Setup: vPBX

Step 4: Check the "Big Picture"

Step 5: Solve the Customer Problem

Solve "Device / Network / Configuration / Registration" Problems

Solve "Device Hardware & Firmware" Problem

Solve "Device Network" Problem

Solve "Registration" Problem

Solve "Connection" Problems

Solve "Quality of Service QoS" QoS-Problems

Introduction to QoS-Problems

1st Step: Interview the User

2nd Step: Localize the QoS-Problem

Localize "No-Way Connection" and Possible Actions

Localize "One-Way Connection A->B" and Possible Actions

Localize "One-Way Connection B->A" and Possible Actions

Localize "Glitch Connection" and Possible Actions

Localize "Glitch Connection A->B" and Possible Actions

Localize "Glitch Connection B->A" and Possible Actions

Solve "Voice Glitches with ISDN-PBX" Problem

Solve "Special Telephony" Problem

Solve "FAX Transmission" Problem

Solve "DECT Multi-Cell with ISDN-PBX" Problem

Navigation menu

Search

Localize "One-Way Connection `A->B`" and Possible Actions

Localize "One-Way Connection `B->A`" and Possible Actions

Localize "Glitch Connection `A->B`" and Possible Actions

Localize "Glitch Connection `B->A`" and Possible Actions