home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Standards
/
CD2.mdf
/
ccitt
/
1992
/
q
/
q931g.asc
< prev
next >
Wrap
Text File
|
1991-12-31
|
20KB
|
1,165 lines
G.7 Interworking class
G.7.1 Cause No. 127 "interworking unspecified"
This cause indicates that there has been interworking with a network
which does not provide causes for actions it takes, thus, the precise cause
for a message which is being sent cannot be ascertained.
Annex H
(to Recommendation Q.931)
Examples of information elements coding
This annex gives examples on the detailed coding of the following
information elements:
- bearer capability information element;
- channel identification information element;
- called/calling party sub-address.
H.1 Bearer capability information element
H.1.1 Coding for speech
H.1.2 Coding for 3.1 kHz audio
H.1.3 Coding for unrestricted digital information
Type 1: Synchronous 64 kbit/s working
Type 2: Synchronous rates less than 64 kbit/s with CCITT standardized rate
adaption V.110/X.30; in-band negotiation not possible.
H.1.4 Coding for X.25 packet mode access connections
Case (b)
H.2 Channel identification information element
H.2.1 Basic interface, circuit mode, B channel
Example (a)
- Channel B1 preferred.
- Channel is located in same interface which includes the
D channel.
Example (b)
- Any B channel.
H.2.2 Primary rate interface, circuit mode, B channel
Case (a)
Case (b)
Example (c)
H.3 Called/calling party sub-address information element
H.3.1 Coding of IA5 sub-address digits
Note 1 - AFI code 50 (in BCD) indicates that the sub-address consists of IA5
characters (see ISO standard 8348 AD2).
Note 2 - IA5 character according to CCITT Recommendation T.50/ISO 646.
Note 3 - The number of IA5 characters shown above is just an example. There may
be up to 19 IA5 characters.
Note 4 - The value of this bit has no significance when the type of sub-address
is "NSAP".
Annex I
(to Recommendation Q.931)
Use of progress indicators
This annex describes the use of the different progress indicator values
defined in 4.5.22. Examples of use are given.
Progress indicator No. 1 indicates that interworking with a non-ISDN has
occurred within the network or networks through which the call has traversed.
Progress indicator No. 2 indicates that the destination user is not ISDN.
Progress indicator No. 3 indicates that the origination user is not ISDN.
Progress indicator No. 4 indicates that a call which had left the ISDN has
returned to the ISDN at the same point it had left due to redirection within the
non-ISDN. This progress indicator would be employed when a prior
Recommendation Q.931 message resulted in a progress indicator No. 1 "call is not end-to-end ISDN"
being delivered to the calling user.
The use of progress indicators Nos. 1, 2 and 3 is exemplified in the
following.
Three interworking situations are identified in the figure below:
a) interworking with another network;
b) interworking with a non-ISDN user connected to ISDN;
c) interworking with non-ISDN equipment within the calling or called
user's premises.
As regards calls from A the following applies:
case a) - progress indicator No. 1 sent to A;
case b) - progress indicator No. 2 sent to A;
case c) - progress indicator No. 2 sent to A (location sub-field =
private network).
As regards calls towards A the following applies:
case a) - progress indicator No. 1 sent to A;
case b) - progress indicator No. 3 sent to A;
case c) - progress indicator No. 3 sent to A (location sub-field =
private network)
The use of progress indicator No. 8 "in-band information or appropriate
pattern now available" is described in 5.
Annex J
(to Recommendation Q.931)
Examples of cause value and location for busy condition
This annex gives examples on the detailed cause value and location to be
sent in a Cause information element for the busy condition.
Figure J-1/Q.931 shows the reference configuration which identifies nodes
where busy condition may occur and therefore a cause should be generated.
Table J-1/Q.931 shows:
a) a cause value and location to be generated at the point where the
busy condition occurs; and
b) a cause value and location to be delivered to the user (indicated
as A) for each location (B - P) where the busy
condition occurs.
As is indicated in the table, the cause value is not changed but the location
may be changed in the receiving exchange, when the cause value crosses a
network boundary.
Note - The interface A-B, C-D, M-N and O-P are assumed to be Q.931.
FIGURE J-1/Q.931
Examples of cause values and location for busy condition
TABLE J-1/Q.931
Location where busy occurs and the cause codings
┌───────────────────┬──────────────────┬──────────────────┐
│ Location where │Cause at the point│ Cause received │
│ busy occurs │ of generation │ by user A │
├───────────────────┼──────────────────┼──────────────────┤
│ │ │ │
│B incoming circuit │ #34 or #44 LPN │ ) │
│B outgoing circuit │ #34 LPN │ ) │
│C outgoing circuit │ #34 LPN │ ) │
│ │ │ ) │
│D incoming circuit │ #34 or #44 LN │ ) │
│D outgoing circuit │ #34 LN │ )The same as left│
│E outgoing circuit │ #34 LN │ ) │
│ │ │ ) │
│F outgoing circuit │ #34 TN │ ) │
│G outgoing circuit │ #34 TN │ ) │
│ │ │ ) │
│H outgoing circuit │ #34 INTL │ ) │
│I outgoing circuit │ #34 INTL │ ) │
│ │ │ │
│J outgoing circuit │ #34 TN │ #34 TN │
│K outgoing circuit │ #34 TN │ #34 TN │
│ │ │ │
│L outgoing circuit │ #34 LN │ #34 RLN │
│M outgoing circuit │ #17 LN │ #17 RLN │
│ │ │ │
│N incoming circuit │ #34 or #44 LPN │ #34 or #44 RPN │
│N outgoing circuit │ #34 LPN │ #34 RPN │
│O outgoing circuit │ #17 LPN │ #17 RPN │
│ │ │ │
│P incoming circuit │ #34 or #44 U │ #34 or #44 U │
│P call control │ #17 U │ #17 U │
└───────────────────┴──────────────────┴──────────────────┘
LPN : Private network serving the local user
LN : Public network serving the local user.
TN : Transit network.
INTL: International transit network.
RLN : Public network serving the remote user.
RPN : Private network serving the remote user.
U : User.
Table J-1/Q.931 is for further study.
Annex K
(to Recommendation Q.931)
Message segmentation procedures
K.1 Introduction
Layer 3 messages that are longer than the length of frames that the data
link layer can support may be partitioned into several segments.
Message segmentation shall only be used when the message length exceeds
N.201 (defined in Recommendation Q.921) [3]. These procedures are optional and
may not be supported by all equipment.
The architectural relationship to other Recommendation Q.931 functions
is shown in Figure K-1/Q.931. These procedures apply only within a specific data
link connection and do not impact the procedures in operation on other parallel
data link connections.
K.2 Message segmentation
The following rules apply when Recommendation Q.931 messages are to be
segmented for transmission:
a) the default maximum number of message segments is eight. If the
message is too long to be segmented then a local
maintenance activity shall be notified;
b) the first message segment shall begin with the protocol
discriminator immediately followed by the Call
reference, the segment message type, the Segmented message
information element, and one or more other information
elements;
c) each subsequent message segment shall begin with the protocol
discriminator immediately followed by the call
reference, the segment message type, the Segmented message
information element and one or more other information
elements;
d) the first segment indicator field of the Segmented message
information element shall be set to indicate the
first segment of a segmented message, and not set in any
other segment;
e) the number of segments remaining field of the Segmented message
information element shall be set to indicate how many
more segments are to be sent, see Figure L-2/Q.931.
f) the Message type information element shall be coded to indicate a
segment message, and the Segmented message
information element shall indicate the message type of the
original message;
g) the transmission of a segmented message may be aborted by:
sending a message or message segment containing a
different call reference; sending a message with the
message type not coded "segment message" or stopping the
transmission of subsequent message segments pertaining
to the same message;
h) once the first segment has been transmitted on a particular data
link connection, then all remaining segments of that
message shall be sent (in order) before any other
message (segmented or not) for any other call reference is
sent on that data link connection;
i) messages shall be segmented only at information element
boundaries; i.e., no information element shall be
separated into two segments;
j) the information element order as a whole is preserved for the
Segmented message regardless of segment boundary.
K.3 Reassembly of segmented messages
The following rules apply to the receipt and reassembly of segmented
Q.931 messages:
a) a reassembly function, on receiving a message segment containing
the Segmented message information element with the
first segment indicator indicating "first message", and
containing the call reference and message type (coded
as "segment message" shall enter the Receiving
Segmented Message state and accumulate message segments;
b) timer T314, shall be initialized or reinitialized upon receipt of
a message segment containing the Segmented message
information element with a non-zero number of segments
remaining field. Timer T314 shall be stopped upon
receipt of the last segment; i.e., a message segment
containing the segmented message information element with
the number of segments remaining field coded zero.
Timer T314 shall not be initialized or reinitialized if
error procedures as identified in rules below are
initiated;
c) a reassembly function receiving a message segment with a
segmented message information element should wait for
receipt of the last message segment pertaining to the
same message i.e., containing the segmented message
information element with the number of segments
remaining field coded zero before delivering the message for
further Q.931 processing as specified in 5.8. The
reassembly function shall enter the Null state;
d) upon expiry of timer T314, the reassembly function shall: discard
all segments of this message so far received; notify
the layer 3 management entity for the data link
connection that message segments have been lost; and enter
the null state.
Note - Subsequent message segments relating to the same message
shall be discarded according to rule f).
e) a reassembly function, upon receiving eight message segments of
the same segmented message without receiving a
message segment with a number of segments remaining field of
the Segmented message information element coded zero,
shall: discard all message segments so far received;
notify the layer 3 management entity for the data link
connection that messages have been discarded; and
enter the Null state;
Note - Subsequent message segments relating to the same message
shall be discarded according to rule f).
f) a reassembly function, on receiving a message segment containing
a Segmented message information element, but with no
call reference or Message type information element,
while in the Null state shall discard that message
segment and remain in the Null state;
g) a reassembly function, on receiving a message segment containing
a Segmented message information element, while in the
Receiving Segmented Message state with the number of
segments remaining field that is not decremented from
the number of segments remaining field in the Segmented
message information element of the previous message
segment, shall: discard all segments of this message so
far received; and enter the Null state;
Note - Subsequent message segments relating to the same message
shall be discarded according to rule f).
h) if there is a DL RELEASE INDICATION primitive or DL ESTABLISH
INDICATION primitive received while in the Receiving
Segmented Message state, the reassembly function
shall: discard all received message segments so far
received; forward the DL
RELEASE INDICATION primitive or DL ESTABLISH INDICATION primitive
for further Q.931 processing, and enter the null
state;
i) a reassembly function, upon receiving a message segment with the
first segment indicator of the Segmented message
information element indicating "subsequent", while in the
Null state, shall: discard that message segment; and
remain in the Null state.
FIGURE K-1/Q.931
Logical architecture containing segmentation function
FIGURE K-2/Q.931
Relation between message and segments
Block diagram
FIGURE K-3/Q.931
Segmentation functional interaction diagram
FIGURE K-4/Q.931
Message segmenter SDL
FIGURE K-5/Q.931
Message reassembler SDL (1 of 3)
FIGURE K-5/Q.931
Message reassembler SDL (2 of 3)
FIGURE K-5/Q.931
Message reassembler SDL (3 of 3)