WPCL 2BJ|x ` H   x|@  6'6' O  `  @  <AP IX147E OO  `  @  <AP IX147E OI (3296) I (3296)    4.HRecommendation I.515 -PARAMETER EXCHANGE FOR ISDN INTERWORKING 1.HGeneral 1.1HScope   HThe objective of this Recommendation is to provide overall parameter exchange principles and functional descriptions for ISDN interworking. This Recommendation describes the principles for parameter exchange mechanisms. It   is recognized that depending on the available (endtoend) signalling capability, the exchange of parameters may use either out or inband procedures. HParameter exchange may be necessary to establish compatible interworking functions for a variety of applications. Typical examples where parameter exchange takes place include, terminal adaption compatibility establishment, modem type selection and voice encoding compatibility establishment. This does not imply, however, any requirement for an ISDN to support network based modem interworking. HFigure 1/I.515 illustrates several voice and data applications, supported by different networks and mechanisms. Parameter exchange may be necessary where interworking between different terminals or networks (as per other Recommendations) is required. Note Where interworking procedures exist, the appropriate references are made herein. M = MODEM IWF = INTERWORKING FUNCTION (May TA(c) = TA WITH CODEC include: Physical Requirements, Signalling Requirements, Terminal Adaptation Modulation, etc.) JFIGURE 1/I.515 Q Notes to Figure 1/I.515 HH 1. IWFs may be located: Hwithin the network(s), Hseparate to the network(s), Hwithin the customer's premises.  x  2. The requirement for interworking between terminals may not be inferred Hfrom Figure 1. 3. Figure 1/I.515 is not exhaustive. 1.2HDefinitions and abbreviations HUse is made of the following terms within this Recommendation. These terms do not necessarily refer to any existing protocol structure rather, they define information requirements in the context of this Recommendation. H Bearer capability information HX Specific information defining the lower layer characteristics of the network. H Low layer compatibility information HX Information defining the lower layer characteristics of a TE or TA. H High layer compatibility information HX Information defining the higher layer characteristics of a terminal. H Protocol identifier HX Information defining the specific protocols used by a terminal to support data transfer. H Progress indicator HX Information supplied to indicate to the ISDN terminal that interworking has occurred. H Outband parameter exchange HX Information exchanged via signalling channels which are not within the channel used for user information transfer. H Inband parameter exchange HX Information exchanged using the same information channel as that used for the user information transfer. 2HPrinciples 2.1HTypes of parameter exchanges HThree types of parameter exchange need to be considered: Hi)  endtoend, outband as shown in Figure 2/I.515. H a)hParameter exchange is accomplished via the D Channel and Signalling System No. 7. MFIGURE 2/I.515 T @Outband parameter exchange via D Channelă Hii)  endtoend, in band as shown in Figure 3/I.515. H a)via a transit network Note 64 kbit/s connection type is assumed for ISDN H b)direct through an extended IDN Note The extended IDN shown has 64 kbit/s transmission channel (see I.231), however its signalling system is not compatible with that of the ISDN. MFIGURE 3/I.515 T GInband parameter exchangeă Hiii) Parameter exchange to select IWFs MFIGURE 4/I.515 HThe inband parameter exchange occurs after the establishment of an endtoend connection and may provide for establishment of compatibility between the end points, based on characteristics such as protocol, rate adaption scheme and modem type. 2.2HRelationship of parameter exchange to call establishment HParameter exchange may occur: Hi)  prior to Call Establishment (Call Negotiation); HX In this case parameter exchange will occur using outband techniques. Hii)  after Call Establishment, prior to information transfer; HX In this case parameter exchange may occur using either inband or outband techniques. Hiii) during the information transfer phase of the call. HX In this case parameter exchange will occur using either outband or inband techniques. 2.2.1HParameter exchange prior to Call Establishment (Call Negotiation) HCall Negotiation may be used to satisfy a number of basic call requirements in ISDN. In addition, call negotiation may be necessary for interworking as described in I.510 (between terminals, services and networks) for: Ha)  Terminal Selection (see I.333, Q.931, Q.932); Hb)h  selection of interworking requirements when interworking between ISDN and other dedicated networks is identified (e.g. modem type); Hc)h  the appropriate selection of network (ISDN or other network) functions to support the service required (e.g., use of call progress indicator); Hd)h  the selection of network functions when interworking between incompatible terminals is identified or when interworking of different services is required. HEach of the requirements a) through d) above are necessary during the call establishment phase, therefore, call or service negotiation mechanisms should be k+ included within basic call establishment procedures. Further study is required. 2.2.1.1 Call Negotiation types HThree types of Call Negotiation are currently envisaged. H Bearer capability (BC); H Low layer compatibility (LLC); H High layer compatibility (HLC). HThe relationship of these information elements to parameter exchange functions is for further study. Note BC, LLC, HLC are information elements defined in Recommendation Q.931. 2.2.1.3 Transfer of information HThe transfer of information associated with Call Negotiation is illustrated in Figure 4/I.515. Note 1 The examination of LLC by the network when the IWF is not an addressed entity, is for further study. Note 2 The IWF can be distributed (see I.510 for definition of IWF). Note 3 When the IWF is on the customer premises, examination of additional information elements to satisfy basic call requirements may be appropriate (e.g., subaddress called party ID). MFIGURE 5/I.515 2.2.2HAfter call establishment and prior to information transfer phase HThis parameter exchange may be necessary when signalling to allow adequate compatibility checking during the call setup phase is not available, or when additional capability checking is required due to characteristics of the terminals which are not defined in call establishment procedures. HWhen outband parameter exchange is used refer to section 3.1.2. HWhen inband parameter exchange is used refer to section 3.2.1. 2.2.3HDuring information transfer phase HThis parameter exchange may be necessary when configurations change during the information transfer phase (e.g., maintenance, subchannel information). Detailed aspects are for further study. 3.HParameter exchange procedures 3.1HOutband parameter exchange 3.1.1HPrior to call establishment HRefer to Recommendation Q.931 and Q.764. Other protocols are for further study. 3.1.2HAfter call establishment prior to information transfer phase HRefer to Q.931 and Q.764. 3.1.3HDuring information transfer phase HRefer to Q.931 and Q.764. 3.2HInband parameter exchange 3.2.1HAfter call establishment prior to information transfer HThe following parameter exchange sequence identifies one method of establishing compatibility during interworking between an ISDN and existing networks and between ISDNs. H call establishment phase (e.g. refer to Q.931 and Q.764); H originating terminal changes from idle condition to busy E FFH!Gcondition; H connection enters parameter exchange phase; H connection enters information transfer phase. 3.2.1.1 Voice services HRefer to Recommendation G.725. 3.2.1.2 Parameter exchange mechanism for terminal adaption protocol H8"Iidentification HSome Inband Parameter Exchange (IPE) Procedures are in existence, e.g., Appendix 1 of Recommendation V.110. Two circuit mode terminal adaption procedures are emerging within CCITT (i.e., I.463/V.110 and V.120). In many countries, the Terminal Adaptor (TA) design may not be controlled by the administration/RPOAs so that special forms of terminal adaption may be deployed. To support multiple forms of terminal adaption in a mixed ISDN/nonISDN network, terminal adaption implementations which support multiple terminal adaption protocols will be required. For use with such implementations, a method is needed for some applications to identify the specific terminal adaption protocol to be used by the multifunctional adaptor (MTA) devices. This will allow the terminal equipment (or appropriate network component), to release the call where compatibility cannot be achieved, or to request the network to provide an appropriate interworking function. examples, for any given instances of communication, different parameters may be required. 4.1HNumbering parameters H subscriber number; H subaddress; H terminal selection (see Recommendation I.333). 4.2HProtocol control parameters HProtocol control parameters can be used to identify the protocol supported. An example is the terminal adaption protocol supported, such as V.110, V.120. 4.3HDTE/DCE configuration parameters HThe protocol identification is performed during the following three steps after the call is placed by using the normal call establishment procedures: OAPPENDIX B T ETA protocol self identificationă HThis appendix discusses guidelines for selfidentification procedures that may be used by multiprotocol terminal adaptor (MTA) implementations in selecting the protocol to be used on an individual connection. It is assumed that the multiprotocol terminal adaptor supports the procedures of I.463(V.110) and I.465 (V.120). Where outband signalling is available multiprotocol terminal adaptors should function in accordance with the protocol negotiated during call setup. Selfidentification procedures are only applicable where such signalling capabilities are not available. MTAs intended to interwork with Uniprotocol TAs HThe MTA may initiate transmission as if it were a uniprotocol TA conforming to any of the capabilities provided. The received signals would be examined by the MTA and the MTA should revert to transmission in accordance with the procedures of the protocol of the uniprotocol TA as indicated by the received signals. If compatibility is not achieved it would provide a disconnect. HIt is noted that there are a range of capabilities that may be implemented in TAs conforming to either I.463 (V.110) or I.465 (V.120). For distinguishing the capabilities of the different TA protocols, an MTA should follow the procedures specified in the individual Recommendations. MTAs intended to interwork with other MTAs HThe MTA should initiate transmission, following the connect indication, in accordance with Recommendation I.465 (V.120). Note Self identification can be extended to accommodate multiple protocols. It is only necessary to define the priority for the use of each protocol and a retry procedure. The general rule would be that an MTA would always initiate transmission assuming the protocol of the highest priority supported that has not been tried. The MTA would always delay disconnect, when the received signal is not recognized, for a period long enough for the necessary number of retries (this is protocol and implementation dependent see, e.g., I.463 (V.110) and I.465 (V.120). 8I (3296) CCITT\APIX\DOC\147E2.TXS 88I (3296) CCITT\APIX\DOC\147E2.TXS 8  OAPPENDIX C T @Parameter exchange for selection of IWFsă FISDN PSTN data interworkingă   HHNote The preferred methods for modem selection for ISDN PSTN calls are for further study.  `   H C.1.1HMechanisms which do not require the ISDN user to have prior knowledge of the modem characteristics of the PSTN user. HHC.1.1.3 Registration   HHThe DTE/DCE characteristics of the PSTN user are registered with the ISDN.  `   H C.1.2HMechanisms which may require the ISDN user to have prior knowledge of modem characteristics of the PSTN network user. C.1.2.1 Default Identification HAny DTE uses the same default modem characteristics. C.1.2.2 ISDN user selects the modem dynamically.   HHUsing available parameter exchange mechanisms (i.e. SN, LLC/BC, IPE) the user selects specific TA/modem characteristics at the IWF.  `  C.2HISDN Bearer Capabilities for interworking. C.2.1H3.1 kHz ISDN Bearer Capability.  8 HHX The IWF may pass parameters (e.g. LLC) to the called user when establishing the ISDN portion of the call.  `    HHX the local exchange will insert the presubscribed modem type in the path.  `    HX multistandard modem at the IWF. The appropriate modem is inserted in the endtoend path.