.rs .\" Troff code generated by TPS Convert from ITU Original Files .\" Not Copyright ( c) 1991 .\" .\" Assumes tbl, eqn, MS macros, and lots of luck. .TA 1c 2c 3c 4c 5c 6c 7c 8c .ds CH .ds CF .EQ delim @@ .EN .nr LL 40.5P .nr ll 40.5P .nr HM 3P .nr FM 6P .nr PO 4P .nr PD 9p .po 4P .rs \v | 5i' .sp 2P .LP \fBRecommendation\ I.333\fR .RT .sp 2P .sp 1P .ce 1000 \fBTERMINAL\ SELECTION\ IN\ ISDN\fR .EF '% Fascicle\ III.8\ \(em\ Rec.\ I.333'' .OF '''Fascicle\ III.8\ \(em\ Rec.\ I.333 %' .ce 0 .sp 1P .ce 1000 \fI(Melbourne, 1988)\fR .sp 9p .RT .ce 0 .sp 1P .LP \fB1\fR \fBIntroduction\fR .sp 1P .RT .PP This Recommendation defines \*Qterminal selection\*U as the procedures carried out between a terminating ISDN exchange and ISDN terminal equipment situated behind an ISDN interface leading to customer premises whereby terminal response equivalent to answer or rejection is solicited. The procedures apply to both point\(hyto\(hypoint and point\(hyto\(hymultipoint terminal operations. .PP Note that in case of an existing terminal (TE2) connected via a terminal adaptor (TA) to an ISDN access, the combination of TA and TE2 is seen as to provide the same functionality as a TE1. As there should be no modifications to the existing terminal, the functions described are provided by the terminal adaptor. .PP \fINote\fR \ \(em\ In the context of this Recommendation \*Qterminal\*U is an abstract term and does not constrain the implementation of physical terminals which may consist of one or more logical terminals. .RT .sp 1P .LP 1.1 \fITerminal selection responsibilities\fR .sp 9p .RT .PP The network responsibility is to deliver a call to the interface identified by the called number using connection types consistent with the service requested by the calling party. It is the responsibility of the called party to arrange the terminals on the interface so that incoming calls properly originated are accepted only by the appropriate terminal(s). The network may provide additional functions to aid in the completion of calls from dedicated networks. The network may provide additional services to ensure that calls are completed only to terminals consistent with information provided by the caller. It is the responsibility of the terminal manufacturer and/or service provider to provide terminals that use the terminal selection data in a way that is consistent with the intended application of the terminal, (e.g.\ for telematic terminals according to Recommendation\ T.90). .PP The calling party agrees, when placing a call, to accept the terminating capabilities provided by the called party. The terminating exchange has a cooperative role with the terminal in establishing an information transfer which lends itself to the required terminal selection needs for a given interface. .RT .sp 1P .LP 1.2 \fIIdentification requirements\fR .sp 9p .RT .PP An ISDN number identifies any of the interfaces at reference point S (Recommendation\ I.330, \(sc\ 2.1). Additional identifiers or terminal selection functions are therefore needed in those cases where the number is insufficient to make needed distinctions among terminals. This Recommendation addresses the general principles to be applied in identifying: .RT .LP 1) specific individual terminals or .LP 2) groups of terminals among which no further distinction is required by the terminating user. .LP Specific sequences in which identifying information is applied are not specified. .sp 1P .LP 1.3 \fIGeneral operations\fR .sp 9p .RT .PP While specific selection sequences for the application of terminal identifiers are not required, the ISDN number is a fundamental discriminator. The whole network \(em\ including the terminating exchange\ \(em relies heavily on this resource. The bearer capability must also be given a high status since its transfer across the interface is mandatory with every call request. Other information potentially useful in the selection process is given in \(sc\ 4. An originator of a call is generally not required to provide any of the other information in every call. Exceptions for telematic terminals are listed in Recommendation\ T.90. .bp .PP If terminal selection is to be successful in establishing a connection between the calling and the called terminal in a prescribed manner, the calling terminal should conform to the reasonable expectations of the called subscriber's terminal arrangement. A calling subscriber who does not conform to the expectations of the called subscriber's terminal arrangement is inviting an irregularity. The terminating subscriber has a corresponding obligation to provide a means for needed discrimination among terminals. It should be noted that information expected at a called subscriber's terminal configuration may not, in all cases, be provided by the calling subscriber, (for example, interworking with a non\(hyISDN). .PP The point\(hyto\(hymultipoint operation tends to be emphasized in subsequent text because distinctions in this mode of operation require some terminal selection functions. Nevertheless, the treatment of both point\(hyto\(hypoint and point\(hyto\(hymultipoint selection procedures are considered appropriate for this Recommendation. The terminal selection stage is said to be completed when an individual terminal reacts and is awarded the call. In the case of NT2, the call award need not come as a direct result of the point\(hyto\(hypoint procedure but may come later from a terminal attached to the NT2. .PP The details regarding the processing of this information by the terminating exchange and the sequence used in offering this information to the user\(hynetwork interface may be a matter of formal agreement between the subscriber and the Administration at the time of service provisioning. The call set\(hyup and terminal selection procedures in ISDN require that the terminating exchange and the terminals play cooperative roles. .RT .sp 2P .LP \fB2\fR \fBObjective\fR .sp 1P .RT .PP 2.1\fI\fR The primary objective of this Recommendation is to provide overall principles on terminal selection in ISDN. This Recommendation therefore provides a framework within which Administrations may choose appropriate terminal selection procedures, to suit their own operating environment and applications. .sp 9p .RT .PP 2.2 The guidelines contained in the appendices do not represent requirements on terminals for terminal selection functionality, but represent terminal selection techniques that are useful in appropriate circumstances. Possible choices are contained in appendices. However, other Recommendations, e.g.\ Recommendation\ T.90 have also to be taken into account. .sp 2P .LP \fB3\fR \fBScope\fR .sp 1P .RT .PP 3.1 It is recognized that call set\(hyup is an end\(hyto\(hyend process requiring appropriate switching, signalling and terminal functionality at both ends. However, the frame of reference used in this Recommendation is mainly the terminating ISDN exchange and the terminal configuration(s) served by that exchange. The originating exchange and the terminal configuration(s) served by that exchange are covered only if a specific request for a terminal function at the calling side, supporting the terminal selection procedure at the called side, is identified. .sp 9p .RT .PP 3.2 It is also recognized that calls originating from existing dedicated networks with limited addressing and signalling capabilities will not be able to avail themselves of the full range of terminal identification functions. This Recommendation therefore addresses the terminal selection for the following types of calls: .LP \(em calls within the ISDN: .LP i) selection based on network assisted capabilities (e.g.\ see Appendices\ II and\ III); .LP ii) selection based on end\(hyto\(hyend user capability (e.g.\ see Appendices\ I and\ II); .LP \(em calls from public dedicated networks to ISDN. .PP \fINote\fR \ \(em\ Calls from private networks to ISDN are not currently addressed in this Recommendation. .bp .PP 3.3 This Recommendation addresses terminal selection in ISDN for both basic and primary rate access. .sp 9p .RT .PP 3.4 Though selection of a specific terminal in a multipoint configuration in ISDN for maintenance and operation purposes may be a requirement, this Recommendation does not currently address this application. .PP 3.5 This Recommendation is related to and/or is compatible with the following Recommendations: .LP \(em Recommendations of the I.200\(hySeries on ISDN services; .LP \(em Recommendation I.330: ISDN numbering and addressing principles; .LP \(em Recommendation I.331 (E.164): Numbering plan for the ISDN era; .LP \(em Recommendations I.410, I.411, I.412: ISDN user\(hynetwork interfaces; .LP \(em Recommendation I.441 (Q.921): ISDN user\(hynetwork interfaces: layer 2 specifications; .LP \(em Recommendation I.451 (Q.931): ISDN user\(hynetwork interfaces: layer 3 specifications; .LP \(em Recommendations of the I.500\(hySeries defining interworking between various networks; .LP \(em Recommendation Q.932, Annex A: Generic procedures for the control of ISDN supplementary services \(em\ User service profiles and terminal identification; .LP \(em Recommendation T.90: Characteristics and protocols for terminals for telematic services in ISDN. .sp 2P .LP \fB4\fR \fBTerminal selection functions\fR .sp 1P .RT .PP 4.1 Any information which categorizes attributes of an incoming call may be used for the terminal selection process (some information given hereafter is service oriented and some is terminal oriented): .sp 9p .RT .LP 1) an ISDN number; .LP 2) bearer capability; .LP 3) other low layer functionality; .LP 4) higher layer functionality; .LP 5) direct dialling\(hyin (DDI) number, multiple subscriber number, or subaddress; .LP 6) ISDN/non\(hyISDN call source indicator; .LP 7) local exchange functionality. .PP In a point\(hyto\(hymultipoint configuration, call set\(hyup information from the terminating ISDN exchange to the terminal configuration is transferred via broadcast procedures. All active terminals receive attribute values and determine whether or not to respond. .PP In the case of more than one terminal supporting the same service, the supplementary service Multiple Subscriber Number (MSN) (Note\ 1) or Direct Dialling\(hyIn (DDI) (Note\ 2) may be used to identify a specific terminal. To support these services the terminal must be able to recognize its own identity based typically on a number of digits, which consist of the whole, or a part of the Subscriber Number (SN) in the ISDN numbering plan. Alternatively, \(sc\ 4.3 may apply. .PP This principle applies for both a homogeneous ISDN environment and for interworking cases with non\(hyISDN. In a homogeneous ISDN environment the subaddressing function (Note\ 3) may be used alternatively. However, it cannot be used in all cases of interworking. .PP \fINote\ 1\fR \ \(em\ Based on the use of distinct ISDN numbers, the multiple subscriber number supplementary service enables specific terminal(s), connected to the basic access in a point\(hyto\(hymultipoint configuration, to be indicated by the called party number. .PP \fINote\ 2\fR \ \(em\ Based on the use of distinct ISDN numbers, the direct dialling\(hyin supplementary service enables a user to establish a connection to another user or an ISPBX, or other private system without attendant intervention. .PP \fINote\ 3\fR \ \(em\ Based on an extension of the addressing capability beyond the E.164 (I.331) numbering plan, subaddressing enables the calling user to select a specific terminal at the called user's termination and/or to invoke a specific process in the called terminal at the called user's termination. .bp .RT .PP 4.2\fR The terminal selection function in \(sc 4.1 is currently supported by Recommendation\ Q.931 (I.451) call set\(hyup protocols, Q.932 and Q.921 as follows: .sp 9p .RT .LP 1) called party number information element; .LP 2) bearer capability information element; .LP 3) low layer compatibility information element; .LP 4) High Layer Compatibility (HLC) information element; .LP 5) called party number/subaddress information element; .LP 6) progress indicator information element; .LP 7) End point Identifier (EID) information element (see Q.932, Annex\ A); .LP 8) Terminal End point Identifier (TEI) (see Q.921, \(sc\ 3.3.4). .PP 4.3 It is recognized that a local procedure, between the ISDN exchange and terminal, may be provided to allow the exchange to assign a particular terminal with network parameters (e.g.\ logical terminal profile). This identification mechanism will assist the exchange in providing additional terminal selection or service features (see Appendix\ III). .sp 9p .RT .LP \fB5\fR \fBTerminal selection\fR .sp 1P .RT .sp 2P .LP \fI\fR 5.1 \fICalls within ISDN(s)\fR .sp 1P .RT .sp 1P .LP 5.1.1 \fITerminal selection functions\fR .sp 9p .RT .PP These are described in \(sc 4. .RT .sp 1P .LP 5.1.2 \fIProcessing of selection functions\fR .sp 9p .RT .PP In the terminating exchange, the called subscriber number and the bearer capability are checked. If any form of subscriber profile exists for the interface, it may also be consulted. .RT .LP a) For point\(hyto\(hypoint applications .LP Proceed to establish the connection according to subscriber requirements; for an NT2 transfer all appropriate information. .LP b) For point\(hyto\(hymultipoint applications (broadcast) .LP i) As information is broadcast from the terminating exchange to the terminal configuration, each active terminal receives the presented information to identify the requested service, as described in \(sc\ 4.1 .LP ii) Each active terminal which wishes to be awarded the call will inform the network. The network will award the call to the first terminal equipment which requests connection. .LP When supporting multiple types of terminals, e.g. telematic and telephone terminals, on a point\(hyto\(hymultipoint configuration, improper call handling will occur if inappropriate terminals request connection of the call. Appendices\ I, II and\ III provide possible solutions to these problems. e.g.\ solutions specifically aimed at telematic terminals are included in Appendix\ I. .PP The development of terminal configurations in addition to those described in the appendices which will operate successfully in specific circumstances (e.g.\ select a specific terminal from among several for services, supplementary services, maintenance operations,\ etc.) are for further study. Provision of guidance to terminal manufacturers, ISDN subscribers, and network operators about how terminals might respond in such circumstances, requires further study. .sp 1P .LP 5.1.3 \fITerminal differentiation\fR .sp 9p .RT .PP The terminating party is expected to arrange available terminals to facilitate access. Distinctions may be drawn, for example, by taking notice in a terminal of the presence or absence (not the content) of a subaddress (see also \(sc\ 4.2). Calls interworking from PSTN (bearer capability 3.1\ kHz audio), for example, could be accepted by terminals sensing no subaddress, while allowing more capable terminals to bid for calls with the same bearer capability and subaddress as well. .bp .RT .sp 1P .LP 5.2 \fICalls from PSTN to ISDN\fR .sp 9p .RT .PP A call originated in the PSTN, supported by conventional signalling prior to arrival at the ISDN interworking point, will belong to one of two indistinguishable call types, i.e.\ ordinary speech or voiceband data. At the interworking point the bearer capability \*Q3.1\ kHz audio\*U will be assigned to assure compatibility with these call types. A progress indicator is also applied to mark a non\(hyISDN call source. Some PSTN customers, however, will be served from ISDN\(hycapable exchanges and calls will be supported by common channel signalling for the entire connection. This affords some added opportunities to make distinctions. The extent to which this should be recommended is for further study. .PP Those cases where the bearer capability \*Q3.1 kHz audio\*U does not apply (such as digital data service based on digital PSTNs) require further study, based on Recommendation\ I.231, and Recommendation\ I.515. .RT .sp 1P .LP 5.3 \fICalls from PSPDN to ISDN\fR .sp 9p .RT .PP A call originated in the PSPDN will carry either a circuit or a packet bearer capability when presented to an ISDN terminal (case\ A or\ B according to Recommendation\ X.31). Terminal selection procedures in these cases are for further study. .RT .sp 1P .LP 5.4 \fICalls from CSPDN to ISDN\fR .sp 9p .RT .PP A call originated in the CSPDN will carry a circuit bearer capability and indicate the kind of bitrate adaption used when presented to an ISDN terminal configuration. If the CSPDN is used to offer a teleservice, e.g.\ Teletex in some countries, the interworking point may not be able to provide this information to ISDN. Therefore, a distinction between a circuit mode data call and a Teletex call may not be possible and again the only basic principle which allows individual distinction between terminals is the supplementary service multiple subscriber number. \v'1P' .RT .ce 1000 APPENDIX\ I .ce 0 .ce 1000 (to Recommendation I.333) .sp 9p .RT .ce 0 .ce 1000 \fBExamples of terminal selection for general purpose terminals .sp 1P .RT .ce 0 .LP I.1 \fIScope\fR .sp 1P .RT .PP The aim of this Appendix is to describe terminal selection functions for general purpose terminals which allow operation when multiple terminals supporting a variety of services (including telematic services) are in a point\(hyto\(hymultipoint configuration (S/T bus), and the full complement of terminal selection functions (including HLC information element) have to be invoked for successful terminal selection. .PP Terminals which comply with the clauses below do not impose any constraints on terminal configurations with respect to existing recommendations dealing with telematic services. .PP Application of the terminal selection guidelines contained in this Appendix is described in \(sc\ I.3. .RT .sp 1P .LP I.2 \fITerminal functions\fR .sp 9p .RT .PP To meet the requirements mentioned in the scope of this Appendix, the following functions shall be provided by terminals connected to an ISDN. The functions are grouped into those which shall be provided as a minimum for offering an adequate quality of service and into those which may be implemented additionally. .PP \fINote\fR \ \(em\ The processing of information at the called side can be executed in the order appropriate to a particular customer installation. The order chosen in this Recommendation is for description and does not impose any constraints on implementations. .bp .RT .sp 2P .LP I.2.1\ \ \fITerminals supporting bearer services\fR .sp 1P .RT .sp 1P .LP I.2.1.1\ \ \fIMinimum functions\fR .sp 9p .RT .LP I.2.1.1.1\ \ For outgoing calls, generation of information defining the service and address information, i.e.\ bearer capability and called address. .LP I.2.1.1.2\ \ For incoming calls, analysis of whether a bearer service is requested (not a teleservice). If a higher layer protocol (repesenting a specific teleservice) is requested, the terminal shall ignore the call. This function may be provided by the simple determination of the \fIexistence\fR of higher layer protocol information received with the incoming call message. .LP I.2.1.1.3\ \ For incoming calls, analysis of the individual bearer service requested. This function is obtained by the analysis of the bearer capability information received with the incoming call message. .LP I.2.1.1.4\ \ For incoming calls, analysis of multiple subscriber number information, if provided. A call shall only be answered if the requested multiple subscriber number matches the identity assigned to the terminal. .PP Terminals which do not support the multiple subscriber number supplementary service, shall at least detect the presence of this information. If present, such terminals shall not answer the call. .PP Terminals supporting the multiple subscriber number supplementary service must analyze this information and will only answer the call if the received information matches the pre\(hyassigned identity or if there is a global call. .RT .LP I.2.1.1.5\ \ For incoming calls, analysis of subaddress information. A call shall only be answered if the requested subaddress matches the one assigned to the terminal. .PP Terminals which do not support the subaddressing mechanism, shall at least detect the presence of this information. If present, such terminals shall not answer the call. .PP Terminals supporting the subaddressing mechanism must analyze this information and will only answer the call if the received information matches the pre\(hyassigned information. Terminals with subaddress capability shall not reject calls on the absence of subaddress information. .RT .LP I.2.1.1.6\ \ Terminals supporting more than one bearer service must apply rules of \(sc\(sc\ I.2.1.1.1, I.2.1.1.2 and\ I.2.1.1.3 individually. The assignment of a multiple subscriber number or a subaddress may be common for all bearer services. .sp 1P .LP I.2.1.2\ \ \fIOptional functions\fR .sp 9p .RT .LP I.2.1.2.1\ \ Terminals supporting the multiple subscriber number supplementary service may be pre\(hyassigned more than one number and will therefore answer incoming calls which match one of the pre\(hyassigned identities or which have a global identity (global call) (see Note). .LP I.2.1.2.2\ \ Terminals supporting the subaddressing mechanism may be pre\(hyassigned more than one subaddress and will therefore answer incoming calls which match one of the pre\(hyassigned subaddress or which have no subaddress ( global call ). .PP \fINote\fR \ \(em\ An incoming call is global if there is no information contained in the call set\(hyup message to relate the call to sub\(hyset of the terminal population based on terminal identity (information on terminal identity is conveyed in the called party number information element). The term \*Q global identity \*U is used to reflect the global relationship with respect to terminal identity, and suitable coding methods are: .LP \(em to omit the called party number information element; .LP \(em to define a specific called party number as a global number (see also Recommendation\ Q.931). .sp 2P .LP I.2.2\ \ \fITerminals supporting teleservices\fR .sp 1P .RT .sp 1P .LP I.2.2.1\ \ \fIMinimum functions\fR .sp 9p .RT .LP I.2.2.1.1\ \ For outgoing calls, generation of information defining the service and address information, i.e.\ bearer capability, higher layer protocol information specifying the requested teleservice and called address. .bp .LP I.2.2.1.2\ \ For incoming calls, analysis of whether a teleservice is requested (and not a bearer service), i.e.\ if high layer protocol information (representing a specific teleservice) is \fInot\fR requested, the terminal shall ignore the call. This function may be provided by the simple determination of the \fIexitence\fR of high layer protocol information received with the incoming call message. As high layer compatibility (HLC) information may not be provided in the case of interworking with a non\(hyISDN, its absence should not be used as a reason for rejecting the call (see \(sc\ I.2.3.1). .LP I.2.2.1.3\ \ For incoming calls, analysis of the individual teleservice requested. This function is obtained by the analysis of the bearer capability information and the high layer protocol information received with the incoming call message. .LP I.2.2.1.4\ \ For incoming calls, analysis of multiple subscriber number information. A call shall only be answered if the requested multiple subscriber number matches the identity assigned to the terminal. .PP Terminals which do not support the multiple subscriber number supplementary service, shall at least detect the presence of this information. If present, such terminals shall not answer the call. .PP Terminals supporting the multiple subscriber number supplementary service must analyze this information and will only answer the call if the received information matches the pre\(hyassigned identity or if there is a global call. .RT .LP I.2.2.1.5\ \ For incoming calls, analysis of subaddress information. A call shall only be answered if the requested subaddress matches the one assigned to the terminal. .PP Terminals which do not support the subaddressing mechanism shall at least detect the presence of this information. If present, such terminals shall not answer the call. .PP Terminals supporting the subaddressing mechanism must analyze this information and will only answer the call if the received information matches the pre\(hyassigned information. Terminals with subaddress capability shall not reject calls on the absence of subaddress information. .RT .LP I.2.2.1.6\ \ Terminals supporting more than one teleservice must apply rules of \(sc\(sc\ I.2.2.1.1, I.2.2.1.2 and I.2.2.1.3 individually. The assignment of a multiple subscriber number or a subaddress may be common for all teleservices. .sp 1P .LP I.2.2.2\ \ \fIOptional functions\fR .sp 9p .RT .LP I.2.2.2.1\ \ Terminals supporting the multiple subscriber number supplementary service may be pre\(hyassigned more than one number and will therefore answer incoming calls which match one of the pre\(hyassigned identities or which have a global identity (global call). .LP I.2.2.2.2\ \ Terminals supporting the subaddressing mechanism may be pre\(hyassigned more than one subaddress and will therefore answer incoming calls which match one of the pre\(hyassigned subaddress or which have no subaddress (global call). .sp 2P .LP I.2.3 \fITerminals interworking with dedicated networks\fR .sp 1P .RT .sp 1P .LP I.2.3.1 \fIGeneral\fR .sp 9p .RT .PP For calls from the ISDN to a dedicated network the interworking function has to make provision that only calls which can be handled by the dedicated network are forwarded. .PP For calls originated in the dedicated network the interworking function may be unable to provide all elements exactly specifying the service requested according to the rules for a call within the ISDN. For example a call from the telephone network may be a request for telephony, for facsimile or for modem\(hybased data transmission and is presented to the ISDN as a request for the 3.1\ kHz audio bearer service. .PP In the case of interworking with a dedicated network, appropriate information is generated by the interworking function (progress indicator). The presence/absence of this information should be used as a criterion for different treatment of a call depending on whether the call originated within ISDN or within a dedicated network. .RT .sp 1P .LP I.2.3.1.1\ \ \fICalls from PSTN to ISDN\fR .sp 9p .RT .PP A PSTN call, supported by conventional signalling prior to arrival at an ISDN interworking point, will belong to one of two indistinguishable call types, i.e.\ ordinary speech of voiceband data, of which the latter includes facsimile and modem\(hybased data. At the interworking .bp .PP point the bearer capability \*Q3.1\ kHz audio\*U is routinely assigned to assure compatibility with any of these call types. A \*Qprogress indicator\*U is also applied to mark a non\(hyISDN call source. Some PSTN customers, however, will be served from ISDN\(hycapable exchanges and calls will be supported by common channel signalling for the entire connection. This affords some added opportunities to make distinctions between the call types. The extent to which this should be recommended is for further study. .RT .sp 1P .LP I.2.3.1.2\ \ \fICalls from PSPDN to ISDN\fR .sp 9p .RT .PP (See \(sc 5.3 of this Recommendation.) .RT .sp 1P .LP I.2.3.1.3\ \ \fICalls from PSPDN to ISDN\fR .sp 9p .RT .PP (See \(sc 5.4 of this Recommendation.) .RT .sp 1P .LP I.2.3.1.4 \fICalls from networks referred to as digital PSTNs, pre\(hyISDNs,\fR \fIpilot ISDNs or extended IDNs to ISDNs\fR .sp 9p .RT .PP Calls providing a 64 kbit/s transfer rate transparently from one of the above\(hymentioned networks to an ISDN terminal configuration are not yet finally defined. The 64\ kbit/s unrestricted bearer service will be used, but in any case there is an interworking taking place. A progress indicator is present, indicating a non\(hyISDN call source. Specific high or low layer functionality information cannot, however, be guaranteed. Therefore, the only basic principle which allows distinction between individual terminals is the supplementary service multiple subscriber number. .RT .sp 1P .LP I.2.3.2 \fITelephone terminals in ISDN\fR .sp 9p .RT .PP Telephone terminals have certain particular characteristics which have to be taken into account. With these terminals, compatibility checking will be aided by the HLC. Details are for further study. In the case of absence of HLC information, telephone terminals may be considered in a similar manner as terminals supporting bearer services described in \(sc\ I.2.1 above \(em\ even if telephony is a teleservice. .PP Telephone terminals must interwork with the existing analogue telephone network. For incoming calls they must therefore accept not only the bearer capability \*Qspeech\*U, which occurs in calls within ISDN, but also the bearer capability \*Q3,1\ kHz audio\*U, which is the bearer capability in case of interworking with the analogue telephone network and which is accompanied with call progress information indicating the interworking case. .RT .sp 1P .LP I.2.3.3 \fIFacsimile terminals in ISDN\fR .sp 9p .RT .PP A facsimile terminal on ISDN may have the capability to support both Group\ 2/3 mode and Group\ 4 mode (Group\ 3/Group\ 4 machine), Group\ 2/3 mode only (Group\ 3 machine) or Group\ 4 mode only (Group\ 4 machine). .PP In order to cater for the case where calls are incoming from networks not able to convey HLC information (e.g.\ PSTN, switched 64\ kbit/s, non\(hyISDN networks) it must be possible for a facsimile terminal to accept calls without the provision of an HLC information element. This may involve subscription to the Multiple Subscriber Number (MSN) supplementary service, in order to substitute the missing HLC information element. Moreover, for successful call establishment the facsimile terminal has to support the bearer service offered by the interworking function and the mode requested by the calling facsimile terminal. .PP Similar problems may occur for facsimile calls within the ISDN, if a Group 3 machine in combination with a terminal adaptor (TA) function is connected to the ISDN. .PP It is obvious that a Group 4 machine and a Group 3 machine are unable to communicate, whatever the network configuration is, when interworking with a dedicated network or TA. However, a Group\ 3/Group\ 4 machine is able to communicate to a facsimile machine connected to a dedicated network (this is a Group\ 3 machine in the case of PSTN, and a Group\ 4 machine in the case of switched 64\ kbit/s, non\(hyISDN Networks) or connected to the ISDN by means of a TA function. Appendix\ IV describes the circumstances and capabilities of facsimile terminals for the interworking situations identified above. .bp .RT .sp 1P .LP I.2.3.4 \fIData terminals in ISDN\fR .sp 9p .RT .PP Data terminals in ISDN may interwork with compatible data terminals in a dedicated data network or in the telephone network. For outgoing calls, the terminal has to operate as described in \(sc\ I.2.1 above and it selects the proper bearer capability according to the service request. For incoming calls, a data terminal shall function as described for terminals supporting bearer services in \(sc\ I.2.1 above. In case of interworking with the telephone network it has to accept calls indicating the bearer capability 3.1\ kHz audio which is accompanied with the call progress information. .PP Automatic answering data terminals connected to the ISDN and interworking with the telephone network or with the CSPDN shall support the multiple subscriber number supplementary service, because this is the only safeguard to avoid that a data terminal will capture each incoming telephone call, facsimile call from the PSTN or possibly each teletex call from the CSPDN. .RT .sp 1P .LP I.3 \fIApplications\fR .sp 9p .RT .PP Terminals (or terminal adaptors) that follow these terminal selection guidelines can be used on the same point\(hyto\(hymultipoint configuration with terminals of different functionality (e.g.\ Telefax, Teletex), but following the same terminal selection guidelines, thereby allowing incoming calls to be selected by the appropriate terminal. The inclusion on a point\(hyto\(hymultipoint configuration of terminals not following these guidelines may result in the mishandling of some calls. .PP Since the application of the terminal selection guidelines is not mandatory for ISDN terminals, it is essential to ensure that the terminals used on each multipoint interface are compatible among themselves for terminal selection. \v'1P' .RT .ce 1000 APPENDIX\ II .ce 0 .ce 1000 (to Recommendation I.333) .sp 9p .RT .ce 0 .ce 1000 \fBExamples of terminal selection in illustrative configurations\fR .sp 1P .RT .ce 0 .LP II.1 \fIScope\fR .sp 1P .RT .PP This appendix describes arrangements indicating some methods which could be used in terminal selection. The different terminal capabilities described in the arrangements are for illustration only. It is the responsibility of the terminal provider to provide terminals with capabilities appropriate to the intended use of the terminal. It is the responsibility of the called party to arrange the terminals on the interface so that incoming calls are handled according to the desires of the called party. .PP Each illustration indicates likely circumstances for use, and the potential impact of using the terminals on a point\(hyto\(hymultipoint configuration with terminals having different terminal selection functionality. Other terminal selection arrangements may be useful for certain circumstances. .PP Since the application of the terminal selection guidelines is not mandatory for ISDN terminals, it is essential that the terminals used on each multipoint interface are compatible among themselves for terminal selection. .RT .sp 2P .LP II.2 \fILimited functionality speech terminal\fR .sp 1P .RT .sp 1P .LP II.2.1 \fIConfiguration\fR .sp 9p .RT .PP An example of a simple terminal configuration is illustrated in Figure\ II\(hy1/I.333. The multiple terminal configuration example consists of up to eight voice terminals without terminal selection logic. .bp .RT .LP .rs .sp 13P .ad r \fBFigure II\(hy1/I.333, p.\fR .sp 1P .RT .ad b .RT .sp 1P .LP II.2.2 \fITerminals and network capabilities\fR .sp 9p .RT .PP Calls are delivered to the interface on the basis of an ISDN subscriber number (ISDN\(hySN). The terminals respond to the call offered on the basis of presumed eligibility to complete the call. .RT .sp 1P .LP II.2.3 \fIOffered call treatment\fR .sp 9p .RT .PP A terminal will respond to a set\(hyup message regardless of other terminal selection information (e.g.\ LLC) present in the set\(hyup message. More than one terminal may answer the offered call, but the network awards the call to the first terminal from which it receives an answer (connect) indication. .RT .sp 1P .LP II.2.4 \fIApplication\fR .sp 9p .RT .PP This type of terminals is appropriate for subscribers who wish only to receive speech calls and who are not concerned with which terminal answers the call. The use of this type of terminal on a point\(hyto\(hymultipoint configuration with terminals designed for anything other than speech calls will result in the mishandling of some calls. .RT .sp 2P .LP II.3 \fITerminal selected by\fR \fIend point identifier (EID)\fR \fIor subaddress\fR .sp 1P .RT .sp 1P .LP II.3.1 \fIConfiguration\fR .sp 9p .RT .LP \(em Multiple terminals with the same subscriber number. .LP \(em Distinction among the terminals is obtained using the EID or the subaddress (see Figure\ II\(hy2/I.333). .LP .rs .sp 13P .ad r \fBFigure II\(hy2/I.333, p.\fR .sp 1P .RT .ad b .RT .LP .bp .sp 1P .LP II.3.2 \fITerminals and network capabilities\fR .sp 9p .RT .PP The network may deliver the call using terminal identification procedures based on the end point identifier (EID). The terminal may respond to the set\(hyup message based on terminal identification procedures (e.g.\ use of the EID as defined in Recommendation\ Q.932 or subaddressing). .RT .sp 1P .LP II.3.3 \fIOffered call treatment\fR .sp 9p .RT .PP The network provides a set\(hyup message with terminal selection information that uniquely identifies a terminal. The terminal identification procedures based on EID or subaddressing schemes will identify a particular terminal and this terminal will respond according to the call or service offered. .RT .sp 1P .LP II.3.4 \fIApplication\fR .sp 9p .RT .PP The EID is provided by the network to identify a specific terminal. The network may make use of a User Service Profile together with terminal selection data to select the EID. In other applications, particularly those involving data terminals, each terminal may be assigned a subaddress and would respond only to calls containing that subaddress. .RT .sp 2P .LP II.4 \fIMultiple different terminals on a passive bus\fR .sp 1P .RT .sp 1P .LP II.4.1 \fIConfiguration\fR .sp 9p .RT .PP This example considers a speech terminal, a terminal adaptor for analogue interface, and a terminal adaptor for digital interface connected on a passive bus. The interface has been assigned three numbers that can be used (by non\(hyISDN customers) to indicate the terminal they wish to access. The arrangement is shown in Figure\ II\(hy3/I.333. .RT .LP .rs .sp 26P .ad r \fBFigure II\(hy3/I.333, p.\fR .sp 1P .RT .ad b .RT .LP .bp .sp 1P .LP II.4.2 \fITerminals and network capabilities\fR .sp 9p .RT .PP In this example, the terminals are connected to an interface that has been assigned three numbers. Any of the three numbers may be used from another ISDN for any service supported by the subscribers' terminals. For callers from networks that cannot indicate directly the service required (PSTNs, CSPDNs, and PSPDNs), the first number \*Q201\(hy555\(hy1111\*U is intended for speech services. The second number, \*Q201\(hy555\(hy2222\*U is intended for modem data services. The third number, \*Q201\(hy555\(hy3333\*U is intended for access to the terminal adaptor for digital interface. .PP Terminal selection based on the ISDN subscriber number, bearer capability, and progress indicators is used to identify one (or none) of the three terminals that is appropriate to respond to an offered call. .RT .sp 2P .LP II.4.3 \fIOffered call treatment\fR .sp 1P .RT .sp 1P .LP II.4.3.1 \fISpeech terminal\fR (see Figure II\(hy4/I.333) .sp 9p .RT .PP Offered call bearer capability \(em \*QSpeech\*U: .RT .LP \ \ \ The terminal responds to the call. .LP Offered call bearer capability \(em \*Q3.1 kHz audio\*U: .LP 1) Progress indicator \(em non\(hyISDN: .LP i) Called number \(em 201\(hy555\(hy1111: .LP \ \ \ The terminal responds to the call .LP ii) Other called numbers: .LP \ \ \ The terminal does not respond. .LP 2) No progress indicator \(em ISDN origination and transit: .LP \ \ \ The terminal assumes that the call is a data call and does not respond. .PP Offered call with other bearer capabilities: the terminal does not respond. .LP .rs .sp 25P .ad r \fBFigure II\(hy4/I.333, p.\fR .sp 1P .RT .ad b .RT .LP .bp .sp 1P .LP II.4.3.2 \fITA for analogue interface/video display terminal\fR .sp 9p .RT .PP The terminal adaptor contains a codec that produces an analogue signal that is connected to a modem; the modem has a V\(hySeries interface to the Video Display Terminal (VDT). The logic is shown in Figure\ II\(hy5/I.333. .PP Offered call bearer capability \(em \*Q3.1 kHz audio\*U: .RT .LP 1) Progress indicator \(em non\(hyISDN: .LP i) Called number \(em 201\(hy555\(hy2222: .LP The terminal adaptor assumes that the call is a data call and responds. The call is connected to the video display terminal through a modem. .LP ii) Other called number: .LP The terminal adaptor does not respond. .LP 2) No progress indicator \(em ISDN origination and transit: .LP The terminal adaptor responds. It assumes that, since the call originated at an ISDN terminal, the call is a data call regardless of the called number. .PP Offered call with other bearer capabilities: the terminal adaptor does not respond. .LP .rs .sp 27P .ad r \fBFigure II\(hy5/I.333, p.\fR .sp 1P .RT .ad b .RT .sp 1P .LP II.4.3.3 \fITA for digital interface/video display terminal\fR .sp 9p .RT .PP The terminal adaptor adapts the V\(hySeries interface to the interface at reference point\ S of ISDN. .PP The adaptation includes rate adapting the 9600 bit/s rate of the display terminal to the 64\ kbit/s rate of a B\(hychannel. The logic for the digital terminal adaptor is shown in Figure\ II\(hy6/I.333. .bp .PP For non\(hyISDN calls, it is assumed that the call is routed through an interworking function that establishes a bearer capability of 64\ kbit/s for the call. .PP Offered call bearer capability \(em \*Q64 kbit/s unrestricted\*U: .RT .LP 1) Progress indicator \(em non\(hyISDN: .LP i) Called number \(em 201\(hy555\(hy3333: .LP The switch routes the connection through an interworking unit (e.g. a modem). The terminal adaptor for digital interface/display terminal answers the call. .LP ii) Other called numbers: .LP The terminal adaptor does not respond. .LP 2) No progress indicator \(em ISDN origination and transit: .LP The terminal adaptor responds. It assumes that, since the call originated at an ISDN terminal, the call is a data call regardless of the called number. .LP .rs .sp 28P .ad r \fBFigure II\(hy6/I.333, p.\fR .sp 1P .RT .ad b .RT .sp 1P .LP II.4.4 \fIApplication\fR .sp 9p .RT .PP This example of multiple different terminals on a passive bus illustrates the terminal selection logic that allows the appropriate terminal, from among a speech terminal, a terminal adaptor for analogue interface, and a terminal adaptor for digital interface, to respond to an incoming call. Calls from a non\(hyISDN network are selected on the basis of the called ISDN number; calls from an ISDN subscriber are selected on the basis of the bearer capability. The addition to the interface of other terminals with different functionality but using the same bearer capability would result in incorrect terminal selection. .bp .RT .ce 1000 APPENDIX\ III .ce 0 .ce 1000 (to Recommendation I.333) .sp 9p .RT .ce 0 .ce 1000 \fBExamples of terminal selection using\fR .sp 1P .RT .ce 0 .ce 1000 \fBlocal terminal selection procedures\fR .ce 0 .PP This appendix describes the concept of a logical terminal and its application in assisting the network to provide services to the access through local terminal identification mechanisms. .sp 1P .RT .sp 1P .LP III.1 \fILogical terminals\fR .sp 9p .RT .PP There may exist up to 8 physical terminals on an S/T bus. Within each physical terminal there may exist one or more logical terminals (as shown in Figure\ III\(hy1/I.333). A logical terminal is considered to be the exchange's view of the physical terminal(s) on an interface. The parameters which are maintained by the exchange, which describe the logical terminal characteristics, are collectively termed to be the Logical Terminal Profile (LTP). The LTP may contain such information as subscriber numbers, bearer capabilities supported, services subscribed to, or other information which the exchange may require to successfully offer service to the terminals on the interface. A physical terminal can appear (to the network) to be several logical terminals by using several unique TEIs (see Note), each of which may map into a single LTP. The relationship of logical terminals to LTPs may be one\(hyto\(hyone or many\(hyto\(hyone. The relationship between physical terminals, logical terminals. TEIs and LTPs is illustrated in Figure\ III\(hy2/I.333). .PP \fINote\fR \ \(em\ The terminal end point identifier (TEI) is part of the D\(hychannel layer\ 2 address field [see Recommendation\ Q.921 (I.441)]. .PP Eight logical terminals (the inner boxes, labeled LT1 to LT8) are shown in a total of four physical terminals (the outer boxes, labeled PT1 to PT4). Each logical terminal corresponds to one TEI. This arrangement reflects a customer subscribing to the multiple subscriber number (MSN) supplementary service. .RT .LP .rs .sp 23P .ad r \fBFigure III\(hy1/I.333, p.\fR .sp 1P .RT .ad b .RT .LP .bp .LP .rs .sp 39P .ad r \fBFigure III\(hy2/I.333, p.\fR .sp 1P .RT .ad b .RT .sp 1P .LP III.2 \fIApplication\fR .sp 9p .RT .PP It is considered that the subscriber may want the exchange to provide terminal selection functions for his terminals. A local terminal selection procedure will accommodate this. In addition, future services may be facilitated which could require special call treatment based on knowledge of the terminal(s) maintained in an LTP and identified using a local procedure. .PP In the context of terminating calls, when an exchange receives digits of a subscriber number (SN) for a call to a terminal on a subscriber line, it would search for the LTP(s) associated with the SN. It would then formulate network\(hylayer call control messages to alert these terminals based on the descriptions associated with the LTP. The Q.932 procedure is used to allow association of a TEI with an LTP. The procedures used for all establishment comply with Recommendation\ Q.931 (I.451). .bp .RT .ce 1000 APPENDIX\ IV .ce 0 .ce 1000 (to Recommendation I.333) .sp 9p .RT .ce 0 .ce 1000 \fBFacsimile terminals in ISDN\fR \v'1P' .sp 1P .RT .ce 0 .LP IV.1 \fIOutgoing calls\fR .sp 1P .RT .PP In accordance with \(sc I.2.2.1.1 a G3/G4 (Group3/Group/4) machine or a G4 machine attempting a G4 call shall use the bearer capability according to the capabilities of the network, which may be either \*Qcircuit\(hymode 64\ kbit/s unrestricted 8\ kHz structured\*U (category\ I.231.1) or \*Qvirtual call\*U (category\ I.232.1), or both of them, and provide the HLC information element with high layer characteristics identification \*Qfacsimile group\ 4\*U. .PP In accordance with \(sc I.2.2.1.1 a Terminal Adaptor (TA) supporting a G3 machine shall use the 3.1\ kHz audio bearer capability and shall provide the HLC information element with high layer characteristics identification \*Qfacsimile group\ 3\*U. .PP The actions to be taken by the calling facsimile terminal following an unsuccessful call attempt where incompatibility has been indicated (e.g.\ cause \*Qincompatible destination\*U for calls within the ISDN, or call rejection with a suitable cause indication in the case of interworking with a dedicated network) require further study. The optimum condition to achieve compatibility in a call re\(hyattempt greatly depends on the cause indication provided to the calling facsimile terminal and its capability to divert to the requested characteristics for the call re\(hyattempt. For a certain type of facsimile terminal these actions may include: .RT .LP i) A G3 machine shall release the call and take no further action. .LP ii) A G4 machine shall release the call. .LP The G4 machine may initiate a call re\(hyattempt, if a mismatch of the bearer capability has been indicated and it can match the requested characteristics, e.g.\ in the case where the \*Qvirtual call\*U (category\ I.232.1) bearer capability has been requested by the calling facsimile terminal and interworking with switched 64\ kbit/s non\(hyISDN network takes place. Otherwise it cannot take further actions and is unable to communicate with the called facsimile terminal. .LP iii) A G3/G4 machine shall release the call. .LP If interworking ISDN to PSTN has been indicated, or cause \*Qincompatible destination\*U for calls within the ISDN, when the call has been rejected, the G3/G4 machine may initiate a re\(hyattempt in the G3 mode. It shall use the 3.1\ kHz audio bearer capability and shall provide the HLC information element with high layer characteristics identification \*Qfacsimile group\ 3\*U. .LP If interworking ISDN, to switched 64 kbit/s non\(hyISDN network, has been indicated when the call has been rejected, actions according to item\ ii) may be appropriate. .sp 1P .LP IV.2 \fIIncoming calls\fR .sp 9p .RT .PP For incoming calls originated within ISDN, the facsimile terminal shall function as described for terminals supporting teleservices in \(sc\ I.2.2. .PP For incoming calls from non\(hyISDN networks such as the telephone network (PSTN), the facsimile terminal will receive the appropriate information indicating an interworking situation (call progress information). It shall rely on the call progress information element to accept calls which are offered without information specifying high layer protocols, if it matches other elements describing the incoming call. Otherwise it shall release or ignore the call (user options). Facsimile terminals connected to the ISDN and interworking .PP with non\(hyISDN networks must support the supplementary service Multiple Subscriber Number. This supplementary service allows to substitute the missing information describing the call and is the only means to avoid having a facsimile terminal accept calls which are not appropriate to it, e.g.\ incoming call from non\(hyISDN networks such as telephone calls or data calls. .bp .PP The rules below are applicable to a certain type of facsimile terminal. They define the criteria which should be used by the terminal to determine whether, and in what mode it should answer the call: .RT .LP i) A TA supporting a G3 machine should answer the call if the following criteria are fulfilled: .LP a) The called party number information element, if present, contains a number which matches the number assigned to the TA; and .LP b) the bearer capability information element indicates the information transfer capability \*Q3.1\ kHz audio\*U; and .LP c1) the progress indicator information element indicates the progress description \*Qcall is not end\(hyto\(hyend ISDN\*U (incoming call from PSTN);and .LP d1) the high layer compatibility information element is not present; and .LP e1) the called party subaddress information element is not present; .LP or (instead of c1, d1, e1) .LP c2) the progress indicator information element is not present (incoming call from ISDN); and .LP d2) the high layer compatibility information element indicates high layer characteristics identification \*Qfacsimile group\ 3\*U; and .LP e2) the called party subaddress information element, if present, contains a number which matches the subaddress assigned to the terminal. .LP ii) A G3/G4 machine should answer the call in the G3 mode (including modem and codec functions) if the following criteria are fulfilled (incoming call from PSTN); .LP a) The called party number information element, if present, contains a number which matches the number assigned to the terminal; and .LP b) the bearer capability information element indicates the information transfer capability \*Q3.1\ kHz audio\*U; and .LP c) the progress indicator information element indicates the progress description \*Qcall is not end\(hyto\(hyend ISDN\*U; and .LP d) the high layer compatibility information element is not present; and .LP e) the called party subaddress information element is not present. .LP iii) A G3/G4 machine (or a G4 machine) should answer the call in the G4 mode (neither modem nor codec functions) if the following criteria are fulfilled (incoming call from switched 64\ kbit/s network (non\(hyISDN); .LP a) The called party number information element, if present, contains a number which matches the number assigned to the terminal; and .LP b) the bearer capability information element indicates the information transfer capability \*Qunrestricted digital information\*U and transfer mode \*Qcircuit mode\*U; and .LP c) the progress indicator information element indicates the progress description \*Qcall is not end\(hyto\(hyend ISDN\*U; and .LP d) the high layer compatibility information element is not present; and .LP e) the called party subaddress information element is not present. .LP iv) A G3/G4 machine (or a G4 machine) should answer the call in the G4 mode (neither modem nor codec functions) if the following criteria are fulfilled (incoming call from ISDN); .LP a) The called party number information element, if present, contains a number which matches the number assigned to the terminal; and .LP b) the bearer capability information element indicates the information transfer capability \*Qunrestricted digital information\*U and a transfer mode which is supported by the called facsimile terminal (\*Qcircuit mode\*U or \*Qpacket mode\*U); and .LP c) the progress indicator information element is not present; and .LP d) the high layer compatibility information element indicates high layer characteristics identification \*Qfacsimile group\ 4\*U; and .LP e) the called party subaddress information element, if present, contains a number which matches the subaddress assigned to the terminal. .bp .sp 2P .LP Recommendation I.334 .RT .sp 2P .ce 1000 \fBPRINCIPLES\ RELATING\ ISDN\ NUMBERSB/FSUBADDRESSES\ TO\fR .EF '% Fascicle\ III.8\ \(em\ Rec.\ I.334'' .OF '''Fascicle\ III.8\ \(em\ Rec.\ I.334 %' .ce 0 .sp 1P .ce 1000 \fBTHE\ OSI\ REFERENCE\ MODEL\ NETWORK\ LAYER\ ADDRESSES\fR .ce 0 .sp 1P .ce 1000 \fI(Melbourne, 1988)\fR .sp 9p .RT .ce 0 .sp 1P .LP 1. \fIIntroduction\fR .sp 1P .RT .PP Recommendation X.200, covering the open systems reference model, applies the term \*Qaddress\*U to identify service access points at each layer. With respect to the network layer, a service access point may be identified by an ISDN numberB/Fsubaddress. This Recommendation is provided to clarify the concepts and terminology which relate ISDN numbers and subaddresses to one another and to OSI reference model network layer addresses. .RT .sp 1P .LP 1.1 \fIBasic relationships\fR .sp 9p .RT .PP The essential purpose of the network layer is to achieve routing of information within the Open Systems Interconnection (OSI) environment. To that purpose it may be useful to establish a correspondence between an ISDN address (ISDN number, possibly with subaddress) and an X.200 network layer service access point. However, an ISDN address may in some instances identify an\fR end\(hysystem not conforming to the OSI model. In such cases the format and syntax of the subaddress are available for user\(hyspecific purposes. Section 2 summarizes the coding agreements which allow this flexibility. (The publication of the summary in this Recommendation is for information only and does not indicate administrative responsibility for contents nor assure current status of the material presented.) .RT .sp 1P .LP 1.2 \fINSAPs and ISDN addresses\fR .sp 9p .RT .PP The ISDN address (ISDN number, possibly with subaddress) may include the OSI network layer address and thereby offer means to identify Network Service Access Points (NSAPs). Figure\ 1/I.334 shows the three cases,\ a), b) and\ c) below, relating an ISDN address to a particular OSI\ NSAP address. .PP For completeness, references to protocol elements are included in the three cases which follow. For circuit mode access, the callingB/Fcalled subaddress information elements associated with the Q.931 SET\(hyUP message are used to transmit subaddress information, while the X.25 address extension field serves this purpose for packet mode access. For interoffice circuit mode calls, the Q.931 subaddress information elements may be transmitted within the access transport parameter of the Signalling System No.\ 7 (S.S. No.\ 7) initial address message. On packet mode internetwork calls, the X.75 address extension field is available to carry subaddress information. .PP The components of the OSI NSAP address are the AFI (Authority and Format Identifier), the IDI (Initial Domain Identifier) and possibly the \fR DSP\ (Domain Specific Part) (see also \(sc\ 3). .RT .LP a) The OSI NSAP address is comprised only of an AFI IDI, in which the IDI is semantically identical to the ISDN number. There is no DSP. A terminal can do one of the following: .LP a1) The entire NSAP is carried in the subaddress field; or .LP a2) If the conditions in \(sc\ 1.3.1 are satisfied, the NSAP address can be inferred from the E.164 number. .LP \fINote\fR \ \(em\ For circuit mode calls, the semantic content of the AFI may be contained in the numbering and addressing plan identification in the Q.931 or S.S. No.\ 7 callingB/Fcalled address protocol elements. For packet mode calls, similar information may be found in the X.25B/FX.75 protocol. Until such time as a protocol mechanism for identifying the numbering plan and the type of number is implemented in X.25B/FX.75, analogous to that which exists in Q.931B/FS.S. No.\ 7, such information may be derivable from the X.25B/FX.75 address fields which may include a numbering plan escape code. It may also be possible for the semantic content of the AFI to be implied by network arrangements.\fR .bp .LP b) The OSI NSAP address is comprised of an AFI+IDI+DSP, in which the IDI is semantically identical to the ISDN number. In this case, the entire NSAP address is carried in the subaddressB/Faddress extension field. .LP c) The OSI NSAP address is comprised of an AFI+IDI+DSP, in which the IDI is not related to the ISDN number. The entire NSAP address is conveyed in the subaddressB/Faddress extension field. .LP .rs .sp 32P .ad r \fBFigure 1/I.334, p.\fR .sp 1P .RT .ad b .RT .sp 2P .LP 1.3 \fIEncoding of NSAP addresses\fR .sp 1P .RT .sp 1P .LP 1.3.1 \fIUse of the AF (Address Field)\fR .sp 9p .RT .PP Under certain conditions, the NSAP address, as defined in ISO 8348 AD2, may be conveyed entirely in the AF. These conditions are: .RT .LP a) the NSAP address consists solely of the IDP (i.e.\ the DSP is null); .LP b) the AFI can be deduced from the contents of the AF (e.g.\ with knowledge of the subnetwork to which the DTE is attached); and .LP c) the IDI is the same as the SNPA (Subnetwork Point of Attachment) address. .bp .PP When all the above conditions are satisfied, the AF may be used to convey the semantics of the entire NSAP address (the AFI is implied and the contents of the AF are equivalent to the IDI). In these cases, the AEF (Address Extension Field) may also be used (see \(sc\ 1.3.2). .sp 1P .LP 1.3.2 \fIUse of the AEF (Address Extension Field)\fR .sp 9p .RT .PP When the conditions in \(sc\ 1.3.1 are not satisfied, the AEF shall be used. The NSAP address, complete with AFI, is placed in the AEF (type of subaddress is X.213B/FISO 8348\ AD2). In this case, the contents of the AF are not defined by this Recommendation. .RT .sp 2P .LP 1.4 \fIDecoding of NSAP addresses\fR .sp 1P .RT .sp 1P .LP 1.4.1 \fIAbsent AEF case\fR .sp 9p .RT .PP If the AEF is not present, then local knowledge is required by the receiving NL (Network Layer) entity to determine whether an OSI NSAP address is to be deduced from the content of the AF. If this local knowledge indicates that an NSAP address is present, its abstract syntax is as follows: .RT .LP a) the AFI is deduced from knowledge of the subnetwork from which the packet was received; .LP b) the IDI is the same as the contents of the AF; and .LP c) the DSP is absent. .sp 1P .LP 1.4.2 \fIAEF case\fR .sp 9p .RT .PP If the AEF is present and the type of subaddress is X.213/ISO 8348 AD2, then the NSAP address is contained entirely within the AEF. The abstract syntax is as follows: .RT .LP a) the AFI is contained within the first two digits of the AEF; .LP b) the IDI is the remainder of the Initial Domain Part (IDP) after any leading and trailing padding digits are discarded; and .LP c) the DSP, if present, constitutes the remainder of the AEF content after any trailing padding digits are discarded. .sp 2P .LP \fB2\fR \fBMeans to specify the type of subaddress\fR .sp 1P .RT .PP Considering the three cases in which the NSAP address may be related to the ISDN addressB/Fsubaddress, a mechanism which permits determination of the type of subaddress present may be useful in making distinctions. The method of distinction is dependent upon the protocol being used. .PP In the case of Q.931B/FI.451, 3 bits within octet 3 of each subaddress information element (i.e.,\ calling and called party subaddress) .FS Octets\ 1 and\ 2 of the subaddress information elements serve as information element and length identifiers, respectively. .FE establish the \*Qtype of subaddress\*U. Two existing assignments, subject to change by responsible authorities are \*Quser\(hyspecified\*U and \*QX.213B/FISO 8348\ AD2\*U. All other values are reserved. .PP The actual subaddress information is coded beginning in octet 4 with the possibility of continuing up to octet 23, i.e., the subaddress information element has the capacity to carry a maximum of 20 octets of subaddress information. .RT .LP \(em Under the X.213B/FISO 8348\ AD2 encoding of type of subaddress, the initial two digits of the subaddress represent the AFI which permits further distinction in subaddress encoding schemes as specified in Figure\ 2/I.334. .LP \(em Under the user\(hyspecified encoding of type of subaddress, the subaddress field is encoded according to user specifications subject to a maximum length of 20\ octets. .PP In the case of packet mode calls using X.25/ISO 8208, bits within the first octet of the calling/called address extension facility parameter field indicate the \*Qtype of address extension\*U in a similar manner. .LP .sp 2 .bp .LP .rs .sp 34P .ad r \fBFigure 2/I.334, p.\fR .sp 1P .RT .ad b .RT .sp 2P .LP \fB3\fR \fBThe \fR \fBOSI NSAP address format\fR .sp 1P .RT .PP For reference purposes, a description of terms used in connection with NSAP addresses is provided below: .PP The format of the NSAP address is: .RT .LP .rs .sp 6P .ad r \fBFigure, p.\fR .sp 1P .RT .ad b .RT .LP .bp .LP IDP \(em Initial Domain Part . This is the part which contains all the internationally standardized parts of the NSAP address, i.e.\ those addresses and numbers which are controlled either by ISO or CCITT. .LP AFI \(em Authority and Format Identifier . This 2\(hydigit code indicates the authority responsible for the number following the AFI, such as\ X.121 or\ E.164 and the format of the DSP. This is always two digits and is allocated as per X.213/ISO 8348\ AD2. .LP IDI \(em Initial Domain Identifier . This may contain, for example, an E.164 or X.121 number. The networks which use these numbering schemes are termed subnetwork by ISO. The overall length of the field is determined by the maximum length of the number format being used. .LP DSP \(em Domain Specific Part . In the context of an E.164 IDI, this part contains an address which is relevant only to the domain which has been accessed beyond the domain specified within the IDI, such as a PBX\ extension, a LAN terminal and so on. This is a variable length field, and is constrained by the length of the IDP, as the overall maximum length of the OSI\ NSAP address is 20\ octets. \v'1P' .sp 2P .LP Recommendation\ I.335 .RT .sp 2P .sp 1P .ce 1000 \fBISDN\ ROUTING\ PRINCIPLES\fR .EF '% Fascicle\ III.8\ \(em\ Rec.\ I.335'' .OF '''Fascicle\ III.8\ \(em\ Rec.\ I.335 %' .ce 0 .sp 1P .ce 1000 \fI(Melbourne, 1988)\fR .sp 9p .RT .ce 0 .sp 1P .LP \fB1\fR \fBIntroduction\fR .sp 1P .RT .PP A wide range of services is likely to be offered on ISDNs, which will be supported by a specific set of network capabilities. From a routing point of view, the relationship between these services and network capabilities must therefore be considered. .PP The aim of this Recommendation is to lay down basic routing principles defining the relationship between ISDN telecommunication services, as described in the I.200\(hySeries of Recommendations, and ISDN network capabilities as described in the I.300\(hySeries of Recommendations. This Recommendation addresses the relevance of these principles to the proposed routing plan for ISDN, and indicates what factors are involved in processing a call. ISDN routing implications of interworking (intra\(hyISDN and with other networks) are for further study. .RT .sp 2P .LP \fB2\fR \fBGeneral routing principles\fR .sp 1P .RT .PP As described in Recommendation I.210, telecommunication services are the communication capabilities offered to customers. The service concept can therefore be considered to be time independent. A particular instance (or use by the user) of a service is commonly referred to as a call. .PP Likewise, the network capabilities which support services, the ISDN connection types, are described in Recommendation\ I.340. These connection types are also time independent in their concept. .PP The ISDN network architecture Recommendation\ I.324 explains how an ISDN connection type is made up of connection elements: .RT .LP \(em the \*Qaccess connection element\*U; .LP \(em the \*Qnational transit connection element\*U; and .LP \(em the \*Qinternational transit connection element\*U. .LP The connection elements, also time independent, are used for the description of the different reference configurations associated with the different connection types (see Recommendation\ I.325). .PP It should be noted that the user specifies only the service required. The network allocates the resources to set up a connection of the specific type as necessary to support the requested service. For certain services, additional network functions, e.g.\ additional lower layer function and/or higher layer functions, may be required as depicted in Figure\ 1/I.335. For examples of such cases refer to Recommendation\ I.310. .bp .LP .rs .sp 16P .ad r \fBFigure 1/I.335, p.\fR .sp 1P .RT .ad b .RT .PP Figure 2/I.335 shows the general relationship between telecommunication services and ISDN connection types . It also shows in general the association with the actual realization of a service provision (call) by the establishment of a connection through the selection of a route. .PP The relationship between a call and a connection is a \fIroute\fR . This means that a route\fR is the application of a particular connection to a specific call. The connection (being an instance of a connection type) will specify the network capabilities being used on a particular call. A route therefore has geographical significance. .RT .LP .rs .sp 19P .ad r \fBFigure 2/I.335, p.\fR .sp 1P .RT .ad b .RT .PP In order to establish a communication an ISDN must select: .LP \(em an appropriate connection type, i.e.\ functional grouping , to support the service; .LP \(em an appropriate association between the selected functional grouping in terms of a physical realization, i.e.\ the network allocates the set of connection elements necessary to realize the appropriate connection type. .bp .PP The concept of connection type describes network capabilities using the attribute technique. One of these attributes is known as \*Qinformation transfer susceptance\*U. Some other attributes (e.g.\ \*Qconnection control protocol\*U) describe the signalling capabilities. .LP i) \fIInformation transfer susceptance\fR .LP For each service requested by the user, the network has to provide a connection type having a suitable value of the information transfer susceptance attribute, involving switching and transmission capability. The selection of an appropriate connection type is part of the routing functions. .LP The relationship between the information transfer susceptance attribute of a connection type and the transmission/switching capabilities is detailed in Recommendation\ E.172. .LP ii) \fISignalling capabilities\fR .LP Since the telephone network will progressively evolve towards ISDN, not all part of the network will initially have the same signalling capabilities. Between two given exchanges in the network, the following signalling systems for example, may be available: .LP \(em channel associated signalling: R1, R2. .LP \(em Signalling System No. 6 .LP \(em Signalling System No. 7: TUP .LP \(em Signalling System No. 7: ISUP .LP These different signalling systems have different signalling capabilities. The routing functions have to take into account the signalling capabilities of the network to ensure that the required service will be correctly provided. It is also necessary to consider the case where the required service can be provided, but with some restrictions. .LP \fIExample\fR \ \(em\ For a telephone call between two ISDN subscribers, TUP may be sufficient to set up a call but does not allow end\(hyto\(hyend information transfer and some supplementary services. .LP The routing principles consider these different cases. .PP The ISDN routing process, which is further detailed in \(sc\ 4 is divided into three aspects: .LP 1) matching between telecommunication services and ISDN connection types; .LP 2) determination of parameters relevant to routing to be conveyed and possibly processed across the signalling network; .LP 3) selection of rules for routing through the different connection elements with respect to the reference configurations in Recommendation\ I.325. .LP The \*Qrouting plan\*U itself, which is the set of rules for path selection in the ISDN, is given in Recommendation\ E.172. .PP This routing plan follows the routing principles outlined in Recommendation\ I.335 as well as other factors. Among others, the use of connections over geostationary satellites does not call for any alterations in the basic principles of ISDN routing. .PP Figure 3/I.335 shows the relationship between Recommendations relating to routing. .RT .sp 2P .LP \fB3\fR \fBMatching between telecommunication services and connection\fR \fBtypes\fR .sp 1P .RT .sp 1P .LP 3.1 \fIGeneral\fR .sp 9p .RT .PP The user requests a service not a connection type. It is the responsibility of the network, as part of its routing functions, to allocate a suitable connection type to support the requested service. Providing a mapping between the ISDN services and connection types would assist the network in its routing decisions. .PP Network operators will have freedom of choice in the selection of a suitable connection type for a given service request. .PP For international connections, the connection type selected should, for reasons of economy, generally be the minimum necessary to support the service. If for reasons of congestion such a connection type is not available the next higher capability connection type could be selected. .bp .RT .LP .rs .sp 31P .ad r \fBFigure 3/I.335, p.\fR .sp 1P .RT .ad b .RT .sp 1P .LP 3.2 \fIList of\fR \fIbearer services\fR .sp 9p .RT .PP Tables 1a/I.335 and 1b.I.335 list the attribute values and recommended provision of circuit\(hymode and packet\(hymode bearer service, respectively, as described in Recommendations\ I.231 and\ I.232. .RT .sp 1P .LP 3.3 \fIList of\fR \fIteleservices\fR .sp 9p .RT .PP Table 2/I.335 lists the attribute values of teleservices described in Recommendation\ I.241. .RT .sp 1P .LP 3.4 \fIList of\fR \fIconnection types\fR .sp 9p .RT .PP Table 3/I.335 lists the recommended connection types in an ISDN as described in Recommendation\ I.340. .RT .sp 1P .LP 3.5 \fIMapping of bearer services for ISDN connection types\fR .sp 9p .RT .PP Tables 4a/I.335, 4b/I.335 and 4c/I.335 show the mapping between bearer services and connection types. .PP Note that, in certain cases, more than one connection type may be suitable for a given bearer service. The first value would usually represent an exact match to the already defined bearer service attribute values, and subsequent values would represent acceptable alternative(s). .bp .PP Therefore, in determining the connection types usable for a given bearer service the network may provide: .RT .LP a) a connection type which is an exact mapping between the already defined bearer service and connection type attribute values; .LP b) a connection type wherein the mapping between the bearer service and the connection type attribute values differs for certain attributes, but shall provide equivalent or superior performance to that of\ a). .PP Also, permanent services might be supported on semi\(hypermanent connections. This is for further study. .sp 1P .LP 3.6 \fIMapping of teleservices to ISDN connection types\fR .sp 9p .RT .PP Teleservices are expected to be supported by the same set of connection types, but further studies are needed on additional routing aspects that may be required (see Table\ 5/I.335). .RT .sp 2P .LP \fB4\fR \fBRouting process in an ISDN\fR .sp 1P .RT .PP This section describes the routing process within the ISDN using the general model of the ISDN provided in the Recommendation\ I.324. .PP The routing process is the sequence of steps required to establish a connection in response to a service request. .PP A diagram of how routing parameters are used in the ISDN routing process, using the currently defined Q.760\ parameter fields is provided in Figure\ 4/I.335. .RT .sp 2P .LP 4.1 \fIDescription\fR .sp 1P .RT .sp 1P .LP 4.1.1 \fIUser\(hynetwork interface\fR .sp 9p .RT .PP The user places a request for a particular service. The terminal equipment converts this request into a Q.931\ set\(hyup message. This Q.931\ set\(hyup message is presented to the user\(hynetwork interface to request one of the following: .RT .LP \(em a bearer service .LP \(em a bearer service and supplementary service(s) .LP \(em a teleservice .LP \(em a teleservice and supplementary service(s) .PP The Q.931 request is coded to indicate the appropriate attributes of the requested service. The information elements indicated within the Q.931 message will vary depending on the type of bearer service or teleservice and supplementary service(s) requested. .sp 1P .LP 4.1.2 \fIOriginating local CRF\fR .sp 9p .RT .PP The originating local connection related function (CRF), e.g.\ local exchange, processes the Q.931 service request and determines if network routing is required. If network routing is required using S.S. No.\ 7 ISDN user part (ISUP), the local CRF translates this request into an appopriate initial address message (IAM) and determines the network resources needed to support this service. The IAM contains certain attributes of a connection type that specifies network capabilities sufficient to support this service. During the translation of the request the local CRF selects appropriate basic connection components. .RT .sp 1P .LP 4.1.3 \fITransit CRF\fR .sp 9p .RT .PP The transit CRF processes the incoming IAM and generates an appropriate outgoing IAM for the next stage of the call. The outgoing IAM contains certain attributes that defines network capabilities required to support this service. The transit CRF also allocates appropriate basic connection components, e.g.\ echo cancellers, \(*m\(hyA\ law converters, satellite links. .bp .RT .ce \fBH.T. [T1.335]\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(312p) . TABLE\ 1a/I.335 .T& cw(312p) . { \fBCircuit\(hymode bearer services recommended in an\fR \fBISDN\fR | ua\d\u)\d } .TE .TS center box ; cw(24p) | cw(30p) | cw(30p) | cw(72p) | cw(36p) | cw(24p) | cw(36p) | cw(60p) . No. Transfer mode Transfer rate (kbit/s) Transfert capability { Establishment of communication } Structure Communication configuration Symetry | ub\d\u)\d _ .T& cw(24p) | cw(30p) | cw(30p) | lw(72p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) . 1.1 circuit 64 { unrestricted digital | uc\d\u)\d } demand 8 kHz pt\(hypt bidirectional symmetric .T& cw(24p) | cw(30p) | cw(30p) | lw(72p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) . 1.2 circuit 64 { unrestricted digital | uc\d\u)\d } reserved 8 kHz pt\(hypt bidirectional symmetric .T& cw(24p) | cw(30p) | cw(30p) | lw(72p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) . 1.3 circuit 64 { unrestricted digital | uc\d\u)\d } permanent 8 kHz pt\(hypt bidirectional symmetric _ .T& cw(24p) | cw(30p) | cw(30p) | lw(72p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) . 2.1 circuit 64 speech demand 8 kHz pt\(hypt bidirectional symmetric .T& cw(24p) | cw(30p) | cw(30p) | lw(72p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) . 2.2 circuit 64 speech reserved 8 kHz pt\(hypt bidirectional symmetric .T& cw(24p) | cw(30p) | cw(30p) | lw(72p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) . 2.3 circuit 64 speech permanent 8 kHz pt\(hypt bidirectional symmetric _ .T& cw(24p) | cw(30p) | cw(30p) | lw(72p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) . 3.1 circuit 64 3.1 kHz audio demand 8 kHz pt\(hypt bidirectional symmetric .T& cw(24p) | cw(30p) | cw(30p) | lw(72p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) . 3.2 circuit 64 3.1 kHz audio reserved 8 kHz pt\(hypt bidirectional symmetric .T& cw(24p) | cw(30p) | cw(30p) | lw(72p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) . 3.3 circuit 64 3.1 kHz audio permanent 8 kHz pt\(hypt bidirectional symmetric _ .T& cw(24p) | cw(30p) | cw(30p) | lw(72p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) . 4.1 circuit 64 alt speech/unrestricted demand 8 kHz pt\(hypt bidirectional symmetric .T& cw(24p) | cw(30p) | cw(30p) | lw(72p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) . 4.2 circuit 64 alt speech/unrestricted reserved 8 kHz pt\(hypt bidirectional symmetric .T& cw(24p) | cw(30p) | cw(30p) | lw(72p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) . 4.3 circuit 64 alt speech/unrestricted permanent 8 kHz pt\(hypt bidirectional symmetric _ .T& cw(24p) | cw(30p) | cw(30p) | lw(72p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) . 5.1 circuit 2\(mu64 unrestricted demand 8 kHz | ud\d\u)\d pt\(hypt bidirectional symmetric .T& cw(24p) | cw(30p) | cw(30p) | lw(72p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) . 5.2 circuit 2\(mu64 unrestricted reserved 8 kHz | ud\d\u)\d pt\(hypt bidirectional symmetric .T& cw(24p) | cw(30p) | cw(30p) | lw(72p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) . 5.3 circuit 2\(mu64 unrestricted permanent 8 kHz | ud\d\u)\d pt\(hypt bidirectional symmetric _ .T& cw(24p) | cw(30p) | cw(30p) | lw(72p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) . 6.1 circuit 384 unrestricted demand 8 kHz pt\(hypt bidirectional symmetric .T& cw(24p) | cw(30p) | cw(30p) | lw(72p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) . 6.2 circuit 384 unrestricted reserved 8 kHz pt\(hypt bidirectional symmetric .T& cw(24p) | cw(30p) | cw(30p) | lw(72p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) . 6.3 circuit 384 unrestricted permanent 8 kHz pt\(hypt bidirectional symmetric _ .T& cw(24p) | cw(30p) | cw(30p) | lw(72p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) . 7.1 circuit 1536 unrestricted demand 8 kHz pt\(hypt bidirectional symmetric .T& cw(24p) | cw(30p) | cw(30p) | lw(72p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) . 7.2 circuit 1536 unrestricted reserved 8 kHz pt\(hypt bidirectional symmetric .T& cw(24p) | cw(30p) | cw(30p) | lw(72p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) . 7.3 circuit 1536 unrestricted permanent 8 kHz pt\(hypt bidirectional symmetric _ .T& cw(24p) | cw(30p) | cw(30p) | lw(72p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) . 8.1 circuit 1920 unrestricted demand 8 kHz pt\(hypt bidirectional symmetric .T& cw(24p) | cw(30p) | cw(30p) | lw(72p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) . 8.2 circuit 1920 unrestricted reserved 8 kHz pt\(hypt bidirectional symmetric .T& cw(24p) | cw(30p) | cw(30p) | lw(72p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) . 8.3 circuit 1920 unrestricted permanent 8 kHz pt\(hypt { bidirectional symmetric } .TE .LP \ua\d\u)\d As given in Recommendation I.231. .LP \ub\d\u)\d Unidirectional services are for further study. .LP \uc\d\u)\d During an interim period some networks may only offer restricted digital information transfer capability (i.e. an all\(hyzero octet is not allowed). .LP \ud\d\u)\d With RDTD \*QRestricted differential time delay\*U. .nr PS 9 .RT .ad r \fBTableau 1a/I.335 [T1.335], A L'ITALIENNE, p. 15\fR .sp 1P .RT .ad b .RT .LP .bp .ce \fBH.T. [T2.335]\fR .ce TABLE\ 1b/I.335 .ce \fBPacket mode bearer services\fR .ce | ua\d\u)\d .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(42p) | cw(30p) | cw(24p) | cw(30p) | cw(42p) | cw(36p) | cw(24p) . Bearer service No. Transfer mode Transfer rate Transfer capability { Establishment of the communication } Structure _ .T& lw(42p) | cw(30p) | cw(24p) | cw(30p) | cw(42p) | cw(36p) | cw(24p) . Virtual call P1 P2 packet packet FS FS unrestricted unrestricted demand permanent SDU SDU _ .T& lw(42p) | cw(30p) | cw(24p) | cw(30p) | cw(42p) | cw(36p) | cw(24p) . User to user signalling P3 P4 packet packet FS FS unrestricted unrestricted demand permanent SDU .TE .IP SDU \ua\d\u)\d As given in Recommendation I.232. .IP FS For further study. .IP SDU Service data unit. .nr PS 9 .RT .ad r \fBTableau 1b/I.335 [T2.335], p. 16\fR .sp 1P .RT .ad b .RT .LP .rs .sp 33P .ad r Blanc .ad b .RT .LP .bp .ce \fBH.T. [T3.335]\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(306p) . TABLE\ 2/I.335 .T& cw(306p) . { \fBList of teleservices (as described in\fR \fBRecommendation\ I.241)\fR } .TE .TS center box; cw(30p) | cw(36p) | cw(24p) | cw(24p) | cw(36p) | cw(36p) | cw(24p) | cw(36p) | cw(60p) . No. Teleservice Transfer mode Transfer rate (kbit/s) Transfer capability { Establishment of communication } Structure Communication configuration Symmetry _ .T& cw(30p) | lw(36p) | lw(24p) | cw(24p) | lw(36p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) . 1.1 telephony circuit 64 speech demand 8 kHz pt\(hypt bidirectional symmetric .T& cw(30p) | lw(36p) | lw(24p) | cw(24p) | lw(36p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) . 1.2 telephony circuit 64 speech reserved 8 kHz pt\(hypt bidirectional symmetric .T& cw(30p) | lw(36p) | lw(24p) | cw(24p) | lw(36p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) . 1.3 telephony circuit 64 speech permanent 8 kHz pt\(hypt bidirectional symmetric .T& cw(30p) | lw(36p) | lw(24p) | cw(24p) | lw(36p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) . 1.4 telephony circuit 64 speech demand 8 kHz multipt bidirectional symmetric .T& cw(30p) | lw(36p) | lw(24p) | cw(24p) | lw(36p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) . 1.5 telephony circuit 64 speech reserved 8 kHz multipt bidirectional symmetric .T& cw(30p) | lw(36p) | lw(24p) | cw(24p) | lw(36p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) . 1.6 telephony circuit 64 speech permanent 8 kHz multipt bidirectional symmetric _ .T& cw(30p) | lw(36p) | lw(24p) | cw(24p) | lw(36p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) . 2.1 teletex circuit 64 unrestricted demand 8 kHz pt\(hypt bidirectional symmetric _ .T& cw(30p) | lw(36p) | lw(24p) | cw(24p) | lw(36p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) . 3.1 telefax (Group 4) circuit 64 unrestricted demand 8 kHz pt\(hypt bidirectional symmetric _ .T& cw(30p) | lw(36p) | lw(24p) | cw(24p) | lw(36p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) . 4.1 mixed mode circuit 64 unrestricted demand 8 kHz pt\(hypt bidirectional symmetric _ .T& cw(30p) | lw(36p) | lw(24p) | cw(24p) | lw(36p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) . 5.1 videotex | ua\d\u)\d circuit 64 unrestricted demand 8 kHz pt\(hypt bidirectional symmetric .T& cw(30p) | lw(36p) | lw(24p) | cw(24p) | lw(36p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) . 5.2 videotex | ub\d\u)\d circuit 64 unrestricted demand 8 kHz pt\(hypt bidirectional symmetric .T& cw(30p) | lw(36p) | lw(24p) | cw(24p) | lw(36p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) . 5.3 videotex | ub\d\u)\d circuit 64 unrestricted permanent 8 kHz pt\(hypt bidirectional symmetric .T& cw(30p) | lw(36p) | lw(24p) | cw(24p) | lw(36p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) . 5.4 videotex | ub\d\u)\d circuit 64 unrestricted demand 8 kHz multipt bidirectional symmetric .T& cw(30p) | lw(36p) | lw(24p) | cw(24p) | lw(36p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) . 5.5 videotex | ub\d\u)\d circuit 64 unrestricted permanent 8 kHz multipt bidirectional symmetric .T& cw(30p) | lw(36p) | lw(24p) | cw(24p) | lw(36p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) . 5.6 videotex | ub\d\u)\d packet FS unrestricted demand SDU pt\(hypt bidirectional symmetric .T& cw(30p) | lw(36p) | lw(24p) | cw(24p) | lw(36p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) . 5.7 videotex | ub\d\u)\d packet FS unrestricted permanent SDU pt\(hypt bidirectional symmetric .T& cw(30p) | lw(36p) | lw(24p) | cw(24p) | lw(36p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) . 5.8 videotex | ub\d\u)\d packet FS unrestricted demand SDU multipt bidirectional symmetric .T& cw(30p) | lw(36p) | lw(24p) | cw(24p) | lw(36p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) . 5.9 videotex | ub\d\u)\d packet FS unrestricted permanent SDU multipt bidirectional symmetric _ .T& cw(30p) | lw(36p) | lw(24p) | cw(24p) | lw(36p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) . 6.1 telex circuit 64 unrestricted demand 8 kHz pt\(hypt bidirectional symmetric .T& cw(30p) | lw(36p) | lw(24p) | cw(24p) | lw(36p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) . 6.2 telex circuit 64 unrestricted reserved 8 kHz pt\(hypt bidirectional symmetric .T& cw(30p) | lw(36p) | lw(24p) | cw(24p) | lw(36p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) . 6.3 telex circuit 64 unrestricted permanent 8 kHz pt\(hypt bidirectional symmetric .T& cw(30p) | lw(36p) | lw(24p) | cw(24p) | lw(36p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) . 6.4 telex circuit 64 unrestricted demand 8 kHz multipt bidirectional symmetric .T& cw(30p) | lw(36p) | lw(24p) | cw(24p) | lw(36p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) . 6.5 telex circuit 64 unrestricted reserved 8 kHz multipt bidirectional symmetric .T& cw(30p) | lw(36p) | lw(24p) | cw(24p) | lw(36p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) . 6.6 telex circuit 64 unrestricted permanent 8 kHz multipt bidirectional symmetric .T& cw(30p) | lw(36p) | lw(24p) | cw(24p) | lw(36p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) . 6.7 telex packet FS unrestricted demand SDU pt\(hypt bidirectional symmetric .T& cw(30p) | lw(36p) | lw(24p) | cw(24p) | lw(36p) | lw(36p) | lw(24p) | lw(36p) | lw(60p) . 6.8 telex packet FS unrestricted demand SDU multipt { bidirectional symmetric } .TE .LP \ua\d\u)\d Transmission between user terminal and Videotex centre. .LP \ub\d\u)\d Transmission between Videotex centres and external computers. .LP FS For further study. .LP SDU Service data unit. .nr PS 9 .RT .ad r \fBTableau 2/I.335 [T3.335], A L'ITALIENNE, p. 17 \fR .sp 1P .RT .ad b .RT .LP .bp .ce \fBH.T. [T4.335]\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(300p) . TABLE\ 3/I.335 .T& cw(300p) . { \fBISDN connection types (based on Table 2/I.340)\fR } .TE .TS center box; cw(24p) | cw(30p) | cw(30p) | cw(60p) | cw(24p) | cw(36p) | cw(36p) | cw(60p) . Connection type No. Transfer mode Transfer rate (kbit/s) Transfer capability Structure Establishment of connection { Communication configuration | ua\d\u)\d } Symmetry _ .T& lw(24p) | lw(30p) | cw(30p) | lw(60p) | lw(24p) | lw(36p) | lw(36p) | lw(60p) . A.1 circuit \ \ 64 unrestricted digital 8 kHz switched pt\(hypt bidirectional symmetric .T& lw(24p) | lw(30p) | cw(30p) | lw(60p) | lw(24p) | lw(36p) | lw(36p) | lw(60p) . A.2 circuit \ \ 64 unrestricted digital 8 kHz semi\(hypermanent pt\(hypt bidirectional symmetric .T& lw(24p) | lw(30p) | cw(30p) | lw(60p) | lw(24p) | lw(36p) | lw(36p) | lw(60p) . A.3 circuit \ \ 64 unrestricted digital 8 kHz permanent pt\(hypt bidirectional symmetric _ .T& lw(24p) | lw(30p) | cw(30p) | lw(60p) | lw(24p) | lw(36p) | lw(36p) | lw(60p) . A.4 circuit \ \ 64 speech 8 kHz switched pt\(hypt bidirectional symmetric .T& lw(24p) | lw(30p) | cw(30p) | lw(60p) | lw(24p) | lw(36p) | lw(36p) | lw(60p) . A.5 circuit \ \ 64 speech 8 kHz semi\(hypermanent pt\(hypt bidirectional symmetric .T& lw(24p) | lw(30p) | cw(30p) | lw(60p) | lw(24p) | lw(36p) | lw(36p) | lw(60p) . A.6 circuit \ \ 64 speech 8 kHz permanent pt\(hypt bidirectional symmetric _ .T& lw(24p) | lw(30p) | cw(30p) | lw(60p) | lw(24p) | lw(36p) | lw(36p) | lw(60p) . A.7 circuit \ \ 64 3.1 kHz audio 8 kHz switched pt\(hypt bidirectional symmetric .T& lw(24p) | lw(30p) | cw(30p) | lw(60p) | lw(24p) | lw(36p) | lw(36p) | lw(60p) . A.8 circuit \ \ 64 3.1 kHz audio 8 kHz semi\(hypermanent pt\(hypt bidirectional symmetric .T& lw(24p) | lw(30p) | cw(30p) | lw(60p) | lw(24p) | lw(36p) | lw(36p) | lw(60p) . A.9 circuit \ \ 64 3.1 kHz audio 8 kHz permanent pt\(hypt bidirectional symmetric _ .T& lw(24p) | lw(30p) | cw(30p) | lw(60p) | lw(24p) | lw(36p) | lw(36p) | lw(60p) . A.10 circuit 2\(mu64 unrestricted digital 8 kHz | ub\d\u)\d switched pt\(hypt bidirectional symmetric .T& lw(24p) | lw(30p) | cw(30p) | lw(60p) | lw(24p) | lw(36p) | lw(36p) | lw(60p) . A.11 circuit 2\(mu64 unrestricted digital 8 kHz | ub\d\u)\d semi\(hypermanent pt\(hypt bidirectional symmetric .T& lw(24p) | lw(30p) | cw(30p) | lw(60p) | lw(24p) | lw(36p) | lw(36p) | lw(60p) . A.12 circuit 2\(mu64 unrestricted digital 8 kHz | ub\d\u)\d permanent pt\(hypt bidirectional symmetric _ .T& lw(24p) | lw(30p) | cw(30p) | lw(60p) | lw(24p) | lw(36p) | lw(36p) | lw(60p) . B.1 packet \ \ 64 (FS) unrestricted digital SDU switched pt\(hypt bidirectional symmetric .T& lw(24p) | lw(30p) | cw(30p) | lw(60p) | lw(24p) | lw(36p) | lw(36p) | lw(60p) . B.2 packet \ \ 64 (FS) unrestricted digital SDU semi\(hypermanent pt\(hypt bidirectional symmetric _ .T& lw(24p) | lw(30p) | cw(30p) | lw(60p) | lw(24p) | lw(36p) | lw(36p) | lw(60p) . C.1 circuit \ 384 { unrestricted digital | uc\d\u)\d } 8 kHz switched pt\(hypt bidirectional symmetric .T& lw(24p) | lw(30p) | cw(30p) | lw(60p) | lw(24p) | lw(36p) | lw(36p) | lw(60p) . C.2 circuit \ 384 { unrestricted digital | uc\d\u)\d } 8 kHz semi\(hypermanent pt\(hypt (unidirectionnal: FS) .T& lw(24p) | lw(30p) | cw(30p) | lw(60p) | lw(24p) | lw(36p) | lw(36p) | lw(60p) . C.3 circuit \ 384 { unrestricted digital | uc\d\u)\d } 8 kHz permanent pt\(hypt (unidirectionnal: FS) _ .T& lw(24p) | lw(30p) | cw(30p) | lw(60p) | lw(24p) | lw(36p) | lw(36p) | lw(60p) . C.4 circuit 1536 unrestricted digital 8 kHz switched pt\(hypt bidirectional symmetric .T& lw(24p) | lw(30p) | cw(30p) | lw(60p) | lw(24p) | lw(36p) | lw(36p) | lw(60p) . C.5 circuit 1536 unrestricted digital 8 kHz semi\(hypermanent pt\(hypt (unidirectional: FS) .T& lw(24p) | lw(30p) | cw(30p) | lw(60p) | lw(24p) | lw(36p) | lw(36p) | lw(60p) . C.6 circuit 1536 unrestricted digital 8 kHz permanent pt\(hypt (unidirectional: FS) _ .T& lw(24p) | lw(30p) | cw(30p) | lw(60p) | lw(24p) | lw(36p) | lw(36p) | lw(60p) . C.7 circuit 1920 unrestricted digital 8 kHz switched pt\(hypt bidirectional symmetric .T& lw(24p) | lw(30p) | cw(30p) | lw(60p) | lw(24p) | lw(36p) | lw(36p) | lw(60p) . C.8 circuit 1920 unrestricted digital 8 kHz semi\(hypermanent pt\(hypt (unidirectional: FS) .T& lw(24p) | lw(30p) | cw(30p) | lw(60p) | lw(24p) | lw(36p) | lw(36p) | lw(60p) . C.9 circuit 1920 unrestricted digital 8 kHz permanent pt\(hypt (unidirectional: FS) .TE .LP \ua\d\u)\d For multipoint services the necessary multipoint capabilities have to be provided. .LP \ub\d\u)\d With RDTD \*QRestricted differential time delay\*U. .LP \uc\d\u)\d During an interim period some networks may only offer restricted digital information transfer capability (i.e. an all\(hyzero octet is not allowed). .LP FS For further study. .LP SDU Service data unit. .nr PS 9 .RT .ad r \fBTableau 3/I.335 [T4.335], A L'ITALIENNE, p. 18\fR .sp 1P .RT .ad b .RT .LP .bp .ce \fBH.T. [T5.335]\fR .ce TABLE\ 4a/I.335 .ce \fBMapping of bearer services at 64 kbit/s to connection types\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(48p) | cw(14p) sw(14p) sw(14p) | cw(14p) sw(14p) sw(8p) | cw(14p) sw(14p) sw(14p) | cw(14p) sw(14p) sw(8p) | cw(24p) , ^ | c | c | c | c | c | c | c | c | c | c | c | c | ^ . { Connection types Bearer services } { 64 kbit/s Unrestricted digital } Speech 3.1 kHz audio { Unrestricted digital 2 \(mu 64 kbit/s } Notes A.1 A.2 A.3 A.4 A.5 A.6 A.7 A.8 A.9 A.10 A.11 A.12 _ .T& lw(48p) | cw(14p) | lw(14p) | lw(14p) | lw(14p) | lw(14p) | lw(8p) | lw(14p) | lw(14p) | lw(14p) | lw(14p) | lw(14p) | lw(8p) | lw(24p) . Unrestricted 1.1 X .T& lw(48p) | cw(14p) | cw(14p) | lw(14p) | lw(14p) | lw(14p) | lw(8p) | lw(14p) | lw(14p) | lw(14p) | lw(14p) | lw(14p) | lw(8p) | lw(24p) . digital 1.2 X .T& lw(48p) | cw(14p) | cw(14p) | cw(14p) | lw(14p) | lw(14p) | lw(8p) | lw(14p) | lw(14p) | lw(14p) | lw(14p) | lw(14p) | lw(8p) | lw(24p) . 64 kbit/s 1.3 X X _ .T& lw(48p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | lw(14p) | lw(8p) | cw(14p) | lw(14p) | lw(14p) | lw(14p) | lw(14p) | lw(8p) | cw(24p) . . 2.1 \ua\d\u)\d X X \ub\d\u)\d .T& lw(48p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | lw(8p) | cw(14p) | cw(14p) | lw(14p) | lw(14p) | lw(14p) | lw(8p) | cw(24p) . Speech 2.2 \ua\d\u)\d X X \ub\d\u)\d .T& lw(48p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | cw(8p) | cw(14p) | cw(14p) | cw(14p) | lw(14p) | lw(14p) | lw(8p) | cw(24p) . . 2.3 \ua\d\u)\d \ua\d\u)\d X X X X \ub\d\u)\d _ .T& lw(48p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | cw(8p) | cw(14p) | cw(14p) | cw(14p) | lw(14p) | lw(14p) | lw(8p) | cw(24p) . 3.1 kHz 3.1 \ua\d\u)\d X \ub\d\u)\d .T& lw(48p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | cw(8p) | cw(14p) | cw(14p) | cw(14p) | lw(14p) | lw(14p) | lw(8p) | cw(24p) . audio 3.2 \ua\d\u)\d X \ub\d\u)\d .T& lw(48p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | cw(8p) | cw(14p) | cw(14p) | cw(14p) | lw(14p) | lw(14p) | lw(8p) | cw(24p) . . 3.3 \ua\d\u)\d \ua\d\u)\d X X \ub\d\u)\d _ .T& lw(48p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | cw(8p) | cw(14p) | cw(14p) | cw(14p) | lw(14p) | lw(14p) | lw(8p) | cw(24p) . Alternate 4.1 \ua\d\u)\d \uc\d\u)\d .T& lw(48p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | cw(8p) | cw(14p) | cw(14p) | cw(14p) | lw(14p) | lw(14p) | lw(8p) | cw(24p) . speech/64 kbit/s 4.2 \ua\d\u)\d \uc\d\u)\d .T& lw(48p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | cw(8p) | cw(14p) | cw(14p) | cw(14p) | lw(14p) | lw(14p) | lw(8p) | cw(24p) . unrestricted 4.3 \ua\d\u)\d \ua\d\u)\d \uc\d\u)\d _ .T& lw(48p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | cw(8p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | lw(14p) | lw(8p) | cw(24p) . Unrestricted 5.1 X .T& lw(48p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | cw(8p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | lw(8p) | cw(24p) . digital 5.2 X .T& lw(48p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | cw(8p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | cw(14p) | cw(8p) | cw(24p) . 2 \(mu 64 kbit/s 5.3 X X .TE .LP \ua\d\u)\d May present A\(hy\(*m law conversion problems, echo control problems, etc. .LP \ub\d\u)\d Analogue transmission may also be used. .LP \uc\d\u)\d For the possibility of change of service during a call, see \(sc\ 5.2 of Recommendation\ I.340. .LP X Indicates that the connection type can definitely support the service. .LP \fINote\ 1\fR \ \(em\ During an interim period, some networks may only support restricted transfer capability (i.e. no all\(hyzero octet allowed). .LP \fINote\ 2\fR \ \(em\ For multipoint services the necessary multipoint capabilities have to be provided. .nr PS 9 .RT .ad r \fBTableau 4a/I.335 [T5.335], p. 19\fR .sp 1P .RT .ad b .RT .LP .rs .sp 14P .ad r Blanc .ad b .RT .LP .bp .ce \fBH.T. [T6.335]\fR .ce TABLE\ 4b/I.335 .ce \fBMapping of bearer services 64 kbit/s\fR .ce \fB(up to primary rate) to connection types\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(48p) | cw(18p) sw(18p) sw(18p) | cw(18p) sw(18p) sw(18p) | cw(18p) sw(18p) sw(18p) , ^ | c | c | c | c | c | c | c | c | c. { Connection types Bearer services } 384 kbit/s unrestricted 1536 kbit/s unrestricted 1920 kbit/s unrestricted C.1 C.2 C.3 C.4 C.5 C.6 C.7 C.8 C.9 _ .T& lw(48p) | cw(18p) | lw(18p) | lw(18p) | cw(18p) | lw(18p) | lw(18p) | cw(18p) | lw(18p) | lw(18p) . 384 kbit/s 6.1 X \ua\d\u)\d \ua\d\u)\d .T& lw(48p) | cw(18p) | cw(18p) | lw(18p) | cw(18p) | cw(18p) | lw(18p) | cw(18p) | cw(18p) | lw(18p) . unrestricted 6.2 X \ua\d\u)\d \ua\d\u)\d .T& lw(48p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) . . 6.3 X X \ua\d\u)\d \ua\d\u)\d \ua\d\u)\d \ua\d\u)\d _ .T& lw(48p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) . 1536 kbit/s 7.1 X \ua\d\u)\d .T& lw(48p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) . unrestricted 7.2 X \ua\d\u)\d .T& lw(48p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) . . 7.3 X X \ua\d\u)\d \ua\d\u)\d _ .T& lw(48p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) . 1920 kbit/s 8.1 X .T& lw(48p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) . unrestricted 8.2 X .T& lw(48p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) | cw(18p) . . 8.3 X X .TE .LP \ua\d\u)\d An appropriate rate adaption scheme must be defined and utilized. .LP X Indicates that the connection type can definitely support the service. .nr PS 9 .RT .ad r \fBTableau 4b/I.335 [T6.335], p. 20\fR .sp 1P .RT .ad b .RT .ce \fBH.T. [T7.335]\fR .ce TABLE\ 4c/I.335 .ce \fBMapping of packet\(hymode bearer services to connection types\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(54p) | cw(18p) | cw(18p) . { Connection types Bearer services } B.1 B.2 _ .T& lw(54p) | cw(18p) | lw(18p) . P.1 X P.2 X P.3 | ua\d\u)\d P.4 | ua\d\u)\d .TE .LP \ua\d\u)\d The connection types for these bearer services are for further study. .nr PS 9 .RT .ad r \fBTableau 4c/I.335 [T7.335], p. 21\fR .sp 1P .RT .ad b .RT .LP .bp .ce \fBH.T. [T8.335]\fR .ce TABLE\ 5/I.335 .ce \fBMapping of teleservices to ISDN connection types\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; lw(42p) | cw(12p) sw(12p) sw(12p) | cw(12p) sw(12p) sw(12p) | cw(12p) sw(12p) sw(12p) | cw(12p) sw(12p) | cw(18p) sw(12p) | cw(24p) , ^ | c | c | c | c | c | c | c | c | c | c | c | c | c | ^ . { Connection types Teleservices } 64 kbit/s unrestricted 64 kbit/s speech 64 kbit/s 3.1 kHz audio Packet User signalling Notes A.1 A.2 A.3 A.4 A.5 A.6 A.7 A.8 A.9 B.1 B.2 B.3 B.4 _ .T& lw(42p) | cw(12p) | lw(12p) | lw(12p) | cw(12p) | lw(12p) | lw(12p) | cw(12p) | lw(12p) | lw(12p) | lw(12p) | lw(12p) | lw(18p) | lw(12p) | rw(24p) . . 1.1 \ua\d\u)\d X X \ub\d\u)\d .T& lw(42p) | cw(12p) | cw(12p) | lw(12p) | cw(12p) | cw(12p) | lw(12p) | cw(12p) | cw(12p) | lw(12p) | lw(12p) | lw(12p) | lw(18p) | lw(12p) | rw(24p) . . 1.2 \ua\d\u)\d X X \ub\d\u)\d .T& lw(42p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | lw(12p) | lw(12p) | lw(18p) | lw(12p) | lw(24p) . Telephony 1.3 \ua\d\u)\d \ua\d\u)\d X X X X \uc\d\u)\d \ub\d\u)\d .T& lw(42p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | lw(12p) | lw(12p) | lw(18p) | lw(12p) | lw(24p) . . 1.4 \ua\d\u)\d X X \uc\d\u)\d \ub\d\u)\d .T& lw(42p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | lw(12p) | lw(12p) | lw(18p) | lw(12p) | lw(24p) . . 1.5 \ua\d\u)\d X X \uc\d\u)\d \ub\d\u)\d .T& lw(42p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | lw(12p) | lw(12p) | lw(18p) | lw(12p) | lw(24p) . . 1.6 \ua\d\u)\d \ua\d\u)\d X X X X \uc\d\u)\d \ub\d\u)\d _ .T& lw(42p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | lw(12p) | lw(12p) | lw(18p) | lw(12p) | lw(24p) . Teletex 2.1 X _ .T& lw(42p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | lw(12p) | lw(12p) | lw(18p) | lw(12p) | lw(24p) . Facsimile 3.1 X _ .T& lw(42p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | lw(12p) | lw(12p) | lw(18p) | lw(12p) | lw(24p) . Mixed mode 4.1 X _ .T& lw(42p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | lw(12p) | lw(12p) | lw(18p) | lw(12p) | lw(24p) . . 5.1 X .T& lw(42p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | lw(12p) | lw(12p) | lw(18p) | lw(12p) | lw(24p) . . 5.2 X .T& lw(42p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | lw(12p) | lw(12p) | lw(18p) | lw(12p) | lw(24p) . . 5.3 X X .T& lw(42p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | lw(12p) | lw(12p) | lw(18p) | lw(12p) | lw(24p) . . 5.4 X \uc\d\u)\d .T& lw(42p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | lw(12p) | lw(12p) | lw(18p) | lw(12p) | lw(24p) . Videotex 5.5 X X \uc\d\u)\d .T& lw(42p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | lw(12p) | lw(18p) | lw(12p) | lw(24p) . . 5.6 X .T& lw(42p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | lw(18p) | lw(12p) | lw(24p) . . 5.7 X \uc\d\u)\d .T& lw(42p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | lw(18p) | lw(12p) | lw(24p) . . 5.8 X \uc\d\u)\d .T& lw(42p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | lw(18p) | lw(12p) | lw(24p) . . 5.9 X \uc\d\u)\d _ .T& lw(42p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | lw(18p) | lw(12p) | lw(24p) . . 6.1 X .T& lw(42p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | lw(18p) | lw(12p) | lw(24p) . . 6.2 X .T& lw(42p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | lw(18p) | lw(12p) | lw(24p) . . 6.3 X X \uc\d\u)\d .T& lw(42p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | lw(18p) | lw(12p) | lw(24p) . T\*'elex 6.4 X \uc\d\u)\d .T& lw(42p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | lw(18p) | lw(12p) | lw(24p) . . 6.5 X \uc\d\u)\d .T& lw(42p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | lw(18p) | lw(12p) | lw(24p) . . 6.6 X X .T& lw(42p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | lw(18p) | lw(12p) | lw(24p) . . 6.7 X .T& lw(42p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | cw(12p) | lw(18p) | lw(12p) | lw(24p) . . 6.8 X \uc\d\u)\d .TE .LP \ua\d\u)\d May present A\(hy\(*m law conversion problems; echo control problems, etc. .LP \ub\d\u)\d Analogue transmission may also be used. .LP \uc\d\u)\d For multipoint services the necessary multipoint capabilities have to be provided. .LP X Indicates that the connection type can definitely support the service. .nr PS 9 .RT .ad r \fBTableau 5/I.335 [T8.335], p. 22\fR .sp 1P .RT .ad b .RT .LP .rs .sp 8P .ad r \fBFigure 4/I.335, p. 23\fR .sp 1P .RT .ad b .RT .LP .bp .sp 1P .LP 4.1.4 \fITerminating local CRF\fR .sp 9p .RT .PP The terminating local CRF, e.g.\ local exchange, processes the incoming IAM. The local CRF uses the information from within the incoming IAM to generate an appropriate Q.931 set\(hyup message. The set\(hyup message is then offered to the destination terminal across the user network interface, subject to certain local conditions and decisions. .RT .sp 1P .LP 4.2 \fIElements and parameters\fR .sp 9p .RT .PP The routing plan is a set of rules defining the process of selecting appropriate basic connection components conforming to the connection elements capable of supporting a given telecommunication service. These rules are developed in Recommendation\ E.172. To be able to implement these rules the CRFs must be capable of processing an elaborate set of parameters. .RT .sp 1P .LP 4.2.1 \fIDescription\fR .sp 9p .RT .PP This section describes the elements and parameters that may be required for the call routing process. Different network CRFs need not require a complete set of these parameters; however each CRF will require a minimum set to ensure efficient and effective routing. .RT .LP a) \fICalling customer's subscription parameters\fR .LP The local CRF may validate service requests against the customer's subscription parameters before the outgoing route is selected. .LP b) \fIIncoming route\fR .LP Some incoming routes may require special treatment (e.g.\ not allow access to all outgoing routes). .LP c) \fICalled number\fR .LP The called number, when provided, is used for routing. Access may be barred to a particular network or a particular customer, under either administrative or network management control, by analysis of the called number. .LP \fINote\fR \ \(em\ For destination network, see Table\ 7/I.335. .LP d) \fIBasic telecommunication service request\fR .LP The nature of the bearer or teleservice requested, requires parameter analysis to determine relevant attribute values of the minimum necessary connection type capable of supporting that service (e.g.\ information transfer susceptance, signalling system capabilities,\ etc.). .LP The parameters analyzed, for call routing, are predominantly related to the lower layers (e.g.\ BC). The network may, however, additionally analyze higher layer parameters (e.g.\ HLC). .LP e) \fITransmission medium requirement (TMR)\fR .LP The TMR is the encoding of the information transfer susceptance attribute value of the minimum necessary connection type capable of supporting the call. .LP \fINote\fR \ \(em\ Relevant attributes of the minimum necessary connection type are derived at the originating local CRF from the BC (Bearer Capability) and supplementary service request as an intermediate step in determining the values of routing parameters. The information transfer susceptance is derived from the information transfer capability and information transfer rate fields contained in the Q.931\ BC information element. .LP The encoding of the TMR may, depending on the network operator's policy, represent a higher value of the information transfer susceptance attribute that the minimum necessary to support the call. However, between international and internetwork gateways, the TMR should represent the minimum necessary (to support the requested service) and should not be modified. The TMR can then be used between such gateways to perform efficient routing. This does not preclude that some gateways may need to examine additional information [e.g.\ USI (User Service Information)]. .bp .LP Table 6/I.335 identifies the relationship between some circuit\(hymode bearer services and teleservices identified in I.230 with the (minimum) TMR value. .LP The values of TMR for other services is for further study. .LP .sp 1 .ce \fBH.T. [T9.335]\fR .ce TABLE\ 6/I.335 .ce \fBRelationships between the requested service and the minimum TMR .ce value\fR .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(108p) | cw(36p) sw(36p) sw(36p) , ^ | c | c | c. Requested service TMR value Speech 3.1 kHz audio 64 kbit/s unrestricted _ .T& lw(48p) | lw(60p) | cw(36p) | lw(36p) | cw(36p) , ^ | l | c | l | l ^ | l | l | l | l. Bearer services 64 kbit/s unrestricted X 3.1 kHz audio X Speech X _ Unable to convert table .TE .nr PS 9 .RT .ad r \fBTable 6/I.335 [T9.335], p.\fR .sp 1P .RT .ad b .RT .LP .sp 1 f ) \fIUser Service Information (USI)\fR .LP The USI is the encoding of the Q.931 BC into Q.762 ISUP. The USI parameter may be used to regenerate attributes of the TMR required by the routing function(s) at intermediate CRFs [see item\ e) above]. .LP g) \fISupplementary service request\fR .LP Both ISDN and PSTN services may invoke various supplementary services which may require analysis before the outgoing route is selected. The services can be split into those supported by both the ISDN and PSTN and those supported only by the ISDN. Within each of these two groups, some supplementary services may be realized as a function of the originating local exchange (e.g.\ short code dialling) while others will require end\(hyto\(hyend capabilities across the network (e.g.\ calling line identification and closed user group). The provision of these latter supplementary services can influence call routing in terms of the signalling system capability requirement. .LP Therefore the supplementary service requested can influence the value of the signalling system capability attribute of the connection type capable of supporting that combination of basic and supplementary service. .LP h) \fIISUP preference indicator\fR .LP This is an indicator contained within the forward call indicators parameter field of ISUP, sent in the forward direction indicating whether or not the ISDN user part (ISUP) is required or preferred or not required in all parts of the network connection. This information is derived at the originating local CRF from the network signalling capability attribute of the minimum necessary connection type, which is itself derived from the BC and supplementary service request contained in the Q.931 set\(hyup message. .bp .LP i) \fIEnvironment of the connection\fR .LP This information element contains three secondary attributes of the requested bearer service that may influence the routing process, namely: .LP 1) the establishment of communication (demand, reserved, permanent); .LP 2) the configuration of communication (point\(hyto\(hypoint, multipoint, broadcast); .LP 3) symmetry (symmetric, asymmetric). .LP These secondary attributes are contained in the Q.931\ BC information element and are directly transposed by the originating local CRF into the ISUP user service information parameter field [see item f ) above]. The impact of the environment of the connection on TMR for future service is for further study. .LP \fINote\fR \ \(em\ Each of these three secondary attributes may invoke special arrangements that may be necessary in order to establish, for example, point\(hyto\(hymultipoint, or asymmetric calls. .LP j) \fINetwork management conditions\fR .LP There may be cases where network management control of routing functions is required. (Route selection may be under control of routing information dynamically updated by network routing processors, i.e.\ processors monitoring network traffic flows.) For this reason CRFs may be required to implement capabilities for supporting this facility. .LP k) \fITransit network selection\fR .LP National networks may implement capabilities allowing requests for specific transit network(s) to be used in the call. Impact of this on call routing may require further study. .LP l) \fIConnection history\fR .LP In order to ensure that the number of links, the number of satellite hops and any other network limiting functions are not exceeded in a connection, a connection history should be available for processing prior to route selection. A set of relevant parameters is provided in ISUP by the nature of connection indicators parameter field. This field is generated at the originating local exchange and modified at subsequent transit exchanges each time a relevant parameter (e.g.\ number of satellite links) is affected as a result of the transmission path chosen. Code points for other parameters, e.g.\ number of sections with digital circuit multiplication equipment (DCME) and A\(hy\(*m law converters, may not be required for routing purposes since these should be taken into account in the hypothetical digital reference connection (HDRC) at the exchange routing data planning stage. However a signalling capability may be necessary to provide a means of verifying that parameter values are within the allowed limits. .LP \fINote\fR \ \(em\ It is considered that the responsibility of international operators for correctly setting up exchange routing data is of paramount importance to ensure that signalling systems and exchange processors are not burdened with the need for per\(hycall conveyance and examination of unnecessary information. .LP m) \fITime of day\fR .LP Because of varying traffic distributions during a 24\ hour period, it may be advantageous to change the call routing arrangements as a function of the time of day. .sp 1P .LP 4.2.2 \fIApplication in the\fR \fIrouting process\fR .sp 9p .RT .PP This section deals with the application of the information elements and parameters in the routing process identified in \(sc\ 4.2.1. The elements and parameters are given in Table\ 7/I.335 together with their significance with regard to different network CRFs (nodes). .RT .sp 1P .LP 4.2.2.1 \fIOriginating local CRF\fR .sp 9p .RT .PP The originating local CRF processes the Q.931 service request and determines if network routing is required. When routing is required, the local CRF maps the requested service into attributes of a connection type that specifies network capabilities sufficient to support this service. This mapping, discussed in \(sc\ 3, defines the network resources needed to support the service and results in the generation of an appropriate IAM. Additionally, the local CRF allocates the appropriate basic connection components which, as a minimum, conform to the required connection type. .bp .RT .sp 1P .LP 4.2.2.2 \fITransit CRF\fR .sp 9p .RT .PP The transit CRF will process an incoming IAM and will generate an appropriate outgoing IAM. .PP The incoming and outgoing IAM mesage contains the following parameter fields which may be used for routing purposes: .RT .LP \(em nature of connection indicators, .LP \(em forward call indicators, .LP \(em calling party's category, .LP \(em transmission medium requirement (TMR) , .LP \(em called party number, .LP \(em user service information (USI), .LP \(em transit network selection (national use only). .PP The IAM message may contain other parameters whose presence may influence the choice of signalling system capability for the call. These parameters are: .LP \(em call reference, .LP \(em calling party number, .LP \(em optional forward call indicators, .LP \(em redirecting number, .LP \(em CUG interlock code, .LP \(em connection request, .LP \(em user\(hyto\(hyuser information, .LP \(em access transport. .PP The parameters listed above contain all the signalling information needed to perform routing in the international network. .PP In the international network, the TMR is set to the value that represents the minimum network capability to provide the requested service and that value is not modified. .RT .sp 2P .LP \fB5\fR \fBISDN routing principles applicable to network\fR \fBinterworking\fR .sp 1P .RT .PP This section describes routing considerations in network interworking situations (i.e.\ ISDN to/from other networks), defined in the I.500\(hySeries of Recommendations. .RT .sp 1P .LP 5.1 \fIISDN\(hyPSTN interworking\fR .sp 9p .RT .PP Routing implications of the following ISDN\(hyPSTN interworking scenarios are described: .RT .LP i) \fIISDN to PSTN\fR .LP In this scenario, the call is initiated from an ISDN access and terminated on a PSTN access. .LP ii) \fIPSTN to ISDN\fR .LP In this scenario, the call is initiated from a PSTN access and terminated on an ISDN access. .PP These scenarios do not apply to network interworking situations wherein a transit network other than an ISDN or PSTN is involved. .PP The ISDN bearer capabilities that are compatible with the capabilities of the PSTN are identified in Recommendation\ I.530. In the general case, an ISDN\(hyoriginated call incompatible with PSTN capabilities is cleared with an appropriate message. .RT .sp 1P .LP 5.1.1 \fIISDN to PSTN direction\fR .sp 9p .RT .PP In the ISDN to PSTN direction, a call originating from an ISDN access encounters ISDN to PSTN interworking in the following cases: .RT .LP i) the call destination is on a PSTN access; .LP ii) interworking with a non\(hyISUP signalling system is encountered. .bp .ce \fBH.T. [T10.335]\fR .ce TABLE\ 7/I.335 .ce \fBElements and parameters in routing process\fR .ce (Note\ 1) .ps 9 .vs 11 .nr VS 11 .nr PS 9 .TS center box; cw(108p) | cw(30p) sw(30p) sw(30p) sw(30p) , ^ | c | c | c | c. { Generic list of information which may be required for call routing } { Information to be taken into account for routing purposes at: } Originating local exchange National transit exchange International exchange (ISC) Terminating local exchange _ .T& lw(108p) | cw(30p) | lw(30p) | lw(30p) | lw(30p) . { a) Calling customer's subscription parameters } X _ .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | lw(30p) . b) Incoming route X X _ .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . { c) Called number (including NPI/TON information, if present) } X X X X _ .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . Destination network X X X _ .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . { d) Basic service request \(em bearer capability (BC) } X _ .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . { e) Transmission medium requirement (TMR) } Generated X X (Note 2) Terminated _ .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . { f) User service information (USI) } Generated X X (Note 2) _ .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . { g) Supplementary service request } X (Note 3) _ .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . h) ISUP preference indicator Generated X X Terminated _ .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . { i) Environment of the connection } X _ .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . { j) Network management conditions } X X X _ .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . k) Transit network selection X X _ .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . l) Connection history Generated X X Terminated _ .T& lw(108p) | cw(30p) | cw(30p) | cw(30p) | cw(30p) . m) Time of day X X X .TE .LP \fINote\ 1\fR \ \(em\ This table identifies the elements and parameters normally used to route calls. The use of other elements and parameters is not precluded for special circumstances at any routing stage. .LP \fINote\ 2\fR \ \(em\ The USI parameter field containing the BC information element may be processed if necessary to regenerate the required TMR value capable of supporting the requested service. For calls where BD\ =\ speech or 3.1\ kHz audio, between A and \(*m\(hylaw networks the BC would be modified (by the \(*m\(hylaw international gateway) accordingly. .LP \fINote\ 3\fR \ \(em\ The supplementary service request may influence the value of the ISUP preference indicator. .nr PS 9 .RT .ad r \fBTableau 7/I.335 [T10.335], p. 25\fR .sp 1P .RT .ad b .RT .LP .rs .sp 3P .ad r Blanc .ad b .RT .LP .bp .PP On ISDN to PSTN calls, the call is routed as in an ISDN up to the interworking point. The routing decision is performed at the interworking point. This decision is generally based on information available in the ISUP initial address message. If the interworking point is a transit CRF (national or international) where interworking with a non\(hyISUP signalling system is encountered, signalling interworking (ISUP to/from non\(hyISUP) is also performed. If the call can proceed to the PSTN, call establishment continues using normal routing procedures within the PSTN from the interworking point onwards. .PP On ISDN to PSTN calls, progress indications are returned via S.S. No.\ 7 ISUP and the procedures of Q.931 to the ISDN origination as soon as interworking with the PSTN is encountered. .RT .sp 1P .LP 5.1.2 \fIPSTN to ISDN direction\fR .sp 9p .RT .PP In the PSTN to ISDN direction, a call encounters PSTN to ISDN interworking in the following cases: .RT .LP i) the call destination is on an ISDN access; .LP ii) interworking with an ISUP signalling system is encountered. .PP In the general case, a call originating from a PSTN access is assumed by the network to be either a voice call or modem\(hyderived voice\(hyband data call; these two call types are indistinguishable. On PSTN to ISDN calls, the call is routed using normal PSTN routing procedures up to the interworking point. At the interworking point the call is routed in the ISDN and offered to the destination as a \*Q3.1\ kHz audio\*U call accompanied by an appropriate Q.931 progress indication. .PP For some cases, the selection of 3.1\ kHz audio may be inappropriate. For example, for PSTN\(hyISDN data interworking using the 64\ kbit/s bearer service, refer to Recommendation\ I.231. Various selection mechanisms are contained in Recommendation\ I.515. The routing impacts are for further study. .PP If the interworking point is a transit CRF (national or international) where interworking with an ISUP signalling system is encountered, signalling interworking (non\(hyISUP to/from ISUP) is performed at this interworking point. .RT .sp 1P .LP 5.2 \fIISDN\(hyPSPDN interworking\fR .sp 9p .RT .PP Routing implications of ISDN\(hyPSPDN interworking are for further study. .RT .sp 1P .LP 5.3 \fIISDN\(hyCSPDN interworking\fR .sp 9p .RT .PP Routing implications of ISDN\(hyCSPDN interworking are for further study. .RT .sp 1P .LP 5.4 \fIISDN\(hyISDN interworking over concatenated networks\fR .sp 9p .RT .PP Network concatenation occurs when an existing network (e.g.\ PSTN, CSPDN, PSPDN) provides a connection between the originating and terminating ISDNs. The routing implications of network concatenation scenarios are for further study. .RT .LP .rs .sp 10P .ad r Blanc .ad b .RT .LP .bp .LP \fBMONTAGE: PAGE 110 = PAGE BLANCHE\fR .sp 1P .RT .LP .bp