S tandard ECMA-309 2nd Edition - June 2001
Standardizing Information
and
Communication
Systems
Corporate Telecommunication Networks – Signalling Interworking between QSIG and H.323 – Call Diversion Supplementary Services
Phone: +41 22 849.60.00 - Fax: +41 22 849.60.01 - URL: http://www.ecma.ch - Internet: [email protected]
.
S tandard ECMA-309 2nd Edition - June 2001
Standardizing
Information
and
Communication
Systems
Corporate Telecommunication Networks – Signalling Interworking between QSIG and H.323 – Call Diversion Supplementary Services
Phone: +41 22 849.60.00 - Fax: +41 22 849.60.01 - URL: http://www.ecma.ch - Internet: [email protected] IW
ECMA-309.DOC
11-07-01 11,02
.
Brief History
This Standard is one of a series of ECMA Standards defining the interworking of services and signalling protocols deployed in Corporate telecommunication Networks (CNs). The series uses telecommunication concepts as developed by ITU-T and conforms to the framework of International Standards on Open Systems Interconnection as defined by ISO/IEC. It has been produced under ETSI work item DEN/ECMA-00194. This particular Standard defines the signalling protocol interworking for call diversion supplementary services between a Private Integrated Services Network (PISN) and a packet-based private telecommunications network based on the Internet Protocol (IP). It is further assumed that the protocol for the PISN part is that defined for the Q reference point (QSIG) and that the protocols for the IP-based network are based on ITU-T Recommendation H.323. This Standard is based upon the practical experience of ECMA member companies and the results of their active and continuous participation in the work of ISO/IEC JTC1, ITU-T, ETSI and other international and national standardization bodies. It represents a pragmatic and widely based consensus. This ECMA Standard is in complete alignment with International Standard ISO/IEC 21411:2001(E) to be published by ISO/IEC in 2001.
Adopted as 2nd Edition of Standard ECMA-309 by the General Assembly of June 2001.
.
- i -
Table of contents 1
Scope
1
2
Conformance
1
3
Normative references
1
4
Definitions 4 . 1 E x te r n a l d e f in itio n s 4.2 Other definitions 4.2.1 A s s o c ia tio n D 4.2.2 A s s o c ia tio n E 4.2.3 A s s o c ia tio n F 4.2.4 A s s o c ia tio n G 4.2.5 Entity A 4.2.6 Entity B 4.2.7 E n tity B’ 4.2.8 Entity C 4.2.9 Entity D 4.2.10 Entity E 4.2.11 Entity F 4.2.12 Entity G 4.2.13 Entity H 4.2.14 G a te w a y 4.2.15 Leg A 4.2.16 Leg B 4.2.17 L e g B’ 4.2.18 Leg C 4.2.19 Rerouting entity 4.2.20 S c e n a r io A 1 4.2.21 S c e n a r io A 2 4.2.22 S c e n a r io B1 4.2.23 S c e n a r io B2 4.2.24 S c e n a r io C1 4.2.25 S c e n a r io C2 4.2.26 S c e n a r io D 1 4.2.27 S c e n a r io D 2 4.2.28 S c e n a r io E 1 4.2.29 S c e n a r io E 2 4.2.30 S c e n a r io F 1 4.2.31 S c e n a r io F 2 4.2.32 S c e n a r io G 1 4.2.33 S c e n a r io G 2
2 2 2 2 2 2 2 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 4 4 4 4 4 4 4 4 4 4 4
- ii -
5 6
Acronyms Service architecture 6 . 1 S e r v ic e a r c h ite c tu r e f o r in v o c a tio n a n d o p e r a tio n 6.1.1 E CMA - 1 7 4 s e r v ic e a r c h ite c tu r e 6.1.2 H . 4 5 0 . 3 s e r v ic e a r c h ite c tu r e 6.1.3 S c e n a r io s f o r in te r w o r k in g 6.1.4 D e t e r min a t i o n o f t h e l o c a t i o n o f t h e r e r o u t i n g e n t i t y w h e n i n t e r w o r k in g 6.2 Service architecture for activation, deactivation and interrogation 6.2.1 E CMA - 1 7 4 s e r v ic e a r c h ite c tu r e 6.2.2 H . 4 5 0 . 3 s e r v ic e a r c h ite c tu r e 6.2.3 S c e n a r io s f o r in te r w o r k in g
4 5 5 5 5 6 7 7 7 8 8
7
Protocol interworking – General requirements
9
8
Protocol interworking – Messages and APDUs Scenario A1 Scenario A2 Scenario B1 Scenario B2 Scenario C1 Scenario C2 Scenario D1 Scenario D2 Scenario E1 Scenario E2 Scenario F1 Scenario F2 Scenario G1 Scenario G2
9 9 11 12 13 14 14 15 15 16 16 17 17 18 18
8.1 8.2 8.3 8.4 8.5 8.6 8.7 8.8 8.9 8.10 8.11 8.12 8.13 8.14
A n n e x A - I m p le m e n t a t io n C o n f o r m a n c e S t a t e m e n t ( I C S ) p r o f o r m a
19
A n n e x B - Ex a m p le m e s s a g e s e q u e n c e d ia g r a m s
31
1
Scope This Standard specifies signalling interworking between “QSIG” and “H.323” in support of call diversion supplementary services within a Corporate telecommunication Network (CN). “QSIG” is a signalling protocol that operates at the Q reference point between Private Integrated Services eXchanges (PINX) within a Private Integrated Services Network (PISN). The Q reference point is defined in ECMA-133. A PISN provides circuit-switched basic services and supplementary services to its users. QSIG is specified in other Standards, in particular ECMA-143 (call control in support of basic services), ECMA-165 (generic functional protocol for the support of supplementary services) and a number of standards specifying individual supplementary services. ECMA-174 specifies the QSIG protocol in support of call diversion services. “H.323” is a set of signalling protocols for the support of voice or multimedia communication within a packet network, in particular a packet network that uses the Internet Protocol (IP) as its network layer protocol (IP network). H.323 signalling protocols operate between endpoints in an IP network, either indirectly via one or more gatekeepers, or directly. An endpoint can be a terminal or a gateway to another network. H.323 is an “umbrella” recommendation referring to various ITU-T recommendations, in particular Recommendations H.225.0 and H.245 (basic communication capabilities) and Recommendation H.450.1 (generic functional protocol for the support of supplementary services). Recommendation H.450.3 specifies the H.323 protocol in support of call diversion services. NOTE H.450.3 applies only to the 1998 version of H.323 (also known as H.323 version 2) and to later versions. In both ECMA-174 (QSIG) and ITU-Recommendation H.450.3 (H.323), the call diversion supplementary services are Call Forwarding Unconditional (SS-CFU), Call Forwarding Busy (SS-CFB), Call Forwarding No Reply (SS-CFNR) and Call Deflection (SS-CD). These supplementary services apply during call establishment and provide diversion of an incoming call to another destination. Interworking between QSIG and H.323 permits a call originating at a user of a PISN to terminate at a user of an IP network, or a call originating at a user of an IP network to terminate at a user of a PISN. This Standard provides the following additional capabilities: •
a call originating from a PISN and destined for a user of an H.323 network to be diverted by the H.323 network to an alternative destination;
•
a call originating from an H.323 network and destined for a user of a PISN to be diverted by the PISN to an alternative destination;
•
a call destined for a user of a PISN to be diverted to an alternative destination where that alternative destination is in an H.323 network;
•
a call destined for a user of an H.323 network to be diverted to an alternative destination where that alternative destination is in a PISN.
This Standard is applicable to any interworking unit that can act as a gateway between a PISN employing QSIG and an IP network employing H.323.
2
Conformance In order to conform to this Standard, a gateway shall satisfy the requirements identified in the Implementation Conformance Statement (ICS) proforma in annex A.
3
Normative references The following standards contain provisions which, through reference in this text, constitute provisions of this Standard. All standards are subject to revision, and parties to agreements based on this Standard are encouraged to investigate the possibility of applying the most recent editions of the standards indicated below.
- 2 -
In the case of references to ECMA Standards that are aligned with ISO/IEC International Standards, the number of the appropriate ISO/IEC International Standard is given in brackets after the ECMA reference.
4
ECMA-133
Private Integrated Services Network (PISN) - Reference Configuration for PISN Exchanges (PINX) (International Standard ISO/IEC 11579-1)
ECMA-143
Private Integrated Services Network (PISN) - Circuit Mode Bearer Services - InterExchange Signalling Procedures and Protocol (International Standard ISO/IEC 11572)
ECMA-165
Private Integrated Services Network (PISN) - Generic Functional Protocol for the Support of Supplementary Services - Inter-Exchange Signalling Procedures and Protocol (International Standard ISO/IEC 11582)
ECMA-174
Private Integrated Services Network (PISN) - Inter-Exchange Signalling Protocol Call Diversion Supplementary Services (International Standard ISO/IEC 13873)
ECMA-307
Corporate Telecommunication Networks - Signalling Interworking between QSIG and H.323 - Generic Functional Protocol for the Support of Supplementary Services (International Standard ISO/IEC 21409)
ITU-T Rec. H.225.0
Call signalling protocols and media stream packetization for packet-based multimedia communication systems (1998 or later)
ITU-T Rec. H.245
Control protocol for multimedia communication (1998 or later)
ITU-T Rec. H.323
Packet-based multimedia communications systems (1998 or later)
ITU-T Rec. H.450.1
Generic functional protocol for the support of supplementary services in H.323 (1998)
ITU-T Rec. H.450.3
Call diversion supplementary service for H.323 (1998)
Definitions For the purposes of this Standard, the following definitions apply.
4.1
External definitions This Standard uses the following terms defined in other documents: – Call
(ECMA-307)
– Corporate telecommunication Network (CN)
(ECMA-307)
– Endpoint
(ITU-T Rec. H.323)
– Gatekeeper
(ITU-T Rec. H.323)
– IP network
(ECMA-307)
– Private Integrated Services Network (PISN)
(ECMA-307)
– Private Integrated services Network eXchange (PINX)
(ECMA-133)
Additionally the definitions in ECMA-174 and ITU-T Recommendation H.450.3 apply as appropriate.
4.2
Other definitions
4.2.1
A s s o c ia t io n D Signalling association between entity D and entity G.
4.2.2
A s s o c ia t io n E Signalling association between entity E and entity G.
4.2.3
A s s o c ia t io n F Signalling association between entity F and entity G.
4.2.4
A s s o c ia t io n G Signalling association between entity G and entity H.
- 3 -
4.2.5
En t it y A Signalling entity at the PINX or H.323 endpoint serving the calling user (user A).
4.2.6
En t it y B Signalling entity at the PINX serving the diverting user (user B) or H.323 entity that invokes diversion on behalf of user B.
4.2.7
En t it y B’ Signalling entity at the H.323 endpoint serving user B.
4.2.8
En t it y C Signalling entity at the PINX or H.323 endpoint serving the diverted-to-user (user C).
4.2.9
En t it y D Signalling entity at the PINX or H.323 endpoint serving an activating user.
4.2.10
En t it y E Signalling entity at the PINX or H.323 endpoint serving a deactivating user.
4.2.11
En t it y F Signalling entity at the PINX or H.323 endpoint serving an interrogating user.
4.2.12
En t it y G Signalling entity for activation / deactivation / interrogation at a PINX or H.323 endpoint serving a diverting endpoint.
4.2.13
En t it y H Signalling entity for restriction checking at a PINX or H.323 endpoint serving a diverted-to endpoint.
4.2.14
G a t e wa y A gateway as defined in H.323 specifically for the purpose of interworking with a network employing QSIG.
4.2.15
Le g A Call segment that lies between entity A and the rerouting entity.
4.2.16
Le g B Call segment that lies between the rerouting entity and entity B.
4.2.17
Le g B’ Call segment that lies between entity B and entity B’.
4.2.18
Le g C Call segment that lies between the rerouting entity and entity C.
4.2.19
R e r o u t in g e n t it y Signalling entity that initiates the rerouting of a call towards user C and clears the call towards user B.
4.2.20
S c e n a r io A 1 Interworking arrangement in which entity A (PINX A) is in the PISN and the rerouting entity is in the IP network.
4.2.21
S c e n a r io A 2 Interworking arrangement in which entity A (endpoint A) is in the IP network and the rerouting entity is in the PISN.
4.2.22
S c e n a r io B1 Interworking arrangement in which entity B (PINX B) is in the PISN and the rerouting entity is in the IP network.
- 4 -
5
4.2.23
S c e n a r io B2 Interworking arrangement in which entity B (diverting endpoint or its gatekeeper) is in the IP network and the rerouting entity is in the PISN.
4.2.24
S c e n a r io C 1 Interworking arrangement in which entity C (PINX C) is in the PISN and the rerouting entity is in the IP network.
4.2.25
S c e n a r io C 2 Interworking arrangement in which entity C (endpoint C) is in the IP network and the rerouting entity is in the PISN.
4.2.26
S c e n a r io D 1 Interworking arrangement in which entity D (PINX D) is in the PISN and entity G (endpoint G) is in the IP network.
4.2.27
S c e n a r io D 2 Interworking arrangement in which entity D (endpoint D) is in the IP network and entity G (PINX G) is in the PISN.
4.2.28
S c e n a r io E1 Interworking arrangement in which entity E (PINX E) is in the PISN and entity G (endpoint G) is in the IP network.
4.2.29
S c e n a r io E2 Interworking arrangement in which entity E (endpoint E) is in the IP network and entity G (PINX G) is in the PISN.
4.2.30
S c e n a r io F 1 Interworking arrangement in which entity F (PINX F) is in the PISN and entity G (endpoint G) is in the IP network.
4.2.31
S c e n a r io F 2 Interworking arrangement in which entity F (endpoint F) is in the IP network and entity G (PINX G) is in the PISN.
4.2.32
S c e n a r io G 1 Interworking arrangement in which entity G (PINX G) is in the PISN and entity H (endpoint H) is in the IP network.
4.2.33
S c e n a r io G 2 Interworking arrangement in which entity G (endpoint G) is in the IP network and entity H (PINX H) is in the PISN.
Acronyms APDU
Application Protocol Data Unit
CN
Corporate telecommunication Network
ICS
Implementation Conformance Statement
IP
Internet Protocol
PINX
Private Integrated services Network eXchange
PISN
Private Integrated Services Network
SS-CD
Supplementary Service Call Deflection
SS-CFB
Supplementary Service Call Forwarding Busy
SS-CFNR
Supplementary Service Call Forwarding No Reply
- 5 -
SS-CFU
6
Supplementary Service Call Forwarding Unconditional
Service architecture
6.1 6.1.1
Service architecture for invocation and operation EC M A - 1 7 4 s e r v ic e a r c h it e c t u r e The QSIG protocol for call diversion invocation and operation is based around four signalling entities or PINX types: •
entity A – the PINX serving the calling user (user A);
•
entity B – the PINX serving the diverting user (user B);
•
entity C – the PINX serving the diverted-to user (user C);
•
rerouting entity – the PINX that initiates the rerouting of the call towards user C and clears the call towards user B.
Where a user is in another network, the role of entity A, entity B or entity C is performed by the other network, the gateway PINX or the two in combination. However, from the QSIG point of view the role is performed by the gateway PINX. This can be represented diagrammatically as shown in figure 1.
Leg B Entity A
Leg A
Entity B
Rerouting entity Leg C
Entity C
Figure 1 – Call diversion architecture for QSIG From this it can be seen that there are three segments or “legs” to the call: •
leg A from entity A to the rerouting entity;
•
leg B from the rerouting entity to entity B;
•
leg C from the rerouting entity to entity C.
The QSIG protocol supports each of these three legs. The rerouting entity is constrained to be collocated with (in the same PINX as) entity A or entity B (or both if entity A and entity B are collocated). In addition, entity C can be collocated with the rerouting entity (and therefore with entity A and/or entity B). When an entity is collocated with the rerouting entity, the leg of the call concerned is internal to the physical PINX and therefore the QSIG protocol for that leg does not apply. 6.1.2
H . 4 5 0 . 3 s e r v ic e a r c h it e c t u r e The architecture shown above for QSIG applies also to H.450.3, except that PINXs are replaced by H.323 entities as follows: •
entity A – the calling endpoint;
•
entity B – the entity that invokes diversion on behalf of the diverting user;
•
entity B’ – the diverting endpoint;
•
entity C – the diverted-to endpoint;
•
rerouting entity – the entity that initiates the rerouting of the call towards user C and clears the call towards user B.
- 6 -
Where a user is in another network, the role of entity A, entities B and B’ or entity C is performed by the other network, the gateway, or the two in combination. However, from the H.450.3 point of view the role is performed by the gateway. This can be represented diagrammatically as shown in figure 2:
Leg B Entity A
Leg A
Entity B
Leg B’
Entity B’
Rerouting entity Leg C
Entity C
Figure 2 – Call diversion architecture for H.323 From this it can be seen that there are four segments or “legs” to the call: •
leg A from entity A to the rerouting entity;
•
leg B from the rerouting entity to entity B;
•
leg B’ from entity B to entity B’;
•
leg C from the rerouting entity to entity C.
The H.450.3 protocol supports each of these four legs. Entity B is either collocated with entity B’ at the diverting endpoint or is located separately in a gatekeeper acting on behalf of the diverting endpoint, e.g. for situations where B' is switched off since B' can be a PC. The rerouting entity can be collocated with entity A or entity B. Alternatively it can be at a separate device such as a gatekeeper or proxy. 6.1.3
Scenarios for interworking The architectures for QSIG and H.450.3 are very similar. The only difference is the absence of entity B’ and leg B’ from the QSIG architecture. This is not a fundamental difference, but merely reflects the fact that entity B’ and leg B’ are outside the scope of QSIG and therefore no QSIG protocol is required for leg B’. Normally leg B’ would correspond to the PISN access. This means that the H.450.3 architecture is applicable to the inter-networking situation between an IP network and a PISN, where one or more of the users involved are served by the IP network and the others are served by the PISN. In figure 2 interworking between H.450.3 and QSIG could theoretically occur on any of the four legs. However, interworking on leg B’ is of less practical use (a network is unlikely to invoke diversion on behalf of a diverting user in another network), and also is not possible because there is no support for leg B’ in QSIG. Therefore in practice the possible points of interworking occur on legs A, B and C. For each of the three possible points of interworking, two scenarios arise, depending on which side of the interworking point the PISN lies. This gives 6 scenarios in total that need to be considered: •
Scenario A1: Entity A (PINX A) in PISN, rerouting entity in IP network;
•
Scenario A2: Entity A (endpoint A) in IP network, rerouting entity in PISN;
•
Scenario B1: Entity B (PINX B) in PISN, rerouting entity in IP network;
•
Scenario B2: Entity B (diverting endpoint or its gatekeeper) in IP network, rerouting entity in PISN;
•
Scenario C1: Entity C (PINX C) in PISN, rerouting entity in IP network;
•
Scenario C2: Entity C (endpoint C) in IP network, rerouting entity in PISN.
- 7 -
It is possible for more than one scenario to apply to the same call. For example, if entity A and the rerouting entity are in a PISN and entities B and C are in the same IP network or different IP networks, interworking according to scenario B2 will apply on leg B and interworking according to scenario C2 will apply on leg C. A point of interworking will be implemented in a gateway, which acts as both an H.323 endpoint from the point of view of the IP network and an end PINX from the point of view of the PISN. Multiple scenarios can also occur because of multiple (chained) diversions. 6.1.4
Determination of the location of the rerouting entity when interworking The particular scenario (or scenarios) that applies depends not only on the location of the users concerned but also on the location of the rerouting entity. In each of the scenarios it is possible to locate the rerouting entity within the gateway. However, functionally the rerouting entity is separate from the point of interworking and belongs to user B’s network. When this occurs, interworking occurs on leg A (scenario A1 or A2). The possibility of siting the rerouting entity at the gateway arises when the gateway receives a rerouting request (QSIG or H.450.3 callRerouting invoke APDU) from entity B. Instead of creating a rerouting entity at the gateway, the gateway can choose to pass the rerouting request on into the other network towards entity A. In this case interworking occurs on leg B (scenario B1 or B2). In either case, interworking can also occur on leg C (scenario C1 or C2) if entity C is not in the same type of network as the rerouting entity. The gateway’s decision whether to provide the rerouting entity is an implementation matter. This can, but need not, take account of the address of user C. The behaviour of the rerouting entity, if provided at the gateway, is outside the scope of this Standard and is assumed to be in accordance with the requirements of ECMA-174 (for rerouting requests received from the PISN) or in accordance with the requirements of H.450.3 (for rerouting requests received from the IP network).
6.2 6.2.1
Service architecture for activation, deactivation and interrogation EC M A - 1 7 4 s e r v ic e a r c h it e c t u r e The QSIG protocol for call diversion activation, deactivation and interrogation is based around three signalling entities or PINX types: •
entity D – a PINX serving an activating user;
•
entity E – a PINX serving a deactivating user;
•
entity F – a PINX serving an interrogating user;
•
entity G – a PINX serving a diverting user;
•
entity H – a PINX serving a diverted-to user.
Where a user is in another network, the role of the entity concerned is performed by the other network, the gateway PINX or the two in combination. However, from the QSIG point of view the role is performed by the gateway PINX. This can be represented diagrammatically as shown in figure 3.
- 8 -
Entity D Association D
Entity E
Entity F
Association E
Entity G
Association G
Entity H
Association F
F ig u r e 3 – C a ll d iv e r s io n a c t iv a t io n / d e a c t iv a t io n / in t e r r o g a t io n a r c h it e c t u r e f o r Q S I G From this it can be seen that there are four associations between entities: •
association D between entity D and entity G;
•
association E between entity E and entity G;
•
association F between entity F and entity G;
•
association G between entity G and entity H.
Associations D, E and F apply to activation, deactivation and interrogation respectively. Association G applies to activation and allows entity G to check with entity H whether there are any restrictions that prevent activation of diversion. The QSIG protocol supports each of these four associations. 6.2.2
H . 4 5 0 . 3 s e r v ic e a r c h it e c t u r e The architecture shown above for QSIG applies also to H.450.3, except that PINXs are replaced by H.323 entities as follows: •
entity D – an activating endpoint;
•
entity E – a deactivating endpoint;
•
entity F – an interrogating endpoint;
•
entity G – a diverting endpoint or gatekeeper;
•
entity H – a diverted-to endpoint.
Where a user is in another network, the role of the entity concerned is performed by the other network, the gateway, or the two in combination. However, from the H.450.3 point of view the role is performed by the gateway. As for QSIG, there are four associations: D, E, F and G. The H.450.3 protocol supports each of these four associations. 6.2.3
Scenarios for interworking Because the architectures for QSIG and H.450.3 are the same, this architecture is applicable to the internetworking situation between an IP network and a PISN, where one or more of the users involved are served by the IP network and the others are served by the PISN. In figure 3, interworking between H.450.3 and QSIG can occur on any of the four associations. For each of the four possible points of interworking, two scenarios arise, depending on which side of the interworking point the PISN lies. This gives 8 scenarios in total that need to be considered: •
Scenario D1: Entity D (PINX D) in PISN, entity G (endpoint G) in IP network;
- 9 -
•
Scenario D2: Entity D (endpoint D) in IP network, entity G (PINX G) in PISN;
•
Scenario E1: Entity E (PINX E) in PISN, entity G (endpoint G) in IP network;
•
Scenario E2: Entity E (endpoint E) in IP network, entity G (PINX G) in PISN;
•
Scenario F1: Entity F (PINX F) in PISN, entity G (endpoint G) in IP network;
•
Scenario F2: Entity F (endpoint F) in IP network, entity G (PINX G) in PISN;
•
Scenario G1: Entity G (PINX G) in PISN, entity H (endpoint H) in IP network;
•
Scenario G2: Entity G (endpoint G) in IP network, entity H (PINX H) in PISN.
A point of interworking will be implemented in a gateway, which acts as both an H.323 endpoint from the point of view of the IP network and an end PINX from the point of view of the PISN.
7
Protocol interworking – General requirements Protocol interworking between H.323 and QSIG for call diversion supplementary services shall be in accordance with ECMA-307, as modified by the requirements of clause 8. When transmitting an APDU in one protocol as a result of receiving the corresponding APDU in the other protocol, the mapping of elements in the received APDU to corresponding elements in the transmitted APDU shall be in accordance with ECMA-307, where applicable. Optional elements of one protocol that have no corresponding element in the other protocol shall be discarded if received.
8
Protocol interworking – Messages and APDUs In the rules specified below for the different scenarios, the following shall apply: 1.
If the required action is to transmit a QSIG or H.323 FACILITY message but the call state does not permit a FACILITY message to be sent at that time, the action to be taken is an implementation matter.
2.
If the required action is to include an APDU in a transmitted QSIG or H.323 message conditional upon that message being transmitted and that message is not to be transmitted (owing to basic call interworking considerations), the action to be taken is an implementation matter.
3.
If the required action is dependent on the call independent signalling connection extending or being able to be extended into the other network and this cannot be achieved, the action to be taken is an implementation matter.
Annex B shows in diagrammatic form some typical message sequences for some of the scenarios identified in this Standard.
8.1
Scenario A1 A gateway that supports scenario A1 shall behave in accordance with the rules of table 1, by carrying out the required action when a given condition occurs. Each condition applies to the receipt of an H.323 message from a rerouting entity, whether this be located in the gateway or in a separate physical entity in the IP network.
- 10 -
Ta b le 1 – M e s s a g e a n d A P D U h a n d lin g r e q u ir e m e n t s f o r s c e n a r io A 1 Rule
Condition
Required action
1
Receipt of an H.323 FACILITY message containing an H.323 divertingLegInformation1 invoke APDU in the backward direction, no H.323 CONNECT message having been received.
Transmit a QSIG FACILITY message containing a QSIG divertingLegInformation1 invoke APDU if the QSIG call state permits.
2
Receipt of an H.323 CONNECT message containing an H.323 divertingLegInformation1 invoke APDU.
If a QSIG CONNECT message is to be transmitted, include in the QSIG CONNECT message a QSIG divertingLegInformation1 invoke APDU.
3
Receipt of an H.323 ALERTING message containing an H.323 divertingLegInformation3 invoke APDU.
If a QSIG ALERTING message is to be transmitted, include in the QSIG ALERTING message a QSIG divertingLegInformation3 invoke APDU.
4
Receipt of an H.323 FACILITY message containing an H.323 divertingLegInformation3 invoke APDU in the backward direction, no H.323 CONNECT message having been received.
Transmit a QSIG FACILITY message containing a QSIG divertingLegInformation3 invoke APDU if the QSIG call state permits.
5
Receipt of an H.323 CONNECT message containing an H.323 divertingLegInformation3 invoke APDU.
If a QSIG CONNECT message is to be transmitted, include in the QSIG CONNECT message a QSIG divertingLegInformation3 invoke APDU.
- 11 -
8.2
Scenario A2 A gateway that supports scenario A2 shall behave in accordance with the rules of table 2, by carrying out the required action when a given condition occurs. Each condition applies to the receipt of a QSIG message from a rerouting entity, whether this be located in the gateway or in a separate physical entity in the PISN. Ta b le 2 – M e s s a g e a n d A P D U h a n d lin g r e q u ir e m e n t s f o r s c e n a r io A 2
Rule
Condition
Required action
1
Receipt of a QSIG FACILITY message containing a QSIG divertingLegInformation1 invoke APDU in the backward direction, no QSIG CONNECT message having been received.
Transmit an H.323 FACILITY message containing an H.323 divertingLegInformation1 invoke APDU if the H.323 call state permits.
2
Receipt of a QSIG CONNECT message containing a QSIG divertingLegInformation1 invoke APDU.
If an H.323 CONNECT message is to be transmitted, include in the H.323 CONNECT message an H.323 divertingLegInformation1 invoke APDU.
3
Receipt of a QSIG ALERTING message containing a QSIG divertingLegInformation3 invoke APDU.
If an H.323 ALERTING message is to be transmitted, include in the H.323 ALERTING message an H.323 divertingLegInformation3 invoke APDU.
4
Receipt of a QSIG FACILITY message containing a QSIG divertingLegInformation3 invoke APDU in the backward direction, no QSIG CONNECT message having been received.
Transmit an H.323 FACILITY message containing an H.323 divertingLegInformation3 invoke APDU if the H.323 call state permits.
5
Receipt of a QSIG CONNECT message containing a QSIG divertingLegInformation3 invoke APDU.
If an H.323 CONNECT message is to be transmitted, include in the H.323 CONNECT message an H.323 divertingLegInformation3 invoke APDU.
6
Receipt of a QSIG NOTIFY message containing notification “call is diverting” (NOTE 1). This can be accompanied by notification “pss1IeNotification” with embedded public ISDN Redirection number information element.
Transmit an H.323 FACILITY message containing an H.323 divertingLegInformation1 invoke APDU if the H.323 call state permits (NOTE 2).
7
Receipt of a QSIG CONNECT message containing no QSIG divertingLegInformation3 invoke APDU, subsequent to transmitting an H.323 FACILITY message containing an H.323 divertingLegInformation1 invoke APDU in accordance with rule 6.
If an H.323 CONNECT message is to be transmitted, include in the H.323 CONNECT message an H.323 divertingLegInformation3 invoke APDU.
NOTE 1 This can arise as a result of the PISN routing the call on into a public ISDN, where diversion occurs. NOTE 2 If no embedded public ISDN Redirection number information element is received, mandatory element nominatedNr in the H.323 divertingLegInformation1 invoke APDU shall be coded to indicate that no address is available.
- 12 -
8.3
Scenario B1 A gateway that supports scenario B1 shall behave in accordance with the rules of table 3, by carrying out the required action when a given condition occurs. Each condition applies to the receipt of an H.323 message from a rerouting entity, whether this be located in the gateway or in a separate physical entity in the IP network, or the receipt of a QSIG message from entity B. Ta b le 3 – M e s s a g e a n d A P D U h a n d lin g r e q u ir e m e n t s f o r s c e n a r io B1
Rule
Condition
Required action
1
Receipt of a QSIG FACILITY message containing a QSIG callRerouting invoke APDU in the backward direction, no QSIG CONNECT message having been received.
Transmit an H.323 FACILITY message containing an H.323 callRerouting invoke APDU if the H.323 call state permits.
2
Receipt of an H.323 FACILITY message containing an H.323 callRerouting return result APDU in response to an H.323 callRerouting invoke APDU.
Transmit a QSIG FACILITY message containing a QSIG callRerouting return result APDU if the QSIG call state permits.
3
Receipt of an H.323 RELEASE COMPLETE message containing an H.323 callRerouting return result APDU in response to an H.323 callRerouting invoke APDU.
Transmit a QSIG DISCONNECT message containing a QSIG callRerouting return result APDU if the QSIG call state permits.
4
Receipt of an H.323 FACILITY message containing an H.323 callRerouting return error APDU in response to an H.323 callRerouting invoke APDU.
Transmit a QSIG FACILITY message containing a QSIG callRerouting return error APDU if the QSIG call state permits.
5
Receipt of an H.323 RELEASE COMPLETE message containing an H.323 callRerouting return error APDU in response to an H.323 callRerouting invoke APDU.
Transmit a QSIG DISCONNECT message containing a QSIG callRerouting return error APDU if the QSIG call state permits.
6
Receipt of an H.323 FACILITY message containing an H.323 cfnrDivertedLegFailed invoke APDU in the forward direction
Transmit a QSIG FACILITY message containing a QSIG cfnrDivertedLegFailed invoke APDU if the QSIG call state permits.
- 13 -
8.4
Scenario B2 A gateway that supports scenario B2 shall behave in accordance with the rules of table 4, by carrying out the required action when a given condition occurs. Each condition applies to the receipt of a QSIG message from a rerouting entity, whether this be located in the gateway or in a separate physical entity in the PISN, or receipt of an H.323 message from entity B. Ta b le 4 – M e s s a g e a n d A P D U h a n d lin g r e q u ir e m e n t s f o r s c e n a r io B2
Rule
Condition
Required action
1
Receipt of an H.323 FACILITY message containing an H.323 callRerouting invoke APDU in the backward direction, no H.323 CONNECT message having been received.
Transmit a QSIG FACILITY message containing a QSIG callRerouting invoke APDU if the QSIG call state permits.
2
Receipt of a QSIG FACILITY message containing a QSIG callRerouting return result APDU in response to a QSIG callRerouting invoke APDU.
Transmit an H.323 FACILITY message containing an H.323 callRerouting return result APDU if the H.323 call state permits.
3
Receipt of a QSIG DISCONNECT message containing a QSIG callRerouting return result APDU in response to a QSIG callRerouting invoke APDU.
Transmit an H.323 RELEASE COMPLETE message containing an H.323 callRerouting return result APDU if the H.323 call state permits.
4
Receipt of a QSIG FACILITY message containing a QSIG callRerouting return error APDU in response to a QSIG callRerouting invoke APDU.
Transmit an H.323 FACILITY message containing an H.323 callRerouting return error APDU if the H.323 call state permits.
4
Receipt of a QSIG DISCONNECT message containing a QSIG callRerouting return error APDU in response to a QSIG callRerouting invoke APDU.
Transmit an H.323 RELEASE COMPLETE message containing an H.323 callRerouting return error APDU if the H.323 call state permits.
6
Receipt of a QSIG FACILITY message containing a QSIG cfnrDivertedLegFailed invoke APDU in the forward direction.
Transmit an H.323 FACILITY message containing an H.323 cfnrDivertedLegFailed invoke APDU if the H.323 call state permits.
- 14 -
8.5
Scenario C1 A gateway that supports scenario C1 shall behave in accordance with the rules of table 5, by carrying out the required action when a given condition occurs. Each condition applies to the receipt of an H.323 message from a rerouting entity, whether this be located in the gateway or in a separate physical entity in the IP network, or receipt of a QSIG message from entity C. Ta b le 5 – M e s s a g e a n d A P D U h a n d lin g r e q u ir e m e n t s f o r s c e n a r io C 1
Rule
Condition
Required action
1
Receipt of an H.323 SETUP message containing an H.323 divertingLegInformation2 invoke APDU.
If a QSIG SETUP message is to be transmitted, include in the QSIG SETUP message a QSIG divertingLegInformation2 invoke APDU.
2
Receipt of a QSIG ALERTING message containing a QSIG divertingLegInformation3 invoke APDU.
If an H.323 ALERTING message is to be transmitted, include in the H.323 ALERTING message an H.323 divertingLegInformation3 invoke APDU.
3
Receipt of a QSIG FACILITY message containing a QSIG divertingLegInformation3 invoke APDU in the backward direction, no QSIG CONNECT message having been received.
Transmit an H.323 FACILITY message containing an H.323 divertingLegInformation3 invoke APDU if the H.323 call state permits.
4
Receipt of a QSIG CONNECT message containing a QSIG divertingLegInformation3 invoke APDU.
If an H.323 CONNECT message is to be transmitted, include in the H.323 CONNECT message an H.323 divertingLegInformation3 invoke APDU.
8.6
Scenario C2 A gateway that supports scenario C2 shall behave in accordance with the rules of table 6, by carrying out the required action when a given condition occurs. Each condition applies to the receipt of a QSIG message from a rerouting entity, whether this be located in the gateway or in a separate physical entity in the PISN, or the receipt of an H.323 message from entity C. Ta b le 6 – M e s s a g e a n d A P D U h a n d lin g r e q u ir e m e n t s f o r s c e n a r io C 2
Rule
Condition
Required action
1
Receipt of a QSIG SETUP message containing a QSIG divertingLegInformation2 invoke APDU.
If an H.323 SETUP message is to be transmitted, include in the H.323 SETUP message an H.323 divertingLegInformation2 invoke APDU.
2
Receipt of an H.323 ALERTING message containing an H.323 divertingLegInformation3 invoke APDU.
If a QSIG ALERTING message is to be transmitted, include in the QSIG ALERTING message a QSIG divertingLegInformation3 invoke APDU.
3
Receipt of an H.323 FACILITY message containing an H.323 divertingLegInformation3 invoke APDU in the backward direction, no QSIG CONNECT message having been received.
Transmit a QSIG FACILITY message containing a QSIG divertingLegInformation3 invoke APDU if the QSIG call state permits.
4
Receipt of an H.323 CONNECT message containing an H.323 divertingLegInformation3 invoke APDU.
If a QSIG CONNECT message is to be transmitted, include in the QSIG CONNECT message a QSIG divertingLegInformation3 invoke APDU.
- 15 -
8.7
Scenario D1 A gateway that supports scenario D1 shall behave in accordance with the rules of table 7, by carrying out the required action when a given condition occurs. Each condition applies to the receipt of a QSIG message from entity D or an H.323 message from entity G. Ta b le 7 – M e s s a g e a n d A P D U h a n d lin g r e q u ir e m e n t s f o r s c e n a r io D 1
Rule
Condition
Required action
1
Receipt of a QSIG activateDiversionQ invoke APDU carried on a call independent signalling connection.
If the call independent signalling connection extends or is able to be extended into the IP network, transmit an H.323 activateDiversionQ invoke APDU.
2
Receipt of an H.323 activateDiversionQ return result APDU carried on a call independent signalling connection in response to an H.323 activateDiversionQ invoke APDU.
Transmit a QSIG activateDiversionQ return result APDU.
3
Receipt of an H.323 activateDiversionQ return error APDU carried on a call independent signalling connection in response to an H.323 activateDiversionQ invoke APDU.
Transmit a QSIG activateDiversionQ return error APDU.
8.8
Scenario D2 A gateway that supports scenario D2 shall behave in accordance with the rules of table 8, by carrying out the required action when a given condition occurs. Each condition applies to the receipt of an H.323 message from entity D or a QSIG message from entity G. Ta b le 8 – M e s s a g e a n d A P D U h a n d lin g r e q u ir e m e n t s f o r s c e n a r io D 2
Rule
Condition
Required action
1
Receipt of an H.323 activateDiversionQ invoke APDU carried on a call independent signalling connection.
If the call independent signalling connection extends or is able to be extended into the PISN, transmit a QSIG activateDiversionQ invoke APDU.
2
Receipt of a QSIG activateDiversionQ return result APDU carried on a call independent signalling connection in response to a QSIG activateDiversionQ invoke APDU.
Transmit an H.323 activateDiversionQ return result APDU.
3
Receipt of a QSIG activateDiversionQ return error APDU carried on a call independent signalling connection in response to a QSIG activateDiversionQ invoke APDU.
Transmit an H.323 activateDiversionQ return error APDU.
- 16 -
8.9
Scenario E1 A gateway that supports scenario E1 shall behave in accordance with the rules of table 9, by carrying out the required action when a given condition occurs. Each condition applies to the receipt of a QSIG message from entity E or an H.323 message from entity G. Ta b le 9 – M e s s a g e a n d A P D U h a n d lin g r e q u ir e m e n t s f o r s c e n a r io E1
Rule
Condition
Required action
1
Receipt of a QSIG deactivateDiversionQ invoke APDU carried on a call independent signalling connection.
If the call independent signalling connection extends or is able to be extended into the IP network, transmit an H.323 deactivateDiversionQ invoke APDU.
2
Receipt of an H.323 deactivateDiversionQ return result APDU carried on a call independent signalling connection in response to an H.323 deactivateDiversionQ invoke APDU.
Transmit a QSIG deactivateDiversionQ return result APDU.
3
Receipt of an H.323 deactivateDiversionQ return error APDU carried on a call independent signalling connection in response to an H.323 deactivateDiversionQ invoke APDU.
Transmit a QSIG deactivateDiversionQ return error APDU.
8.10
Scenario E2 A gateway that supports scenario E2 shall behave in accordance with the rules of table 10, by carrying out the required action when a given condition occurs. Each condition applies to the receipt of an H.323 message from entity E or a QSIG message from entity G. Ta b le 1 0 – M e s s a g e a n d A P D U h a n d lin g r e q u ir e m e n t s f o r s c e n a r io E2
Rule
Condition
Required action
1
Receipt of an H.323 deactivateDiversionQ invoke APDU carried on a call independent signalling connection
If the call independent signalling connection extends or is able to be extended into the PISN, transmit a QSIG deactivateDiversionQ invoke APDU.
2
Receipt of a QSIG deactivateDiversionQ return result APDU carried on a call independent signalling connection in response to a QSIG deactivateDiversionQ invoke APDU.
Transmit an H.323 deactivateDiversionQ return result APDU.
3
Receipt of a QSIG deactivateDiversionQ return error APDU carried on a call independent signalling connection in response to a QSIG deactivateDiversionQ invoke APDU.
Transmit an H.323 deactivateDiversionQ return error APDU.
- 17 -
8.11
Scenario F1 A gateway that supports scenario F1 shall behave in accordance with the rules of table 11, by carrying out the required action when a given condition occurs. Each condition applies to the receipt of a QSIG message from entity F or an H.323 message from entity G. Ta b le 1 1 – M e s s a g e a n d A P D U h a n d lin g r e q u ir e m e n t s f o r s c e n a r io F 1
Rule
Condition
Required action
1
Receipt of a QSIG interrogateDiversionQ invoke APDU carried on a call independent signalling connection.
If the call independent signalling connection extends or is able to be extended into the IP network, transmit an H.323 interrogateDiversionQ invoke APDU.
2
Receipt of an H.323 interrogateDiversionQ return result APDU carried on a call independent signalling connection in response to an H.323 interrogateDiversionQ invoke APDU.
Transmit a QSIG interrogateDiversionQ return result APDU.
3
Receipt of an H.323 interrogateDiversionQ return error APDU carried on a call independent signalling connection in response to an H.323 interrogateDiversionQ invoke APDU.
Transmit a QSIG interrogateDiversionQ return error APDU.
8.12
Scenario F2 A gateway that supports scenario F2 shall behave in accordance with the rules of table 12, by carrying out the required action when a given condition occurs. Each condition applies to the receipt of an H.323 message from entity F or a QSIG message from entity G. Ta b le 1 2 – M e s s a g e a n d A P D U h a n d lin g r e q u ir e m e n t s f o r s c e n a r io F 2
Rule
Condition
Required action
1
Receipt of an H.323 interrogateDiversionQ invoke APDU carried on a call independent signalling connection.
If the call independent signalling connection extends or is able to be extended into the PISN, transmit a QSIG interrogateDiversionQ invoke APDU.
2
Receipt of a QSIG interrogateDiversionQ return result APDU carried on a call independent signalling connection in response to a QSIG interrogateDiversionQ invoke APDU.
Transmit an H.323 interrogateDiversionQ return result APDU.
3
Receipt of a QSIG interrogateDiversionQ return error APDU carried on a call independent signalling connection in response to a QSIG interrogateDiversionQ invoke APDU.
Transmit an H.323 interrogateDiversionQ return error APDU.
- 18 -
8.13
Scenario G1 A gateway that supports scenario G1 shall behave in accordance with the rules of table 13, by carrying out the required action when a given condition occurs. Each condition applies to the receipt of a QSIG message from entity G or an H.323 message from entity H. Ta b le 1 3 – M e s s a g e a n d A P D U h a n d lin g r e q u ir e m e n t s f o r s c e n a r io G 1
Rule
Condition
Required action
1
Receipt of a QSIG checkRestriction invoke APDU carried on a call independent signalling connection.
If the call independent signalling connection extends or is able to be extended into the IP network, transmit an H.323 checkRestriction invoke APDU.
2
Receipt of an H.323 checkRestriction return result APDU carried on a call independent signalling connection in response to an H.323 checkRestriction invoke APDU.
Transmit a QSIG checkRestriction return result APDU.
3
Receipt of an H.323 checkRestriction return error APDU carried on a call independent signalling connection in response to an H.323 checkRestriction invoke APDU.
Transmit a QSIG checkRestriction return error APDU.
8.14
Scenario G2 A gateway that supports scenario G2 shall behave in accordance with the rules of table 14, by carrying out the required action when a given condition occurs. Each condition applies to the receipt of an H.323 message from entity G or a QSIG message from entity H. Ta b le 1 4 – M e s s a g e a n d A P D U h a n d lin g r e q u ir e m e n t s f o r s c e n a r io G 2
Rule
Condition
Required action
1
Receipt of an H.323 checkRestriction invoke APDU carried on a call independent signalling connection.
If the call independent signalling connection extends or is able to be extended into the PISN, transmit a QSIG checkRestriction invoke APDU.
2
Receipt of a QSIG checkRestriction return result APDU carried on a call independent signalling connection in response to a QSIG checkRestriction invoke APDU.
Transmit an H.323 checkRestriction return result APDU.
3
Receipt of a QSIG checkRestriction return error APDU carried on a call independent signalling connection in response to a QSIG checkRestriction invoke APDU.
Transmit an H.323 checkRestriction return error APDU.
- 19 -
Annex A ( n o r ma tiv e )
Implementation Conformance Statement (ICS) proforma
A.1
Introduction
A.1.1
Purpose of an ICS proforma The supplier of an implementation which is claimed to conform to this Standard shall complete the following Implementation Conformance Statement (ICS) proforma. A completed ICS proforma is the ICS for the implementation in question. The ICS is a statement of which capabilities and options have been implemented for a given specification. The ICS can have a number of uses, including use: − by the implementor, as a check list for implementations to reduce the risk of unintended nonconformance, e.g. through oversight; − by the supplier and acquirer, or potential acquirer, of the implementation, as a detailed indication of the capabilities of the implementation, stated relative to the common basis for understanding provided by the Standard's ICS proforma; − by the user or potential user of the implementation, as a basis for initially checking the possibility of interworking with another implementation - while interworking can never be guaranteed, failure to interwork can often be predicted from incompatible ICS; − by a tester, as the basis for selecting appropriate tests against which to assess the claim for conformance of the implementation.
A.2
Instructions for completing the ICS proforma
A.2.1
General structure of the ICS proforma The ICS proforma is a fixed format questionnaire divided into sub-clauses each containing a group of individual items. Each item is identified by an item reference, the description of the item (question to be answered), and the reference(s) to the clause(s) that specifies (specify) the item in the main body of this Standard. The "Conditions for Status" column contains a specification, if appropriate, of the predicate upon which a conditional status is based. The indication of an item reference in this column indicates a simple-predicate condition (support of this item is dependent on the support marked for the referenced item). The “Status” column indicates whether an item is applicable and if so whether support is mandatory or optional. The following terms are used: I
irrelevant or out-of-scope - this capability is outside the scope of the standard to which this ICS proforma applies and is not subject to conformance testing in this context;
M
mandatory (the capability is required for conformance to the standard);
N/A
not applicable - in the given context, it is impossible to use the capability; no answer in the support column is required;
O
optional (the capability is not required for conformance to the standard, but if the capability is implemented it is required to conform to the specification in this Standard);
- 20 -
O.<n>
qualified optional - in this case, <n> is an integer that identifies a unique group of related optional items; if no additional qualification is indicated, the support of at least one of the optional items is required for conformance to this Standard; otherwise, the qualification and logic of the selection among the optional items is defined below the table explicitly;
X
excluded or prohibited - there is a requirement not to use this capability in a given context.
Answers to the questionnaire items are to be provided in the “Support” column, by simply marking an answer to indicate a restricted choice (Yes, No or N/A). In specific cases, the indication of explicit values may be requested. Where a support column box is left blank, no answer is required. If a "prerequisite line" (see A.2.4 below) is used after a subclause heading or table title, and its predicate is false, no answer is required for the whole subclause or table, respectively.
A.2.2
Additional Information Items of Additional Information allow a supplier to provide further information intended to assist the interpretation of the ICS. It is not intended or expected that a large quantity will be supplied, and an ICS can be considered complete without any such information. Examples might be an outline of the ways in which a (single) implementation can be set up to operate in a variety of environments and configurations. References to items of Additional Information may be entered next to any answer in the questionnaire, and may be included in items of Exception Information.
A.2.3
Exception Information It may occasionally happen that a supplier will wish to answer an item with mandatory or prohibited status (after any conditions have been applied) in a way that conflicts with the indicated requirement. No preprinted answer will be found in the Support column for this. Instead, the supplier is required to write into the support column an x.<i> reference to an item of Exception Information, and to provide the appropriate rationale in the Exception item itself. An implementation for which an Exception item is required in this way does not conform to this Standard. A possible reason for the situation described above is that a defect in the standard has been reported, a correction for which is expected to change the requirement not met by the implementation.
A.2.4
Further indications of the ICS proforma tables In addition to the columns of a table, the following information may be indicated: "Prerequisite line" A prerequisite line after a subclause heading or table title indicates that the whole subclause or the whole table is not required to be completed if the predicate is false. "Qualification" At the end of a table, a detailed qualification for a group of optional items may be indicated, as specified in the description of the status "qualified optional" in subclause in A.2.1. "Comments" This box at the end of a table allows a supplier to enter any comments to that table. Comments may also be provided separately (without using this box).
- 21 -
A.3
Identification of the Implementation
A.3.1
Implementation Identification Supplier (Note 1)
Contact point for queries about the ICS (Note 1)
Implementation Name(s) and Version(s) (Note 1, Note 2) Other information necessary for full identification - e.g., name(s) and version(s) for machines and/or operating systems; System name(s)
NOTE 1 Only the first three items are required for all implementations; other information may be completed as appropriate in meeting the requirement for full identification. NOTE 2 The terms Name and Version should be interpreted appropriately to correspond with a suppliers terminology (e.g. Type, Series, Model).
- 22 -
A.3.2
Specification for which this ICS applies Title
Corporate telecommunication networks – Signalling interworking between QSIG and H.323 – Generic functional protocol for the support of supplementary services
Version
1.0
Corrigenda Implemented (if applicable) Addenda Implemented (if applicable) Amendments Implemented (if applicable) Have any exception items been required ?
No[ ]Yes[ ] (The answer Yes means that the implementation does not conform to this Standard) (Note)
Date of Statement NOTE: In this case, an explanation shall be given of the nature of non-conformance either below or on a separate sheet of paper. Nature of non-conformance (if applicable):
- 23 -
A.4
Major capabilities Table A.1 - Major capabilities
Item
Question: Does the implementation...
MC 1
Conditions for status
Status
Reference
Support
support rerouting entity functionality for handling rerouting requests received from the PISN
O
6.1.4
[ ]Yes [ ]No
MC 2
support rerouting entity functionality for handling rerouting requests received from the IP network
O
6.1.4
[ ]Yes [ ]No
MC 3
support scenario A1
M
6.1.3
[ ]Yes
MC 4
support scenario A2
M
6.1.3
[ ]Yes
MC 5
support scenario B1
MC1 NOT MC1
O M
6.1.3
[ ]Yes [ ]No [ ]Yes
MC 6
support scenario B2
MC2 NOT MC2
O M
6.1.3
[ ]Yes [ ]No [ ]Yes
MC 7
support scenario C1
M
6.1.3
[ ]Yes
MC 8
support scenario C2
M
6.1.3
[ ]Yes
MC9
support scenarios D1 and D2 (remote activation)
O
6.2.3
[ ]Yes [ ]No
MC10
support scenarios E1 and E2 (remote deactivation)
O
6.2.3
[ ]Yes [ ]No
MC11
support scenarios F1 and F2 (remote interrogation)
O
6.2.3
[ ]Yes [ ]No
MC12
support scenarios G1 and G2 (remote restriction checking for activation)
O
6.2.3
[ ]Yes [ ]No
Comments:
A.5
General requirements Table A.2 - General requirements for protocol interworking
Item
Question: Does the implementation...
GR1
perform protocol interworking in accordance with ECMA-307
Comments:
Conditions for status
Status
Reference
Support
M
7
[ ]Yes
- 24 -
A.6
Message and APDU handling
A.6.1
Message and APDU handling for scenario A1 Table A.3 - Message and APDU handling for scenario A1
Item
Question: Does the implementation...
MA1 1
Conditions for status
Status
Reference
Support
behave in accordance with rule 1 for scenario A1
M
8.1
[ ]Yes
MA1 2
behave in accordance with rule 2 for scenario A1
M
8.1
[ ]Yes
MA1 3
behave in accordance with rule 3 for scenario A1
M
8.1
[ ]Yes
MA1 4
behave in accordance with rule 4 for scenario A1
M
8.1
[ ]Yes
MA1 5
behave in accordance with rule 5 for scenario A1
M
8.1
[ ]Yes
Comments:
A.6.2
Message and APDU handling for scenario A2 Table A.4 - Message and APDU handling for scenario A2
Item
Question: Does the implementation...
MA2 1
Status
Reference
Support
behave in accordance with rule 1 for scenario A2
M
8.2
[ ]Yes
MA2 2
behave in accordance with rule 2 for scenario A2
M
8.2
[ ]Yes
MA2 3
behave in accordance with rule 3 for scenario A2
M
8.2
[ ]Yes
MA2 4
behave in accordance with rule 4 for scenario A2
M
8.2
[ ]Yes
MA2 5
behave in accordance with rule 5 for scenario A2
M
8.2
[ ]Yes
MA2 6
behave in accordance with rule 6 for scenario A2
M
8.2
[ ]Yes
MA2 7
behave in accordance with rule 7 for scenario A2
M
8.2
[ ]Yes
MA2 8
behave in accordance with rule 8 for scenario A2
M
8.2
[ ]Yes
Comments:
Conditions for status
- 25 -
A.6.3
Message and APDU handling for scenario B1 Table A.5 - Message and APDU handling for scenario B1
Item
Question: Does the implementation...
Conditions for status
Status
Reference
Support
MB1 1
behave in accordance with rule 1 for scenario B1
MC5
M
8.3
[ ]Yes
MB1 2
behave in accordance with rule 2 for scenario B1
MC5
M
8.3
[ ]Yes
MB1 3
behave in accordance with rule 3 for scenario B1
MC5
M
8.3
[ ]Yes
MB1 4
behave in accordance with rule 4 for scenario B1
MC5
M
8.3
[ ]Yes
Comments:
A.6.4
Message and APDU handling for scenario B2 Table A.6 - Message and APDU handling for scenario B2
Item
Question: Does the implementation...
Conditions for status
Status
Reference
Support
MB2 1
behave in accordance with rule 1 for scenario B2
MC6
M
8.4
[ ]Yes
MB2 2
behave in accordance with rule 2 for scenario B2
MC6
M
8.4
[ ]Yes
MB2 3
behave in accordance with rule 3 for scenario B2
MC6
M
8.4
[ ]Yes
MB2 4
behave in accordance with rule 4 for scenario B2
MC6
M
8.4
[ ]Yes
Comments:
- 26 -
A.6.5
Message and APDU handling for scenario C1 Table A.7 - Message and APDU handling for scenario C1
Item
Question: Does the implementation...
MC1 1
Conditions for status
Status
Reference
Support
behave in accordance with rule 1 for scenario C1
M
8.5
[ ]Yes
MC1 2
behave in accordance with rule 2 for scenario C1
M
8.5
[ ]Yes
MC1 3
behave in accordance with rule 3 for scenario C1
M
8.5
[ ]Yes
MC1 4
behave in accordance with rule 4 for scenario C1
M
8.5
[ ]Yes
Comments:
A.6.6
Message and APDU handling for scenario C2 Table A.8 - Message and APDU handling for scenario C2
Item
Question: Does the implementation...
MC2 1
Status
Reference
Support
behave in accordance with rule 1 for scenario C2
M
8.6
[ ]Yes
MC2 2
behave in accordance with rule 2 for scenario C2
M
8.6
[ ]Yes
MC2 3
behave in accordance with rule 3 for scenario C2
M
8.6
[ ]Yes
MC2 4
behave in accordance with rule 4 for scenario C2
M
8.6
[ ]Yes
Comments:
Conditions for status
- 27 -
A.6.7
Message and APDU handling for scenario D1 Table A.9 - Message and APDU handling for scenario D1
Item
Question: Does the implementation...
Conditions for status
Status
Reference
Support
MD1 1
behave in accordance with rule 1 for scenario D1
MC9
M
8.7
[ ]Yes
MD1 2
behave in accordance with rule 2 for scenario D1
MC9
M
8.7
[ ]Yes
MD1 3
behave in accordance with rule 3 for scenario D1
MC9
M
8.7
[ ]Yes
Comments:
A.6.8
Message and APDU handling for scenario D2 Ta b le A . 1 0 - M e s s a g e a n d A P D U h a n d lin g f o r s c e n a r io D 2
Item
Question: Does the implementation...
Conditions for status
Status
Reference
Support
MD2 1
behave in accordance with rule 1 for scenario D2
MC9
M
8.8
[ ]Yes
MD2 2
behave in accordance with rule 2 for scenario D2
MC9
M
8.8
[ ]Yes
MD2 3
behave in accordance with rule 3 for scenario D2
MC9
M
8.8
[ ]Yes
Comments:
A.6.9
Message and APDU handling for scenario E1 Ta b le A . 1 1 - M e s s a g e a n d A P D U h a n d lin g f o r s c e n a r io E1
Item
Question: Does the implementation...
Conditions for status
Status
Reference
Support
ME1 1
behave in accordance with rule 1 for scenario E1
MC10
M
8.9
[ ]Yes
ME1 2
behave in accordance with rule 2 for scenario E1
MC10
M
8.9
[ ]Yes
ME1 3
behave in accordance with rule 3 for scenario E1
MC10
M
8.9
[ ]Yes
Comments:
- 28 -
A.6.10 Message and APDU handling for scenario E2 Ta b le A . 1 2 - M e s s a g e a n d A P D U h a n d lin g f o r s c e n a r io E2 Item
Question: Does the implementation...
Conditions for status
Status
Reference
Support
ME2 1
behave in accordance with rule 1 for scenario E2
MC10
M
8.10
[ ]Yes
ME2 2
behave in accordance with rule 2 for scenario E2
MC10
M
8.10
[ ]Yes
ME2 3
behave in accordance with rule 3 for scenario E2
MC10
M
8.10
[ ]Yes
Comments:
A.6.11 Message and APDU handling for scenario F1 Ta b le A . 1 3 - M e s s a g e a n d A P D U h a n d lin g f o r s c e n a r io F 1 Item
Question: Does the implementation...
Conditions for status
Status
Reference
Support
MF1 1
behave in accordance with rule 1 for scenario F1
MC11
M
8.11
[ ]Yes
MF1 2
behave in accordance with rule 2 for scenario F1
MC11
M
8.11
[ ]Yes
MF1 3
behave in accordance with rule 3 for scenario F1
MC11
M
8.11
[ ]Yes
Comments:
A.6.12 Message and APDU handling for scenario F2 Ta b le A . 1 4 - M e s s a g e a n d A P D U h a n d lin g f o r s c e n a r io F 2 Item
Question: Does the implementation...
Conditions for status
Status
Reference
Support
MF2 1
behave in accordance with rule 1 for scenario F2
MC11
M
8.12
[ ]Yes
MF2 2
behave in accordance with rule 2 for scenario F2
MC11
M
8.12
[ ]Yes
MF2 3
behave in accordance with rule 3 for scenario F2
MC11
M
8.12
[ ]Yes
Comments:
- 29 -
A.6.13 Message and APDU handling for scenario G1 Ta b le A . 1 5 - M e s s a g e a n d A P D U h a n d lin g f o r s c e n a r io G 1 Item
Question: Does the implementation...
Conditions for status
Status
Reference
Support
MG1 1
behave in accordance with rule 1 for scenario G1
MC12
M
8.13
[ ]Yes
MG1 2
behave in accordance with rule 2 for scenario G1
MC12
M
8.13
[ ]Yes
MG1 3
behave in accordance with rule 3 for scenario G1
MC12
M
8.13
[ ]Yes
Comments:
A.6.14 Message and APDU handling for scenario G2 Ta b le A . 1 6 - M e s s a g e a n d A P D U h a n d lin g f o r s c e n a r io G 2 Item
Question: Does the implementation...
Conditions for status
Status
Reference
Support
MG2 1
behave in accordance with rule 1 for scenario G2
MC12
M
8.14
[ ]Yes
MG2 2
behave in accordance with rule 2 for scenario G2
MC12
M
8.14
[ ]Yes
MG2 3
behave in accordance with rule 3 for scenario G2
MC12
M
8.14
[ ]Yes
Comments:
- 30 -
- 31 -
Annex B ( in f o r ma tiv e )
Example message sequence diagrams
This annex contains some examples of typical message sequences for some of the scenarios identified in this Standard. Although the examples shown are typical, other valid message sequences are possible. In the figures, the arrows indicate the direction of messages. For each message, only the message name and the contained APDU (if applicable) are shown. Other message contents are not shown, in particular for unsuccessful attempts at call diversion. The following abbreviations are used: .inv
invoke APDU
.res
return result APDU
B.1
Scenario A1 PISN
IP network
Interworking unit
QSIG SETUP H.225.0 SETUP QSIG CALL PROCEEDING H.225.0 CALL PROCEEDING
QSIG FACILITY divertingLegInformation1.inv
H.225.0 FACILITY divertingLegInformation1.inv H.225.0 ALERTING
QSIG ALERTING QSIG CONNECT divertingLegInformation3.inv
H.225.0 CONNECT divertingLegInformation3.inv
F ig u r e B. 1 – Ex a m p le o f s c e n a r io A 1 ( c a ll f o r wa r d in g u n c o n d it io n a l o r c a ll f o r wa r d in g b u s y )
- 32 -
B.2
Scenario A2 IP network
PISN
Interworking unit
H.225.0 SETUP QSIG SETUP H.225.0 CALL PROCEEDING QSIG CALL PROCEEDING QSIG ALERTING H.225.0 ALERTING H.225.0 FACILITY divertingLegInformation1.inv H.225.0 CONNECT divertingLegInformation3.inv
QSIG FACILITY divertingLegInformation1.inv QSIG CONNECT divertingLegInformation3.inv
F ig u r e B. 2 – Ex a m p le o f s c e n a r io A 2 ( c a ll f o r wa r d in g n o r e p ly )
- 33 -
B.3
Scenario B1 IP netowork
PISN
Interworking unit
H.225.0 SETUP QSIG SETUP H.225.0 CALL PROCEEDING QSIG CALL PROCEEDING
H.225.0 ALERTING
H.225.0 FACILITY callRerouting.inv H.225.0 FACILITY callRerouting.res H.225.0 DISCONNECT
QSIG ALERTING QSIG.0 FACILITY callRerouting.inv
QSIG.0 FACILITY callRerouting.res QSIG.0 RELEASE COMPLETE
H.225.0 RELEASE H.225.0 RELEASE COMPLETE
F ig u r e B. 3 – Ex a m p le o f s c e n a r io B1 ( c a ll f o r wa r d in g n o r e p ly )
- 34 -
B.4
Scenario B2 PISN
IP network
Interworking unit
QSIG SETUP H.225.0 SETUP QSIG CALL PROCEEDING H.225.0 CALL PROCEEDING H.225.0 FACILITY callRerouting.inv
QSIG FACILITY callRerouting.inv QSIG FACILITY callRerouting.res
H.225.0 FACILITY callRerouting.res
QSIG DISCONNECT
H.225.0 RELEASE COMPLETE
QSIG RELEASE QSIG RELEASE COMPLETE
F ig u r e B. 4 – Ex a m p le o f s c e n a r io B2 ( c a ll f o r wa r d in g u n c o n d it io n a l o r c a ll f o r wa r d in g b u s y )
B.5
Scenario C1 IP network
PISN
Interworking unit
H.225.0 SETUP divertingLegInformation1.inv
QSIG SETUP divertingLegInformation1.inv
H.225.0 CALL PROCEEDING QSIG CALL PROCEEDING QSIG ALERTING H.225.0 ALERTING H.225.0 CONNECT divertingLegInformation3.inv
QSIG CONNECT divertingLegInformation3.inv
F ig u r e B. 5 – Ex a m p le o f s c e n a r io C 1
- 35 -
B.6
Scenario C2 PISN
IP network
Interworking unit
QSIG SETUP divertingLegInformation1.inv
H.225.0 SETUP divertingLegInformation1.inv
QSIG CALL PROCEEDING H.225.0 CALL PROCEEDING H.225.0 ALERTING QSIG ALERTING QSIG CONNECT divertingLegInformation3.inv
H.225.0 CONNECT divertingLegInformation3.inv
F ig u r e B. 6 – Ex a m p le o f s c e n a r io C 2
.
.
Free printed copies can be ordered from: ECMA 114 Rue du Rhône CH-1204 Geneva Switzerland Fax: Email:
+41 22 849.60.01 [email protected]
Files of this Standard can be freely downloaded from the ECMA web site (www.ecma.ch). This site gives full information on ECMA, ECMA activities, ECMA Standards and Technical Reports.
ECMA 114 Rue du Rhône CH-1204 Geneva Switzerland See inside cover page for obtaining further soft or hard copies.