DS Series IP Guide

DIGITAL TELEPHONE EXCHANGES
12/2010
IP FEATURES GUIDE
DS SERIES
IP FEATURES
GUIDE
NOVEMBER 2010
DS Series IP Features Guide
VERSION TABLE
CPU SOFTWARE VERSIONS
DATE/VERSION OF GUIDE
BAD
AAA/01.12.2010
DS SERIES IP FEATURES GUIDE REV. AAA 01.12.2010

KAREL reserves the right to make modifications in product features mentioned in this document for development
and improvement purposes, without prior notice. Individual products may possess characteristics different from
those that have been mentioned in this document, due to their differences in software and hardware versions.
II
PREFACE
This guide aims to cover all IP related programming in DS Series Systems.
First section is dedicated to basic IP parameters and their controls on a network. They are included in
this guide to be a general guidance to the technical staff who will be putting IP extensions, lines or
gateways into service.
Next sections are totally specific to Karel DS Series Systems and Karels own IP programming
solutions are given. Necessary programming for IP extensions, IP lines and IP gateways are given in
separate sections. The first programming section is dedicated to EX200 MGW Media Gateway card,
which is the backbone of communications as for IP extensions and IP lines.
Last sections describe tools that can used to monitor IP communications in Karel systems and
necessary precautions for secure IP communication.
We wish you a successful programming session.
KAREL Electronics
III
CONTENTS
I. INTRODUCTION................................................................................................................................. 1
II. CONTROLS BEFORE SYSTEM PROGRAMMING .......................................................................... 2
II.1. CONTROL STEPS FOR BASIC COMMUNICATION ..................................................................... 2
II.2. CONTROL STEPS FOR VOICE QUALITY..................................................................................... 5
II.3. CONTROL STEPS FOR NETWORK DEVICES ............................................................................. 6
II.4. BANDWIDTH usage by Karel modules ........................................................................................... 7
II.4. THE LIST OF KAREL MODULES .................................................................................................. 8
III. VoIP GATEWAY............................................................................................................................... 9
III.1. VOIP GATEWAY CARD TECHNICAL SPECIFICATIONS ............................................................ 9
III.2. FUNCTIONS OF A VoIP GATEWAY CARD ................................................................................ 10
III.3. PROGRAMMING ON THE SYSTEM ........................................................................................... 10
III.4. PROGRAMMING on vop gateway card ...................................................................................... 11
III.4.1. NETWORK SETTINGS ............................................................................................................. 11
III.4.2. ADDRESS TABLE .................................................................................................................... 11
III.4.3. CAPABILITY TABLE ................................................................................................................. 11
III.4.4. PARAMETERS ......................................................................................................................... 12
III.4.5. REGISTRATION PROXY.......................................................................................................... 12
III.4.6. WRITE TO EEPROM ................................................................................................................ 12
III.4.7. MORE OPTIONS ON KNEE ..................................................................................................... 12
IV. MGW CARD PROGRAMMING ...................................................................................................... 13
IV.1. MGW CARD TECHNICAL SPECIFICATIONS ............................................................................ 13
IV.2. FUNCTIONS OF A MGW CARD ................................................................................................. 15
IV.3. INTRODUCING the MGW card to the system ............................................................................. 15
IV.4. MGW PROGRAMMING THROUGH KNEE................................................................................. 17
IV.4.1. NETWORK SETTINGS............................................................................................................. 17
IV.4.2. CAPABILITY TABLE................................................................................................................. 17
IV.4.3. PARAMETERS ......................................................................................................................... 17
IV.4.4. WRITE TO EEPROM................................................................................................................ 17
IV.4.5. MORE OPTIONS ON KNEE..................................................................................................... 17
V. IP EXTENSIONS and SIP_SPC MODULE ..................................................................................... 18
V.1. DEFINING IP EXTENSION NUMBERS IN THE SYSTEM ........................................................... 18
V.2. CONFIGURING IP TELEPHONES............................................................................................... 20
V.2. 1. ESSENTIAL Parameters........................................................................................................... 20
V.2.2. ADVANCED Parameters ........................................................................................................... 21
V.3. SIP_SPC MODULE SETTINGS ................................................................................................... 23
V.3.1. NETWORK SETTINGS.............................................................................................................. 23
V.3.2. CAPABILITY TABLE.................................................................................................................. 23
V.3.3. PROTOCOL DEFINITIONS ....................................................................................................... 23
V.3.4. WRITE TO EEPROM................................................................................................................. 23
V.4. SIP EXTENSION FEATURES ...................................................................................................... 24
V.4.1. IP RELATED SERVICES........................................................................................................... 25
VI. SIP_TPC and H323 TRUNK MODULES ....................................................................................... 30
VI.1. DEFINING IP TRUNK NUMBERS IN THE SYSTEM................................................................... 30
VI.2. SIP_TPC / H323 TRUNK MODULE SETTINGS.......................................................................... 31
VI.2.1. NETWORK SETTINGS............................................................................................................. 31
VI.2.2. REGISTRATION PROXY ......................................................................................................... 31
VI.2.3. ADDRESS TABLE .................................................................................................................... 31
VI.2.4. CODEC TABLE ........................................................................................................................ 31
VI.2.5. WRITE TO EEPROM................................................................................................................ 31
VI.2.6. MORE OPTIONS ON KNEE..................................................................................................... 31
VII. MAINTENANCE ............................................................................................................................ 32
VII.1. ETHEREAL WIRESHARK USE............................................................................................... 32
VII.2. SIP LISTENER USE ................................................................................................................... 37
VIII. SECURITY.................................................................................................................................... 39
IV
I. INTRODUCTION
More than billions of people are connected to a network for voice or data transmission. This entire
network structure includes many kinds of telecommunications and switching interfaces like public
exchanges, routers, hubs, switches, satellites
This variety of interfaces automatically brought the need to combine all networks under a main
infrastructure, with an acceptable cost. This is where IP communication comes in with its following
outstanding features:
Data and voice can be transferred over the same infrastructure.
IP communications can use the already available infrastructure for communication between
different locations. Since communication does not take place over conventional telephone
network, the high cost of long distance communication is virtually eliminated
DS series systems can respond to growing IP need as explained in the next sections.
II. CONTROLS BEFORE SYSTEM PROGRAMMING

This section gives steps that you need to control before configuring IP modules on Karel system.
These steps are independent from Karel systems but they are directly affecting the systems
operation. Cooperation with an administrator who has control on / knowledge of the network is
necessary in these steps.
II.1. CONTROL STEPS FOR BASIC COMMUNICATION

The parameters mentioned in this section are the primary settings to control. If they are not
programmed properly for telephones, lines and gateways, the communications will not start properly.
Sections dedicated to each of these modules contain the related programming details.
IP ADDRESSES OF MODULES
Each module that will be involved in the network must have a unique IP address within the network.
If a DHCP server is available on the network, IP telephones can be programmed to get IP
addresses from this server.
MGW and VoIP cards do not have DHCP support on the other hand. So these modules must
be programmed appropriately as per their static IP addresses.
Important: DS Series systems are not able to act as a DHCP server. To use the
DHCP client function of a module connected to the system, a separate DHCP server
is required on the network.
SUBNET MASK
The IP addresses of the modules connected to Karel system must fall within the same subnet of the
default gateway (e.g., router) of the LAN.
GATEWAY ADDRESS
The IP address of the gateway on LAN must be learnt and programmed on the modules connected to
Karel system.
GATEKEEPER / PROXY SERVER

Gatekeepers or SIP Proxy Servers offer extra network management facilities to registered clients.
Some of these facilities are:
Numbers dialed by extensions are routed to the IP addresses (the clients do not have to
decide routes)
Authentication
Bandwidth control
If a gatekeeper exists on the network, EX200 (4VoIP/0), EX200 (8VoIP/0) and EX200 (16VoIP/0)
cards with H323 protocol can be programmed to use this gatekeeper. Similarly, the cards with SIP
protocol can first register to a SIP Proxy Server and make the calls over this server.
NAT USE
If NAT (Network Address Translation) is used on the network and a single IP address is used as the
Internet access point of network, the modules connected to Karel system must be programmed
accordingly. This access point IP address is referred as NAT IP Address.
STUN Use
If your NAT IP address is not static, you can activate STUN on Karel modules. The advantage
of STUN server is not to care about the dynamic (changing) NAT IP address. STUN server will
be giving the appropriate NAT IP address to the module. Thus NAT IP address does not have
to be re-programmed each time the IP address is changed.
Important: The efficiency of STUN depends on functionality of STUN Server. If there is a

failure on STUN Server, communication will not be established due to change of NAT IP
address. So if reliable functionality of STUN server cannot be guaranteed, it is recommended
to obtain a static IP addresses for VoIP communication through modems/router etc. and thus
to use static NAT IP address settings.
RTP Proxy Use

When NAT is used within the network, speech and signaling ports must be separately
forwarded to each IP modules address to establish communication with those IP modules. If
the number of IP modules is high, port forwarding for all IP Modules will be a long process
which is also subject to mistakes. To get over these difficulties, you can activate RTP Proxy
use on your system. In this case, IP modules will not talk from end-to-end with each other;
instead the speech will be carried through RTP proxy and port forwarding will not be needed.
Note: RTP Proxy use for IP extensions can be activated on extension basis from IDEA
Virtual Subscriber settings. On the other hand, KNEE address table is used to activate RTP
proxy use for IP trunks, on route basis.
DNS USE
Depending on the network configuration, Karel modules may be in communication with an external
server to maintain IP communication. If DNS server is activated on the modules, instead of the IP
address of these external servers, their names can be entered on the modules. In such a case, it will
be the DNS server that will convert these names to IP addresses.
VLAN
VLANs are logical segments within a corporate LAN. If such segments are available on the network
and there are IP telephones with 2 ports (primary and secondary) for packet communication, these
ports can be allocated to different VLANs depending on the packet type: voice signal / data. This will
reduce the load on the network and bring efficiency and speed to the communication.
SIGNALLING (TRANSPORT) TYPE

IP modules connected to DS series systems can use UDP (User Datagram Protocol), TCP
(Transmission Control Protocol) or TLS (Transport Layer Security) for signaling. If the module is a
VoIP gateway, the only signaling type is UDP and it cannot be modified. For IP trunks and extensions,
any of these three signaling types can be selected based on the following items:
UDP is commonly used due to its speed: there is no flow control or error correction. This is the
main difference between UDP and TCP. TCP protocol offers a guaranteed delivery due to flow
control mechanism.
The connected parties may ask you for TCP connection. In that case you can activate TCP
signaling on an IP extension or trunk.
An IP extension that uses UDP signaling cannot call an IP extension with TCP/TLS signaling.
Vice versa is also true.
The signaling that will be used in IP trunk applications is flexible and following criteria are
used:
-
The initial communication is started with the signaling programmed as SIP Transport
Type in KNEE program Protocol Definitions menu.
If IP trunk is registered to a Proxy Server, the signaling that will be used during registration
can be programmed in Registration Proxy menu. The default value of this parameter is =
signaling programmed under Protocol Definitions.
Each route in Address Table can have its own signaling type. The default value of this
parameter is = signaling programmed under Protocol Definitions.
Incoming requests with UDP signaling are always accepted.
If TLS or TCP is selected as signalling type at least once in at least one of the Protocol
Definitions, Registration Proxy or Address Table menus, the calls with TLS / TCP
signaling are also accepted.
Another criteria controlled in incoming call requests is the signaling port number. In all
signaling types, the call is not accepted if the signaling port number of that call does not
match the programmed signaling port number in Protocol Definitions menu.
The following examples are given with the assumption that signaling port numbers are in
match:
Example 1:
- Signaling in Protocol Definitions: TCP
- Signaling in Proxy Settings: UDP
- Signaling in Address Table: UDP.
Calls are initiated with UDP signaling. Incoming requests with UDP, TCP and TLS signaling
are accepted.
Example 2:
- Signaling in Protocol Definitions: UDP
- Signaling in Proxy Settings: TCP
- Signaling in Address Table: TLS.
Registration to the Proxy Server is made with TCP signaling whereas access to the target IP
addresses is made with TLS. Incoming requests with UDP, TCP and TLS signaling are
accepted.
Example 3:
- Signaling in Protocol Definitions: UDP
- Signaling in Proxy Settings: UDP
- Signaling in Address Table: UDP.
All communication is made with UDP signalling; other signaling types are not accepted.
Among these signaling types, TLS is the safest. It provides authentication and encryption of
the SIP signaling. The communication is started after a handshake, where various parameters
are agreed for the sake of security. The communication with TLS signalling can be monitored
by sniffers but cannot be decoded.
When sRTP is used, TLS is the recommended signaling type. Otherwise, a sniffer can detect SIP
logs of the communication and detect the encryption method & encryption key.
II.2. CONTROL STEPS FOR VOICE QUALITY

The parameters mentioned in this section are not essential for communication establishment but they
are important to have a high quality communication.
TYPE OF NETWORK
The type of network (being managed or unmanaged) is a key for communication quality.
A managed network (Frame Relay, Virtual Private Network VPN, Leased Line, etc.) is
convenient for VoIP implementations.
An unmanaged network (Internet-ADSL, Internet-VPN) is not recommended for VoIP

communications due to negative effects on speech quality caused by delays and packet
losses.
BANDWIDTH
It is important to check the available bandwidth on your network before activating IP modules on your
DS200 system. If the network is already loaded with other applications (e-mail servers, web
applications, etc.) and if the required bandwidth amount for IP communications is beyond networks
limit, both IP communications and those other applications will suffer decrease in performance,
especially in heavy traffic.
A table is given in the next pages to make a bandwidth evaluation more easily.
TOS
TOS parameter in Karel IP lines and gateways can be programmed to desired values. If the router of
your network is capable of giving a priority based on these TOS values, speech quality can be
improved since the router will give higher priority to voice packets and lower the rate of losses and
delays.
Note: This facility depends on specifications of network router.
ECHO CANCELLATION
The echo in IP communications can be a real trouble due to the topology of the IP networks. The
delays in the communication, the impedance mismatch of analog ports may cause echo on IP calls.
DS200 systems are equipped with advanced echo canceler algorithms and thus echo is not a problem
for DS200. But yet huge delays may decrease the performance of echo canceler so the users may still
hear echo. In such cases, VLAN and other ToS solutions must be considered by the network
administrators.
PACKET CONTROL FEATURES

Karel IP telephones, lines and gateways have packet controlling features like dynamic jitter buffer
(controls delay variations that occur due to different paths traced during transmission) , PLC algorithm
(controls packet loss). If other devices on the network support these features as well, they will make a
positive effect on quality of communications.
Voice Activity Detection (VAD): Being an important packet control feature, it helps to detect silent
periods during a call. Those detected silence periods are not sent to the network, thus bandwidth is
protected. This feature can be supported by the CODEC G729A and must be used at both sides of the
connection.
II.3. CONTROL STEPS FOR NETWORK DEVICES

The parameters mentioned in this section are the controls on the modules that lie within the same
network as Karel systems.
PERMISSIONS
If communication between different networks is also required and conversations with parties at
different ends will be carried out; firewalls, routers and similar network access points have to be
programmed appropriately at each network by network administrators. This programming is nothing
but port forwarding on these devices to the relevant IP modules. A table is given below for this
purpose:
Application Name / Explanation
TCP / UDP
Port Number to be
forwarded
Destination IP
address
For
signaling
between
SIP UDP /TCP/TLS
extensions/lines/gateways
and
WAN,
incoming requests to this port must be
forwarded to local IP address of the
telephone/line/gateway /MGW
5060 /5060/5061
IP address of
telephone, line,
gateway or MGW
For
signaling
between
H323 TCP
lines/gateways and WAN, incoming
requests to this port must be forwarded to
local IP address of the gateway
1720
Line or gateways IP
address
For conversations between SIP telephones UDP

and WAN, incoming requests to this port
must be forwarded to local IP address of
the telephone
Changes
wrt Telephones IP
telephone model
address
For conversations between SIP telephones UDP

and WAN, incoming requests to this port
must be forwarded to local IP address of
MGW
54000
MGW IP address
For conversations between SIP / H323 UDP

gateways and WAN, incoming requests to
this port must be forwarded to local IP
address of gateway
5004
Gateway IP address
For KNEE connection to Karel modules
UDP
14200
Karel modules IP
address
For KNEE connection to Karel modules
TCP & UDP
14201
Karel modules IP
address
12120
Karel modules IP
address
For SIP Listener connection (maintenance) UDP
SWITCH TYPES
To have a qualitative communication, layer 2 or higher switches are recommended. (Hubs increase
the load on the network and this may lead to decrease in speech quality.)
Note: MGW2 cards do not work with GB switch and 10 Mbit hub.
CABLE TYPES
Due to their capacity and isolation quality, CAT 5 or higher cables must be preferred.
Note: Unexpected problems like packet loss can be faced with handmade network cables.
II.4. BANDWIDTH USAGE BY KAREL MODULES

Currently G.711 and G.729 are the supported CODECs in Karel systems and the required bandwidth
depends which one of these is used. If MGW2 card is used, G.723 and iLBC are supported as well
The key points that will help to decide which one of these CODECs will be used are:
G.711 uses 64 kb to transfer 1 second of data whereas G.729 uses 8 kb to transfer the same
amount. This value is 5.3 kb or 6.3 kb for G.723 and 15.2 kb (for frames of 20 sec) or 13.33 (for
frames of 30 sec) kb for iLBC.
Being independent from the CODEC used, each packet contains a header of 54 bytes
approximately.
If as an example 100 voice packets are transferred in a second, just 43.2 kbits (100 voice packets
require 5400 bytes in total and considering 1 byte = 8 bits, this will be 43.2 kbits) will be used by
headers. This will require 51.2 kbps with G.729 whereas 107.2 kbps will be required by G711.
The following table shows the required bandwidth compared to G.729 and G.711 with respect to
different packet sending intervals.
Packet
sending
intervals
10 ms
20 ms
40 ms
Codec
Voice in a second Headers in a

second
Total
G.711
G.729
G.723
Number of
packets in a
second
100
100
100
64 kb
8 kb
5.3 kb or 6.3 kb
43.2 kb
43.2 kb
43.2 kb
iLBC
100
15.2 kb or 13.33
kb
43.2 kb
107.2 kbps
51.2 kbps
48.5 kbps or
49.5 kbps
58,4 kbps or
56,53 kbps
G.711
G.729
G.723
50
50
50
64 kb
8 kb
5.3 kb or 6.3 kb
21.6 kb
21.6 kb
21.6 kb
iLBC
50
15.2 kb or 13.33
kb
21.6 kb
G.711
G.729
G.723
25
25
25
64 kb
8 kb
5.3 kb or 6.3 kb
10.8 kb
10.8 kb
10,8 kb
iLBC
25
15.2 kb or 13.33
kb
10,8 kb
85.6 kbps
29.6 kbps
26.9 kbps or
27.9 kbps
36,8 kbps or 34,
93
74.8 kbps
18.8 kbps
16,1 kbps or
17,1 kbps
26 kbps or
24.13 kbps
Required Bandwidth for a DS200 system

= No. of IP extensions Required Bandwidth for the used CODEC by telephones +
No. of channels of MGW card Required Bandwidth for the used CODEC by MGW card + no of IP
trunk channels x required bandwidth for used codes on trunks.
Example
No. of IP extensions: 20
No. of IP trunks :10
No. of channels of MGW card: 16
Codec: G.729
Packet sending interval: 40 msec
Required bandwidth = [20 x 18.8 kb] + [16 x 18.8 kb] + [10 x 18.8 kb] = 864.8 kbps
II.4. THE LIST OF KAREL MODULES

In the following pages the following Karel IP modules will be explained:
1) VOIP (Voice Over IP) Gateway Module
2) MGW (Media Gateway - IP<>TDM converter) Module
3) IP extensions and SIP_SPC (IP Extension software) Module
4) IP trunks and SIP_TPC (IP Trunk Software) and H323 trunk modules
The programming of these modules requires different media: IDEA, telephones own Web interface
and KNEE. The steps are given with basic information assuming the fact that the programmer is
already familiar to the mentioned programming tools.
III. VoIP GATEWAY

The following sections explain VoIP Gateway card with its different aspects:
-
Its technical specifications
Its functions
Its programming in two phases: programming on the system, programming on VoIP Gateway
card.
VoIP Gateway card is used as an IP trunk card on DS200 systems which does not have IP enabled
CPU cards.
III.1. VOIP GATEWAY CARD TECHNICAL SPECIFICATIONS
There are three different VoIP Gateway cards: EX200 (0/4VoIP), EX200 (0/8VoIP) and EX200
(0/16VoIP). The only difference between cards is the number of channels. Their programming
details are identical.
Each VoIP Gateway card can have either H323 or SIP protocols.
A VoIP gateway module actually consists of two cards: a main board and a CPU card that lies on
top of this main board. The CPU card is identical for all VoIP gateway cards. The main board on
the other side is different as per the number of channel resources.
There are two software files on a VoIP gateway module: main software and u-boot software.
U-boot software is unique for all VoIP gateway modules.
There are 6 different main software files: the software files for EX200 (0/4VoIP), EX200
(0/8VoIP) and EX200 (0/16VoIP). Additionally, the software files that supportH323 and SIP
protocols are different for each capacity.
The main software file can be programmed through KNEE program or through a direct PC
connection via serial port of the card. KNEE offers the option to load u-boot software but it is
recommended to load this software through direct PC connection via serial port of the card for a
more reliable connection.
III.2. FUNCTIONS OF A VOIP GATEWAY CARD

Main function of VoIP Gateway card is to establish connection between your DS200 system and the IP
network. While performing this basic function, the card can be used for two basic functions:
As a direct gateway (without a proxy server) between your exchange and IP network. This use can
be thought of as an IP tie-line connection.
First the card registers to a Proxy Server and the calls to IP network all forwarded to that proxy.
III.3. PROGRAMMING ON THE SYSTEM

The system-side programming for a VoIP gateway card is basically the number routing, namely LCR.
The details of LCR programming are given in DS Series Programming Guide. In this guide, just a
figure is given below:
The remote system extension numbers (in the range 1525 and 1566) are routed to the line 7200,
without any LCR filtering. 7200 is the port number of VoIP gateway card on slot 58.
10
III.4. PROGRAMMING ON VOIP GATEWAY CARD

IP related settings of VoIP Gateway cards are made by KNEE software. KNEE software includes
different parameters in its menus. The following sections are separated as per the KNEE menus.
This section explains the essential parameters for operation of VoIP gateway cards. For other
adjustments, which are rather details of applications, KNEE guide must be referred.
KNEE programming options can vary depending on protocol of card being SIP or H323. The
programming options are explained with the note of the supported protocol.
III.4.1. NETWORK SETTINGS

(Valid for SIP H323 protocols)
This is the place where primary network settings of VoIP gateway card are made.
a) The following settings are essential for the proper operation of VoIP Gateway cards:
-
IP address
Gateway address
Subnet mask
b) If WAN access is required in the communication, NAT IP address must be programmed.

c) The following settings may be programmed if required:
-
TFTP server
DNS & STUN settings (for cards with SIP protocol)
Gatekeeper (for cards with H323 protocol)
III.4.2. ADDRESS TABLE

Address table is the place where numbers dialed by extensions are checked and thus the correct IP
address to forward the call is resolved.
The following fields of this table must be filled out to have a proper IP routing:
-
Numbers
Destination IP address
III.4.3. CAPABILITY TABLE

This table is used to program the codec types that will be used in IP communications and is very critical for
the sake of communication.
If the CODECs on the destination IP address do not match with CODECs on VoIP
gateway card, voice will not be transmitted between parties.
Note: Always use the Capability as Rcv&XmtAudio.
11
III.4.4. PARAMETERS
These parameters control communication specific parameters like receive transmit voice levels, packet
sending intervals, TCP connection settings and delays in passing the packets coming from network.
The following parameters in this menu are important:
-
Gain levels
Fast start. (Available only with H323 protocol.) It must match to the settings of destination.
Otherwise, call request will not be taken into account.
NAT IP address. It must be programmed for cards with H323 protocol if WAN access is required.
(Cards with SIP protocol require this setting in Network Settings Menu.)
RTP_UDP port: 5004 by default. Programming it may be necessary if WAN access is problematic
at speech side.
Signaling port: 1720 for H323 and 5060 for SIP by default. Programming it may be necessary if
WAN access is problematic at signaling side.
III.4.5. REGISTRATION PROXY

(Valid for SIP protocol)
This menu includes parameters required for registration to a Proxy Server. If registration to a server is not
required, you do not have to use this menu at all. One card can be registered to multiple servers at a time.
For mote details on registration to a proxy server, please refer KNEE manual. Please also check the
settings in the Endpoint Settings menu.
III.4.6. WRITE TO EEPROM

This option saves the recent programming changes on the memory of VoIP Gateway card. If not used, the
last settings will not be recalled after the card is powered OFF and ON.
III.4.7. MORE OPTIONS ON KNEE

KNEE program offers more programming options for VoIP Gateway cards. The details of these menus can
be found in KNEE manual. Below, their brief descriptions are given.
a) Protocol definitions (valid for SIP protocol): Detailed parameters like T1- T2 retransmission times,
session expiring durations, DTMF settings can be programmed.
b) Routing settings (valid for SIP protocol): Alternative routes for various erroneous cases (like Ping or
QoS errors) can be programmed.
c) KNE user accounts (valid for SIP protocol): Different user accounts can be defined to program or
view VoIP Gateway cards.
d) Manipulation tables (valid for SIP protocol): Called and calling party numbers can be modified if the
desired extension makes a call and/or a desired number is called. The modification is to add or
delete digits from the front or end.
e) Status and diagnostic (valid for SIP protocol): KNEE also offers basic monitoring options.
f)
Software update: Recommended only for upgrade of main software. This option should not be
used for u-boot software upgrade.
12
IV. MGW CARD PROGRAMMING

The following sections explain MGW card with its different aspects:
-
Its technical specifications
Its functions
Its programming in two phases: programming on the system, network programming on MGW card.
IV.1. MGW CARD TECHNICAL SPECIFICATIONS

There are two types of MGW cards: MGW and MGW2.
MGW card:
MGW and EX200 (16 VoIP/0) cards are identical except for their main software and their appearance on
IDEA Configuration window. The following items are comparison of these two cards:
Their cards are identical in hardware
Their CPU cards are identical (the small cards that lie on the main cards)
Their u-boot software is identical
Their software upgrade methods are identical (either by IP connection over KTFTP server or
HyperTerminal connection through serial part)
But,
Their main software is different.
Their appearances are different.
MGW2 card:
MGW2 and MGW cards have different hardware/software and they are different in terms of technical
specifications as well.
MGW2 card has two slots for blackfin cards. Each blackfin card can have one or two DSP chips. Each
DSP chip has 12 speech channels; hence a single MGW2 card can support 48 speech channels. This
number is 16 for MGW card.
MGW2 communicates with master software over Ethernet.
MGW card supports G.711, G.729 and G729AB CODECs whereas MGW2 card supports G.711,
G.729, G729AB, G723, iLBC and T38.
MGW card does not support encrypted speech, namely sRTP whereas MGW2 card supports the
same. Usage of sRTP is subject to authorization and 2 speech channels are used in sRTP speeches.
(48 channel of MGW2 card can be used when sRTP is used.)
DSP chips on MGW2 card can be configured as RTP proxy. Thus signaling and speech will be made
through different servers.
13
14
IV.2. FUNCTIONS OF A MGW CARD

Main function of MGW cards is to carry speech between IP and non-IP components of Karel system.
For MGW card, communication with non-IP components is established over the PCM channels of
backplane. For MGW2, all communication is made over Ethernet.
(IP components: IP extensions, IP lines
Non-IP component: All of the remaining components: analog/digital extensions/lines, IP gateways.)
Additionally, location of MGW card on the system is used as the node of IP extensions / lines. Therefore,
before introducing IP extensions and IP lines to the system, it is necessary to introduce a MGW card to
have speech between IP and TDM ports.
IV.3. INTRODUCING THE MGW CARD TO THE SYSTEM

Once the MGW card is installed on the system, it is necessary to specify its slot location in following steps.
Go to Virt. Sbsc. Settings menu on IDEA.
Press Branch Exchange Node Table.
Enter the starting ending port numbers of MGW card and select the application that will use this
MGW card as a node: SIP for IP extensions, IP trunk for IP lines. (If the same card will be used both
for SIP extensions and trunks, the same port numbers must be defined at different rows as SIP and IP
trunk.)
15
* HINT: Starting and ending port numbers of a MGW card can be seen by
pointing the mouse pointer on it in Configuration window.
16
IV.4. MGW PROGRAMMING THROUGH KNEE

IP settings of a MGW card are made over KNEE program, just like a regular VoIP Gateway card.
IV.4.1. NETWORK SETTINGS

Program the following fields on this menu:
-
IP address
Gateway address
- Subnet mask
If you want to upgrade MGW card software through KNEE, also program TFTP server IP address.
IV.4.2. CAPABILITY TABLE

This table is used to program the codec types that will be used in IP communications and is very critical for
the sake of communication between IP and non-IP modules of the system:
If the IP components that will be in communication with the system have different
CODECs from the CODECs of MGW card, the communication between Non-IP and IP
ports will not be established.
Note: On MGW card, always use the Capability as Rcv&XmtAudio.
IV.4.3. PARAMETERS
These parameters control communication specific parameters.
The following parameters in this menu are important:
-
Gain levels
RTP_UDP port: 5004 by default. Programming it may be necessary if WAN access is problematic
at speech side.
IV.4.4. WRITE TO EEPROM

This option saves the recent programming changes on the memory of MGW card. If not used, the last
settings will not be recalled after the card is powered OFF and ON.
IV.4.5. MORE OPTIONS ON KNEE

The details of other KNEE menus can be found in KNEE manual.
17
V. IP EXTENSIONS and SIP_SPC MODULE

The following sections explain the programming steps of IP extensions:
-
Introducing IP extension numbers to the system
Configuring IP telephones to connect to the system
SIP_SPC module settings.
Prior to these programming steps, a MGW card that is programmed as SIP node type
must be available on the system refer the previous section.
V.1. DEFINING IP EXTENSION NUMBERS IN THE SYSTEM

IP extension numbers can be defined from Virt. Sbsc. Settings menu on IDEA. It is necessary to fill out
following fields:
Access code: The access code of the SIP extension (the telephone number of the IP phone).
Node number: The index for the MGW card. This is the row number on Branch Exchange Node Table
where MGW location is programmed as SIP.
IP Number Usage: If this is programmed as changeable, any IP telephone can register to the system with
this access code. If it is programmed as fixed, the system requires the telephone to have the IP address
as programmed in IP # field.
SIP password: IP extensions are required to have a password during registration. The default value of this
password is abcdefgh12345678.
Authentication Control: If programmed as at registration, password from an IP extension is required only
during its registration. If programmed as at registration and incoming calls, password is required in each
call attempt as well.
RTP Proxy Mode: RTP Proxy use for an IP extension is programmed within this field. When it is adjusted
as automatic, RTP Proxy will be used only if the IP extensions is registered behind NAT (if it is an internal
IP extension RTP Proxy is not used). Other programmable options are always and never.
Other fields in this table are for maintenance purposes. They cannot be edited.
Port #: The SIP signaling port number of the extension. This is entered from telephone and the system
programming does not have any effect.
Registered: Shows if the IP extension with the given access code is registered to the system or not.
IP#: IP address of the phone. Must be entered if the IP Number Usage parameter is chosen as Fixed.
The IP address of the IP phone is automatically obtained during registration and written here if the same
parameter is chosen as Changeable.
18
REGISTRATION PRINCIPLES
It might be useful to list down some registration principles of the system to visualize the system capabilities
better:
The system does not register multiple IP addresses with the same access code.
In case of a register request from an IP extension the system checks following points:
-
Is the telephone number defined as an extension number? If no, the request is denied. If yes,
Does the request contain correct password? If no, request is denied. If yes,
- (If IP number usage: fixed) Does the request come from correct IP address? If not
request is denied.
If the answers to all of these points are YES, then the IP extension is registered to the system.
The IP extensions can stay registered to the system for a certain period. This period is called
REGISTRATION PERIOD and it is programmed from the telephone. At the end of this period,
registration is terminated by the DS200 system.
If registration period is too short, registration process will cause extra traffic on the system. I the
duration is too long, the system may try to reach this extension considering that it is still registered
even when the Ethernet connection does not exist. So, an optimum value must be used here.
Within registration period, the system keeps access code, node number, fixed/changeable IP use, SIP
signaling port number, password, authentication control method and register status of the IP extension
in its memory. If the system is required to re-start within this registration period, the extension will be reregistered from these settings.
Once an IP telephone is registered to the system, it becomes an extension and its parameters can be
programmed through IDEA just like a TDM extension.
19
V.2. CONFIGURING IP TELEPHONES

V.2. 1. ESSENTIAL PARAMETERS
In order to register to a Karel system, the following adjustments are necessary on an IP telephone:
SIP server address: The IP address of the Karel system must be programmed as SIP server of the
telephone. This IP address is the IP address of the Ethernet port on CPU card of your system which is
used by the SIP_SPC software.
SIP ID: The access code that will be used as extension number must be programmed as SIP ID of the
telephone.
SIP (authentication) password: The password defined in Virt. Sbsc. Settings menu (which is
abcdefgh12345678 by default) must be programmed as SIP password.
CODECs: At least one CODEC used by the telephone must match with a CODEC from MGW cards list.
Example from NT32I:
1. Write the IP address of the telephone on Web browser and open Web interface of the telephone.
20
2. Go the protocol settings and enter the required parameters.
3. Set CODECs.
V.2.2. ADVANCED PARAMETERS

Depending on the requirements some extra settings might be necessary as well. These settings will appear
during use of the telephone as an extension of the system. Some might be required due to network settings
whereas some might be required by the system. The most common ones are listed below:
SIP and RTP port numbers: These port numbers are used if a call comes from WAN to this IP telephone.
The firewall router (or similar network device) must be programmed such that the call requests for this
port must be forwarded to the IP address of this telephone.
21
Register period: This is the duration that the system will store parameters of the IP telephone in its
memory.
DTMF settings: If you want to use Leave Message feature of your system, you must activate In-band
DTMF setting. This might appear as SIP info in some telephones.
PRACK: This is a standard SIP feature that stands for acknowledge for provisional messages (like ringing).
It does not require any extra setting on Karel system side.
User Name: This name is shown in the calls between two IP telephones. If another name is given through
IDEA port parameters, IDEA name will be used.
IMPORTANT:
For some SIP telephones, pressing Save or OK is not enough to activate
programming changes. They may also require telephone restart. Existence of such a
requirement must be checked from the telephones manual.
22
V.3. SIP_SPC MODULE SETTINGS

Depending on your network requirements or specifications, you may need to activate extra settings on your
system. These IP related settings are saved in configuration file, which is named as SIP_SPC.CONF.
Again, KNEE is the interface to enter settings to the SIP_SPC.CONF file.
V.3.1. NETWORK SETTINGS

The IP address of the CPU card must be entered. Normally this will be same IP address with the one you
have entered while running KNEE program.
If WAN access is required in the communication, NAT IP address must be programmed.
DNS & STUN settings can be programmed if required.
V.3.2. CAPABILITY TABLE

This is nothing but a list that contains list of CODECs used in IP communications in your system.
V.3.3. PROTOCOL DEFINITIONS

Detailed parameters like T1- T2 retransmission times, PRACK usage, session expiring durations, DTMF
settings can be programmed.
V.3.4. WRITE TO EEPROM

This option is required to save the recent programming changes. If not used, the last settings will not be
recalled after the system is powered OFF and ON.
23
V.4. SIP EXTENSION FEATURES

SIP extensions can use various features as extensions of your system. Some of these features are the
ones defined by SIP standards, whereas some of them are facilities of Karel DS series systems. In
other words, some of the usable features can only be used when SIP telephones are registered to
Karel DS series systems.
Some of DS series features, which can also be used by SIP extensions, are listed below:
- Marked External Call
- Call Back
- Account Coded Call
- Leaving message to other extensions
- Forced Account Coded Call
- Parked Call Retrieve
- Marked and Forced Account Coded Call
- Conference
- Changing forced account code password
- Listening to messages
- Password dialing from another extension
- Door opener
- Chief-Secretary Mode
- Name display
- Last Number Auto-Dial
- PBX group log-in / log-out
- Redial
- Call pick up
- Password define/change
- Group call pick up
- Phone lock
- Group external call pick up
- External calls from locked phone
- Line-line connection
- Reminder Service (with without message)
- Time/date setting
- Temporary Permanent Absent Message
- Alarm service
IMPORTANT:
SIP telephones support features only in N-block dialing mode.
Examples:
1. In order to define the password as 1234, SIP telephone must first enter the digits 8361234 and
then send these digits.
2. To start an external call using the account code 116, SIP extension must enter the digits 797116
and then send these digits.
For some of the DS series features, activation methods of SIP extensions are slightly different from the
methods of TDM extensions. These facilities are noted below:
LEAVING MESSAGE TO OTHER EXTENSIONS
SIP telephones cannot leave message to a ringing extension. They can leave messages to other
extensions only by pressing 6 after receiving Busy or No Answering menu of ACD. Both the called
extensions and calling SIP extensions must have the necessary permissions to use EVM menus.
CONFERENCE
SIP telephones can start conference by first pressing * and then putting the call on hold, as shown in
the sequence below
24

-
Call first party.
Press *. The speech will continue.
Hold the call with the respective key on the phone.
Call second party.
After talking to second party, press *. Conference will start. To include more extensions you can
hold the ongoing conference, and include more parties with *.
CALL BACK
SIP telephones can use this feature as follows:
- To activate Call Back: 811 + access code
- To deactivate Call Back: 810 + access code
When Call Back call will be realized, while the called party is ringing, SIP extension is kept on hold. As
soon as called party answers the call, connection with SIP extension is realized.
V.4.1. IP RELATED SERVICES

In addition to the features that can be used by TDM extensions, there are some facilities defined by
SIP standards and they can only be used by SIP extensions of your system. These features are given
below with related notes to use them.
IMPORTANT:
PRESENCE and INSTANT MESSAGING facilities can ONLY be used if the system
has the required license. Please contact Karel to have the required licenses.
PRESENCE
Provided that the system has the required license, IP extensions can see the status of other
extensions, if they are programmed accordingly. The system can broadcast 60 presence information
at a time.
Note: For the IP telephone models that do not support presence facility, if BLF lamps are available on
the phone, those LEDs can show status of other ports as Busy / Idle.
-
IP extensions send their current status to the system with PUBLISH messages. (Defined by RFC
3903.)
IP extensions ask for the status of other IP messages with SUBSCRIBE messages. The system
then send the status of extensions to the requesting parties by NOTIFY messages. (Defined by
RFC 3265.)
Once the necessary programming steps are traced, the following status of extension can
automatically be viewed by the requesters:
Idle,
On the phone,
Ringing,
Busy (defined by user),
Away (defined by user),
Idle (appears automatically after some period defined by the user) and
Off-line.
The IP extensions can also define a message that will appear along with this status. (Defined by
RFC 3863.)
The following figures are given to illustrate Presence activation steps, on a softphone.
25
a. First step: Send current status to the system by registering to the Present Agent, which is a part of
SIP_SPC.
b. Second step: Ask for status information of extensions. You can ask status of non-IP extensions as
well as IP extensions.
c. Application: See the status of extensions.
26
27
INSTANT MESSAGING
Provided that the system has required licenses, two IP telephones can send messages to each other
as per standards defined by RFC 3428.
-
The messages that cannot be sent are stored in a database server.
The default size of this database is 500 Kbytes.
The size of this database is controlled within each 50 minutes. If the size of the database has
reached 80% of 500 Kbytes, then the older messages are erased until the size is reduced down to
50% of 500 Kbytes.
As the unsent messages are stored in the database, if the target IP extension is not registered at
that moment, he will be able to receive his messages after his registration.
SIP_SPC.CONF program can be used to control the database, with the following commands. If
these commands are not typed in SIP_SPC.CONF file, the default values will be used.
db_ipaddr: Normally the database server and SIP_SPC are on the same location. If required,
a separate address can be used as database server. In that case, this command must be
used to define this address.
mess_db_size: Size of the database (in KB) is defined with this command. (Default = 500
Kbytes)
mess_db_upper_limit: The highest limit (in %) is defined with this command. (Default = 80%)
mess_db_lower_limit: The minimum limit (in %) is defined with this command.( Default =
50%)
A view of SIP_SPC.CONF file is given below:
VIDEO CALLS
Video calls can be established if the used IP telephones have video support. Any of the video codes H263, H263-1998, H.264 (low quality),H.264 (high quality) - can be used for video calls.
28
SESSION TIMER
Session timer is a method to check the continuity of the calls. If the telephones hang up unexpectedly
(disconnection of Ethernet cable, power failure etc.), this can be detected within a session interval
duration and the call can be terminated
When session timer is activated, the participants first agree on the session interval, and then the party
that will control the process is decided. The responsible side sends UPDATE and INVITE messages
within session interval. If no answer is detected, the call is terminated.
-
Session timer can be defined on IP telephones if desired. However, SIP_SPC already uses 300
seconds as session interval.
When both parties have session intervals with different duration, the valid session interval will be
the interval of called party.
The first UPDATE and INVITE messages are sent at the half of session interval. (e.g. if session
interval is decided as 500 msec, UPDATE and INVITE messages are sent at each 250 msec.)
SIP_SPC.CONF program uses the following commands to control session timer facility. If these
commands are not typed in SIP_SPC.CONF file, the default values will be used.
session_Interval: Session interval duration (in seconds) that will be used by SIP_SPC.
(Default = 300 sec)
mins_SE: The minimum value that can be accepted as a valid session interval by SIP_SPC.
(Default = 90 sec)
A view of SIP_SPC.CONF file is given below:
29
VI. SIP_TPC and H323 TRUNK MODULES

IP trunk application is a better version of VoIP Gateway application. The differences between these
two applications can be listed as follows:
A VoIP gateway application requires a dedicated card (VoIP Gateway card). IP trunk application
does not need any hardware. It uses of MGW card, only when TDM extensions will use IP trunks.
VoIP gateway cards carry both media and signaling. On the other hand, in an IP trunk application,
signaling is made through IP trunk and media is transmitted through MGW (in TDM calls) or
directly between IP nodes.
The following sections explain the programming steps of IP trunks.

-
Introducing IP trunks to the system
SIP_TPC module or H323 trunk module settings.
Prior to these programming steps, a MGW card that is programmed as IP trunk node
type must be available on the system refer the previous section.
VI.1. DEFINING IP TRUNK NUMBERS IN THE SYSTEM

Defining IP trunk numbers is nothing but to define new access codes in IP Trunks section of ports
list. The only difference from regular analog / digital lines is just one parameter:
Node number: The index for the MGW card. This is the row number on Branch Exchange Node
Table where MGW location is programmed as IP Trunk.
30
VI.2. SIP_TPC / H323 TRUNK MODULE SETTINGS

KNEE is the interface to enter extra settings for IP trunks, including network adjustments, address
routing etc. These settings are almost identical to VoIP gateway cards.
st
KNEE settings for H323 trunks are made through 1 ethernet port of CPU card.
KNEE settings for SIP_TPC are made through 2
nd
ethernet port of CPU card.
VI.2.1. NETWORK SETTINGS

The IP address of the CPU card must be entered as Master IP address. This is the address of the
second Ethernet port on your CPU card.
If WAN access is required in the communication, NAT IP address must be programmed.
DNS & STUN settings can be programmed if required.
VI.2.2. REGISTRATION PROXY

This menu includes parameters required for registration to a Proxy Server. An IP trunk can be
registered to multiple servers at a time. If registration to a server is not required, you do not have to
use this menu at all. For mote details on registration to a proxy server, please refer KNEE manual.
Please also check the settings in Endpoint Settings menu.
VI.2.3. ADDRESS TABLE

The routing of dialed numbers to the desired destination IP addresses must be programmed, just like
a VoIP Gateway card.
VI.2.4. CODEC TABLE

This is nothing but a list that contains list of CODECs used in IP communications in your system.
VI.2.5. WRITE TO EEPROM

This option saves the recent programming changes. If not used, the last settings will not be recalled
after the system is powered OFF and ON.
VI.2.6. MORE OPTIONS ON KNEE

KNEE program offers more programming options for IP trunks. The details of these menus can be
found in KNEE manual. Below, their brief descriptions are given.
a) Protocol definitions (valid for SIP protocol): Detailed parameters like T1- T2 retransmission
times, session expiring durations, DTMF settings can be programmed.
b) Routing settings (valid for SIP protocol): Alternative routes for various erroneous cases (like
Ping or QoS errors) can be programmed.
c) KNE user accounts (valid for SIP protocol): Different user accounts can be defined to program
or view VoIP Gateway cards.
d) Manipulation tables (valid for SIP protocol): Called and calling party numbers can be modified
if the desired extension makes a call and/or a desired number is called. The modification is to
add or delete digits from the front or end.
e) Status and diagnostic (valid for SIP protocol): KNEE also offers basic monitoring options.
31
VII. MAINTENANCE
The IP system, unlike the conventional circuit switched communication systems, uses common
resources with the data network of the companies. Therefore, the maintenance of a data network and
the voice network have a lot in common.
The IP traffic density on the system is related to the bandwidth of the IP infrastructure (as explained in
the previous sections) and to the processing power of the server used for SIP_SPC and SIP_TPC
applications.
On the CPU card of a DS series system with the PPC 850 processor, simultaneously 128x128 IP
extensions (256 IP extensions in total) and 100 IP trunks can be used. However, if an external PC is
used as the SIP_SPC and SIP_TPC servers, the simultaneous communication channel number
increases depending on the processing power of the used server. It is highly recommended to
calculate the required traffic density and depending on this calculation, select an appropriate server for
the IP applications.
As the server is setup and run, the run time of the IP system may require some on-line monitoring for
bandwidth utilization, packet loss rate, delays and etc. IT departments generally have such monitoring
tools. If not, such tools should be obtained for proper maintenance capabilities.
In case of a problem on any IP module, IP monitoring will be required. Based on these logs Karel will
be able to give assistance. Karel systems offer two tools for monitoring:
Use of an open source program (Ethereal or Wireshark). This requires connection to the
monitored destination over a HUB or programmable switch (with port mirroring feature).
Use of Karel SIP listener program. This can be used for IP applications with SIP protocol, if a Hub
or programmable switch is not available.
VII.1. ETHEREAL WIRESHARK USE

Ethereal (or Wireshark) is actually a network analyzer. To be able to receive IP packets, the Ethereal
must be running on a PC that is in connection to the monitored destination (e.g. Karel MGW card) via
a Hub. If Hub is not available, a programmable switch can also be used. In that case, the PC must be
connected to a port that is listening to other ports on switch. This is called port mirroring and a
sample snapshot for port mirroring is given below.
32
If an Ethereal running PC is connected to port 1 of this switch, incidents from ports 3, 4, 5,8 can be
monitored. An Ethereal log file can be retrieved in following steps:
1. Run the program and click the second icon on the main window.
2. On Capture Options window, select network interface of your PC.
3. On the same Capture Options window activate all Display Options.
33
34
4. Again on the same Capture Options press Start button.
5. IP messages will appear on the main window:
35
6. After recording the instance, stop the recording from Capture menu or stop icon in the main
window.
7. Save your recordings to a file from File menu or save icon in the main window and then send that
file to Karel.
36
VII.2. SIP LISTENER USE

SIP Listener is a module of KARELNET program, which is prepared for maintenance purposes. It
monitors the signaling on the Karel IP modules (with SIP protocol). For the cases where Hub or
programmable switch is not available for Ethereal logs, logs of even just the signaling part can provide
valuable data.
The use of SIP Listener is really simple with few steps:
1. Open KARELNET and run its SIP Listener option.
2. Open Properties menu and enter the following options. Press Save and then exit the window.
37
3. Type the IP address of the Karel module that you will monitor.
4. Press Start and check that the box Conn. has turned green to indicate the successful connection.
Messages will appear on the left side of the window. These messages will be stored in the files that
automatically form under the directory SIPLOGS. The files can be distinguished from date & IP
address of the module. Send all of these files to Karel.
38
VIII. SECURITY
When it comes to IP communication, to offer a secure communication becomes a very critical
requirement. On user side (in other words end points like IP extensions or IP trunks), security
assurance is simpler: The end user can use sRTP protocol for speech and TLS for signaling for a
secure communication
There are controls on Karel DS series systems that facilitate secure communication. These controls
are operational even in the absence of sRTP / TLS. Similar controls can be activated on the network
components that lie outside Karel system.
This section explains these controls. If these controls are not taken into account, hackers can make
use of the resources of your communication system out of your control which may be harmful.
CONTROLS ON NETWORK
If Internet access is available on a network, following steps must be controlled with network
administrator of the installation site. (If a closed network like point-to-point VPN is used, these controls
are not required.)
Modems/routers that are used as Internet access points must have extra capabilities of at
least a simple firewall and must be able to handle IP port forwarding.
Static IP must be a pre-requisite for the parties that will be reaching the modem firewall. On
the system side, modem firewall must be configured to accept requests coming only from
these known static IP addresses.
The maintenance passwords of ADSL modems must be changed to a different password from
the factory default. A password of at least 8 characters with at least 2 letters must be used.
80 port of modems that can normally be managed from Web must be closed.
th
Important: Controls that can be made on Karel side are not totally eliminating the
possibility of unauthorized access. The guaranteed solution against this risk is to use
a closed network structure (VPN access).
CONTROLS ON SYSTEM
To disable unauthorized system access through IP network, following settings must be activated on
IDEA:
PABX passwords must be defined from Security Operations menu of IDEA. Thus, each IDEA
user that will be connected to the system has to first enter the systems password.
When LCR is used, LCR routes that are used to access PSTN lines must have access levels
greater than 0.
When LCR is not used, the system must be configured to refuse external call requests coming
from VoIP gateways or IP trunks.
(Whenever possible) If LCR is not used, line access of port 0 must be prohibited.
If the system is using a LAN adaptor card, IP addresses that can connect to your system for
IDEA, KNEE or Net-CM programs must be determined through a local KNEE connection.
CONTROLS ON VOIP GATEWAY IP TRUNK

To disable unauthorized system access through IP network, following settings must be activated on
KNEE:
A KNEE of version AAQ or better must be used to activate password. A password of at least 8
characters with at least 2 letters must be used.
Apply IP Security must be enabled from Protocol Definitions menu on KNEE. With this
setting, only the IP addresses that exist in target list of Address table can reach VoIP gateway
39
or IP trunk. (This setting is available with AAT and AAS software versions of new and old type
VoIP gateway cards.)
It is recommended to change the default signaling port 5060 to another unused port value if
possible throughout the whole network.
40
12/2010
IP FEATURES GUIDE

DS Series IP Guide

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

DS Series IP Guide

Hochgeladen von

Copyright:

Verfügbare Formate

DIGITAL TELEPHONE EXCHANGES

DS Series IP Features Guide

DS SERIES IP FEATURES GUIDE REV. AAA 01.12.2010

DS Series IP Features Guide

DS Series IP Features Guide

DS Series IP Features Guide

Data and voice can be transferred over the same infrastructure.

DS Series IP Features Guide

II. CONTROLS BEFORE SYSTEM PROGRAMMING

II.1. CONTROL STEPS FOR BASIC COMMUNICATION

GATEKEEPER / PROXY SERVER

DS Series IP Features Guide

Important: The efficiency of STUN depends on functionality of STUN Server. If there is a

RTP Proxy Use

SIGNALLING (TRANSPORT) TYPE

DS Series IP Features Guide

DS Series IP Features Guide

II.2. CONTROL STEPS FOR VOICE QUALITY

An unmanaged network (Internet-ADSL, Internet-VPN) is not recommended for VoIP

PACKET CONTROL FEATURES

DS Series IP Features Guide

II.3. CONTROL STEPS FOR NETWORK DEVICES

For conversations between SIP telephones UDP

For conversations between SIP telephones UDP

For conversations between SIP / H323 UDP

For KNEE connection to Karel modules

For KNEE connection to Karel modules

TCP & UDP

For SIP Listener connection (maintenance) UDP

DS Series IP Features Guide

II.4. BANDWIDTH USAGE BY KAREL MODULES

Voice in a second Headers in a

Required Bandwidth for a DS200 system

DS Series IP Features Guide

II.4. THE LIST OF KAREL MODULES

DS Series IP Features Guide

III. VoIP GATEWAY

Its technical specifications

III.1. VOIP GATEWAY CARD TECHNICAL SPECIFICATIONS

U-boot software is unique for all VoIP gateway modules.

DS Series IP Features Guide

III.2. FUNCTIONS OF A VOIP GATEWAY CARD

III.3. PROGRAMMING ON THE SYSTEM

DS Series IP Features Guide

III.4. PROGRAMMING ON VOIP GATEWAY CARD

III.4.1. NETWORK SETTINGS

b) If WAN access is required in the communication, NAT IP address must be programmed.

DNS & STUN settings (for cards with SIP protocol)

Gatekeeper (for cards with H323 protocol)

III.4.2. ADDRESS TABLE

III.4.3. CAPABILITY TABLE

DS Series IP Features Guide

III.4.5. REGISTRATION PROXY

III.4.6. WRITE TO EEPROM

III.4.7. MORE OPTIONS ON KNEE

DS Series IP Features Guide

IV. MGW CARD PROGRAMMING

Its technical specifications

IV.1. MGW CARD TECHNICAL SPECIFICATIONS

Their cards are identical in hardware

Their u-boot software is identical

Their main software is different.

Their appearances are different.

MGW2 communicates with master software over Ethernet.