Annex A: Signalling System No. 7 signalling procedure for the explicit invocation of user-to-user signalling services 1, 2 and 3.... 59
- 3 -
AP IX-112-E
2. User-to-user signalling service
2.1 General description of user-to-user service
The User-to-user Signalling Supplementary Service(s) provide(s) a means
of communication between two users by using the ISDN User Part or SCCP protocols
defined in Recommendations Q.711-714 and Q.761-764, 766. In order for the
services to be usable, the services also have to be provided in the access protocol.
User-to-user signalling is used to exchange I.257 information between two
users to provide the User-to-user Services described in
Recommendation I.257. This section is specific to Signalling System No. 7 and the general
description for services 1-3 may be found in the last mentioned Recommendation and
the functional description in Recommendation Q.87.
2.1.1 User-to-user services
Three user-to-user signalling services associated with circuit-switched
calls that may be provided by the network users are:
1. Service 1:
user-to-user signalling exchanged during the set-up and clearing phases
of a call, within ISDN User Part call set-up and release
messages as defined in Recommendation Q.763;
2. Service 2:
user-to-user signalling exchanged during call set-up between the
Address Complete or Call Progress Messages and the Answer
or Connect Messages, within User-to-user Information
Messages; and
3. Service 3:
user-to-user signalling exchanged while a call is in the active state,
within User-to-user Information Messages.
All three services may be used separately or in any combination within
a single call. As an option at call set-up, users may be able to specify
whether the requested User-to-user signalling service(s) is(are) essential or
non-essential for the call (i.e. whether the call should be completed or not if
user-to-user information cannot be passed). Up to 128 octets of user information
may be transferred in a message in each of the three services 1. The 128 octets
does not include the user-to-user information parameter name, the protocol
control indicator or the length octets.
2.1.2 Service request
Service 1 may be requested implicitly by the presence of the
user-to-user information parameter in the Initial Address Message. An implicit
request is "non-essential" by default.
Explicit requests of Service 1 and 2 must be in the Initial Address
Message. Service 3 may be explicitly requested in the Initial Address Message during
call set-up. When there is an explicit request a single user-to-user indicators
parameter will be used with one of the following indications for each of the
three services:
- no information;
- requested, non-essential;
- requested, essential.
2.1.3 Response (Confirmation)
- 4 -
AP IX-112-E
If explicit requests are used there should, in general, be explicit
responses in a user-to-user indicators parameter with one of the following
indications for each of the three services:
- no information;
- provided;
- not provided.
Implicit "not provided" responses occur when:
- Service 1 has been implicitly requested and no user-to-user
information is received in call set-up or release messages; or
- Service 1, 2 or 3 has been explicitly requested and there is no
indication of acceptance or rejection from call control.
2.1.4 Flow control
The exchange of user-to-user signalling is limited by flow control
procedures provided on the access by either the user or network. The need for
interexchange flow control procedures by the ISDN User Part for user-to-user signalling
should be evaluated.
2.2 Procedures for user-to-user signalling associated with circuit-switched calls
The following sections only specify the signalling procedure used to
implicitly invoke the Service 1. Signalling procedures defined to support the other
services are specified in Annex A.
2.2.1 User-to-user signalling, Service 1
2.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, then
the service should be rejected.
2.2.1.2 User-to-user signalling in the call set-up phase - implicit service
request
Procedures for call set-up are as described in Recommendation Q.764,
Section 2, with the following changes:
Service 1 may be invoked by sending the user-to-user information
parameter of variable length that is specified in Recommendation Q.763,
Section 3.34 in an Initial Address Message that is requested in a call set-up
request from call control. This information parameter is transported across the
network and delivered unchanged to the terminating call control for the called
user. The user-to-user indicators parameter will not be sent.
The reception of a user-to-user information parameter in a call set-up
or release request from the terminating call control is an implicit indication of
the acceptance of Service 1.
The user or network may not be able to interpret incoming user-to-user
information. In such situations, the user should discard this information without
disrupting normal call handling. No specific signalling is provided by the
network to accommodate this situation.
2.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
- 5 -
AP IX-112-E
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 service.
2.2.1.4 Rejection of implicit service requests
Networks that cannot provide the service requested may not return a
rejection indication.
2.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.
2.2.1.6 Message flow diagrams
The message flow diagrams are shown in Figure 1/Q.730. Figure 1/Q.730
shows the use of User-to-user Signalling Service 1 when implicitly requested in a
point-to-point configuration.
┌──────────────────────────────────┐
│ Abbrev. Parameter Name │
├──────────────────────────────────┤
│ UUI user-to-user information │
├──────────────────────────────────┤
│ Abbrev. Message Name │
├──────────────────────────────────┤
│ ACM Address Complete │
│ ANM Answer │
│ IAM Initial Address │
│ REL Release │
│ RLC Release Complete │
└──────────────────────────────────┘
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 should be
examined.
- 6 -
AP IX-112-E
FIGURE 1/Q.730
UUS Service 1 (implicit request, called user is point-to-point)
Note 1 - In case that an ALERTING indication is carried by a Call Progress
Message, the user-to-user information parameter may also be transported in the Call
Progress Message.
Note 2 - In case that the called user is an automatic answering terminal user-
to-user information parameter may be transported in a Connect Message.
2.2.2 Interaction with other supplementary services
2.2.2.1 Call forwarding services
Interactions with the call forwarding services are shown in the call
forwarding protocol sections.
2.2.2.2 Call waiting service
Interactions with the call waiting service are shown in the call waiting
protocol sections. (Call waiting is for further study.)
2.2.2.3 Other services
There are no known interactions with services other than those listed.
2.2.2.4 State transition diagrams
The state transition diagrams may be found in Stage 2 descriptions of
the User-to-user Service.
3. Closed user group (CUG)
3.1 General
The Closed User Group (CUG) supplementary service enables a group of
users to intercommunicate only among themselves or, as required, one or more users
may be provided with incoming/outgoing access to users outside the group.
The stage I definition of the CUG service is given in the Recommendation
I.255 and its stage II service definition including network functions are given
in the Recommendation Q.85.
The realization of the CUG facilities is done by the provision of
interlock codes and is based on various validation checks as defined in Q.85 at call
set-up, determining whether or not a requested call to or from a user having a
CUG facility is allowed. In particular, a validation check is performed by
verifying that both the calling and called parties belong to the CUG indicated by the
interlock code.
The data for each CUG that a user belongs to can either be stored at the
local exchange to which the user is connected (decentralized administration of
CUG data), or at dedicated point(s) in the network (centralized administration of
CUG data).
In section 3.2 the call set-up procedure based on decentralized
- 7 -
AP IX-112-E
administration of CUG data is specified making use of the ISDN User Part as defined in
Recommendations Q.761-764 and Q.766.
In section 3.3 the call set-up procedure based on centralized
administration of CUG data is specified making use of the ISDN User Part as defined in
Recommendations Q.761-764 and Q.766 and the Transaction Capabilities Application
Part as defined in Recommendations Q.771-775.
In section 3.4 the application service element (ASE) on top of
Transaction Capabilities Application Part for CUG validation check with centralized
administration of CUG data is specified.
- 8 -
AP IX-112-E
4. General description of the Calling Line Identity Presentation and
Restriction service
Calling Line Identification Presentation (CLIP) is a supplementary
service offered to the called party which provides the calling party's ISDN number,
possibly with additional address information (i.e. sub-address), to the called
party.
Calling Line Identification Restriction (CLIR) is a supplementary
service offered to the calling party to restrict presentation of the calling party's
ISDN number, possibly with additional address information
(i.e. sub-address), to the called party.
The stage 1 definitions for the CLIP and CLIR services are given in the
Recommendation I.254 and the stage 2 service definitions including network
functions, are given in Recommendation Q.84. This stage 3 description of CLIP and
CLIR use the ISDN User Part protocol as defined in Recommendations Q.761-764 and
Q.766.
4.1 Description of the Calling Line Identity Presentation (CLIP) service
Calling Line Identity Presentation (CLIP) is a user facility that
enables a user to be informed on incoming calls, of the address of the calling party.
When provided the facility applies to all incoming calls except for when the
calling party has the Calling Line Identity Restriction (CLIR) facility active [see
section 4.2 below] or the complete number of the calling party is not available
at the destination exchange.
The Calling Line Identity (CLI) is generally the ISDN number of the
calling party (with possible additional address information, i.e. sub-address) which
may be provided by the network or partly by the calling party.
In the case where a national network does not always provide the CLIP
facility, the included CLI may be the known part of the ISDN number at the
interworking point (e.g. Trunk Code).
In the case where a calling party is an ISPBX, the network may send the
ISDN number of the PABX attendant operator or, if provided by the calling party,
the DDI number of the extension as the CLI.
When the CLI is provided by the user or ISPBX it is verified or screened
for validity by the network, i.e. the CLI provided by the user is within the
known number range for that user.
i) If the user provided CLI is valid the Calling Number Parameter
field contains the CLI in the Address Signal with the Screening
indicator set to "user provided verified and passed".
ii) If the user provided CLI is not valid or screened the originating
exchange defaults to the network provided CLI for the Address Signals
of the Calling Party Number parameter field with the Screening
indicator set to "network provided".
When the CLI is provided by the network the originating exchange
includes the stored CLI set against the calling party and sets the screening indicator
to "network provided".
The CLI sent to the called user should contain all the necessary digits
to enable a call to be established in the reverse direction.
Note - This may not always be possible if, for example, the DDI extension of an
ISPBX is not provided by the calling party.
Information indicating that a subscriber has the user access to the CLIP
facility is available in the exchange to which the subscriber is connected.
- 9 -
AP IX-112-E
4.1.1 Call set-up procedure
The call control procedure and the information included in Call Control
Messages vary depending on whether the CLI is included in the Initial Address
Message and also whether the calling party has indicated a request to use the CLIR
facility for this call.
Two different call control procedures can be used to provide the CLIP
facility. Both procedures are specified for international use, however, the first
method is to be preferred.
4.1.1.1 The Calling Line Identity is included in the Initial Address Message
When the CLI is available for insertion in the IAM the systematic
inclusion of this parameter, in the IAM, is recommended. However, it is realized that
under certain interworking conditions the CLI may only be available subsequent to the
transmission of the IAM.
In this situation, to avoid unnecessary unsuccessful requests for the CLI
the following procedures are recommended:
a) If the CLI cannot be included in the IAM (for any reason) but is
available and may be requested with a good chance of receiving it, then
the optional field "calling party number parameter" should not be
included in the IAM.
b) If the CLI cannot be transferred (because it is not allowed to be
passed or because the national network cannot provide the number), then
the optional field "calling party number parameter" should be included
in the IAM with the indication "presentation restricted" or "address
not available" set as appropriate in the Address Presentation
Restricted Indicator.
The CLI is sent to the called party in accordance with the user-network
interface protocol.
For calls between networks (e.g. an outgoing ISC as referred to in b)
above) the outgoing gateway exchange may remove any CLI digits from the IAM and
indicate in the calling party number parameter that presentation is restricted.
Interworking exchanges may generate only part of the CLI for inclusion in
the IAM (e.g. trunk code). This will be indicated in the number incomplete
indicator in the Calling Party Number Parameter field.
In the case where the destination exchange receives only part of the CLI,
(it is assumed to be the most significant part), the CLI is forwarded to the
called party with the appropriate indications set.
- 10 -
AP IX-112-E
4.1.1.2 The Calling Line Identity is not included in the Initial Address Message
In the case where the CLIP facility is applied, and the IAM has indicated
that the CLI may be available, an Information Request Message is sent towards the
originating exchange with the Information Request Indicator Parameter field bit
set to calling party address requested.
When receiving the request for Calling Party Address and the CLI is
available, the originating/interworking exchange sends an information message containing
the Calling Party Number Parameter field with the appropriate indications and CLI
included.
xxxx
ANNEX A
(to Signalling System No. 7)
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 Recommendation Q.730, sections 2.1-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
setup 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 setup are as described in Recommendation Q.764,
section 2 with the following changes:
On call setup the Initial Address Message will contain the user-to-user
indicators parameter with Service 1 indicated as "requested essential/not essential"
and Services 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 setup phase.
- 11 -
AP IX-112-E
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 be 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 setup
Procedures for call setup are as described in Recommendation Q.764, section 2
with the following changes:
- 12 -
AP IX-112-E
On call setup 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 "to information" 2. 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 parameter 3. 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 parameter 4. (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".
- 13 -
AP IX-112-E
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 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.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 Recommendation
Q.763, Table 20/Q.763.
If 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 setup phase. If more than two messages are received during call setup, 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 setup or after
call setup. However, Service 3 should not be requested after call setup if it has been
rejected during the call setup phase.
A.2.3.2 Service 3 requested during call setup
Procedures for call setup are as described in Recommendation Q.764, Section 2
with the following changes:
On call setup 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 5". 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.
- 14 -
AP IX-112-E
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 parameter 6. 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 setup
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 parameter 7. (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 setup
After call setup 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" 8. 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 parameter1.
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.
- 15 -
AP IX-112-E
A.2.3.5 Rejection of Service 3 when requested after call setup
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 9.
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 Stage 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 message1. If Service 3 was requested after call setup, a Facility Reject Message is
returned1. 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
Recommendation Q.763, 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
Section 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 sections 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".
- 16 -
AP IX-112-E
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 section 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 sections
2.2.1.6, 2.2.2.3 and 2.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, Services 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 sections A.2.1.4, I.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 control 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 sections A.2.2.5 and A.2.3.7.
- 17 -
AP IX-112-E
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 to A-7.
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 1 to 7:
Note 1 - In case that 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 case that the called user is an automatic answering terminal
user-to-user indicators parameter and/or user-to-user information parameter may be
transported in a Connect Message.
Figure A-1 shows a successful use of user-to-user Signalling Service 1 when
explicitly requested in a point-to-point configuration.
Figure A-2 shows both the successful and unsuccessful use of
user-to-user Signalling Service 2 in a point-to-point configuration.
Figure A-3 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 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 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 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 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.
Note - During an interim period of time, networks may support a lesser number
(e.g. 32 octets) due to protocol restrictions; 32 octets will always be supported.
Restrictions may apply to calls requesting user-to-user information more
than 32 octets.
The connection request parameter will be included if CO-SCCP method is
selected, or the call reference parameter will be included if CL-SCCP method is
selected.
The SCCP connection confirm message will be returned if CO-SCCP method is
selected.
- 18 -
AP IX-112-E
The SCCP connection refused message will be returned if CO-SCCP method is
selected.
The connection request parameter will be included if CL-SCCP method is selected
or the call reference parameter will be included if CL-SCCP method is selected.
The SCCP connection confirm message will be returned if CO-SCCP method is
selected.
The SCCP connection refused message will be returned if CO-SCCP method is
selected.
The Connection Request parameter will be included if CO-SCCP method is
selected, or the Call Reference parameter will be included if CL-SCCP
method is selected.
The SCCP connection refused message will be returned if CO-SCCP method is
