ITU Telecommunication Standardization Sector Document AVC-867 Study Group 15 30 December 1995 Experts Group for Video Coding and Systems Version 1 in ATM and Other Network Environments Source: Rapporteur for Q.2/15 (Sakae OKUBO) Title : Open Issues towards the Ipswich Meeting Purpose: for action ----------------------- This is a list of items which require contributions before the Ipswich meeting regarding finalization of H.225.0, H.310, H.323 and other matters. 1. H.310 text ^^^^^^^^^^^^^ - See AVC-868 for the current text. - Note that H.310 reference is with respect to TD46 (PLE/15), November 1995 - h310_det.mw6 in the AVC ftp site. 1) Relationship between default PIDd and the use of acknowledged procedures; this is dependent on the definition of start up procedures see 2.5.4/AVC-854R 2) Relationship between H.310 ROT/SOT and other terminals - Relationship with DAVIC STU for VoD services - Relationship with J.82 terminal for distribution services - Use of multiprogram TS (H.222.1 specifies single program while J.82 covers multiprogram) - J.82 uses UNacknowledged procedures for logical channel signalling, and AAL1 mandates the use of the long interleaver. - Include the relevant description in the "Scope" of H.310 see 2.8.5 3)/AVC-854R - Clarify support of DSM-CC see Footnote 34/H/310 3) Review/update of call setup and logical channel setup procedures in Figure 2/H.310 for complete pictures of the communication phases. - Start up VC: 1 VC vs 2 VCs - Signalling channel parameters for the initial and additional VCs - SOT/ROT call procedures are different from RAST ones? - Analyze all possible cases of interworking such as RAST to RAST, RAST to ROT/SOT, RAST to H.321, RAST to H.320, etc. see 2.8.5 1)/AVC-854R see Annex 7/AVC-854R see Footnote 36/H.310 - Evaluate Mr. Radha's idea of dropping the initial channel see Footnote 40/H.310 4) Definition of mandatory transfer rates: 6.abc and 9.xyz Mbit/s see 2.8.3/AVC-854R 5) Syntax, semantics and procedures for video frame synchronous C&I signals 6) Communication protocol - Clarify how to use toolkit Recommendations (H.222.0, H.222.1, H.245, Q.2931, etc.). - Clarify what H.245 procedures shall/should be used. - Specify how to handle error situations. see H.324 specifications as an example see 2.8.4/AVC-854R see Footnote 39/H.310 7) Relationship between terminal type and its attributes - Review/update Tables 2-6/H.310 which indicates mandatory and optional functions for each terminal type. - Use of MPEG1 Layer2 audio coding should be mandatory for H.310 RAST native modes? A combination of G.711 and H.262 video at 6/9 Mbit/s does not lack balance? - Functions to be supported by RAST-C terminals need clarification, particularly for H.320/H.321 mode. What should be in terminals and what should be in gateways? For example, if H.221 is allowed either in terminal or gateway, are not there interoperability issues? see discussion in 5.2/AVC-854R see Sections 1, 5.2.2.1, 5.2.3.1, 5.3, Table 5, Footnote 43 of H.310 - Clarify support of MPEG1/2 audio by ROT/SOT/RAST see Footnote 23/H.310 - Clarify support of data protocols by ROT/SOT see Footnote 24/H.310 8) Protocol stacks for T.120 data - Clarify the single VC case see Annex 6/AVC-854R see AVC-862 by T. Lyons to be distributed 9) Support of bi-directional audio and uni-directional video - RAST specifications cover this type of terminal? see 2.8.5 3)/AVC-854R 10) Number of VCs to be supported - 1 or more for RAST-P H.310 native mode? This depends on the choice of start up VC see Footnote 20/H.310 11) Multipoint communication - Text is required to set out necessary minimum support of multipoint related H.245 messages. see Section 10/H.324 see Section 5.5/H.323 2. H.225.0 text ^^^^^^^^^^^^^^^ See also Editor's notes in h225r1.ww2 dated December 20, 1995. 1) H.245 level knowledge of interworking unit/terminal differences 2) Changes related to moving RTP to the annex 3) Changes related to terminology 4) Handling of the section "Overall Call Management using RTP/RTCP" 5) Review of QOS section 6) With regard to Q.931 - there has never been an intent to bring all parts of Q.931 used into H.225.0 - this is probably impractical and unnecessary. However, we need to make every effort to be completely clear what (messages, fields, times, etc.) are required, optional, and forbidden. 7) Completion of Q.931 and the ASN.1 messages, the latter in particular. 3. H.323 text ^^^^^^^^^^^^^ See also Editor's notes in h323-9a.ww2 dated 28 December 1995. 1) LAN Terminology, including "network" and "dynamic." Of particular concern is the use of "network" by both LAN and Telecom people. Other issues include reliable/unreliable vs. assured/non-assured vs guaranteed/non-guaranteed. Also should cover transport address vs network address vs E.164 address. 2) In H.323 Sec. 5.2.5.1, consider the use of time tags by MCUs and Gateways, and also create a definition of "receive path delay." Also consider possible requirements on the decoder buffer size for video. 3) H.323 section 5.2.6 - provide a proper description of "Transparent User Data." 4) H.323 section 5.2.7 - create a table of H.245 commands and indications, indicating for each one mandatory, optional, or forbidden. 5) H.323 section 5.2.9.2 - H.245 vs RTP flow control. 6) H.323 Section 5.5 - review the definition of caps for centralized and decentralized operation, including all options, and also considering proposed H.245 changes. Consider whether the current set is complete and correct. 7) H.323 section 5.5 - a possible need for a cap in H.245 to inform that MC which endpoints are terminals and which endpoints are gateways has been expressed. Given that the Gatekeeper will know which is which, it is not clear what value is gained by having this knowledge at the H.245 level. The only difference perceived is that a gateway may take longer to respond to a cap exchange. However, this could be dealt with by setting appropriate timers in H.323. 8) H.323 section 5.6 - a more full description of how time tags are handled in each case (centralized, decentralized, etc.) is needed. This should be organized in to a separate section on each mode of operation for clarity. 9) H.323 encryption. 10) H.323 section 6.1 - the number of characters in the H.323 id needs to have some limit. It should be addressed what kinds of addresses the gatekeeper is required to translate, and when. It should also be covered how H.323 ids are generated and assigned to terminals. 11) Loopback configuration 4. H.222.1 ^^^^^^^^^^ 1) Security aspects; encryption, conditional access 5. Verification tests for H.222.1 and H.245 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 1) Bitstream exchange and verification by simulation 2) Hardware verification - Logical channel signalling in particular - From call setup to teardown for SVC - Cooperation with the LBC group These tests should be materialized. 6. H.321 ^^^^^^^^ 1) New H.221 BAS codes for 2B communications using a single VC? 2) Consideration for ATM LAN environments 7. Second phase work items ^^^^^^^^^^^^^^^^^^^^^^^^^^ 1) Verification of the H.310 total system - H.245 procedures - H.222.1 acknowledged procedures for logical channel signalling 2) Interworking between different H-series terminals accommodated in different networks - Consistent policy of function allocation for interworking - Definition of gateways see 5.2/AVC-854R see Section 8.2/H.324 see Section 5.3/H.323 3) Multipoint systems - Classical MCU configuration - Use of multicast capabilities of the ATM network - Signal processing for continuous presence 4) VBR communications - Implementation of low delay system 5) Questions for the next study period 8. Liaison with other groups ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 1) Study Group 13 (AVC-861 to be distributed) - Network performance scenario 2) Study Group 11 - Request of Correlation ID syntax in B-LLI see 2.7.1/AVC-854R - Request of re-defining terminal types in B-HLI see Footnote 35/H.310, Annex 7/AVC-854R - Universal availability of B-HLI see 2.8.5 1)/AVC-854R 4) Study Group 8 (AVC-862 to be distributed) - Protocol stacks for H.245 and T.120-series data References ^^^^^^^^^^ [1] AVC-802 Open Issues toward the Yokosuka meeting (Rapporteur), Version 3, September 1995 [2] AVC-854R Report of the Yokosuka meeting (Rapporteur), October 1995 END