150 PERSI - Personal Identification

The AMO PERSI is used to administer personal data. The cross-reference to the person is invariably established via the station number.
Names
Each station number can be assigned either one or several (any number of) names; the name entered first will be displayed on DIGITE displays. All other names are used for ETD functions. The name can also be made up of 2 parts:
1.
Surname, simple or composite, e.g. Hr. Meier, Fr. Dr. Huber
2.
Name, and additional information, e.g. Anna, Dept. A3
The characters of the "surname" are separated from those of the "name" by means of a "*".
Display at Optiset/OptiPoint:
The DIGITE has a 24-character display. The type of display, e.g. station number plus name or name only is defined by means of AMO ZAND, TYPE=ALLDATA, DISPMODE-MODE1 to MODE5 (see Examples). There is no verification of the last name. The number of blanks between the station number and the name is exactly one.
When configuring or changing a network wide subscriber name ( parameter NAME, NEWNAME ), which doesn't correspond to a person but e.g. to the geographical location ( "ENTRANCE ADMIN.BLDG5" ) of a terminal the display of the subscriber name can be incorrect, if a blank occurs in the subscriber name, and DISPMODE=MODE5 ( see AMO ZAND ) is activated. The resaon for this is, that blanks are used to sparate family names and first names,and errors can occur due to the network protocol, when the subscriber name is transfered. This can be avoided, if blanks are replaced by special characters e.g. "-", "." or "," or "_" in the geographical identification of the terminal.
Examples
Input: Dr. v. Ritter*Martin
Display
MODE1: 32857 DR. V. RITTER M.
MODE2: 32857
MODE3: DR. V. RITTER MARTIN
MODE4: DR. V. RITTER
MODE5: # DR. V. RITTER
Display at OpenStage:
The OpenStage devices have different display sizes. The type of the display is controlled internally in OpenStage devices. The ZAND parameter DISPMODE is not evaluated at OpenStage devices.
The data configured via AMO-PERSI are transferred to the OpenStage device without any modification. If the name display field is too short, the OpenStage device shortens the name itself (no specification by the system).
Emails
For mapping between ONS/DESK number and Unify Video accounts, the email address of the users are used. Therefore, AMO PERSI is used to configure an email address for a station.
For each station, only one email address can be assigned and it must be unique in the system.
The PERSI rules for email address configuration are listed below:
•
All characters must be convert to lower case.
•
According to section 4.5.3 of RFC 5321, the maximum length of an email address is 320 byte (64 octets for the user name, 1 octet for the '@' and 255 octets for the domain). However, in order to align SIP URI and EMAIL concepts in RMX DB, the maximum length of an email address is 127 byte (63 octets for the user name, 1 octet for the '@' and 63 octets for the domain).
•
The following characters are allowed:
! # $ % & ' * + - / = ? ^ _ ` { | ?
•
The domain name must start with a letter and end with letter or a digit. Inside the domain name, there can be letter, digits, hyphens and dot. For more information, see section 3.5 of RFC 1034.
•
The NGTC solution allows only basic Latin characters (Aa Bb Cc Dd Ee Ff Gg Hh Ii Jj Kk Ll Mm Nn Oo Pp Qq Rr Ss Tt Uu Vv Ww Xx Yy Zz) inside the email addresses associated with users or administrators. Variations of the allowed characters set (e.g. ä) are not supported.
More precisely, email addresses should:
•
Contain basic Latin characters, numbers and the following special characters for the local part of the address:
_ * + - $ ? ^ { ! # % & ' / = ` | } ~ .
•
The local part cannot start or end with a period (.).
•
There should be only one @ inside the email address.
•
The server and domain parts can only consist of Latin characters, numbers or hyphens ( - ).
•
The domain part (.com) should include at least 2 items. There can be more than one domain part.
Examples of unusual, but valid email addresses:
^local.2@server8.domain-1.domain-2
*_+-$?^{!#%&'/=`|}.~@e.co
a@a.co
 
Organizational unit
Each name can be assigned an organizational unit (for ETD functions).
If a station number has not been assigned a name, no org. unit can be assigned.
If station number has been assigned several names, but not everyone of these names has been assigned an organizational unit, the organizational unit which was assigned last is automatically assigned to the remaining names.
Personal identification number (PIN)
The PIN is used for personal identification of a person to the system. Each station number can be assigned any number of PINs. The length of a particular PIN type is determined centrally. The PIN length may or may not be the same for the types of PINs described above. Each PIN (execpt COSXCD) must be unique throughout the system.
The same class of service changeover code (COSXCD) can be assigned to any number of stations. When a COSXCD that was previously assigned to a station is configured, the system outputs advisory message H38 to notify the user of this fact, and the command is still executed. If the user does not want the COSXCD to be assigned to multiple stations, he can delete the COSXCD for the station with DEL-PERSI:TYPE=PIN,PIN=number,STNO=number ;
In the case of PINC, it must also be determined at which position on the magnetic/chip card the PINC begins. (PIN pointer)
A ’Class of PIN’ (COPIN) must be introduced for each type of PIN to be able to implement the PIN display feature and to be able to differentiate between the various types of PINs.
The COPIN defines the characteristics and functions of individual PIN applications such as the type of PIN (PINM, PINC, COSXCD, PCODE etc.), PIN length, PIN texts and various flags used to disable or enable specific functions.
The "class of PIN" (COPIN) is used for each PIN type in order to implement the PIN display feature and in order to distinguish between the different PIN types.
The characteristics of the COPINs (1 through 15) are summarized in the so-called COPIN table in which the following default values are assigned to the type of PIN:
 
PINTYPE
(=COPIN)
 
PIN
COTYPE
PIN Meaning of a type of PIN
1
=
PIN1
MOBILE
Manual identification
2
=
PIN2
BUSLONG
Identification of business calls (remains active until manual deletion or timeout).
3
=
PIN3
BUSSHRT
Identification of business calls
4
=
PIN4
PRIVSHRT
Identification of private calls
5
=
PIN5
PCODE
Identification of a project for a call (project code = PCODE).
6
=
PINC
PINCARD
Identification by means of a magnetic/chip card which is inserted into the card reader of the terminal.
7
=
COSXCD
COSXCD
Identification of users which are authorized to activate COS changeover from the terminal.
8
=
SI
SI
Pin for service id
9
=
CDRAC
PCODE
CDR account code
10
=
PIN10
PCODE
PIN for dialing pattern check
11
=
PIN11
MOBILE
Manual identification
12
=
PIN12
MOBILE
Manual identification
13
=
PIN13
MOBILE
Manual identification
14
=
PIN14
MOBILE
Manual identification
15
=
PIN15
MOBILE
Manual identification
COPIN 15 is used for ONS groups. Therefore this COPIN is treated in a special way in CDR: The PIN number is not showing up in the CDR records.
The COPIN table allows the administration of all entries execpt the timer administration (AMO CTIME) using the AMO PERSI. Please note that the type of PIN can only be changed for COPINs 1-5,10-15 and that for the PIN card only COPIN 6 is used, COS changeover only COPIN 7 is used whereas for service id only COPIN 8 and CDR account code only COPIN 9 is used.
Each PIN has at least one COPIN for identification of the PIN type.
However, a PIN may also be valid for several PIN types. Such a PIN is assigned more than one COPIN.
For data protection reasons, manually keyed-in PINs are not displayed, instead a wildcard ’*’ is displayed for each character.
To allow the user to check whether he has entered the PIN or PCODE correctly, he can use the parameter PINDISP or parameter DISPPIN (TYPE=COPIN) which allows each type of PIN to be administered separately.
The parameter COSXCOS2 is used for COS changeover to COS2 with or without a COSXCD.
a)
Company code (COCO)
If several companies share a system, a 1- to 4-digit COCO on the magnetic/chip card indicates the card owner’s company code. As a result of this, several companies can be assigned the same PIN.
The company code pointer (CPOINT) marks the position at which the COCO begins on the ID card. This position may coincide with that of the PINC.
The COCO is assigned for each ITR group since the STNs are categorized into ITR groups if several companies share the same system.
b)
STNO-Code calling number conversion for code calling system, multiple (CCMS).
Some CCMSs have a repertory of code calling numbers which differs from the system’s station number plan. Since individual persons are paged via their station numbers, it is necessary to convert the STNOs into CCMS code calling numbers. During conversion, several station numbers may be assigned the same code calling number, but not vice-versa.
A maximum of 2 CCMSs can be connected to the system. This is why, during STNO-Code calling number conversion the relevant CCMS is identified by its code (or else by the DPLN group it belongs to).
The size of the memories to be used for PERSI data (NAME, ORG, PIN) is defined by means of AMO DIMSU. For each ’STNO-Code calling number’ conversion one table is available for each CCMS (1000 entries).
This AMO is non-resident and is only called down by the AM.
c)
project code (PCODE)
The PCODE is used to assign call carges to specific projects. For this reason, it is not assigned to any of the users.
The PCODE is activated with the same code as the PIN.
The PCODE remains active only for the duration of a call.
The PCODE can also be entered while a PIN is active (mobile STN). In this case, the data and the classes of service of the PIN’s home station are valid.
d)
service id (SI)
The service id is used to sign off resp. sign on a station.
The service id is activated with the sign off resp. sign on code.
e)
CDR account code (CDRAC)
The CDR account code is used as account code for incoming and outgoing call, which are listed in the call charge data output.
f)
modulo check algorithm
The validity check on a PIN or porject code cannot only be performed by comparing the entry in the PIN/Project code table created by the PERSI AMO but also using a module check algorithm. It is possible to define 3 modulo check algorithms in the system (action CHANGE TYPE=MODULO), see also FUE "Verfiying the PIN/PCODE".
With which of the 3 algorithms the check is to be carried out can be specified individually for each type of PIN.
OpenScape 4000 V10, Volume 1: AMO Descriptions, Service Documentation, Issue 5, ID: P31003H31A0S107057620
 © 09/2025 Mitel Networks Corporation. -  All rights reserved.
 Mitel and the Mitel logo are trademarks of Mitel Networks Corporation. Unify and associated marks are trademarks of Unify Software and Solutions GmbH&Co. KG. All other trademarks herein are the property of their respective owners.