SIP@Net Server CE Manual

SIP@Net Server
Customer Engineer Manual
Issue : January 2012

A Publication of
NEC Nederland B.V.
HILVERSUM, THE NETHERLANDS
Date : January 2012
Great care has been taken to ensure that the information contained
in this handbook is accurate and complete. Should any errors or
omissions be discovered or should any users wish to make
suggestions for improving this handbook, they are invited to send
the relevant details to:
NEC Nederland B.V.

P.O. BOX 32
1200 JD HILVERSUM
THE NETHERLANDS
© NEC Nederland B.V.

All rights are reserved. Reproduction in whole or in part is
prohibited without the written consent of the copyright owner.
All brand names and product names in this document are
trademarks or registered trademarks of their respective companies.
CONTENTS
PREFACE ................................................................... 3
1. INTRODUCTION ........................................................ 5
2. SIP@Net SERVER ...................................................... 6

2.1. INTRODUCTION................................................................................... 6
2.2. SIP@Net SERVER - FAULT TOLERANT SOLUTION ..................................... 9
2.3. SIP@Net SERVER IN MORE DETAIL ...................................................... 11
2.4. MEDIA SERVER ................................................................................. 12
2.4.1. Media Server for Add-on Conference .................................................... 13
2.4.2. Media Server for Progress Tones.......................................................... 13
2.4.3. Media Server for Break-in ................................................................... 13
2.4.4. Media Server for Announcements ........................................................ 13
2.4.5. Media Server for Music On Hold ........................................................... 13
2.4.6. Media Server for Recognition of RFC 2833 DTMF-digits ........................... 14
2.4.7. G.729 Support by Media Server ........................................................... 14
2.4.8. Non-Peer-to-Peer Media for SIP Trunk .................................................. 14
2.4.9. Constraints of the Media Server ........................................................... 15
2.5. MULTI PARTY CONFERENCE ON SIP@Net SERVER ................................. 15
2.5.1. Multi Party Conference Using the Trunk Interface .................................. 16
2.5.2. Multi Party Conference Using the Extension Interface ............................. 17
2.6. LICENSING ....................................................................................... 19
2.7. (REMOTE) DONGLE ............................................................................ 21
2.8. MAINTENANCE ASPECTS .................................................................... 22
2.9. JOURNALLING OF DYNAMIC DATA ....................................................... 23
2.10. PREPARATION ................................................................................... 26
2.10.1. Multiple Ethernet Cards ...................................................................... 26
2.10.2. Configuring and Dimensioning the Media Server .................................... 26
2.10.3. BOUNDARIES .................................................................................... 28
2.11. INSTALLATION .................................................................................. 29
2.11.1. Installation of SIP@Net on the Server .................................................. 29
2.11.2. Installation of the SIP Driver ............................................................... 36
2.11.3. Installation of the Media Server ........................................................... 41
2.11.4. Installation of the Tools for the SIP@Net Server .................................... 47
2.12. TELNET IN WINDOWS 2008 ................................................................ 53
2.13. INSTALLATION OF THE REMOTE DONGLE SERVER (Optional) .................. 54
2.14. INSTALLATION OF THE SIP TERMINALS CONFIGURATION
TOOL (Optional) ................................................................................ 59
2.15. RELEASE IDENTIFICATION.................................................................. 63
2.16. UPGRADE (DOWNGRADE) SCENARIO ................................................... 64
2.17. DIAGNOSTIC TOOLS .......................................................................... 65
2.17.1. Simple Alarming ................................................................................ 65
2.17.2. System Info Console .......................................................................... 67
2.17.3. Diag@Net ......................................................................................... 68
2.17.4. Windows Event Viewer ....................................................................... 70
2.17.5. Create a System Dump by External Trigger........................................... 71
2.18. SIP@Net MOBILTY ACCESS (SMA) ....................................................... 72
-1-
3. IP-PM ..................................................................... 74
3.1. INTRODUCTION................................................................................. 74
3.2. PROJECTING ASPECTS ....................................................................... 77
3.3. CLOCK REFERENCE IN IP-PM............................................................... 79
3.4. PMC-SIC / SIC BOARD ....................................................................... 79
3.4.1. PMC-SIC ........................................................................................... 79
3.4.2. SIC ................................................................................................ 80
3.4.3. PMC-SIC / SIC INTERFACES ................................................................ 81
3.4.4. PMC-SIC / SIC LEDS .......................................................................... 81
3.5. HOW TO INSTALL / PROJECT THE IP-PM ............................................... 83
3.6. CLASSIC DECT IN MULTIPLE IP-PMs..................................................... 86
4. IN SYSTEM GATEWAY (ISG) .................................... 88

4.1. PROJECTING THE ISG ........................................................................ 88
4.2. ISG OPERATION WITHOUT DHCP AND TFTP SERVER .............................. 92
4.3. UPGRADING OF ISG FIRMWARE PACKAGE ............................................ 93
4.4. ISG LEDS ......................................................................................... 93
A. BOUNDARIES .......................................................... 94
B. SIMPLE NETWORK MANAGEMENT PROTOCOL ......... 97
C. SPECIFICATIONS FOR SIP@Net SERVER ............... 102
D. SIP@Net SERVER LIMITATIONS ............................ 105
E. OPEN SOURCE LICENSE ACKNOWLEDGMENT ........ 106

E.1. oSIP libraries .................................................................................. 106
E.2. PWLib libraries ................................................................................ 106
E.3. OpenTLS libraries ............................................................................ 106
E.4. PJSIP (PJMEDIA) ............................................................................. 106
E.5. Open H323 and PWLib ...................................................................... 106
E.6. TLS ................................................................................................ 107
E.7. SRTP .............................................................................................. 109
-2-
PREFACE
This manual is valid for the SIP@Net Server running SIP@Net 4.5 or higher.
It contains all relevant aspects of the SIP@Net Server and the IP-PM. The new
functionality, the installation aspects and an upgrade scenario are described in this
manual. For specific installation details please refer to the "PM/CSM Shelf 19 Inch"
Installation Manual.
-3-
PRODUCT DISPOSAL INFORMATION (EN)
For countries in the European Union
The symbol depicted here has been affixed to your product in

order to inform you that electrical and electronic products
should not be disposed of as municipal waste.
Electrical and electronic products including the cables, plugs and

accessories should be disposed of separately in order to allow proper
treatment, recovery and recycling. These products should be taken
to a designated facility where the best available treatment, recovery
and recycling techniques are available. Separate disposal has
significant advantages: valuable materials can be re-used and it
prevents the dispersion of unwanted substances into the municipal
waste stream. This contributes to the protection of human health and
the environment.
Please be informed that a fine may be imposed for illegal disposal of electrical and
electronic products via the general municipal waste stream.
In order to facilitate separate disposal and environmentally sound recycling
arrangements have been made for local collection and recycling. In case your
electrical and electronic products need to be disposed of please refer to your supplier
or the contractual agreements that your company has made upon acquisition of these
products.
At www.nec-unified.com/weee you can find information about separate disposal and

environmentally sound recycling.
For countries outside the European Union
Disposal of electrical and electronic products in countries outside the European Union
should be done in line with the local regulations. If no arrangement has been made
with your supplier, please contact the local authorities for further information.
Battery Information
Defect or exhausted batteries should never be disposed of as

municipal waste. Return old batteries to the battery supplier, a
licensed battery dealer or a designated collection facility. Do not
incinerate batteries.
The following cards of this product use batteries for memory backup and retention
purposes :
SIC : Vanadium Pentoxide Lithium 3V, 20 mAh VL2020
PMC-SIC : Vanadium Pentoxide Lithium 3V, 20 mAh VL2020
-4-
1. INTRODUCTION
Since SIP@Net 4.2 a true native IP SIP@Net Server (running on a Windows
operating system) is available to execute all call processing functions required for SIP
based endpoints, SIP trunking and SIP based networking via iPVN.
Since SIP@Net 4.5 the IP-PM is introduced. An IP-PM is based on the traditional
iS3000 PM Shelf with extension and/or trunk boards that act as a gateway between an
IP-infrastructure and a TDM-infrastructure.
The SIP@Net Server running SIP@Net 4.5 can control the IP-PM via either a PMC-SIC
board or a separate SIC and PMC-G board. The ISG board converts the media from
TDM to IP domain.
The SIP@Net Server is a native IP communication system running as a 32-bit

application on a :
Windows Server 2003.

Windows Server 2008, 32-bit and 64-bit.
SIP@Net 4.x also runs on the traditional hybrid communication platforms offered by
the iS3000 systems using the CCS, CPU3000 or CPU4000 controlling boards.
Since SIP@Net 4.3 it is also possible to run the SIP@Net Server on an external server
instead of the In Skin Server (ISS) as available on the CPU4000. In that "hybrid"
configuration up to 4 PMs (not IP-PM) can be controlled by the SIP@Net Server, just
like the CPU4000.
-5-
2. SIP@Net SERVER
2.1. INTRODUCTION
The SIP@Net Server is a native IP system. It offers the solution for the large SIP
based migration/expansion needs for the (iS3000) customer base. Expansion with SIP
interfaces on existing CPU3000 and CCS system has its limits due to performance
reasons. Running the SIP@Net Server there is no performance issue: a maximum of
5000 SIP users per server is possible.
The general concept for SIP with SIP@Net Server is given below.
Figure 1. SIP@Net Server
In the TDM domain, various (progress-) tones, DTMF tone detection/generation and
"3-party add-on" functionality is realized in the Peripheral Module hardware. In the
SIP@Net Server there is no Peripheral Module hardware, therefore these functions are
taken care of by a so-called Media Server. It is recommended to host SIP@Net, SIP
driver and the Media Server on a single server. It is also allowed to place an additional
SIP driver on a separate server.
The SIP@Net Server runs on Windows 2003/2008 server operating system on
standard industrial server platforms.
The SIP@Net Server is a full SIP based standalone SIP server up to 5000 SIP ports for
the installed base and new sales. An industrial server should be used to ensure
availability.
In case the SIP@Net Server has to support TDM hardware related functionality, for
example an ISDN30 interface or an interface for connecting analogue/digital (non-SIP)
telephone sets, one or more IP-PMs are required (see Figure 2. SIP@Net Server with
an IP-PM).
-6-
Figure 2. SIP@Net Server with an IP-PM
An alternative for the IP-PM is to have 2 communication servers : one native-IP

system and one iS3000 "hybrid", connected using a SIP trunk with iPVN projected on
top of it (see Figure 3. SIP@Net Server in a SIP@Net iPVN Network).
Figure 3. SIP@Net Server in a SIP@Net iPVN Network
-7-
Note that the iS3000 "TDM" system must run SIP@Net 4.2 or higher and that iPVN is
based on DPNSS only !
The SIP@Net Server offers the following functionality :
Maximum of 5000 SIP ports for extensions, trunks and applications

Up to 5000 ports are offered. Trunking can be offered as direct SIP trunk, an ISDN
interface board in an IP-PM, or by means of external SIP to ISDN gateways.
In SIP@Net 4.5 the maximum number of IP-PM‟s is set to 20 and the maximum
number of BSP-IDs is 5000.
In general installations like CPU3000 based iS3010/3030/3050 or iS3070 /3090

systems/networks are the target market for this server based solution. To network
the SIP@Net Server and the iS3000 system, an ISG board, SIP@Net and iPVN
licenses must be installed in the existing iS3000 system. Trunk access from the
SIP extensions is supposed to be routed via a SIP trunk to the Internet Provider,
via the existing iS3000 trunk lines or via ISDN gateways.
Full SIP based

All "Call Processing" interfaces on the SIP@Net Server are SIP based. H323 or
CCIS are not supported. If other interfaces are required an IP-PM can be installed
or external "SIP to ISDN" or "SIP to analogue" gateways have to be used.
Full support of the Polycom, DT700 and BaseLine Pro SIP terminal range
All known functions that the Polycom, DT700 and BaseLine Pro SIP terminals offer
on the iS3000 CPU based systems are also available on the SIP@Net Server.
Full support of SIP IP-DECT Access Points and DECT handsets

The SIP based IP-DECT solution (not the iTMP) is the on site mobile solution
offering reliable and secure communication.
Full Support of SIP based VoWLAN network and handsets

The iS3000 mobility solution is enhanced with the VoWLAN offer when it comes to
Access Points and end user devices like the Polycom/Spectralink terminal range.
Support of ISDN and gateways

To offer BRI/PRI interfaces to the ISDN and analogue world interface modules (like
the AudioCodes gateways) are identified, tested and supported on the SIP@Net
Server.
Full iSNet working facilities to iS3000 system/network

In order to have feature transparency between the SIP@Net Server and the
existing iS3000 network, iPVN (based on DPNSS only) is applied. Note that the SIP
trunk must have been set to P2P.
For TDM based connections like ISDN/QSIG/DPNSS or for connecting “non-SIP”
telephone sets, one or more IP-PMs are required.
-8-
MAC and MA4000 support
The SIP server is installed via an MSI installer package. Management of the
SIP@Net Server is done via existing tooling. Operational Maintenance (OM
commands) can be used by the engineers.
MAC manager can be applied to add, move and change SIP extensions.
MA4000 release 8 (and higher) can be used to generate and modify the Polycom,
BaseLine Pro SIP and DT700 configuration files.
There is also a separate SIP Terminal Configuration Tool available to generate and
modify the Polycom and BaseLine Pro SIP configuration files but not the DT700
configuration files.
Runs on industrial Windows based server

The required operating system is Windows Server 2003/2008 SP1 (English (US)),
or later.
Various servers will be identified and certified and as such given full support by
NEC Nederland B.V.. Based on the standard specification for the server, another
server can locally be obtained, however no support is given. For details of the
Windows Server 2003/2008 requirements, refer to Appendix C.
Application support
It is strongly advised to install nothing else than SIP@Net and its related
components, that are installed when running the "SIP@Net Installer" like the Media
Server, SIP driver, etc. on the Windows platform. This is to avoid a situation where
resources (such as UDP ports) are claimed by other programs, like a TFTP server.
2.2. SIP@Net SERVER - FAULT TOLERANT SOLUTION
This can be realised by using "Marathon everRun” third party software. Marathon
everRun software combines the hardware resources present in two standard servers
to create a protected virtual environment. By having that virtual environment run
synchronously on both servers, everRun provides a virtual platform on which the
SIP@Net Server is fully redundant. If one of the two servers is down (or Ethernet
failure), no data is lost and no interruption of the SIP@Net Server will occur.
When applying the "Marathon everRun” solution it is possible to install other

applications like Business ConnecT BCT) and MA4000.
For details, see http://www.marathontechnologies.com/
-9-
Marathon‟s everRun offers non-stop operations in the event of any class of failure like :
1. an Ethernet failure
2. a local storage is down,
or even
3. a complete server is down
See figure below.
- 10 -
2.3. SIP@Net SERVER IN MORE DETAIL
In general, the SIP@Net Server (without an IP-PM) does not support TDM hardware
related functionality directly. For example it is not possible to connect a SuperVisor
60E operator console : the alternative for this function is the Business ConneCT (-
Operator) application or installing an IP-PM.
From the SIP@Net Server point of view, the following 3 protocols are relevant for
telephony :
CPU - IP-PM protocol, in case an IP-PM is projected.

SIP protocol : both for extensions and trunks.
iPVN-signalling protocol, in case iPVN is projected on top of a basic SIP trunk.
Figure 4. Protocols used in the SIP@Net Server
The SIP@Net Server runs the following programs :
SIP@Net 4.2 (or higher)

SIP driver
Media Server
It is recommended to host SIP@Net, SIP driver and the Media Server on a single
server. It is also allowed to place an additional SIP driver on a separate server.
- 11 -
A Media Server is needed to support the SIP@Net Server with among others :
Add-on 3-party conference

Break-in
Giving progress tones
MOH
Announcements
Recognizing DTMF digits during post dialling
The Media Server is connected to the SIP@Net Server via a SIP trunk using TCP, P2P
RTP and applies port number 2620 as a default port number in the SIP trunk. This can
be configured via the applied SIP trunk.
2.4. MEDIA SERVER
One Media Server per SIP@Net instance is sufficient.

The decision of one Media Server for one SIP@Net instance is based on the following
information :
One Media Server instance can handle up to 2048 channels.
One channel per call is needed for :

- Busy tone with DTMF-recognition (Automatic Ring Back)
- Confirmation tone
- Dial tone in enquiry
- Music-On-Hold (MOH) : with the Media Server solution every MOH-user listens to
a dedicated channel.
- Announcement.
Three channels for 3 party handling in case of :

- Break-in initiated by users and/or CSTA-application
- 3-party-conference initiated by CSTA-application
Note that 3-party-conference initiated by the SIP endpoint is not possible, except
for Polycom users and other SIP sets with built-in conference.
Since SIP@Net 5.0 it is also possible to use this way of Add on Conference on
SIP terminals that don‟t have a local conference bridge, like the BaseLine Pro SIP
and DECT handsets based on SIP-DECT. The behaviour of this way of Add on
Conference is the same as for non-SIP terminals.
For SIP terminals that have a local conference bridge it is advised to use that
conference function on the phone : this provides a better user interface and do
not require system resources.
A SIP@Net Server can serve 5000 SIP-endpoints : extensions, trunks, media

channels.
Remark
A channel is not fixed configured for one application : so one moment the channel is
used for tone and another moment it is used for an announcement or for one channel
of 3 party conference, etc.
- 12 -
2.4.1. Media Server for Add-on Conference
When add-on conference is initiated (in the “SIP@Net way” using the add-on prefix
*30) on a SIP terminal, the terminal provides for a local conference unit without
providing ticker tone. In this situation FCM 0 (Add-on Entitled) must be assigned to
the DNR of the SIP terminal. When not assigned, the result will be a single speech
path. However when add-on conference is initiated using CSTA, the SIP@Net Server
uses the Media Server channels to provide for a conference, including provision of
ticker tone.
2.4.2. Media Server for Progress Tones
Many tones such as dial tone and tones as result of a final response are generated
locally by the SIP-terminal. For some progress tones the SIP@Net Server uses the
Media Server. The progress tones that are initially supported for SIP extensions are
busy-tone, COB-tone and confirmation-tone. The media server provides the tone by
playing the related wav-file, for example : “nl_busy_tone.wav” or
“uk_confirmation_tone.wav”. The localization (nl, uk or other country) takes place
during installation of the Media Server.
The Media Server includes tone-wav-files for the following countries :
at : Austria de : Germany za : South Africa

be : Belgium uk : Great Britain es : Spain
br : Brazil gr : Greece se : Sweden
cn : China it : Italy ch : Switzerland
dk : Denmark nl : Netherlands
2.4.3. Media Server for Break-in
The SIP@Net Server uses a Media Server to provide a conference for the break-in
functionality, including provision of ticker tone.
2.4.4. Media Server for Announcements
The Media Server delivers announcements for incoming trunks and ACD groups as
defined with OM command CHANNO, by playing the related wav-file for example :
"anno_102.wav" for announcement 102.
Note that in case announcement number "8" is specified in OM command CHANNO,
the name of the anno_xxx.wav file is "anno_008.wav".
OM command CHANNO can not be used to define a MOH source.
2.4.5. Media Server for Music On Hold
The Media Server will deliver Music-on-hold (MOH) by repeatedly playing a single
wav-file. The feature "MOH-per Compatibility Value" (CV) is supported by playing the
wav-file for this CV, for example "moh_003.wav" in case of CV=3. When the wav-file
for a specific CV is not present, then the Media Server plays the default wav-file for
MOH "moh_000.wav". Note that the relation defined with OM command CHCVMH
between CV and the EHWA of an MOH device is irrelevant for SIP@Net Server.
- 13 -
2.4.6. Media Server for Recognition of RFC 2833 DTMF-digits
To enable post-dialling during busy, for example to start ARB, the SIP@Net Server
uses the Media Server to recognize RFC 2833 coded DTMF-digits. SIP terminals must
be configured to generate RFC 2833-digits during conversation. Default, the Media
Server uses payload type value 96.
2.4.7. G.729 Support by Media Server
In addition to the codecs G.711 ALaw (PCMA) G.711 µLaw (PCMU), the Media Server
has been extended (since SIP@Net 4.5) with the G.729A codec with support for G.729
Annex B silence compression (G.729AB).
The list of enabled codecs and the order of priority can be configured.
By default all codecs are enabled in order (highest priority first):
“G.711 ALaw --> G.711 µLaw --> G.729”.
G729 Voice-Activity-Detection (VAD) can be configured to 1=on (default) or 0=off.

If set to 1 (on), the Media Server will reduce the sending of RTP during silence periods
e.g. when playing tones.
2.4.8. Non-Peer-to-Peer Media for SIP Trunk
In previous SIP@Net releases, all media is Peer-to-Peer (P2P).

However, since SIP@Net 5.0 the Non-Peer-to-Peer option for SIP trunks is supported.
This implies that the media will flow via the Media Server.
Supporting non-P2P has the following advantages compared to P2P media :
• When using non-P2P, SIP@Net will not re-INVITE the media. This is to solve issues
with equipment that has problems with re-INVITE like Microsoft Exchange.
• When using non-P2P, it can be configured what codecs will be supported, in a
similar way as done on the hybrid system with the CHIPPD command.
• Transcoding is supported, to be able to used defined codecs on the SIP trunk.
• When using non-P2P, SIP@Net generates the SDP and hides the SDP of the other
equipment connected to the system. In this way it is possible to certify the SIP
trunk interface of the system independent what equipment is used to make or
receive calls.
• When using non-P2P, SIP@Net is capable to send and receive DTMF digits to or
from the trunk via RFC2833.
Setting the P2P option on the SIP trunk to „0‟ implies that all media will go via the
Media Server. The only exceptions to this rule are:
• The media contains video. As the Media Server does not support video codecs, the
media will become p2p in case video is advertised in the SDP.
• The media contains T.38 fax. As the Media Server does not support T.38, the media
will become p2p in case the T.38 is negotiated.
As all media from the trunk is now negotiated with the Media Server this implies that
the capabilities of the Media Server determine the supported features like codecs,
payload sizes, SRTP, etc.
- 14 -
Media Server enhancements
The Media Server has been extended with the following configuration parameters with
given default value, as listed in the table below.
Parameter Default value Allowed values

PCMA payload 20 10, 20, 30, 40, 50 , 60
PCMU payload 20 10, 20, 30, 40, 50 , 60
G729 payload 20 10, 20, 30, 40, 50 , 60
Internal frame time 10 10, 20
DTMF payload type 96 96 ... 127
For parameter “Internal frame time” the following applies :

Allowed values are 10 and 20 ms, default 10 ms.
• a value of 10 ms supports payload sizes of 10, 20, 30, 40, 50 and 60 ms.
• a value of 20 ms supports payload sizes of 20, 40 ms and 60 ms.
One can select a value of 20 ms to reduce the CPU load.
2.4.9. Constraints of the Media Server
The maximum number of simultaneous ports a Media Server can handle depends
among others on the performance of the selected hardware platform, but it is limited
to 2048 ports per Media Server.
The Media Server supports the 8 kHz codecs G711ALaw, G711µLaw and (since
SIP@Net 4.5) the G.729A codec. The wav-files for MOH, announcements and tones
must have the following properties : single channel/mono, 16 bit signed PCM, 8 kHz.
Files with these properties can be made with an open source tool, for example
"Audacity".
Although other sampling frequencies than 8 kHz also work, this is not recommended,
because this makes the media server to do on-line resampling causing unnecessary
loading on the server.
A Media Server serves only a single SIP@Net Server : more Media Servers for one
single SIP@Net Server is possible. The management interface on the Media Server to
configure and replace wav-files (e.g. for MOH) can be done via Windows Explorer.
2.5. MULTI PARTY CONFERENCE ON SIP@Net SERVER
The Multi Party Conference on the SIP@Net Server can be used in two different
configurations :
• using the trunk interface.

• using the extension interface optionally in combination with conference groups.
- 15 -
2.5.1. Multi Party Conference Using the Trunk Interface
Multi party conference is supported using SIP-trunk interface.

All calls to the SIP route of the media server will end up in a multi party conference.
The conference room is a one to one relation with the dialled number.
The only restriction is that the dialled number does not contain any star (*) or hash
(#), so the number is numeric and the number is an even (DDI-)number e.g. 3500.
One can become the conference leader of that group by dialling the odd number that
is one higher than the even number of the conference, so 3501.
On forehand, the conference leader (initiator) informs the conference members to
dial-in on number 3500, while the conference leader itself dials 3501.
In fact, number 3500 has to be projected as follows :
- 35 is a trunk access code leading to destination 35, route table 35 and in this route
table the route of the Media server is included e.g. route 90.
- for destination 35 an external analysis tree is used (e.g. 85) and in this tree
number range 00 … 99 is projected as an external number.
So :
- 3500 is the first conference room and 3501 is the conference leader.
- 3502 is the second conference room and 3503 is the conference leader.
- 3504 is the third conference room and 3505 is the conference leader.
- etc.
Example
<ASINTN:0,35,1,21,35;
<CHDSTC:35,85,00,35;
<CHROTA:35;
Enter route table data <ROUTE>,<PREF-CODE>,<TRFC>[,<SMART-BOX-EM>]:90,0,1;
<ROUTE>,<PREF-CODE>,<TRFC>[,<SMART-BOX-EM>]:;
<ASEXTN:85,0,1,2,2,0;
Give [<ROUTE-TABLE>[,<POINT-CODE]]:;
In case 35xx is not an DDI number one can project a valid DDI number with a fixed
Follow Me relation to 35xx.
In principle this means that the number of conference groups and the number of
conference members is only limited by the number of resources, like available SIP
trunk lines to the media server.
This implies that the following features are available:
• A tone is given when participant enters the conference

The tone is “conference_entered_tone.wav”
• On the server platform a SIP trunk license is required per active conference user
• On the hybrid platform an ISG channel license is required per active conference
user.
• When conference leader leaves the conference the conference calls of other
members are cleared.
• Conference leader can mute and un-mute the speech of other conference members.
- 16 -
In the media server the following parameters have to be configured to support the
mute and un-mute function for the conference leader :

Mute conference prefix *0 0 – 2 digits (0 – 9, * and #)
Un-mute conference prefix #0 0 – 2 digits (0 – 9, * and #)
2.5.2. Multi Party Conference Using the Extension Interface
Multi party conference is supported by Media Server using SIP-extension interfaces

with the following features :
• A tone is given when participant enters the conference

The tone is “conference_entered_tone.wav”
• When conference leader leaves the conference the conference calls of other
members are cleared.
• Conference leader can mute and un-mute the speech of other conference members.
• A SIP Extension license is required per conference-group-member.
• It combines well with the SIP@Net conference-group facility.
Media Server can be configured using the installer with the following parameters :

Number of conference groups 0 0–5
Number of members per 0 0 – 32
conference group
Mute conference prefix *0 0 – 2 digits (0 – 9, * and #)
Un-mute conference prefix #0 0 – 2 digits (0 – 9, * and #)
Dependent on these parameters the Media Server registers the SIP extension with the
Alternative Usernames in the range :
Conf0Member0 … Conf0Member31 for group 1

Each with the password of Media Server (default password is “admin”).

Using these Alternative-Usernames one can freely choose the DNR of each member.
Member0 of each conference group is meant for the conference leader.
The party connected to member0 :
• can mute and un-mute the other members of the conference by selecting the
configured prefix.
• releases all calls to the conference group when it releases its call.
The Media Server multi-party conference group combines well with the “Multi-party
conference group” feature as described in the “Voice Facilities – Explained” manual.
- 17 -
Example
Projecting a conference group of 5 members.
<CHDNRC:1700,15,2,0;
<CHDNRC:1701,15,2,1;
<CHDNRC:1702,15,2,2;
<CHDNRC:1703,15,2,3;
<CHDNRC:1704,15,2,4;
<SETINS:15,2;
<SETINS:15,2,0&&4;
<CHSUSR:15,2,0;
Enter Authentication password:admin;
Alternative Username:Conf0Member0;
<CHSUSR:15,2,1;
<CHSUSR:15,2,2;
<CHSUSR:15,2,3;
<CHSUSR:15,2,4;
<DISUSR:15,2,0&&4;
SHELF BRD CRT DNR ALT.USERNAME PASSWORD
15 2 0 1700 Conf0Member0 admin

EXECUTED
Group 1777 with group property 60 “Conference group” has 4 members DNRs 1701 –
1704, and the supervisor is DNR 1700 connected to member0 :
<CRGRPA:1777,60,0,1700;
Enter <MEMBER-BSP-ID>,[<SWITCH-ALL/INIT-STATUS>],<RANK>
[,[<LINE-POS>][,<PARK-POS>]]:1701,1,1;
[,[<LINE-POS>][,<PARK-POS>]]:1702,1,2;
[,[<LINE-POS>][,<PARK-POS>]]:1703,1,3;
[,[<LINE-POS>][,<PARK-POS>]]:1704,1,4;
[,[<LINE-POS>][,<PARK-POS>]]:;
- 18 -
2.6. LICENSING
The licensing mechanism of the SIP@Net Server is based on the existing iS3000
licenses and structure. The SIP@Net Server licenses are re-named to the actual
extension figures of 96, 288, 1216, 3300 and max extensions. These steps are also
applied in the SIP@Net Server.
For running SIP@Net on an external server, license 71 and (since SIP@Net 5.0)
license 73 (Start Upgrade Period) are required.
Next to license 71 & 73, the SIP extension license 69 is the most common used
license when using the SIP@Net Server.
SIP trunk ports are not licensed and as such not chargeable and controllable. Full SIP
based iSNetworking requires the iPVN licenses.
License string for the SIP@Net Server is related to a USB dongle (Safenet/Sentinel )
that is delivered via Prophix ordering. The fingerprint of a SIP@Net Server is fetched
from the dongle. Hardware failure of the dongle does not directly result in a non
functioning system for a customer.
Without a dongle, the SIP@Net Server can be used as a SIP Extension "basic
application" for up to 10 SIP extensions (license 69).
The license mechanism is derived from the current iS3000 behavior and works
according the following flow.
- 19 -
For the SIP@Net Server, when no dongle is present (or the license file does not match
the fingerprint of the dongle), the system operates according the license file for 3
days. If no license file is present at start-up, the system operates with "basic
functionality" (demo mode) meaning 10 SIP extensions, no licensed facilities : in
these situations Alarm Code 36 is raised.
- 20 -
2.7. (REMOTE) DONGLE
In order to verify a license file, SIP@Net must readout a Safenet/Sentinel dongle that
provides a system fingerprint.
Only one Safenet/Sentinel dongle attached to the PC is supported by the SIP@Net
Server. When using Safenet/Sentinel services only one application can connect to a
dongle at the same time. SIP@Net will remain connected to that dongle. This makes it
impossible to share 1 dongle between multiple SIP@Net servers.
Since SIP@Net 5.0 it is possible to readout a dongle that is connected to another

system than the system running SIP@Net itself.
In order to do so the IP address of the remote machine must be configured. This can
be done using the SIP@Net installer :
The remote dongle is handled as if it were connected to the machine running SIP@Net.
This functionality applies to any SIP@Net configuration that uses a Safenet/Sentinel
dongle to provide a fingerprint.
SIP@Net will first try to connect to a dongle that provides the same fingerprint as
present in the license file. If no dongle with that fingerprint is available, then SIP@Net
will connect to the first available dongle. However then there is a mismatch between
the dongle and license file. The consequence is that the system is operational for 72
hours with the licenses according the license file.
Note that the Safenet/Sentinel Dongle server must be installed on the machine acting
as Remote Dongle Server!
- 21 -
2.8. MAINTENANCE ASPECTS
Date and Time

The SIP@Net Server synchronizes its date and time with the time of the Operating
System it is running on. This synchronization is done at least every minute. OM
command SEDATI is not supported on the server version.
Note that "ISDN date/time synchronisation" is disabled on the SIP@Net Server.
Maintenance & Management of the SIP@Net Server

The SIP@Net Server can be managed via SMPC, MAC manager or MA4000.
On the CCS and CPU3000 there is always a V.24 OM interface enabled. On the
SIP@Net Server only clients that have the OM service enabled can make a
connection via IP. This is unwanted in case of (projecting) failures. Therefore
connections originating from the machine itself are always allowed. This is valid for
all services as defined with OM command CHPROF.
Alarm Notification
For Alarm Notification an alternative solution is available : Windows Event log.
Writing to the Windows event log is used by most server applications and so also
for SIP@Net Server. All exceptions and restarts as well as alarms are written to the
Windows event log.
Restart, Recovery and Backup

On the iS3000 CCS and CPU3000 systems the restarts are normally done via a so
called MIS-file. This mechanism is not supported on the SIP@Net Server. The
SIP@Net Server starts-up with the PE and LL projecting files, followed by the
journal file. Depending on the amount of changes made in the configuration, the
journal file can become very large if it is never cleared. To avoid this situation, OM
command GEBUFI (Generate Backup File) has to be used : this command executes
the following as an automatic operation :
- Make a complete retrieve : network and local data, dynamic data and name-
number relations. The result will be a PR and OR file.
- Rename the retrieve files PR and OR back to PE and LL.
- Generate a new empty journal file.
The versioning mechanism takes care that always the latest PE and LL projecting
files are used on a restart. The maximum number of versions of the same file is 8.
Location of the SIP@Net Server Configuration Files

The directory (the "LBU") where the SIP@Net Server configuration files are stored
is :
C:\Documents and Settings\All Users\Application Data\iS3000\SIP@Net

(on Windows Server 2003)
C:\Program Data\Application Data\iS3000\SIP@Net
(on Windows Server 2008)
Here the following files can be found :

- PE and LL files
- PR and OR files
- JOURNL.POM file
- License file
- MML files
- 22 -
2.9. JOURNALLING OF DYNAMIC DATA
When the SIP@Net Server performs a restart, either by manually restarting the
service or caused by a (software-) exception, the system is re-projected and all
dynamic data is lost. For example the registration of SIP terminals must be awaited
before calls to and from SIP-terminals are possible.
To reduce the impact of a restart, changes to relevant dynamic data are saved in the
journal file and are restored after a restart by the normal execution of the journal file.
Journalling of dynamic data is available (since SIP@Net 4.5) when system option
190 'Enable journaling of dynamic data' is 'yes'. This option must be set to 'yes' on an
SIP@Net Server.
Changes to the dynamic data listed below are journaled when option 190 'Enable
journaling of dynamic data' is 'yes', and are retrieved with OM command RTRIEV when
retrieve-option P (already existing) 'Retrieve Dynamic Data' is 1. OM command
GEBUFI implicitly retrieves dynamic data.
The following dynamic data is journaled :
Call-forwarding-on-busy-extension activation-status.
Call-forwarding-on-busy extension relation as set by FeatureRequest from CSTA or
ErgoLine.
Fixed follow-me activation-status
Follow-me of extension or group
Follow-me prepared status
Don't disturb of extension or group
Temporary Don't Disturb (see system boundary 260 Don't Disturb Reset Time), is
not journaled, as it is also not kept at a warm start.
Group member presence
When the initial group member presence is absent, after a warm start or SIP@Net
- 23 -
Server-restart group member presence must be absent, and is consequently
neither journaled nor retrieved.
Executive and secretary presence
Night extension presence
ACD group day/night status
As changed from a CSTA application, or by the group-supervisor dialling the 'ACD
group day/night prefix' (Result-Ids 128/129). This is not done for Routing Groups
(Group Property 59).
WAN DECT Mobility failed status as set after an incomplete WAN DECT mobility
move.
Message waiting type 0, 1, 2 and message waiting softring.
Password of password protected facilities, as changed with dialling prefix with
Result-Id 104 'Change password'.
Individual abbreviated number as obtained by dialling prefix with Result-Ids 69, 70
and 71 (Store, Erase and Replace Individual abbreviated number.
A dialled Last-external-number will not be saved to the journal file.
Traffic-class-statuses 'enabled/disabled' and 'up/down' as determined by dialling a
prefix with one of the Result-Ids:
- 105 Enable up/downgrading
- 106 Disable up/downgrading
- 107 Upgrade traffic class
- 108 Downgrade traffic class
SIP extension registration
Only new, cancelled and expired registrations are journaled. Renewed registrations
are not journaled. SIP registrations that are restored from a projecting file are
limited to a maximum lease-time of 3600 seconds. To restore SIP registrations
sufficient SIP-extension-licenses (license 69) must be available. Lack of licenses
results in a license alarm and the SIP registration is not restored.
SIP route registration
When the SIP route is activated as registrar (server) a change of the actual
registration status is journaled, and can be retrieved. When the SIP route is
activated as registerer (client)' registration towards a SIP-proxy is already
restarted after projecting.
Automatic MAC address assignment of iTMP terminals
MAC addresses of iTMP terminals such as ErgoLine@Net terminals or IP-DECT
terminals is assigned automatically when system option 135 'iTMP Free Port
Allocation' is set.
Batch jobs as submitted with command SUBJOB.
A batch job will only be retrieved when it has not yet started. A job that is
executing when the system restarts is not completed nor restarted after a system
restart.
Jobs submitted from projecting and/or journal file are ignored when the date-and-
time is in the past, or when the system time is not set. This is the case on CCS
platform and therefore this function is not supported for this platform.
The OM commands CHBOUN, CHOPTI and CHTIME are journaled independent of

system option 190. Already journaled facilities :
Desksharing, SMA and iSNet-MAN-DECT-Mobility-move

Desksharing (activate/deactivate DNR) and related facilities as move/create DNR,
SMA and iSNet-MAN-DECT-Mobility-move are already journaled, because OM
commands are used.
When system option 190 is set to „Yes‟, option 128 „No journaling for desksharing‟
is ignored.
- 24 -
iSNet WAN DECT Mobility move
This facility changes the location of a free number in a set of iSNet network nodes,
and is already journaled because it uses an OM command.
Change (room) traffic class and switching-service Bar/unbar
Both dialled facility Change (room) traffic class via Result-Ids 161 'Upgrade to day
traffic class' or 162 'Downgrade to night traffic class', and switching service
Bar/unbar use OM command CHTRFC which is already journaled.
Switching service - Insert/remove PID
This facility uses OM commands ASPICC and ERPICC, which are already journaled.
Constraints
ACD-login status
After a restart of the SIP@Net Server (Stop/Start the service) the ACD-login status
must have the initial value as defined with OM command CRGRPA or ASGRPM.
Consequently the ACD-login status is neither journaled nor retrieved.
Automatic Ring Back (ARB) relations are neither journaled nor retrieved.
For the facilities 'Call break at zero budget' and 'Time based call break at zero
budget' the budget changes of a PID are not journaled.
Call records
Buffered call records for toll-ticketing or full-detailed call recording are lost at a
restart of a SIP@Net Server. To prevent or reduce the risk of loss, call records
should be written to a file, or send via IP to a Call Accounting application.
Metering data
Metering data of route, extension, operator, night extension is lost at a restart of
SIP@Net Server.
The system-day/night-traffic-class status is neither journaled nor retrieved, as it is
also not kept at a warm start.
SIP extension subscriptions, used for presence notifications, are neither journaled
nor retrieved, as it is also not kept at a warm start.
Automatic generation of backup files

The journal file will grow over time, and with journaling dynamic data, it will grow
faster and become significantly larger. To reduce the risk of a long start-up time due
to a large journal file, one is advised to regularly execute OM command GEBUFI,
which retrieves the projecting and clears the journal file.
OM command AUBUFI 'Automatic GEBUFI' makes this easier. AUBUFI creates a
command-file (containing a GEBUFI and a SUBJOB command) and submits this (e.g.
daily) at a given date and time.
Projecting aspects
At a change of above dynamic data, a subcommand is written to the journal file.
The to-be-journaled subcommand may be queued in a buffer to overcome a
temporary network lock (e.g. caused by an executing OM command), BM-lock, or non-
availability of inter-unit link to the CBU-unit. In exceptional cases this buffer may
become full or the system may experience a restart before the queue is emptied, due
to which dynamic data may be lost. When due to a full buffer a to-be-journaled
subcommand is lost, Alarm Code/Qualifier 61/52 is raised.
The size of this buffer is defined by system boundary 440 'Dynamic data backup
buffer size'.
- 25 -
2.10. PREPARATION
For the SIP@Net Server the installation is performed via an MSI installer package. The
installer contains the following products / components :
- SIP@Net
- SIP driver
- Media Server
- SIP Terminal Configuration Tool
- Dongle driver
- Various tools like :
- Simple Alarming
- System Info Console
- Diag@Net
- SIP@Net Server convert (simply right-hand mouse click on the PE/LL file)
The complete SIP@Net Server is supported on Windows Server 2003/2008, SP1

English (US), or later.
In case a virus scanner is used, it is advised to exclude the Diag@Net directory
(C:\NEC\Diagnostic files) from scanning.
2.10.1. Multiple Ethernet Cards
As more and more PC's and servers are equipped with more than one Network
Interface Cards (NIC) it should be clear what interface is used by the software. This is
valid for the SIP@Net, the SIP driver and Media Server software. Therefore during the
installation it has to be specified what interface (identified with its IP address) has to
be used. This interface can be specified on a per application basis, making it possible
to separate the voice network from the management network.
Example
When specifying for the SIP Driver and the Media Server interface "VoIP" and for
SIP@Net interface "Mgt" causes all SIP traffic and RTP traffic going via the "VoIP"
interface. All other SIP@Net traffic like CSTA, OM, iPVN and FDCR will be routed via
the "Mgt" interface.
2.10.2. Configuring and Dimensioning the Media Server
Both SIP@Net Server and Media Server need to be configured. System option
LOSYSOP179 must be set to “1”. In the SIP@Net Server the Media Server is
configured as a SIP trunk. The Media Server is configurable at installation time
through the MSI-installer.
The Media Server must be assigned in SIP@Net as a regular SIP route using OM
commands :
CHSIPA : to assign the Media Server's IP-address and Listen-port as PROXY-IP-

ADDRESS and PROXY-IP-PORT
CHSIPD : to assign the Media Server's configuration parameter username and
password.
RESIPR : to activate the SIP route with SIP@Net as registrar.
- 26 -
DISIPR : to show the actual status of the registration and to indicate whether the
connection with the Media Server is still alive.
CHIPPD : to assign a route table for the Media Server.
The Media Server is configured with the following parameters :
PARAMETER DEFAULT VALUE

Media Server IP address 0.0.0.0 (only in case 1 NIC is used)
Media Server SIP port 2620 : this is a TCP port
SIP driver IP address 0.0.0.0 (only in case 1 NIC is used)
SIP driver port number 5060
Username admin
Password admin
First port of RTP port-range 52000 (default) … 56095
Number of RTP ports 2048
Re-registration-time 120 seconds
Windows 2003
C:\Documents and Settings\All Users\Application
Directory for tones Data\ iS3000\MediaServer\ms1\mediacontent\
(or announcements or MOH) tones (or announcements or MOH)
Windows 2008
C:\Program Data\Application Data\iS3000\
MediaServer\ms1\mediacontent\
tones (or announcements or MOH)
Country code "nl"
Codec 1 "G.711 ALaw (PCMA)"
Codec 2 "G.711 µLaw (PCMU)"
Codec 3 "G729A"
G729 Voice-Activity-Detection "1"
(VAD)
PCMA payload 20
PCMU payload 20
G729 payload 20
Internal frame time 10
DTMF payload type 96
Number of conference groups 0
Members per conference group 0
Mute conference prefix *0
Un-mute conference prefix #0
- 27 -
The Media Server uses a 2-character country code as the first part of the filename of
tone-wav-files, to select the country dependent set of tones, for example :
"uk" to select "uk_busy_tone.wav" and "uk_confirmation_tone.wav"

"se" to select "se_busy_tone.wav" and "se_confirmation_tone.wav"
The Media Server only accepts INVITE's from the SIP@Net Server for which it has
been configured.
SIP-media ports are assigned as a normal SIP Trunk-ports on a virtual SIP trunk
board (board-type 44), and assigned as lines in a bundle with signalling-type SIP, in a
route to the Media Server.
The load on a Media Server, caused by the amount of simultaneous tones and
conferences needs to be controlled to prevent poor quality voice connections and
allow use of Media Servers on PCs with low or high performance. To achieve this, the
maximum number of simultaneous calls towards a Media Server is limited by the
amount of SIP trunk-lines in the SIP-media-route that are in service (INS).
The Media Server is assigned, by putting the SIP-media-route in a route table using
CHROTA (). This route table number has to be assigned in the IP signalling data using
OM command CHIPPD. In the default projecting Route Table 90 and signalling group
B001 are used.
2.10.3. BOUNDARIES
As a general rule all boundaries that are applicable for the SIP@Net Server may be set
(with some exceptions) to a maximum value identical to the CCS platform.
The SIP related boundaries are listed below. For other boundaries, see Appendix A.
BOUNDARY DESCRIPTION MAX VALUE

415 SIP relay listen port number 2610
416 SIP driver listen port number 5060
417 Max number of SIP drivers 10
418 Max number of SIP trunk calls per unit 500
419 Max number of SIP routes per unit 255
420 Max number of SIP signalling groups 255
424 Max number of SIP transactions 2500
425 Max number of Kbytes for SIP heap not appl.
426 Max number of SIP extension calls per unit 1000
432 Max number of monitors for SIP extensions 2000
433 Max number of monitors per extension for SIP 40
435 Max number of SIP monitors 40000
436 Max number of virtual SIP shelves 10
437 SIP driver TLS listen port number 5061
- 28 -
2.11. INSTALLATION
Before installing SIP@Net it is advised to :

check/set the Date and Time of the Windows server.
check/set the required IP address/Subnet Mask of the Windows server.
clear the Windows Event Viewer to simplify troubleshooting in case the installation
is not successful.
2.11.1. Installation of SIP@Net on the Server
1. Collect the iS3000/SIP@Net Installer software from the NEC SoftWare DataBase
and copy this on the server.
2. Double click the "setup.html" file : the following "Welcome" screen is displayed.
- 29 -
3. Select the "SIP@Net Server" and select "Install".
The following 2 screens are displayed.
4. Select "Run".
5. Select "Run" once more : the following is displayed.
- 30 -
6. Select "Install".
7. Select "Yes".
- 31 -
8. Select "Next".
9. Accept the "License Agreement" and select "Next".
- 32 -
10. Select "Next" for the default destination folders, or
Select "Change" to choose other destination folders, if required.
11. Fill in the Unit number (1 ... 14), the IP address of the NIC (note that there can
be more than one NIC) and the various Port numbers and then select "Next".
In case of using a remote dongle server, fill-in the IP address of that server.
See also section 2.7. (REMOTE) DONGLE.
- 33 -
Note that a couple of port numbers specified is also represented by a system
boundary. The port numbers (listed in the above screen) are the default values of
those boundaries. When changed here, check them once SIP@Net is operational
using OM command DIMDAT.
The port numbers for iTMP and CCIS are only relevant for a hybrid system.
After the complete installation procedure is finished, the specified settings filled
in can be checked in the Registry as follows :
Go to the "Registry Editor"

-> HKEY_LOCAL_MACHINE
-> SOFTWARE
-> iS3000
-> SIP@Net
12. In the next screen you can choose whether you want to load the "Demo"
configuration (Demo PE/LL) or not.
● when selecting the default situation "This feature will not be available" no
PE/LL files are loaded. This means that after you have finished the installation,
you have to load another existing customers projecting (PE/LL file).
● when selecting "This feature will be installed on local hard drive", the
demo PE/LL files are loaded. This means that only 10 SIP ports are available
and no license is required to run this demo version.
DO NOT USE THIS FOR OPERATIONAL SYSTEMS !
- 34 -
13. Select "This feature will not be available" and then "Next".
Keep in mind that you have to load a customer‟s configuration (PE/LL file)
lateron.
- 35 -
15. After the installation has completed select "Finish".
2.11.2. Installation of the SIP Driver
1. Proceed the installation procedure with the SIP Driver.
2. Select "Yes".
- 36 -
3. Select "Next".
- 37 -
5. Select "Next" for the default destination folder, or
Select "Change" to choose another destination folder, if required.
6. Fill in the IP address of the Windows server where the SIP driver is installed on
and fill in the address of the server where SIP@Net is running.
- 38 -
The field "Interface" holds the IP address of the network interface that the SIP
driver will start listening on. This is the IP address that should be used as
SIP@Net Server when configuring SIP extensions or SIP trunks.
This IP address may be set to 0.0.0.0. In that case the SIP driver will start
listening on the same interface as is used for the connection to SIP@Net.
Also the "SIP@Net IP" address may be set to 0.0.0.0. In that case SIP@Net is
assumed to be installed on the same server as the SIP driver.
The SIP driver will determine and use a "real" network interface : it will not use
"127.0.0.1".
Note that the SIP driver will always listen to one specific interface. Make sure
that that interface is reachable by the SIP extensions!
7. In case you use the built-in certificate, leave the 3 fields empty and select "Next".
In case you do not use the built-in certificate, enter the certificate strings here.
- 39 -
- 40 -
2.11.3. Installation of the Media Server
1. Proceed the installation procedure with the Media Server.
2. Select "Yes".
3. Select "Next".
- 41 -
5. Select "Next" for the default destination folders, or

Select "Change" to choose other destination folders, if required.
- 42 -
6. Fill in the two IP addresses and the Country Code (for the correct tones) and
select "Next".
● Interface
When the Media Server is running on the same server as SIP@Net, then this
IP address is the same as specified in step 8 in subsection 2.11.1.
● SIP-Driver IP
When the SIP driver is running on the same server as SIP@Net, then this IP
address is also the same as above.
In case the Media Server or SIP Driver are installed as separate components
on another Windows server than the one where SIP@Net is installed on, then
fill in the IP address of that other server.
- 43 -
7. Specify the codecs used by the Media Server.
By default all codecs are enabled in order (highest priority first):
"G.711 ALaw --> G.711 µLaw --> G.729A".
For priorities 2 and 3 it is also possible to select “none”.
In that case the Media Server always use the codec specified as "Priority 1".
8. Specify the parameters for the Multi Party Conference function.
- 44 -
In case the Multi Party Conference function is using the :
• trunk interface :
only fill-in the mute and un-mute prefix : there is no limitation on groups
and members.
• extension interface :
also specify the number of conference groups and the number of members.
After the complete installation procedure is finished, the specified settings filled
in can be checked in the Registry as follows :
Go to the "Registry Editor"

-> HKEY_LOCAL_MACHINE
-> SOFTWARE
-> iS3000
-> Media Server
-> ms1
- 45 -
9. Choose for a "Complete setup" and select "Next".
- 46 -
2.11.4. Installation of the Tools for the SIP@Net Server
1. Proceed the installation procedure with the tools for the SIP@Net Server.
2. Select "Next".
- 47 -
3. Select the destination folder and select "Next".
- 48 -
6. Select "Finish".
7. Now go to "Service and Applications" - "Services" and check that the following
services are started :
- iS3000 SIP@Net Service
- iS3000 SIP Driver Service
- iS3000 Media Server
- 49 -
8. In case the demo PE&LL files are loaded, go to the "SIP@Net OM" shortcut or go
to "Run" and setup an OM session via "telnet <IP address>" : the IP address of
SIP@Net (in this example 192.168.116.20)
In case no PE/LL files are loaded, you can not setup an OM session yet.
First copy the customer‟s PE/LL files to the LBU (shortcut on the desktop) and
restart the iS3000 SIP@Net Service as given in step 7 : then go to "SIP@Net
OM" or "Run".
9. Now an OM session can be opened, using "Ctrl-G".

REMARK : In the "Properties" of the telnet session window (right-hand mouse
click on the top bar) you can modify the various settings of the display. It is
advised to put the height of the Screen Buffer Size (in the "Layout" tab) to at
least 700.
The figure below represents the demo configuration.
- 50 -
<DIEXID:1;
UNIT CM PACKAGE PATCH COUNTRY# EXCHANGE# ADMIN# USER# 12NC
1 1 8850.00 0 0670 3000 0810 0460 3522-274-40690
PACKAGE-RELEASE-DATE START-UPGRADE-PERIOD END-UPGRADE-PERIOD DAYS-LEFT

2011Q3 2011Q1 2012Q1 216
EXECUTED
<DIIPPD:B001;
SIG-GRP LANGUAGE ACCESS-CODE GATEKEEPER CODECS PAYLOAD RFC-2833 ROTA

B001 - 779 - 0 1 2 3 30 96 90
SRTP ENCRYPTION AUTHENTICATION T.38 SESSION
- - - - -
VoIP-DATA
-
EXECUTED
<DIROTA:90;
ROUTE-TABLE UNIT SEQUENCE-TABLE
90 1 1
NORMAL EXTENSION OPERATOR PRIORITY EXTENSION
ROUTE PREF TRFC SMART ROUTE PREF TRFC SMART ROUTE PREF TRFC SMART
90 p 1 No 90 p 1 No 90 p 1 No
EXECUTED
<DISIPR:90;
ITEM VALUE
Route number 90
Inside global IP address:port -
Proxy IP address:port 192.168.116.40:2620
Proxy domain name -
Registrar IP address:port 192.168.116.40:2620
Registrar domain name -
SIP driver IP address:port -
Route user name iS3000
Requested lease time in minutes 60
Remaining lease time in minutes 1
Transport protocol TCP
Authentication username admin
Authentication password admin
SIP protocol variant 0
Peer-2-peer RTP 1
Add received phone-context as prefix 0
Identity Header none
Early Media 0
Requested route status SERVER
Current route status OUT
EXECUTED
<
In the demo configuration there is an SIP signalling group B001 with a route
table (ROTA) 90, containing the SIP route 90 of the Media Server. This route
tries to register at the IP address of the SIP driver. In the demo projecting this is
IP address 192.168.116.40. However in our example so far the SIP driver is
running on IP address 192.168.116.20. That is the reason why the "Cur. Status"
in the above OM screen shows OUT. So the route of the Media Server has to
register at 192.168.116.20 instead of 192.168.116.40 : see the next steps.
Also check that the Transport protocol is “TCP” and that the SIP trunk is
registered as “Server”.
- 51 -
10. Execute OM command CHSIPA as follows :
CHSIPA:90;
INSIDE-GLOBAL-IP-ADDR :;
INSIDE-GLOBAL-IP-PORT :;
PROXY-IP-ADDR :192.168.116.20;
PROXY-IP-PORT :;
PROXY-NAME :;
REGISTRAR-IP-ADDR :192.168.116.20;
REGISTRAR-IP-PORT :;
REGISTRAR-NAME :;
SIP-DRIVER-IP-ADDRESS :;
SIP-DRIVER-IP-PORT :;
11. Re-register the route by restarting the Media Server service (step 7) or by
executing OM command RESIPR or wait until the lease-time (default 120 sec.)
has expired.
RESIPR:90,3;
12. Check that the SIP trunk to the Media Server is now registered and in service
condition INS.
DISIPR:90;
13. The system is running without a license. One can check this by reading out the
alarms in the usual way : OM commands DIMAJA, DIMINA, DISILA and DIBLCK.
14. Copy the SIP@Net Server license file to the LBU (shortcut on the desktop) or in
the following directory :
C:\Documents and Settings\All Users\Application Data\iS3000\SIP@Net
15. Execute OM command ACLICS to activate the loaded license.
16. Execute OM command DIDATI to check that the date and time of SIP@Net is in
line with the date and time of the server. Note that the date and time in SIP@Net
can not be set by OM command SEDATI.
17. Now register the SIP terminals.

In general a SIP terminal is registered using the DNR.
In the configuration file of the SIP terminal you have to specify this DNR and the
IP address where to register : the IP address of the SIP driver : in this example
192.168.116.20.
Instead of the DNR, a SIP terminal can register itself, using a Username and
Password. This Username and Password must be filled-in in the configuration file
of the SIP terminal and in SIP@Net, you have to specify this using OM command
CHSUSR.
18. In case TDM interfaces are required, for example an ISDN-30 interface or an
interface for connecting analogue/digital (non-SIP) telephone sets, an IP-PM has
to be projected : see chapter 3. IP-PM.
- 52 -
2.12. TELNET IN WINDOWS 2008
On a clean Windows 2008 Server, the Telnet service is not directly available.
It has to be added as follows :
Go to : Start -> Administrative Tools -> Server Manager -> Features
Select “Add Features”.
Select “Telnet Client”.
- 53 -
2.13. INSTALLATION OF THE REMOTE DONGLE SERVER (Optional)
In case the dongle is not attached to the server where SIP@Net is running on, but on
a remote server, one have to run this part of the installer on that remote server.
1. Double click the "setup.html" file.
The following "Welcome" screen is displayed.
- 54 -
2. Select the "Remote Dongle Server" and select "Install".
3. Select "Run".
- 55 -
5. Select "Next".
- 56 -
- 57 -
9. Select "Yes" for modifying the Firewall settings.
10. Select "Finish".
- 58 -
2.14. INSTALLATION OF THE SIP TERMINALS CONFIGURATION TOOL
(Optional)
The SIP Terminals Configuration Tool is a support tool especially designed to easy the
installation effort of BaseLine Pro SIP and/or Polycom SIP terminals. It allows a
system engineer to easily prepare the configuration files for a set of terminals, either
using a Microsoft Excel® sheet or existing configuration files as import data source, or
by adding new phone configurations from scratch. The SIP Terminal Configuration
Tool automatically generates the "MAC address specific" configuration files, required
for each SIP terminal.
The SIP Terminals Configuration Tool can be installed on a separate PC or on the

same server where SIP@Net is running on. Note that Microsoft Excel® is also installed.
1. Double click the "setup.html" file.
The following "Welcome" screen is displayed.
- 59 -
2. Select the "Configurator for BaseLine Pro SIP and Polycom SIP terminals" and
select "Install".
3. Select "Run".
- 60 -
5. Select "Next".
6. Select "Next" for the default destination folder, or

Select "Change" to choose another destination folder, if required.
- 61 -
8. Select "Finish".
- 62 -
2.15. RELEASE IDENTIFICATION
The identification of the iS3000 installer has the following syntax :
iS3000 Installer <vv>.<mr>.<p>.<c>
in which :
<vv> = version number 2 digits (50 … 99)

<mr> = Maintenance/Repair Release (MR/RR) number 1 or 2 digits (1 … 99)
<p> = patch on MR/RR release 1 digit (0 … 9)
<c> = component update number 1 digit (0 … 9)
e.g. iS3000 Installer 50.0.0.0
SIP@Net Release Installer DIEXID

The first SIP@Net 5.0 release 50.0.0.0 8850.00 0
The second SIP@Net 5.0 release 50.1.0.0 8850.01 0
A patch on the second release 50.1.1.0 8850.01 1
A second patch on the second release 50.1.2.0 8850.01 2
A new release of the other components (Media Server
or SIP driver) is identified by the last digit e.g. 50.1.0.1 8850.01 0
(note that this is not shown by DIEXID)
The first SIP@Net 5.1 release 51.0.0.0 8851.00 0
- 63 -
2.16. UPGRADE (DOWNGRADE) SCENARIO
Before starting an upgrade ALWAYS DO the following :
Execute OM command GEBUFI to save the latest configuration of the

SIP@Net Server projecting.
Be sure to have a backup scenario : create a disk image of the drive, the
SIP@Net Server is running on.
Note that since SIP@Net 5.0 you need an upgrade license.
Suppose you only want to upgrade from SIP@Net 5.0.0 to SIP@Net 5.0.1: the other
components like the Media server or SIP driver are OK and do not need to be
upgraded.
Then execute the following steps :
1. Collect the iS3000 Installer 50.1.0.0 from the NEC Software Database and copy
this to the PC.
2. Run the installation as described in section 2.11. INSTALLATION.
Note that for the telephone users the system is down.

After this is finished the InstallShield Wizard shows :
SIP@Net Server optionally uses the Media Server.

Would you like to install it now ?
Select : No, because the Media Server does not need to be upgraded.
Select also "No" for the other components like SIP driver, dongle etc.
In case any component needs to be upgraded this will be indicated in the Field
Change Order (FCO) of the related iS3000 Installer.
3. Go to "Run" and setup an OM session via telnet : "telnet localhost".

If not successful, go to "Service and Applications" - "Services" and check that the
"iS3000 SIP@Net Service" is started.
4. Open the OM session (Ctrl-G) and execute OM command DIEXID.

This should show : 8850.01 0
5. Check any outstanding alarms in the usual way : OM commands DIMAJA,

DIMINA, DISILA, DIBLCK and DIHIBU.
6. In case the SIP@Net Server is not part of a regular back-up scenario, it is

advised to make a new disk image and to store this image in a safe place.
Note that you can not use the iS3000 Installer to go back (downgrade). In that case
you have to restore the disk image created before the upgrade.
- 64 -
2.17. DIAGNOSTIC TOOLS
When the SIP@Net Server is successfully installed, the following diagnostic tools
automatically become available :
- Simple Alarming
- System Info Console
- Diag@Net
Furthermore the Windows Event Viewer can be used for diagnostics.

Note that since SIP@Net 4.5 it is possible to create a system dump without an
active OM session.
2.17.1. Simple Alarming
iS3000/SIP@Net Server Simple Alarming is a tool to keep informed about the alarm
statuses in the iS3000/SIP@Net Server. The tool shows when a new occurrence of an
alarm type arises or when the last occurrence of an alarm type is solved.
Start Simple Alarming as follows (or use the shortcut on desktop) :
- 65 -
 IP address of the SIP@Net Server (editable when not connected)
 Alarming port number of the SIP@Net Server (editable when not connected)
 Connect/disconnect to/from the SIP@Net Server
 Display of current alarms : Major, Minor and Blocked alarm
 Time the tool was connected to the SIP@Net Server
 Time the current session to the SIP@Net Server started
 Last time the current alarms changed
 Number of sessions that were attempted since this connection was started
 Number of sessions that succeeded since this connection was started
 Graphic display of current alarms
The graphic display will show one of the following icons. Note that a combination of
alarm types is possible.
No alarms
Upper red = one or more Major alarms
Left yellow = one or more Minor alarms
Right purple = one or more Blocked alarms
No connection
The Simple Alarming tool can also be started from the command line. In that case the
following parameters can be specified:
/h(ost) <ip-addr> Specify the IP address of the SIP@Net Server

/p(ort) <port-nr> Specify the port number of the SIP@Net Server
/? or /help Show this text and version information
When both the IP address and the Simple Alarming port number of the SIP@Net
Server are given from the command line (or shortcut) then the tool automatically
connects to the SIP@Net Server.
- 66 -
2.17.2. System Info Console
The System Info Console is used to create an overview of the installed components
and system settings and to collect all kind of diagnostic data such as :
Retrieve COM information

Retrieve installed software information
Retrieve IIS configuration information
Retrieve SIP@Net product and module information
Retrieve all files on the LBU of SIP@Net
Retrieve registry information
Retrieve extended network configuration information, like :
- Connection and listening ports
- Applications creating/using connection and listening ports
- Routing table
- Ethernet statistics
Note : System Info Console runs with low CPU priority. However during busy hour,
running the System Info Console might affect the performance of SIP@Net.
That’s why it is advised to run System Info Console outside office hours.
The System Info Console output has to be added to a support request when a Service
Engineer request support from the NEC Support desk. The output can be generated
via the graphical user interface.
Start the System Info Console as follows :
When the application is started the main window appears :
- 67 -
To generate the System Info Console info data select “Info” and “Create”.
When the information is extracted a progress bar is shown. It takes some time
(especially around 56%) to retrieve all information because it runs with low CPU
priority.
When all information is retrieved, you can use “Save as” to save the data in a file.
All information is stored in a ZIP file, which can be sent to the NEC Support desk.
Example
2.17.3. Diag@Net
Diag@Net is an advanced diagnostic tool for problem detection. Using the Diag@Net,
you can gather information about software problems or detect potential issues like
configuration issues.
Note : In case a virus scanner is used, it is advised to exclude the Diag@Net

directory (C:\NEC\Diagnostic files) from scanning.
Start Diag@Net as follows :
- 68 -
In the left hand pane (application tree, see example) you can select which applications
or services to monitor. Note that events (meaning successful operation of an action)
and exception events are always written to the log file, regardless of the check state.
To enable detailed application tracing, go to "Tools -> Options -> Trace Level" and
select the trace levels to log and monitor.
Note that trace events are only written to the log file if the trace level is ticked.
In "Tools -> Options" you can change some default settings, for example the target
location for diagnostic log files.
Example of Diag@Net in case SIP@Net is (re-)started.

The highlighted row indicates a license Alarm Code 36, QLF 3, ADD 2 and INFO 72.
- 69 -
2.17.4. Windows Event Viewer
With Windows Event Viewer, you can monitor events recorded in event logs.
Applications and operating system components can make use of this centralized log
service to report events that have taken place, such as a failure to start a component
or complete an action. Typically a computer stores the Application, Security and
System logs. It could also contain other logs, depending on the computer's role and
the applications installed.
Start the Windows Event Viewer as follows :
Example of Windows Event Viewer.

The highlighted Warning indicates a license Alarm Code 36, QLF 4, and ADD 1.
- 70 -
2.17.5. Create a System Dump by External Trigger
Since SIP@Net 4.5 it is possible to trigger a system dump without an active OM

session. It can be triggered from the Services interface.
To this purpose the pause-button for SIP@Net service has to be activated. When a
pause is ordered on SIP@Net service, the service is triggered to create a system
dump.
Keep in mind that the SIP@Net service is not actually paused : the system remains
operational. The Services responds to the pause-action with the following message:
This message can be ignored safely.
When a system dump is triggered the alarm 34/02 “System dump created due to a
trigger” is raised. The system dump is saved to the LBU of SIP@Net automatically.
Any system dump that is available in SIP@Net at the time of the external trigger will
also be saved to the LBU.
Usually one system dump is sufficient for further investigation. Therefore the
maximum number of externally triggered system dumps is limited to 1 per minute.
- 71 -
2.18. SIP@Net MOBILTY ACCESS (SMA)
The SIP@Net Server also supports the SIP@Net Mobility Access (SMA) functionality.
Since SIP@Net 5.0, the maximum number of virtual SMA shelves is 10, enabling
10x512=5120 SMA users per system.
For the interface with the PSTN/provider an IP-PM (see chapter 3) or a SIP trunk has
to be projected. In case of a SIP trunk at least one virtual SIP shelf with a virtual
trunk board is required.
Configuration of the SIP trunk is described in the SIP in iS3000 - CE Manual.
Configuration of the SMA is described in "Network and Routing Facilities - Explained"
CE Manual.
Additional information related to Enquiry

SMA users of a SIP@Net Server can initiate enquiry by keytone digit(s). Keytone
(DTMF) digits can be received by the SIP trunk of the SIP extension server in the
following ways :
In-band tone : SIP@Net will not interpret these type of digits.

The digits will be send to the destination as normal speech
(P2P).
SIP INFO message : see below.
RFC2833 : see below.
SIP INFO Message

If the SIP trunk provider or the ISDN gateway supports INFO messages for DTMF,
then the SMA user can initiate enquiry by a DTMF digit.
During a call, 2 ports of the Media Server are involved in the connection : the
connection is not Peer-to-Peer.
The use of the codecs is limited to the codecs the Media Server supports, see section
2.2. SIP@Net SERVER.
For the use of e.g. voice mail applications it is possible to disable enquiry on a per call
base. Then following digits will be regenerated according RFC2833 towards the
destination.
Configuration aspects :
Assign FCM 44 (enquiry by impulse digit) to the BSP-ID of the SMA.

Define (first) “Enquiry Keytone Digit” (BOUND319).
Optionally define “Second Enquiry Keytone Digit” (NEBOUND341).
Define (first) “Disable Enquiry Keytone Digit” (BOUND320).
Optionally define the “Second Disable Enquiry Keytone Digit” (NEBOUND355).
RFC2833
If the SIP trunk provider or the ISDN gateway does not support INFO messages for
DTMF, but instead RFC2833, then the SMA user can initiate enquiry by DTMF digit(s).
During a call 2 ports of the Media Server are in the connection to detect DTMF digits
according RFC2833. The connection is not Peer-to-Peer; the use of codecs is limited to
the codecs the Media Server supports (see section 2.2. SIP@Net SERVER).
The SIP@Net Server is transparent for RFC2833 DTMF digits.
- 72 -
Configuration aspects :
Assign FCM 62 (keytone enquiry entitled) to the BSP-ID of the SMA : see note
below.
Assign FCM 59 (enquiry by keytone-digit limited) to the BSP-ID of the SMA if
enquiry is required only for incoming on trunk calls answered by the SMA user.
Assign FCM 60 (enquiry by keytone-digit full) to the BSP-ID of the SMA if enquiry
is required for all calls to and from the SMA user.
Define (first) “Enquiry Keytone Digit” (BOUND319).
Optionally define “Second Enquiry Keytone Digit” (NEBOUND341).
Define (first) “Disable Enquiry Keytone Digit” (BOUND320).
Optionally define the “Second Disable Enquiry Keytone Digit” (NEBOUND355).
Note : SMA and FCM 62 "keytone enquiry entitled".

When using the enquiry by keytone function then FCM 62 (keytone enquiry
entitled) has to be set in combination with either FCM 59 (enquiry by keytone
digit limited) or FCM 60 (enquiry by keytone digit full).
As FCM 62 is a so called "hardware (EHWA) related FCM" this FCM does not
move with the BSP-ID in case of for example desksharing. But this implies that
after a move of the BSP-ID and a move back of the BSP-ID the FCM 62 is lost.
This results in a broken enquiry by keytone function for the user.
Therefore when the BSP-ID is on a SMA circuit the FCM 62 is not longer
required for the enquiry by keytone function. Only FCM 59 or FCM 60 has to
be assigned to the BSP-ID.
- 73 -
3. IP-PM
3.1. INTRODUCTION
Since SIP@Net 4.5 one or more IP-PM‟s can be added to the SIP@Net Server. An IP-
PM is an iS3000 PM Shelf with extension and/or trunk boards that act as a gateway
between an IP-infrastructure and a TDM-infrastructure.
Instead of having separate different types of gateways, an IP-PM can be used as a

“multi-functional” gateway. The IP-PM provides interfaces for connecting :
analogue telephone sets via an Analogue Line Circuit board (ALC-G).

analogue trunk lines via an Analogue Trunk Unit board (ATU-G).
4-wire digital telephone sets via a Digital Trunk eXtension board (DTX(R)-I).
2-wire digital telephone sets via a Digital Line eXtensions – Upn board (DLX-U).
ISDN 2 (BRI) via a Digital Trunk eXtension board (DTX(R)-I).
ISDN 30 (PRI) via a Digital Trunk Unit board (DTU-G).
PBX network protocols like DPNSS, QSIG (using a DTX(R)-I or DTU-G).
analogue faxes via an Analogue Line Circuit board (ALC-G).
The various boards listed above are already available in a PM of an existing iS3000
hybrid system. Also boards like the VoiceManager 505 (VM505), DDC4/DDC8(R) for
traditional DECT and ATU-PA (for Paging) are supported.
An IP-PM is controlled by a SIP@Net Server which is connected to the PM shelf either

via a PMC-SIC board or a separate SIC and PMC-G board, as illustrated in the figure
below.
- 74 -
An IP-PM does not use the Central-TDM-Switching Network like the SNS boards in the
iS3070/3090 or the CSN board in the iS3050. The Central-TDM-Switching Network is
now replaced by a Central-IP-Switching Network.
The media-stream between TDM ports is always routed via the Central-IP-Switching
Network. In the IP-PM, the ISG is needed to establish IP-media via RTP-streams
between TDM ports and the Central-IP-Switching Network; even when both TDM ports
are in same IP-PM. Note that over one ISG, 30 simultaneous TDM calls can be made.
So it might be necessary to add a second ISG board.
This implies that :
In the IP-PM there is no NCC-HR/MC plug-on card.

In each IP-PM a CRU-cable is needed, when digital TDM-trunks are present. If the
CRU-cable is not present then it is most likely that slip-errors occur.
In each IP-PM sufficient ISG-channels are needed.
The media-stream routing is as illustrated in the figure below :
1) Central-TDM-Switching Network using the SNS or CSN board.
2) The media stream between two TDM-ports even in the same IP-PM is routed via
two ISG-channels and the IP-network.
3) The media stream between one TDM-port and one SIP-port is routed via one
ISG-channel and the IP-network.
4) The media stream between two SIP-ports is routed via the IP-network.
This routing is called peer-to-peer.
- 75 -
A SIP@Net Server can control theoretically a maximum of 31 shelves, which can be
physical IP-PM shelves or virtual shelves. However in SIP@Net 4.5 the maximum
number of IP-PM‟s is set to 20 and the maximum number of BSP-IDs is 5000.
At least one shelf must be a virtual shelf to be able to project a virtual SIP trunk
towards the Media Server.
The Media Server is used for announcements, tones, DTMF-detection and conference
circuits.
The IP-PM uses local PM-paths between ISG-ports and extension-port and/or trunk-
ports. The extension-ports use DTMF-detection via the Media Server. Trunk ports use
local SKT/RKT and or SDT/RDT circuits when required.
The following items are NOT supported in the IP-PM architecture:
Busy Override for SuperVisor 60 operators (on busy trunk lines)

Forced release on busy trunk lines for extension users
IAS-functionality for announcements (the Media Server is used instead)
CCIS
PVN
iPVN (user-channel other than SIP)
Multi unit protocol (IMP)
Voice logging
iTMP-protocol used by ErgoLine@Net and iTMP-DECT
ALC with central Music-On-hold-entry (the Media Server is used instead)
Modem connections : use AudioCodes gateways/convertors
No Alarm Unit (ALU) and Common Answering Night Service (CANS)
For the following items, SIP@Net 5.0 (or higher) is required.

Enquiry for SMA-calls via ISDN or QSIG trunk.
The DTMF digits are recognized by the ISG, not by the RKT.
Non peer-to-peer SIP-trunks.
- 76 -
REMARKS
VoiceManager 505
A VoiceManager 505 (VM505) board is projected as an ALC and thus supported in
an IP-PM.
Traditional DECT
In case of traditional DECT (using DDC4/DDC8(R)) boards, one has to take care for
the clock signal. In the system with TDM Switching Network, the clock signal is
distributed over the system. This means only on a central place synchronization
with an external clock via CRU-input.
In native IP-system each IP-PM must be synchronized, when a digital trunk is
present. This means that each IP-PM with digital trunk needs a CRU-cable.
The DCC boards on different IP-PMs must be synchronized, when the related RFP‟s
are interconnected via the air.
This can be accomplished by a BackBone Repeater (BBR-V3) board in each IP-PM
shelf and a dedicated “Sync Cable DCC8-BBR 1m” cable (12 NC : 9600 016 52000).
Paging
Paging is supported in an IP-PM.
Paging Equipment is connected to an ATU-PA. This Analogue Trunk Unit for Private
Attachments is an adapted ATU-EM using E&M signalling according to ESPA
recommendation 4.4.3.
3.2. PROJECTING ASPECTS
In an IP-PM architecture the "traditional" links between the Switching Network and
the Peripheral Modules (SM-PM links) are not supported anymore.
PMs are linked via IP, via the PMC-SIC/SIC.
This means that OM commands ASLINK / DELINK / DILINK are not relevant
anymore.
It is recommended to use an iS3050 projecting file as bases for an IP-PM

configuration. With the introduction of the IP-PM architecture some functionality
has become obsolete. In case the projecting file contains ASLINK commands then
these commands are skipped. The ASLINK command will no longer be present in
RTRIEV-files.
IP-PM links are projected by setting IP-addresses and IP-ports for the IP-PM-links
with CHSICI.
The status of an IP-PM link can be retrieved by DISICI.
The configuration hierarchy of the IP-PM can be displayed with DICONF.
Reset of IP-PM link is possible via RESICI.
- 77 -
The IP-SIG-GROUP for the Media Server interface is assigned via CHIPSG or
ASBRDS in case of virtual SIP-boards and a route table in the IP-SIG-GROUP (see
CHIPPD).
A TDM-port can only allocate ISG-channels in its own PM. This must be realized by
projecting separate routes for each IP-PM. If only one ISG-route is required in a PM
then only the PMC-board requires an IP-SIG-GROUP. The IP-SIG-GROUP for the
PMC-board is valid for the whole PM. The media access code for the ISG-route is
projected in the IP-SIG-GROUP (IP-PROJ-DATA-TYPE = 0, Media Access Code, see
CHIPPD).
Apart from each IP-PM having an IP-SIG-GROUP assigned, note that also each
other type of virtual PM shelf (e.g. an SMA shelf) must have an IP-SIG-GROUP
assigned. The only exception is the SIP shelf itself: each board in that shelf must
have an IP-SIG-GROUP group anyhow.
Codec order
The codec order in all used SIP-signalling groups must be equal. Also the codec
order of connected SIP-devices must be equal.
To guarantee a matching codec all signalling groups should contain a common
codec.
Via a non-p2p trunk (SIP@Net Server) it is possible to separate domains with
different codec settings.
The codec setting for the non-p2p trunk line side may be completely different
compared to the inner side. There is no need for a common codec on the line side
of a non-p2p with the inner side.
Projecting of ISG-boards is not changed.

In case more than one ISG board is present and projected in the shelf, a number
of TDM boards in the shelf can have IP-SIG-GROUP e.g. B001, containing the
media access code leading to ISG-1 and some other TDM boards in the same shelf
can have IP-SIG-GROUP e.g. B002, containing another media access code leading
to ISG-2.
An IP-SIG-GROUP assigned to a TDM board prevails above the signalling group of
the PMC controlling the IP-PM shelf.
The IP-SIG-GROUP assigned to boards in the IP-PM and/or virtual SIP-ports in the
SIP-shelves can be changed by CHIPPD. The IP-SIG-GROUP contains a route table.
(IP-PROJ-DATA-TYPE = 9, Route table Media Server). The route table contains
routes with bundles that contain SIP-trunk ports. These SIP-trunk ports are able to
setup a SIP-session with the Media Server. In an IP-PM architecture a SIP-port will
never allocate an ISG-port. So the TAC-code (IP-PROJ-DATA-TYPE = 0) to the ISG-
route in the IP-SIG-GROUP assigned to SIP-ports is not used.
The projected IP-SIG-GROUP can be displayed via DIBRDS.
The SIP-boundaries can be the same as the recommended values on a native IP

SIP@Net Server.
The SIP-route data for iPVN SIP-user-channels must have the peer-to-peer option
set.
PMC-G firmware package 810.09.01 or higher is required.
- 78 -
3.3. CLOCK REFERENCE IN IP-PM
The Clock Reference functionality for the PMs connected via IP is handled as with
remote PMs. This means only physical connections, no additional OM. Therefore the
OM commands ASCRUE / DECRUE / DICRUE are not supported on systems with an IP-
PM architecture.
In each IP-PM containing a digital TDM-trunk (via a DTU-G or DTX(R)-I), the PM can
be synchronized to the external clock supplied by that trunk via a clock reference
cable between the DTU-G or DTX(R)-I and the clock input on the PMC-SIC (or PMC-G):
no digital TDM-trunk : no CRU cable

one digital TDM-trunk : 1 CRU cable
more than one TDM-trunk : 2 CRU cables
When both clock inputs are used, the upper input has priority over the lower one.
Subsequently the projecting of a Clock Reference Unit in an IP-PM system is no longer
needed. Note that if the clock reference cable is not present it is most likely that slip-
errors occur.
3.4. PMC-SIC / SIC BOARD
3.4.1. PMC-SIC
The PMC-SIC is the successor of the PMC-G board and the SIC board. The PMC-SIC
must always be placed in the PMC board position 17 in a IP-PM1100 (19 inch) Shelf or
the equivalent position 7 (in a IP-PM255 Lower Shelf).
The PMC-SIC is a downloadable board with its own firmware package id : f19100.102.
The individual packages for the SIC and the PMC-G can not be reused for the PMC-SIC.
The PMC-SIC firmware package can be downloaded from the CPU (using OM command
INSTPK) or via a TFTP server.
Download via TFTP server

The configuration file may be available in 2 formats, either a common file called
prebpmc.txt or a specific prebpmc<mac address>.txt. In general all PMC-SIC board
will have the same application package, so one common prebpmc.txt is normally
sufficient. The PMC-SIC will however scan for both files.
The first line of the prebpmc.txt (or prebpmc<mac address>.txt) configuration file
indicates the application package that needs to run on the PMC-SIC.
An example of such a file is : f19100v1.102
To enforce the PMC-SIC to perform a package load use OM command RESICI.
At power up of the PMC-SIC, an IP address with related netmask, default gateway and
TFTP server (to obtain the SIC configuration file) will be assigned using DHCP.
Operation without DHCP can be achieved by assigning an infinite lease to the PMC-
SIC board. This is done by including the following text in the PMC-SIC configuration
file (identical to the prebisg.txt file of the ISG) :
f19100v1.102
[Control]
DhcpLease=Reuse
First the package will be downloaded from the TFTP server when:
- 79 -
The board is connected to Ethernet, and
The DHCP server gives the address of a TFTP server (using “next server”, not via
option 66), and
The configuration file specifies another package than the currently loaded package,
and
The package is available at the TFTP server.
When one or more of these conditions is not met, the PMC-SIC starts up with its
current package.
Download via OM Command INSTPK

Next the CPU will download a new package when:
A package for the PMC-SIC is defined by INSTPK, and

That package differs from the currently loaded package, and
The new package is available at the LBU.
When both methods are active and define different packages, the PMC-SIC will first
download the TFTP package and then the INSTPK package.
So the package defined by INSTPK overrules the TFTP package.
WARNING : In case of upgrading an existing system (existing projecting)

first modify the firmware package relation to f19100v1.102 or
use a “board-subtype” for the PMC, otherwise the PMC-SIC will
load a PMC-G (or PMC-MC) firmware package. When that is once
loaded, the PMC-SIC will not become operational.
3.4.2. SIC
The SIC is a downloadable board. The configuration file may be available in 2 formats,
either a common file called prebsic.txt or a specific prebsic<mac address>.txt. In
general all SIC boards will have the same application package, so one common
prebsic.txt is normally sufficient. The SIC will however scan for both files. The first line
of the prebsic.txt (or prebsic<mac address>.txt) configuration file indicates the
application package that needs to run on the SIC.
An example of such a file is : fc0000v1.101
To enforce the SIC to perform a package load use OM command RESICI.
The application package includes the boot package image of the SIC as well.
In case a new boot package is required, a new download (application) file must be
present on the TFTP server.
After the new download file is loaded, the application will program the new boot image
into the flash memory and after that, it will perform a reboot.
Note that a power-down during the boot upgrade process may lead to a
defective SIC board !!!
At power up of the SIC, an IP address with related netmask, default gateway and
TFTP server (to obtain the SIC configuration file) will be assigned using DHCP.
Operation without DHCP can be achieved by assigning an infinite lease to the PMC-
SIC / SIC board. This is done by including the following text in the SIC configuration
file (identical to the prebisg.txt file of the ISG) :
- 80 -
fc0000v1.101
[Control]
DhcpLease=Reuse
3.4.3. PMC-SIC / SIC INTERFACES
The PMC-SIC / SIC has 3x 10/100 Ethernet ports mounted at the front.
In case of an IP-PM only the bottom Ethernet port is used :
The bottom Ethernet port is related to the SIC and is applied to communicate
between the SIP@Net Server and the SIC, to control the IP-PM over an IP
connection.
Two clock inputs (PMC-SIC only).
The VGA connector is not used.
The strap on the board must be placed on the bottom pins.
The other Ethernet ports available on the PMC-SIC / SIC board are not used/relevant
in case the PMC-SIC / SIC is installed in the IP-PM.
3.4.4. PMC-SIC / SIC LEDS
The PMC-SIC / SIC is equipped with 3 different LEDs (red, green and yellow). The
color and possible rhythm determine the status of the PMC-SIC / SIC board : see
tables below.
The RAM test indication will hardly be visible, only when the test fails it is steady for
approximately 5 seconds before the PMC-SIC / SIC restarts.
The image updating indication occurring after download of a new package shows a
flashing red LED. During the erasure of the old package the led flashes in a fast
rhythm. When the new package is copied to the old package location the LED is
flashing in a slower rhythm.
Finally when the new package is erased the LED is again flashing in the fast rhythm.
After the update the red LED is steady on indicating the start of the application.
Furthermore each Ethernet connector has 3 (on board) green LEDs associated that
indicate Tx and Rx activity, the Link status and applied speed.
- 81 -
LEDs on PMC-SIC
MEANING
GREEN RED YELLOW
Power up Off On Off
RAM test (data lines) On On Off
RAM test (address lines) On On On
Copying program to RAM On Off On
Program started in BIST mode On Off On
Program started in normal mode Off On On
Downloading new package from TFTP server Off On Flashing
Waiting for communication with CPU On On Off
Operational On Off Off
Installing new package On Flashing On
Downloading new package from CPU (INSTPK) On Off Flashing
One exception applies to this table in the situation where the PMC-SIC is operating in Slave
mode and the Ethernet interface is used. The flashing state of the Yellow LED indicates that
the board is downloading new software. In this situation it is not possible to distinguish
whether the downloading is progressing via TFTP or from the LBU.
LEDs on PMC-SIC
LEDs on SIC
MEANING
GREEN RED YELLOW
Power up Off On Off
RAM test (data lines) On On Off
RAM test (address lines) On On On
Copy application to RAM On Off On
Application copied : BIST On Off On
Application copied : Application Off On On
SIC package download Off On Flashing
SIC Image updating Off Flashing On
SIC Application package start On On Off
Application package operational : On Off Off
communication with the SIP@Net Server is
established
LEDs on SIC
- 82 -
3.5. HOW TO INSTALL / PROJECT THE IP-PM
In the example below an IP-PM is projected in cabinet 1, shelf 2 : so the SHELF

parameter is 12 (or 1012 when system option 0 is set to yes).
1. Check that there is a DHCP and TFTP server in the network.
2. Connect the bottom Ethernet connector on the PMC-SIC / SIC to the LAN.
3. Power-up the PMC-SIC / SIC.
4. The DHCP server handouts an IP address to the PMC-SIC / SIC : take care to
make this a fixed or static address.
In this example the PMC-SIC / SIC IP address is assumed to be 192.168.116.10.
5. Open an OM session on the SIP@Net Server (see section 2.11.4 Installation of

the Tools for the SIP@Net Server) and continue with the following steps.
6. Check that you have license 71 "SIP Extension Server" and enough ISG channels
(license 59). For each IP-PM you need a minimum of 30 ISG channels.
DILICS:71;
DILICS:59;
7. For SIP@Net 4.5

Check that system option 179 "Native SIP Server" is set to 0 and system option
189 "Use SIP Media" is set to 1.
For SIP@Net 5.0 (and higher)
Check that system option 179 "Native SIP Server" is set to 1.
System option 189 is obsolete.
DIMDAT:1,179&189;
When not set correct, change the options to the correct value.
8. After the system options are changed, generate a backup and restart the
SIP@Net service.
GEBUFI:;
9. Assign a PM shelf number 2, with shelf-type 6 (PM1100 shelf) in cabinet 1.

ASSHLF:12,6;
10. Assign a PMC-SIC (or PMC-G) board in position 17, with board-type 91, signalling
group 0B04, hw-type 255.
ASBRDS:12,17,91,0B04,255;
Assigning the PMC-SIC board might fail because boundaries 51 and 52 (number
of RKTs/SKTs) are set too low : increase those two boundaries.
Also set system option 66 “System with Central Switching Network” to “0”.
Note that in an existing projecting, the PMC-SIC board has to be assigned with a
"board-subtype", to avoid the situation that the board will load the wrong PMC-G
(or PMC-MC) firmware package.
ASBRDS:12,17,91-xx,0B04,255;
INSTPK:f19100.101,,xx;
in which xx is an arbitrary board-subtype.
- 83 -
11. Set the PMC in service.
SETINS:12,17;
At this stage the PMC remains in ABL-ER.
12. Define a SIP signalling group, for example B012.

Specify in this signalling group at least :
● the media access code, leading to the ISG in the IP-PM shelf 12,
● the codec order,
● the payload size,
● the way of handling DTMF, and
● the route table to the media server
CHIPPD:B012,0,12;
CHIPPD:B012,4,1,0;
CHIPPD:B012,5,30;
CHIPPD:B012,6,1;
CHIPPD:B012,9,90;
13. Check the changed signalling group data using DIIPPD:B012;

The response of the data entered in the previous step is as follows :
<DIIPPD:B012;
SIG-GRP LANGUAGE ACCESS CODE GATEKEEPER CODECS PAYLOAD RFC2833 ROTA
B012 - 12 - 1 0 - - 30 96 90
SRTP ENCRIPTION AUTHENTICATION T.38 SESSION
- - - - -
VoIP DATA
14. Assign the SIP signalling group (defined in previous step) to the each whole IP-
PM shelf by assigning it to the PMC in position 17.
Apart from each IP-PM having an IP-SIG-GROUP assigned, note that also each
other type of virtual PM shelf (e.g. an SMA shelf) must have an IP-SIG-GROUP
assigned. The only exception is the SIP shelf itself: each board in that shelf must
have an IP-SIG-GROUP anyhow.
CHIPSG:12,17,B012;
All PCT boards and circuits controlled by this PMC will have the same SIP
signalling group B012.
In case of more than one ISG board in the shelf, a number of PCT boards in the
shelf can have SIP signalling group B012, containing the media access code (12)
leading to ISG-1 and some other PCT boards in the same shelf can have SIP
signalling group B015, containing another media access code (e.g. 15) leading to
ISG-2.
Example
CHIPSG:12,1&&8,B012;
CHIPSG:12,9&&16,B015;
Then the boards in positions 1 up to 8 will use ISG-1 and the boards in positions
9 up to 16 will use ISG-2.
15. Set the IP address that the CPU will use to establish an IP link with the
PMC-SIC / SIC.
CHSICI:12,17,1,192.168.116.10;
Note that 17 is the "PMC" position !!!
- 84 -
In case the system response is “Illegal parameter combination”, system option
179 is not set correct :
- in SIP@Net 4.5 : option 179 must be set to 0.
- in SIP@Net 5.0 : option 179 must be set to 1.
16. Check that the PMC-SIC / SIC is INS, using DISICI.

The IP addresses and PMC-SIC / SIC related information is displayed :
<DISICI:12,17;
IP ADDRESS NETMASK DEFAULT GATEWAY ETHERNET ADDRESS
192.168.116.10:2950 255.255.255.0 192.168.116.240 00-18-27-00-77-2A
DHCP TFTP SERVER BOOT-PACK APPL-PACK HW-12NC HW-SERIAL#

Yes 192.168.116.240 C090.01.01 C000.01.01 9600-021-53001 SBxxx00046
SHELF BRD CRT STATUS LOCAL IP ADDRESS SIC IP ADDRESS

12 17 - INS 192.168.116.20:1560 192.168.116.10:2950
EXECUTED
17. Project an ISG in the shelf : see chapter 4.
18. Now continue with projecting the various other PCT boards (like the ALC-G,
DTX(R)-I, DTU-G), depending on the required configuration.
ALC-G : ASBRDS:12,1,6,3210;
DTX(R)-I : ASBRDS:12,3,11,090F;
DTU-G : ASBRDS:12,5,18,5D0D;
Projecting advice
To keep a simple overview (especially when having the maximum of 20 IP-PMs) of the
various SIP signalling groups of the IP-PMs and the media access codes to each ISG in
each IP-PM, it is advised to use the numbering as indicated below.
SHELF 21 31 41 51
SIP Signalling Group B021 B031 B041 B051
Media Access Code to ISG 21 31 41 51
SHELF 12 22 32 42 52
SIP Signalling Group B012 B022 B032 B042 B052
Media Access Code to ISG 12 22 32 42 52
SHELF 13 23 33 43 53
SHELF 14 24 34 44 54
In this way you keep a structured overview.

When a second SIP signalling group is required in an IP-PM you can use signalling
group B015 … B019, B025 … B029, etc.
Note that for this way of numbering, boundary 420 "Max number of SIP signalling
groups" has to be set to at least 55.
- 85 -
3.6. CLASSIC DECT IN MULTIPLE IP-PMs
Classic DECT with the existing DCC boards (DCC4, DCC8 and DCC-8(R)) in one
single IP-PM can be realized rather easy. The only restriction is the accuracy of the
DECT timing, which is derived by the master DCC from the local 2 MHz back panel
timing. A good quality clock can be obtained from an external PSTN trunk of from a
local high quality clock source, as present on the BBR board. Since all equipment is
confined in one PM, there will be no timing issues related to TDM and DECT timing.
Things become different, when classic DECT expands over more than one IP-PM.
The IP-PMs do not have correlation between their timing. Synchronization between
DECT and TDM domain can be realized by regenerating the TDM timing from the DECT
timing.
To this end :
• in each IP-PM one BBR-V3 board has to be present : see figure below.
• in each IP-PM a CRU coax cable has to be present between the BBR and PMC
(green connection).
• in each “slave” IP-PM a dedicated “Sync Cable DCC8-BBR” cable
(12 NC 9600 016 52000) has to be used (yellow connection).
Since the DCC4 misses the connection for this “Sync Cable DCC8-BBR” cable, it
means that the Local Master DCC boards must be a DDC8 or DCC8R board. So the
DCC4 can only be used as the System Master DCC.
- 86 -
The BBR synchronizes the TDM timing by using the DSP (DECT Sync Port) signal. The
DSP is derived from the backbone timing. The DSP is fed from the Local Master DCC
to the BBR, which synchronizes the 2 MHz reference clock to it. This 2 MHz clock is fed
to the CRU input of the PMC. Only the frame timing may have an offset related to the
DECT timing. This offset is handled (compensated) by the BBC. Frame-slip will not
occur.
DCC (SM) = System Master DCC.

Defines the DECT timing in its own IP-PM and distributes it to all other IP-PMs via the
backbone (BBR).
DCC (SL) = Slave DCC.

Synchronizes to the Master DCC (SM or LM) in the same IP-PM.
DCC (LM) = Local Master DCC.

Defines the DECT timing in its own IP-PM and synchronizes to the System Master DCC
timing via the backbone.
The BBR-V3 in IP-PM1 has to be strapped as “stand alone” using straps X6.1 and X6.2.
The BBR-V3 in the other IP-PMs 2, 3 and 4 has to be strapped as “master”.
- 87 -
4. IN SYSTEM GATEWAY (ISG)
The In-System Gateway (ISG) is a PCT board in the IP-PM that performs the media
connection function between the iS3000 and the SIP terminals.
On every ISG board the first 10 B-channels can be used without a license.
For every additional 10 channels, SIP@Net license 59 is required :
for hybrid systems you can order extra ISG licenses.

for native IP systems you must order extra ISG licenses.
The ISG must be loaded with firmware release fa2010v1.609 or higher.

It is possible to achieve load-sharing when two (or more) ISGs are present in the
system.
4.1. PROJECTING THE ISG
1. Assign one (or more) ISG board(s) with board-type 18, signalling group
5D21 - QSIG in each IP-PM.
ASBRDS:12,19,18,5D21,255;
2. Assign an analysis tree (if not yet present) to DIAL-TYPE 11: "media dialling".
The TAC to be used for the media access code is analysed in the projected
analysis tree, in this example 11.
ASTREE:11,11;
3. Assign for each IP-PM a media access code (trunk access code) to the destination
(the ISG in the IP-PM) in the analysis tree related to dial type "media dialling"
IP-PM shelf 12 : media access code 12
IP-PM shelf 13 : media access code 13
etc.
In the example below media access code 12 is used for IP-PM shelf 12.
So analysis tree '11', trunk access code '12' and destination '12' is used.
ASINTN:11,12,2,21,12;
4. Set the destination characteristics.

CHDSTC:12,12,00,12;
5. Create a QSIG route.

CRROUT:12;
6. Enter the route in the route table.

CHROTA:12;
Enter route table data :12,1,2;
Enter route table data :;
7. Set the route characteristics.

CHRTCG:12,01100100001,543543;
CHRTCI:12,10100000000,000699999,35;
CHRTCO:12,000100,0
8. Set the bundle characteristics.

CHBNDC:12,22,0000000000010001,420;
The CON-AND-SIG-TYPE of the "ISG bundle" is always 420 : QSIG-A
- 88 -
9. Assign the bundle to the route.
ASBNDL:12,12;
10. Assign 30 lines to the bundle.

ASLINE:12,0101,12,19,0,1;
| | | |
ASLINE:12,0115,12,19,0,15;
ASLINE:12,0117,12,19,0,17;
| | | |
ASLINE:12,0131,12,19,0,31;
11. Repeat steps 3 up to 10 for each IP-PM in shelf 13, 14, 21, 22, etc.
12. Make sure that on the TFTP server a prebisg.txt (or prebisg<mac-
address>.txt in case only one specific ISG should be loaded) file is present.
This basic configuration files contains the name of the used ISG software
package (e.g. fa2010v1.609)
13. Make sure that on the TFTP server the software package fa2010v1.609 (or
higher) is present.
14. Set the ISG board and circuit 0 into service : now the isg<mac-address>.sdp and
isg_trunk.sdp files are loaded.
SETINS:12,19; (12,19 is the ISG board position given in step 1)
SETINS:12,19,0;
15. To check the settings on the ISG, start up a web-browser and fill in the IP
address of the ISG. To login, use "isgadmin" for both the Username and
Password (case sensitive and fixed).
Keep in mind that the browser output is mainly for test/check-purpose. This
means that the layout might be enhanced in the future release of the ISG.
Furthermore not all data is valid e.g. when the data is "unknown", then it means
default value.
SECURITY ASPECT
It is possible to switch OFF the ISG web server page.
To achieve this the following text lines have to be included in the prebisg.txt file :
[WebServer]
WebServerEnabled = 0
Default the webserver will be on.
- 89 -
- 90 -
- 91 -
In the "Channel Status Overview", the second column indicates the status of the
channels. This can be :
- Free : B-channel is not used.

- Busy IO : B-channel is used for an "Internal Outgoing" call
(call from/to IP phone).
- Busy TO : B-channel is used for a "Trunk Outgoing" call (call between ISGs).
- Busy TI : B-channel is used for a "Trunk Incoming" call (call between ISGs).
- Busy EI : B-channel is used for an Incoming call to an Extension
connected to an IP21.
- Busy EO : B-channel is used for an Outgoing call from an Extension
connected to an IP21.
- Busy S : B-channel is used for "SIP" call.
- Busy SN : B-channel is used for "SIP" call, but no RTP channel is assigned.
Note that for a SIP and CCIS call it is not possible to discriminate between an
incoming or outgoing call.
4.2. ISG OPERATION WITHOUT DHCP AND TFTP SERVER
The ISG has the possibility to operate without DHCP and TFTP. For DHCP the ISG
makes use of the so-called infinite lease mechanism. There are 2 mechanisms to
assign fixed IP address. A LAN based procedure and a peer-to-peer procedure.
In case VLAN tagging is applied notice that in that case the PC that is referred to in
step 3 needs to be equipped with 2 network interfaces. This interface has to be
able to deal with 802.1Q-tagged Ethernet frames. The OS has to pass VLAN
identifiers to the DHCP/TFTP server.
All settings (IP settings, configuration items and trunk table) are stored in flash. So
a TFTP server is no longer required to guarantee a proper operation of the ISG.
To make it possible to operate without the use of DHCP in a controlled manner the
following tag [Control] and one of the four DhcpLease possibilities have to
included in the prebisg.txt configuration file :
[Control]
DhcpLease=Reuse or,
DhcpLease=Replace or,
DhcpLease=Erase or,
DhcpLease=Ignore
Reuse
In case no lease is available in flash yet, a lease will be obtained and stored in
flash (provided it is an infinite lease). In case a lease is available in flash already,
no DHCP access will be done and the lease from flash is used. This is ‟the option‟
for operation without DHCP server.
- 92 -
4.3. UPGRADING OF ISG FIRMWARE PACKAGE
In case new ISG firmware has to be loaded, execute the following steps :
1. Copy the new application package (which is available on the iS3000 Series
Software CD ROM) to the TFTP server's working directory.
2. Copy (and rename if applicable to the prebisg.txt file) the example file prebisg.txt,
which is also present on the iS3000 Series Software CD ROM.
3. Force a reboot action of the ISG.

This can be realized by means of :
- power-down/up of the ISG or,
- putting circuit 0 or the whole board out of service.
Then the application package will read the prebisg.txt file on the TFTP server for
the file name. This file name will be compared with the file name of the current
application package. If the ISG notices a different application package, then it will
reboot.
With OM command DIEQID the software version of the application package and boot-
package can be checked.
Take care that the TFTP server will not be overloaded. Put the ISG out of service only
when no other main actions are running on the TFTP server e.g. simultaneously
upgrading of SIP terminals firmware.
4.4. ISG LEDS
At the front of the ISG board LED indicators are present, indicating the status of the
board. Via the on-board web-server diagnostic data is available.
LEDS
MEANING
GREEN RED
No system power or defect on-board power Off Off
PMC not operational or no operational package Off On
or Internal test active
Operational package running and waiting for On On
commands from PMC
Communication with PMC On Off
Software downloading via IP-connector Off Winking
- 93 -
A. BOUNDARIES
For the boundaries not listed below, refer to the Second Line Maintenance Manual.
BOUNDARY DESCRIPTION MAX VALUE

1 Exchange number 3000
10 Max number of extension circuits 9984
11 Max number of night extensions 255
13 Max number of hotlines 512
15 Max number of secretary groups 400
(the max value is related to boundary 17)
16 Max number of operators 31
17 Max number of groups 1000
20 Max number of COB places 999
21 Max number of COB queues 999
22 Max number of ARB destination places 512
23 Max number of ARB primary places 512
24 Max number of ARB primary queues 512
27 Max number of BSPs 9984
29 Max number of queues CANS calls 255
30 Max number of abbreviated numbers 4496
31 Max number of digit conversions per route 20
32 Max number of projected CV values 255
35 Max number of IABD numbers per user 100
36 Max number of IABD elements 12000
37 Max number of IABD list entries 4621
46 Max number of extension DNRs 9984
53 Max number of trunks 3000
57 Max number of bundles 255
59 Max number of routes 255
63 Max number of routes in system 255
64 Max number of msg waiting requests in queue 255
70 Max number of analysis trees 255
71 Max number of analysis pyramids 999
72 Max number of analysis groups 255
73 Max number of DNRs in system 65530
74 Max number of outgoing destinations 255
83 Max number of PMs 31
91 Max number of resource relations 12000
108 Max number of PCT ips 80
139 Max number of TT data blocks 600
154 System limited number of shelves per cabinet 4
- 94 -
174 System limited number of cabinets 15
195 Max number of simultaneous ARB destinations 512
202 Max number of control blocks 6150
203 Max number of signal packets 32000
204 Max number of short data blocks 512
205 Max number of long data blocks 700
206 Max number of user stacks 480
213 Max number of different OM commands in system 1000
218 Max number of long facility destinations 1000
219 Max number of members 5000
222 Max number of buffer packets 2400
231 Max number of ACD groups 100
247 Max number of ACD agents 400
250 Max number of FDCR data blocks 2400
255 Max number of outgoing digit conversions 6000
257 Max number of medium data blocks 2400
275 Max number of IPD entries 6000
276 Max number of CSTA links per unit 15
277 Max number of CSTA monitored BSPs 5000
279 Max number of CSTA calls per unit 3000
288 Max number of I/O packets 480
291 Max number of status monitoring items 10000
293 Max number of stored call records in system 65533
305 Max number of internal CNND database entries 11015
306 Max number of CNND cache entries 1000
307 Max number of free numbering entries 65530
315 Max number of CLI/COL translation entries 10000
326 Max number of CSTA data paths 2000
328 Max number of CSTA I/O registrations 2000
330 Max number of CSTA call ids per unit 4096
342 Max number of internal name database entries 65530
345 Max number of ARB relations 512
350 Max number of external name database entries 65530
364 Max number of call forwarding not reachable 10
367 PVE max extension monitors 65534
368 PVE max group monitors 65534
369 PVE max data monitors 65534
372 Max number of virtual PMs in a unit 10
415 SIP relay listen port number 2610
416 SIP driver listen port number 5060
417 Max number of SIP drivers 10
- 95 -
418 Max number of SIP trunk calls per unit 500
419 Max number of SIP routes per unit 255
420 Max number of SIP signalling groups 255
424 Max number of SIP transactions 2500
425 Max number of Kbytes for SIP heap not appl.
426 Max number of SIP extension calls per unit 1000
432 Max number of monitors for SIP extensions 2000
433 Max number of monitors per extension for SIP 40
435 Max number of SIP monitors 8000
436 Max number of virtual SIP shelves 10
437 SIP driver TLS listen port number 5061
As a general rule all boundaries that are applicable for the SIP@Net Server may be set
(with some exceptions) to a maximum value identical to the CCS platform.
- 96 -
B. SIMPLE NETWORK MANAGEMENT PROTOCOL (SNMP)
With help of the (pre-installed) tool “evntwin.exe”, the iS3000 SIP@Net log-events
can be configured to be translated into SNMP traps. An SNMP Trap is an SNMP
message that is autonomously sent by an SNMP Agent application to one or more
SNMP Management applications. This appendix explains how to configure the MS-
Windows SNMP Agent to generate SNMP Traps for the iS3000 SIP@Net events.
SNMP uses a distributed architecture consisting of agents and managers. An agent is

an SNMP application that responds to queries from SNMP manager applications. The
SNMP agent is responsible for retrieving and updating local management information
based on the requests of the SNMP manager. The agent also notifies registered
managers when significant events or traps occur. A manager is an SNMP application
that generates queries to SNMP agent applications and receives traps from SNMP
agent applications.
On Windows computers, the SNMP agent is implemented by the Windows SNMP

service (snmp.exe). The SNMP Management Console is typically a third-party
application and does not need to (but may) run on the same host as the SNMP agent.
When using SNMP it is assumed that SIP@Net is running : check that with the Service
Utility.
B.1. ADDING TRAP DESTINATIONS
First the SNMP Community Name(s) and the Trap Destinations have to be configured.
A community name is part of every SNMP Message and serves as a kind of 'password'.
The SNMP management application will only accept SNMP messages containing
community names that have been added to it. Ask the Network Administrator what
Community name(s) the SNMP Manager(s) will accept.
1. In the Service Utility, locate the SNMP Service. This is the SNMP Agent on this
computer that will send SNMP Traps to the (remote) SNMP Manager.
- 97 -
2. Double Click the SNMP Service in the List and the following Dialog will appear :
3. In this dialog, select the Traps tab, then enter a valid Community Name, then
Add to list, then add the IP address(es), hostname or IPX address of one or more
SNMP-Managers to the Trap-destinations-list by pressing the Add button.
Note that more than one Community Name can be added, each containing one or
more (SNMP Manager) Destination addresses.
B.2. ADDING iS3000 SIP@Net EVENTS TO THE SNMP TRAP LIST
1. Start the Event to Trap Translator Configuration Utility.
2. Press “Start”, select “Run” and type "evntwin" in the Run Dialog Box and press
“OK”.
- 98 -
3. The Event to Trap Translator Configuration Utility will now appear :
4. Select Configuration type “Custom”, then “Edit”, to make it possible to add

custom events.
5. In the Event Sources list, open the Application folder.
- 99 -
6. Scroll down to iS3000 SIP@Net in the Event sources list and click on it.
In the Event List on the right (when scrolling down), all possible iS3000 SIP@Net
events will be listed :
• event id's 200, 202, 204 and 206 represents the generated
major, minor, silent and blocked alarms respectively.
• event id's 201, 203, 205 and 207 represents the cleared
major, minor, silent and blocked alarms respectively.
7. Now you can add the individual iS3000 SIP@Net Events (or any other
applications) that you want to be translated to SNMP Traps, by selecting them in
the Event List on the right, and select “Add”.
8. The following Dialog will appear for each added Event :
- 100 -
9. Note that the Enterprise OID will be the SNMP OID as it will be sent to the SNMP
Manager.
10. Finally, press “OK”.
- 101 -
C. SPECIFICATIONS FOR SIP@Net SERVER
NEC is providing a limited range of certified NEC servers to support the suite of unified
communication applications. The NEC Unified server line comprises of a limited range
of fixed IT platforms.
Budget SMB Server (NEC Express 5800 GT110b)
Localized Operating System, keyboard and

mouse. And optional a monitor and
19”bracket for small to medium installations
in both front and back offices.
Standard Application Server (NEC 5800 Express)
This server has six cores bare metal or virtual

services (VM‟s) and offers a limited number of
protected Virtual Machines. This server is
cloud ready and provisioned for remote
management including installation.
Enterprise Performance Server (NEC 5800 Express 2U/FT)
A server with 12 cores for full virtual

infrastructure or desktop. V-available based
on Citrix and Marathon to run NEC‟s Unified
Business Communications proposition in a
fault tolerant environment without the burden
of SAN‟s. Support for third party hypervisors
like ESXi and Hyper-V and with the present of
a customer SAN even third party high
availability. This server is cloud ready and
provisioned for remote management including
installation.
Server Blade Technology (NEC Flexpower)
NEC‟s Flexpower with blade server technology

to support fully virtualized desktop and
infrastructure solution (12 C). Support for
hypervisors like XEN, ESXi and Hyper-V and
with the presence of integrated SAN to run
NEC‟s Unified Business Communications
proposition in a fault tolerant environment.
The Flexpower is cloud ready and provisioned
for remote management including installation.
- 102 -
Detailed information per server is listed below.
Budget SMB Server (NEC Express 5800 GT110b)
1 x Chassis Mini-Tower (size : 175w x 430d x 367h)

1 x Xeon X3430 QuadlCore
1 x 2GB Memory
1 x 500GB SATA
1 x PCI + 3 x PCIe
1 x Mouse + keyboard localization : French, Italian, Belgium, UK and US Int.
1 x Windows 2008 Foundation
Language localization : English, Brazilian, Czech, Dutch, French, German,
Hungarian, Italian, Polish, Portuguese, Russian. Spanish, Swedish, Turkish
1x DVD ROM
1x Ultracare Service BASIC 3 Years - Onsite NBD intervention
Optional
1x 19” rack bracket

1x 22” widescreen multi-sync monitor with audio (black)
Standard Application Server (NEC 5800 Express)
1x NEC Server R120b-1 Hotswap High efficiency 80+ Gold PSU Model 0 - no
CPU, no RAM, no 2.5' HDD, no DVD-ROM, no FDD
1 x Front Bezel for Express5800/R120b-1
1 x Cable Arm kit (One Touch Rails compatible only)
1 x Hot swap and Redundant 650w 80+ gold power supply
1 x Intel® Xeon® Processor E5645 (6 Core, 2.40GHz, 12MB, 5.86GT/s)
2 x 4GB DDR3-1333, 1.35V/1.5V, Registered (1x 4GB, PC3-10600)
1 x 1x PCI EXPRESS 2.0(x16) + 1x PCI EXPRESS 2.0(x8) Std riser
1 x LSI MegaRAID Sas/Sata 9264-8i controller, RAID0/1, 256MB, BBU less,
Int. X8
1 x RAID 1 Activation Service ( 2 HDDs, same disk capacity)
2 x HDD SAS 2.5" HotSwap 15K (6Gbps) 146.5GB
1 x Battery Backup Unit for LSI MegaRAID SAS8708EM2 and 9264-8i controllers
1 x Intel PRO/1000 PT Dual Port Gigabit Copper NIC (2x 10/100/1000, 2x RJ45,
PCI Express X4, ALB/AFT)
1x SATA DVD superMulti Slim 4,7/9,4GB
1x Ultracare Service BASIC 3 Years - Onsite NBD intervention or CRU exchange
(EC-CAT2)
Enterprise Performance Server (NEC 5800 Express 2U/FT)
1x NEC Server R120b-2 Hotswap High efficency 80+ Gold PSU Model 0 - no
CPU, no RAM, no 2.5' HDD, no DVD-ROM, no FDD
1 x Front Bezel for Express5800/R120b-2
1 x Cable Arm kit (One Touch Rails compatible only)
1 x Hot swap and Redundant 750w 80+ gold power supply
8 x 4GB DDR3-1333, 1.35V/1.5V, Registered (1x 4GB, PC3-10600)
3 x PCI EXPRESS 2.0(x8) + 1x PCI EXPRESS 2.0(x4) + 1x PCI EXPRESS(x4) Std
riser
- 103 -
1x LSI MegaRAID Sas/Sata 9264-8i controller, RAID0/1/5/6, 256MB, BBU less,
Int. X8
1 x RAID 5 Activation Service ( 3 HDDs minimum, same disk capacity)
4 x HDD SAS 2.5" HotSwap 15K (6Gbps) 146.5GB
1 x Battery Backup Unit for LSI MegaRAID SAS8708EM2 and 9264-8i controllers
2 x Intel PRO/1000 PT Dual Port Gigabit Copper NIC (2x 10/100/1000, 2x RJ45,
PCI Express X4, ALB/AFT)
1x SATA DVD superMulti Slim 4,7/9,4GB
1x Ultracare Service BASIC 3 Years - Onsite NBD intervention or CRU exchange
(EC-CAT3)
Server Blade Technology (NEC Flexpower)
1x NEC Server FlexPower enclosure (including 2x1000W PSU, Hotswap

Redundant fans, 1x Storage Controller, 1x Lan switch, 1x management
module and management Software), no compute module, no HDD
2x 1000W Power Supply Unit and cables (2x units necessary for 2-3 servers, 3x
for 4-6, fourth unit for redundancy, 100/240VAC, 1x power cable+ 1x IEC
320 cable)
2x WestMere Compute Module with 1x E5645 CPU / 1x 8GB DDR3 1333Mhz
registered Memory
6x HDD SAS 2.5" HotSwap 15K 146.5GB
2x Nehalem/Westmere LAN Mezzanine Card (2-port Gigabyte Ethernet) (One
card required on each compute module with optional Gigabyte Ethernet
Switch)
1x Redundant Gigabyte Ethernet switch module (10x ports uplink)
1x Redundant SAS Storage module (with battery backup; 4x external SAS ports)
1x Ultracare FlexPower Service BASIC 3 Years - Onsite NBD intervention or CRU
exchange (EC-CAT7B)
2x Intel® Xeon® Processor E5645 (6 Core, 2.40GHz, 12MB, 5.86GT/s)
1x Flexpower Enhanced SAN support kit (to enable sharing virtual disks across
several compute modules
6x 8GB DDR3-1333Mhz ECC Registered SDRAM (1x 8GB)
NEC Flexpower Expansion
1x WestMere Compute Module with 1x E5645 CPU / 1x 8GB DDR3 1333Mhz

registered Memory
3 x 8GB DDR3-1333Mhz ECC Registered SDRAM (1x 8GB)
2 x HDD SAS 2.5" HotSwap 15K 146.5GB
1 x Nehalem LAN Mezzanine Card (2-port Gigabyte Ethernet) (One card required
on each compute module with optional Gigabyte Ethernet Switch)
1x Ultracare FlexPower Service BASIC 3 Years - Onsite NBD intervention or CRU
exchange (EC-CAT7B)
*** INCLUDED IN THE ULTRACARE CHASSIS CONTACT ***
- 104 -
D. SIP@Net SERVER LIMITATIONS
The SIP@Net Server running the latest SIP@Net release still has a number of
limitations as listed below :
Only announcement functionality for operator and ACD functionality, no digit

detection to select extension.
No G722 on Media Server so no HD quality announcements.
No SRTP and TLS on Media Server so no encryption on 3 party conference.
No call-break warning tone for budget dialling when budget is reaching the end.
No WLAN-terminals with SRTP/TLS.
No Central Directory Dialling with Polycom terminals.
No Terminal Quality-messages.
No SIP Multi-party video conference.
No SIP Voice Logging.
No CCIS interface on CCIS to NECJ voice servers.
No Certification-server for encryption, iS3000 uses build in certificate.
No iTMP support.
No remote survivability.
- 105 -
E. OPEN SOURCE LICENSE ACKNOWLEDGMENT
SIP@Net uses third-party open source software, in modified or in unmodified form,
subject to the following licenses (see next paragraphs).
Under request, the Owner can provide you a copy of the license.
A copy of the, by NEC Nederland B.V. modified third-party open source software
source code can be obtained “as-is” by sending a written request to:
NEC Nederland B.V.

P.O. BOX 32
1200 JD Hilversum
The Netherlands
E.1. oSIP libraries
The application SIP@Net uses oSIP libraries, which are available under GNU Lesser
General Public License (LGPL) version 3.
You may obtain a copy of the LGPL at :
http://www.gnu.org/licenses/lgpl.html
E.2. PWLib libraries
The application SIP Driver uses the PWLib libraries, which are available under Mozilla
Public License (MPL) version 1.1.
You may obtain a copy of the MPL at :
http://www.opensource.org/licenses/mozilla1.1.php
E.3. OpenTLS libraries
The application SIP Driver uses the OpenTLS libraries, which are available under
Apache-style license.
You may obtain a copy of the Apache-style license at :
http://www.apache.org/licenses/LICENSE-2.0
E.4. PJSIP (PJMEDIA)
The application Media Server uses PJSIP (PJMEDIA) and is subject to GNU General
Public License (GPL) version 3.
You may obtain a copy of the GPL license at :
http://www.gnu.org/licenses/gpl.html
E.5. OpenH323 and PWLib
The ISG uses OpenH323 library version 1.10.4 and PWlib version 1.1.4, which are
available under Mozilla Public License (MPL) version 1.1.
You may obtain a copy of the MPL at :
http://www.opensource.org/licenses/mozilla1.1.php
- 106 -
E.6. TLS
For TLS that is part of the SIP driver the openssl library version openssl-0.9.8e is
applied. The following text is applicable to the open ssl library:
OpenSSL License:
Copyright (c) 1998-2004 The OpenSSL Project. All rights reserved. Redistribution and
use in source and binary forms, with or without modification, are permitted provided
that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this list of
conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this
list of conditions and the following disclaimer in the documentation and/or other
materials provided with the distribution.
3. All advertising materials mentioning features or use of this software must display
the following acknowledgment: "This product includes software developed by the
OpenSSL Project for use in the OpenSSL Toolkit (http://www.openssl.org/)".
4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to
endorse or promote products derived from this software without prior written
permission. For written permission, please contact openssl-core@openssl.org.
5. Products derived from this software may not be called "OpenSSL" nor may
"OpenSSL" appear in their names without prior written permission of the
OpenSSL Project.
6. Redistributions of any form whatsoever must retain the following

acknowledgment: "This product includes software developed by the OpenSSL
Project for use in the OpenSSL Toolkit (http://www.openssl.org/)".
THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY
EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR ITS
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY
OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
This product includes cryptographic software written by Eric Young

(eay@cryptsoft.com). This product includes software written by Tim Hudson
(tjh@cryptsoft.com).
Original SSLeay License Copyright (C) 1995-1998 Eric Young (eay@cryptsoft.com).

All rights reserved.
- 107 -
This package is an SSL implementation written by Eric Young (eay@cryptsoft.com).
The implementation was written so as to conform with Netscapes SSL. This library is
free for commercial and non-commercial use as long as the following conditions are
sheared to. The following conditions apply to all code found in this distribution, be it
the RC4, RSA, lhash, DES, etc., code; not just the SSL code.
The SSL documentation included with this distribution is covered by the same
copyright terms except that the holder is Tim Hudson (tjh@cryptsoft.com).
Copyright remains Eric Young's, and as such any Copyright notices in the code are not
to be removed. If this package is used in a product, Eric Young should be given
attribution as the author of the parts of the library used. This can be in the form of a
textual message at program startup or in documentation (online or textual) provided
with the package.
Redistribution and use in source and binary forms, with or without modification, are
permitted provided that the following conditions are met:
1. Redistributions of source code must retain the copyright notice, this list of
2. Redistributions in binary form must reproduce the above copyright notice, this
list of conditions and the following disclaimer in the documentation and/or other
3. All advertising materials mentioning features or use of this software must display
the following acknowledgement: "This product includes cryptographic software
written by Eric Young (eay@cryptsoft.com)". The word 'cryptographic' can be left
out if the routines from the library being used are not cryptographic related.
4. If you include any Windows specific code (or a derivative thereof) from the apps
directory (application code) you must include an acknowledgement: "This
product includes software written by Tim Hudson (tjh@cryptsoft.com)".
THIS SOFTWARE IS PROVIDED BY ERIC YOUNG "AS IS" AND ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR
ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
The licence and distribution terms for any publically available version or derivative of
this code cannot be changed. i.e. this code cannot simply be copied and put under
another distribution licence [including the GNU Public Licence.]
- 108 -
E.7. SRTP
For SRTP version 1.4.2 is applied. The following license text is applicable to the SRTP
library.
The srtp library and the test drivers distributed with it are licensed under the following
BSD-based license.
Copyright (c) 2001-2005 Cisco Systems, Inc.

All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are
permitted provided that the following conditions are met:
Redistributions of source code must retain the above copyright notice, this list of
Redistributions in binary form must reproduce the above copyright notice, this list
of conditions and the following disclaimer in the documentation and/or other
Neither the name of the Cisco Systems, Inc. nor the names of its contributors may
be used to endorse or promote products derived from this software without
specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS

"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
HOLDERS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- 109 -

SIP@Net Server CE Manual

Uploaded by

Copyright:

Available Formats

SIP@Net Server CE Manual

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SIP@Net Server CE Manual

Uploaded by

Copyright:

Available Formats

SIP@Net Server

Customer Engineer Manual

Issue : January 2012

Date : January 2012

NEC Nederland B.V.

© NEC Nederland B.V.

2. SIP@Net SERVER ...................................................... 6

4. IN SYSTEM GATEWAY (ISG) .................................... 88

B. SIMPLE NETWORK MANAGEMENT PROTOCOL ......... 97

C. SPECIFICATIONS FOR SIP@Net SERVER ............... 102

D. SIP@Net SERVER LIMITATIONS ............................ 105

E. OPEN SOURCE LICENSE ACKNOWLEDGMENT ........ 106

For countries in the European Union

The symbol depicted here has been affixed to your product in

Electrical and electronic products including the cables, plugs and

At www.nec-unified.com/weee you can find information about separate disposal and

For countries outside the European Union

Defect or exhausted batteries should never be disposed of as

The SIP@Net Server is a native IP communication system running as a 32-bit

Windows Server 2003.

Figure 1. SIP@Net Server

An alternative for the IP-PM is to have 2 communication servers : one native-IP

Figure 3. SIP@Net Server in a SIP@Net iPVN Network

The SIP@Net Server offers the following functionality :

Maximum of 5000 SIP ports for extensions, trunks and applications

In general installations like CPU3000 based iS3010/3030/3050 or iS3070 /3090

Full SIP based

Full support of SIP IP-DECT Access Points and DECT handsets

Full Support of SIP based VoWLAN network and handsets

Support of ISDN and gateways

Full iSNet working facilities to iS3000 system/network

Runs on industrial Windows based server

2.2. SIP@Net SERVER - FAULT TOLERANT SOLUTION

When applying the "Marathon everRun” solution it is possible to install other

For details, see http://www.marathontechnologies.com/

See figure below.

CPU - IP-PM protocol, in case an IP-PM is projected.

Figure 4. Protocols used in the SIP@Net Server

The SIP@Net Server runs the following programs :

SIP@Net 4.2 (or higher)

Add-on 3-party conference

2.4. MEDIA SERVER

One Media Server per SIP@Net instance is sufficient.

One Media Server instance can handle up to 2048 channels.

One channel per call is needed for :

Three channels for 3 party handling in case of :

A SIP@Net Server can serve 5000 SIP-endpoints : extensions, trunks, media

2.4.2. Media Server for Progress Tones

at : Austria de : Germany za : South Africa

2.4.3. Media Server for Break-in

2.4.4. Media Server for Announcements

2.4.5. Media Server for Music On Hold

2.4.7. G.729 Support by Media Server

By default all codecs are enabled in order (highest priority first):

“G.711 ALaw --> G.711 µLaw --> G.729”.

G729 Voice-Activity-Detection (VAD) can be configured to 1=on (default) or 0=off.

2.4.8. Non-Peer-to-Peer Media for SIP Trunk

In previous SIP@Net releases, all media is Peer-to-Peer (P2P).

Parameter Default value Allowed values

For parameter “Internal frame time” the following applies :