ITU Telecommunication Standardization Sector Document AVC-833 STUDY GROUP 15 ____________________ Yokosuka, 24-27 October 1995 Question(s): 2/15 Source: TU Berlin / TELES GmbH Joerg Ott / Peter Kratz Voice: +49 30 314-73389 {jo,kratz}@cs.tu-berlin.de Fax: +49 30 314-25156 Title: The use of Q.931 for H.323 connection setup TUB/TEL-04-A Document: AVC-833 Purpose: Information / Discussion 1. Introduction This contribution is intended to emphasize the feasibility of the Q.931 signaling protocol for usage as setup protocol for H.323 connections in LANs. We provide a somewhat informal description of the motivation to consider Q.931 for H.323 at all and argue why this is a simple and possible approach to pursue. Also, we give a short overview of Q.931 PDUs and which of them are required in the context of H.323. 2. Motivation for using Q.931 The basic motivation for considering Q.931 is quite simple: We are designing protocols for video telephony / video conferencing service in LANs, with a particular focus on interworking with the circuit switched environments (ISDN and PSTN). Considering this background, it seems likely that the outcome of a protocol design for connection setup will be somehow similar (i.e. provide comparable functionality) to other connection setup protocols such as Q.931. Furthermore, for interoperability purposes an H.323 connection setup protocol and an ISDN connection setup protocol need to be mapped on one another in interworking units. Following this, it is natural to look for existing protocols that are capable of performing the required functions. One of the protocols of most interest is Q.931 because it provides the functionality required and has proven to work in the real world. In the following list (which is not prioritized), we address some of the issues that have been raised in the past for or against the use of Q.931, and present some new ones. - When interconnecting an H.323 terminal via gateway to an H.320 terminal there is no loss of information concerning the connection setup procedure. Mapping from one network to another is straightforward. Also, for other networks, recommendations for interconnecting them via gateways does not need to be newly defined. - Q.931 is stable and works in the real world. It is unlikely that any new connection setup protocol we build from scratch will become as stable in the near-term. Such an approach would be acceptable for a proprietary protocol, that can be refined easily if shortcomings are found during the implementation phase. However, we do not have such an implementation and trial phase to verify the new approach. - Referring to AVC-830, no modifications to Q.931 are required! Even if they were (or this requirement comes up in the future), Q.931 provides simple mechanisms for extensions in a compliant way. Even subsequent setup of multipoint connections is not prevented, as this will be negotiated using H.245. What this group should focus on is the terminal/gateway to gatekeeper protocol. - It was stated several times that Q.931 is too complex. We do not agree with that; even a simple ISDN telephone implements Q.931. Furthermore, a newly defined protocol that achieves the required functionality is likely to become as "complex" as Q.931 is -- even if the PDU formats are different, the PDUs are called differently, etc. as has been proposed. - Note that interpretation of many information elements of Q.931 is optional and that unknown information may simply be skipped when parsing PDUs. This allows keeping low-end terminals simple and cheap while not preventing high-end terminals from having valuable (distinctive) features (see next item). - Many useful types of information are conveyed with Q.931. It is desirable to have most of this information -- that is available to the user with many ISDN telephones and also (computer-integrated) videophones -- available at an H.323 terminal as well. The most important messages to be relayed include call progress and charge information when connected through a gateway to an H.320 terminal so that the user does not notice any difference between using an H.323 terminal or an H.320 terminal. - For interoperability with H.320 terminals each gateway needs to implement Q.931 anyway. Thus, also from an engineering point of view there is no benefit inventing something new. - Protocol testing is comparably simple with Q.931. Testing equipment does exist for Q.931 which only needs to be adopted for H.323 testing. This should ease the way towards interoperable products. 3. Q.931 PDUs to be used (all) Q.931 defines a total of 20 PDUs for - call establishment: ALERTING, CALL PROCEEDING, CONNECT, PROGRESS, SETUP, SETUP ACKNOWLEDGE All these PDUs would be required in a LAN environment as well. - call information phase: RESUME, RESUME ACKNOWLEDGE, RESUME REJECT, SUSPEND, SUSPEND ACKNOWLEDGE, SUSPEND REJECT, USER INFORMATION These PDUs are not fundamentally required and vendors that do not want to implement "ISDN-compatible" terminals might do without these PDUs. - call clearing: DISCONNECT, RELEASE, RELEASE COMPLETE Again, all these messages are required. - miscellaneous functions: CONGESTION CONTROL, FACILITY, INFORMATION, NOTIFY, STATUS, STATUS ENQUIRY These PDUs are useful but not definitively required. Again, this is a point where different vendors might choose different strategies to differentiate their products. As stated in section two, many of the information elements contained in the PDUs are optional as well. This provides another means to simplify implementations of low-end systems. It is up to our group to mandate a set of PDUs that have to be understood and upon receipt of which a proper reaction is required. The optional PDUs -- if any are considered optional -- must be understood by any H.323 terminal (information elements simply may be skipped if they are not understood). However, if the H.323 terminal does not support a particular PDU it must react in a way that does not confuse the sender of this PDU (e.g. ignore the PDU if no action was to be taken; or reject a request otherwise).