ITU Telecommunication Standardization Sector Document AVC-832 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: Comments on drafts H.22Z and H.323 TUB/TEL-03-A Document: AVC-832 Purpose: Information / Discussion 1. Introduction This contribution presents some of our comments on the draft recommendations H.323 (revision #5) and H.22Z (revision #3). 2. General comments What is the H.22Z multiplex? To our understanding, H.22Z defines how to make use of existing protocols to create a multimedia connection between H.323 terminals / gateways (and control connections to the gatekeeper). There is -- for the time being -- no reason to have a separate H.22Z header in conjunction with neither - RTP/RTCP used for audio and video information (on top of UDP), nor - Q.931 used on top of TCP with RFC1006, nor - H.245 control channel on top of TCP with RFC1006, nor - T.120 data information X.224/RFC1006/ (according to T.123) (refer also to figure 4 of AVC-830). The H.22Z header is so far only useful for communication with the gatekeeper. In addition, we have identified in AVC-830 (section 3.1.4.) some kind of initialization PDU to identify what a particular connection shall be used for. This would definitively belong into the scope of H.323 PDU definitions. However, re-encapsulating every packet transmitted in the LAN using a generic H.22Z header seems to be unnecessary overhead to us. 3. Specific comments on H.22Z 3.1 Figure 1/H.22Z The H.245, Q.931, X.224 part of the figure is not clear so far. a) H.245 does not reside on top of Q.931 b) Either H.245 and Q.931 are used directly on top of the transport (be it X.224 or plain RFC1006) or they reside on top of some H.22Z reliable protocol, but this should not be termed "call-control". c) Or is X.224 class 4 to be used to provide the reliable connection? (However, this seems a lot of overhead.) d) Concerning the footnote: X.224 is required for T.125 only, it is not for Q.931 and H.245. 3.2 Section 7.2: Use of RTP/RTCP Many of the "Editor's note"s -- which to us seem very important -- should be clarified by directly talking to Steve Casner and/or Henning Schulzrinne and/or the entire AVT working group. Particularly, the code-points should be easy to get. 3.3 Section 8.1: Control PDU structure Basically, there are two choices of multiplexing different connection types (e.g. H.245 vs. Q.931). Either separate transport addresses (TCP/UDP port numbers) are used -- this approach is to be taken with RTP for efficiency reasons anyway. Or, when using the same transport address, the connection type needs to be identified which can be done immediately after setup thus eliminating the need to retransmit this information in every packet: - If TCP is used this identification can be done using the first packet (for which such an H.22Z PDU would be required). - If some H.22Z specific protocol is used over an unreliable transport the reliability part of the protocol would add some notion of a connection as well so that, again, the identification needs only be done initially. As both sides always have some state associated with the connection, this notion of a connection exists even they do not operate in a connection oriented manner (i.e. with explicit connection setup). 3.4 Section 8.4 a) Why do we define PDUs for connection setup instead of referencing those of Q.931. b) For the connection request we do not need means to address multiple nodes at this layer. Conference setup at the network and transport layer is done on a one-by-one basis, using point-to-point setup for each node. 3.5 Section 8.5 See 3.4., item a). 3.6 Section 10 (Annex A) RFC1006 should be located above the LAN boundary. This applies to both TCP/IP and SPX/IPX. This also requires changes to Figure 1/H.22Z. 4. Specific comments on H.323 4.1 Section 5.2 Terminal Characteristics a) Figure 5/H.323 currently indicates that also the call control information is passed through the H.22Z multiplex. This is misleading since the Q.931 call signaling is carried out *BEFORE* an H.22Z multiplex is established! Q.931 is an out-of-band signaling and uses a separate (TCP) connection; it is not part of H.22Z -- analogous to H.324, H.320, etc. This should be clearly indicated in Figure 5/H.323. The text in section 5.2.2, fourth bullet should be corrected accordingly. b) Q.931 PDUs shall be exchanged on a reliable connection (such as TCP). It seems unnecessary complicated to invent yet another reliability mechanism on top of UDP and to implement timeouts, retransmissions, and flow control once again. However, as packet borders should be preserved to be able to determine the length of a single Q.931 PDU, a simple TCP connection cannot be used. We propose to make use of the mechanism described in RFC1006 which prepends a four byte header: version (1 octet), reserved, mbz (1 octet), length (2 octets). This is the standard way of running OSI protocols that require packet boundaries over a stream-oriented TCP connection. 4.2 Section 6. Call Signaling a) H.323 suggests usage of an unreliable channel to avoid setup latencies and packet overhead. Even having multiple IP routers in a path between two end systems produces round trip times (on a campus ethernet/fddi) in the order of 5-10 ms (five routers on the path). Connection setup in established transport protocols (such as TCP) proceeds very quickly, so that the first data packet is expected to arrive at the target host in approx. 15 ms. We do not see the two additional packets as critical for the setup. The single severe problem we see in this context is the availability of a sufficiently large number of sockets at the gateway / gatekeeper. Maybe there is an easier solution than using a connectionless transport and defining a new reliable protocol. b) The first paragraph also refers to Q.931 PDUs being carried in H.22Z packets; this should be corrected (see comment to 5.2). c) Two different ways to set up multimedia connections are used. It is obvious that the gatekeeper needs to become involved in the setup process. Also, the messages exchanged are reasonable. However, the gatekeeper should be informed/queried by one of the communicating peer entities rather than acting as an intermediate system which is relaying all packets. This seems to make the process more complicated (and also increases the probability of failures) than necessary. In particular, this requires each terminal to implement two different procedures for call setup -- depending on whether a gatekeeper is involved or not. The following proposal retains the concept of the gatekeeper but minimizes the differences between the two setup types (gatekeeper vs. no gatekeeper). Also, the gatekeeper not acting as intermediate entity eliminates the need for a Q.931 extension to convey the network addresses to both communicating peers. Refer to AVC-830 for a revised proposal that does not require extensions to Q.931. +--------+ Query(1) +--------+ +--------+ | |----------->| | | | |Calling | Response(2)| Gate- | | Called | |Terminal|<-----------| keeper | |Terminal| | | | | | | | |Setup process as w/o gatekeeper | | | |<==============================>| | | | (refer to Q.931 for messages) | | | | | | | | | |RsvChange(3)| | | | | |----------->| | | | | |RsvChgCnf(4)| | | | | |<-----------| | | | +--------+ +--------+ +--------+ (1) The Query request contains an E.164 address to be translated into a network specific address, and, optionally, a reservation request for a certain bandwidth (and QoS). (2) The gatekeeper admits or denies the request according to his locally implemented policies. If the call is admitted, the connection setup is done directly between the two end points according to Q.931. (3) During the course of the call it is possible that a change of the QoS parameters (particularly, the bandwidth) is required. This is requested by the calling entity by sending a message to the gatekeeper. (4) The gatekeeper accepts or denies the changed QoS parameters for the connection. Note that the negotiations about changes to the channel bandwidth take place using H.245; also the information when to carry out the changes is conveyed over the H.245 control channel. d) Furthermore, H.323 should only reference Q.931 connection procedures rather than listing the various possible messages, as there are more messages of interest. Basically, all messages defined in Q.931 should be supported.(*) (*) For an implementation of an ISDN gateway these are needed anyway so that no extraordinary additional effort is needed to include the software in an H.323 terminal as well. f) It is proposed to use a call reference of 0x00. However, this field may well be used to identify PDU belonging to a particular call. This would eliminate the need to do this in the H.22Z header.