Conceptio › Archive › ECMA International

ECMA Internationalopen access

ECMA-308 — Corporate telecommunication networks - Signalling interworking between QSIG and H.323 - Call transfer supplementary services (June 2001)

ECMA International · ECMA International

ECMA International · Standards · License: Open Access

corporate ecma ecmainternational networks qsig signalling supplementary telecommunication

ecma, standard, ecma international, specification, ecma-308, ecma 308, 308, corporate, telecommunication, networks, signalling, interworking, between, qsig, and, h.323, call, transfer, supplementary, services

S tandard ECMA-308 2nd Edition - June 2001

Standardizing Information

and

Communication

Systems

Corporate Telecommunication Networks – Signalling Interworking between QSIG and H.323 – Call Transfer 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-308 2nd Edition - June 2001

Standardizing

Information

and

Communication

Systems

Corporate Telecommunication Networks – Signalling Interworking between QSIG and H.323 – Call Transfer Supplementary Services

Phone: +41 22 849.60.00 - Fax: +41 22 849.60.01 - URL: http://www.ecma.ch - Internet: [email protected] IW

ECMA-308.DOC

11-07-01 10,55

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-00195. This particular Standard defines the signalling protocol interworking for call transfer 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 21410:2001(E) to be published by ISO/IEC in 2001.

Adopted as 2nd Edition of Standard ECMA-308 by the General Assembly of June 2001.

- i -

Table of contents 1

Scope

Conformance

Normative references

Definitions 4 . 1 E x te r n a l d e f in itio n s 4.2 Other definitions 4.2.1 Entity A 4.2.2 Entity A* 4.2.3 Entity B 4.2.4 E n tity B* 4.2.5 E n tity B’ 4.2.6 Entity C 4.2.7 E n tity C* 4.2.8 E n tity C’ 4.2.9 Gateway 4.2.10 Leg AB 4.2.11 L e g A B* 4.2.12 Leg AC 4.2.13 L e g BC 4.2.14 L e g BC* 4.2.15 Leg B 4.2.16 L e g B* 4.2.17 Leg C 4.2.18 S c e n a r io A B1 4.2.19 S c e n a r io A B* 1 4.2.20 S c e n a r io A B2 4.2.21 S c e n a r io A B* 2 4.2.22 S c e n a r io A C1 4.2.23 S c e n a r io A C2 4.2.24 S c e n a r io BC1 4.2.25 S c e n a r io BC* 1 4.2.26 S c e n a r io BC2 4.2.27 S c e n a r io BC* 2 4.2.28 S c e n a r io B1 4.2.29 S c e n a r io B* 1 4.2.30 S c e n a r io B2 4.2.31 S c e n a r io B* 2 4.2.32 S c e n a r io C1 4.2.33 S c e n a r io C2

2 2 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 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 QSIG service architecture 6.1.2 H . 4 5 0 . 2 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 e n t i t i e s w h e n i n te r w o r k i n g 6.2 Service architecture for activation, deactivation and interrogation 6.2.1 QSIG service architecture 6.2.2 H . 4 5 0 . 2 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

5 5 5 5 8 11 12 19 19 19 19

Protocol interworking – General requirements

Protocol interworking – Messages and APDUs Scenario AB1 Scenario AB2 Scenario AC1 Scenario AC2 Scenario BC1 Scenario BC2 Scenario B1 Scenario B2 Scenario C1 Scenario C2 Scenario AB*1 Scenario AB*2 Scenario BC*1 Scenario BC*2 S c e n a r io B* 1 S c e n a r io B* 2

19 19 20 21 21 22 23 24 25 26 27 27 28 29 30 31 32

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 8.15 8.16 9

Protocol interworking – Content of APDUs 32 9 . 1 A P D U c o n te n t ma p p in g f r o m Q S I G to H . 3 2 3 33 9.1.1 Q S I G s s c t I n i t i a t e in v o k e A P D U ma p p i n g t o H . 3 2 3 c a l l T r a n s f e r I n i t i a t e in v o k e APDU 33 9.1.2 Q S I G s s c tS e tu p in v o k e A P D U ma p p in g to H . 3 2 3 c a llT r a n s f e r S e tu p in v o k e A P D U 3 3 9 . 2 A P D U c o n te n t ma p p in g f r o m H . 3 2 3 to Q S I G 33 9.2.1 H . 3 2 3 c a l l T r a n s f e r I n i t i a t e in v o k e A P D U ma p p i n g t o Q S I G s s c t I n i t i a t e in v o k e APDU 33 9.2.2 H . 3 2 3 c a llT r a n s f e r S e tu p in v o k e A P D U ma p p in g to Q S I G s s c tS e tu p in v o k e A P D U 3 4

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

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

Scope This Standard specifies signalling interworking between “QSIG” and “H.323” in support of the call transfer 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-178 specifies the QSIG protocol in support of call transfer by consultation and ECMA-300 specifies the QSIG protocol in support of single step call transfer. “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.2 specifies the H.323 protocol in support of call transfer. NOTE H.450.2 applies only to the 1998 version of H.323 (also known as H.323 version 2) and to later versions. Call transfer by consultation, as supported by ECMA-178, is a supplementary service that enables a user (user A) to transform two of that user's calls (at least one of which must be answered) into a new call between the two other users in the two calls (users B and C). Single step call transfer, as supported by ECMA-300, is a supplementary service that enables a user (user A) to transform an existing call between user A and user B into a new call between user B and user C without user A needing to establish a call with user C prior to transfer. Call transfer, as supported by H.450.2, is a supplementary service that enables the served user (user A) to transform an existing call with a second user (user B) into a new call between user B and a third user (user C) selected by user A. User A may or may not have a call established with user C prior to call transfer. If a call is already established between user A and user C, this is known as transfer by consultation and is equivalent to call transfer as supported by ECMA-178. If a call is not already established between user A and user C, this is known as single step call transfer and is equivalent to call transfer as supported by ECMA-300. 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 PISN user with two calls established, at least one of which being to or from a user in an IP network, to be able to transform those two calls into a new call between the other two users involved;

•

a PISN user with a call established to or from a user in an IP network to be able to transform that call into a new call between the IP network user and a third user selected by the PISN user, that third user being either in the IP network or in the PISN;

•

a PISN user with a call established to a second PISN user to be able to transfer that call into a new call between the second user and a third user selected by the first user, that third user being in an IP network;

•

an IP network user with two calls established, at least one of which being to or from a user in a PISN, to be able to transform those two calls into a new call between the other two users involved;

•

an IP network user with a call established to or from a user in a PISN to be able to transform that call into a new call between the PISN user and a third user selected by the IP network user, that third user being either in the IP network or in the PISN; and

- 2 -

•

an IP network user with a call established to a second user in the IP network to be able to transfer that call into a new call between the second user and a third user selected by the first user, that third user being 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.

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.

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. 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.

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-178

Private Integrated Services Network (PISN) - Inter-Exchange Signalling Protocol Call Transfer Supplementary Service (International Standard ISO/IEC 13869)

ECMA-300

Private Integrated Services Network (PISN) - Inter-Exchange Signalling Protocol Single Step Call Transfer Supplementary Service (International Standard ISO/IEC 19460)

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.2

Call transfer 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)

- 3 -

– IP network

(ECMA-307)

– Gatekeeper

(ITU-T Rec. H.323)

– Private Integrated Services Network (PISN)

(ECMA-307)

– Private Integrated services Network eXchange (PINX)

(ECMA-133)

Additionally the definitions in ECMA-178, ECMA-300 and ITU-T Recommendation H.450.2 apply as appropriate.

4.2

Other definitions

4.2.1

En t it y A In call transfer by consultation, the signalling entity at the PINX or H.323 endpoint serving the transferring user (user A).

4.2.2

En t it y A * In single step call transfer, the signalling entity at the PINX or H.323 endpoint serving the transferring user (user A).

4.2.3

En t it y B In call transfer by consultation, the signalling entity in the PISN or IP network associated with the call between the transferring user (user A) and the transferred user (user B).

4.2.4

En t it y B* In single step call transfer, the signalling entity in the PISN or IP network associated with the call between the transferring user (user A) and the transferred user (user B).

4.2.5

En t it y B’ Signalling entity at the PINX or the H.323 endpoint serving the transferred user (user B).

4.2.6

En t it y C In call transfer by consultation, the signalling entity in the PISN or IP network associated with the call between the transferring user (user A) and the transferred-to-user (user C).

4.2.7

En t it y C * In single step call transfer, the signalling entity in the PISN or IP network associated with the call between the transferred user (user B) and the transferred-to-user (user C).

4.2.8

En t it y C ’ Signalling entity at the PINX or H.323 endpoint serving the transferred-to-user (user C).

4.2.9

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.10

Le g A B In call transfer by consultation, the call segment that lies between entity A and entity B.

4.2.11

Le g A B* In single step call transfer, the call segment that lies between entity A* and entity B*.

4.2.12

Le g A C In call transfer by consultation, the call segment that lies between entity A and entity C.

4.2.13

Le g BC In call transfer by consultation, the call segment that lies between entity B and entity C.

4.2.14

Le g BC * In single step call transfer, the call segment that lies between entity B* and entity C*.

4.2.15

Le g B In call transfer by consultation, the call segment that lies between the entity B and entity B’.

- 4 -

4.2.16

Le g B* In single step call transfer, the call segment that lies between entity B* and entity B’.

4.2.17

Le g C In call transfer by consultation, the call segment that lies between entity C and entity C’.

4.2.18

S c e n a r io A B1 Interworking arrangement in which entity A (PINX A) is in the PISN and entity B is in the IP network.

4.2.19

S c e n a r io A B* 1 Interworking arrangement in which entity A* (PINX A) is in the PISN and entity B* is in the IP network.

4.2.20

S c e n a r io A B2 Interworking arrangement in which entity A (endpoint A) is in the IP network and entity B is in the PISN.

4.2.21

S c e n a r io A B* 2 Interworking arrangement in which entity A* (endpoint A) is in the IP network and entity B* is in the PISN.

4.2.22

S c e n a r io A C 1 Interworking arrangement in which entity A (PINX A) is in the PISN and entity C is in the IP network.

4.2.23

S c e n a r io A C 2 Interworking arrangement in which entity A (endpoint A) is in the IP network and entity C is in the PISN.

4.2.24

S c e n a r io BC 1 Interworking arrangement in which entity B (PINX B) is in the PISN and entity C is in the IP network.

4.2.25

S c e n a r io BC * 1 Interworking arrangement in which entity B* (PINX B) is in the PISN and entity C* is in the IP network.

4.2.26

S c e n a r io BC 2 Interworking arrangement in which entity B is in the IP network and entity C is in the PISN.

4.2.27

S c e n a r io BC * 2 Interworking arrangement in which entity B* is in the IP network and entity C* is in the PISN.

4.2.28

S c e n a r io B1 Interworking arrangement in which entity B (PINX B) is in the PISN and entity B’ is in the IP network.

4.2.29

S c e n a r io B* 1 Interworking arrangement in which entity B* (PINX B) is in the PISN and entity B’ is in the IP network.

4.2.30

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 entity B’ is in the PISN.

4.2.31

S c e n a r io B* 2 Interworking arrangement in which entity B* (diverting endpoint or its gatekeeper) is in the IP network and entity B’ is in the PISN.

4.2.32

S c e n a r io C 1 Interworking arrangement in which entity C (PINX C) is in the PISN and entity C’ is in the IP network.

4.2.33

S c e n a r io C 2 Interworking arrangement in which entity C (endpoint C) is in the IP network and entity C’ is in the PISN.

- 5 -

Acronyms

APDU

Application Protocol Data Unit

Corporate telecommunication Network

ICS

Implementation Conformance Statement

Internet Protocol

PINX

Private Integrated services Network eXchange

PISN

Private Integrated Services Network

SS-CT

Supplementary Service Call Transfer

SS-SSCT

Supplementary Service Single Step Call Transfer

Service architecture

6.1

Service architecture for invocation and operation

6.1.1

6.1.1.1

QSIG service architecture QSIG supports two different call transfer services: •

transfer by consultation (ECMA-178); and

•

single step call transfer (ECMA-300). EC M A - 1 7 8 s e r v ic e a r c h it e c t u r e - t r a n s f e r b y c o n s u lt a t io n ECMA-178 supports a call transfer service that starts from a situation where user A has two calls (typically one of which is on hold). Transfer from this situation can be performed in two ways: by join (at the PINX serving user A) or by rerouteing. A single model can be derived to accommodate both scenarios. The model involves five signalling entities as follows: •

entity A – acts on behalf of user A and co-ordinates the transfer;

•

entity B – initiates the re-routed connection from the first transferred user (user B) to the other transferred user (user C);

•

entity B’ – acts on behalf of user B;

•

entity C – terminates the re-routed connection from user B to user C and completes the join; and

•

entity C’ – acts on behalf of user C.

This can be represented diagrammatically as shown in figure 1.

Entity B

Leg B

Entity B’

Leg AB

Entity A

Leg BC

Leg AC

Entity C

Leg C

Entity C’

F ig u r e 1 – G e n e r a lis e d c a ll t r a n s f e r m o d e l f o r Q S I G t r a n s f e r b y c o n s u lt a t io n

- 6 -

From this it can be seen that there are five segments or “legs” to the call: •

leg AB between entity A and entity B;

•

leg AC between entity A and entity C;

•

leg BC between entity B and entity C;

•

leg B between entity B and entity B’; and

•

leg C between entity C and entity C’.

The protocol defined in ECMA-178 supports each of these five legs. For both transfer by join and transfer by rerouteing, entities A, B’ and C’ are located at the PINX serving user A, user B and user C respectively. For call transfer by join, entities B and C are collocated with entity A in the PINX serving user A. This means that legs AB, AC and BC are all internal to that PINX, and therefore the QSIG protocols for these legs do not apply. Only the QSIG protocols for legs B and C apply. This is shown in figure 2.

PINX B Entity B’

PINX A Entity B

Leg B

Entity A Entity C Leg C Entity C’

PINX C F ig u r e 2 – C a ll t r a n s f e r b y j o in m o d e l f o r Q S I G For call transfer by rerouteing, entity B is collocated with entity B’ in the PINX serving user B, and entity C is collocated with entity C’ in the PINX serving user C. This means that legs B and C are internal to the respective PINXs, and therefore the QSIG protocols for these legs do not apply. Only the QSIG protocols for legs AB, AC and BC apply. This is shown in figure 3.

- 7 -

PINX B Entity B

Entity B’

Leg AB PINX A Entity A

Leg BC

Leg AC

Entity C

Entity C’

PINX C Figure 3 – Call transfer by rerouteing model for QSIG In both cases (transfer by join and transfer by re-routeing), 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. 6.1.1.2

EC M A - 3 0 0 s e r v ic e a r c h it e c t u r e – s in g le s t e p c a ll t r a n s f e r ECMA-300 supports a call transfer service that starts from a situation where user A has an active call with user B and the call is to be transferred to user C in the case where A does not already have a call to user C. If user A does not provide sufficient information to enable a call to be established to user C, user B may provide additional information to identify user C and enable the call to be established. The generalised model for Single Step call Transfer is as shown in figure 4.

Entity B*

Leg B*

Entity B’

Leg AB*

Entity A*

Leg BC*

Entity C*

Entity C’

F ig u r e 4 – G e n e r a lis e d m o d e l f o r Q S I G S in g le S t e p C a ll Tr a n s f e r Compared with the general model for transfer by consultation, the following differences exist: •

entity A* replaces entity A (although it has some common functionality);

•

entity B* replaces entity B (although it has some common functionality);

•

entity C* replaces entity C;

•

leg AB* replaces leg AB (but differs only slightly);

•

leg BC* replaces leg BC (but differs only slightly);

- 8 -

•

leg B* replaces Leg B (but differs only slightly); and

•

leg AC does not exist.

Entities A*, B’ and C’ are located at the PINX serving user A, user B and user C respectively. Entity B* may be located at any PINX between entity A* and Entity B’. Entity C* is always collocated with entity C’ in the PINX serving user C. This means that the leg between entity C* and entity C’ is internal to the PINX, and therefore the QSIG protocol for this leg does not apply. Only the protocols defined in ECMA-300 for legs AB*, BC* and B* apply. Where a user is in another network, the role of entity A*, entity B’ or the combined entities C*/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. 6.1.2

H . 4 5 0 . 2 s e r v ic e a r c h it e c t u r e H.450.2 supports two different call transfer services:

6.1.2.1

•

transfer by consultation (similar to the service supported by ECMA-178); and

•

single step call transfer (similar to the service supported by ECMA-300). Tr a n s f e r b y c o n s u lt a t io n The model shown in figure 1 for QSIG call transfer by consultation applies also to H.450.2. Various scenarios arise, depending on gatekeeper involvement. A gatekeeper can act on behalf of user B and/or a gatekeeper can act on behalf of user C. If no gatekeepers are involved in the call transfer service, entity A is located at user A’s endpoint, entities B and B’ are located at user B’s endpoint, and entities C and C’ are located at user C’s endpoint. Legs AB, AC and BC are supported by H.450.2 signalling. This is shown in figure 5.

Endpoint B Entity B

Entity B’

Leg AB Endpoint A Entity A

Leg BC

Leg AC

Entity C

Entity C’

Endpoint C F ig u r e 5 – H . 4 5 0 . 2 c a ll t r a n s f e r b y c o n s u lt a t io n m o d e l – n o g a t e k e e p e r s in v o lv e d If a gatekeeper is involved in call transfer on behalf of user B and another gatekeeper is involved on behalf of user C, entities B and C are located in the respective gatekeepers and legs AB, AC, CB, B and C are all supported by H.450.2 signalling. This is shown in figure 6.

- 9 -

Gatekeeper B Entity B

Endpoint B Leg B

Entity B’

Leg AB Endpoint A Entity A

Leg BC

Leg AC

Entity C

Leg C

Gatekeeper C

Entity C’

Endpoint C

F ig u r e 6 – H . 4 5 0 . 2 c a ll t r a n s f e r b y c o n s u lt a t io n m o d e l – g a t e k e e p e r s in v o lv e d o n behalf of endpoint B and endpoint C Models for the cases where only entity B or only entity C is located at a gatekeeper can easily be derived. If the same gatekeeper acts on behalf of user B and user C, the model in figure 7 applies. In this case leg BC is internal to the gatekeeper and H.450.2 signalling does not apply.

Endpoint B

Gatekeeper Endpoint A

Leg AB

Leg B

Entity B’

Entity B

Entity A Leg AC

Entity C Leg C Entity C’

Endpoint C F ig u r e 7 – H . 4 5 0 . 2 c a ll t r a n s f e r b y c o n s u lt a t io n m o d e l – s in g le g a t e k e e p e r involved on behalf of endpoint B and endpoint C Where a user is in another network, the role of entity A, entities B and B’ or entities C and C’ is performed by the other network, the gateway, or the two in combination. However, from the H.450.2 point of view the role is performed by the gateway. NOTE The equivalent of QSIG transfer by join does not exist with H.450.2. Legs AB and AC exist in all scenarios (although leg BC can be hidden inside a gatekeeper). 6.1.2.2

S in g le s t e p c a ll t r a n s f e r For single step call transfer, the general model is as shown in figure 4. Unlike the QSIG single step call transfer supplementary service (see 6.1.1.2), the H.450.2 single step call transfer supplementary service does not enable user B to provide additional information to identify user C if user A did not provide sufficient information to enable a call to be established to user C.

- 10 -

Various scenarios arise, depending on gatekeeper involvement. A gatekeeper can act on behalf of user B and/or a gatekeeper can act on behalf of user C. This has impact on the exposure of legs B* and C*, as for transfer by consultation. If no gatekeepers are involved in single step call transfer, entity A* is located at user A’s endpoint, entities B* and B’ are located at user B’s endpoint, and entities C* and C’ are located at user C’s endpoint. Legs AB*, and BC* are supported by H.450.2 signalling. This is shown in figure 8.

Endpoint B Entity B*

Entity B’

Leg AB* Endpoint A Entity A*

Leg BC*

Entity C*

Entity C’

Endpoint C F ig u r e 8 – H . 4 5 0 . 2 s in g le s t e p c a ll t r a n s f e r m o d e l– n o g a t e k e e p e r s in v o lv e d If a gatekeeper is involved in single step call transfer on behalf of user B and another gatekeeper is involved on behalf of user C, entities B* and C*/C’ are located in the respective gatekeepers and legs AB*, BC*, and B* are all supported by H.450.2 signalling. This is shown in figure 9.

Gatekeeper B Entity B*

Endpoint B Leg B*

Entity B’

Leg AB* Endpoint A Entity A*

Leg BC*

Entity C*

Entity C’

Gatekeeper C F ig u r e 9 – H . 4 5 0 . 2 s in g le s t e p c a ll t r a n s f e r m o d e l – g a t e k e e p e r s in v o lv e d o n behalf of endpoint B and endpoint C Models for the cases where only entity B or only entity C is located at a gatekeeper can easily be derived. If the same gatekeeper acts on behalf of user B and user C, the model in figure 10 applies. In this case leg BC* is internal to the gatekeeper and H.450.2 signalling does not apply.

- 11 -

Endpoint B

Gatekeeper Endpoint A

Leg AB*

Leg B*

Entity B’

Entity B*

Entity A* Entity C*

Entity C’

F ig u r e 1 0 – H . 4 5 0 . 2 s in g le s t e p c a ll t r a n s f e r m o d e l – s in g le g a t e k e e p e r in v o lv e d on behalf of endpoint B and endpoint C In all of these cases of single step call transfer, where a user is in another network, the role of entity A*, entities B* and B’ or entities C* and C’ is performed by the other network, the gateway, or the two in combination. However, from the H.450.2 point of view the role is performed by the gateway. 6.1.3 S c e n a r io s f o r in t e r wo r k in g 6.1.3.1 Tr a n s f e r b y c o n s u lt a t io n The models for QSIG and H.450.2 are very similar. This means that the same model 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. Entities A, B’ and C’ are always located in the network of the user concerned, but there is some flexibility in the location of entities B and C. Interworking between H.450.2 and QSIG can occur on any of the five legs. For each of the five possible points of interworking, two scenarios arise, depending on which side of the interworking point the PISN lies. This gives 10 scenarios in total that need to be considered: •

Scenario AB1: Entity A (PINX A) in PISN, entity B (gatekeeper B or endpoint B) in IP network;

•

Scenario AB2: Entity A (endpoint A) in IP network, entity B (PINX B) in PISN;

•

Scenario AC1: Entity A (PINX A) in PISN, entity C (gatekeeper C or endpoint C) in IP network;

•

Scenario AC2: Entity A (endpoint A) in IP network, entity C (PINX C) in PISN;

•

Scenario BC1: Entity B (PINX B) in PISN, entity C (gatekeeper C or endpoint C) in IP network;

•

Scenario BC2: Entity B (gatekeeper B or endpoint B) in IP network, entity C (PINX C) in PISN;

•

Scenario B1: Entity B (PINX B) in PISN, entity B’ (endpoint B) in IP network;

•

Scenario B2: Entity B (gatekeeper B or endpoint B) in IP network, entity B’ (PINX B) in PISN;

•

Scenario C1: Entity C (PINX C) in PISN, entity C’ (endpoint C) in IP network; and

•

Scenario C2: Entity C (gatekeeper C or endpoint C) in IP network, entity C’ (PINX C) in PISN.

With scenarios AB1, AB2, AC1, AC2, BC1 and BC2, the PISN is involved in transfer by rerouteing. Since this is only an optional part of ECMA-178, these scenarios will not always be available. It is possible for more than one scenario to apply to the same call. In particular, because of the triangular situation, scenarios AB1, AB2, AC1, AC2, BC1 and BC2 will always occur in pairs, e.g., scenarios AB1 and AC1 if entity A is in the PISN and entities B and C are in the IP network. 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. Call transfer entities can be located in the gateway but are logically separate from the point of interworking. For example, if user B is in the PISN and users A and C are in the IP network, entity B could be located in the gateway on the IP network side of the interworking point, with entity B’ in the PISN (PINX B). Logically interworking would still be taking place on leg B.

- 12 -

6.1.3.2

S in g le s t e p c a ll t r a n s f e r The models for QSIG and H.450.2 are very similar. This means that the same model 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. Entities A*, B’ C* and C’ are always located in the network of the user concerned, but there is some flexibility in the location of entity B*. Interworking between H.450.2 and QSIG can occur on any of legs AB*, BC* and B*. For each of the three points of interworking, two scenarios arise, depending on which side of the interworking point the PISN lies. This gives six scenarios in total that need to be considered: •

Scenario AB*1: Entity A* (PINX A) in PISN, entity B* (gatekeeper B* or endpoint B*) in IP network;

•

Scenario AB*2: Entity A* (endpoint A) in IP network, entity B* (PINX B) in PISN;

•

Scenario BC*1: Entity B* (PINX B) in PISN, entity C* (gatekeeper C* or endpoint C*) in IP network;

•

Scenario BC*2: Entity B* (gatekeeper B* or endpoint B*) in IP network, combined entities C*/C’ (PINX C) in PISN;

•

Scenario B*1: Entity B* (PINX B) in PISN, entity B’ (endpoint B) in IP network;

•

Scenario B*2: Entity B* (gatekeeper B* or endpoint B*) in IP network, entity B’ (PINX B) in PISN.

It is possible for more than one scenario to apply to the same call e.g., scenarios BC*1 and B*1 if entity B* is in the PISN and entities B’ and C* are in the IP network. 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. Single step call transfer entities can be located in the gateway but are logically separate from the point of interworking. For example, if user B is in the PISN and users A and C are in the IP network, entity B* could be located in the gateway on the IP network side of the interworking point, with entity B’ in the PISN (PINX B). Logically interworking would still be taking place on leg B*. 6.1.4 D e t e r m in a t io n o f t h e lo c a t io n o f e n t it ie s wh e n in t e r wo r k in g 6.1.4.1 Tr a n s f e r b y c o n s u lt a t io n Entities A, B’ and C’ are always located in the network of the user concerned. The locations of entities B and C are determined as follows. If user A and therefore entity A are in the QSIG network at PINX A and PINX A implements only transfer by join or chooses to perform transfer by join, entities B and C will be located at PINX A. Interworking will occur on leg B and/or leg C, depending on the location of users B and C. This is shown in figure 11.

- 13 -

PISN

IP network

Endpoint B Entity B’

G/W

Leg B

I/W PINX A

Entity B

Entity A Entity C

(Scenario B1)

G/W I/W (Scenario C1)

Endpoint C Leg C

Entity C’

Figure 11 – Interworking – transfer by join in a PISN If user A and therefore entity A are in the QSIG network at PINX A and PINX A performs transfer by rerouteing, if user B is in the IP network the gateway between user A’s network and user B’s network can choose, on receipt of a transfer request from PINX A, whether to provide entity B (in which case interworking occurs on leg B) or to instruct the IP network to provide entity B (in which case interworking occurs on leg AB). Similarly, if user C is in the IP network the gateway between user A’s network and user B’s network can choose, on receipt of a transfer identify request from PINX A, whether to provide entity C (in which case interworking occurs on leg C) or to instruct the IP network to provide entity C (in which case interworking occurs on leg AC). Figure 12 and figure 13 show the two cases where the two gateways make the same decision. If the two gateways make different decisions, interworking will also occur on leg BC. The case where entity B is in the PISN and entity C is in the IP network is shown in figure 14. The reverse case is not shown.

- 14 -

PISN

IP network Endpoint B G/W

Entity B

Entity B’

I/W (Scenario AB1)

PINX A Entity A

Leg AB

Leg BC

Leg AC I/W (Scenario AC1)

Entity C

Entity C’

G/W Endpoint C Figure 12 – Interworking – transfer by rerouteing between PINX A and endpoints B and C in the IP network

PISN

IP network G/W

Endpoint B I/W

Entity B

Leg B

(Scenario B1)

Leg AB

Entity B’

PINX A Leg BC

Entity A

G/W Leg AC

Entity C

Endpoint C I/W

(Scenario C1)

Leg C

Entity C’

Figure 13 – Interworking – transfer by rerouteing between PINX A and t wo g a t e wa y s

- 15 -

PISN

IP network G/W Entity B

Leg AB

Endpoint B I/W

Leg B

(scenario B1)

Entity B’

PINX A G/W

Entity A

I/W (Scenario BC1)

Leg AC

Leg BC G/W I/W (Scenario AC1)

Endpoint C Entity C

Entity C’

Figure 14 – Interworking – transfer by rerouteing –between PINX A, entity B in a gateway and entity C in the IP network If user A and therefore entity A are in the IP network at endpoint A, if user B is in the PISN the gateway between user A’s network and user B’s network can choose, on receipt of a transfer request from endpoint A, whether to provide entity B (in which case interworking occurs on leg B) or to instruct the PISN to provide entity B (in which case interworking occurs on leg AB). The latter requires support for transfer by rerouteing in the PISN. Similarly, if user C is in the PISN the gateway between user A’s network and user C’s network can choose, on receipt of a transfer identify request from endpoint A, whether to provide entity C (in which case interworking occurs on leg C) or to instruct the PISN to provide entity C (in which case interworking occurs on leg AC). The latter requires support for transfer by rerouteing in the PISN. If the two gateways make different decisions, interworking will also occur on leg BC. Figure 15 and figure 16 show the two cases where the two gateways make the same decision. If the two gateways make different decisions (not shown), interworking will also occur on leg BC.

- 16 -

IP network

PISN

PINX B Entity B

Entity B’

G/W I/W Endpoint A

Leg AB

(Scenario AB2)

Entity A

Leg BC Leg AC

I/W (Scenario AC2)

G/W

Entity C

Entity C’

PINX C Figure 15 – Interworking – transfer by rerouteing between endpoint A in the IP network and PINXs B and C

IP network

PISN PINX B

G/W Entity B Leg AB

I/W

Leg B

(Scenario B2)

Entity B’

Endpoint A Entity A

Leg BC G/W Leg AC

Entity C

PINX C I/W (Scenario C2)

Leg C

Entity C’

Figure 16 – Interworking – transfer by rerouteing between endpoint A in the I P n e t wo r k a n d t wo g a t e wa y s In cases where a gateway can choose whether to provide entity B or entity C functionality, the gateway’s decision is an implementation matter. This can, but need not, take account of the user C or user B respectively. The behaviour of entity B or entity C, if provided at the gateway, is outside the scope of this Standard and is assumed to be in accordance with the requirements of ECMA-178 (when entity A is in the PISN) or in accordance with the requirements of H.450.2 (when entity A is in the IP network).

- 17 -

6.1.4.2

S in g le s t e p c a ll t r a n s f e r Entities A*, B’ C* and C’ are always located in the network of the user concerned. The location of entity B* is determined as follows. If user A and therefore entity A* are in the QSIG network at PINX A entity B* may be located at PINX A. Interworking will occur on leg B* and/or leg BC*, depending on the location of users B and C. If user B is in the IP network, the gateway between user A’s network and user B’s network can choose, on receipt of a transfer request from PINX A, whether to provide entity B* (in which case interworking occurs on leg B*) or to instruct the IP network to provide entity B* (in which case interworking occurs on leg AB*). Figure 17 shows the case where entity B* is provided by the gateway. Figure 18 shows the case where entity B* is provided by the IP network.

PISN

IP network G/W

Endpoint B Leg B*

I/W

Entity B*

Entity B’

(Scenario B*1)

Leg AB* PINX A Entity A*

G/W

Leg BC*

I/W (Scenario BC*1)

Endpoint C Entity C*

Entity C’

F ig u r e 1 7 – I n t e r wo r k in g – s in g le s t e p c a ll t r a n s f e r in a P I S N

PISN

IP network Endpoint B G/W

Entity B*

Entity B’

I/W PINX A Entity A*

(Scenario AB*1)

Leg AB*

Leg BC*

Entity C*

Entity C’

Endpoint C Figure 18 – Interworking – single step call transfer between PINX A and endpoints B and C in the IP network

- 18 -

Also, in the case where entity B* is provided by the IP network and user C is in the PISN, interworking will also occur on leg BC*. This case is not shown. If user A and therefore entity A* are in the IP network at endpoint A, if user B is in the PISN the gateway between user A’s network and user B’s network can choose, on receipt of a transfer request from endpoint A, whether to provide entity B* (in which case interworking occurs on leg B*) or to instruct the PISN to provide entity B* (in which case interworking occurs on leg AB*). These are shown in figure 19 and figure 20. IP network

PISN G/W

PINX B Leg B*

I/W

Entity B*

(Scenario B*2)

Leg AB*

Entity B’

Endpoint A Entity A*

G/W

Leg BC*

I/W (Scenario BC*2)

PINX C Entity C*

Entity C’

Figure 19 – Interworking – single step call transfer between endpoint A in the IP network and two gateways

IP network

PISN PINX B G/W

Entity B*

Entity B’

I/W (Scenario AB*2)

Endpoint A

Leg BC*

Entity A* Leg AB*

Entity C*

Entity C’

PINX C Figure 20 – Interworking – single step call transfer between endpoint A in the IP network and PINXs B and C Also, in the case where entity B* is provided by the PISN and user C is in the IP network, interworking will also occur on leg BC*. This case is not shown. In cases where a gateway can choose whether to provide entity B* functionality, the gateway’s decision is an implementation matter. This can, but need not, take account of the location of user C. The behaviour of entity B*, if provided at the gateway, is outside the scope of this Standard and is

- 19 -

assumed to be in accordance with the requirements of ECMA-300 (when entity A* is in the PISN) or in accordance with the requirements of H.450.2 (when entity A* is in the IP network).

6.2

Service architecture for activation, deactivation and interrogation

6.2.1 QSIG service architecture 6.2.1.1 EC M A - 1 7 8 s e r v ic e a r c h it e c t u r e Not applicable. 6.2.1.2

EC M A - 3 0 0 s e r v ic e a r c h it e c t u r e Not applicable.

6.2.2

H . 4 5 0 . 2 s e r v ic e a r c h it e c t u r e Not applicable.

6.2.3

S c e n a r io s f o r in t e r wo r k in g Not applicable.

Protocol interworking – General requirements Protocol interworking between H.323 and QSIG for call transfer supplementary services shall be in accordance with ECMA-307, as modified by the requirements of clauses 8 and 9 below. 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.

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. Annex B shows in diagrammatic form some typical message sequences for some of the scenarios identified in this Standard.

8.1

Scenario AB1 A gateway that supports scenario AB1 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 a QSIG message from entity A, or receipt of an H.323 message from entity B.

- 20 -

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 B1 Rule

Condition

Required action

Receipt of a QSIG FACILITY message containing a QSIG callTransferInitiate invoke APDU while the QSIG call is in the active state.

Transmit an H.323 FACILITY message containing an H.323 callTransferInitiate invoke APDU if the H.323 call state permits.

Receipt of an H.323 RELEASE COMPLETE message containing an H.323 callTransferInitiate return result APDU in response to an H.323 callTransferInitiate invoke APDU.

If a QSIG DISCONNECT message is to be transmitted, include in the QSIG DISCONNECT message a QSIG callTransferInitiate return result APDU.

Receipt of an H.323 FACILITY message containing an H.323 callTransferInitiate return error APDU in response to an H.323 callTransferInitiate invoke APDU.

Transmit a QSIG FACILITY message containing a QSIG callTransferInitiate return error APDU if the QSIG call state permits.

8.2

Scenario AB2 A gateway that supports scenario AB2 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 an H.323 message from entity A, or receipt of a QSIG message from entity B. 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 B2

Rule

Condition

Required action

Receipt of an H.323 FACILITY message containing an H.323 callTransferInitiate invoke APDU while the H.323 call is in the active state.

If the callIdentity element in the H.323 callTransferInitiate invoke APDU is not empty, transmit a QSIG FACILITY message containing a QSIG callTransferInitiate invoke APDU if the QSIG call state permits. If the callIdentity element in the H.323 callTransferInitiate invoke APDU is empty, refer to the rules in 8.12, or reject the request if single step call transfer is not supported.

Receipt of a QSIG DISCONNECT message containing a QSIG callTransferInitiate return result APDU in response to a QSIG callTransferInitiate invoke APDU.

If an H.323 RELEASE COMPLETE message is to be transmitted, include in the H.323 RELEASE COMPLETE message an H.323 callTransferInitiate return result APDU.

Receipt of a QSIG FACILITY message containing a QSIG callTransferInitiate return error APDU in response to a QSIG callTransferInitiate invoke APDU.

Transmit an H.323 FACILITY message containing an H.323 callTransferInitiate return error APDU if the H.323 call state permits.

- 21 -

8.3

Scenario AC1 A gateway that supports scenario AC1 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 a QSIG message from entity A, or receipt of an H.323 message from entity C. 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 A C 1

Rule

Condition

Required action

Receipt of a QSIG FACILITY message containing a QSIG callTransferIdentify invoke APDU while the QSIG call is either in the call received state or in the active state.

Transmit an H.323 FACILITY message containing an H.323 callTransferIdentify invoke APDU if the H.323 call state permits.

Receipt of an H.323 FACILITY message containing an H.323 callTransferIdentify return result APDU in response to an H.323 callTransferIdentify invoke APDU.

Transmit a QSIG FACILITY message containing a QSIG callTransferIdentify return result APDU if the QSIG call state permits.

Receipt of a QSIG FACILITY message containing a QSIG callTransferAbandon invoke APDU.

Transmit an H.323 FACILITY message containing an H.323 callTransferAbandon invoke APDU if the H.323 call state permits.

Receipt of an H.323 FACILITY message containing an H.323 callTransferIdentify return error APDU in response to an H.323 callTransferIdentify invoke APDU.

Transmit a QSIG FACILITY message containing a QSIG callTransferIdentify return error APDU if the QSIG call state permits.

8.4

Scenario AC2 A gateway that supports scenario AC2 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 an H.323 message from entity A, or receipt of a QSIG message from entity C. 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 A C 2

Rule

Condition

Required action

Receipt of an H.323 FACILITY message containing an H.323 callTransferIdentify invoke APDU while the H.323 call is either in the call received state or in the active state.

Transmit a QSIG FACILITY message containing a QSIG callTransferIdentify invoke APDU if the QSIG call state permits.

Receipt of a QSIG FACILITY message containing a QSIG callTransferIdentify return result APDU in response to a QSIG callTransferIdentify invoke APDU.

Transmit an H.323 FACILITY message containing an H.323 callTransferIdentify return result APDU if the H.323 call state permits.

Receipt of an H.323 FACILITY message containing an H.323 callTransferAbandon invoke APDU.

Transmit a QSIG FACILITY message containing a QSIG callTransferAbandon invoke APDU if the QSIG call state permits.

Receipt of a QSIG FACILITY message containing a QSIG callTransferIdentify return error APDU in response to a QSIG callTransferIdentify invoke APDU.

Transmit an H.323 FACILITY message containing an H.323 callTransferIdentify return error APDU if the H.323 call state permits.

- 22 -

8.5

Scenario BC1 A gateway that supports scenario BC1 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 a QSIG message from entity B, or receipt of an H.323 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 BC 1

Rule

Condition

Required action

Receipt of a QSIG SETUP message containing a QSIG callTransferSetup invoke APDU.

If an H.323 SETUP message is to be transmitted, include in the H.323 SETUP message an H.323 callTransferSetup invoke APDU. If the QSIG SETUP message also contains a QSIG callTransferUpdate invoke APDU, include an H.323 callTransferUpdate invoke APDU in the H.323 SETUP message.

Receipt of an H.323 ALERTING message containing an H.323 callTransferSetup return result APDU in response to an H.323 callTransferSetup invoke APDU.

If a QSIG ALERTING message is to be transmitted, include in the QSIG ALERTING message a QSIG callTransferSetup return result APDU. If the H.323 ALERTING message also contains an H.323 callTransferUpdate invoke APDU, include a QSIG callTransferUpdate invoke APDU in the QSIG ALERTING message.

Receipt of an H.323 CONNECT message containing an H.323 callTransferSetup return result APDU in response to an H.323 callTransferSetup invoke APDU.

If a QSIG CONNECT message is to be transmitted, include in the QSIG CONNECT message a QSIG callTransferSetup return result APDU. If the H.323 CONNECT message also contains an H.323 callTransferUpdate invoke APDU, include a QSIG callTransferUpdate invoke APDU in the QSIG CONNECT message.

Receipt of a QSIG FACILITY message containing a QSIG subaddressTransfer invoke APDU.

Transmit an H.323 FACILITY message containing an H.323 subaddressTransfer invoke APDU if the H.323 call state permits.

Receipt of an H.323 FACILITY message containing an H.323 subaddressTransfer invoke APDU.

Transmit a QSIG FACILITY message containing a QSIG subaddressTransfer invoke APDU if the QSIG call state permits.

Receipt of an H.323 RELEASE COMPLETE message containing an H.323 callTransferSetup return error APDU in response to an H.323 callTransferSetup invoke APDU.

If a QSIG DISCONNECT message is to be transmitted, include in the QSIG DISCONNECT message a QSIG callTransferSetup return error APDU.

- 23 -

8.6

Scenario BC2 A gateway that supports scenario BC2 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 an H.323 message from entity B, or receipt of a QSIG 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 BC 2

Rule

Condition

Required action

Receipt of an H.323 SETUP message containing an H.323 callTransferSetup invoke APDU.

If the callIdentity element in the H.323 callTransferSetup invoke APDU is not empty, then if a QSIG SETUP message is to be transmitted, include in the QSIG SETUP message a QSIG callTransferSetup invoke APDU. If the H.323 SETUP message also contains an H.323 callTransferUpdate invoke APDU, include a QSIG callTransferUpdate invoke APDU in the QSIG SETUP message. If the callIdentity element in the H.323 callTransferSetup invoke APDU is empty, refer to the rules in 8.14, or reject the request if single step call transfer is not supported.

Receipt of a QSIG ALERTING message containing a QSIG callTransferSetup return result APDU in response to a QSIG callTransferSetup invoke APDU.

If an H.323 ALERTING message is to be transmitted, include in the H.323 ALERTING message an H.323 callTransferSetup return result APDU. If the QSIG ALERTING message also contains a QSIG callTransferUpdate invoke APDU, include an H.323 callTransferUpdate invoke APDU in the H.323 ALERTING message.

Receipt of a QSIG CONNECT message containing a QSIG callTransferSetup return result APDU in response to a QSIG callTransferSetup invoke APDU.

If an H.323 CONNECT message is to be transmitted, include in the H.323 CONNECT message an H.323 callTransferSetup return result APDU. If the QSIG CONNECT message also contains a QSIG callTransferUpdate invoke APDU, include an H.323 callTransferUpdate invoke APDU in the H.323 CONNECT message.

Receipt of a QSIG FACILITY message containing a QSIG subaddressTransfer invoke APDU.

Transmit an H.323 FACILITY message containing an H.323 subaddressTransfer invoke APDU if the H.323 call state permits.

Receipt of an H.323 FACILITY message containing an H.323 subaddressTransfer invoke APDU.

Transmit a QSIG FACILITY message containing a QSIG subaddressTransfer invoke APDU if the QSIG call state permits.

Receipt of a QSIG call clearing message containing a QSIG callTransferSetup return error APDU in response to a QSIG callTransferSetup invoke APDU.

If an H.323 RELEASE COMPLETE message is to be transmitted, include in the H.323 RELEASE COMPLETE message an H.323 callTransferSetup return error APDU.

- 24 -

8.7

Scenario B1 A gateway that supports scenario B1 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 B, or receipt of an H.323 message from entity B’. 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 B1

Rule

Condition

Required action

Receipt of a QSIG FACILITY message containing a QSIG callTransferComplete invoke APDU.

Transmit an H.323 FACILITY message containing an H.323 callTransferComplete invoke APDU if the H.323 call state permits. If the QSIG FACILITY message also contains a QSIG callTransferUpdate APDU, then include an H.323 callTransferUpdate invoke APDU in the H.323 FACILITY message.

Receipt of a QSIG FACILITY message containing a QSIG callTransferUpdate invoke APDU.

Transmit an H.323 FACILITY message containing an H.323 callTransferUpdate invoke APDU if the H.323 call state permits.

Receipt of an H.323 FACILITY message containing an H.323 callTransferUpdate invoke APDU.

Transmit a QSIG FACILITY message containing a QSIG callTransferUpdate invoke APDU if the QSIG call state permits.

Receipt of a QSIG FACILITY message containing a QSIG subaddressTransfer invoke APDU.

Transmit an H.323 FACILITY message containing an H.323 subaddressTransfer invoke APDU if the H.323 call state permits.

Receipt of an H.323 FACILITY message containing an H.323 subaddressTransfer invoke APDU.

Transmit a QSIG FACILITY message containing a QSIG subaddressTransfer invoke APDU if the QSIG call state permits.

Receipt of a QSIG FACILITY message containing a QSIG callTransferActive invoke APDU.

Transmit an H.323 FACILITY message containing an H.323 callTransferActive invoke APDU if the H.323 call state permits.

- 25 -

8.8

Scenario B2 A gateway that supports scenario B2 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 a QSIG message from entity B’, or receipt of an H.323 message from entity B. 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 B2

Rule

Condition

Required action

Receipt of an H.323 FACILITY message containing an H.323 callTransferComplete invoke APDU.

Transmit a QSIG FACILITY message containing a QSIG callTransferComplete invoke APDU if the QSIG call state permits. If the H.323 FACILITY message also contains an H.323 callTransferUpdate APDU, then include a QSIG callTransferUpdate invoke APDU in the QSIG FACILITY message.