Internet Standards/CD2.mdf/ccitt/1992/i/i257.asc

Text File | 1993-06-28 | 16KB | 876 lines

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 Rec-
ommendationI.130 using the means given in RecommendationI.210.



    Supplementary services are described by a prose definition and description (step 1.1) and by a dynamic description
(step1.3). The application of the attribute technique, as defined in RecommendationI.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 128octets per message as a maximum.



Note - During an interim period of time, some networks may support 32octets on one or more of the services,
32octets will always be supported. Restrictions may apply to calls requesting UUI of more than 32octets. 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 ter-
minating 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 service1 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 service1 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 service2 should be used in point-to-point configurations. In a multipoint configuration service2 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



    Services1, 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 combi-
nation.



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. Service3 may be requested by the calling or as a service provider option, by the called user at callsetup
or during the setup or active state of the call.



Note - Depending on the network connection selected at call setup, the request for service3 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. Service1 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 service3 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 suffi-
cient signalling connectivity to allow the transfer of UUI. Confirmation of delivery is not provided by the network. The net-
work 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 reasons2 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 with-
out 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 service2 and service3 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 theservice 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 section2 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 Figure1/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













ûûûûûûûûûûûûûûû