Echo
-
whipps23
Re: Echo
QOS is applied on the network for the voice vlans. We are using All alcatel equipment end to end in our new environment. I thought about the carrier but we are getting the reports of calls sounding like they are in a tunnnel, trash can etc. even between IP touch phones on the same floor. We also have this report from calls to our old Avaya system.
I used the IP ticket viewer and the call quality is good from the scores we are getting. I do not know what BFI is though.
I thought it might be side tone.Thanks
I used the IP ticket viewer and the call quality is good from the scores we are getting. I do not know what BFI is though.
I thought it might be side tone.Thanks
-
stefan
Re: Echo
Hi,
please supply more info on common / crystal hardware , release etc......
To really check your network performance you need a network scan tool... like the Aviso tool from ALU and 2 test sets... it generates calls between the 2 sets/sites and after a few days.... presto... report on performance of the network....and maybe a indication for your problem....but since it is licensed
.... you need to start by checking the basics...but first let me ask you : does it also happen when 2 IP sets on the same floor call ??
1. check compression type of the communications
- check IP domain configuration (G711 is best quality !)
(check compression type / packitisation-time setup of your system)
2. check compressor board type configuration (config 1 0 -d)
(mcv xx / GIP 4 = 32 ms echo-cancellation, mada x / GIP 6 = 128 ms echo-cancellation)
and check config in MGR / 4760 !)
3. is your system clocked on public lines ? check with infocs (common HW!)
BFI = Bad Frame Interpolation
if a packet is lost or corrupted then a BFI is generated, the system interpolates lost and/or corrupted packets by using the previously received voice frames for increasing voice quality, the BFI proces is able to estimate how to build the missing packet.
BFI have impact on communications :
- 1 BFI = unnoticed
- 2 consecutive BFI : discrepancies
- 3 consecutive BFI : silence
If a packet arrives rapidly after silence, it generates a variation of decibels that will prompt a metallic sound....
(more info on BFI see ITU G113 - transmission impairments)
echo
often a problem with analog sets or analog public lines, digital sets may introduce echo by acoustic coupling (hands free/speaker option)
....
Hope it helps...
good luck !
Stefan
ACSE OTUC R5.x
ACSE 4760 R4.x
ACSE OXE R8.x
++++++++++++ RTFM ++++++++++++++++
please supply more info on common / crystal hardware , release etc......
To really check your network performance you need a network scan tool... like the Aviso tool from ALU and 2 test sets... it generates calls between the 2 sets/sites and after a few days.... presto... report on performance of the network....and maybe a indication for your problem....but since it is licensed
.... you need to start by checking the basics...but first let me ask you : does it also happen when 2 IP sets on the same floor call ??
1. check compression type of the communications
- check IP domain configuration (G711 is best quality !)
(check compression type / packitisation-time setup of your system)
2. check compressor board type configuration (config 1 0 -d)
(mcv xx / GIP 4 = 32 ms echo-cancellation, mada x / GIP 6 = 128 ms echo-cancellation)
and check config in MGR / 4760 !)
3. is your system clocked on public lines ? check with infocs (common HW!)
BFI = Bad Frame Interpolation
if a packet is lost or corrupted then a BFI is generated, the system interpolates lost and/or corrupted packets by using the previously received voice frames for increasing voice quality, the BFI proces is able to estimate how to build the missing packet.
BFI have impact on communications :
- 1 BFI = unnoticed
- 2 consecutive BFI : discrepancies
- 3 consecutive BFI : silence
If a packet arrives rapidly after silence, it generates a variation of decibels that will prompt a metallic sound....
(more info on BFI see ITU G113 - transmission impairments)
echo
often a problem with analog sets or analog public lines, digital sets may introduce echo by acoustic coupling (hands free/speaker option)
....
Hope it helps...
good luck !
Stefan
ACSE OTUC R5.x
ACSE 4760 R4.x
ACSE OXE R8.x
++++++++++++ RTFM ++++++++++++++++
-
cavagnaro
Re: Echo
That is only true if the network environment allows this. If the network has a lot of package loss or high delays or small bandwidth G711 will not work or will work bad hearing echo, or robot-like conversations.stefan wrote: - check IP domain configuration (G711 is best quality !)
To select a codec you have to analyze your network, for example if you choose G723 because it consumes less bandwidth and expect to work like a charm you must know that using this codec retransmissions are much frequent and on some networks as delay is high voice will not go, so you can choose then or use G729 or increase codec values for retransmissions.
So at the end you need to really understand how the network works and is compossed to select a correct codec and configuration.
Regards
Re: Echo
Is it really between two IP phones? Echo on straight (RTP) IP-IP connection sounds strange.whipps23 wrote: These are IP to IP calls
Which type of PSTN you have - analog(NDDI)/digital(PRI)?whipps23 wrote: and via the PSTN.
If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck.
Re: Echo
Usually echo is due to bad VoIP quality (big delays) but sometimes echo can be also due to the presence of analogue equipment between two communications. So in the case of the calls through the PSTN you should ask for your public provider to check their equipment.
As far as the VoIP issues in the same building these are due to poor network design. Few things that you can do to improve the quality is
1) Manage voice packets prioritization in your data equipment and then apply this number to your OXE.
2) Ask from your data provider to divide the bandwidth to two independent segments. One should be for voice and the other for data. Especially he should avoid any overflow of the data packets in the voice part. This should not create any problems when we are speaking about VoIP communications in the same LAN. This is usually for WLAN calls.
3) You have to manage in your router the incoming and outgoing queue to be as small as possible. Remember that if a big data packet is being waiting to be transmitted in the router queue all the Voice packets will waiting a considerable time.
4) Manage the router to divide the packets in small parts. These will assist in faster transmission of the packets.
5) Check your routers CPU utilization. It should not be more than 40%. If it is higher you could have delays in packets transmission and you will need a better router.
These are few things that by doing them you can improve the VoIP quality tremendously.
.
As far as the VoIP issues in the same building these are due to poor network design. Few things that you can do to improve the quality is
1) Manage voice packets prioritization in your data equipment and then apply this number to your OXE.
2) Ask from your data provider to divide the bandwidth to two independent segments. One should be for voice and the other for data. Especially he should avoid any overflow of the data packets in the voice part. This should not create any problems when we are speaking about VoIP communications in the same LAN. This is usually for WLAN calls.
3) You have to manage in your router the incoming and outgoing queue to be as small as possible. Remember that if a big data packet is being waiting to be transmitted in the router queue all the Voice packets will waiting a considerable time.
4) Manage the router to divide the packets in small parts. These will assist in faster transmission of the packets.
5) Check your routers CPU utilization. It should not be more than 40%. If it is higher you could have delays in packets transmission and you will need a better router.
These are few things that by doing them you can improve the VoIP quality tremendously.
.
-
iourid
Re: Echo
The fact that echo is sporadic points to QOS, however you may want to check the following.
There was an echo problem in comfort handsets (very small batch) for 4018,4028,4038,4068 0r 4039 that has been manufactured between June 2007 and April 2008; its date code (the last three digits of its 3GV reference) is between 723 and 814. Example: 3GV26043DBAA040810.
On internal call between set with suspected handset and set with OK handset, user with OK handset will hear his own voice.
The solution is to exchange handsets.
There was an echo problem in comfort handsets (very small batch) for 4018,4028,4038,4068 0r 4039 that has been manufactured between June 2007 and April 2008; its date code (the last three digits of its 3GV reference) is between 723 and 814. Example: 3GV26043DBAA040810.
On internal call between set with suspected handset and set with OK handset, user with OK handset will hear his own voice.
The solution is to exchange handsets.
-
robguez
Re: Echo
I hope I can help that I have same problem on the Echo's IP phones when there are outgoing calls on analog lines (PSTN or GSM Analog Gateway). phones digital and analog works well and is not heard the echo.
The network configuration is correct, this will be implemented VLAN, QoS, etc. ..
what is more worrying to me is happening with 3 different PBX.
OXE Release 8.0.1 12th and 8.0.1 17b
my Handset have date of manufacture of 824
I hope can guide
best regards
The network configuration is correct, this will be implemented VLAN, QoS, etc. ..
what is more worrying to me is happening with 3 different PBX.
OXE Release 8.0.1 12th and 8.0.1 17b
my Handset have date of manufacture of 824
I hope can guide
best regards

