Recommendation I.257 - Additional Information Transfer Supplementary Service The purpose of this Recommendation is to provide the stage 1 description of the method defined in Recommendation I.130 using the means given in Recommendation I.210. Supplementary services are described by a prose definition and description (step 1.1) and by a dynamic description (step 1.3). The application of the attribute technique, as defined in Recommendation I.140, for supplementary technique is for further study. This Recommendation describes the following Additional Information Transfer Supplementary service. I.257.1 User-to-User Signalling (UUS) 1. Definition The user-to-user signalling (UUS) supplementary service allows an ISDN user to send/receive a limited amount of information to/from another ISDN user over the signalling channel in association with a call to the other ISDN user. Note - These procedures are applicable to user-to-user information (UUI) transfer in association with a circuit-switched telecommunication service only. Procedures to permit UUI transfer in association with other types of calls (e.g., packet bearer services) need to be investigated. 2. Description 2.1 General description User-to-user signalling (UUS) allows the user to send/receive a limited amount of user generated information to/from another user-network interface. This information is passed transparently (i.e. without modification of contents) through the network. Normally, the network will not interpret or act upon this information. Services 1, 2 and 3 allow the transmission of 128 octets per message as a maximum. Note - During an interim period of time, some networks may support 32 octets on one or more of the services, 32 octets will always be supported. Restrictions may apply to calls requesting UUI of more than 32 octets. Limitations are also placed on the amount of information a user is permitted to transfer in a given time period (e.g. limitations can be placed on the number of messages transmitted or the throughput can be limited). The user can transfer UUI in different phases of the call depending on the service(s) to which the user subscribes. These are: - Service 1: The transfer of UUI during the setup and clearing phases of a call, with UUI embedded within call control messages; - Service 2: The transfer of UUI during the setup phase of call, transferred independently of call control messages. From the sender's point of view UUI is sent prior to the active phase of the call (i.e., prior to the acceptance of the call at the distant exchange). This same UUI may as a service provider option be received by the terminating exchange and delivered to the user during the active phase of the call; - Service 3: During the active phase of a call, transferred independently of call control messages. In a point-to-multipoint arrangement at the called party the following service 1 UUI transfer is allowed: - in the forward direction: UUI will only be accepted if it is contained in either the initial setup or the first clearing message. In this case of premature clearing, UUI will be delivered to terminals, which have at this point in time already acknowledged the call; - in the backward direction: UUI will only be accepted by the network at the called interface from a terminal which is selected (Note). This means that a terminal in a multipoint configuration at the called interface is not allowed to send UUI service 1 information with the alerting indication to the calling party; - if the call never reaches the active phase (e.g. in case of call rejection), and if multiple responses are received, only one UUI which was sent from the called party will be transferred to the calling party; Note - A selected terminal is the terminal behind the called interface that the service provider considers or elects as the terminal to be in the active phase of a call. Preferentially, UUS service 2 should be used in point-to-point configurations. In a multipoint configuration service 2 may lead to an inconsistent view from a user's perspective. 2.2 Specific terminology None identified. 2.3 Qualifications on the applicability to telecommunication services Restrictions can only be identified for telecommunication services, which are based on the X.31 packet mode bearer services and its future enhancement. 3. Procedures 3.1 Provision/withdrawal Services 1, 2 and 3 must be subscribed to by the calling user to whom billing will apply. It is a service provider option whether these component services are offered to the user as separate supplementary services or in any particular combination. 3.2 Normal procedures 3.2.1 Activation/deactivation/registration UUS services 1 and 2, must be requested by the calling user at the setup of the call if UUI transfer is desired in either direction. Service 3 may be requested by the calling or as a service provider option, by the called user at call setup or during the setup or active state of the call. Note - Depending on the network connection selected at call setup, the request for service 3 during the setup or active phase of the call may fail. Once a UUS service is activated (Note), the network will accept UUI in both directions according to the subscription of the calling user. Note - Activation means request for UUS. Invocation means submission of UUI. Services 2 and 3 must be explicitly requested. Service 1 may be explicitly or implicitly requested. The service is implicitly requested when UUI is included in the call request (i.e. the service is requested at the same time it is invoked). On a per call basis the calling user should be able to specify the desired UUS service(s) according to the service options offered by the service provider. As an option, at call setup, users should be able to specify whether the requested UUS service(s) is required for the call, i.e. if the call should be completed or not if UUI cannot be passed. If the UUI required indication is given by the user, the call will not be completed if UUI cannot be passed to the destination user. If the UUI-required indication is not given by the user, the call will be completed even if UUI cannot be passed. If UUS service 3 is requested during the call it cannot be requested as "UUI required". For services 2 and 3 the network will confirm the UUS service request. This confirmation is preceeded by an end-to-end check by the network for service availability. For services 2 and 3 the network should interrogate for the service availability with the destination user. No response from the destination user is taken as a rejection to the UUS request by the network. The network should explicitly indicate to the origination user whether the requested service(s) has been (are) successfully activated or not. In the case of unsuccessful activation, the network should indicate whether the condition is due to unavailability of the destination user or not (section 3.3). Note - The term "originating" and "destination" refer to the origination or destination of the UUS request. When service 1 is explicitly requested, the network will inform the destination user of the request. The destination party should accept or reject the activation as described for services 2 and 3. 3.2.2 Invocation and operation A user wishing to send UUI will be informed by the network as part of normal call establishment if there is not sufficient signalling connectivity to allow the transfer of UUI. Confirmation of delivery is not provided by the network. The network does not expect any confirmation of UUI acceptance from the destination. 3.2.2.1 Service 1 If authorized, an ISDN user may transfer a limited amount of user generated information when inititating, accepting, rejecting, or clearing a call. It is possible for a calling user to request UUI transfer with a call setup and terminate the call before a connection is established. 3.2.2.2 Service 2 Any time after the explicit confirmation of the UUS service request is received from the network, an ISDN user may transfer a limited amount of user generated information (two messages in each direction) to the other user involved in the call. 3.2.2.3 Service 3 If explicit confirmation of the UUS service request has been received from the network, during the active phase of a call an ISDN user may transfer a limited amount of user generated information to the other user on the call. 3.3 Exceptional procedures 3.3.1 Activation/deactivation/registration If the network cannot accept a request for UUI transfer, notification with cause will be returned to the served user. Possible reasons for rejection are: 1) service not subscribed to; 2) calling or called user is not an ISDN user; 3) protocol error; 4) necessary interoffice signalling connectivity does not exist between sending and recieving users; 5) user constraints prohibit activation/invocation of service between calling and called users (e.g. CUG); 6) network congestion. Note - If UUI contained in a setup message cannot be transferred for reasons 2 or 5, notification will not be provided until after the network has received a response to the setup message, since the network does not know a priori whether UUI can be transferred or not. When the invocation of services 2 or 3 is not understood by the service provider or by the called user, no explicit rejection is sent to the calling user. This lack of acknowledgement must be interpreted as a rejection, 3.3.2 Invocation and operation The user may not be able to interpret incoming UUI. In such situations, the user should discard this information without disrupting normal call handling. No specifc signalling is provided by the network to accommodate this situation. UUI sent near or at the end of a call may not reach its destination, e.g. if the called party initiates disconnection procedures prior to the arrival of the UUI. At all other times, however, the network offers high probability that messages will be delivered correctly. Under circumstances of network congestion or failure, the network may discard service 2 and service 3 UUI. Users desiring to have confirmed UUI delivery must employ their own end-to-end protocols (i.e. acknowledgement of receipt by another UUI). In case of excessive UUI length, no truncation is performed by the service provider. UUI information is discarded and the user will be informed. 3.4 Alternative procedures 3.4.1 Activation/deactivation/registration None identified. 3.4.2 Invocation and operation None identified. 4. Network capabilities for charging This Recommendation does not cover charging principles. Future Recommendations in the D-Series are expected to contain that information. It shall be possible to charge the subscriber accurately for the service. 5. Interworking requirements UUI can be delivered only when both users are ISDN subscribers or when a non-ISDN network provides a means of conveying the UUI. 6. Interaction with other supplementary services 6.1 Call Waiting Calling user: any UUI included in the call setup message will be delivered with the call waiting indication. UUI can be sent by the calling user to the called user during the call alerting period. Called user: if a call waiting user also uses UUI, he can include UUI with the rejection of the call. UUI can be sent by the called user to the calling user during the call alerting period. Note - See section 2 for restrictions on point-to-multipoint arrangements. 6.2 Call Transfer See Call Transfer interaction with User-to-User Signalling in I.252.1. 6.3 Connected Line Identification Presentation No impact, i.e. neither supplementary service affects the operation of the other supplementary service. 6.4 Connected Line Identification Restriction No impact, i.e. neither supplementary service affects the operation of the other supplementary service. 6.5 Calling Line Identification Presentation No impact, i.e. neither supplementary service affects the operation of the other supplementary service. 6.6 Calling Line Identification Restriction No impact, i.e. neither supplementary service affects the operation of the other supplementary service. 6.7 Closed User Group No impact, i.e. neither supplementary service affects the operation of the other supplementary service. 6.8 Conference Calling See Conference Calling interaction with User-to-User Signalling. 6.9 Direct Dialling-In No impact, i.e. neither supplementary service affects the operation of the other supplementary service. 6.10 Diversion services 6.10.1 Call Forwarding Busy See Call Forwarding Busy interaction with User-to-User Signalling. 6.10.2 Call Forwarding No Reply See Call Forwarding No Reply interaction with User-to-User Signalling. 6.10.3 Call Forwarding Unconditional See Call Forwarding Unconditional interaction with user-to-user signalling. 6.11 Line Hunting No impact, i.e. neither supplementary service affects the operation of the other supplementary service. 6.12 Three Party Service See Three-Party interaction with UUS in I.254.2. 6.13 User-to-User Signalling Not applicable. 6.14 Multiple Subscriber Number No impact, i.e. neither supplementary service affects the operation of the other supplementary service. 6.15 Call Hold Service See Call Hold Service interaction with User-to-User Signalling in I.253.2. 6.16 Advice Of Charge See Advice Of Charge interaction with User-to-User Signalling in I.256.2. 7. Dynamic description The dynamic description of this service is shown in Figure 1/I.257.1. FIGURE 1/I.257.1 User-to-User Signalling Note 1 - The call is cleared. Note 2 - This service must be requested at call setup by the calling user. Note 3 - This service 3 may be requested at call setup or during the active phase of the call by the calling user and during the active phase of the call by the called user. Note 4 - As an option, at call setup, users should be able to specify whether the requested UUS service is essential or non essential for the call. Note 5 - Service 1 may be explicitly or implicitly requested. Note 6 - The reasons for rejections are given in section 3.3. FIGURE 1/I.257.1 (continued) User-to-User Signalling FIGURE 1/I.257.1 User-to-User Signalling 컴컴컴컴컴컴컴�