ANNEX A
(to Recommendation Q.730)
Signalling procedure for the explicit invocation of
user–to–user signalling services 1, 2 and 3
A.1	User–to–user signalling service
A.1.1	General description of user–to–user service
	See §§ 2.1 and 2.2.
A.2	Procedures for user–to–user signalling associated with circuit switched calls
A.2.1	User–to–user signalling, Service 1
A.2.1.1	General characteristics
	Service 1 allows users to communicate with user–to–user signalling by transferring user–to–user information within ISDN user part messages during the call set–up and clearing phases. The user–to–user signalling service provided is not a guaranteed service. If for any reason the combination of the basic plus supplementary service information causes the overall maximum length of the message to be exceeded then if the User–to–user Signalling Service 1 is included the service should be rejected.
A.2.1.2	User–to–user signalling, Service 1 – Explicit service request
	Procedures for call set–up are as described in Recommendation Q.764, § 2 with the following changes:
	On call set–up, the Initial Address Message will contain the user–to–user indicators parameter with Service 1 indicated as “requested essential/not essential” and Service 2 and 3 indicated as “no information”. The service request will be received from call control at the originating exchange and will be passed to the call control at the terminating exchange.
	If the called user or network can support the transfer of user–to–user, a Service 1 acceptance will be returned to the originating exchange in an Address Complete or Call Progress Message for the point–to–point case or the Answer or Connect Message in the point–to–multipoint case with the indication “Service 1 provided” in the user–to–user indicators parameter. Services 2 and 3 will be indicated as “no information” in the user–to–user indicators parameter. These explicit indications shall be forwarded to the call control at the originating exchange.
	User–to–user information may be contained in any of the messages that may be transferred in the call set–up phase.
A.2.1.3	Interworking
	In the case of interworking with a non–ISDN network, the “interworking” protocol control information will be returned to the originating exchange in the first appropriate message, e.g., and Address Complete Message. Two ISDN networks that interwork may have to retain knowledge of the service request until it is clear whether both can support the service.
A.2.1.4	Rejection of explicit service requests
	If the called user or network does not understand the Service 1 request then the Address Complete or Call Progress Message returned to the originating exchange shall not include either a Service 1 acceptance or rejection. This type of response will be taken as an implicit rejection of Service 1. (Note – The Study Group XVIII service description does not allow this implicit rejection.)

	If the network or called user cannot support Service 1, and it was requested with a non–essential indication, a Service 1 rejection indication is returned in the Address Complete or Call Progress Message with the indication “Service 1 not provided” in the user–to–user indicators parameter.
	If the Service 1 request is indicated as essential and the called user or network cannot support it a Release Message is sent with cause code 50, “requested facility not subscribed”, cause code 29, “facility rejected by the network” or cause code 69, “requested facility not implemented” and the diagnostic containing the user–to–user indicators parameter.
A.2.1.5	User–to–user signalling in the call clearing phase
	A user–to–user information parameter may be included in the Release Message. The user–to–user information parameter received at the distant exchange in the Release Message is passed to the call control for the remote user. In the case of simultaneous clearing of the call the Release Message may not reach the distant local exchange and the user–to–user information will be lost.
A.2.2	User–to–user signalling, Service 2
A.2.2.1	General characteristics
	Service 2 allows the users to communicate with user–to–user signalling by transferring up to two user–to–user information messages in each direction during the call setup phase. As a network option, user–to–user information may de delivered to the called party after the call is answered to accommodate situations where the information was sent at approximately the same time as the call was answered. This service allows either an implicit or explicit rejection.
	Service 2 is only applicable when a point–to–point configuration exists at the user–network interface at the terminating exchange.
A.2.2.2	Call set–up
	Procedures for call set–up are as described in Recommendation Q.764, § 2 with the following changes:
	On call set–up the Initial Address Message will contain the user–to–user indicators parameter with Service 2 indicated as “requested essential/not essential” and Services 1 and 2 indicated as “no information”1). The service request will be received from call control. The service request will be passed to call control at the terminating exchange.
	If the called user or network can support the transfer of user–to–user information, a Service 2 acceptance will be returned to the originating exchange in an Address Complete or Call Progress Message with the indication “Service 2 provided” in the user–to–user indicators parameter2). Services 1 and 3 will be indicated as “no information” in the user–to–user indicators parameter. These explicit indications shall be forwarded to the call control at the originating exchange.
A.2.2.3	Service rejection
A.2.2.3.1	Point–to–point calls
	If the called user or network does not understand the Service 2 request then the Address Complete or Call Progress Message returned to the originating exchange shall not include either a Service 2 acceptance or rejection. This type of response will be taken as an implicit rejection of Service 2.
	If the network or called user cannot support Service 2, and it was requested with a non–essential indication, a Service 2 rejection indication is returned in the Address Complete or Call Progress Message with the indication “Service 2 not provided” in the user–to–user indicators parameter3). (Note – The Study Group XVIII service description does not allow this implicit rejection.)
	If the Service 2 request is indicated as essential and the called user or network cannot support it a Release Message is sent with cause code 50, “requested facility not subscribed” cause code 29, “facility rejected by the network” or cause code 69, “requested facility not implemented” and the diagnostic containing the user–to–user indicators parameter.
A.2.2.3.2	Point–to–multipoint calls
	If the call is point–to–multipoint then Service 2 cannot be provided at the called party because the user is not identified until the user is connected. Consequently, Service 2 must be rejected using the point–to–point procedures. The cause value in this case is code 88, “incompatible destination”.
A.2.2.4	Interworking
	In the case of interworking with a non–ISDN network, the “interworking” protocol control information will be returned to the originating exchange in the appropriate message, e.g., an Address Completed Message. Two ISDN networks that interwork may have to retain knowledge of the service request until it is clear whether both can support the service.
A.2.2.5	Transfer of messages containing user–to–user information
	Once acceptance of Service 2 has been transmitted across the network, both of the involved users can transfer user–to–user information between themselves. Within the network the user–to–user information parameter will be carried in a User–to–user Information Message. The network provides for the transfer of these messages from the calling to the called side and vice versa.
	The User–to–user Information Message format can be found in Table 20/Q.763.
	If the Service 2 is provided, no more than two User–to–user Information Messages carrying user–to–user information parameters may be transmitted in each direction during the call set–up phase. If more than two messages are received during call set–up, the additional messages are discarded. If only Service 2 has been requested, one of the messages may also be received and passed after the answer state has been reached.
	No transfer of user–to–user information can occur until the service is acknowledged.
A.2.3	User–to–user signalling, Service 3
A.2.3.1	General characteristics
	Service 3 allows the users to communicate with user–to–user signalling by transferring User–to–user Information Messages in each direction during the active phase of the call. This service allows either an implicit or explicit rejection.
	Service 3 allows the service to be requested either during call set–up or after call set–up. However, Service 3 should not be requested after call set–up if it has been rejected during the call set–up phase.
A.2.3.2	Service 3 requested during call set–up
	Procedures for call set–up are as described in Recommendation Q.764, § 2 with the following changes:
	On call set–up the Initial Address Message will contain the user–to–user indicators parameter with Service 3 indicated as “requested essential/not essential” and Services 1 and 2 indicated as “no information”4). The service request will be received from call control at the originating exchange. The service request will be passed to the call control at the terminating exchange.
	If the called user or network can support the transfer of user–to–user information, a Service 3 Acceptance will be returned to the originating exchange in an Answer or Connect Message with the indication “Service 3 provided” in the user–to–user indicators parameter5). Services 1 and 2 will be indicated as “no information” in the user–to–user indicators parameter. These explicit indications shall be forwarded to the call control at the originating exchange.

A.2.3.3	Rejection of Service 3 when requested during call set–up
	If the called user or network does not understand the Service 3 request then the Address Complete Call Progress Message, Answer or Connect Message, returned to the originating exchange shall not include either a Service 3 acceptance or rejection. This type of response will be taken as an implicit rejection of Service 3.
	If the network or called user cannot support Service 3, and it was requested with a non–essential indication, a Service 3 rejection indication is returned in the Address Complete, Call Progress Message, Answer or Connect with the indication “Service 3 not provided” in the user–to–user indicators parameter6). (Note – The Study Group XVIII service description does not allow this implicit rejection.)
	If the Service 3 request is indicated as essential and the called user or network cannot support it a Release Message is sent with cause code 50, “requested facility not subscribed”, cause code 29, “facility rejected by the network” or cause code 69, “requested facility not implemented” and the diagnostic containing the user–to–user indicators parameter.
A.2.3.4	Service 3 requested after call set–up
	After call set–up has been completed either the calling or called party may request to transfer Service 3 information. On reception of the request from call control the ISDN User Part sends a Facility Request Message containing the facility indicator parameter indicating user–to–user service and a user–to–user indicators parameter requesting Service 3 to the distant local exchange using the appropriate transport method. The facility request will contain the user–to–user indicators parameter with Service 3 indicated as “requested essential/not essential” and Services 1 and 2 indicated as “no information”7). On receipt of the Facility message at the distant exchange call control will be notified which will then notify the remote user. If the user wishes to support Service 3 during the active phase, a Service 3 acceptance will be returned to call control. On notification of the acceptance by call control the ISDN User Part will generate a Facility Accepted Message with the indication “Service 3 provided” in the user–to–user indicators parameter8). Services 1 and 2 will be indicated as “no information” in the user–to–user indicators parameter. On the receipt of the message this explicit acceptance indication shall be forwarded to call control which will then notify the requesting user.
A.2.3.5	Rejection of Service 3 when requested after call set–up
	If the requested user or network does not understand the Service 3 request then no message is returned. This response shall be taken as an implicit rejection of the service request.
	If the network or requested user cannot support Service 3, and it was requested with a non–essential indication, a Service 3 rejection indication is returned in the Facility Reject Message with the indication “Service 3 not provided” in the user–to–user indicators parameter.
	If the call control does not indicate acceptance or rejection the network shall not return any explicit rejection to the exchange.
	Note 1 – The Stage 1 service description does not allow this implicit rejection.
	Note 2 – The handling of essential/non essential Service 3 request is not yet consistent with the State 1 service description.

A.2.3.6	Interworking
	In the case of interworking with a non–ISDN network an “interworking” protocol control indicator will be returned to the originating exchange in the first appropriate message9). If Service 3 was requested after call set–up, a Facility Reject Message is returned9). Two ISDN networks that interwork may have to retain knowledge of the service request until it is clear whether both can support the service.
A.2.3.7	Transfer of messages containing user–to–user information
	Once acceptance of Service 3 has been transmitted across the network, both of the involved users can transfer user–to–user information between themselves. Within the network the user–to–user information parameter will be carried in a User–to–user Information Message. The network provides for the transfer of these messages from the calling to the called side and vice versa.
	The User–to–user Information Message format can be found in Table 20/Q.763.
A.2.4	Requesting user–to–user signalling Services 1, 2 and 3
	This section describes procedures for requesting Services 1, 2 and 3.
	Note – User–to–user Service 1 implicit request/response procedures are also found in § 2.2.1. Only explicit Service 1 requests may follow the procedure in this section.
A.2.4.1	Call establishment
	Procedures for call establishment are described in §§ A.2.1.2, A.2.2 and A.2.3.2 with the following modifications:
	On service request one user–to–user indicators parameter will be sent with each service being indicated as “requested, essential/non essential”.
	If the called user can support the indicated services, then all three services will be indicated as “provided” in the user–to–user indicators parameter in the Address Complete or Call Progress Message. Alternatively, the Address Complete or Call Progress Message may indicate “Service 3, no information” and “Service 3 provided” in the Answer or Connect Message as provided in § A.2.3.2. In the case that the call is to multi–point users, the acknowledgement of Services 1 and 3 shall be delayed until the Answer or Connect Message is sent.
A.2.4.2	Service rejection
	If the called user or network does not understand the service requested, then the Address Complete, Call Progress, Answer or Connect Messages returned will not include either service(s) acceptance or rejection. This type of response will be taken as an implicit rejection of all services.
	If the called user or network does not understand a specific service request, that specific service is implicitly rejected following the procedures of §§ A.2.1.4, A.2.2.3 and A.2.3.3. Alternatively, if the network or called user cannot support one or more service requests and the service requests were indicated as non–essential, then the rejection may be provided in the Address Complete or Call Progress Messages. (In the case of a call to multi–point users only Service 2 may be rejected in this way, Service 1 and 3 must be rejected in the Answer or Connect Message if the called user is furnishing the rejection.) The services may also be rejected following the procedures of §§ A.2.1.4, A.2.2.3 and A.2.3.3.
	If any or all of the services requested is indicated as essential and the called user or network cannot support one or more of the services, a Release Message is sent with cause code 29, “facility rejected by the network”, cause code 50, “requested facility not subscribed”, or cause code 69, “requested facility not implemented” and the diagnostic containing the user–to–user indicators parameter.

	If the call control does not indicate Service 1, 2 or 3 acceptance or rejection prior to the sending of the Address Complete, Call Progress, Answer or Connect Message, then no indication of service acceptance or rejection shall be returned for the specific service(s).
A.2.4.3	Interworking
	In the case of interworking with a non–ISDN network, the “interworking” protocol information will be returned to the originating exchange in the first appropriate message, e.g., an Address Complete Message. Two ISDN networks that interwork may have to retain knowledge of the service request until it is clear whether both can support the services.
A.2.4.4	Transfer of User–to–user Information Messages
	The procedures for the transfer of User–to–user Information Messages is covered in §§ A.2.2.5 and A.2.3.7.
A.2.5	User–to–user information transport methods for Services 2 and 3
	The Transport methods for Services 2 and 3 may be found in § 3 of Recommendation Q.764.
A.2.6	Message flow diagrams
	The message flow diagrams are shown in Figures A–1/Q.730 to A–7/Q.730.
	For User–to–user Signalling Service 2 and 3 the figures only show ISDN user part messages required for basic call control and user–to–user signalling and are not meant to imply any particular transfer method. The parameters and indicators shown are for the User–to–user Signalling Service only, i.e. any parameters or message associated with the various transport methods are not shown.
	The following notes apply to Figures A–1/Q.730 to A–7/Q.730:
	Note 1 – In cases where an ALERTING indication is carried by a Call Progress Message the user–to–user indicators parameter and/or the user–to–user information parameter may also be transported in the Call Progress Message.
	Note 2 – In cases where the called user is an automatic answering terminal, user–to–user indicators parameter and/or the user–to–user information parameter may be transported in a Connect Message.
	Figure A–1/Q.730 shows a successful use of user–to–user Signalling Service 1 when explicitly requested in a point–to–point configuration.
	Figure A–2/Q.730 shows both the successful and unsuccessful use of user–to–user Signalling Service 2 in a point–to–point configuration.
	Figure A–3/Q.730 shows an unsuccessful use of user–to–user Signalling Service 2 in a point–to–multipoint configuration. This unsuccessful case is shown because the network reactions will be the same in all similar cases.
	Figure A–4/Q.730 shows both successful and unsuccessful cases for user–to–user Signalling Service 3 when the service is non–essential in a point–to–point configuration.
	Figure A–5/Q.730 shows a successful use of user–to–user Signalling Service 3 after the call is active in a point–to–point configuration.
	Figure A–6/Q.730 shows a successful use of user–to–user signalling Services 1, 2 and 3 and where all services are non–essential in a point–to–point configuration.
	Figure A–7/Q.730 shows successful use of user–to–user signalling Services 1 and 3 and unsuccessful use of Service 2 in a point–to–multipoint configuration. It should be noted again that Service 2 will not work in a point–to–multipoint configuration.

	The following abbreviations are used in the figures:

Abbreviations	 User–to–user Indicator Values	
 ni	 no information	
 rne	 requested, non essential	
 re	 requested, essential	
 p	 provided	
 np	 not provided	
 Abbreviations	 Parameter name	
 UUI	 user–to–user information	
 UUI ind.	 user–to–user indicators	
 Abbreviations	 Message name	
 ACM	 Address Complete	
 ANM	 Answer	
 FAR	 Facility Request	
 FAA	 Facility Accepted	
 IAM	 Initial Address	
 REL	 Release	
 RLC	 Release Complete	
 USR	 User–to–user Information	

	The messages shown with dashed lines are not part of the ISDN User Part protocol and are for information only. For detailed information on the access protocol user–to–user procedures the ISDN access protocol Recommendation Q.931 should be examined.
Figure A–1/Q.730 - T1115880-88

Figure A–2/Q.730 - T1115890-88

Figure A–3/Q.730 - T1115900-88

Figure A–4/Q.730 - T1115910-88

Figure A–5/Q.730 - T1115920-88

Figure A–6/Q.730 - T1115930-88

Figure A–7/Q.730 - T1115940-88

A.2.7	Interaction with other supplementary services
A.2.7.1	Call forwarding services
	Interactions with the call forwarding services are shown in the call forwarding protocol sections.
A.2.7.2	Call waiting service
	Interactions with the call waiting service are shown in the call waiting protocol sections. (Call waiting is for further study.)
A.2.7.3	Other services
	There are no known interactions with services other than those listed.
A.2.8	State transition diagrams
	The state transition diagrams may be found in the Stage 2 description of the User–to–user Service.