S tandard ECMA-326
June 2001
Standardizing Information
and
Communication
Systems
Corporate Telecommunication Networks – Signalling Interworking between QSIG and H.323 – Call Completion 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-326
June 2001
Standardizing
Information
and
Communication
Systems
Corporate Telecommunication Networks – Signalling Interworking between QSIG and H.323 – Call Completion Supplementary Services
Phone: +41 22 849.60.00 - Fax: +41 22 849.60.01 - URL: http://www.ecma.ch - Internet: [email protected] IW
ECMA-326.doc
05-03-02 16,31
.
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 DTS/ECMA-00215. This particular Standard defines the signalling protocol interworking for call completion supplementary services between a Private Integrated Services Network (PISN) and a packet-based private telecommunication 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 contributed to ISO/IEC JTC1 under the terms of the fast-track procedure, for adoption as an ISO/IEC International Standard.
This ECMA Standard has been adopted by the General Assembly of June 2001.
.
- i -
Table of contents 1
Scope
1
2
Conformance
1
3
References
1
4
5
Definitions 4 . 1 E x te r n a l d e f in itio n s 4 . 2 O th e r d e f in itio n s 4.2.1 Entity A 4.2.2 Entity B 4.2.3 G a te w a y 4.2.4 I P n e tw o r k 4.2.5 Leg A 4.2.6 S c e n a r io A 1 4.2.7 S c e n a r io A 2 Acronyms
2 2 2 2 2 2 2 2 2 3 3
6
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 8 6 s e r v ic e a r c h ite c tu r e 6.1.2 H . 4 5 0 . 9 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 S e le c tio n o f th e s a me g a te w a y f o r a ll p h a s e s 6 . 2 O p tio n s
3 3 3 4 4 4 5
7
Protocol interworking – General requirements
5
8
P r o t o c o l in t e r wo r k in g – M e s s a g e s a n d A P D U s 8 . 1 S ig n a llin g p h a s e 1 - in v o c a tio n o f c a ll c o mp le tio n 8.1.1 S c e n a r io A 1 8.1.2 S c e n a r io A 2 8 . 2 S ig n a llin g p h a s e 2 – u s e r B a v a ila b le n o tif ic a tio n 8.2.1 S c e n a r io A 1 8.2.2 S c e n a r io A 2 8 . 3 S ig n a llin g p h a s e 3 – CC c a ll e s ta b lis h me n t 8.3.1 S c e n a r io A 1 8.3.2 S c e n a r io A 2 8 . 4 S ig n a llin g p h a s e 4 – c a n c e lla tio n o f S S - CC 8.4.1 S c e n a r io A 1 8.4.2 S c e n a r io A 2
5 5 6 7 7 8 9 10 10 10 10 11 11
- ii -
9
P r o t o c o l in t e r wo r k in g – c o n t e n t o f A P D U s 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 9.1.1 c c b s Re q u e s t/c c n r Re q u e s t in v o k e A P D U ma p p in g 9.1.2 c c b s Re q u e s t/c c n r Re q u e s t r e tu r n r e s u lt A P D U ma p p in g 9.1.3 c c Ca n c e l/c c E x e c P o s s ib le in v o k e A P D U ma p p in g 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 9.2.1 c c b s Re q u e s t/c c n r Re q u e s t in v o k e A P D U ma p p in g 9.2.2 c c b s Re q u e s t/c c n r Re q u e s t r e tu r n r e s u lt A P D U ma p p in g 9.2.3 c c Ca n c e l/c c E x e c P o s s ib le in v o k e A P D U ma p p in g
12 12 12 12 12 13 13 13 13
Annex A - Implementation Conformance Statement (ICS) proforma
15
A n n e x B - M e s s a g e f lo w e x a m p le s
23
1
Scope This Standard specifies signalling interworking between “QSIG” and “H.323” in support of call completion supplementary services within a Corporate telecommunication Network (CN). “QSIG” is a signalling protocol that operates at the Q reference point between Private Integrated services Network 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 ECMA 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-186 specifies the QSIG protocol in support of call completion 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.9 specifies the H.323 protocol in support of call completion services. NOTE H.450.9 applies only to the 1998 version of H.323 (also known as H.323 version 2) and to later versions. In both ECMA-186 (QSIG) and ITU-Recommendation H.450.9 (H.323), the call completion supplementary services are Completion of Calls to Busy Subscribers (SS-CCBS) and Completion of Calls on No Reply (SS-CCNR). These supplementary services apply after a call establishment attempt has failed because the called user was busy or not available, and provide means to re-establish the call when the called user becomes available. Interworking between QSIG and H.323 permits a call originating at a user of a PISN to terminate at a user of a private IP network, or a call originating at a user of a private IP network to terminate at a user of a PISN. In such a scenario, this Standard allows the completion of calls when the called user becomes available after having been busy (SS-CCBS), or having not answered the original call (SS-CCNR). Interworking between a PISN employing QSIG and a public IP network employing H.323 is outside the scope of this Standard. However, the functionality specified in this Standard is in principle applicable to such a scenario when deployed in conjunction with other relevant functionality (e.g., number translation, security functions, etc.). This Standard is applicable to any interworking unit that can act as a gateway between a PISN employing QSIG and a private 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
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)
- 2 -
4
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-186
Private Integrated Services Network (PISN) - Inter-Exchange Signalling Protocol Call Completion Supplementary Services (International Standard ISO/IEC 13870)
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.9
Call completion supplementary services for H.323 (2000)
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)
– Private Integrated Services Network (PISN)
(ECMA-307)
– Private Integrated services Network eXchange (PINX)
(ECMA-133)
Additionally the definitions in ECMA-186 and ITU-T Recommendation H.450.9 apply as appropriate.
4.2
Other definitions
4.2.1
En t it y A Signalling entity at the PINX or H.323 endpoint serving the calling user (user A).
4.2.2
En t it y B Signalling entity at the PINX or H.323 endpoint serving the called user (user B).
4.2.3
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.4
I P n e t wo r k A network, unless otherwise stated a CN, offering connectionless packet-mode services based on the Internet Protocol (IP) as the network layer protocol.
4.2.5
Le g A Call segment that lies between entity A and entity B.
4.2.6
S c e n a r io A 1 Interworking arrangement in which entity A (PINX A) is in the PISN and entity B is in the IP network.
- 3 -
4.2.7
5
S c e n a r io A 2 Interworking arrangement in which entity A (endpoint A) is in the IP network and entity B is in the PISN.
Acronyms
6
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-CC
Supplementary Service Call Completion (either SS-CCBS or SS-CCNR)
SS-CCBS
Supplementary Service Completion of Calls to Busy Subscribers
SS-CCNR
Supplementary Service Completion of Calls on No Reply
Service architecture
6.1 6.1.1
Service architecture for invocation and operation EC M A - 1 8 6 s e r v ic e a r c h it e c t u r e The QSIG protocol for call completion invocation and operation is based around two signalling entities or PINX types: •
entity A – the PINX serving the calling user (user A);
•
entity B – the PINX serving the called user (user B).
Where a user is in another network, the role of entity A or entity B is performed by the other network, the gateway or the two in combination. However, from the QSIG point of view the role is performed by the gateway, which acts as a gateway PINX. This can be represented diagrammatically as shown in figure 1. Entity A
Leg A
Entity B
Figure 1 – Call completion architecture From this it can be seen that there is only one segment or “leg” as far as the QSIG protocol is concerned (regardless of any transit entities through which the signalling may pass). However, an instance of SS-CC consists of several consecutive phases, each phase being a separate instance of call related or call independent signalling. In other words, leg A in figure 1 represents several calls or call independent signalling connections between entities A and B, which all belong to a single instance of SS-CC but may take different routes through the network. The typical course of action for an instance of SS-CC is: •
Prerequisite: unsuccessful call attempt because of busy or absent user B;
•
invocation of SS-CC, using a call independent signalling connection (signalling phase 1);
•
monitoring of user B; there is no (network) signalling involved during this phase;
- 4 -
•
user B available notification, using call independent signalling, and suspension/resumption of SS-CC if user A is busy at this stage (signalling phase 2);
•
recall, resulting in an automatically initiated basic call from user A to user B (signalling phase 3);
•
cancellation of SS-CC, by the network (e.g. after timeout), or by user A or user B at any time (signalling phase 4).
NOTE Interworking is only concerned with the phases that involve (network) signalling. 6.1.2
H . 4 5 0 . 9 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.9, except that PINXs are replaced by H.323 entities as follows: •
entity A – the calling endpoint;
•
entity B – the called endpoint.
Either entity can alternatively be located at a gatekeeper or proxy (as defined in H.450.9) acting on behalf of the respective endpoint, the signalling between endpoint and gatekeeper/proxy being outside the scope of H.450.9. In this case the gatekeeper/proxy performs the role of entity A or B, respectively. However, from the H.450.9 point of view the role is performed by the endpoint. Where a user is in another network, the role of entity A or entity B is performed by the other network, the gateway or the two in combination. However, from the H.450.9 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 The architectures for ECMA-186 and H.450.9 are very similar. This means that the same architecture is applicable to the inter-networking situation between an IP network and a PISN, where one user involved is served by the IP network and the other is served by the PISN. For the point of interworking, two scenarios arise, depending on which side of the interworking point the PISN lies: •
Scenario A1: Entity A (PINX A) in PISN, entity B (endpoint B) in IP network;
•
Scenario A2: Entity A (endpoint A) in IP network, entity B (PINX B) in PISN.
The 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 a gateway PINX from the point of view of the PISN. 6.1.4
S e le c t io n o f t h e s a m e g a t e wa y f o r a ll p h a s e s Since the different phases of an SS-CC instance in general use separate signalling paths, messages belonging to different phases may pass through different gateways. In this situation it does not make sense for a gateway to maintain SS-CC related states on either side, unless it can be assured that all signalling for a particular SS-CC instance passes through the same gateway. This is the case if there is only one gateway available for connecting the particular pair of users A and B at any time, but usually not if the load is shared dynamically between several gateways. One possible way to always choose the same gateway is by means of addressing. If the gateways themselves are addressable entities with their own alias addresses / PISN numbers – in contrast to being only indirectly addressed via the alias addresses / PISN numbers of users reachable through the gateway – a specific gateway can be selected: •
on the IP side of the gateway, by using both elements destinationAddress (=gateway address) and remoteExtensionAddress (=PISN user address) within the relevant address fields of the H.450.9 APDUs or the Setup message;
•
on the PISN side of the gateway, by using a (temporary) gateway number, selected (by the gateway) to represent the remote user in this instance of SS-CC at this gateway. The gateway then has to map
- 5 -
between the temporarily assigned number and the pair of elements destinationAddress / remoteExtensionAddress. However, the interworking procedures specified in this Standard do not by themselves require the use of the same gateway for all signalling related to a particular instance of SS-CC. NOTE It will be required if connection retention and connection release methods have to be interworked (see 6.2 and 8.1 for more information).
6.2
Options SS-CC can be – and has been – implemented in different ways. Both QSIG and H.323 offer several options, mainly for ease of interworking with existing implementations in other networks. The following options of SS-CC can be selected by implementations both in QSIG and in H.323: •
Service retention: If a CC call attempt fails because user B is busy again, SS-CC may either re-enter the monitoring phase (service retention) or be cancelled (service non-retention).
•
Connection retain/release method: A call independent signalling connection may or may not be maintained between entities A and B during monitoring phases, i.e. phases without signalling.
For both options negotiation is possible, and both can be interworked between QSIG and H.323. The following option is only available in QSIG: •
Path reservation/non-reservation: A network path is established for the CC call before informing user A (path reservation), or user A is informed first and the CC call is then established as a basic call upon acceptance by user A (path non-reservation).
H.323 supports only path non-reservation, therefore path reservation cannot be directly interworked.
7
Protocol interworking – General requirements Protocol interworking between H.323 and QSIG for call completion 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 apply:
8.1
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.
Signalling phase 1 - invocation of call completion The invocation procedure of call completion uses a call independent signalling connection, which may be retained for signalling phase 2 onwards (see below) or released at the end of signalling phase 1. The interworking rules imply that the signalling connection is either retained on both sides or released on both sides of the gateway. Interworking scenarios where the connection is released on one side and retained on the other are not provided for.
- 6 -
NOTE 1 Element retain-sig-connection in the ccbsRequest / ccnrRequest invoke APDU will be passed on by the gateway if present and allows entity A to ask for a specific method. Entity B will honour this request unless further interworking requires a different method. If the element is not present entity B will choose the method. NOTE 2 A possible reason for "mixed" scenarios is a concatenation of networks some of which are neither H.323 nor QSIG. An implementation may support such scenarios in a proprietary way. In this case the side without signalling connection must be able to locate the gateway initially used (which has retained the connection on the other side). 6.1.4 shows how this could be achieved. Service retention is negotiated end-to-end between entities A and B. 8.1.1
S c e n a r io A 1 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 a QSIG message from entity A, or receipt of an H.323 message from entity B.
Table 1 – Message and APDU handling requirements for signalling phase 1, scenario A1 Rule
Condition
Required action
1.1
Receipt of a QSIG SETUP message for a call independent signalling connection, containing a QSIG ccbsRequest or ccnrRequest invoke APDU.
If the call independent signalling connection can be extended into the IP network, transmit an H.323 SETUP message for a call independent signalling connection, containing an H.323 ccbsRequest or ccnrRequest invoke APDU.
1.2
Receipt of an H.323 CONNECT message containing an H.323 ccbsRequest or ccnrRequest return result APDU.
If a QSIG CONNECT message is to be transmitted, include in the QSIG CONNECT message a QSIG ccbsRequest or ccnrRequest return result APDU.
1.3
Receipt of an H.323 RELEASE COMPLETE message containing an H.323 ccbsRequest or ccnrRequest return result APDU.
Transmit a QSIG RELEASE message containing a QSIG ccbsRequest or ccnrRequest return result APDU if the QSIG call state permits.
1.4
Receipt of an H.323 RELEASE COMPLETE message containing an H.323 ccbsRequest or ccnrRequest return error APDU.
Transmit a QSIG RELEASE message containing a QSIG ccbsRequest or ccnrRequest return error APDU if the QSIG call state permits.
- 7 -
8.1.2
S c e n a r io A 2 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 an H.323 message from entity A, or receipt of a QSIG message from entity B.
Table 2 – Message and APDU handling requirements for signalling phase 1, scenario A2 Rule
Condition
Required action
1.1
Receipt of an H.323 SETUP message for a call independent signalling connection, containing an H.323 ccbsRequest or ccnrRequest invoke APDU.
If the call independent signalling connection can be extended into the PISN, transmit a QSIG SETUP message for a call independent signalling connection, containing a QSIG ccbsRequest or ccnrRequest invoke APDU.
1.2
Receipt of a QSIG CONNECT message containing a QSIG ccbsRequest or ccnrRequest return result APDU.
If an H.323 CONNECT message is to be transmitted, include in the H.323 CONNECT message an H.323 ccbsRequest or ccnrRequest return result APDU.
1.3
Receipt of a QSIG RELEASE message containing a QSIG ccbsRequest or ccnrRequest return result APDU.
Transmit an H.323 RELEASE COMPLETE message containing an H.323 ccbsRequest or ccnrRequest return result APDU if the H.323 call state permits.
1.4
Receipt of a QSIG RELEASE message containing a QSIG ccbsRequest or ccnrRequest return error APDU.
Transmit an H.323 RELEASE COMPLETE message containing an H.323 ccbsRequest or ccnrRequest return error APDU if the H.323 call state permits.
8.2
Signalling phase 2 – user B available notification The procedures of this phase use either the retained call independent signalling connection or a new one if the previous one was released after signalling phase 1. If user A is busy at this stage, SS-CC will be suspended and resumed when user A becomes free, which will result in monitoring the status of user B again, and signalling phase 2 will eventually be re-entered. However, in scenario A2 there is a slight danger of incompatible protocol states at entities A and B caused by one specific combination of options where QSIG and H.323 deviate. The procedures below specify a method to resolve this conflict with a high probability of success. If user A is not busy the service will proceed from signalling phase 2 to signalling phase 3 (or signalling phase 4 in case of failure).
- 8 -
8.2.1
S c e n a r io A 1 A gateway that supports scenario A1 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 B.
Table 3 – Message and APDU handling requirements for signalling phase 2, scenario A1 Rule
Condition
Required action
2.1
Receipt of an H.323 SETUP message for a call independent signalling connection, containing an H.323 ccExecPossible invoke APDU.
If the call independent signalling connection can be extended into the PISN, transmit a QSIG SETUP message containing a QSIG ccExecPossible invoke APDU.
2.2
Receipt of an H.323 FACILITY message containing an H.323 ccExecPossible invoke APDU.
Transmit a QSIG FACILITY message containing a QSIG ccExecPossible invoke APDU if the QSIG call state permits.
2.3
Receipt of a QSIG FACILITY message containing a QSIG ccSuspend invoke APDU.
Transmit an H.323 FACILITY message containing an H.323 ccSuspend invoke APDU if the H.323 call state permits.
2.4
Receipt of a QSIG RELEASE message containing a QSIG ccSuspend invoke APDU. (Note)
Transmit an H.323 RELEASE COMPLETE message containing an H.323 ccSuspend invoke APDU if the H.323 call state permits.
2.5
Receipt of a QSIG CONNECT message containing a QSIG ccSuspend invoke APDU.
If an H.323 CONNECT message is to be transmitted, include in the H.323 CONNECT message an H.323 ccSuspend invoke APDU.
2.6
Receipt of a QSIG FACILITY message containing a QSIG ccResume invoke APDU.
Transmit an H.323 FACILITY message containing an H.323 ccResume invoke APDU if the H.323 call state permits.
NOTE This should not occur as it is a path reservation specific procedure, but causes no harm on the H.323 side.
- 9 -
8.2.2
S c e n a r io A 2 A gateway that supports scenario A2 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 B.
Table 4 – Message and APDU handling requirements for signalling phase 2, scenario A2 Rule
Condition
Required action
2.1
Receipt of a QSIG SETUP message for a call independent signalling connection, containing a QSIG ccExecPossible invoke APDU.
If the call independent signalling connection can be extended into the IP network, transmit an H.323 SETUP message containing an H.323 ccExecPossible invoke APDU.
2.2
Receipt of a QSIG FACILITY message containing a QSIG ccExecPossible invoke APDU.
Transmit an H.323 FACILITY message containing an H.323 ccExecPossible invoke APDU if the H.323 call state permits.
2.3
Receipt of an H.323 FACILITY message containing an H.323 ccSuspend invoke APDU.
Transmit a QSIG FACILITY message containing a QSIG ccSuspend invoke APDU if the QSIG call state permits.
2.4
Receipt of an H.323 RELEASE COMPLETE message containing an H.323 ccSuspend invoke APDU.
Transmit a QSIG RELEASE message without a QSIG ccSuspend invoke APDU if the QSIG call state permits. (Note 1)
2.5
Receipt of an H.323 CONNECT message containing an H.323 ccSuspend invoke APDU.
If a QSIG CONNECT message is to be transmitted, include in the QSIG CONNECT message a QSIG ccSuspend invoke APDU.
2.6
Receipt of an H.323 FACILITY message containing an H.323 ccResume invoke APDU.
Transmit a QSIG FACILITY message containing a QSIG ccResume invoke APDU if the QSIG call state permits.
2.7
Receipt of an H.323 SETUP message for a call independent signalling connection containing an H.323 ccResume invoke APDU.
Return a ccExecPossible invoke APDU (omitting the argument or including it in the short form) in an H.323 FACILITY message, followed by an H.323 RELEASE COMPLETE message. (Note 2)
NOTE 1 Sending of a ccSuspend invoke APDU in a RELEASE message would be possible in QSIG, but then the following CC call is expected to use path reservation. The suppression of ccSuspend at the gateway in this case avoids inconsistent protocol states at entities A and B at the expense of a possible (implementation specific) timeout in entity B. NOTE 2 The ccResume cannot be passed on in a SETUP message on the QSIG side. Due to the likely protocol state at entity B, inviting entity A to initiate signalling phase 3 offers the best chance of successfully completing the service. In this case the gateway is responsible for clearing the signalling connection on the H.323 side and suppressing a ccSuspend invoke APDU which may be received (in a FACILITY message) in response to ccExecPossible.
- 10 -
8.3
Signalling phase 3 – CC call establishment The procedures of this signalling phase are call related.. Because H.450.9 does not specify a path reservation method, the actions specified below result in the rejection of a QSIG path reservation request.
8.3.1
S c e n a r io A 1 A gateway that supports scenario A1 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 A, or receipt of an H.323 message from entity B.
Table 5 – Message and APDU handling requirements for signalling phase 3, scenario A1 Rule
Condition
Required action
3.1
Receipt of a QSIG SETUP message containing a QSIG ccRingout invoke APDU.
If an H.323 SETUP message is to be transmitted, include in the H.323 SETUP message an H.323 ccRingout invoke APDU.
3.2
Receipt of an H.323 RELEASE COMPLETE message containing an H.323 ccRingout return error APDU.
Transmit a QSIG DISCONNECT message containing a QSIG ccRingout return error APDU if the QSIG call state permits.
3.3
Receipt of a QSIG SETUP message containing a QSIG ccPathReserve invoke APDU.
No mapping, return a QSIG DISCONNECT message including a ccPathReserve return error APDU with value 'failedDueToInterworking'.
8.3.2
S c e n a r io A 2 A gateway that supports scenario A2 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 A, or receipt of a QSIG message from entity B.
Table 6 – Message and APDU handling requirements for signalling phase 3, scenario A2 Rule
Condition
Required action
3.1
Receipt of an H.323 SETUP message containing an H.323 ccRingout invoke APDU.
If a QSIG SETUP message is to be transmitted, include in the QSIG SETUP message a QSIG ccRingout invoke APDU.
3.2
Receipt of a QSIG DISCONNECT message containing a QSIG ccRingout return error APDU.
Transmit an H.323 RELEASE COMPLETE message containing an H.323 ccRingout return error APDU if the H.323 call state permits.
8.4
Signalling phase 4 – cancellation of SS-CC This phase covers the unsuccessful termination of an SS-CC instance either through an explicit request for cancellation or through exception handling (e.g. timeout). It does not occur if an instance of SS-CC terminates successfully. The cancellation procedures apply anytime after signalling phase 1 is completed. They use call independent signalling.
- 11 -
8.4.1
S c e n a r io A 1 A gateway that supports scenario A1 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 A, or receipt of an H.323 message from entity B. T a b l e 7 – M e s s a g e a n d A P D U h a n d l i n g r e q u i r e m e nt s f o r c a n c e l l a t i o n , s c e n a r i o A 1
Rule
Condition
Required action
4.1
Receipt of a QSIG SETUP message for a call independent signalling connection, containing a QSIG ccCancel invoke APDU.
If the call independent signalling connection can be extended into the IP network, transmit an H.323 SETUP message containing an H.323 ccCancel invoke APDU.
4.2
Receipt of a QSIG RELEASE message containing a QSIG ccCancel invoke APDU.
Transmit an H.323 RELEAE COMPLETE message containing an H.323 ccCancel invoke APDU if the H.323 call state permits.
4.3
Receipt of an H.323 SETUP message for a call independent signalling connection, containing an H.323 ccCancel invoke APDU.
If the call independent signalling connection can be extended into the PISN, transmit a QSIG SETUP message containing a QSIG ccCancel invoke APDU.
4.4
Receipt of an H.323 RELEASE COMPLETE message containing an H.323 ccCancel invoke APDU.
Transmit a QSIG RELEASE message containing a QSIG ccCancel invoke APDU if the QSIG call state permits.
8.4.2
S c e n a r io A 2 A gateway that supports scenario A2 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 A, or receipt of a QSIG message from entity B. T a b l e 8 – M e s s a g e a n d A P D U h a n d l i n g r e q u ir e m e n t s f o r c a n c e l l a t i o n , s c e n a r i o A 2
Rule
Condition
Required action
4.1
Receipt of an H.323 SETUP message for a call independent signalling connection, containing an H.323 ccCancel invoke APDU.
If the call independent signalling connection can be extended into the PISN, transmit a QSIG SETUP message containing a QSIG ccCancel invoke APDU.
4.2
Receipt of an H.323 RELEASE COMPLETE message containing an H.323 ccCancel invoke APDU.
Transmit a QSIG RELEASE message containing a QSIG ccCancel invoke APDU if the QSIG call state permits.
4.3
Receipt of a QSIG SETUP message for a call independent signalling connection, containing a QSIG ccCancel invoke APDU.
If the call independent signalling connection can be extended into the IP network, transmit an H.323 SETUP message containing an H.323 ccCancel invoke APDU.
4.4
Receipt of a QSIG RELEASE message containing a QSIG ccCancel invoke APDU.
Transmit an H.323 RELEAE COMPLETE message containing an H.323 ccCancel invoke APDU if the H.323 call state permits.
- 12 -
9
Protocol interworking – content of APDUs This clause contains the requirements for the mapping of elements that are not covered by the general requirements in clause 7. Rules are provided •
for elements that are mandatory in at least one of the protocols (optional elements that cannot be mapped may be discarded if received);
•
for elements which require a specific setting due to interworking between QSIG and H.323;
•
for elements which have no equivalent in the other protocol.
9.1
APDU content mapping from QSIG to H.323
9.1.1
ccbsRequest/ccnrRequest invoke APDU mapping When transmitting an H.323 ccbsRequest/ccnrRequest invoke APDU as a result of receiving a QSIG ccbsRequest/ccnrRequest invoke APDU, a gateway shall map elements in accordance with table 9. Ta b le 9 – c c b s R e q u e s t /c c n r R e q u e s t in v o k e A P D U m a p p in g f r o m Q S I G t o H . 3 2 3
element name
QSIG element type “(M)” denotes mandatory element
H.323 element type “(M)” denotes mandatory element
Mapping requirement
service
PSS1InformationElement (M) with embedded BC[,LLC][,HLC]
BasicService (ENUMERATED) (M)
Ignore LLC and HLC
Information transfer capability: speech unrestr. digital information 3.1 kHz audio
speech unrestrictedDigitalInformation audio3100Hz
Map if BC contains coding standard = ‘ITU-T’, transfer mode = ‘circuit mode’ and information transfer rate = ‘64kbit/s’, otherwise reject operation Further mapping rules are outside the scope of this Standard
can-retainservice 9.1.2
BOOLEAN
BOOLEAN (M)
Set to 'FALSE' if not present
ccbsRequest/ccnrRequest return result APDU mapping When transmitting an H.323 ccbsRequest/ccnrRequest return result APDU as a result of receiving a QSIG ccbsRequest/ccnrRequest return result APDU, a gateway shall map elements in accordance with table 10.
Ta b le 1 0 – c c b s R e q u e s t /c c n r R e q u e s t r e t u r n r e s u lt A P D U m a p p in g f r o m Q S I G t o H . 3 2 3 element name
QSIG element type “(M)” denotes mandatory element
H.323 element type “(M)” denotes mandatory element
Mapping requirement
retainservice
BOOLEAN
BOOLEAN (M)
Set to 'FALSE' if not present
9.1.3
ccCancel/ccExecPossible invoke APDU mapping When transmitting an H.323 ccCancel or ccExecPossible invoke APDU with argument longArg, as a result of receiving a QSIG ccCancel or ccExecPossible invoke APDU with argument fullArg (in a SETUP message), a gateway shall map element service in accordance with table 9 above.
- 13 -
9.2
APDU content mapping from H.323 to QSIG
9.2.1
ccbsRequest/ccnrRequest invoke APDU mapping When transmitting a QSIG ccbsRequest/ccnrRequest invoke APDU as a result of receiving an H.323 ccbsRequest/ccnrRequest invoke APDU, a gateway shall map elements in accordance with table 11. Ta b le 1 1 – c c b s R e q u e s t /c c n r R e q u e s t in v o k e A P D U m a p p in g f r o m H . 3 2 3 t o Q S I G
element name
H.323 element type “(M)” denotes mandatory element
QSIG element type “(M)” denotes mandatory element
Mapping requirement
service
BasicService (ENUMERATED) (M)
PSS1InformationElement (M) with embedded BC[,LLC][,HLC]
Do not generate LLC and HLC
Information transfer capability: speech unrestr. digital information 3.1 kHz audio
Map BC as indicated
speech unrestrictedDigitalInformation audio3100Hz
Further mapping rules are outside the scope of this Standard
Coding standard = ‘ITU-T’, Transfer mode = ‘circuit mode’ Information transfer rate = ‘64kbit/s’ 9.2.2
ccbsRequest/ccnrRequest return result APDU mapping When transmitting a QSIG ccbsRequest/ccnrRequest return result APDU as a result of receiving an H.323 ccbsRequest/ccnrRequest return result APDU, a gateway shall map elements in accordance with table 12.
Ta b le 1 2 – c c b s R e q u e s t /c c n r R e q u e s t r e t u r n r e s u lt A P D U m a p p in g f r o m H . 3 2 3 t o Q S I G element name
H.323 element type “(M)” denotes mandatory element
QSIG element type “(M)” denotes mandatory element
Mapping requirement
no-pathreservation
–
BOOLEAN
Set to 'TRUE'
9.2.3
ccCancel/ccExecPossible invoke APDU mapping When transmitting a QSIG ccCancel or ccExecPossible invoke APDU as a result of receiving an H.323 ccCancel or ccExecPossible invoke APDU with argument longArg (in a SETUP message), a gateway shall map elements in accordance with table 13. Ta b le 1 3 – c c C a n c e l / c c Ex e c P o s s ib le in v o k e A P D U m a p p in g f r o m H . 3 2 3 t o Q S I G
H.323 element name / type “(M)” denotes mandatory element
QSIG element name / type “(M)” denotes mandatory element
Mapping requirement
longArg (SEQUENCE): numberA numberB ccIdentifier service
fullArg (SEQUENCE): numberA (M) numberB (M) – service (M)
Discard APDU if one or more of the elements numberA, numberB, service are missing (further actions implementation dependent) map service as indicated in table 11 above
- 14 -
- 15 -
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);
- 16 -
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).
- 17 -
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).
A.3.2
Specification for which this ICS applies Title
Corporate telecommunication networks – Signalling interworking between QSIG and H.323 – Call completion 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):
- 18 -
A.4
Major capabilities Table A.1 - Major capabilities
Item
Question: Does the implementation...
MC 1
Conditions for status
Status
Reference
Support
support scenario A1
M
6.1.3
[ ]Yes
MC 2
support scenario A2
M
6.1.3
[ ]Yes
MC 3
support selection of the same gateway for all phases
O
6.1.4
[ ]Yes [ ]No
MC 4
support the connection release method
M
6.2
[ ]Yes
MC 5
support the connection retention method
M
6.2
[ ]Yes
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
- 19 -
A.6
Message and APDU handling
A.6.1
Message and APDU handling for scenario A1 Ta b le A . 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 A 1
Item
Question: Does the implementation...
MA1 1
Status
Reference
Support
behave in accordance with rule 1.1 for scenario A1
M
8.1.1
[ ]Yes
MA1 2
behave in accordance with rule 1.2 for scenario A1
M
8.1.1
[ ]Yes
MA1 3
behave in accordance with rule 1.3 for scenario A1
M
8.1.1
[ ]Yes
MA1 4
behave in accordance with rule 1.4 for scenario A1
M
8.1.1
[ ]Yes
MA1 5
behave in accordance with rule 2.1 for scenario A1
M
8.2.1
[ ]Yes
MA1 6
behave in accordance with rule 2.2 for scenario A1
M
8.2.1
[ ]Yes
MA1 7
behave in accordance with rule 2.3 for scenario A1
M
8.2.1
[ ]Yes
MA1 8
behave in accordance with rule 2.4 for scenario A1
M
8.2.1
[ ]Yes
MA1 9
behave in accordance with rule 2.5 for scenario A1
M
8.2.1
[ ]Yes
MA1 10
behave in accordance with rule 2.6 for scenario A1
M
8.2.1
[ ]Yes
MA1 11
behave in accordance with rule 3.1 for scenario A1
M
8.3.1
[ ]Yes
MA1 12
behave in accordance with rule 3.2 for scenario A1
M
8.3.1
[ ]Yes
MA1 13
behave in accordance with rule 3.3 for scenario A1
M
8.3.1
[ ]Yes
MA1 14
behave in accordance with rule 4.1 for scenario A1
M
8.4.1
[ ]Yes
MA1 15
behave in accordance with rule 4.2 for scenario A1
M
8.4.1
[ ]Yes
MA1 16
behave in accordance with rule 4.3 for scenario A1
M
8.4.1
[ ]Yes
MA1 17
behave in accordance with rule 4.4 for scenario A1
M
8.4.1
[ ]Yes
Comments:
Conditions for status
- 20 -
A.6.2
Message and APDU handling for scenario A2 Ta b le A . 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 A 2
Item
Question: Does the implementation...
MA2 1
Status
Reference
Support
behave in accordance with rule 1.1 for scenario A2
M
8.1.2
[ ]Yes
MA2 2
behave in accordance with rule 1.2 for scenario A2
M
8.1.2
[ ]Yes
MA2 3
behave in accordance with rule 1.3 for scenario A2
M
8.1.2
[ ]Yes
MA2 4
behave in accordance with rule 1.4 for scenario A2
M
8.1.2
[ ]Yes
MA2 5
behave in accordance with rule 2.1 for scenario A2
M
8.2.2
[ ]Yes
MA2 6
behave in accordance with rule 2.2 for scenario A2
M
8.2.2
[ ]Yes
MA2 7
behave in accordance with rule 2.3 for scenario A2
M
8.2.2
[ ]Yes
MA2 8
behave in accordance with rule 2.4 for scenario A2
M
8.2.2
[ ]Yes
MA2 9
behave in accordance with rule 2.5 for scenario A2
M
8.2.2
[ ]Yes
MA2 10
behave in accordance with rule 2.6 for scenario A2
M
8.2.2
[ ]Yes
MA2 11
behave in accordance with rule 2.7 for scenario A2
M
8.2.2
[ ]Yes
MA2 12
behave in accordance with rule 3.1 for scenario A2
M
8.3.2
[ ]Yes
MA2 13
behave in accordance with rule 3.2 for scenario A2
M
8.3.2
[ ]Yes
MA2 14
behave in accordance with rule 4.1 for scenario A2
M
8.4.2
[ ]Yes
MA2 15
behave in accordance with rule 4.2 for scenario A2
M
8.4.2
[ ]Yes
MA2 16
behave in accordance with rule 4.3 for scenario A2
M
8.4.2
[ ]Yes
MA2 17
behave in accordance with rule 4.4 for scenario A2
M
8.4.2
[ ]Yes
Comments:
Conditions for status
- 21 -
A.7
APDU content mapping Table A.5 - APDU content mapping
Item
Major capability: Does the implementation...
Reference
Support
MAP 1
behave in accordance with mapping from MA1 1 QSIG ccbsRequest/ccnrRequest invoke APDU to H.323 ccbsRequest/ccnrRequest invoke APDU
M
9.1.1
[ ]Yes
MAP 2
behave in accordance with mapping from MA1 2 OR QSIG ccbsRequest/ccnrRequest return MA1 3 result APDU to H.323 ccbsRequest/ ccnrRequest return result APDU
M
9.1.2
[ ]Yes
MAP 3
behave in accordance with mapping from MA2 5 OR QSIG ccCancel/ccExecPossible invoke MA1 14 OR APDU to H.323 ccCancel/ccExecPossible MA2 16 invoke APDU
M
9.1.3
[ ]Yes
MAP 4
behave in accordance with mapping from MA2 1 H.323 ccbsRequest/ccnrRequest invoke APDU to QSIG ccbsRequest/ccnrRequest invoke APDU
M
9.2.1
[ ]Yes
MAP 5
behave in accordance with mapping from MA2 2 OR H.323 ccbsRequest/ccnrRequest return MA2 3 result APDU to QSIG ccbsRequest/ ccnrRequest return result APDU
M
9.2.2
[ ]Yes
MAP 6
behave in accordance with mapping from MA1 5 OR H.323 ccCancel/ccExecPossible invoke MA1 16 OR APDU to QSIG ccCancel/ccExecPossible MA2 14 invoke APDU
M
9.2.3
[ ]Yes
Comments:
Conditions for Status status
- 22 -
- 23 -
Annex B ( in f o r ma tiv e )
Message flow examples
This annex contains some examples of typical message sequences for 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. The following abbreviations are used: .inv
invoke APDU
.res
return result APDU
B.1
Scenario A1 PISN
IP network
Interworking unit
Call attempt failed because user B is busy QSIG SETUP ccbsRequest.inv QSIG RELEASE ccbsRequest.res
H.225.0 Setup ccbsRequest.inv H.225.0 Release Complete ccbsRequest.res monitoring user B
QSIG SETUP ccExecPossible.inv QSIG RELEASE
QSIG SETUP ccRingout.inv
H.225.0 Setup ccExecPossible.inv
user B free
H.225.0 Release Complete
H.225.0 Setup ccRingout.inv
Figure B.1 – Example of scenario A1: successful call completion on busy, connection release option
- 24 -
PISN
IP network
Interworking unit
Call attempt failed because user B is busy QSIG SETUP ccbsRequest.inv QSIG CONNECT ccbsRequest.res
H.225.0 Setup ccbsRequest.inv H.225.0 Connect ccbsRequest.res monitoring user B
QSIG FACILITY ccExecPossible.inv QSIG RELEASE
QSIG SETUP ccRingout.inv
H.225.0 Facility ccExecPossible.inv
user B free
H.225.0 Release Complete
H.225.0 Setup ccRingout.inv
Figure B.2 – Example of scenario A1: successful call completion on busy, connection retention option
- 25 -
B.2
Scenario A2 PISN
Interworking unit
IP network
Call attempt failed because user B is busy H.225.0 Setup ccbsRequest.inv
QSIG SETUP ccbsRequest.inv
H.225.0 Release Complete ccbsRequest.res
QSIG RELEASE ccbsRequest.res monitoring user B
H.225.0 Setup ccExecPossible.inv H.225.0 Release Complete
H.225.0 Setup ccRingout.inv
QSIG SETUP ccExecPossible.inv
user B free
QSIG RELEASE
QSIG SETUP ccRingout.inv
Figure B.3 – Example of scenario A2: successful call completion on busy, connection release option
- 26 -
PISN
Interworking unit
IP network
Call attempt failed because user B is busy H.225.0 Setup ccbsRequest.inv
QSIG SETUP ccbsRequest.inv
H.225.0 Connect ccbsRequest.res
QSIG CONNECT ccbsRequest.res monitoring user B
H.225.0 Facility ccExecPossible.inv H.225.0 Release Complete
H.225.0 Setup ccRingout.inv
QSIG FACILITY ccExecPossible.inv
user B free
QSIG RELEASE
QSIG SETUP ccRingout.inv
Figure B.4 – Example of scenario A2: successful call completion on busy, connection retention option
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.