5.21.2.4. NNO Determination 
A call in OpenScape 4000 is assigned a source and a destination node
number (NNO/DNNO). NNOs are used by number formatting AMOs such as KNFOR,
KNMAT, KNDEF etc.
For outgoing calls, the destination NNO is taken from RICHT and also
LDAT (should DNNO be entered).
For incoming calls, the source NNO is determined differently depending
on device type:
- For Central Office TDCSU device types, the node number is taken from NNO in TDCSU.
However
if COT DCCO is set, reverse lookup is used.
Central Office device type examples are S0COD, S1COD, S2COD, HG3550CO...
- For TIE devices, the node number is taken from NNO in TDCSU when COT DFNN is set.
If COT DFNN is not set, reverse lookup is used unless a NNO is received in protocol messaging (e.g. when connected to another 4K).HINT: If partner 4K node has COT LWNC set, then no NNO is sent.TIE device type examples are S0CONN, S2CONN, HG3550IP...
To clarify, the behaviour is different (reversed) for CO and TIE trunks, but COT DFNN/DCCO
can be used to toggle the default behaviour.
Reverse look-up uses the incoming Calling Party Number to derive the destination NNO
by
evaluating the WABE/LCR process and establishing if there is an outgoing route leading
to this
number. If a route is found, the node number (DNNO) will be taken from that outgoing
LCR ROUTE
(RICHT/LDAT). If no LDPLN match is found, then the node number is taken from TDCSU.
To be
explicit, this means the same NNO is assigned for an incoming call that would be used
for an
outgoing call dialling the same number. This behaviour is often needed by systems
with
multiple KNDEF entries.
HINT: Any DNNO configured in LDAT will be used instead of RICHT DNNO.
Application examples:
- To derive different Node values for multiple E164 numbers on an IP Trunk
- To differentiate number modification for systems with KNDEF entries across multiple country codes.
- Numbers from a foreign system that might use multiple different area codes.
- Open numbering to 3rd party network where partner system cannot insert TIE codes with calling number.
- UC deflect binding where the default KNDEF node is different to the E164 number needed
The flexibility of the 'reverse look-up' feature is also apparent when multiple systems
are
networked with open numbering to one trunk. If the calling numbers of each system
can be
evaluated, it is then possible to define different node numbers for each system. This
then
means KNMAT can be used to modify different prefixes to the calling parties i.e. system
1 with
123, system 2 with 134 etc i.e. KNMAT can make a modification for each node number
that was
derived from LCR, even though the calls arrived on the same physical trunk.
Example Processing for Reverse Look-Up:
(HINT, these number modification HISTA messages are produced according to DIAGS
configuration. Check AMO descriptions for DIAGS (CP2) switches for how to activate).
- Explicit number, 22233344412888 -ISDN/inter, received in incoming Setup via TDCSU with NNO=1-1-699;
- Conversion to implicit follows: 00022233344412888
- A route for this digit pattern is not found, reverse look up fails and the node ID
from
TDCSU is
used.
F4066 M8 N8675 NO ACT BPA CP ADVISORY 18-06-13 22:24:55 ALARM CLASS:CENTRAL:023 FORMAT:49 TEST: IN IN CPB, CALLING ORIGIN: 1- 1- 699 DESTIN: 1- 1- 781 BITS:0123456789012345678 22233344412888 ISDN inter 1- 1- 699 --012-----D-------- 00022233344412888 ISDN unknown U-012-----DI-------
- Outgoing route is added, the incoming CLI will now be found in
LCR
ADD-RICHT:MODE=LRTENEW,LRTE=222,NAME="REVERSELOOKUP2", TGRP=69,DNNO=1-1-222; ADD-LDPLN:LCRCONF=LCRPATT,DIPLNUM=0,LDP="0"-"W"-"00"-"222"-"Z", LROUTE=222,LAUTH=1;
- Source node (ORIGIN) becomes
1-1-222:
F4066 M8 N8678 NO ACT BPA CP ADVISORY 18-06-13 22:29:43 ALARM CLASS:CENTRAL:023 FORMAT:49 TEST: IN IN CPB, CALLING ORIGIN: 1- 1- 222 DESTIN: 1- 1- 781 BITS:0123456789012345678 22233344412888 ISDN inter 1- 1- 222 --012-----D-------- 00022233344412888 ISDN unknown U-012-----DI-------