When interworking with a non-ISDN network occurs a PROGRESS or an
ALERTING message with the Progress indicator information element
indicating # 1 "call is not end-to-end ISDN; further call progress information may
be available in-band" is sent to the calling user to indicate that the
service cannot be guaranteed.
If any one or all of the services requested is indicated as required,
then the network or called user that cannot support or provide the request
will send a RELEASE COMPLETE with cause # 50 "requested facility not subscribed" or
cause # 69 "requested facility not implemented" and the service rejection
associated with that service.
7.1.7.4 Transfer of USER INFORMATION messages
The transfer of USER INFORMATION messages is defined in 7.1.4.4
and 7.1.5.6.
7.1.8 Summary of actions to be taken by the called side and subsequent
network action
Actions to be taken by the called side and the subsequent network actions
are summarized in the following table.
iii) Service 3: user-to-user signalling exchanged while a call is in
the Active state, within USER INFORMATION messages.
All three services may be used separately or in any combination in
association with a single call. As an option, at call setup, users may be able to specify
that the requested user-to-user signalling services(s) is (are) required for the
call, i.e. the call should not be completed if user-to-user information cannot be
passed.
7.1.2 Explicit invocation procedures for services 1, 2 and 3
Services 1, 2 and 3 listed above may be provided on a per call basis
following an explicit request from a user. The standard explicit invocation procedure
makes use of the Facility information element defined in 4.
In addition, or alternatively, some networks may support explicit
invocation procedures making use of:
- Keypad facility information element; or
- Feature activation information element.
The exact operation of stimulus invocation procedures are network
dependent but must follow the rules defined in 8 of this Recommendation. More detailed
protocol aspects can also be found in 4 (for the keypad protocol invocation) and
in 5 (for the feature management protocol invocation) of Recommendation Q.932.
When a network supports more than one invocation procedure, the following
principles shall be followed:
- for invocations using the Keypad facility information element,
the network will convey the remote user's response using a Signal,
a Display, or a Feature indication information element;
- for invocations using the Feature activation information element, the
network will convey the remote user's response using a
Feature indication information element;
- for invocations using the Facility information element, the
network will convey the remote user's response using a Facility
information element.
In the network-to-user direction, explicit service 1 and service 2
requests may be indicated using the Facility information element.
In the network to user direction, service 3 requests may be indicated
using:
i) Signal information element (see note);
ii) Display information element (see note);
iii) Feature indication information element (see note); or
iv) Facility information element.
For indications using the Facility information element, the user will
respond with a Facility information element. No response is needed when any of
the first three information elements are used.
Note - These may be used only when the network has knowledge that the user
receiving the notification has subscribed to the service. In this case, the
network will generate the service confirmation to the originating user (i.e., the
user requesting the service) on behalf of the user who did not originate the
service request. For service 3, invoked during the active state of a call, the
message use is symmetric across the user-network interface; i.e., the FACILITY
message is returned in response to a FACILITY message.
7.1.3 User-to-user signalling service 1
7.1.3.1 General characteristics
Service 1 allows the users to communicate by means of user-to-user
signalling by transferring user-to-user information within Recommendation Q.931
call control messages during call establishment and clearing phases.
7.1.3.2 User-to-user signalling - implicit service request
(preferred, i.e. - not required)
Service 1 may be implicitly requested by including a User-user
information element of variable length as specified in 4.5.29 in the SETUP message
transferred across the user-network interface at the calling side as described in
5.1.1. This information element is transported by the network and delivered
unchanged in the User-user information element included in the SETUP message
transferred across the user-network interface at the called side as described in
5.2.1. For invocation purposes, this information element must be at least three
octets long as defined in 4.5.29.
In the case where contention by users for the incoming call is not
allowed (e.g., when the SETUP message containing an implicit service invocation is
delivered using a point-to-point link at the data link layer or when the
network, despite using broadcast capability at layer 2, knows based on the first
response received from the user that no contention takes place), a User-user
information element may be included in the ALERTING and/or CONNECT messages
transferred across the user-network interface at the called side as described in
5.2.5. The content of this information element is transported by the network and
delivered in the User-user information element included in the corresponding
message(s) transferred across the user-network interface at the calling side as
described in 5.1.7 and 5.1.8.
On call request, the SETUP message sent by the calling user will
contain a service 2 request. The SETUP message sent by the network at the called
side, will also contain an explicit service 2 request.
If the called user can support USER INFORMATION messages during call
establishment, a service 2 acceptance shall be included in the ALERTING message
sent to the network. This explicit acceptance indication shall be forwarded in
the ALERTING message sent by the network to the calling user.
7.1.4.3 Service rejection
If the called user or network does not understand the service 2
request, then the ALERTING message returned to the calling user will not include
either a service 2 acceptance or rejection. This type of response shall be taken as
an implicit rejection of service 2. Alternatively, if the network or called
user cannot support USER INFORMATION messages during call establishment, and the
request is indicated as preferred, a service 2 rejection is included in the
ALERTING message.
If the service 2 request indicated required, and the called user or
network cannot support or provide the service, a RELEASE COMPLETE is sent with
cause # 50 "requested facility not subscribed" or cause # 69 "requested facility
not implemented" and a service 2 rejection.
If the called user does not include a service 2 acceptance or rejection
in the ALERTING message, the network shall return an explicit rejection in the
ALERTING message sent to the calling user.
In the case of interworking with a non-ISDN network, a PROGRESS or
ALERTING message with the progress indicator information element indicating # 1
"call is not end-to-end ISDN; further call progress information may be available
in-band" is sent to the calling user to indicate that the full service cannot be
guaranteed.
7.1.4.4 Transfer of USER INFORMATION messages
Once an ALERTING message has been received, both the involved users can
transfer information between themselves by transferring USER INFORMATION
messages across the user-network interface. The network provides for the transfer of
such messages from the calling to the called side and vice versa.
The USER INFORMATION message includes the Call reference, the Protocol
discriminator, and the User-user information elements as defined in 3.1.26.
The More data information element may also be included by the source user to
indicate to the remote user that another USER INFORMATION message will follow,
containing information belonging to the same block. The use of More data
information element is not supervised by the network.
If the user-to-user signalling facility is provided, no more than two
USER INFORMATION messages may be transferred in each direction after the
ALERTING message and before the CONNECT message.
Sending or receiving of USER INFORMATION messages does not change the
state of the call.
7.1.5 User-to-user signalling service 3
7.1.5.1 General
Service 3 allows the users to communicate by means of transferring USER
INFORMATION messages during the Active state of a call. This service allows
either an implicit or explicit rejection (see 7.1.5.3.). This service may be
requested during call establishment or during the Active state of the call.
7.1.5.2 Service request during call establishment
Procedures for call establishment are as described in 5.1 and 5.2
with the following modifications.
On call request, the SETUP message sent by the calling user will
contain a service 3 request. The SETUP sent by the network at the called side will
also contain a service 3 request.
If the called user can support USER INFORMATION message transfer during
the Active state, a service 3 acceptance shall be included in the CONNECT
message.
7.1.5.3 Rejection of service requested during call establishment
If the called user or network does not understand the service 3
request, then the CONNECT message returned to the calling user shall not include
either a service 3 acceptance or rejection. This type of response will be taken as
an implicit rejection of service 3. Alternatively, if the network or called user
cannot support USER INFORMATION messages during the Active state, and the
request is indicated as preferred, a service 3 rejection is included in the CONNECT
message. If the service 3 request indicated required, and the called user or
network cannot support or provide the service, a RELEASE COMPLETE is sent with
cause # 50 "requested facility not subscribed" or cause # 69 "requested facility
not implemented" and a service 3 rejection.
If the called user does not include a service 3 acceptance or rejection
in the CONNECT message, the network shall return a service 3 rejection in the
CONNECT message sent to the calling user.
When interworking with a non-ISDN network occurs a PROGRESS or an
ALERTING message with the Progress indicator information element indicating # 1
"call is not end-to-end ISDN; further call progress information may be available in-band" is sent to the calling user to indicate that the service cannot be
guaranteed.
7.1.5.4 Service request after call establishment
During the Active state of a call, a user may request service 3
preferred only. A FACILITY message indicating a service 3 request is sent from the
requesting user to the network. The network shall indicate the service 3 request
to the user that did not request service 3 in the FACILITY message.
If the user that did not request service 3 can support the transfer of
USER INFORMATION messages during the Active state, a service 3 acceptance is
returned in the FACILITY message. This explicit acceptance indication shall be
conveyed back to the requesting user in a FACILITY message.
7.1.6 Unexpected USER INFORMATION messages
7.1.6.1 Receipt of USER INFORMATION messages in incompatible call states
Whenever a USER INFORMATION message is received from the user and it is
not allowed by an invoked service (e.g., in any other state than Active where
only service 3 is invoked), the message will be discarded by the network. The
network will respond with a STATUS message with a cause # 43 "access information
discarded".
7.1.6.2 Receipt of unexpected USER INFORMATION messages
Whenever a USER INFORMATION message is received by the network from the
calling or called user after the network has indicated that user-to-user cannot
be supported, that message shall be discarded without further action.
7.1.7 Requesting user-to-user signalling services 1, 2 and 3
7.1.7.1 General
This section describes procedures for requesting services 1, 2 and 3 in
the same SETUP message. These services are described in 7.1.3, 7.1.4 and
7.1.5, respectively.
Note - User-to-user service 1 implicit request/acceptance follows 7.1.3.2
procedures. Only explicit service 1 requests may follow the procedure in this
section.
7.1.7.2 Call establishment
Procedures for call establishment are described in 7.1.3.3, 7.1.4.2,
and 7.1.5.2 with the following modifications. On call request, the SETUP
message sent by the calling user will contain independent service 1, 2, 3 requests.
The SETUP sent by the network at the called sides will also contain the
same independent service requests. If the called user can support the indicated
services, then specific services acceptances may all be indicated in the
ALERTING message. Alternatively, the user may accept services 1 and 2 in the ALERTING
message, as defined in 7.1.3.3 and 7.1.4.2, and service 3 in the CONNECT
message, as defined in 7.1.5.2.
7.1.7.3 Service rejection
If the called user or network does not understand any of the services
requested, then the ALERTING and CONNECT messages returned to the calling user
will not include either a service 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 defined in 7.1.3.6, 7.1.4.3 or
7.1.5.3. Alternatively, if the network or called user cannot support one or
more services requested, and the service requests were indicated as preferred, the
specific service rejection may be included in the ALERTING message. The
services may also be rejected following the procedures in 7.1.3.6, 7.1.4.3 or
7.1.5.3.
If the called user does not include a service 1, 2 or 3 acceptance or
rejection in the ALERTING and/or CONNECT message, the network shall return a
service 1, 2 or 3 rejection in the ALERTING and/or CONNECT message sent to the
calling user.
7.2 Procedures for user-to-user signalling not associated with
circuit-switched calls
7.2.1 General characteristics
This feature allows the users to communicate by means of user-to-user
signalling without setting up a circuit-switched connection. A temporary
signalling connection is established and cleared in a manner similar to the control of
a circuit-switched connection.
7.2.2 Call establishment
Procedures for call establishment are as described in 5.1 and 5.2
with the following modifications.
On call request, the calling user sends a SETUP message identifying,
within the Bearer capability and Channel identification information elements, a
temporary signalling connection to be established on SAPI=O. The SETUP message
is encoded to indicate:
Bearer capability information element
- Unrestricted digital information in the information transfer
capability field;
- Packet mode in the transfer mode field;
- User information layer 2 protocol is Recommendation Q.931 and
user information layer 3 protocol is Recommendation
Q.931 in the layer and protocol identification field.
Channel identification information element
- Exclusive in the preferred/exclusive field;
- D Channel in the D-Channel indicator field;
- No channel in the channel selection field.
If the network determines that the requested temporary signalling
connection service is not authorized or is not available, the network
shall initiate call clearing in accordance with 5.3.2(a) or 5.3.2(c) with one of
the following causes:
a) #57 "bearer capability not authorized"
b) #58 "bearer capability not presently available"
c) #63 "service or option not available, unspecified"
d) #65 "bearer service not implemented"
The called user accepts the temporary signalling connection request by
sending a CONNECT message towards the calling user. After the called user has
received a CONNECT ACKNOWLEDGE message, it may begin sending USER INFORMATION
messages. Once the calling user receives a CONNECT message, it can begin sending
USER INFORMATION messages.
7.2.3 Transfer of USER INFORMATION messages
Once a temporary signalling connection is established both users can
transfer information between themselves by transferring USER INFORMATION messages
across the user-network interface. The network provides for the transfer of such
messages from the called to the calling side and vice versa.
The USER INFORMATION message includes the Call reference, the Protocol
discriminator, and the User-to-user information elements as defined in
3.3.13. The More data information element may also be sent by the source user to
indicate to the remote user that another USER INFORMATION message will follow,
containing information belonging to the same block. The use of the More data
information element is not supervised by the network.
7.2.4 Congestion control of USER INFORMATION messages
Congestion control procedures are the same as those described in
7.1.5.7.
7.2.5 Call clearing
The clearing of an established temporary signalling connection can be
initiated by the user or network by sending a RELEASE message towards the far end
user. The clearing procedure followed and the timers involved are the same as
those for clearing a circuit-switched connection as described in 5.3.3 and
