Solution as in the scenario depicted by Figure 102:

User A calls user B by dialling 8 702 #B.

KNMAT (which is active for all call set-ups) adds the routing digits of the calling node (i.e. 700 for level 0 and 7 for level1) and 7700 #A is sent to node 702 and is displayed at B.

Node 702 returns the digits 702 #B to node 1, where DGTPR in TDCSU adds 8 (i.e. the DX network area code) to the front of the string. This is displayed at user A. This is required because the DX does not send a node code OpenScape 4000 can use and so KNMAT cannot prefix the incoming CLI.

If user B has CF to user C, then the diversion may take place, if it is performed by the DX. However, the divert destination that is returned to node 1 is 703 #C.

Even if the diversion has successfully taken place, a problem arises in this situation if the OpenScape 4000 attempts a callback or circuit optimization as it does not have the correct routing information of the diverted to party and therefore callback requests and optimization will fail.

Fig. 1 Example: The calling party dials 8-702-4711. Ext.4711 is forwarded to 8-703-4712

The ISDX 702 send's the redirection party number as 7034712, without the private network ac-cess code. OpenScape 4000 701 can not evaluate the digits correctly and the call attempt fails,or even worse end's at a wrong destination.

Since the ISDX software can not be changed the OpenScape 4000 has to prefix the redirection party num-ber with the private access code before presenting it to digit analysis.

The private network access code is customer specific. In order to allow for enough flexibilty it was decided to administer the access code on a B-channel group basis.

Only ISDN trunks are affected by the feature.