ISO/IEC 13874:1995
(Main)Information technology - Telecommunications and information exchange between systems - Private Integrated Services Network - Inter-exchange signalling protocol - Path replacement additional network feature
Information technology - Telecommunications and information exchange between systems - Private Integrated Services Network - Inter-exchange signalling protocol - Path replacement additional network feature
Technologies de l'information — Télécommunications et échange d'information entre systèmes — Réseau privé à intégration de services — Protocole de signalisation d'interéchange — Facilité de réseau additionnelle de remplacement de chemin
General Information
Relations
Frequently Asked Questions
ISO/IEC 13874:1995 is a standard published by the International Organization for Standardization (ISO). Its full title is "Information technology - Telecommunications and information exchange between systems - Private Integrated Services Network - Inter-exchange signalling protocol - Path replacement additional network feature". This standard covers: Information technology - Telecommunications and information exchange between systems - Private Integrated Services Network - Inter-exchange signalling protocol - Path replacement additional network feature
Information technology - Telecommunications and information exchange between systems - Private Integrated Services Network - Inter-exchange signalling protocol - Path replacement additional network feature
ISO/IEC 13874:1995 is classified under the following ICS (International Classification for Standards) categories: 33.040.35 - Telephone networks. The ICS classification helps identify the subject area and facilitates finding related standards.
ISO/IEC 13874:1995 has the following relationships with other standards: It is inter standard links to ISO 17510-1:2002/Cor 1:2004, ISO/IEC 13874:1995/Cor 1:1996, ISO/IEC 13874:1999; is excused to ISO/IEC 13874:1995/Cor 1:1996. Understanding these relationships helps ensure you are using the most current and applicable version of the standard.
You can purchase ISO/IEC 13874:1995 directly from iTeh Standards. The document is available in PDF format and is delivered instantly after payment. Add the standard to your cart and complete the secure checkout process. iTeh Standards is an authorized distributor of ISO standards.
Standards Content (Sample)
I NTERNATI ON AL
ISO/IEC
STANDARD 13874
First edition
1995-1 1-01
Information technology -
Telecommunications and information
exchange between systems - Private
-
Integrated Services Network
Inter-exchange signalling protocol - Path
replacement additional network feature
Technologies de l'information - Télécommunications et échange
d'information entre systèmes - Réseau privé à intégration de
services - Protocole de signalisation d'itlteréchange - Facilité de réseau
additionnelle de remplacement de chemin
Reference number
ISO/IEC 138741 995(Ei
Contents
Page
...
Foreword .
Introduction . iv
1 Scope . 1
2 Conformance . 1
3 Normative references . 1
4 Definitions . 2
4.1 External definitions . 2
......................................................................................................................................... 3
4.2 Other definitions
5 List of acronyms . 3
6 Signalling protocol for the support of ANF-PR . 3
6.1 ANF-PR description . 3
.............................................................................................................. 4
6.2 ANF-PR operational requirements
6.3 ANF-PR coding requirements . 5
6.4 ANF-PR state definitions . 9
6.5 ANF-PR signalling procedures . 10
6.6 ANF-PR optional signalling procedures for retention of part of the old connection . 12
6.7 ANF-PR impact of interworking with public ISDNs . 15
6.8 ANF-PR impact of interworking with non-ISDNs . 15
6.9 Protocol interactions between ANF-PR and other supplementary services and ANFs . 15
6.10 ANF-PR parameter values (timers) . 17
Annex A - Protocol Implementation Conformance Statement (PICS) proforma . 18
B - Imported ASN.l definitions . 25
Annex
Annex C - Examples of message sequences . 26
Annex D - Specification and Description Language (SDL) representation of procedures . 32
O ISO/IEC 1995
. Unless otherwise specified. no part of this publication may be reproduced or utilized in any
All rights reserved
form or by any means. electronic or mechanical. including photocopying and microfilm. without permission in
writing from the publisher .
ISO/IEC Copyright Office Case postale 56 CH-1211 Genève 20 Switzerland
Printed in Switzerland
..
O rso/IEc
ISO/IEC 138741995 (E)
Foreword
IS0 (the International Organization for Standardization) and IEC (the Inter-
national Electrotechnical Commission) form the specialized system for worldwide
standardization. National bodies that are members of IS0 or IEC participate in the
development of International Standards through technical committees established
by the respective organization to deal with particular fields of technical activity.
IS0 and IEC technical committees collaborate in fields of mutual interest. Other
international organizations, governmental and non-governmental, in liaison with
IS0 and IEC, also take part in the work.
In the field of information technology, IS0 and IEC have established a joint
technical committee, ISOAEC JTC 1. Draft International Standards adopted by the
joint technical committee are circulated to national bodies for voting. Publication
as an International Standard requires approval by at least 75 % of the national
bodies casting a vote.
International Standard ISO/IEC 13874 was prepared by Joint Technical
Committee ISO/IEC JTC 1, Information technology, Subcommittee SC 6,
Telecommunications and information exchange between systems.
Annex A forms an integral part of this International Standard. Annexes B to D are
for information only.
iii
O 1somc
This International Standard is one of a series of International Standards defining services and signalling protocols
applicable to Private Integrated Services Networks (PISNs). The series uses ISDN concepts as developed by ITU-T and
conforms to the framework of International Sîandards for Open Systems Interconnection as defined by ISO/rec.
This particular International Standard specifies the signalling protocol for use at the Q reference point in support of
the Path Replacement additional network feature.
INTERNATIONAL STANDARD O ISO/IEC
Information technology - Telecommunications and information exchange between
systems - Private Integrated Services Network - Inter-exchange signalling
protocol - Path replacement additional network feature
1 Scope
This International Standard specifies the signalling protocol for the support of the Path Replacement additional
network feature (ANF-PR) at the Q reference point between Private Integrated Services Network Exchanges (PINXs)
connected together within a Private Integrated Services Network (PISN).
ANF-PR is a feature which applies to an established call, allowing that call's connection between PINXs to be replaced
by a new connection.
The Q reference point is defined in ISO/IEC 11579-1.
Service specifications are produced in three stages and according to the method specified in CCITT Recommendation
1.130. This International Standard contains the stage 3 specification for the Q reference point and satisfies the
requirements identified by the stage 1 and stage 2 specifications in ISO/EC 13863.
The signalling protocol for ANF-PR operates on top of the signailing protocol for basic circuit switched call control, as
specified in ISO/IEC 11572, and uses certain aspects of the generic procedures for the control of supplementary
services specified in ISO/IEC 11582.
This International Standard also specifies additional signalling protocol requirements for the support of interactions at
the Q reference point between ANF-PR and other supplementary services and ANFs.
This International Standard is applicable to PINXs which can interconnect to form a PISN.
2 Conformance
In order to conform to this International Standard, a PINX shall satisfy the requirements identified in the Protocol
Implementation Conformance Statement (PICS) proforma in annex A.
3 Normative references
The following standards contain provisions which, through reference in this text, constitute provisions of this
International Standard. At the time of publication, the editions indicated were valid. All standards are subject to
revision, and parties to agreements based on this International Standard are encouraged to investigate the possibility of
applying the most recent editions of the standards indicated below. Members of IEC and IS0 maintain registers of
currently valid International Standards.
ISO/IEC 11571: 1994, Information technology - Telecommunications and information exchange between systems -
Numbering and sub-addressing in Private Integrated Services Networks.
ISO/EC 11572 1994, Information technology - Telecommunications and information exchange between systems -
Private Integrated Services Network - Circuit-mode bearer services - Inter-exchange signalling procedures and
protocol.
ISO/IEC 1 1574: 1994, Information technology - Telecommunications and information exchange between systems -
Private Integrated Services Network - Circuit-mode 64 kbitls bearer services - Service description, functional
capabilities and information flows.
ISO/IEC 11579-1: 1994, Information technology - Telecommunications and information exchange between systems -
Private Integrated Services Network - Part I : Reference configuration for PISN Exchanges (PINX).
O ISOLIEC
ISO/IEC 13874: 1995 (E)
ISO/IEC 1 1582: 1995, Information technology - Telecommunications and information exchange between systems -
Private Integrated Services Network - Generic functional protocol for the support of supplementary services - Inter-
exchange signalling procedures and protocol.
ISO/reC 13863: 1995, Information technology - Telecommunications and informaltion exchange between systems -
Private Integrated Services Network - Specification, functional model and infor,mation flows - Path replacement
additional network feature.
ISOPEC 13869: 1995, Information technology - Telecommunications and informtion exchange between systems -
Private Integrated Services Network - Inter-exchange signalling protocol - Call transfer supplementary services.
CCITT Rec. 1.112(1988), Vocabulary of terms for ISDNs (Blue Book).
CCITT Rec. 1.130(1988), Method for the characterization of telecommunication services supported by an ISDN and
network capabilities of an ISDN (Blue Book).
CCITT Rec. 1.210(1988), Principles of telecommunication services supported by an ISDN and the means to describe
them (Blue Book).
CCITT Rec. Z.lOO( 1988), Specijïcation and Description Language (Blue Book).
ITü-T Rec. Q.950( 1993), Digital Subscriber Signalling System No. 1 (DSSl) - Supplementary services protocols,
structure and general principles.
4 Definitions
For the purposes of this International Standard, the following definitions apply.
4.1 External definitions
This International Standard uses the following terms defined in other documents:
ANF-PR user (ISO/IEC 13863)
Application Protocol Data Unit (APDU) (ISO/IEC 11582)
Basic Service (CCITT Rec. 1.210)
Call, Basic Call (ISO/IEC 11582)
Connection (ISO/IEC 13863)
Incoming Gateway PINX (ISO/IEC 11572)
Interpretation APDU (ISO/IEC 11582)
Network Facility Extension (NFE)
(ISO/IEC 11582)
New connection
(ISO/IEC 13863)
Old Connection (IsOPEC 13863)
Originating PINX (ISO/iEC 11572)
Outgoing Gateway PINX (ISO/IEC 11572)
Private Integrated Services Network (PISN) (ISO/IEC 11579-1)
11 579- 1)
Private Integrated Services Network Exchange (PINX) (ISO/IEC
Signalling (CCITT Rec. 1.1 12)
Supplementary Service (CCITT Rec. 1.210)
Supplemenîary Services Control Entity (ISO/IEC 11582)
Terminating PINX (ISO/IEC 11572)
(ISODC 11572)
Transit PINX
Trombone Connection (ISO/IEC 13863)
User (except in the context of ANF-PR user) (ISO/IEC 11574)
O ISO/IEC ISOlIEC 138741995 (E)
4.2 Other definitions
4.2.1 branching PINX: The Transit PINX at which the retained connection finishes and the new connection starts.
4.2.2 cooperating PINX: The end PINX which initiates the establishment of the new connection towards other end
PINX involved in the call.
4.2.3 end PINX: Within the context of a call, a PINX which is not acting as a Transit PINX, i.e., an Originating
PINX, a Terminating PINX, an Incoming Gateway PINX or an Outgoing Gateway PINX.
4.2.4 preceding PINX: The adjacent PINX in the direction of the cooperating PINX, relative to a particular PINX
involved in the old connection.
NOTE 1 -This can be the cooperating PINX itself or a Transit PiNX.
4.2.5 replaced connection: That part of the old connection which is not retained and is replaced by the new
connection.
4.2.6 requesting PINX: The end PINX which invokes ANF-PR and towards which the new connection is routed.
4.2.7 retained connection: That part of the old connection which is retained and not replaced by the new connection.
4.2.8 subsequent PINX: The adjacent PINX in the direction of the requesting PINX, relative to a particular PINX
involved in the old connection.
NOTE 2 - This can be the requesting PINX itself or a Transit PEW.
5 List of acronyms
ANF Additional Network Feature
ANF-PR Path Replacement additional network feature
APDU Application Protocol Data Unit
ASN. 1 Abstract Syntax Notation no. 1
ISDN Integrated Services Digital Network
NFE Network Facility Extension
PICS Protocol Implementation Conformance Statement
PINX Private Integrated Services Network Exchange
PISN Private Integrated Services Network
SDL Specification and Description Language
SS-CT Call Transfer supplementary service
6 Signalling protocol for the support of ANF-PR
6.1 ANF-PR description
ANF-PR is invoked by an ANF-PR user for an established call, allowing that call's connection through the PISN to be
replaced by a new connection. If the new connection is required to satisfy certain criteria, ANF-PR should be used in
conjunction with other supplementary services and/or ANFs. In the absence of specific criteria, the new connection
should be established using the routeing rules which apply to basic call establishment.
NOTE 3 - Annex A of ISO/IEC 13863 gives examples of the circumstances under which ANF-PR can be used and criteria which can govern the
selection of the new connection.
The requesting PINX shall request the cooperating PINX to attempt the estabüshment of a new connection from the
cooperating PINX to the requesting PINX. If successful, the new connection shall replace the old connection.
NOTE 4 - The requesting PiNX can be either end PiNX involved in a call, i.e., the Originating PiNX or the Terminating PINX or, in the case of
interwoiking with another netwoik, the Incoming Gateway PINX or Outgoing Gateway PiNX.
ISO/IEC 138741995 (l3) O ISO/IEC
Optionai procedures and coding are specified for allowing the retention of one or mare elements of the old connection,
starting from the cooperating PINX and continuing as far as a Transit PINX, subject to any given criteria being
achievable in that way. A new connection is established from the Transit PINX to the requesting PINX instead of from
the cooperating PINX to the requesting PINX.
6.2 ANF-PR operational requirements
6.2.1 Requirements on the cooperating PINX
ANF-PR shall be applicable to a call whose protocol control state, as defined in ISO/IEC 11572, is Active.
NOTE 5 - State Active will have been reached as a mult of ISO/IEC 11572 call establishment procedures, possibly in conjunction with supplementary
service andor ANF procedures.
ISO/reC 11572 protocol control procedures for call establishment at the outgoing side of an inter-PINX link shall
apply to the establishment of the new connection. ISO/IEC 11572 protocol control procedures for call clearing shall
apply to the release of the old connection in the event of successful switch over to tht: new connection.
Generic procedures for the call-related control of supplementary services, as specified in ISO/IEC 11582 for an end
PINX, shall apply.
6.2.2 Requirements on the requesting PINX
ANF-PR shall be applicable to a call whose protocol control state, as defined in ISO/IEC 11572, is Active.
NOTE 6 - State Active will have been reached as a result of ISODEC 11572 call establishment procedures possibly in conjunction with supplementary
service anaor ANF pmcedures.
ISO/reC 11572 protocol control procedures for call establishment at the incoming side of an inter-PINX link shall
apply to the establishment of the new connection. ISO/IEC 11572 protocol control procedures for call clearing shall
apply to the release of the old connection in the event of successful switch over to the new connection.
Generic procedures for the call-related control of supplementary services, as specified in ISOLE!C 11582 for an end
PINX, shall apply.
6.2.3 Requirements on a Transit PINX
6.2.3.1 Transit PINX involved in the replaced connection
ANF-PR shaIl be applicable to a call whose protocol control state, as defined in ISO/EC 11572, on each of the two
links (incoming and outgoing) is Active and whose call control state, as defined in ISO/IEC 11572 is
TCC-Call-Active.
NOTE 7 - State Active will have been reached as a result of ISO/IEC 11572 call establishment procedures, possibly in conjunction with supplementary
service and/or ANF procedures.
ISO/IEC 11572 protocol control and call control procedures for call clearing at ;i Transit PINX shall apply to the
release of the old connection in the event of successful switch over to the new connection.
Generic procedures for the call-related control of supplementary services, as specifiled in ISO/IEC 11582 for a Transit
PINX, shall apply. For ANF-PR the requirements are limited to the passing on of Facility information elements for
which the destination, as indicated in the Network Facility Extension (NFE), is not ithe Transit PINX.
6.2.3.2 Transit PINX involved in the new connection
ISO/IEC 11572 protocol control and call control procedures for call establishment at a Transit PINX shall apply to the
establishment of the new connection.
ISO/IEC 11572 protocol control and call control procedures for call clearing at ;î Transit PINX shall apply to the
release of the new connection in the event of failure to complete ANF-PR successfully.
Generic procedures for the cail-related control of supplementary services, as specified in ISOhEC 11582 for a Transit
PINX, shall apply. For ANF-PR the requirements are limited to the passing on oif Facility information elements for
which the destination, as indicated in the Network Facility Extension (NFE), is not the Transit PINX.
6.2.3.3 Transit PINX involved in the retained connection
The procedures below are applicable only if the optional procedures for retention of part of the old connection (6.6) are
supported.
O ISO/IEC ISOlXEC 138741995 (E)
ANF-PR shall be applicable to a call whose protocol control state, as defined in ISO/IEC 11572, on each of the two
links (incoming and outgoing) is Active and whose call control state, as defined in ISO/IEC 11572 is
TCC-Call-Active.
NOTE 8 - State Active will have been reached as a result of ISO/IEC 11572 call establishment procedures, possibly in conjunction with supplementary
service and/or ANF procedures.
Generic procedures for the call-related control of supplementary services, as specified in ISO/IEC 11582 for a Transit
PINX, shall apply.
6.2.3.4 Branching PINX
The procedures below are applicable only if the optional procedures for retention of part of the old connection (6.6) are
supported.
ANF-PR shall be applicable to a call whose protocol control state, as defined in ISO/IEC 11572, on each of the two
links (incoming and outgoing) is Active and whose call control state, as defined in ISO/IEC 11572 is
TCCCall-Active.
NOTE 9 - State Active will have been reached as a result of ISOLEC 11572 call establishment procedures, possibly in conjunction with supplementay
service and/or ANF procedures.
0 ISO/IEC 11572 protocol control procedures for call establishment at the outgoing side of an inter-PINX link shall
apply to the establishment of the new connection. ISO/IEC 11572 protocol control procedures for call clearing shall
apply to the release of the replaced connection in the event of successful switch over to the new connection.
Generic procedures for the call-related control of supplementary services, as specified in ISO/IEC 11582 for a Transit
PINX, shall apply.
6.3 ANF-PR coding requirements
6.3.1 Operations
The operations defined in Abstract Syntax Notation number 1 (ASN.l) in Table 1 shall apply.
O ISO/IEC
Table 1 - Operations in support of ANF-PR
2ath-Replacement-Operations
(iso standard pssl -path-replacement (1 3874) pr-operations (O))
I
3EFINITIONS EXPLICIT TAGS ::=
3EGIN
l
MPORTS OPERATION, ERROR FROM Remote-Operation-Notation
(joint-iso-ccitt(2) remote-operations(4) notation (O)}
Extension FROM Manufacturer-specific-service-extension-definition
(iso standard
pssl -generic-procedures (1 1582) msi-definition (O)}
notAvailable, supplementaryServiceInteractionNotAllowed
FROM General-Errors-List
(cciît recommendation q 950 general-error-list (1 )}
PartyNumber FROM Addressing-Data-Elements
{ iso( 1) sîandard(0) pss l-generic-procedures( 1 1582) addressing-data-elements(9)
,
t;
'ath ReplacePropose ::= OPERATION
ARG U M ENT P R Propose Arg
ERRORS {
notAvailable,
temporarily Unavailable,
supplernentaryServicelnteractionNotAllowed,
criteria Permanently Unachievable,
CriteriaTemporarily Unachievable,
invalidRerouteingNumber,
unrecognizedCalIIdentity ,
establishment Failure,
collision,
unspecified
'ath Replacesetup :I= OPERATION
ARGUMENT PRSetupArg
RESULT DummyResult
ERRORS {
criteria Permanently Unachievable,
criteriaTemporarily Unachievable,
invalidRerouteingNumber,
unrecognizedCallldentity ,
temporarily Unavailable,
unspecified
I
O ISO/IEC
Table 1 (continued)
--- . .-
'ath Replace Retain
OPERATION
ARGUMENT PRRetainArg
RESULT DummyResult
ERRORS {
not Available,
temporarily Unavailable,
supplementaryServicelnteract ionNotAllowed,
criteria Permanently Unachievable,
CriteriaTemporarily Unachievable,
invalidRerouteing Number,
unrecognizedCallldentity ,
establishment Failure,
unspecified
-
'RProposeArg .-
SEQUENCE {
callldentity Callldentity,
rerouteing Number
Party N u mber,
extension CHOICE {
[l] IMPLICIT Extension,
[2] IMPLICIT SEQUENCE OF Extension
} OPTIONAL
a*- .-
' RSetupArg
SEQUENCE {
callldentity Callldentity,
extension CHOICE {
[l] IMPLICIT Extension,
[2] IMPLICIT SEQUENCE OF Extension
} OPTIONAL
e.-
RRetainArg . .-
SEQUENCE {
callldentity Callldentity,
rerouteingNumber PartyNumber,
extension CHOICE {
[l] IMPLICIT Extension,
[2] IMPLICIT SEQUENCE OF Extension
1 OPTIONAL
..- . .-
)ummyResult
CHOICE {
NULL,
[l] IMPLICIT Extension,
[2] IMPLICIT SEQUENCE OF Extension
*a- . .-
iallldentity Numericstring (SIZE(1.4))
ISO/IEC 138741995 (E) O ISO/IEC
Table 1 (continued)
lathReplacePropose PathReplacePropose ::= 4
>at h Replacesetup PathReplaceSetup ::= 5
lathReplaceRetain PathReplaceRetain ::= 6
emporarily Unavailable
ERROR ::= 1000
-- used when the operation is temporarily not cavailable and none of
-- the other errors applies - a later attempt could be successful
allision ERROR ::= 1001
-- used when a pathRepiacePropose invoke APDU is received by a PlNX
-- which has sent a pathReplacePropose invoke APDU
xiteriapermanently Unachievable
ERROR ::= 1002
-- used when the special criteria requested ca.nnot be achieved
-- because the necessary resources are permanently unavailable
:riteriaTemporarilyUnachievable
ERROR ::= 1003
-- used when the special criteria requested cannot be achieved
-- because the necessary resources are templorarily unavailable
-- a later attempt could be successful
nvalidRerouteingNumber
ERROR ::= 1004
-- used when the establishment of the new connection fails because the
-- Called patty number information element is not a valid number for
-- routeing the new connection to
inrecognizedCallldentity
ERROR ::= 1005
-- used when establishment of the new connection fails because it could
-- not be associated with the old connection at the requesting PlNX
stablishmentFailure
ERROR ::= 1006
-- used when establishment of the new connoction fails and no other error
-- applies
Jnspecified ERROR PARAMETER Extension
inspecified Unspecified ::= 1008
-- used to convey a manufacturer specific error, possibly with other
nformation
-N D -- of Path-Replacement-Operations
6.3.2 Information elements
6.3.2.1 Facility information element
APDUs of the operations defined in 6.3.1 shall be coded in the Facility information element in accordance with
ISO/IE?C 11582.
O ISO/IEC ISO/IEC 13874:1995 (E)
When conveying APDUs of operations pathReplacePropose and patliReplaceSetup, the NFE shall be included.
When conveying the invoke APDU of operation pathReplacePropose, the destinationEntity data element of the NFE
shall contain value endPINX.
When conveying the invoke APDU of operation pathReplaceSetup, the destinationEntity data element of the NEB
shall contain value endPINX.
When conveying the invoke APDU of operation parneplacelietain, the "FE shall be omitted.
When conveying the invoke APDU of operation pathReplaceSetup, the Interpretation APDU shall be included and
shall have the value clearCallIfAnyInvokePduNotRecognised. When conveying any other Remote Operations APDU,
the Interpretation APDU shall either be omitted or have the value rejectAnyUnrecognisedInvokePdu.
6.3.2.2 Other information elements
The following information elements used during establishment of the new connection and release of the old
connection shall be coded as specified in ISO/iEC 11572:
- Bearer capability
- Called party number
- Cause
- Sending complete
6.3.3 Messages
Except for cases where a basic call message is to be conveyed at the same time, the Facility information shall be
conveyed in a FACILITY message as specified in ISO/IEC 11582.
The following messages used during establishment of the new connection and release of the old connection shall be as
specified in ISOE 11572:
- CALL PROCEEDING
- CONNECT
- CONNECT ACKNOWLEDGE
- DISCONNECT
- RELEASE
- RELEASE COMPLETE
- SETUP
6.4 ANF-PR state definitions
6.4.1 States at the requesting PINX
The procedures for the requesting PINX are written in terms of the following conceptual states existing within the
ANF-PR functional entity in that PINX in association with a particular call.
6.4.1.1 State PR-Req-Idle
ANF-PR is not operating.
6.4.1.2 State PR-Req-Initiated
A pathReplacePropose invoke APDU has been sent to the cooperating PINX.
6.4.1.3 State PR-Req-Completing
The new connection has been established and a pathReplaceSetup return result APDU has been sent to the cooperating
PINX.
6.4.2 States at the cooperating PINX
The procedures for the cooperating PINX are written in terms of the following conceptual states existing within the
ANF-PR functional entity in that PINX in association with a particular call.
6.4.2.1 State PR-Coop-Idle
ANF-PR is not operating.
6.4.2.2 State PR-Coop-Establishment
A pathReplaceSetup invoke APDU has been sent in conjunction with the establishment of the new connection.
6.4.2.3 State PR-Coop-Retain
A pathRep1aceReîa.h invoke APDU has been sent to the subsequent PINX.
6.4.3 States at a Transit PINX on the retained path, including the branching PINX
The procedures for a Transit PINX on the retained path are written in terms of the following conceptual states existing
within the ANF-PR functional entity in that PINX in association with a particular call.
6.4.3.1 State PR-Transit-Idle
ANF-PR is not operating.
6.4.3.2 State PR-Transit-Establishment
A pathReplaceSetup invoke APDU has been sent in conjunction with the establishment of the new connection.
6.4.3.3 State PR-Transit-Retain
A pathRep1aceReîa.h invoke APDU has been sent to the subsequent PINX.
6.5 ANF-PR signalling procedures
The signalling procedures specified below are in support of replacement of the entire connection. Additional optional
procedures for retention of part of the old connection are specified in 6.6.
Examples of message sequences are shown in C. 1 and C.2 of annex C.
6.5.1 Actions at the requesting PINX
The SDL representation of procedures at the requesting PINX is shown in D.l of annex D.
6.5.1.1 Normal procedures
On determining that ANF-PR is to be invoked during a call whose protocol control state is Active, the requesting
PINX shall send a pathReplacePropose invoke APDU in a FACILITY message to the cooperating PINX and enter
state PR-Req-Initiated. Within the argument, the rerouteingNumber data element shall contain a number from one of
the native numbering plans of the PISN (see ISO/IEC 11571). The number, when used as the contents of information
element Called party number in a SETUP message, shall be sufficient to cause routeing of the new connection to the
requesting PINX. The callIdentity data element shall contain a number which, in conjunction with the
rerouteingNumber data element, identifies the particular ANF-PR entity, and therefore the call on which ANF-PR is
being invoked. This number need not have significance outside the requesting PINX.
NOTE 10 - nie number in the callIdentity data element should be sufficient to distinguish the call concerned from any other call for which the PINX is
acting as an ANF-PR requesting PINX at that time.
Having agreed the B-channel and sent back a CALL PROCEEDING message in response to an incoming SETUP
message, in accordance with the procedures of ISO/iEC 11572, if the SETUP contains a pathReplaceSetup invoke
APDU the requesting PINX shall proceed as follows. If the callIdentity data element in the argument of
PathReplaceSetup, in conjunction with the number information in the Called party number information element,
identifies an ANF-PR entity in state PR-Req-Initiated, the requesting PINX shall associate the new connection (as
requested by the SETUP message) with the call on whose behalf that ANF-PR entity is acting.
/ called user to the B-channel of the new connection and terminate the
The requesting PINX shall connect the calling
B-channel of the old connection in a suitable manner (pending its release).
NOTE 11 - nie method of terminating the old connection's B-channel is an implementation matter. Annex B of ISO/IEC 13863 contains more
on this.
information
A pathReplaceSeîup return result MDU shall be sent in a CONNECT message using the call reference of the new
connection and state PR-Req-Completing shall be entered.
NOTE 12 - C~I sending CONNECT, the protocol control state for the new connection will become Adive.
O ISO/mC ISO/IEC 138741995 (E)
While in state PR-Req-Completing, if a DISCONNECT message is received using the call reference of the old
connection, the requesting PINX shall complete the release of the old connection in accordançe with the procedures of
ISOE 11572, and enter state PR-Req-Idle. The call shall continue as an active call using the new connection.
6.5.1.2 Exceptional procedures
Receipt of a FACILITY message containing a pathReplacePropose return error APDU or reject APDU during state
PR-Req-Initiated shall cause entry to state PR-Req-Idle, thereby abandoning ANF-PR. The call shall continue to use
the old connection.
NOTE 13 - Depending on the error, it may be appropriate to invoke ANF-PR again later. if the error is collision, steps should be taken to reduce the
probability of a fuither collision, e.g., by using a random delay before invoking again.
Failure to associate an incoming SETUP message containing a pathReplaceSetup invoke APDU with an ANF-PR
entity in state PR-Req-Initiated shall result in the sending of a DISCONNECT message to initiate the clearing of the
new connection. Depending on implementation, the DISCONNECT message shall contain either:
- a suitable cause number in the Cause information element, e.g., 1 "unallocated (unassigned) number"; or
- cause number 29 "facility rejected in the Cause information element and a return error APDU containing error
invalidRerouteingNumber: or
- cause number 29 "facility rejected" in the Cause information element and a return error APDU containing error
UnrecognizedCallIdentity .
If the incoming SETUP message containing a pathReplaceSetup invoke APDU is successfully associated with an
ANF-PR entity in state PR-Req-Initiated but the new connection is unsuitable for some reason, e.g., criteria not
satisfied, a DISCONNECT message shall be sent to initiate clearing of the new connection. The DISCONNECT
message shall contain cause number 29 "facility rejected" in the Cause information element and a return error APDU
containing an appropriate error. The ANF-PR entity shall remain in state PR-Req-Initiated.
NOTE 14 -Receipt of a patbReplacePropose return error APDU can be expected.
On receipt of a FACILITY message containing a pathReplacePropose invoke APDU while in state PR-Req-Initiated, a
pathReplacePropose return error APDU containing error collision shall be returned. No state change shall occur.
NOTE 15 -Receipt of a pathReplacePropose return error APDU containing error collision can be expected.
While in state PR-Req-Completing, if a DISCONNECT message is received using the call reference of the new
connection, the requesting PINX shall complete the release of the new connection in accordance with the procedures
of ISO/IEC 11572, reconnect the calling / called user to the B-channel of the old connection, and enter state
PR-Req-Idle.
6.5.2 Actions at the cooperating PINX
The SDL representation of procedures at the cooperating PINX is shown in D.2 of annex D.
6.5.2.1 Normal procedures
On receipt of a FACILITY message containing a pathReplacePropose invoke APDU while in protocol control state
Active and ANF-PR state PR-Coop-Idle, the cooperating PINX shall determine whether it can proceed with ANF-PR.
If so, it shall attempt to establish a new connection by selecting an outgoing B-channel on a route determined by the
contents of the rerouteingNumber data element within the received argument. If a B-channel is available, a SETUP
message shall be sent using a new call reference in accordance with the procedures of ISO/DEC 11572. The SETUP
shall contain a new call reference and the following information elements.
- Bearer capability, containing bearer capability information as for the old connection:
- Called party number, containing the number received in the rerouteingNumber data element within the received
argument:
- Sending complete:
- Facility.
The Facility information element shall contain a pathReplaceSetup invoke APDU. Within the argument, data element
callIdentity shall have the same contents as the corresponding data element in the argument of the received
pathReplacePropose invoke APDU.
ISO/IEC 138741995 (E) O ISO/IEC
The cooperating PINX shall terminate the new connection's B-channel suitably.
NOTE 16 - nie method of tenninating the new connection's B-channel is an implementation matter. Annex B of ISOAEC 13863 contains moFe
infonnation on this.
State PR-Coop-Establishment shall be entered.
The protocol control procedures of ISO/IEC 11572 shall apply during the establishment of the new connection.
NOTE 17 - initially protocol control will enter state Call initiated. On receipt of a CALL PROCEEDING message, state Outgoing Call Pmceedmg will
be entered and on receipt of CONNECT, state Active will be entered.
On receipt of a CONNECT message (using the call reference of the new connection) containing a pathReplaceSetup
return result APDU, the cooperating PINX shall disconnect the B-channel of the old connection and connect the
calling /called user instead to the B-channel of the new connection. A DISCONNECT message shall be sent using the
call reference of the old connection, thereby initiating the clearing procedures of ISO/IEC 11572 for the old
connection. State PR-Coop-Idle shall be entered. The call shall continue as an active call using the new connection.
6.5.2.2 Exceptional procedures
If the cooperating PINX is unable to comply with the pathReplacePropose invoke APDU, it shall send back a
FACILITY message containing a pathReplacePropose return error APDU with a suitable error.
If the new connection fails to be established for any reason, the cooperating PINX shall send using the old connection
a FACILITY message containing a pathReplacePropose return error APDU with a suitable error. Reasons can include:
- unable to select a B-channel for the new connection;
- receipt of a call clearing message using the new connection's call reference without a pathReplaceSetup return
error APDU or reject APDU;
- receipt of a call clearing message using the new connection's call reference with a pathReplaceSetup return error
APDU or reject APDU,
- timer expiry at the cooperating PINX.
In each case state PR-Coop-Idle shall be entered and the call shall continue as an active call using the old connection.
6.5.3 Actions at a cooperating/requesting PINX U1 the case of a trombone connection
On receipt of a FACILITY message containing a pathReplacePropose invoke APDU, the cooperating PINX can
determine from the rerouteingNumber data element in the argument whether the requesting PINX is the same as the
cooperating PINX, i.e., whether a trombone connection exists.
In the case of a trombone connection, establishment of the new connection and switching over to it will be intra-PINX
matters. The only further signalling which will occur at the Q reference point will be the clearing of the old
connection.
6.5.4 Actions at a Transit PINX
No special actions are required in support of ANF-PR.
6.6 ANF-PR optional signalling procedures for retention of part of the old connection
Examples of message sequences are shown in C.3 to C.5 of annex C
6.6.1 Actions at the requesting PINX
The procedures of 6.5.1 shall apply, with the following addition.
If the requesting PINX receives a FACILITY message containing a PathReplaCeRetain invoke APDU from the
preceding PINX, it shall send back a FACILITY message containing a pathReplaceRetain return result APDU and
enter state PR-Req-Idle.
6.6.2 Actions at the cooperating PINX
The SDL representation of procedures at the cooperating PINX, including optional retention of part of the old
connection, is shown in D.2 of annex D.
O ISO/IEC ISO/IEC 13874:1995 (E)
6.6.2.1 Normal procedures
On receipt of a FACILITY message containing a pathReplacePropose invoke APDU while in protocol control state
Active and ANF-PR state PR-Coop-Idle, the cooperating PINX shall determine whether it can proceed with ANF-PR,
and whether it can retain that part of the old connection as far as the subsequent PINX while still meeting any given
criteria. If so, it shall send a FACILITY message containing a pathReplaceRetain invoke APDU to the subsequent
PINX and enter state PR-Coop-Retain. The rerouteingNumber and callIdentity data elements shall have the same
contents as the corresponding data elements received in the pathReplacePropose invoke APDU.
NOTE 18 - The omission of the NFE from the Facility information element ensures that the APDU will be processed by the subsequent PiNX. If the
subsequent PINX does not suppoit these optional procedures it will send back a reject APDU.
If it cannot retain that part of the old connection as far as the subsequent PINX it shall proceed according to the
provisions of 6.5.2.
On receipt of a FACILITY message containing a PathReplaceRetain return result APDU from the subsequent PINX,
the cooperating PINX shaii enter state PR-Coop-Idle.
6.6.2.2 Exceptional procedures
On receipt of a FACILITY message containing a PathReplaceRetain return error APDU or reject APDU from the
subsequent PINX while in state PR-Coop-Retain, the cooperating PINX shall either, depending on the reason for the
error or reject APDU:
- proceed according to the provisions of 6.5.2, as if there had been no attempt to retain part of the old connection; or
- send back a FACILITY message containing a pathReplacePropose return error APDU with a suitable error to the
requesting PINX and enter state PR-Coop-Idle.
6.6.3 Actions at a Transit PINX on the retained connection
The SDL representation of procedures at a Transit PINX on the retained Connection is shown in D.3 of annex D.
On receipt of a FACILITY message containing a pathReplaceRetain invoke APDU from the preceding PINX while in
protocol control state Active and ANF-PR state PR-Transit-Idle, the Transit PINX shall determine whether it can
retain that part of the old connection as far as the subsequent PINX while still meeting any given criteria.
6.6.3.1 Able to retain old connection as far as subsequent PINX
6.6.3.1.1 Normal procedures
If the Transit PINX determines that it can retain that part of the old connection as far as the subsequent PINX, it shall
send a FACILITY message containing a pathReplaceRetain invoke APDU to the subsequent PINX and enter state PR-
Transit-Retain. The rerouteingNumber and caludentity data elements shall have the same contents as the
corresponding data elements in the received pathReplaceRetain invoke APDU.
NOTE 19 - The omission of the NFE from the Facility information element ensures that the AF'DU will be processed by the subsequent PINX. If the
subsequent PINX does not suppoit these optional procedures it will send back a reject AF'DU.
On receipt of a FACILITY message containing a pathReplaceRetain return result APDU from the subsequent PINX
while in state PR-Transit-Retain, the Transit PINX shall send a pathReplaceRetain return result APDU to the
preceding PINX and enter state PR-Transit-Idle.
6.6.3.1.2 Exceptional procedures
On receipt of a FACILITY message containing a PathReplaceRetain return error APDU or reject APDU from the
subsequent PINX while in state PR-Transit-Retain, the Transit PINX shall either, depending on the reason for the
error or reject APDU
- proceed according to the provisions of 6.6.3.2, as if there had been no attempt to retain the old connection as far as
the subsequent PINX, or
- send a pathReplaceRetain return error APDU to the preceding PINX and enter state PR-Transit-Idle.
O 1somc
ISO/lEC 138741995 (E)
6.6.3.2 Unable to retain old connection as far as subsequent PINX
6.6.3.2.1 Normal procedures
If the Transit PINX determines that it is unable to retain that part of the old connection as far as the subsequent PINX,
it shall attempt to establish a new connection by selecting an outgoing B-channel on a route determined by the
contents of the rerouteingNumber data element within the received argument. If a B-channel is available, a SETUP
message shall be sent using a new call reference in accordance with the procedures of ISODEC 11572. The SETUP
shall contain a new call reference and the following information elements.
- Bearer capability, containing bearer capability information as for the old connection;
- Called party number, containing the number received in the rerouteingNumber data element within the received
argument;
- Sending complete;
- Facility.
The Facility information element shall contain a pathReplaceSetup invoke APDU. Within the argument, data eleme
...








Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...