Loading...

Performance of Host-Based Media Processing

The viability of host-based software in providing media processing capabilities continues to expand the possibilities for voice application development. Over time, we will see a larger percentage of applications deployed on host vs. board-based systems. This trend is driven primarily by the relentless increase in processor speed and capabilities. Host-based media processing is also a natural fit for VoIP-based applications, since these applications can now be delivered as software-only solutions.

Vendors of host-based media processing implementations face a number of technical challenges in providing a viable solution to telephony application developers. The main challenges are:

  • System Capacity: optimizing media processing algorithms to take advantage of the computing power now available on standard desktop platforms.
  • Robustness: preventing other applications running on the platform and the media processing from interfering with each other when competing for CPU resources.
  • Latency: ensuring that the latency introduced by the media processing does not affect the perceived quality of the audio signal being processed.

We discuss each of these challenges in detail below and how PIKA’s host-based media processing implementation meets each of these challenges.

Defining System Capacity

The capacity of a system is the maximum number of active media processing channels (such as play, record, DTMF detection, and echo cancellation) that can be supported by the application on a platform. The greater the capacity of a single platform, the lower the cost per port for an application and the greater the value the application provides to a customer. To increase the capacity of an application, the media processing must be as efficient as possible.

The factors that affect the system capacity of host-based media processing applications on a platform are:

  • the acceptable percentage of CPU capacity that can be dedicated to media processing
  • the types of media processing that are performed on each active channel
  • the specifications (CPU speed and architecture, operating system, amount of RAM, cache size, and NIC speed) of the platform running the application

PIKA has performed extensive performance tests with a variety of media processing applications executed on a wide range of platform configurations. Figure 1 lists a representative sample of applications that PIKA has benchmarked and the media processing that was performed on each channel for the duration of the test.

Application

Media Processing Performed

Gateway VoIP interface (using G.711 or G.729 Codec)
Echo cancellation (12ms tail length)
PSTN interface
IVR VoIP interface (using G.711 or G.729 Codec) or PSTN interface
Play for all channels for 70% of the call duration
DTMF detection
Conference VoIP interface (using G.711 or G.729 Codec) or PSTN interface
Conference
DTMF detection

Figure 1: Benchmark Applications Media Processing Functions


High-Level API

VoIP Density

This test measures CPU usage for the specified number of simultaneous RTP channels. The CPU usage was measured after all calls were set up. The test initiator places an outgoing call to the test receiver system. The receiving system answers the call and places an outgoing call back to the test initiator. DTMF detection and tone detection are enabled throughout the call. For the duration of the call, the test initiator plays an announcement on the outgoing channel and records the announcement on the incoming channel. Call duration is 5 minutes. The audio quality of the recording is verified through PESQ scoring.

The following table lists supported channels for the following PCs:

  • Test initiator (play/record): Intel Core 2 Duo E6600, 2.4Mhz, 2 GB RAM, 4M Cache
  • Test receiver (switching): Intel Core 2 Duo E6600, 2.4Mhz, 2 GB RAM, 4M Cache

 

Linux (CentOS 5.4)

Application Channels Average CPU%
G.711a Density (play / record) 400 43
G.711a Density (switching) 600 47
G.729 Density (play / record) 160 56
G.729 Density (switching) 160 51

ISDN Density

The test initiator places an outgoing call to the test receiver system. The receiving system answers the call and places an outgoing call back to the test initiator. DTMF detection and tone detection are enabled throughout the call. For the duration of the call, the test initiator plays an announcement on the outgoing channel and records the announcement on the incoming channel. Call duration is 5 minutes. The audio quality of the recording is verified through PESQ scoring.

The following table lists supported channels for the following PCs:

  • Test initiator (play/record) : Intel Core 2 Duo E6400 processor, 2.13 GHz, with 1 GB RAM
  • Test receiver (switching): AMD Athlon64 X2 4800+ AM2 Dual-Core 65W Processor, 1 GM RAM

Linux (CentOS 5.4)

Application Channels Average CPU%
E1 ISDN Density (play / record) 480 27
E1 ISDN Density (switching) 600 31

Windows

Application Channels Average CPU%
E1 ISDN Density (play / record) 480 28
E1 ISDN Density (switching) 600 32

Gateway and IVR

  • IVR
    • A TDM channel (ISDN E1) answers the incoming call. DTMF detection and tone detection are enabled
      throughout the call. All channels perform audio playback for the duration of the call. Call duration is 30
      seconds.The audio quality of the recording is verified through PESQ scoring.
  • Gateway
    • A TDM channel (ISDN E1) answers the incoming call. Based on the calling number, a SIP call is made and the
      underlying RTP channel (G.711) is connected to the TDM channel. DTMF detection and tone detection are
      enabled throughout the call. Echo cancellation is applied to all TDM channels (64ms tail length). For the duration of the call, an announcement is played on the incoming channel and recorded on the outgoing channel. Call duration is 5 minutes. The audio quality of the recording is verified through PESQ scoring.

The following table lists supported channels for the following PC:

  • Intel Core 2 Duo E6400 processor, 2.13 GHz, with 1 GB RAM

Linux (CentOS 5.4)

Application Channels Average CPU%
ISDN E1 IVR 160 24
ISDN E1 to G.711a Gateway 160 57

Note: Perceptual Evaluation of Speech Quality (PESQ) is a standard for evaluating audio quality in telephony
applications. It is standardized as ITU-T recommendation P.862 (02/01).

Low-Level API

The following table lists supported channels for the following PC at 60% CPU utilization: Intel Quad Core Xeon
Processor E53452, 2.33 GHz, 2 GB RAM, 4 MB L2 Cache, 1 GB NIC.

Application Number of Channels
(Windows)
Number of Channels
(SUSE 10.2)
G.711 Gateway 400 480
G.729 Gateway 180 300
G.711 Channel 1200 1400
G.729 Channel 320 350
V.17 Fax 480 600
G.711 Advanced Conference 400 250
TDM Advanced Conference 360 400
Mixed G.711 / G.729 IVR 320 400


The following table lists supported channels for the following PC running at 60% CPU utilization: Intel Dual Xeon Nocona, 2×3.0 GHz, 1 GB RAM, 2 MB L2 Cache, 1 GB NIC.

Application Number of Channels
(Windows)
Number of Channels
(SUSE 10.2)
G.711 Gateway 260 260
G.729 Gateway 120 120
G.711 Channel 800 850
G.729 Channel 160 160
V.17 Fax 360 400
G.711 Advanced Conference 250 250
TDM Advanced Conference 240 240

Details on Applications

  • G.711 Gateway
    • A TDM channel (ISDN E1) answers the incoming call. Based on the calling number, a SIP call is made and the underlying RTP channel (G.711) is connected to the TDM channel. Echo cancellation is applied to all TDM channels (12ms tail length). Call duration is 180 seconds.
  • G.729 Gateway
    • A TDM channel (ISDN E1) answers the incoming call. Based on the calling number, a SIP call is made and the underlying RTP channel (G.729) is connected to the TDM channel. Echo cancellation is applied to all TDM channels (12ms tail length). Call duration is 180 seconds.
  • G.711 Channel
    • An RTP channel (SIP G.711) answers the incoming call. DTMF detection is turned on throughout the call and an announcement is played to the call originator for 70% of the call duration. Call duration is 30 seconds.
  • G.729 Channel
    • An RTP channel (SIP G.729) answers the incoming call. DTMF detection is turned on throughout the call and an announcement is played to the call originator for 70% of the call duration. Call duration is 30 seconds.
  • V.17 Fax
    •  A V.17 channel (ISDN E1) answers the incoming call. FAX reception is turned on and a fax is received. Call duration is 60 seconds.
  • G.711 Advanced Conference
    • An RTP channel (SIP G.711) answers the incoming call and connects it to an available 3-party advanced conference. Digit detection and echo cancellation (12ms tail length) are enabled. The conference is configured for two active talkers with automatic gain control and digit clamping enabled.
  • TDM Advanced Conference
    • A TDM channel (ISDN E1) answers the incoming call and connects it to an available 3-party advanced conference. Digit detection and echo cancellation (12ms tail length) are enabled. The conference is configured for two active talkers with automatic gain control and digit clamping enabled.
  • Mixed G.711/G.729 IVR
    • An RTP channel (SIP 25% G.729, 75% G.711) answers the incoming call. Tone detection, speech detection, and DTMF detection are turned on throughout the call. One quarter of the channels are performing audio playback and record.

Robustness of Host-Based Processing

When implementing a host-based media processing solution there are two key robustness objectives:

1. Host-based media processing must receive sufficient CPU capacity to perform all the required functions in real-time.
2. Other applications running on the same platform must regularly receive sufficient CPU capacity to perform all their required activities without noticeable deterioration of performance or noticeable pauses in execution.
HMPx1

Ideally, the CPU would be partitioned so that the host-based media processing receives a specific proportion of the CPU capacity and other applications receive the rest. For example, on a 3.2 GHz processor, the host-based media processing could be guaranteed 25% of the CPU capacity, and other applications would perform as if they were running on a dedicated 2.4 GHz platform.

Why is CPU partitioning important? If there is not strong partitioning between host-based media processing and application CPU utilization, a number of problems arise. If the host-based media processing does not receive sufficient CPU capacity, on a regular basis, it is not able to process all the media in real-time. The quality of the audio will deteriorate and sections of the audio may be dropped, causing distortion and choppiness in the audio signal. If other applications do not receive sufficient CPU capacity on a regular basis, their performance becomes slow, choppy, and non-responsive. In extreme cases, the platform may not respond to mouse movements or keystrokes.

Windows and Linux are not real-time operating systems and, as such, are not designed to easily partition CPU usage. They have no built-in mechanisms to ensure that a process does not monopolize the CPU to the detriment of other processes.

PIKA’s solution is a real-time microkernel that acts as a firewall between applications and media processing. The microkernel allows non-real-time operating systems to serve the real-time demands of processing voice media without allowing the processor to be monopolized. The PIKA host-based media processing implementation partitions the available CPU capacity so that in every tick, the host-based media processing function execution is guaranteed to be allotted sufficient CPU capacity in real-time while ensuring that other processes running on the same platform receive sufficient CPU capacity to run smoothly and provide good performance.

PIKA’s micro-kernel is designed to work on single processor platforms and to balance the load for each CPU on hyper-threading or multiple processors platforms.

To test PIKA’s microkernel and host-based media processing, a number of formal and informal tests were executed in conjunction with media processing activity. No combination of commercial applications or CPU load had any effect on the quality of the media processed audio.

PIKA performed the following formal tests, on both Windows and Linux operating systems, to verify the robustness of its microkernel:

  • Test the interference from and with user-level processes (normal applications).
  • Test the interference from and with kernel-level processes (device drivers, such as NIC drivers, and disk drivers).
  • Test competition for PCI bus resources.

To test interference between media processing and user level processes:

  1. A media processing application was set up to provide the continuous playing of a recorded message to a large conference with 120 members.
  2. A phone was used to connect to the conference to monitor the audio quality.
  3. A base-line measure of the CPU utilization was taken.
  4. A normal-priority user application was executed that consumes a continually increasing percentage of CPU capacity.
  5. As the user application consumes more and more CPU capacity the quality of the audio recording received from the conference was monitored.

Results: There was no change to the quality of the audio, even when the user application saturated the CPU utilization at 100%.

To test interference between media processing and kernel level processes, a similar test was performed, only this time the test process consumed CPU capacity at the kernel level.

Results: The results were identical to the previous test with no change to the quality of the audio, even when the kernel application saturated the CPU utilization at 100%.

To test competition for PCI bus resources, a Vmetro board was installed on the test platform. This board flooded the PCI bus with data, causing congestion on the PCI bus.

Results: Again, there was no change to the quality of the audio being received from the conference.

Finally, informal tests were performed that more accurately simulated real application processing. The following tasks were performed on the test platform while a conferencing application was executing:

  • Search for the word “cow” in all files on the hard drive. This is a disk I/O and CPU intensive application that generates a large number of interrupts.
  • Copy a large file to a network drive. This function causes a large number of interrupts and network traffic.
  • Play an MP3 streaming audio file. This function causes interrupts from the audio card. The quality of the audio heard is very sensitive to the application being starved for CPU capacity.
  • Compile source code. Compiling code is a CPU intensive activity.

With these functions running, the recording played to the conference was monitored. 

Results: As with the other tests, there was no change to the quality of the audio being received from the conference. There was also no deterioration in the quality of the streaming audio file being played.

We can see from the above testing that PIKA’s microkernel has succeeded in partitioning the CPU and in isolating the media processing and other applications running on the same platform.

Measuring Latency

In simple terms, latency is the length of time from when you say something until the person on the other end of the phone line hears what you said. The perceived quality of the audio heard in a call is highly dependent on latency. Typically, the latency for PSTN switching, including PIKA’s AllOnHost TDM switching, and networks is very low, on the order of 5 ms. Developers of pure PSTN applications are rarely concerned with latency. On the other hand, elements of a VoIP network (phones, switches, and gateways) generally add significant latency to the audio path; therefore, applications using VoIP must be must be aware of the total latency of the audio path to ensure that the latency does not exceed the acceptable limits.

How much latency is acceptable? There are two classes of applications that should be considered when determining the acceptable amount of latency; terminating applications such as IVRs, and switching applications such as PBXs, conference bridges, and gateways.

Terminating applications typically imply human interaction with a computer. The application records audio data, plays announcements, and detects DTMF tones or speech generated by the caller. Studies have shown that as long as the application responds within 500 ms, the caller will perceive a good quality connection.

Switching applications typically imply human-to-human interaction. The ITU-T specification G.114 defines three audio quality regions for latency in human-to-human call.

Latency Range (ms) Audio Quality
0 to 150 ms Acceptable for most applications
150 to 400 ms Marginally acceptable – impacts the quality of application
Above 400 ms Unacceptable

Figure 5: G.114 Latency Guidelines for Switching Applications

PIKA measured the latency of several connection types using its AllOnHost (host-based) media processing. The result of these measurements is shown in Figure 6. For comparison, the latency measured between two good quality IP phones is also listed.

Equipment Configuration Measured Latency Range (ms)
TDM switching using AllOnHost – Analog phone to analog phone <5
Good IP phone directly to good IP phone 50 to 60
IP Gateway using AllOnHost – Analog phone to IP phone 50 to 60
Mixed conferencing using AllOnHost – Analog phone to IP phone 50 to 60
IP conferencing using AllOnHost – IP phone to IP phone 105 to 120
IP transcoding using AllOnHost – G.711 IP phone to G.729 IP phone 105 to 120

Figure 6: AllOnHost Latency Measurement

These values are valid for both G.711 and G.729 codecs. All tests used 20 ms packets and good quality IP phones. The measurements were performed using a switched LAN and locally-connected IP and analog phones.

Note that the latency of the AllOnHost IP gateway is identical to the latency measured between two good quality IP phones and that the latency added by the AllOnHost IP gateway is the same as the latency of a hardware-based IP gateway.

For some applications, the network latency must also be considered when determining the overall latency the callers experience. Figure 7 lists the range of latencies that can be expected, as well as the typical latency for a number of network distances. For comparison, values for PSTN latency for different distances are also given.

PSTN Network Expected Latency
Range (m)
Typical Latency (ms)
Local 0.5 to 4 2
National long distance 2 to 70 12
International long distance (excluding satellite) 2 to 150 20
IP Network
Switched LAN 0.1 to 2 <1
Metropolitan WAN 2 to 50 20
National WAN 2 to 150 50

Figure 7: Network Connection Latency

To determine the expected latency of an application, take the equipment latency measured for that type of application from Figure 6 and add in the network latency, from Figure 7, that will be encountered by the audio signal as it passes from the speaker to the listener. To demonstrate this, consider the following examples, an IP PBX and a conference server.

 

hmpx2

 

IP PBX – In this application, shown in Figure 8, the IP PBX provides connectivity between the PSTN network and local and remote IP phones.

When determining the latency for this application, the latency for three different types of connection must be considered:

• Between PSTN and local IP phones (such as A and B)
• Between PSTN and remote IP phones (such as A and C)
• Between local and remote IP phones (such as B and C)

Figure 9 lists the connection type, the connection latency, the networks traversed, the network latency, and the total latency for each type of connection.

The latency for each type of connection is within the 150 ms limit although the connections to the remote IP phone are at the upper end of the acceptable range. Any additional latency introduced by the host-based media processing would cause the perceived quality of the connection to deteriorate.
Figure 8: IP PBX Application Architecture

Between Phones Equipment Configuration Equipment Latency (ms) Networks Traversed Network Latency (ms) Total Latency (ms)
PSTN and Local IP IP Gateway 60 PSTN-LAN 2+1 63
PSTN and Remote IP IP Gateway 60 PSTN-LAN-WAN -LAN 2+1+50+1 114
Local and Remote IP IP Phone to IP Phone 60 LAN-WAN -LAN 1+50+1 112

Figure 9: IP PBX Latency Estimates


hmpx3

 

Conference Server – In this application, shown in Figure 10, the conference server provides connectivity between phones from the PSTN network and local IP phones.

When determining the latency for this application, the latency for three different types of connections must be considered:

• Between PSTN phones (such as A and B)
• Between PSTN and IP phones (such as A and C)
• Between IP phones (such as C and D)

Figure 11 lists the connection type, the connection latency, the networks traversed, the network latency, and the total latency for each type of connection.

The latency for each type of connection is within the 150 ms limit although the connection between IP phones is at the upper end of the acceptable range. Any additional latency introduced by the host-based media processing would cause the perceived quality of the connection to deteriorate.

Figure 10: Conference Server Application Architecture

Between Phones Equipment Configuration Equipment Latency (ms) Network Latency (ms) Total Latency (ms)
PSTN PSTN conferencing 4 PSTN-PSTN 2+2 8
PSTN and IP Mixed conferencing 60 LAN-LAN 1+1 62
IP IP conferencing 120 LAN-LAN 1+1 122

Figure 11: Conference Server Latency Estimate

Summary: Overcoming the Challenges

There are significant challenges to implementing a host-based media processing solution. Each of these challenges must be overcome to produce a viable software-only telephony application. PIKA’s microkernel solution ensures that:

  • The capacity of applications based on PIKA’s AllOnHost (host-based) media processing can accommodate up to 600 active channels. This is sufficient capacity for cost-effective small-sized to medium-sized applications.
  • There is no interference between the AllOnHost media processing and other applications executing on the platform. The media processing is guaranteed to receive sufficient CPU capacity to perform the required functions in real time.
  • The latency added by the host-based media processing is small enough that applications can achieve latency below the 150 ms required for good quality human-to-human conversation.

Technical Specifications

HMP Digital

Category
Details
Network Connection
Rear panel RJ48 connectors (DSX-1 or DS-1 interface)
Number of T1/E1 Spans
1 to 4 spans
LineBuildOut
Software Selectable ( CSU/DSU )
Impedance
T1: 100 ohm, E1: 120 ohm
Switch Types
4ESS, DMS 100, 5ESS, NI-2, NET5
HDLC
3 available per span
Framing
T1: ESF, SF/D4 E1: CRC4, Basic
Encoding
T1: B8ZS, AMI (NONE, GTE, BELL, JB8) E1: HDB3, AMI
Bus Interface: PCIe
Based on PCIe revision 1.0a specifications
PCIe bus speed
2.5 GHz, single lane link
Memory Address Allocation
Automatically assigned by Plug and Play cycle
Interrupts Allocation
Automatically assigned by Plug and Play cycle
Dimensions: PCIe (Metric) PCIe (Imperial)
151.8 mm L x 106.7 mm H x 15.2 mm D 5.975” L x 4.2” H x 0.6” D
Power Requirements PCIe
Power consumption from 3.3V rail 1 W max
Environment Requirements
Operating Temperature 0 °C to +60 °C
Storage Temperature
-20 °C to +85 °C
Humidity, Non-condensing
5% to 95%

Technical Specifications

HMP Analog FXS

Category
Details
PCIe Bus Interface
Based on PCIe revision 1.0a speci cations
PCIe Bus Speed
2.5 GHz, single lane link
Memory Address Allocation
Automatically assigned by Plug and Play cycle
Interrupts Allocation
Automatically assigned by Plug and Play cycle
Slot Requirements
PCIe 9.5” slot
Dimensions (Metric)
241 mm L x 98 mm H
Dimensions (Imperial)
9.5” L x 3.875” H
Power Requirements
Power consumption from 12V rail 13W
Peak Current from 12V rail 2.7A
9.5” L x 3.875” H

Environment Requirements
Operating Temperature: 0 °C to +60 °C
Storage Temperature: -20 °C to +85 °C
Humidity, Non-condensing: 5% to 95%
Mean Time Between Failure (MTBF) : 35 years
Telephony Interfaces
Off-Hook: 600 ohms or TBR21 complex impedance
Dimensions (Imperial)
Return Loss: >30 dB
DC Feed
Open Loop Voltage 48V
Constant Loop Current 20mA
Max Loop Length 4kft
REN
1

Technical Specifications

HMP Analog FXO

Category
Details
PCIe Bus Interface
Based on PCIe revision 1.0a specifications
PCIe Bus Speed
2.5 GHz, single lane link
Memory Address Allocation
Automatically assigned by Plug and Play cycle
Interrupts Allocation
Automatically assigned by Plug and Play cycle
Switch Types
4ESS, DMS 100, 5ESS, NI-2, NET5
Slot requirements
PCIe 9.5” slot
Dimensions (Metric)
241 mm L x 98 mm H
Dimensions (Imperial)
9.5” L x 3.875” H
Power consumption from 3.3V rail
2 W max
PCIe bus speed
2.5 GHz, single lane link
Memory Address Allocation
Automatically assigned by Plug and Play cycle
Interrupts Allocation
Automatically assigned by Plug and Play cycle
Power consumption from LS Lines
North America 1.4 W European Union 2.0 W
Power Requirements PCIe
Power consumption from 3.3V rail 1 W max
Environmental Requirements
Operating Temperature: 0 °C to +60 °C
Storage Temperature: -20 °C to +85 °C
Humidity, non-condensing: 5% to 95%
Mean Time Between Failure (MTBF)
31 years
Telephony Interfaces
4 – 16 FXO trunk interface ports
AC Impedance (in audio band)
Off-hook: 600 ohms
On-hook metallic (tip to ring): >300 k ohms
Return Loss: >26.8 dB
DC Current – Loop Current Range
13 – 110 mA
Ring Detection

14 Vms @ 16 Hz
14 Vms @ 20 Hz
12 Vms @ 68 Hz

Ringer Impedance (20 Hz)
> 26 K ohm
Ringer Equivalence Number (REN)
0.1B
On-Hook Common Mode Gain
>27 dB (300-3400)
Signal to Noise Ratio (15 dBm, 1 KHz reference)
> 38 dB
On-Hook Inter Hybrid (Interface) Crosstalk
No measureable crosstalk
Off-Hook Inter Hybrid (Interface) Crosstalk
No measureable crosstalk
Idle Channel Noise
6 dBrnc
Transverse Balance
> 57 dB
Supervision
Ring Detection, Loop Disconnect, Reversal Detection, Loop Voltage, Loop Current
Signalling
Off Hook, Flash, DTMF, Pulse Dial
Onhook Audio Detect
Caller ID, DTMF, Audio Logging
 

DC Resistance

Longitudinal (tip to ground, ring to ground)
On-Hook Metallic (Tip to Ring)
Off-Hook Metallic (Tip to Ring)
>9.8 M ohms
>6.5 M ohms
310 ohms @ 20mA
117 ohms @ 100 mA
Gain Tolerance (Linearity)
On-Hook in (2 to 4 wire) NA
Off-Hook In (2 to 4 wire) NA
Off-Hook Out (4 to 2 wire)
0.0 to 0.8 dB (300-3400 Hz)
-1.5 to -0.4 dB (300 -3400 Hz)
-4.8 to -0.7 dB (300-3400 Hz)
 

Gain Range

Fixed – On-Hook H/W Gain In (2 to 4 wire)
Fixed – Off -Hook H/W Gain In (2 to 4 wire)
Fixed – Off-Hook H/W Gain Out (4 to 2 wire)
On-Hook Signal overload level @0 dB gain In (2 to 4 wire)
Off-Hook Signal overload level @0 dB gain In (2 to 4 wire)
-1.6 dB
-0.75dB
+0.24 dB
+4.77 dBm
+3.92 dBm

Technical Specifications

HMP Digital Logging

Category
Details
Network Connection
Rear panel RJ48 connectors (DSX-1 or DS-1 interface)
Number of T1/E1 Spans
1 to 2 spans
Protocol
ISDN, Clear Channel, CAS/RBS
Impedance compatibility
T1: 100 ohm, E1: 120 ohm
Switch Types
4ESS, DMS 100, 5ESS, NI-2, NET5
Approvals
North America, European Union
HDLC
3 available per span
Framing
T1: ESF, SF/D4 E1: CRC4, Basic
Encoding
T1: B8ZS, AMI (NONE, GTE, BELL, JB8) E1: HDB3, AMI
Bus Interface: PCIe
Based on PCIe revision 1.0a specifications
PCIe bus speed
2.5 GHz, single lane link
Memory Address Allocation
Automatically assigned by Plug and Play cycle
Interrupts Allocation
Automatically assigned by Plug and Play cycle
Dimensions: PCIe (Metric) PCIe (Imperial)
151.8 mm L x 106.7 mm H x 15.2 mm D
5.975” L x 4.2” H x 0.6” D
Power Requirements PCIe
Power consumption from 3.3V rail 1 W max
Environment Requirements
Operating Temperature 0 °C to +60 °C
Storage Temperature
-20 °C to +85 °C
Humidity, Non-condensing
5% to 95%
Mean Time Between Failure (MTBF)
101 years

Technical Specifications

HMP Analog Logging Boards

Category
Details
PCIe Bus Interface
Based on PCIe revision 1.0a specifications
PCIe Bus Speed
2.5 GHz, single lane link
Memory Address Allocation
Automatically assigned by Plug and Play cycle
Interrupts Allocation
Automatically assigned by Plug and Play cycle
Slot requirements
PCIe 9.5” slot
Dimensions (Metric)
241 mm L x 98 mm H
Dimensions (Imperial)
9.5” L x 3.875” H
Power consumption from 3.3V rail
2 W max
Power consumption from LS Lines
North America 1.4 W
European Union 2.0 W
Environmental Requirements
Operating Temperature: 0 °C to +60 °C
Storage Temperature: -20 °C to +85 °C
Humidity, non-condensing: 5% to 95%
Mean Time Between Failure (MTBF)
31 years
Power consumption from LS Lines
North America 1.4 W European Union 2.0 W
Power Requirements PCIe
Power consumption from 3.3V rail 1 W max
Environmental Requirements
Operating Temperature: 0 °C to +60 °C
Storage Temperature: -20 °C to +85 °C
Humidity, non-condensing: 5% to 95%
Mean Time Between Failure (MTBF)
31 years
Telephony Interfaces
4 – 16 high impedance analog tapping
AC Impedance (in audio band)
On-hook metallic (tip to ring): >300 k ohms
DC Current – Loop Current Range
13 – 110 mA
Ring Detection

14 Vms @ 16 Hz
14 Vms @ 20 Hz
12 Vms @ 68 Hz

Ringer Impedance (20 Hz)
> 26 K ohm
Ringer Equivalence Number (REN)
0.1B
Common Mode Gain
-52.9 dBm0 avg
Signal to Noise Ratio (15 dBm, 1 KHz reference)
> 38 dB
Inter Hybrid (Interface) Crosstalk
No measurable crosstalk
Idle Channel Noise
6 dBrnc
Transverse Balance
> 57 dB
Supervision
ON-HOOK supervision
 DC Resistance

 Longitudinal (tip to ground, ring to ground) > 9.8 M ohms
On-Hook Metallic (Tip to Ring) >6.5 M Ohmns

Audio Detect
Caller ID, DTMF, Audio Logging
DC Resistance
Longitudinal (tip to ground, ring to ground)
On-Hook Metallic (Tip to Ring)
>9.8 M ohms
>6.5 M ohms
Gain Tolerance (Linearity)
2 to 4 wire NA
0.0 to 0.8 dB (300-3400 Hz)

Technical Specifications

Primenet Digital

Functionality Specifications
T1/E1 Spans 1, 2, 3 or 4
Switching PIKA DSP based media processing provides realtime audio
switching between TDM or IP interfaces
Data Bus Type PCI (universal signaling)
Media processing Media processing is performed using DSP based software
resources
Supported OS Windows 2000/XP/2003
Red Hat 7.3/Enterprise 4 SuSE 9.3 distributions of Linux
Host Interface
PCI Interface PCI 32 bit target/initiator V2.2 compliant
33 MHz bus speed
H.100 compatible telephony bus
Network Interface rear panel RJ48, Impedance matched for T1/E1 connections; high impedance interface for audio recording variant
CSU/DSU mode software selectable
DSX-1 or DS-1 interface
Network Types
Proprietary
National ISDN-1, ISDN-2, ISDN-3
Japan/NTT
France
Germany
ETSI EuroISDN
United Kingdom
Australia
Framing
T1 ESF, SF/D4
E1 CRC4, BASIC
Encoding
T1 AMI, B8Z
E1 AMI, HDB3
Protocols
T1/E1 ISDN PRI
T1/E1 CAS (RBS, MFR1, MFR2, DTMF/Pulse Dialing)
Compliance and Capabilities
FCC Part 15 and FCC Part 68
Industry Canada CS-03
TBR4
CSA C22.2 no. 950 NRTL/C
EN55022, EN55024
EN60950 Safety
Switch Interoperability
Standard switches including
AT&T 4ESS and 5ESS
NTT (Japan) INSnet 1500
Nortel DMS-100
US National ISDN-2
AUS
NET5
Physical Properties
Slot Requirements IBM PC/AT single PCI slot
12.4″ L x 3.92″ H x 0.062″ D (Imperial)
Note: Measurements are approximate and do not include card faceplate and Amphenol connector.
MTBF
Baseboard, 4 DSPs 59 years
Baseboard, 2 DSPs 68 years
2 Span NIM 399 years
1 span NIM 657 years
V-Engine 6/3.3 Volt 156 years
V-Engine 2/3.3 Volt 239 years
DSP
Motorola 56303 DSP
Power Requirements
Typical values for a worst-case operating scenario
Single Span T1 820mA @ +5 volts
Dual Span T1 920mA @ +5 volts
Quad Span T1 1.4A @ +5 volts
MM Series V-engine 725mA max @ +3.3 volts (6 DSP Variant)
Environmental Requirements
Operating Temperature 0 °C to +60 °C
Storage Temperature -20 °C to +85 °C
Humidity 5 to 95%, non-condensing

 

RoHS
All PIKA products are RoHS compliant.

Technical Specifications

Inline Low Density

Host Interface
PCI Interface PCI 32 bit target/initiator V2.2 compliant
33 MHz bus speed
Network Interface RJ14 connectors
RJ22 headset/handset connector
Headset Interface RJ22 headset/handset connector; does not require external power supply
Loop Start Trunk Interfaces (CO Interface Circuit) Headset/handset connection configurable via software during set up
On-hook audio reception
Ground button (Euro version only)
Gain pad
DC Resistance
North America 360-140 ohms over 15-120 mA typical
Euro version 470-154 ohms over 14-130 mA typical
Loop range 0-2000 ohms
AC impedance: 600 ohms ( North America ) or complex (Euro version)
Supervision loop current drop, battery reversal, ringing
Signaling off-hook, flash, DTMF
Loop current range
North America 15-120 mA
Euro version: 14-130 mA
Compliance and Capabilities
FCC part 15 and FCC Part 68
Industry Canada CS-03 CSA C22.2 no. 950 NRTL/C
TBR21
EU 55022:1998 Class B EU 55024:1998 EU 60950:1992
2002 / 95 / EC RoHS 6
DSP
Motorola 56303 DSP Software reset on per DSP basis
MTBF
4L/3L plus headset North America: 47 years
Euro version: 45 years
Power Requirements
355mA
Environmental Requirements
Operating Temperature 0 °C to +60 °C
Storage Temperature -20 °C to +85 °C
Humidity: 5 to 95%, non-condensing
Media Capabilities
Play and record
DTMF, tone, speech detection
DTMF, tone generation
Fax
RTP, IP/SIP
Integration with Asterisk and Skype technologies

RoHS
All PIKA products are RoHS compliant.

Technical Specifications

Daytona High Density

Host Interface
PCI Interface PCI 32 bit target/initiator V2.2 compliant
33 MHz bus speed
Network Interface 50 pin Amphenol; RJ21 (optional 12 x RJ14 breakout)x
Telephony Interfaces: Loop Start (standard mode or passive logging mode)
DC Resistance
North American 330 ohms (@ 20 mA) to 127 ohms (@ 105 mA)
European 420 ohms (@ 14 mA) to 89 ohms (@ 150 mA)
DC Loop Current
North American 20 mA to 105 mA (operating range)
European 14 mA to 150 mA (operating range)
AC Impedance
North American 600 ohms (off hook), >350 K ohms (on hook)
European Complex as per TBR21 spec (off hook), >350 K ohms (on hook)
Supervision North American Ringing voltage (15.3 – 68 Hz, >= 32 VRMS), loop current disconnect
European Ringing voltage (16 – 60 Hz, >=25 VRMS), loop current disconnect
Signaling Off hook, Flash, DTMF
On Hook Audio Detect
Caller ID, DTMF (KT23), Audio Logging
DC Triggering 3V, 18V, or 33V programmable threshold
Telephony Interface: Station Interface (SLIC)
Current Limiting Constant at 30 mA
AC Impedance 600 ohms
Loop Range 0-750 ohms @ -24VDC
Supervision Off hook, Flash, Ring Trip, DTMF
Signaling Ringing (externally sourced), Cadence and Power Management Under Software Control
Maximum Ringing Load 2 Ren/line
Compliance and Capabilities
FCC part 15 and FCC Part 68
Industry Canada CS-03
CSA C22.2 no. 950 NRTL/C
TBR21
EU 55022:1998 Class B
EU 55024:1998
EU 60950:1992
2002 / 95 / EC RoHS 6
DSPs
Motorola 56303
Software reset on per DSP basis
MTBF
Daytona Baseboard
Daytona Loop Start Module
Daytona Station Module
V-Engine
68 years
280 years
244 years
144 years
Power Requirements
12LC
24LC
12P
24P
4LC/8P
8LC/16P
MM Series V-engine
770mA max @ +5 Volts
960mA max @ +5 Volts
1060mA max @ +5 Volts
1540mA max @ +5 Volts
960mA max @ +5 Volts
1350mA max @ +5 Volts
890mA max @ +5 volts
Environmental Requirements
Operating Temperature 0 °C to +60 °C
Storage Temperature -20 °C to +85 °C
Humidity 5 to 95%, non-condensing
Media Capabilities
Play and record
DTMF, tone, speech detection
DTMF, tone generation
Fax
RTP, IP/SIP
Integration with Asterisk, Skype technologies

Note: Typical values.

RoHS
All PIKA products are RoHS compliant.