Answer: NO, definitely not. It is always assumed that there must be a fixed relationship between a HG 3575 and a HG 3500 to transfer signaling data. However, signaling data comes directly from the central processor (via the SL 200 or SL 100 module). The HG 3500 is only responsible for payload transport. The number of HG 3500s required in the system depends solely on the traffic volume between the access points (total for all APs) and the central system.

Answer: HG 3500s are not allocated to any specific access points. If there are several HG 3500s in the system, then they share the overall traffic volume. HG 3500 seizure is performed cyclically in the system, i.e. the first connection is routed via the first HG 3500, the next via the second and so on. If an HG 3500 fails, all active calls over this board are interrupted. The board is then no longer seized for new calls. These new calls are then routed via the other HG 3500s, as capacity allows.

Answer: Hubs work in Ethernet’s classic “shared medium“ mode. All connected units share the total bandwidth. Jeder kann alles mithören. Nur einer kann zu einem Zeitpunkt senden. Voice communication is bidirectional. The data flow from A to B is the same size (expect using VAD) as the dataflow from B to A. As transmission is only possible from one unit at a time in shared medium mode, the send and receive direction each occupy the same share of the total bandwidth available. The use of layer 2 switches, which are nowadays often cheaper than hubs, decouples the connection media of the individual units. All units can simultaneously send and receive. The bandwidth (now available for each unit) can be used more efficiently.

Answer: The default setting should ensure that initial startup runs relatively smoothly. However, on account of the recurring problems encountered with autonegotiation, we strongly urge you to enter a fixed setting for both interface partners. It is essential to configure both interfaces - with the same values - at the same time. When using an autonegotiate interface with one that is fixed, the autonegotiate interface often fails to “negotiate“ to the fixed interface’s setting. Please also refer to the Note on page 652.

Answer: You can operate multiple OpenScape 4000 systems in the same network. In this case, the components’ IP addresses must not be used more than once and the capacity of the router or WAN connection must suffice for the entire bandwidth requirement.

Answer: The default values used for IPDA come from an internal standard that was implemented in all HG 35xx gateways. The interoperability problem has since come to light with the result that the company standard will be modified shortly. The default values can be modified at any time and modified in line with actual conditions in the customer network.

Answer: Yes but only in conjunction with priority tagging. In accordance with IEEE 802.1 p/q, tagging was introduced for IPDA to support priority tagging. If tagging is activated then the permanently preset priority bits of the various types of traffic are always set (see the last column of Table 3 “TOS values” in document “Gateways HG 3500 and HG 3575”). If tagging is active, the VLAN ID can also be set (default value is zero). VLAN ID is not supported without the set priority bits.

Answer: Yes. When the network mask is entered, a check is performed to determine whether the block of ones that has been set meets the minimum length required for the class of the address, i.e. 8 ones for Class A, 16 for B and 24 for C. If the number of ones is greater than the number required for the class, subnetting is activated.

Answer: No.

Answer: Payload survivability is designed as an emergency solution in the event of an IP network crash/malfunction. Only basic call functionality can be guaranteed. You must also take into consideration that signaling via IP must offer Quality of Service which is often not supported when using external narrowband WAN links together with data communication in existing installations.

Follow-up question: It cannot be that difficult for an ISDN PABX to route voice connections via a carrier network.

Answer: The systems are designed for it. However, in the case described above, the system must call itself via the CO and negotiate this as an internal call with the complete range of features - and this in itself is not an easy task.

Answer: The reason for the internal router and the additional address is due to signaling survivability. For signaling survivability, TCP layer packets which can no longer be transported via LAN must be delivered on another route, that is, the survivability path, before the supervision timer in the TCP expires. The IP destination addresses must remain the same for this, only the router involved can be switched. In the case of a “networked“ access point, the (default) LAN router is switched to the survivability router. This LAN router is not available in the case of a “direct link“ access point, as CC and AP are in the same LAN segment. You cannot switch from no router to a survivability router. Consequently, signaling survivability could not be offered for “direct link“. The only practical solution is to integrate the LAN router in the access point. Two IP addresses are therefore provided for a “direct link“ access point: the router port IP address at the OpenScape 4000 LAN segment and the signaling instance IP address in the AP “internal network“.

Answer: If the entire network is ideally dimensioned, if there is no packet loss and no significant packet propagation time during long-term measurements and if the network load (including the IPDA load) is moderate on all paths, then an IPDA system will also function in this network without QoS measures. Malfunctions will occur if these conditions are violated, for example, through load displacement or something similar. Constant, highly developed network monitoring is essential in this case to recognize bottlenecks developing in the network and to remove them immediately. If narrowband WAN connections which are also used for data connections and have a high load are utilized in the network used for IPDA, then malfunctions are guaranteed in networks without a QoS functionality for prioritizing IPDA traffic.

Answer: The bit rate required by the access point can be limited by the Resource Manager. Table 29 “High-priority load of an AP as a function of the permissible B-channels” provides an overview of the capacity required as a function of the number of connections simultaneously active. The basis for this assumption is calls using the G.711 codec. The signaling load was set to 64 Kbps. With a sample size of 30 ms (default), nine connections could be used simultaneously to remain under 800 Kbps (792).

Follow-up question: Table 28 “High-priority load of an AP as a function of codec and sample size” shows me that I can transport significantly more B-channels with the available bandwidth if I use the G.729 codec.

Answer: The 800 Kbps available could theoretically transport over 30 B channels if the sample size were set to 40 ms in G.729. However, please note that in this case, all the trunks in the entire system involved in calls must be configured to support G.729 (classmark G729OPT). This is the default setting. All trunks in the access point must also be configured with classmark G729 which necessitates the use of the G.729 codec. This also applies to the conference connection and music-on-hold. However, we advise against configuring the conference unit with G.729 if you want to guarantee the best voice comprehension levels possible for conferences. It should also be noted that the melody played back when music-on-hold is active is distorted by the voice compression. In addition, please note that fax machines, modems and ISDN data terminals must not operate with G.729 compression. If these devices are active, 81 Kbps will be seized (30 ms - in this example - with G.711 and 40 ms with G.729) instead of the anticipated 21 Kbps. In other words, the number of B channels in this example must not be set to 30 even with the maximum possible use of G.729. The correct value is between 9 and 30. It depends on how many G.711 connections are still required. If the number of B channels is set too high, ALL connections will be affected when the capacity of the WAN link is exceeded. The signaling connection can also be affected and can, depending on the level of interference, cause a switchover to signaling survivability or an access point restart.

Answer: Yes, you should stay well clear of this configuration. Although 7 B channels require only 114 Kbps with G.729 compression and a sample size of 60 ms, there is good reason for always keeping around 64 Kbps free for signaling. This leaves only around 64 Kbps for payload. That is not sufficient, even if only one call cannot be compressed (fax, modem, ISDN data). See also Question 13.

Answer: Yes, having “dynamic“ WAN bandwidth will cause problems that can only be resolved with fixed bandwidth. The reason for this is very simple. Let’s assume that the amount of bandwidth currently available is exactly right. Now a call comes through. There is therefore no longer enough bandwidth available. What does the router do? Firstly, it blocks the packets that it can no longer get rid of due to the lack of bandwidth, which affects all connections equally. If the backlog is not cleared within a specific time, it establishes a second 64 Kbps connection in the telephone network. Once connection setup has been completed, there is once again enough bandwidth available. (If not, a further 64 Kbps are set up.) This requires only a few seconds. During this time, all payload connections are affected as is - if not protected by means of prioritization - the signaling connection.

Answer: The QoS values recorded with the real-time transmission protocol can be checked via SNMP at all HG 3575 and HG 3500 boards. See Chapter 19, “SNMP Support HG 3500 / HG 3575” in the document “Gateways HG 3500 and HG 3575”. OpenScape 4000 Assistant also features an option for recording, evaluating and displaying QoS parameters on a call-by-call basis. See OpenScape 4000 Assistant -> Diagnose -> IPDA Service Access -> Call Quality Recording Viewer, MIB Viewer or QoS Viewer

Follow-up question: According to the network operator, not a single IP packet was lost during the period when there were problems with voice communication. Is there another possible cause for poor voice quality?

Answer: If the network operator delivers packets with a delay greater than the size of the jitter buffer, they are not available for the codec when they are needed. This means that although the packets are being delivered correctly from the network operator’s point of view, they are lost in the real time context of voice transmission.

Answer: There are three factors that are relevant here: packet loss, jitter and delay. Modern voice codecs provide acceptable voice quality even with a packet loss of 5% through procedures such as “packet loss concealment“. The packet loss cannot, however, be disguised in the case of fax, modem or ISDN data connections. The throughput declines here due to the number of retransmissions necessary. If packet loss is too high, the connection is cleared down by the terminals. Jitter causes indirect packet loss. Jitter buffer dimensioning is important here. This should be dimensioned as small as possible to keep delays short. However, packets whose deviation from “normal“delays can no longer be compensated for in the jitter buffer are lost. The total number of packets lost in the network or due to high jitter levels should be significantly higher for voice then for fax, modem and data. To satisfy the various traffic type requirements in terms of jitter-specific packet loss (voice < 5%, fax, modem data ~0%), the jitter buffer value set for fax, modem or data connections is increased by 30 ms in the OpenScape 4000 components HG 3500 and HG 3575. The delay on the connection can - depending on the data transfer protocol used - also be critical. If transmission is subject to acknowledgment, the acknowledgment is delayed by the transmission delay which reduces the throughput in contrast to connections that are not delayed. The signal processors evaluate the signaling tones from the connected fax or modem devices when setting up a connection. A distinction is made here between high- and low-speed devices and transmission is optimized accordingly.

Answer: IPDA is unable to guarantee bit rates higher than those ensured by the OpenScape 4000 central system. That is 14.4 Kbps. Higher bit rates lead to dependencies on the attenuation plan, the attenuation set at the T reference point, etc. Bit rates above 14.4 Kbps are technically possible in particular constellations but cannot be guaranteed.

Answer: Problem are caused by all-in-one devices that want to improve the transmission speed above and beyond the fax standard. These devices enter the negotiation phase at the start of the fax connection as “normal“ Group 3 fax devices. If they both determine that they both support a proprietary - and faster - transmission method, then they use it. The IPDA gateway problem is like the problem that occurs on remote links. The transmission path is optimized on the basis of the signaling tones that indicate a low bit-rate connection. But the devices decide to use a transmission method with a high bit rate during negotiation. And that causes problems with the path optimized for low bit-rate transmission.

Answer: There are three factors that influence a successful ping

For this to happen, the routing from the port of the computer that sends the ping to the destination must be safeguarded. It is therefore important that ping requests come from known IPDA components (AMO SIPCO, parameter LSNET und AMO AART, parameter APNET) and not from any other unknown network address segments/devices (e.g. service PC on different network).

The control processors CC-A/CC-B protect themselves from floods of ping requests by allowing only a specific volume of requests per unit of time. The filter is set up so that a standard ping command with approximately 5 requests in intervals of about one second can be responded to without any problems. However, requests that are more frequent or at shorter intervals are rejected. Both CC-A and CC-B will reply.

For this to happen, the routing from the pinged IPDA component to the computer that sent the ping must be safeguarded. The control processors CC-A/CC-B use specific host routes to the configured devices (in other words, no default route exists to unknown networks on which other devices are connected). AMO SIPCO, parameter DEFRT is therefore only used for those specific routes and is not a classic default router.

Answer: With the NCUI, cross-wise exchange is very problematic because the local configuration data needs to be changed. If you just exchange the modules without reconfiguring them, you take the LTU number and the entire configuration of the shelf as well. The central system accesses LTU 17 with the configured IP address. If the NCUI module with this address now actually sits in another shelf, this is now LTU 17. You should therefore follow the instructions in Section 2.2.9, “Information on Exchanging HG 3575 Boards” of the Service Manual when exchanging modules. Cross-wise exchange is also a module exchange. This involves applying the local configuration (with “Expert Access“) in exactly the same way as EXEC-USSU:UPDATAP,LTU Number,UL;

Answer: There is a widespread and logical ban on the operation of PCs that have simultaneous network access to another networks (that cannot be controlled and is not protected by a firewall, etc.) on the LAN. Devices of this kind could be used as “private“ gateways in order, for example, to offer a secure dial-in connection to the LAN.

An IPDA access point used as a gateway for voice connections from TDM <-> IP must have access both to the LAN and to TDM ports.

The design of the HG 3575 guarantees a distinct separation between the payload functionality and the signaling functionality.

In the payload part, random TDM <-> TDM or TDM <-> IP <-> TDM connections are set up at the request of the OpenScape 4000 central system. The network consisting of the OpenScape 4000 central system and the IPDA access points provides a TDM operation that, from the outside, appears closed and features an internal IP network for networking the access points.

If HG 3575 were misused, additional IP connections would be routed from the NCUI, for example via PPP, to TDM connections.

This is not possible because

Answer: You have no digital trunk interfaces in the access point or do not use these for clocking the HG 3575. Without synchronization over digital trunk interfaces in the access point, the clock generators in the OpenScape 4000 central system and the access point become asynchronous, despite the extremely high precision of the free-running clock generator on the HG 3575 (ISO 11 573 class III, TIA stratum 4, CTR4 and CTR12/13). Nevertheless, the unsynchronized clock generators start to diverge over time. In the scenario you measured, the receiver works with a slightly higher clock frequency than the sender. The IP connection starts with the predefined jitter buffer value. As more data is read than sent, the jitter buffer slowly runs idle. This explains the steadily falling mouth-to-ear delay. When the minimum jitter buffer fill level is reached, time is “inserted“ at the receive end during which the jitter buffer fills up again. This explains the jump to the maximum value. The converse effect can be observed in the opposite direction. The mouth-to-ear delay climbs steadily until the upper limit of the jitter buffer is exceeded. Time is then “removed“ and the jitter buffer is reset to the target value.

You can observe this effect in all devices that transfer data at a constant rate over a long period of time without transfer clock synchronization. A solution for the IPDA access points involves synchronizing the central system and all HG 3575 ASCs with a common exchange clock.

Answer: VoiceMail systems are not affected by payload survivability. This is explicitly specified as an exception in the sales release for OpenScape 4000 (1st supplement). In this case, calls are not routed over the survivability path (that is the CO).

Answer: NO.

Answer:

Answer: From HiPath 4000 V6 R2 loadware lines, access points will accept HSR connections from any IP address, so long as there is not one already active (i.e. the IPDA must be in NOT READY status for this to work). This means you can simply change the CCA/CCB address in AMO SIPCO (also NCUI/OpenScape 4000 SoftGate) and the access point will accept the new HSR connection upon next startup. The alternative method listed under Section 2.14, “IP Address Changes”, can still be used for running systems with active HSR connections.