Handling Process
1.
I checked the IP phone version.
Found out that the IP phones
version was not up to date.
I suggested to the customer to
upgrade the IP phones to the latest software version.
2. I checked the
environment/topology where the calls were made.
The customer
was making conferences with external parties. This meant long duration calls and
a lot of bandwidth used.
3. I checked the codec negotiated by phones by
asking a wireshark trace.
I ***yzed the wireshark trace and
found out that the customer was using G.722 codec, which takes a lot of
bandwidth compared to G.729 for example. I suggested to the customer to change
the settings on the IP phones from G.722 to G.729A/B. You cand find this setting
on the IP phone web manangement page in the Advanced - > Media - > Voice
Codec Priority tab.
4. I checked if customer had any QoS policies
implemented.
I noticed in the wireshark trace that customer
sent back, that there were no COS or DSCP tagged packets.
I
checked the qos configuration on the IP PBX with these
commands:
[%eSpace U1980(config)]#show qos
mode
Vlan function: disable
====
Command executed success ! ====
[%eSpace U1980(config)]#show qos
rule
QoS Rule
Ruleid Rulename Protocoltype Beginport Endport
Vlanid Vlanpriortity Rfctype Rfcpriority
------ -------- ------------
--------- ------- ------ ------------- ------- -----------
0 ---
OTHER --- --- 0 0 ---
---
Rfcservertype
-------------
---
==== Command executed
success ! ====
There was no QoS configuration.
5.
After the customer updated the IP phones software version and changed the codec
to G.729A/B, the sound quality was back to normal.
Root Cause
1.
I checked the IP phone version.
2. I checked the environment/topology where
the calls were made.
3. I checked the codec negotiated by phones by asking a
wireshark trace.
4. I checked if customer had any QoS policies
implemented.
Suggestions
Always check the bandwidth requirenments for your needs and also
take QoS implementation into consideration.
