Collapse AllExpand All

2.25. Frequently asked Questions Previous topic Parent topic Child topic Next topic

  1. Question: Are HG 3500 gateways supported on the Hicom 300 H?
    Answer: No. Customers have to upgrade to HiPath 4000 V4 or higher in order to take advantage of integrated IP gateways.
  2. Question: Why does the HG 3500 require a static IP address?
    Answer: From an IP networking point of view the HG 3500 is a gateway/voice-router. Gateways/routers always require static IP addresses. This ensures that all IP devices always find their gateway/router without having to be reprogrammed constantly. Having dynamic IP addresses on gateways/routers does not make any practical sense.
  3. Question: Is the HG 3500 supported on IP distributed Access Points?
    Answer: Yes. The HG 3500 version is supported on IP distributed Access Points. Excessive delays that resulted from multiple TDM to IP conversions when IP users on the IP Access Points call IP users on other IP Access Points or IP users on the host are eliminated using DMCs.
  4. Question: Why do HG 3500 and HG 3575 not support DHCP?
    Answer: Consider HG 3500/3575 as a voice router. These voice routers must always be available and know each other. As is the case with IP router ports, it is useful to work with fixed IP addresses. For complete system availability, it is also better to avoid dependencies on DHCP and/or DNS servers.
  5. Question: Why does the HG 3500 not support the G.722 codec?
    Answer: There is absolutely no need for the HG 3500 to support G.722 because there is no wideband quality available on the TDM side; G.722 strictly works between IP clients and it is the clients that negotiate the codec type. The HG 3500 will pass the signaling between any IP clients that support G.722, enabling high quality voice.
  6. Question: Why is the default value for the jitter buffer set to 60 milliseconds on HG 3500/75? Can lower values also be set without leading to problems?
    Answer: The default setting should ensure that initial startup runs relatively smoothly. 60 ms is definitely too high for modern campus LAN installations that only use device connections at Layer-2 switch ports and have sufficient bandwidth reserves. A jitter buffer depth of 20 ms has been shown to be satisfactory. On the other hand, 60 ms may sometimes be too low for installations over WAN links with extremely low bandwidth and no reserve. Setting the jitter buffer depth too high causes an unnecessarily high voice delay. Setting it too low leads to poor transmission quality as a result of high packet loss rates. This poses problems particularly for fax, modem, and ISDN data connections.
  7. Question: The maximum value that can be set for the jitter buffer is 210 ms. I assume that the system works properly with this setting. Can I specify this value in my WAN tender specification as a carrier requirement?
    Answer: The system has no problems with a 210 ms jitter buffer. This setting can balance out an extremely high jitter value of up to 210 ms without impairing voice comprehension. It should be noted, however, that the size of the jitter buffer has a direct effect on voice delay. See also Section 1.4, “Voice Quality”. Voice delay (mouth-to-ear delay) is influenced by five elements:
    1. Packet size/sample size/the number of audio milliseconds per packet
      • Processing time on the receiving end
      • Transmission time in the LAN/WAN
      • Jitter buffer
      • Processing time on the receiving end
      Figure 3 Voice quality depending on delay illustrates user satisfaction in relation to the mouth-to-ear delay. Satisfaction drops dramatically at around 150 ms. Users start to notice interference at around 250 ms and become dissatisfied.
      Please note that a similar installation can also cause delays in trunk calls at the other end of the CO trunk. In other words, only one half of the tolerable delays may be caused by each end.
      The following table shows a couple of sample calculations (all values in ms)
      Sample size
      20
      60
      20
      20
      60
      60
      60
      20
      Transmission time in the LAN/WAN
      10
      10
      10
      40
      40
      40
      60
      0
      Processing time
      Send+receive direction
      32
      32
      32
      32
      32
      32
      32
      32
      Jitter buffer
      20
      20
      60
      60
      60
      120
      210
      210
      Mouth-to-ear delay
      82
      122
      122
      152
      192
      252
      362
      262
      It is not possible to achieve delays under 262 ms with a 210 ms jitter buffer.
  8. Question: Both the HG 3500 and the HG 3575 have a fixed MAC address for the Ethernet port assigned to the board. The IP addresses, however, are assigned from the system database on the basis of the board’s “PEN“. If I switch a HG 3500 in a particular slot with another board of the same type, the IP address is maintained from the IP network’s perspective. However, the MAC address to which the packets are sent changes. Doesn’t this mean that the new board cannot be reached on account of the modified MAC address until aging makes the ARP entries obsolete in the IP stacks?
    Answer: The standard solution for this problem which is principally an address resolution issue is also implemented on the HG 3500 and HG 3575 gateways. After activating the hardware interface, the gateway sends an ARP request “gratuitous ARP“ to the actual IP address. This way, all IP devices on the LAN segment learn the new IP <-> MAC address assignment.
  9. Question: We regularly encounter statistic overflow problems in a customer installation. Individual HG 3500/75 boards are temporarily taken out of service. This clears down all calls over these boards but does not have any other visible effect. What causes this problem and what can be done about it?
    Answer: A statistical evaluation of error messages is performed for the HG 3500/75 in the same way as for other boards. This also includes the loss of the signaling connection in HG 3575 and “bad quality“ messages for the HG 3500/75 payload connections.
    Poor IP connection quality between the HG 3500/75 gateways or the OpenScape 4000 central system and the HG 3575 over a sustained period can lead to a large number of error messages in a short space of time, which in the end causes a statistic overflow and a board reset.
    Resetting the board should prevent a temporary board fault from turning into a problem.
    If the fault clearly originates in the network, no improvements will be achieved by resetting the board.
    You can use the AMO PSTAT to increase the threshold values for the STMI and NCUI counters or deactivate the statistical evaluation entirely by setting the threshold values to zero.
    CHANGE-PSTAT:TYPE=CTRLTAB,LEVEL=BOARD,BOARD=NCUI,FAULT=1 or 2, MAXCOUNT=xxx;
    Stage 1 (COUNT1, counts pairs of in-service and out-of-service messages) and stage 2 (COUNT2, counts messages that could develop into a message flood) should also be taken into consideration.
    Separate counters are used for NCUI/STMI and NCUI2/STMI2 
    +----------+--------+----------+----------+----------+----------+----------+
! NCUI     ! COUNT1 !   Byte1  !      61  !      10  !       2  !       4  !
! STMI     +--------+----------+----------+----------+----------+----------+
!          ! COUNT2 !   Byte2  !      61  !       6  !       2  !       2  !
!          +--------+----------+----------+----------+----------+----------+
!          ! COUNT3 !   Byte3  !      21  !       10  !       2  !       4  !
!          +--------+----------+----------+----------+----------+----------+
!          ! COUNT4 !   Byte4  !      19  !       10  !       2  !       4  !
+----------+--------+----------+----------+----------+----------+----------+
! NCUI2    ! COUNT1 !   BYTE1  !     241  !      10  !       2  !       4  !
! STMI2     +--------+----------+----------+----------+----------+----------+
!          ! COUNT2 !   Byte2  !      241  !       6  !       2  !       2  !
!          +--------+----------+----------+----------+----------+----------+
!          ! COUNT3 !   Byte3  !      21  !       10  !       2  !       4  !
!          +--------+----------+----------+----------+----------+----------+
!          ! COUNT4 !   Byte4  !      19  !       10  !       2  !       4  !
+----------+--------+----------+----------+----------+----------+----------+
    Details on the AMO PSTAT can be found in the AMO description in the OpenScape 4000 Service Manual.
    Modifying the statistics prevents the boards from being reset when quality problems that affect the overall function of the system occur in the IP network. Your objective must be get these problems under control.
  10. Question: Where can I hear how packet loss concealment affects the G.711 or G.729 codec?
    The suggestion to provide acoustic samples in the electronic version of the handbook was rejected by Service and Sales because this information is not relevant for service technicians and sales managers. Sorry!
  11. Question: Which is the difference between TOSLAN, TOSSIGNL and TOSPL?
AMO SIPCO
TOSSIGNL
QoS value for the TCP stream from HSR > NCUIs
TOSPL
QoS value for the payload stream outgoing from the IPDA-STMI (HHS)
AMO STMIB
TOSLAN
QoS value for the TCP stream from NCUI > HSR
TOSPL
QoS value for the payload stream outgoing from the NCUI
AMO CGWB
TOSSIGNL
QoS value for the TCP stream from STMI > STMI (IP Trunking) or STMI > IP-Phone
TOSPL
QoS value for the payload stream outgoing from the STMI (HFA/IP Trunking)
Notes:
If MFS is used with IPDA functionality then the TOSPL (AMO SIPCO & AMO CWGB) must be the same.
The TOS values for the packets sent by the IP phone can be setup in the IP phone only.
${DocTitle}, ID: ${DocID}
© 03/2026 Mitel Networks Corporation. All rights reserved. Mitel and the Mitel logo are trademark(s) of Mitel Networks Corporation. Unify and associated marks are trademarks of Unify Software and Solutions GmbH & Co. KG. All other trademarks herein are the property of their respective owners.