ENTP0400P13TEUS
ENTP0400P13TEUS
ENTP0400P13TEUS
R9.1 Newness
OBJECTIVE
The aim of the New Generation Platform(1) is to cover the hardware and
software obsolescence and to provide
A converged solution for both Common and Crystal hardware platforms
New IP Gateway functionalities, capacities and performances
30 onboard compressors, permanent binaries authentication
1) NGP is available as of R9.1 TR+1b (i1.605.14 available on BPWS since 26 feb 2010)
3) This board mainly covers hardware obsolescence. It can only be connected to a GD3
Remark:
The NGP boards handle Linux Kernel 2.6
4) An order realized with Actis 14.1.1 will offer GD2/GA2/MEX and INTIP2
PCS mode
For XL configuration, instead of Appliance Sever use, the CS-2 can be used
1) V24 port can be used for Remote reset signal coming from a RMA Box
2) If the second Ethernet port is not used, it must not be connected to the network
When a set forwarded (on a SIP voicemail or an external number via SIP
Trunking) is called, this feature allows to add an History-Info header in the
INVITE message for the SIP External gateways/Voice mails (allowing to
notify the initial called party)
A SIP MESSAGE can be sent to the SEPLOS device in order to inform the user
about the CS settings
Forwarding activation, DND, Hunting group belonging
Compatible devices: Thomson ST2022/ST2030 and 4008/18 EE in SIP mode
As of release 9.1 the user part is sent in the FROM and in the Contact
fields
The SIP sets (SEPLOS & Device) and the external gateways can be activated
on an active PCS
Only equipments supporting Primary and Backup SIP server can benefit from this feature
1) Restriction in ABC-F network: all nodes have to use R9.1 version at minimum
The OmniTouch 4135 IP is a conference phone based on SIP providing wideband sound (200-7000 Hz)
Features: Audio
5-way conferences
Call recording on SD card up to 2 GB
G711, G729ab
DTMF: In-band / SIP INFO, DTMF RFC 2833
Features: Directory
Phone book: 1,000 entries per profile
Export/import of directory and configuration
Call list
User profile: 4 profiles (password protected)
LDAP Directory access
Features: Infrastructure
DHCP, static IP, SIP SEPLOS
One SIP account
Redundancy : Spatial, PCS, via external SIP proxy
802.1p and VLAN tagging, 802.1x
NTP and SNTP
Power over Ethernet IEEE 802.3af
Transformer: 100240 V AC/13.5 V DC
Expansion microphone port and aux port
Software upgrade: TFTP / HTTP/HTTPS
Integrated web server
Web-based remote configuration & diagnostics log files and SIP traces
In the previous releases, theIBS domains could only support identity and
Authentication modes
The system accepts emission/reception of DECT communications from DECT terminals only
verifying their IPUI-N/IPUI-0
An authentication key (AC(1) key) has to be given to the system and terminals
Thanks to a specific algorithm, each device is going to derivate a new (called UAK(2)) key from the AC
one
The OXE generates a random key and codes it with the UAK key, this new key is called:
DCK(3),
Then it provides the random key to the terminal
The terminal calculates itself the DCK from the received random key et sends it to the OXE
The OXE checks the coherency of the keys if they correspond, the terminal is
authenticated
The specificity of this RSI is to send Route-End only when call is answered
In case of ringing overflow on RSI, Reroute Request will be sent instead of a new
Route Request
Configuration
/Applications/CCD/RSI
Max Number of Reroute Request : 3 (up to 1000)
The maximum number of RSI Reroute Request is displayed in the rsi tool
When the PCS is inactive the connection is treated like with a stand-by CPU
From the release I1 the user account password management in OXE takes JITC
conformance as a minimum level of security
The SSL support for LOW encryption ciphers is disabled in order to increase
the security level because messages encrypted with low encryption ciphers
are easy to decrypt
The key length must be equal or larger than 128 bits
With the previous releases, the DHS3 process logs during RUNTEL are stored in
DHS3-init logs
Logs are kept for the for three last RUNTEL startup
At each restart of the OXE the oldest is lost and overwritten by the new one
The log files are stored in /tmpd folder
From release R9.1 the last 10 RUNTELs DHS3-init logs will be stored
There are two real-time processes, btracer and blackbox, used to export
the information linked with the Monitel telephone application process
From release R9.1 the last 10 reboots btracer and blackbox logs will be
stored
The infocollect tool is used to collect all the logs from the site in case of any
problem
Currently it copies only 3 logs of DHS3-init logs
From release 9.1 the latest 10 logs from main and standby will be copied by
infocollect tool(1)
Supervision Enhancement
A new option allows to cancel the direct call by supervision key
Default IP Domain
Calling Id:
Central
01273380000
Office USA
CLI:02088529000
IP Domain 1
IP Domain 2
FORWARDED
CLI: 01273380000
Private to public overflow
France
CAC=0 CAC=0
GD 2
UK
CLI: 01392 875100 GD 1
Unavailable route
The aim of this feature is to respond to a specific case: a CS owns two GDs but CAC of links between GDs and CS is set to 0, meaning
than no call can be done from GD #1 to GD #2 directly.
Instead, private to public overflow feature is used.
Before R9.1 in a such situation, if a set of GD #2 is immediately forwarded on an external number using a GD #2 trunk group, call from
GD #1 to this set actually fails, because call forward is managed directly from caller set (on GD #1) and private to public overflow does
not allow to seize distant trunk group (on GD #2).
In R9.1, the call forwarding works fine.
Multi-Country feature can affect external call forward. If forwarded sets are not located in the same country then the call terminates,
calling number presented on outgoing trunk group must take care of this specific case. To provide a relevant calling number two
possibilities are offered:
Building an International calling number from caller number using parameters of the country of forwarded set.
Ignore the configuration and provide forwarded sets number.
Due to high complexity of first solution, in case of multi-county external forward, number of forwarded sets will be provided as calling
number. This feature works only with R2 and ISDN TGs.
1) The terminal sends to the switch some information via a LLDP/LLDP_MED message. It then starts a one second timer. If the set
does not receive anything from the switch, it considers that the adjacent LAN Switch does not support VLAN Assignment, and the
terminal continues its initialization with a normal startup
MIPT set in Branch Office has to be able to reach a PCS in case of WAN
failure
Step1 (OXE R9.0): solution requiring a mandatory local DHCP server
Step2 (OXE R9.1): solution with IP addresses in flash memory of the MIPT
PRS on MIPT
With new implementation: MIPT display will be having name on two lines
(30 characters in UTF-8) instead of one
MobiCall (MC) is an alarm system which is connected to OXE through an ABC-F TDM trunk group (T1 or T2). When an alarm occurs MC
calls an MIPT set (a nurse or other people). In the SET-UP message MC fills the calling name with the 16 first characters of the alarm
text. For example "Patient. When the MIPT answers MC sends 16 further characters as name in FACILITY message.
For example "Room No12345".
With new implementation MIPT display will be having name on 2 lines (30 characters) instead of one.
MC will send 30 characters in UTF8 name. When ringing, instead of 3 lines with Name, number and "Calling", display would be Name on
two lines (15 characters on each line) and "Calling" on 3rd line. When MIPT answers call, display would be Name on two lines and
"Conversation" + timer" on 3rd line.
A new trunk group data will be added in given below path.
Trunk Group -> Special Services + Alarm Call.
+ Nothing
+ Urgent Broadcasting
+ Timed Call Release.
Default value for the parameter Special Services is Nothing.
The condition to modify display on MIPT for an Alarm Call will be MIPT Set + trunk group data. When MIPT answers the call, it directly
goes to DTMF mode. When MIPT dials the digits in DTMF mode, display of digits on MIPT screen can be managed through parameter
given in below path.
System -> Other System Parameter + No. Digits displayed on the Sets (1 to 16).
Because 4035/4037 sets are in phase out status, there is no more hard-phone
for attendants
A solution based on 4068 (Fast Ethernet/Extended Edition) allows to use this set
as an attendant
The IP Touch Security Solution offered the possibility to secure the signaling
and voice over IP in Stand-Alone configuration at its first launching
Then, this Thalès solution has been chosen to respond to some customers who
wanted a strong and reliable signaling link against DOS(3) attacks for remote IP
Media Gateways (Common hardware). The Thalès VPN Client is embedded on
the GD(4) and only encrypts the signaling
This GD is then called MGSec
The release 9.1 introduces the possibility to secure a MG without Thalès boxes
(NGP Crystal & Common hardware) for Signaling & Voice. The Thalès VPN Client
is embedded on both platforms boards
1) SSM: Server Security Module. In case of Call Server duplication, A SSM can be used per CPU
2) MSM: Media Security Module. According to the box generation [MSM or MSM-RM (Rack Mounted)] and the topology, a MSM can
protect a GD (or GD + GA) or an INTIPA/B (or two INTPA/B)
3) Deny Of Service
A NGP board always controls the authenticity of the binary even if the security
mode is Bypass(1)
The binaries are signed with the Alcatel-Lucent private key. The boards use the
Alcatel-Lucent public key stored in their flash to authenticate the files. This
authentication control ensures that the binary has been produced by Alcatel-Lucent
The integrity control uses the SHA-1 HMAC method(2) for NGP boards
The new NGP hardware capabilities offer the possibility to handle the security
functionalities without any MSM(3). The security level of this solution is the
following one:
Terminology
SoftMSM: NGP Media Gateway(6) running the embedded Thalès VPN client and
the Thalès SRTP library
1) In the previous release the GD authenticated its binary only if the security feature was activated (Security=Protect in the
lanpbx.cfg file). The crystal INTIP board did not support this authentication
2) The MD5 method is still used for classical Common hardware (GD-GD2)
3) A SSM is still required to protect the Call Server. The MSM are not used to protect the NGP Media Gateways
Remark:
A MSM remains mandatory to protect a PCS in order to secure the communications handled by the PCS
4) Advanced Encryption Standard (AES) cipher Algorithm - in Cipher Block Chaining (CBC) Mode
The packet authentication uses the HMAC-SHA-1 method
5) The voice encryption is realized with the AES-CM cipher [Advanced Encryption Standard (AES) cipher Algorithm - in Counter Mode
(CM)]
Problem with previous releases features like « Free Seating »and Contact center
frequently modify the database(1)
If the Stand-by CPU is unreachable (loss of the IPLINK for maintenance reasons, IP
network failure
), the consistency of the database is no more ensured
Differences between the 2 databases raise many incidents and may give issues at
the next CPU switchovers
A manual mastercopy must be done
The main CPU stores the mao commands when stand-by is no more
available(2). This data is transmitted to the stand-by CPU as soon as the
inter-CPU IPLINK is back to normal in order to avoid a mastercopy
2) The second CPU has at least once to be connected and initialized as stand-by CPU to activate the feature
Only CS-2, Appliance Server and Blade server are compatible with this feature(1)
If the Stand-by CPU is still unavailable, the main CPU IPLINK ends the storage
of the MAO commands after a timer (max 2 hours) a MASTERCOPY will be
required !
Configuration
/IP/Duplication parameters
Updates storage time limit: 120(2)
If the Stand-by CPU is available before the main IPLINK deletes stored MAO
commands, the main IPLINK forwards the MAO commands to the Stand-by
IPLINK in order to update the Stand-by CPUs database
2) Value in minutes. If this timer is equal to 0, there is not any MAO command storage
Information about the storage of MAO commands is saved in the log file of the
main IPLINK (/var/log/iplink.log)
The file iplink.log provides some information about the storage of MAO messages
On main CPU
(1)xa000000> more iplink.log
(29/09/09 09:29:41) DUPLI: local CPU connected to the reference media gateway
(29/09/09 11:05:49) DlLink: Save MAO msg because Sdby CPU is not available
(29/09/09 11:40:22) DUPLI: local CPU connected to the reference media gateway
(29/09/09 11:47:23) DUPLI: MAO is ON on the remote CPU
(29/09/09 11:47:23) DlLink: Ready to send 2 MAO msg saved when standby CPU was not available
(29/09/09 11:47:23) DUPLI: Database updated on the remote CPU
(29/09/09 11:52:35) DUPLI: MAO is ON on the remote CPU
On stand by CPU
(29/09/09 11:40:38) MAIN: iplink killed by signal 15
(29/09/09 11:47:37) DUPLI: MAO is ON on the local CPU
(29/09/09 11:47:37) DUPLI: expecting 2 MAO msg
(29/09/09 11:47:38) DUPLI: Database updated on the local CPU
(29/09/09 11:47:44) SOCKET: socket is closed
(29/09/09 11:47:44) SOCKET: socket is suspended
(29/09/09 11:47:44) MAIN: iplink killed by signal 15
(29/09/09 11:52:35) DUPLI: MAO is ON on the local CPU
The maohist command allow also to check if the mao information are taken into
account by the CPU updated
Save MAO msg because Sdby CPU is not available occurs on main CPU only. The IP link between both CPU is broken. The database
on main CPU has been modified and the first MAO message has been stored by main IPLINK waiting for standby CPU comes back.
MAO is ON on the remote CPU occurs on main CPU only. Main IPLINK received the MAO_IS_ON message from standby IPLINK. That
means that standby CPU is ready to process MAO messages stored by main CPU.
MAO is ON on the local CPU occurs on standby CPU only. Standby IPLINK received the MAO_IS_ON_ACK message from main IPLINK.
That means that main CPU knows that standby CPU is ready to process MAO messages. So, main IPLINK starts sending stored MAO
messages.
Stop saving MAO msg after X minutes occurs on main CPU only. Main IPLINK stopped storing MAO messages after X minutes
whereas standby CPU was not available. Stored MAO messages are deleted. Standby CPU MUST be updated using the master copy
command.
It happens on main CPU when main IPLINK deletes stored MAO messages. It
may happen when the time limit for storage is reached, or in a double
main case when both of the CPUs have stored MAO commands
When this incident is raised, the OXE system administrator MUST proceed to
a mastercopy on standby CPU
When both CPUs are main after a network failure, they decide which one
must reset. If the CPU that resets, has stored MAO messages, this incident is
raised
On an ABC-F IP trunk group all the calls were released in case of Call Server
switchover
R9.1 Improvement
In set-up phase:
Communications are released except the incoming external communications which
are routed to the relevant Entity (e.g. an attendant)
Note:
As in Release 9.0, the IP ABC-F communications can not be encrypted
From R9.0, the Telnet service has been disabled by default on boards but can
be activated. Here follows the activation methods available from R9.1
GD-2/GA-2 et GD-3/GA-3
Via V24 or from the CS with the commande cpl_online
In the mgconfig, activate the Telnet server (always opened, or opened with a timer)
Remark:
The telnet_al command has to be used for all the boards in order to initialize properly the Telnet session
Network compatibilities
The cohabitation with release R5.1 < to < 7.x is only allowed during migration
process