ITU Telecommunication Standardization Sector	Document AVC-854R
Study Group 15	27 October  1995
Experts Group for Video Coding and Systems	
in ATM and Other Network Environments

Source:	RAPPORTEUR (Sakae OKUBO)	
Title:	REPORT OF THE TWENTIETH EXPERTS GROUP MEETING IN YOKOSUKA (24-27 October 1995)	
Purpose:	Report	
Status	Confirmed by the participants	

-----------------------

1. General
2. H.310 discussion
3. H.245 discussion
4. H.22Z/H.323 discussion
5. Joint discussion of the H.310 and H.323 sub-groups
6. Work method and work plan
7. Interactions with other groups
8. Actions toward the SG15 November meeting
9. Future meetings till May 1996

1. General

1.1	Introduction

The nineteenth meeting of the Experts Group was held under chairmanship of Rapporteur (Mr. Sakae Okubo) during 24-27 October 1995 in NTT Yokosuka R&D Center, Yokosuka, Japan, at the kind invitation of the Steering Committee for the Q.2/15 Rapporteur Meeting organized by the Ministry of Posts and Telecommunications.  At the start of the meeting, Dr. Kazunori Shimamura, Executive Manager of Visual Media Laboratory, NTT Human Interface Laboratories, gave a welcoming address on behalf of the hosting organization.  A list of participants appears at the end of this report.

The time schedule of this meeting is shown in Annex 1.

It is noted that the discussion sessions for H.22Z, H.245, H.310 and H.323 were chaired by respective Editors; Mr. Dale Skran, Mr. Mike Nilsson, Mr. Sakae Okubo (on behalf of Mr. Hayder Radha) and Mr. Gary Thom.

At the end of the meeting, Rapporteur thanked the hosting organization, particularly Mr. Tomoaki Tanaka, NTT, for providing us excellent facilities and services to support the meeting.

1.2	Documentation (TD-2)

For this meeting, 54 AVC-numbered documents and 32 Temporary documents have been made available as listed in Annex 2.

1.3	Demonstration of hardware trials (AVC-840)

In the afternoon of the first day, the interconnection tests of the H.310 hardware (as specified in Annex 6 to AVC-707R) were demonstrated using the NTT experimental ATM network.  The following seven organizations joined this test: Fujitsu, GCL, KDD, Mitsubishi Electric, NEC, NTT, Sharp.

1.4	Review of the activities since the previous meeting

1.4.1	Experts Group Haninge meeting (AVC-800R, 801)

The following actions were taken after the meeting:

•	submission of SG15 white contributions (COM 15-155, 156, 157, 158)
•	Rapporteur correspondence to SG11 (TD-6)
•	liaison to MPEG re RTI (Annex 2 to AVC-800R)
•	correspondence to SA&A/ATMF and ETSI NA5 (Annexes 12, 13, 7 to AVC-800R)
•	correspondence to SG13 (Annex 3 to AVC-800R)

1.4.2	MPEG meeting in July

The following items were introduced as of our particular interest:

•	RTI (TD-4)
•	DSM-CC (AVC-805, 809)

1.4.3	SG13 meeting in July (AVC-803, 804)

The following items were introduced as of our particular interest:

•	AAL1 FEC
•	AAL5 corrupted data delivery

1.4.4	SG8 meetings in July and October (AVC-808, 828)

The following items were introduced as of our particular interest:

•	T.120/H.245 protocol stacks
•	session ID

1.4.5	SG11 meeting in August (AVC-806, 807)

The following items were introduced as of our particular interest:

•	B-HLI
•	Correlation ID

1.4.6	LBC meeting in October (AVC-853)

An update of H.245 was input from the LBC Darmstadt meeting.

1.4.7	ATMF meeting in October (AVC-848; TD-7)

Mr. J. Lynch introduced he following items as of our particular interest:

•	AAL5-SDU for TS packets
•	corrupted data delivery

1.4.8	DAVIC meeting in September (AVC-846)

Mr. O. Poncin's report drew attention to:

•	Specifications 1.0
•	CFP3

1.4.9	IETF activities related to H.323

The meeting agreed to draw attention of SG15 to the relevance of IETF activities in the context of H.22Z and RTP.

1.5	Identification of open issues (AVC-802; TD-12)

Before starting discussion, the meeting identified H.310 related major issues and H.323 related major issues which need resolutions during the week.

2. H.310 discussion

2.1	H.222.0

•	Mr. S. Dunstan and Mr. S. Okubo check Annex to AVC-709 (January 1995) and produce a defect report if necessary.
•	As to Amendments regarding the format identifier and the copyright identifier, a white contribution COM 15-190 was submitted to SG15.

2.2	H.262

2.2.1	Amendments

•	A white contribution COM 15-191 was submitted to cover the copyright identifier and the 4:2:2 profile.

2.2.2	Corrections to IDCT specifications (TD-5, TD-16)

•	Comments were requested regarding the fix for the IDCT internal register overflow problem.  Since no objections were expressed by the end of the week, the meeting decides to agree on this correction.
•	The pel value output requirement for the case of a DC only component in an IDCT block is now being discussed through correspondence in the MPEG community and it may be raised at the Dallas meeting.  Members of the AVC Experts Group have been requested to review this discussion so that we are prepared for the Dallas meeting.  No comments have been raised by the end of the meeting.

2.2.3	Corrigenda

•	We will input the two corrigenda which will come out from the MPEG Dallas meeting to the SG15 meeting.

2.3	H.321 (COM 15-157;  AVC-847; TD-24)

•	The meeting deferred the conclusion on reflecting the recent B-HLI codepoint work in SG11 to Draft H.321 until we clarify the H.310 terminal type definition.  There was a comment that the B-HLI codepoint is not yet fixed, thus describing it in Draft H.321 at this time is not appropriate.
•	We describe the reason for SDT being mandated in Draft Recommendation at the end of Section 5.6.1.  Mr. J. Lynch undertook to draft the following sentence with a footnote for this purpose, requesting Mr. H. Radha's review by correspondence: 

"To ensure compatibility with ITU-T Recommendation I.580, the SDT pointer must also be sent in a single VC carrying a single H0, H11 or H12 ISDN channel*.

Footnote * This is true for all three cases; A, B and C."

2.4	H.322 (COM15-158)

•	There is a typographical error in the cover page (H.321 should read H.322) and dotted lines in figures are erroneously converted to solid lines.

2.5	H.222.1, AAL (COM15-156)

2.5.1	FEC (AVC-803)

•	If we use AAL1 FEC without interleaving, bit error expands when there happens a cell loss because it invokes dummy byte insertion.  We see bit count integrity is important for clock recovery, thus dummy bite insertion is useful for audiovisual communications.  Furthermore, our view to the cell loss is that its probability is sufficiently low for the CBR traffic according to our network performance scenario, hence the error propagation due to cell loss is not significant.

2.5.2	AAL (AVC-804, 848)

•	We are not interested in AAL-CU because it is not used by the terminal.
•	We support the AAL5 corrupted data delivery option which provides more choices for the implementer to handle transmission errors.  It also helps the use of adaptive clock at the AAL output with bit count integrity.
•	The meeting took note of that choice of AAL is left to applications in new version of I.362.

2.5.3	TS packet to AAL5-SDU mapping (AVC-848, TD-7)

•	The recent change of the TS packet to AAL5-SDU mapping in ATMF VoD specifications should be reflected to Draft H.222.1.  Mr. S. Dunstan will produce a text of the relevant section.

2.5.4	Identification of applications for the Transport Stream (TD-3)

•	The meeting discussed if conflict with H.222.1 default PID values with other applications (DVB, ATV, ...) can be a problem.
•	We have understood the problem, but we believe that the external means (e.g. human user indication) listed as Solution 2-1 in Section A.1/TD-3 enables switching of TS decoder operational modes.
•	As we use the acknowledged procedures for logical channel signalling, we may be able to do without default PIDs though they are defined in Draft H.222.1.

2.6	RTI (TD-4)

•	We maintain the Haninge meeting decision; if t_jitter = 25 microsecond is included the standard is no more useful for ITU-T, we proposed to make it a definition document.  See Section 5.1/AVC-800R.
•	Changing from International Standard to Technical Report does not affect the ITU-T position to make it a common text Recommendation.
•	H.222.1 refers to H.222.2 as the second note in Section 9 as well as Section 2 on the assumption that the proposal from the Haninge meeting will be supported at the MPEG Dallas meeting; otherwise the note will not be included.  Mr. S. Dunstan will produce the relevant texts.
•	Mr. S. Dunstan and Mr. M. Nilsson review the Clive Holborow's rewriting of Section 3.

2.7	Q.2931, DSM-CC

2.7.1	Correlation ID (AVC-805, 807, 828; TD-32)

•	H.245 needs to indicate a particular logical channel in a particular VC when multiple VCs are involved in an audiovisual communication.  To meet this requirement, we need the following two identifications:
		- association of the multiple VCs originated at a particular terminal
		- identification of each VC 
•	The former identification is by means of calling party number and subaddress information elements.
•	The latter identification is by means of "Resource ID" in the B-HLI information element which is going to be defined.  Its length is 2 bytes.  The calling side uses the value starting from the lowest, the called side uses the value starting from the highest to cope with the case that both sides may simultaneously set up a new VC.
•	For the H.310 call processing, we do not restrict that connections are always from the same side.
•	In case of PVC, there is no need to use the Correlation ID because the association of multiple VCs should be known by both parties in advance of the communication.
•	It has been confirmed that concurrent use of H.245 and DSM-CC is possible in the Generic Identifier Transport as multiple instances of this GTI information element.
•	AVC-828 asks a question regarding identifying multiple communication sessions originating at the same terminal each of which consists of multiple connections.  This requires identification of multiple sessions.  Based on our interpretation of the SG8 requirements, the meeting agreed to define Correlation ID which consists of 2 bytes "Session ID" and 2 bytes "Resource ID".
•	Mr. J. Lych undertook to draft a response to SG8 as in Annex 3, seeking clarification of the "multiple sessions within the same terminal" and presenting a possible provision in the Q.2931 signalling element.  The meeting approved to send this correspondence to Rapporteur of Q.10/8.

2.7.2	Connection setup delay (AVC-806, 841; TD-22)

•	We are concerned with maximum 10 second delay of additional connection establishment which is prohibitive for conversational services.  Experience of the H.320 2B calls show much shorter delay.  We seek advice of SG11 whether there are any means to shorten the delay in the terminal design.
•	We desire multiple connections in a communication go through the same routing from service point of view.  If it is not possible, the differential delay within a certain threshold is acceptable.  Allowable differential delay will be of the order of some milliseconds which is expected for CDV in our network performance scenario.
•	Mr. T. Geary undertook to draft a response to the above discussion as well as our answers to the questions regarding time frame for H.310, H.321 and H.310 relation to the F-series service Recommendations as in Annex 4.  Our response is that H.310 is intended as a generic terminal Recommendation so that it covers various applications not only conversational, but also retrieval, distribution, messaging to achieve service integration.  The meeting agreed to send this response to Rapporteur of Q.15/11.
•	As to the relationship between F-series and H-series, attention was drawn to that JCG/AVMMS addressed this issue at its meeting in July 1995 (COM 15R-37). 

2.7.3	Relationship between DSM-CC and H.245 (AVC-809, 838)

•	There was a comment that comparison of DSM-CC and (H.245 + Q.2931) is needed.
•	The meeting agreed to the conclusion in AVC-838 that "when an H.310 RAST terminal also wants to work in the VoD service environment with SRM in it, it has to support not only H.245 but DSM-CC as well".
•	We will make sure that other bodies use H.245 for the control protocol of conversational services.  

2.8	H.310 specifications

2.8.1	Protocol stack (AVC-801, AVC-808)

1)	H.310 protocol reference model (AVC-801)

•	H.221 should be explicitly indicated.
•	White boxes for the T.120 protocol stack are filled in according to AVC-808 with a note for removal of redundant CRC function..
•	T.125 on top of "service convergence" is replaced with T.120 on top of X.224.
•	Updated H.310 protocol reference model is found in Annex 5 to this report.

2)	T.120 stacks (AVC-808; TD-30)

•	We thankfully accept the advice of SG8 regarding the redundant calculation of a Q.922 FCS for the H.245 stack.
•	The single VC case should include AAL1 as well.  The protocol stack for this case should exclude I.365.1 regardless of AAL being AAL1 or AAL5
•	Mr. K. Hibi undertook to draft a response to this input as in Annex 6.  The meeting agreed to send this to Rapporteur of Q.10/8.

2.8.2	Video frame synchronous C&I (AVC-835)

•	The meeting agreed to the framework of the proposal including the use of ASN.1 for the syntax representation.
•	An elementary stream is addressed by  PID / stream_id + straem_id_extension instead of logicalChannelNumber.
•	Identification of the elementary stream to which VFS C&I applies is given by the Resource ID + PID where Resource ID is omitted if the addressed elementary stream is in the same VC as for the VFS C&I PDU.
•	Semantics of the VFS C&Is should be worked out before the next meeting.
•	H.310 should add a section to specify the use of VFS C&I.  Mr. Y. Nakaya undertakes to provide such a text before the next meeting.
•	During the discussion, it was clarified that "portNumber" in H.245 is outside H.245 specifications, hence how to use it is left to the H.245 user's choice.

2.8.3	Transfer rate (AVC-839)

•	The meeting agreed to the approach of defining mandatory and optional bit rates.
•	The reference point for transfer rate definition is AAL-SAP.
•	Mandatory transfer rates are P=6.abc Mbit/s (for MP@ML medium quality services) and Q=9.xyz Mbit/s (for MP@ML high quality services) where P/Q is a simple rational number.  The specific values should be decided by the next meeting; contributions are requested.  An idea of specifying a particular VCXO frequency and its derivatives was not supported to allow wider choices in implementation.
•	Transfer rate is expressed in a multiple of 64 kbit/s.
•	Indication of locking status (locked with STC or network clock) is useful.
•	Representation of optional bit rates in H.245 capability is by enumeration; from the highest bit rate in the descending order.
•	An operational transfer rate is indicated with a new Indication PDU which includes bit rate, resource ID, AAL, PS/TS, etc..  This PDU is sent after the capability exchange.  Mr. M. Nilsson will generate the syntax and semantics of the PDU.
•	This Indication PDU is not useful for the single VC solution at the start up, but useful for bandwidth modification.

2.8.4	Communication protocol (AVC-837)

•	H.245 provides a tool kit, how to use H.245 procedures is specified in H.310.
•	H.310 specifies how to handle error situations according to the principle proposed in AVC-837.
•	Mr. K. Hibi undertakes to provide a text for the necessary minimum set of protocols by the next meeting for inclusion in the H.310 draft .

2.8.5	Start up procedures, terminal type (AVC-841, 847; TD-29)

1)	Start up VC (AVC-841)

•	The meeting considered 2 VC vs. 1 VC solutions for start-up of an H.310 communication.  Both solutions are thought workable.
•	It was confirmed that the bandwidth modification is straightforward, but AAL modification during the call is not possible.  In case of the 1 VC solution, AAL is determined before the call, thus there is no need to modify during the call; if there is AAL mismatch between the two terminals, the call should have been rejected.
•	Advantages of the single VC solution is in less call setup delay, less charge.
•	Start up of RAST calling ROT/SOT may become complicated in the single VC solution.
•	If there are two solutions, H.310 should specify one as mandatory and another optional, or both mandatory to ensure interoperability.
•	The meeting agreed to the view that we need a provision that a call be not established if the two terminals are of a not interworkable combination between RAST, ROT, SOT.
•	Mr. S Dunstan produced a comparison table as in Annex 7 for further consideration of the members.  Distinction between RAST-P and RAST-L in the codepoint might not be necessary, but the meeting concluded that they should be maintained for safety.
•	The signalling parameters for the initial channel which was studied in AVC-841 needs careful review.
•	The meeting agreed to leave "TS with FEC" and "PS with FEC" in Q.2931 B-HLI as they are.  These codepoints are not necessary for immediate use, but they might be useful in the future.
•	Rapporteur (Mr. S. Okubo) will produce a response to SG11 regarding terminal type B-HLI and confirmation for universal availability of B-HLI through correspondence.

2)	H.310 support of native only (AVC-847)

•	The meeting considered the concern expressed in AVC-847 in the context of consistency among H.310, H.323, H.324 interworking scenarios for existing H.320 and agreed to the following function allocation in the RAST-L terminal and its gateway:

-	terminal	H.320 audio coding, video coding, data	
-	gateway	conversion of multiplex, control protocol, network adaptation including AAL between H.310 and H.320	

3)	Definition of ROT and SOT (AVC-821; TD-31)

•	ROT and SOT are not only for VoD services, but they are also for simple audiovisual signal transmission, surveillance, and other services.
•	All H.310 terminals are required to support H.245 as their communication control protocol so that they interoperate each other.  Accordingly, H.310 specifies that the H.222.1 acknowledged procedures are used for the subchannel signalling.
•	The dedicated VoD terminal does not require H.245; such type of terminal is to be defined not as part of H.310 but as part of a separate Recommendation (see the diagram below).  This is in line with the practice of N-ISDN audiovisual terminals, namely H.320 with H.242 and H.331 without H.242.

•	Since ATMF VoD Specifications refer to H.310 ROT, the above conclusion is communicated with ATMF.
•	TD-31 raised a terminal configuration which is receive-only for video but receive and transmit for audio.  This is thought covered as an asymmetrical RAST terminal subject to verification.

2.8.6	Field trial results (AVC-840)

•	AVC-840 reports that no defects of H.222.0, H.222.1 or H.262 have been found through the hardware trials.
•	The meeting considered how to reflect the shaping issue observed during the field trials.  As we did not come up with proper advice (for encoder) or warning (for decoder) during the meeting, no action is taken in the H.310 draft until specific wording is proposed.
•	The field trial results are reported to SG15 as part of the progress report.  They are also reported to the MPEG Dallas meeting.

2.8.7	Data protocols (AVC-850; TD-18)

•	The meeting agreed to the support of T.120 as baseline and insert the text in TD-18 addendum which reads as follows:

"T.120 is the default basis of data interoperability between an H.323 terminal and other H.323, H.320 or H.310 terminals.  Where any optional data application is implemented using one or more of the ITU-T Recommendations which can be negotiated via H.245, the equivalent T.120 application shall be one of those provided.  The sole exception is Transparent User Data."

2.8.8	Review of the draft H.310 text (AVC-821; TD-31)

Editor's notes in AVC-821 and other comments were studied and actions for updating the H.310 draft was summarized in Annex 8.

3. H.245 discussion (COM 15-155; AVC-824, 829, 834, 853; TD-11, 19, 21, 25)

The H.245 discussions considered the issues raised in AVC-824, and the decisions of the LBC group as specified in TD-11 (Annex 9 to this report) and came to the following agreements.

1)	Agree with LBC decision.

2)	Agree with LBC decision.

3)	Agree with LBC decision.

4)	Agree with LBC decision.

5)	See below.

6)	Agree with LBC decision to remove Open bi-directional channel request protocol.

7)	Agree with LBC decision.

8)	Agree with LBC decision.

9)	Agree with LBC decision.

10)	Agree with LBC decision.

11)	Agree with LBC decision. Stuart Dunstan will produce new text and diagrams.

12)	This will not go into the version of H.245 that will be decided in November, but will be part of the agreements made during the H.323 discussions for a later revision of H.245.

13)	Agree with LBC decision.

14)	Agree with LBC decision.

15)	Agree with LBC decision.

16)	Agree with LBC decision, that is, it is part of the solution to issue 18.

17)	It was decided to clarify the meaning of multipointConference as there is no H.230 MIC. A new command will be added in which symmetry of modes is mandated and not of bit rates, as the in-coming bit rate in packet multiplexes may not be known. Bit rates can be controlled using the FlowControl command. BitRate will be added to H.261 and H.263 capability and mode messages.

18)	See below.

19)	It was agreed that this would be a useful addition to H.245 as an informative appendix, but that the introduction should be expanded to give a clearer indication of the contents of the appendix. In particular, it should be clarified why the state transition diagrams contain more information than the similar diagrams in the main text.

20)	See below.

21)	No change to the capability messages are needed as MPEG specifies that the support of either '2/0 stereo' or '1/0 + 1/0 monaural' mandates the support of the other. It was agreed that these should be distinguished (as twoChannelStereo and twoChannelDual) in the MPEG-1 and MPEG-2 audio request mode messages. Table 4 needs to be updated accordingly.

In addition to these issues, the following were also discussed.

AVC-829 proposed a new method of making the master slave decision from the two random numbers that would prevent terminals cheating to achieve their desired result. This proposal was accepted.

AVC-834 proposed adding codepoints h222Data for Data Partitioning. This was agreed, but it was thought that V.42 was not the most suitable protocol as this may not be present in ATM terminals. It was agreed that the protocol stack that will be used for T.120 and H.245 would be more suitable. Codepoints for these protocols will be added in H.245.

The H.222 multiplex capabilities were discussed. It was agreed that the semantics for bit rate should be improved to clarify that the bit rate is measured at the AAL-SAP. It was agreed to replace the single bit rate value by a means to specify a number of operating bit rates, listing the highest rate supported first.

An H.245 indication message will be added to indicate the parameters of a VC that a terminal intends to open. This will include ResourceID, bit rate (and if locked to PCR clock or network clock), AAL parameters and multiplex (TS or PS).

The items 5, 18 and 20 above could not be resolved initially as the outcome of preliminary discussions resulted in disagreement with the LBC group's decisions. Our position was documented and faxed to members of the LBC group. TD-19 includes this fax and replies from Bill Welsh and Dave Lindbergh. TD-21 includes the responses of Corey Gates and Chris Hansen, and TD-25 is the reply from Hardish Singh. No other replies were received.

These issues were then discussed again, and the replies from the LBC participants were presented and considered, and the following decisions were made.

5)	It was agreed that there was no difference between specifying retransmissions in H.245 and specifying repetitions in the case of H.245 protocol failures in the system recommendation, except the editorial differences of where the text is physically located. Consequently it was decided to allow system recommendations to specify the behaviour in the case of H.245 protocol errors including the specification of protocol retries, and to have no retransmissions within the H.245 protocols for consistency of the H.245 protocols.

	Figure I shows the behaviour when retransmissions are specified in H.245, and figure II when they are specified in the System Recommendation. It should be noted that in both cases the transmitted PDUs and the interactions with the user are the same, and occur at the same time.

	It was noted that system recommendations would have to specify the behaviour in the case of protocol errors regardless of whether these occurred after one or multiple attempts.

Figure I. Retransmissions within H.245.

Figure II. Retransmissions within System Recommendation.

18)	The proposal of AVC-829 and shown in figure 3 of TD-19 was accepted as the basis for the solution to bi-directional logical channel signalling. It was agreed that a terminal shall not start to transmit on the reverse channel until data has been received on the forward channel, and also to state that if data is received on a logical channel that is not open, the data shall be discarded and no fault shall be considered to have occurred.

	It was recognised that the initiating terminal may not know the transmission capabilities of the remote terminal and therefore might not be able to set appropriate reverse logical channel parameters, and that figure 2 of TD-19 overcame this problem. However, this solution was thought to be undesirable as it had the potential to set up half a bi-directional logical channel in the case that the responding terminal's request fails.

	To overcome this, the following was agreed. The responding terminal may accept the bi-directional request if it finds it satisfactory, and the protocol is as in figure 3 of TD-19, and is identical to the uni-directional logical channel protocol. If it finds the request unsatisfactory on the grounds of the reverse channel parameters, it shall reject the request with an appropriate (new) cause, and shall immediately initiate its own bi-directional request in which the reverse parameters are equal to the forward parameters of the original request, and in which the forward parameters indicate a mode that it can transmit and which the remote terminal is known to be able to receive. These two cases of the agreed solution are shown in figures III and IV respectively.

	This second case is very similar to that in figure 2 of TD-19, but has the benefit of avoiding setting up half channels and allows the uni-directional logical channel protocol to be used unchanged for bi-directional logical channel signalling.

Figure III. Bi-directional logical channel set up when reverse parameters are satisfactory to responding terminal.

Figure IV. Bi-directional logical channel set up when reverse parameters are not satisfactory to responding terminal.

20)	The responses from the LBC participants were thought to have missed the problem caused by timer expiry, and which is solved by the proposal in AVC-819Rev. It was decided that this problem should be solved.

	It was agreed that allowing the statusDeterminationNumber to be changed in the case of timer expiry, as proposed in AVC-819Rev, would probably not cause problems, but it was considered unnecessary to allow this as no significant benefit could be identified.

	It was therefore decided to adopt the proposal in AVC-819Rev with one change: the statusDeterminationNumber should not be changed unless equal numbers occur.

4. H.22Z/H.323 discussion (TD-28)

4.1	H.22Z RTP Issues (AVC-812, 815, 814, 822, 811; TD-10)

Issues:

	Should we use RTP?
	Should we incorporate RTP by reference?

Resolutions:

1)	Use RTP by reference.
2)	Dale Skran will write a liaison from SG15/WP1 to the IETF to request new RTP Code Points and an RTP Revision Number identifying the version that we reference.
3)	Intel is submitting an H.263 profile for RTP to the IETF and ITU by the January AVC meeting.
4)	A Session is all of the media streams (audio and video, possibly Q.931 and H.245, but not T.120) associated with a control channel. Terminals must be able to insert a Session number into the RTP header on command. Normally it would not be used, but it is mandatory that terminals can be commanded into this mode. It may be in the RTP header extension for audio and video. It would be appended to the Q.931 and H.245 messages. How the Session ID is put in the T.120 data stream is for further study. Method to command this mode, and how the Session ID is determined will be proposed by Eli Doron for the November SG15 meeting. Proposal will address initiation of this mode during an ongoing conference. Session ID now called Diagnostic ID.

4.2	H.22Z Video Coding (AVC-816, 822; TD-10)

Issue:

	Should RTP packet contain Macro Blocks or Group of Blocks?

Resolution:

1)	Macro Block Coding is mandatory subject to change at the Nov. SG 15 meeting based on a review by all parties. If there is an objection, the fall back will be that Decoders must support both macro block and group of block coding. Encoders can generate their choice. There is still an issue about whether there is a single H.261 Cap and there is sufficient info in the packet headers to distinguish between the two, or is it necessary to have two different H.261 Caps. If RTP allows both MB and GOB coding, this resolution will be dropped as it would not be necessary.

4.3	Connection Control

4.3.1	LAN Terminal Addressing from H.320 Terminals (AVC-810)

Issue:

	How is an H.323 terminal on the LAN addressed by an H.320 terminal on the WAN?

Resolutions:

1)	Gateways need to know their WAN Numbers so they can respond to H.320 terminal requests for additional connection numbers (H.230 section 3.7).
2)	Need to have a method to transmit two stage dialing into the Gateway from the WAN. The Gateway has an E.164 address, the LAN terminal has an H.323 extension. Need to define an procedure using BAS codes (either BAS DTMF or SBE numbers). H.323 extension may be any alpha-numeric string. Existing H.320 terminals probably do not have the SBE number capability and would need to be upgraded. Other options are for multiple WAN numbers to be allocated to the gateway for addressing the LAN terminal directly; gateway has an operator that redirects the call; gateway requests the terminal for a conference identifier using TCS-3. We should mandate a method that the gateway must use (for example SBE codes), other methods could also be used. 

4.3.2	Logical Channel to LAN Address (AVC-843)

Issue:

	What is the relationship between the H.245 logical channel number and the LAN port number? 

Resolutions:

1)	Will follow AVC-843  option 2.
2)	In response to OpenLogicalChannel message, receiver returns Transport port number in the OpenLogicalChannelAck.

4.3.3	H.22Z Header

Issues:

	Is H.22Z a multiplex, if not, are H.22Z headers required?
	Does H.245 logical channel definition over-ride RTP header definitions?

Resolutions:

1)	There will be no H.22Z PDU header. Transport port level (e.g. UDP) multiplexing will be used. Connection control and H.245 will be carried on separate channels.
2)	Use RTP header to indicate media content. Use multiple OpenLogicalChannel commands to the same logical channel without first closing the logical channel in order to do a mode change.  The RTP header in the H.323 Audio stream will indicate the coding. This will simplify mode switching and will not require terminals to open and close logical channels (and LAN ports) to do a mode change. This is outside of the normal H.245 procedure. This issue still requires further work.
3)	Must resolve the effect of RTP mixers on the H.323.

4.3.4	Q.931 vs non-Q.931 (AVC-823, 827. 832, 833)

Issues:

	Should H.323 use Q.931 for call control or should it use a new procedure tailored for the LAN?

	Should call control messages be carried on a reliable or unreliable connection. Q.931 expects that it is transmitted on a reliable connection.

	Do you know a priori, when you call another node, that it has a gatekeeper and where it is, for unbound gateways.  Since we have moved away from every gatekeeper knowing about every other terminal, this seems needed.  This issue is independent of whether we use Q.931 or not. 

Resolutions:

1)	Incorporate AVC-827 call setup information into Q.931 messages potentially using the user-to-user information element, when the parameters do not exist in the Q.931. Additional H.22Z messages will be used for registration, auto-binding, queries, bandwidth negotiations, etc.
2)	Proposal is to optionally open/close reliable links for Q.931 use, and send status using unreliable means. This relieves the burden on the GK to keep a reliable link open at all times to all terminals while allowing the use of Q.931 with fewer modifications.
3)	Implication that H.245 Open Logical Channel NACK must have a reason that GK will not allow any more BW for open logical channels.
4)	We need a number of channels in the setup message; to differentiate between an outgoing 128 call and a 2*64 call.
5)	There will not be a separate H.Signal document.
6)	All call signalling messages will be described as in Q.931 PDUs not ASN.1.
7)	Can we develop the messages in ASN.1 and convert them to octets?
8)	Q.931 will be transported over a reliable channel.

4.3.5	Role of Gatekeeper and Multipoint Controller

Issues:

	Multicast Operation
	Point-to-point to Multipoint Switchover
	Mixed Centralized and Decentralized Multipoint

Resolutions:

1)	Location of the MC is not mandated. Could be in the terminal, Gateway, Gatekeeper, or separate.
2)	Delete Call Media field in connect message.
3)	Can have centralized and decentralized multipoint in the same conference.
4)	MC is just multipoint control, MP is multipoint processor which processes audio, video, and data. MCU contains MC and MP.
5)	Extend Open logical channel to include unicast and multicast capability for each stream.
6)	Some channels multicast, some channels unicast.
7)	H.245 cap exchange through the gateway is mediated by the gateway so that the H.320 caps are correctly sent to the H.323 terminal.
8)	Will define H.323 specific indications to be carried in the Q.931 cause codes.
9)	How is the destination for commands such as loopback, NS-Cap, NS-Com indicated? (addressed to the Gateway versus the H.320 terminal.) Resolved in TD-27.

4.3.6	Items to be considered in procedures and PDUs

Conference Models

1) Point to Point Only
2) Multipoint
3) Multipoint Ready Point to Point
4) Broadcast (One Transmitter, many receivers)
	5) Broadcast Panel (Multipoint with Broadcast)

Multipoint Conference Models

1) Centralized Multipoint
terminals unicast to MCU, MCU unicast to terminals
2) Hybrid Multipoint
terminals unicast to MCU, MCU multicast to terminals
3) Decentralized Video and Audio Multipoint
terminals multicast video and audio to terminals
4) Decentralized Video, Centralized Audio Multipoint
terminals multicast video to terminals, unicast audio to MCU, MCU unicast audio to terminals
5) Decentralized Video, Hybrid Audio Multipoint
terminals multicast video to terminals, unicast audio to MCU, MCU multicast audio to terminals
6) Hybrid video, centralized or decentralized audio

AdHoc Multipoint Transitions

1) Join a terminal to an existing conference
2) Invite a terminal to an existing conference
3) Join two existing conferences (future study??)
4) Split a conference into two conferences

Point-to-Point Transitions

1) Forward
2) Redirect
3) Transfer
4) Hold

Multipoint Controller Models

1) MC in terminal
2) Separate MC entity
3) MCU Entity (MC and Multipoint Processor)
4) MCU in Gateway

Gatekeeper Models

1) No Caller Gatekeeper, No Called Gatekeeper
2) Caller and Called on same Gatekeeper
3) Caller on Gatekeeper1, Called on Gatekeeper2
4) Caller on Gatekeeper1, No Called Gatekeeper
5) No Caller Gatekeeper, Called on Gatekeeper

Point-to-Point Connection Models

1) H.323 Terminal to H.323 Terminal
2) H.323 Terminal to GW to WAN Terminal (H.320)
3) WAN Terminal (H.320) to GW to H.323 Terminal
4) H.323 Terminal to GW to GW to H.323 Terminal

Multipoint Connection Models

1) Centralized Multipoint on LAN
2) Decentralized Multipoint on LAN
3) Centralized and Decentralized Multipoint on LAN
4) Centralized Multipoint on LAN, terminals on WAN
5) Decentralized Multipoint on LAN, terminals on WAN
6) Centralized and Decentralized Multipoint on LAN, terminal on WAN
7) Centralized Multipoint on LAN, MCU on WAN
8) Decentralized Multipoint on LAN, MCU on WAN
9) Centralized and Decentralized Multipoint on LAN, MCU on WAN

4.4	H.245 Changes (AVC-825, 843, 852; TD-27)

Issues:

	What changes are necessary to H.245?

Resolutions:

1)	AVC-850 reworded in TD-18 and deemed accepted for H.323 terminals. If ITU standardized data conferencing application is provided, at least the equivalent T.120 application shall be supplied.
2)	AVC-825 has been reworked and accepted. H.245 requirements have been summarized in TD-27 (Annex 10 to this report).  Changes can be added to the next revision of H.245.

4.5	H.323 Encryption (AVC-826)

Issue:

	Is each stream encrypted independently?

Resolutions:

1)	No end to end encryption between H.323 and H.320. H.323 terminal to Gateway link encrypted, Gateway to H.320 terminal link encrypted separately.
2)	Gateway is a trusted entity.
3)	Encryption commands indicate encryption between LAN endpoints only, encryption between the gateway and WAN terminal would be negotiated on the WAN side. Possibly add LAN to WAN signalling later. Encryption will only apply to unicast streams, multicast will be for further study. Each media stream will be encrypted separately.

4.6	H.323 Draft Comments (AVC-844, 842, 823, 832, 851)

Resolutions:

	Many comments discussed, agreed on which will be implemented.

4.7	H.22Z Draft Comments (AVC-822, 845, 832)

Resolutions:

	Many comments discussed, agreed on which will be implemented.

4.8	Interoperability

Resolutions:

1)	H.323 terminals shall interoperate with speech only terminal on ISDN and GSTN via the Gateway Unit.
2)	H.323 terminals on the LAN can be speech only.
3)	An T.120 terminal should be able to participate in the data portion of an H.323 conference.
4)	How do we indicate to a Gateway that an outgoing call is destined for an H.320 terminal or a speech only terminal on the WAN?

5. Joint discussion by the H.310 and H.323 sub-groups

In the morning of Thursday, 26 October, the H.310 and H.323 sub-groups had a joint session to discuss the following 4 items which may need consistency in SG15.

5.1	H.245

•	H.323 requires two types of modifications to H.245; immediate corrections which should be decided at the November SG15 meeting and nearest future additions which should be frozen in parallel with the H.323 approval.
•	We submit two documents to SG15 corresponding to the above two types.
•	Definition of MIC was discussed, see Section 3, Item 17) for the resolution.

5.2	Interworking scenarios (AVC-847)

Stimulated by AVC-847, the meeting considered interworking scenarios of H.310, H.323 and H.324 with H.320 accommodated in N-ISDN and reached the following function allocations:

	H.310 RAST-L	H.323	H.324	
Functions	T	G	T	G	T	G	
G.711 audio coding	X		X			X	
H.261 video coding	X		X		X		
Data	X		X		X		
Multiplex		X		X		X	
H.242 control protocol		X		X		X	
Network adaptation (bit rate, AAL, etc.)		X		X		X	
	Note 1 - T: Terminal, G: Gateway
	Note 2 - Gateway for H.324 is called "Interworking Adapter."

•	It is a common understanding that audio, video and data source codings should be in the terminal to avoid additional delay and quality degradation due to transcoding.
•	Other functions may be in the gateway for conversion.
•	Legacy LAN emulation on the ATM-LAN will allow coexistence of H.323 and H.310 RAST-L terminals on the same ATM-LAN.  This needs further consideration as another interworking situation.
•	There was some discussion if the gateway should be service specific or service independent.  This also needs further consideration.

5.3	Multipoint communications (AVC-849)

•	It was clarified that H.323 is already taking into account two types of multipoint models; centralized multipoint and decentralized multipoint, while H.310 will deal with the multipoint aspects as the next phase work.
•	The H.323 work will include the model discussed in AVC-849 which uses network multicast facilities.

5.4	Session ID

Though both H.310 and H.323 sub-groups are discussing "Session ID", their meanings are different.  The session ID in H.323 is more properly called "Diagnostic ID."  See Sections 2.7.1 and 4.1 above.

5.5	Data options (AVC-850; TD-18)

The meeting agreed to use the same text in H.310 and H.310 to mandate T.120 if data is optionally supported.

6. Work method and work plan

6.1	Future work (AVC-803, 849)

The meeting had a free discussion on the possible future work items which will also contribute to formulate Questions in the next study period.  The following items were listed:

•	enhanced functionalities such as multipoint, encryption, particularly use of multicast services provided by the ATM network
•	interworking among H-series terminals accommodated in different networks
•	further hardware verification
•	VBR audiovisual communications
•	distributed data and distributed control for H.323
•	application of MPEG-4 techniques (MPEG-4 tests early November 1995 may impact our future work)
•	more easily editable bitstream (such as all intra)
•	We may need to change our mindset that bandwidth is limited.  Low delay will be another important property  of the future audiovisual communications.

6.2	Document distribution

It was confirmed that use of the AVC ftp site is effective for document distribution, thus it should be continued.

7. Interactions with other groups

The meeting decided to correspond with other groups as follows:

Destination	Topic	Material	
SG8	• T.120 protocol stack	Annex 6	
	• Session ID	Annex 3	
SG11	• call setup delay	Annex 4	
	• terminal type	Section 2.8.5, Item 1)	
	• Correlation ID	Section 2.7.1	
SG13	• AAL5 corrupted data delivery	Section 2.5.2	
MPEG	• RTI	Section 2.6 above	
	• IDCT	Section 2.2.2 above	
ATMF	• H.310 terminal types	Section 2.8.5, Item 3)	

8. Actions toward the SG15 November meeting

8.1	Amendments and corrigenda for approved Recommendations

Rec.	SG15 documents	Producer	Deadline	
H.222.0	• Changes to amendments	S. Okubo	13 November	
H.262	• Changes to amendments	S. Okubo	13 November	
	• Corrigenda	S. Okubo	13 November	

8.2	Draft Recommendations which are to be decided

Rec.	SG15 document	Producer	Deadline	
H.222.1	• Updated draft	S. Dunstan	9 November	
	• Delta	S. Dunstan	9 November	
H.245	• Updated draft	M. Nilsson, S. Dunstan	9 November	
	• Delta	M. Nilsson	9 November	
	• Future additions	D. Skran	9 November	
H.321	• Delta	S. Okubo	9 November	
H.322	• Delta	S. Okubo	9 November	

8.3	Draft Recommendations which are to be determined

Rec.	SG15 document	Producer	Deadline	
H.222.2	Draft	S. Okubo	13 November	
H.22z	Draft	D. Skran	1 November	
H.310	Draft	H. Radha, S. Dunstan	9 November	
H.323	Draft	G. Thom	1 November	

8.4	Progress report

Rapporteur will report the outcome of the Haninge and Yokosuka meetings.

9. Future meetings till May 1996

Meeting	Date	Place	
Study Group 15	13 - 24 November 1995	Geneva	
21st Experts Group	 16 - 19 January 1996	Ipswich	
Study Group 15	27 May - 7 June 1996	Geneva	

END

Annexes

Annex 1	Time schedule of the Yokosuka meeting	
Annex 2	Documents for the Yokosuka meeting	
Annex 3	Response concerning AVC-828 from SG8	
Annex 4	Response concerning connection delay and common routing	
Annex 5	Updated H.310 protocol reference model	
Annex 6	Harmonization of T.120 and H.245 protocol stacks for B-ISDN	
Annex 7	Consideration on basic H.310 terminal communication modes	
Annex 8	Review of the H.310 draft text in AVC-821	
Annex 9	Report of the H.245 discussion in the LBC meeting in Darmstadt	
Annex 10	H.245 changes and additions for H.323	

Participants of the twentieth meeting of the Experts Group 
for Video Coding and Systems in ATM and Other Network Environments
held in Yokosuka, Japan
(24-27 October 1995)

Country 	Name	Organization	
Australia	Mr. Stuart Dunstan	Siemens	
USA	Mr. Fred Baker	Cisco Systems	
	Mr. Narjala Bhasker	Intel	
	Mr. Chuck Bostrom	CLI	
	Mr. Brent Browning	Sun Microsystems Computer company	
	Mr. Tom Geary	Rockwell Telecommunications	
	Mr. Colin Hulme	Intel	
	Mr. George Kajos	VideoServer	
	Mr. Vineet Kumar	Intel	
	Mr. Jeffrey J. Lynch	IBM	
	Mr. John D. Phillippy	InSoft	
	Mr. Mark Reid	PictureTel	
	Mr. Robert Reynolds	AT&T	
	Mr. Dale Skran	AT&T	
	Mr. Gary A. Thom	DIS	
	Mr. Jim Toga	Intel	
Finland	Mr. Mika Grundstroem	Tampere University of Technology	
France	Mr. Eric Gonfia	CNET	
	Mr. Bruno Lozach	LEP/Philips	
Israel	Mr. Eli Doron	RADVision	
Japan	Mr. Kohtaro Asai	Mitsubishi Electric	
	Mr. Masayuki Baba	Mitsubishi Electric	
	Mr. Shigeru Fukunaga	Oki Electric  Industry	
	Mr. Keiichi Hibi	Sharp	
	Mr. Keita Higuchi	NTT	
	Mr. Shuji Inoue	Matsushita Communication Industrial	
	Mr. James T. Kawamoto	National Semiconductor Japan	
	Mr. Jun-ichi Kimura	GCL	
	Mr. Takayuki Kobayashi	GCL	
	Mr. Kazuhiro Matsuzaki	Mitsubishi Electric	
	Mr. Yuichiro Nakaya	Hitachi	
	Mr. Susumu Oka	Mitsubishi Electric	
	Mr. Sakae Okubo	GCL	
	Mr. Kiyoshi Sakai	Fujitsu	
	Mr. Shigeyuki Sakazawa	KDD	
	Mr. Yasuyuki Sasaki	NTT	
	Mr. Tomoaki Tanaka	NTT	
	Mr. Hideyuki Ueno	Toshiba	
	Mr. Masahiro Wada	KDD	
	Mr. Mitsuharu Yano	NEC	
UK	Mr. Geoff Morrison	BT	
	Mr. Mike Nilsson	BT	

Annex 1 to AVC-854R

Time schedule of the Yokosuka meeting

	Tue 24	Wed 25	Thu 26	Fri 27	
Item	M	A	M	A	E	M	A	E	M	A	
Plenary											
	Short presentation of all the documents	√										
	Review of previous meetings	√										
	Identification of open issues	√										
	H.310 hardware trial demonstration		√									
	Review of the previous day discussions			√			√			√		
	Review of this week achievements										√	
	Work plan and work method										√	
											
H.310 sub-group											
	H.222.0, H.262		√									
	H.321, H.322		√									
	H.222.1, AAL		√									
	RTI		√									
	H.245			√								
	Q.2931, DSM-CC			√								
	H.310				√		√	√				
	Small group discussion / Editing work					√			√			
	Review									√		
											
H.323 sub-group											
	H.22Z		√									
	Connection control			√	√							
	H.245				√							
	H.323						√					
	multipoint / multicast							√				
	Small group discussion / Editing work					√			√			
	Review									√		
											
Joint session											
	H.245 						√					
	interworking scenarios for H.310, H.323						√					
	session ID / correlation ID						√					
	multipoint											

Annex 2 to AVC-854R

Documents for the Yokosuka meeting
(24-27 October 1995)

Normal Documents

AVC
 number	Pur-pose	
Title (Source)	
AVC-800R	R	Report of the Nineteenth Experts Group meeting in Haninge (15-18 may 1995) (Rapporteur)	
AVC-801	R	H.310 Network Adaptation Protocol Reference Model following Haninge meeting (S. Dunstan)	
AVC-802	R	Open Issues towards the Yokosuka Meeting (Rapporteur)	
AVC-803	R	Report of the Q.6.1 meeting (K. Yamazaki - Rapporteur for Q.6.1/13)	
AVC-804	R	Report of the joint Q.6 meeting (Rapporteurs Q.6 - K.Yamazaki, A.Odedra )	
AVC-805	P	Liaison requesting the creation of a DSS2 Correlation Identifier Information Element (DSM-CC SWG)	
AVC-806	R	Proposed Liaison Response to ITU-T SG 15 Q.2/15 (B. Petri)	
AVC-807	R	Session and Resource/Correlation identification capability of DSS2 and B-ISUP signalling protocols (SWP2/1 & SWP2/3 of SG11)	
AVC-808	R	Harmonization of T.123 and H.245 protocol stacks for B-ISDN (Rapporteur Q10/8)	
AVC-809	R	MPEG DSM-CC Meeting in Tokyo, July 24-28/95 (Vahe Balabanian)	
AVC-810	P	LAN Addressing Plan In H.323 (E. Doron)	
AVC-811	P	Defining Session ID for H.323 (E. Doron)	
AVC-812	P	H.22z Frame and LAN packet (E. Doron)	
AVC-813	P	Requirements for H.Signalling Recommendation within the scope of H.323 (E. Doron)	
AVC-814	P	Providing Quality of Service on NGQoS LANs/H.323 (E. Doron)	
AVC-815	P	RTP/RTCP use for H.22z (E. Doron)	
AVC-816	P	H.261 Video Payload for H.323 (E. Doron)	
AVC-817	P	H.245 B-LCSE modifications and illustrations (S. Dunstan)	
AVC-818	P	Informative appendix on H.245 procedures (S. Dunstan)	
AVC-819	P	Review of H.245 master slave determination procedures (S. Dunstan)	
AVC-820	P	Non-MCU Multipoint Call Setup (InSoft)	
AVC-821	P	Draft H.310 (Editor, H. Radha)	
AVC-822	P	Draft H.22z (Editor, D. Skran)	
AVC-823	P	Draft H.323 (Editor, G. Thom)	
AVC-824	R	Report of the H.245 Ad Hoc Committee (Chairperson H.245 Ad Hoc Committee)	
AVC-825	P	Conference control in H.323 (Intel)	
AVC-826	P	Comments for H.323 Encryption (Intel)	
AVC-827	P	Gatekeeper and Connection Setup in H.323 (Intel)	
AVC-828	R	Need for H.245 to support addressing and association of media streams carried over separate network connections (Rapporteur Q10/8)	
AVC-829	P	Bi-directional logical channel signalling (BT)	
AVC-830	P	Connection Management Procedures for H.323 (TELES, TUB)	
AVC-831	D	Usability of Today's LAN Multicast Environments for ITU-T Teleconferencing (TUB, TELES)	
AVC-832	I & D	Comments on drafts H.22Z and H.323 (TUB, TELES)	
AVC-833	I & D	The use of Q.931 for H.323 connection setup (TUB/TELES)	
AVC-834	I & P	Proposal for adding a simple ACK/NACK data protocol to H.245 (AT&T)	
AVC-835	P	Syntax for video frame synchronous C&I (Japan)	
AVC-836	D	Comments on bi-directional logical channel signalling in H.245 (Japan)	
AVC-837	D	Considerations on H.310 communication protocol (Japan)	
AVC-838	I	Relationship between DSM-CC and H.245 (Japan)	
AVC-839	D	Common Bitrate for H.310 Terminals (Japan)	
AVC-840	I	Report of H.310 hardware trials (Japan)	
AVC-841	P	Start up procedures for H.310 terminals (Japan)	
AVC-842	P	Gatekeeper, Gateway, and Terminal Procedures for H.323 (PictureTel)	
AVC-843	P	H.245 additions for H.323 (PictureTel)	
AVC-844	P	Comments on the H.323 draft (Intel)	
AVC-845	P	Comments on the H.22z draft (Intel)	
AVC-846	I	DAVIC status report (O. Poncin)	
AVC-847	D & P	Comments on H.321 and H.310 (IBM)	
AVC-848	I	ATM Forum AMS Status (IBM)	
AVC-849	D	ATM Multi-point in H.310 Multi-conference units (IBM)	
AVC-850	P	Comments on H.323/H.310/H.320 related to data protocols (AT&T)	
AVC-851	P	Comments on H.323 (AT&T)	
AVC-852	D	Mapping H.221/H.230 commands to H.245 commands and related issues (D. Skran, H.22Z editor)	
AVC-854	P	Update of H.245 from the LBC Darmstadt meeting	

Temporary Documents

#	Source	Title	
TD-1	Rapporteur	Agenda for the Yokosuka meeting	
TD-2	Rapporteur	Available documents for the Yokosuka meeting	
TD-3	Japan 	A Study of Schemes to Distinguish MPEG-2 Transport Streams among Applications (to ITU-R)	
TD-4	C. Holborow	Text for the RTI compliance testing	
TD-5	T. Savatier	H.262|ISO/IEC 13818-2 IDCT specifications	
TD-6	S. Okubo	Correspondence to SG11 Rapporteur	
TD-7	ATM Forum	Draft Liaison to SG15	
TD-8	S. Okubo	H.310 discussion items (Part 1)	
TD-9	W. Lidinsky, F. Burg	Overview of work in IEEE 802 on LAN Support of Multimedia Applications	
TD-10	Vineet Kumar	Position of H.323 and H.22z recommendations	
TD-11	Chairperson H.245 Ad Hoc Committee	Report of the H.245 Ad Hoc Committee	
TD-12	G. Thom	H.323/H.22Z discussion items	
TD-13	G. Thom	FIGURE 37/Q.931	
TD-14	S. Okubo	H.310 discussion items (Part 2)	
TD-15	ATM Forum	Audiovisual Multimedia Services: Video on Demand Specification 1.0	
TD-16	T. Savatier et al.	Yet another problem in IDCT?	
TD-17	S. Okubo	H.310 discussion results	
TD-18	D. Skran, G. Morrison	Revised text for H.323/H.310 data options	
TD-19	M. Nilsson	FAX to H.245 contributors of the LBC group	
TD-20	B. Haskell	Comments on H.222.1, H.245	
TD-21	C. Gates, C. Hansen	Reply to TD-19	
TD-22	T. Geary	Draft Liaison response concerning Delay for QoS and Common routing connections to minimize delay	
TD-23	M. Nilsson	Report of H.245 discussions	
TD-24	J. Lynch	Addition to H.321 re use of SDT in H.321	
TD-25	H. Singh	Reply to TD-19	
TD-26	G. Kajos	H.323/H.320 call address and type	
TD-27	H.323 Working Group 	H.245 Additions and Changes for H.323	
TD-28	G. Thom, D. Skran	H.323/H.22Z Session Report	
TD-29	S. Dunstan	Consideration on basic Rec. H.310 terminal communication modes	
TD-30	K. Hibi	Liaison to SG8 on T.120 and H.245 protocol stacks	
TD-31	G. Morrison	Comments on H.310	
TD-32	J. Lynch	Liaison statement to Q10/8	

END

Annex 3 to AVC-854R

Response concerning AVC-828 from SG8

SOURCE:	Rapporteur Q2/15	
TITLE:	Liaison statement to Q10/8	
STATUS:	Not approved by Study Group 15	
SUBJECT:	Need for H.245 to support addressing and association of media streams carried over separate network connections	
FOR:	Action before 15 January 1996	
CONTACT:	Mr. Sakae Okubo
Rapporteur for Q.2/15	Graphics Communication Laboratories
6F ANNEX TOSHIN BLDG, 4-36-19 Yoyogi,
Shibuya-ku, Tokyo 151 Japan
Phone : +81 3 5351 0181
Fax     : +81 3 5351 0185
e-mail :  okubo@gctech.co.jp	

This is in response to your liaison addressing the need for H.245 to support the association of media streams over separate network connections.

H.245 currently supports the capability to uniquely identify connections within a session, but up to now, we have assumed that a single session existed between any 2 end stations. Under this assumption sessions could be uniquely identified via the pairing of the Calling and Called party numbers when the connections are established.  In the following figure, node B has two sessions, one with A and other with C.  Each session is uniquely identified by the called and calling party numbers.  Currently we have defined a 2 byte correlation id to differentiate VCs within a session.  This correlation id is exchanged via Q.2931 via the new Generic Identifier Transport Information Element.  H.245 uses this correlation id to uniquely address each of the connections between H.245 end stations.

We understand from your liaison, you wish to have multiple sessions between two stations.  This is identified in Figure 2.  We anticipate that this connection grouping could eventually be handled via the Q.298X "Connection Group Reference," but to accommodate this possible scenario now, we have expended the correlation id to 4 bytes: two bytes Session ID and 2 bytes Resource ID.  For now, the two byte session id will be reserved.

To satisfy your request for the called party to assign the Session ID, we have identified two possibilities : 

•	Send blank for the session id in the Q.2931 call SETUP and have the called station assign it and return it in the CONNECT message. This requires Q.2931 to be enhanced to allow the generic identifier transport IE in the connect message.

•	H.245 could be enhanced to exchange the session id prior to making subsequent connections. 

We ask your advice on which scheme you prefer before proceeding with changes to either of these recommendations.

END

Annex 4 to AVC-854R

Response concerning connection delay and common routing

Question:	SG15 Q.2/15
Title:	Draft Liaison response concerning Delay for QoS and Common routing connections to minimize delay
Destination:	SG 11 Q.15/11 (DSS2)
Origin:	Rapporteur AVC Experts Group Q.2/15
APPROVAL:	SG15 AVC Rapporteur's Experts Group
SUBMITTED FOR:	Consideration
RESPONSE:	By 15 January 1996
CONTACT:	Mr. Sakae Okubo
Rapporteur SG15 Q.2/15 AVC
P +81 3 5351 0181
F +81 3 5351 0185
okubo@gctech.co.jp

SG15 AVC Experts wishes to thank SG11 for the Liaisons from their July 24-28 1995 Helsinki meeting, titled “Proposed Liaison Response to ITU-T SG15 (Q.2/15)”.  This liaison was reviewed in detail at the October 24-27 1995 Yokosuka meeting of AVC.  The results of that review and the remaining items of question or concern are defined below.

1.  Delay for QoS

Regarding matters related to delay and associated QoS, we are pleased to note that the new draft Q.2961.2 is expected to include the provision for QoS class parameters.  Regarding the issue of call establishment delay, we wish to express our preferences and concerns.  Firstly, we are hopeful that further considerations advice for terminal implementation will result in methods which provide shorter establishment delays.  Please keep us informed of your progress on the new draft Q.2961.2.

Further as our applications may likely require subsequent addition of one or more channels to an established call, minimizing the delays involved with establishment of subsequent channels is considered an important goal.  Target times of even lower than the 10 seconds stated would assure acceptable QoS, noting that the time to establish 1 or more additional channels is approximately equal.  There was notable concern expressed by this group with the 10 second call establishment delay as currently stated.

2.  Common routing and differential delay

Responding to your request for the views of Q.2/15 concerning common routing, we feel that being able to achieve common routing would be the preferred solution.  If methods to achieve and assure this cannot be defined, differential delay limits in amounts similar to those observed for cell-delay-variation are assumed to be acceptable, (2-3 ms maximum).

3.  Answer to the “ask back” questions

Regarding the timing for freezing and approval of the recommendations, the H.321 and H.322 recommendations were frozen in February 1995 and are expected to achieve Resolution 1 decision in November 1995; the H.310 recommendation is expected to be frozen at the November 1995 SG15 meeting and approved in May 1996.

Concerning the relationship of the H-series recommendations under development to the F.722 and F.732 recommendations, the recommendations under development are implementations that are supporting multiple service classes (such as videophone, videoconferencing, retrieval, distribution, messaging) defined by these F-series recommendations to achieve service integration and the H.310 will interwork with the H.323 and other H.320 terminals.

Thank you in advance for consideration of the above items.

Annex 5 to AVC-854R

Updated H.310 protocol reference model

SOURCE:	Stuart Dunstan, Siemens Ltd
TITLE:	H.310 Network Adaptation Protocol Reference Model following Yokosuka meeting

The H.310 Network Adaptation Protocol Reference Model following discussions at the Yokosuka meeting, is shown attached.

This document attempts to illustrate,

•	all of the Recommendations employed in H.310 and their relationships
•	location of network adaptation functions 

The diagram may be suitable for inclusion as an informative annex in H.310.

Changes from the previous version (AVC-801) include the following,

•	inclusion of H.221 multiplex and note 10
•	identification of the T.120 series protocol stack and update to Note 3.
•	replacement of call control label "Q.2931" with "DSS2" and note 11, listing the ITU-T signalling recommendations
•	additional paragraph in Note 5 about the relationship between H.222.1 and H.222.0
•	reference to H.222.2 in Note 6.

Figure 1.
H.310 network adaptation protocol reference model.

Notes to Figure 1.

1)	H.245, DSM-CC (ISO/IEC 13818-6), and the T.120 protocol stacks may be carried in,
-	independent ATM Virtual Channels, or
-	H.222.1

In the later case, the anticipated points of connection are shown.

2)	Clause 1.3 of ISO/IEC 13818-6 states that AAL5 is suitable for the transport of DSM-CC messages on ATM.  The figure indicates this, but leaves unspecified as to whether additional protocol beyond AAL type 5 CPCS is required.

3)	Study Group 8 have agreed to use the FR-SSCS (I.365.1) for support of T.120 series protocols in a separate VC (AVC-808).  AVC-808 recommends use of FR-SSCS also  in case of one VC, which differs from the AVC Experts Group view.  The point of connection recommended by the AVC Experts Group for T.120 series in case of one VC is shown in the figure.

4)	Video frame synchronous signals are described in H.310.

5)	H.222.1/H.222.0 functions:
-	multiplexing
-	timebase recovery
-	media synchronization
-	jitter removal
-	buffer management
-	security and access control
-	in-band signalling
-	trick modes

H.222.1 chooses elements and procedures from the generic H.222.0, and specifies their use in ATM environments.  H.222.1 also specifies code points and procedures for ITU-T defined elementary streams.

6)	This point represents the point at which the H.222.2 | ISO/IEC 13818-9: Real Time Interface applies, if it is applicable.  This point may not always be physically realised.

7)	H.222.1 network adaptation functions:
-	jitter removal

8)	Although AAL type 1 currently addresses constant bit rate operation, it is anticipated that the AAL type 1 SAR sublayer, and perhaps some of the AAL type 1 CS toolkit, will be used for variable bit rate operation.  In the case of variable bit rate operation not all of the following AAL type 1 CS sublayer functions are applicable.

AAL type 1 CS functions:
-	transmission clock recovery
-	jitter removal
-	bit error correction
-	cell loss correction
-	data structure preservation

9)	AAL type 5 (CPCS) functions:
-	bit error detection
-	cell loss detection
-	data structure preservation

9)	H.221 is required in the H.310 RAST-P terminals for interworking with H.320 terminals.

10)	B-ISDN signalling is referred to as Digital Subscriber Signalling System No. 2 (DSS2).  DSS2 is composed of the suite of protocols shown in Table 1.  

Table 1
Summary of DSS2 protocols

ITU-T Rec.	Title	
Q.2931	User Network Interface Layer 3 specification for basic call/connection control	
Q.2961.1	Additional traffic and QOS parameter indications	
Q.2962	Negotiation of traffic and QOS parameters (during cal/connection establishment)	
Q.2963	Renegotiation/modification of traffic and QOS parameters (for already established calls/connections)	
Q.2964	B-ISDN look-ahead	
Q.2971	Point-multipoint call/connection control	
Q.298x	Multiconnection calls	

- end -

Annex 6 to AVC-854R

Liaison to SG8 on T.120 and H.245 protocol stacks

SOURCE	:  Rapporteur Q.2/15
TITLE	:  Liaison to SG8 on T.120 and H.245 protocol stacks
SUBJECT	:  Harmonization of T.120 and H.245 protocol stacks for B-ISDN 
PURPOSE	:  Response to a previous Liaison and request for comments

CONTACT	: Sakae OKUBO
		  Rapporteur for Q.2/15
		  Graphics Communication Laboratories
		  6F ANNEX TOSHIN BLDG, 4-36-19 Yoyogi,
		  Shibuya-ku, Tokyo 151 Japan
		     Phone : +81 3 5351 0181
		     Fax     : +81 3 5351 0185
		     e-mail :  okubo@gctech.co.jp

Experts Group for Video Coding and Systems in ATM and Other Network Environments discussed your liaison statement (Q10/8 95-07-259 rev) at its Yokosuka meeting in October 1995.  We highly appreciated that you have accepted our suggested T.120 protocol stack for B-ISDN in case of a separate VC.  We believe that the service integration in the B-ISDN generation can be achieved by this harmonized solution between Q10/8 and Q2/15.

We further considered your proposed protocol stack for a single VC case and understood that FR-SSCS (I.365.1) is useful, when T.120 or H.245 PDUs are conveyed on AAL type 5.    However, AAL type 1 is also applicable for the transmission of H.222.1 multiplexed stream in H.310 terminals.  In this case, Q.922 can not rely on CRC in AAL-PDU, because AAL type 1 does not have a CRC mechanism.  Thus, it is necessary to use Q.922 FCS for the error checking of PDUs.  We decided that FR-SSCS was not used in the protocol stack for both AAL1 and AAL5 cases, because of the compatibility of H.222.1 multiplexed stream between AAL1 and AAL5.  Our suggested protocol stack is shown in Fig.1.

We also made a comment on your Layer 2 description in section 13.5/T.123.  It is described that both stuffing bytes and Transport Stream adaptation field are not used.  We think that stuffing is essential to adapt a PES packet, which conveys Q.922 PDU, to a TS packet.  This mechanism can be provided by stuffing byte of TS adaptation field.  Why do you think to prevent the stuffing in the TS packet level ?  How do you cope with the variable size Q.922 PDU?

We would appreciate your review and comments before the determination of the revision of T.123 in your February 1996 meeting, toward our harmonized solution on the protocol stack not only in case of a separate VC but also in case of a single VC.

END

Annex 7 to AVC-854R

Consideration on basic H.310 terminal communication modes

SOURCE:	Stuart Dunstan, Siemens Ltd
TITLE:	Consideration on basic Rec. H.310 terminal communication modes

This note attempts to summarise discussions prompted by AVC-841 [1], on possible basic Rec. H.310 terminal communication modes.

One or more basic communication modes might be recommended in H.310 to allow a high success of communication between different terminal types, and between terminals of different manufacturers.

The two following scenarios are considered;

•	single VC solution

	-	default multiplex bit rate eg 6 Mbit/s
	-	MPEG Transport Stream (TS)
	-	default audio mode
	-	AAL type 1

•	2 VC solution
	-	first VC carries low bandwidth H.245 logical channel
	-	high bandwidth AV VC opened after capability exchange

Figure 1.  Basic mode using 1 Virtual Channel (successful establishment due to AAL match)

Figure 2.  Basic mode using 2 Virtual Channels.

Table 1 compares the one VC and two VC basic modes of communication.

	1 VC	2 VC	
problems	•	possibility of call failure due to AAL mismatch
	-	user must retry with other AAL type.
	-	AAL cannot be changed during call
	-	can AAL be re negotiated at call setup?
	-	what terminal configurations cause this problem?

•	what if there is a mismatch in uni/bi directional VC?  Can Q.2931 resolve this?	•	possible long time to audio	
audio start time	•	AAL match - fast

•	different AAL - call rejected	larger than case of 1 VC with successful establishment	
cost	•	low (if multiple VCs cost more)

•	additional cost if larger bandwidth not required	perhaps more than 1 VC case	
mux rate	default may be less than or greater than that actually required	default bandwidth not required	

Terminal classification for Q.2931

The two following principles are used to guide what information should be placed into the Q.2931 Broadband Higher Layer information element,

•	enough terminal type information such that upon call establishment it is not necessary to clear the call due to incompatible terminals
•	“only essential elements ...” (section 6.3/AVC-743R)

Identification of the following terminal types is required at call setup ,

•	H.310 ROT
•	H.310 SOT
•	H.310 RAST (-P and -L are same?)
•	H.310 RAST
•	H.321
•	H.320 (???)

AAL type is included in the SETUP message.  In the case of 2 VCs, the AAL specified in the first SETUP message is the AAL of H.245.  The AAL type for AV communication may be negotiated as a result of the capability exchange.

References

[1]	AVC-841	Start up procedures for H.310 terminal, Japan, 16 October 1995.

- end -

Annex 8 to AVC-854R

Review of the H.310 draft text (AVC-821)

#	Section	Issues	Resolutions	
1	1	•	In the scope, there are 2 interoperability principles per RAST terminals.  Both are worded in the form: "Interworking between .... is mandatory".  Strictly, this is incorrect - it is the ABILITY to interwork which is mandatory.  (TD-31)	•	Accepted.	
2	1	•	In the 3rd line of the para following the above the word "should" should be removed.  (TD-31)	•	Accepted.	
3	1	•	2nd last line, "coding" should be "codings".  (TD-31)		
4	4	•	*2 {Editor’s Note: Several issues need to be addressed here. For example,
•	The terminology “ATM LAN” may not be the best choice here. It has been suggested to use “Private ATM Network” or “Private B-ISDN”.
•	What criteria will be used to distinguish between Public and Private ATM networks? Does the ITU-T have a formal definition for public and private networks?}	

•	"Customer Premises ATM Network".  Accordingly, RAST-L should read RAST-C.

•	Technically, the two are very similar.  Tariff, policing and other administrative aspects are different.	
5	4		•	Add "video transmission" and "surveillance" in the application list.	
6	4	•	Last two bullets.  Change "... user individual presentation control" to "individual presentation by the recipient".  (TD-31)		
7	Fig. 1	•	Q.2931/DSM-CC box in Figure 1 (AVC-847)	•	Change to Q.2931 only.  DSM-CC should separately be indicated as it appears in Fig. 2.	
8	Fig. 1	•	What are the 3 right angled triangles meant to represent?  (TD-31)		
9	Fig. 1	•	Is it acceptable to give the MCU Rec. number as H.23X?		
10	5.2	•	Definition of "native H.310 mode"?	•	Use of H.262 for video, ...?	
11	5.2	•	*6{Editor: I think we need to be clear about this point, i.e. which capability is mandatory or optional under which mode of operation.}	•	Clarification is supported.
•	H.310 is required to be equipped with H.321 mode, but e.g. when two H.310 RAST terminals are communicating, they are not required to operate in an H.321 mode?	
12	5.2.1.1	•	The paragraph just under "Unidirectional Terminal", only the last sentence is relevant. 	•	Delete the first two sentences.	
13	5.2.1.1	•	After the H.262 bullets, "Simple Profile at Mail Profile"	•	"Simple Profile at Main Profile"	
14	5.2.1.1	•	All mention of H.263 is new?  This should be discussed more.  (TD-31)		
15	5.2.1.2	•	{Editor: Should H.310 unidirectional terminals be given the option of supporting any of the G-series audio standards?}	•	Agreed.	
16	5.2.1.2	•	After "Bidirectional Terminals",  "In addition, bidirectional terminals can support one of the following ITU-T audio standard (optional):"	•	... any of the following ITU-T audio standard (optional)... ???  Capability indicates what audio coding algorithms are equipped.	
17	5.2.1.2	•	G.723 at either 5.3 or 6.4 kbit/s	•	5.3 or 6.3 kbit/s	
18	5.2.1.3	•	*10 {Editor: Is NLPID protocol applicable to or useful for H.310 terminals?}	•	No one knew NLPID.
•	Use of T.120 is encouraged.	
19	5.2.1.3	•	{Editor: It might be useful to show or reference the T.120 and other protocol stack here. Also, the possible data transfer rates to be supported by H.310 terminals need to be addressed.} 	•	Insert the following text: "T.120 is the default basis of data interoperability between an H.310 terminal and other H.310, H.320, H.321, H.323 or H.323 terminals.  Where any optional data application is implemented using one or more of the ITU-T Recommendations which can be negotiated via H.245., the equivalent T.120 applications shall be one of those provided.  The sole exception is Transparent User Data."  (TD-18 addendum)	
19	5.2.2	•	*11, *14	•	Put this general description of H.222.1 at the start of Section 5.2.2.1.
•	Add "ITU-T defined stream_id and descriptors" as part of the H.222.1 specific functions.	
20	5.2.2.1	•	*12, *14  It is important to note that the multiplexing of DSM-CC/H.245 and other control signals and data (e.g., T.120) with the audiovisual information may be accomplished at the ATM Service Access Point (SAP).  The DSM-CC/T.120 protocol stacks for H.310 unidirectional terminals is under study.	•	State VC multiplexing inside the main body.
•	Protocol stacks for H.245 and T.120 are fixed for the separate VC case.  T.120 protocol stack in the H.222 multiplex is still under discussion.  See Section 2.8.1 / AVC-854R.	
21	5.2.2.1	•	*13, *15  {Do we need to be more specific in here about timing jitter removal (and possibly other) H.222.1 functions?}	•	The above global introduction of H.222.1 is sufficient.	
22	5.2.2.1	•	Unidirectional Terminals and Bidrectional Terminals, ".... synchronization of H.262 video, MPEG audio, data, and other control (e.g., DSM-CC messages signals."	•	Make it a general description statement; ".... synchronization of audio, video, data and control signals."	
23	5.2.2.1.1	•	Unidirectional Terminals , 3rd last paragraph and Bidrectional Terminals, 2nd last paragraph	•	Use of the AAL5 corrupted data delivery is optional.  Reference to I.363.5 is sufficient for how to process the corrupted data.  The wording should be like "If error(s) is detected, the AAL5 data may be passed to the user according to I.363.5 option of the corrupted data delivery."
•	the lost or gain data event ==> the lost or gained data event	
24	5.2.2.1.1	•	*17 {Editor: Note that the current definition of unidirectional terminals implies that an AAL-1 based transmit-only terminal can not communicate with an AAL-5 based receive terminal, and vice versa. Some of this interworking issues can be resolved by allowing for the support of the other AAL as an option for a given type of terminal.}	•	Agreed.	
25	5.2.2.1.1	•	*18 {Editor: Should H.310 show how H.222.0 packets are mapped into the AAL-5 CPCS sublayer? It might be useful to show a diagram in the main body or in an appendix. In addition, we still need to address the following issues:
-	The packing of H.222.0 Transport Stream packets onto AAL-5 PDUs (as described in H.222.1) needs some modifications to reflect the current consensus inside and outside the ITU-T. In particular, the current description in H.222.1 represents a PCR-aware packing mechanism, whereas a PCR-unaware scheme might be the one that will be specified in the ATM Forum.
-	The mapping of H.222.0 Program Stream onto AAL-1 and AAL-5 PDUs is still an open issue in H.222.1
-	Most of the focus so far has been on resolving the AAL mapping issues for unidirectional terminals. I think we need to be specific on the mapping issues for H.310 bidirectional (RAST) terminals. For example, whatever mapping mechanism we select for the unidirectional/AAL-5 case should be mandatory for all RAST terminals supporting AAL-5. Also, we need to pay a special attention to the mapping of  H.222.0 TS packets over AAL-1 for RAST terminals since the support of TS/AAL-1 is mandatory for (i) RAST-P terminals and (ii) the combination of RAST-L/ATM-LAN Gateway.	•	H.222.1 has such a diagram (Fig. 2/H.222.1 to be revised), we need not repeat it in H.310.

-	Agreed.  See Section 2.5 3)/AVC-854R.

-	Mapping for PS/TS onto AAL1 is specified in Section 10.1/H.222.1.  PS to AAL5-SDU is under study.

-	Agreed except for the last sentence.  See the above comment for the mapping for PS/TS onto AAL1.
	
26	5.2.2.1.1	•	*19, *20 {Editor: Do we need to specify the usage of the CPCS-UU field in AAL-5? Can we use it for anything useful in H.310 terminals.}	•	The meeting was not competent to answer this question.	
27	5.2.2.1.2	•	"The mapping of data (e.g., T.120) over ATM in H.310 terminals is accomplished  through a protocol stack the complete definition of which is still under study."	•	T.120 protocol stack is now clear.  See Section 2.8.1/AVC-854R and Annex 5 to AVC-854R.	
28	5.2.2.1.3	•	"The mapping of H.245 messages over ATM is accomplished through a protocol stack the complete definition of which is still under study."	•	H.245 protocol stack is now clear.  See Section 2.8.1/AVC-854R and Annex 5 to AVC-854R.	
29	5.2.2.2.5	•	*24 {Editor: Do we need to specify the AAL-5 PDU size(s) and other AAL rules for the H.245 messages?}	•	Follow the LBC practice; 2048 bytes maximum (check the LBC specifications).	
30	5.2.2.2	•	transfer rate specifications	•	See Section 2.8.3/AVC-854R; 6.abc Mbit/s and 9.xyz Mbit/s at AAL-SAP are mandatory and other bit rates (in form of multiples of 64 kbit/s) are optional.	
31	5.2.2.2.2	•	"(217-1)"	•	2**16-1 (or 1 - 65535)	
32	5.2.2.2.3	•	{Editor: Do we need to specify the transfer rates at the ATM layer SAP?}	•	Add a description and example(s) to translate the transfer rate at AAL-SAP and peak cell rate at UNI.  See AVC-723 (Source: Japan, January 1995)	
33	5.3	•	After listing H.310 and H.320/H.321 communications modes, "These communication modes are also characterized by using H.245 and/or DSM-CC for capability exchange and other user-to-user signaling functions."	•	H.245 control protocol is mandatory to all H.310 terminals and DSM-CC is optional.  See Section 2.8.5 3) / AVC-854R.	
34	5.4	•	ROT/SOT is only for VoD?  It is also for video transmission, surveillance, ...?  (S. Okubo)	•	Agreed that VoD is one of the services provided by ROT/SOT.  See Section 2.8.5 3) / AVC-854R.	
35	Table 1	•	Optional Audio	•	MPEG2 L1, L2, L3 are the same as those of MPEG1.  Low sampling frequency, multi-channels, multilingual is particular to MPEG2.  We need alignment of the description with that of H.245 audio capabilities.	
36	Table 1	•	*28{Editor: It is not clear if ROT and SOT terminal types would need the functions provided by a standard data protocol such as T.120. Should we consider other data types that might be suitable for these types of terminals?}	•	Far End Camera Control may be useful for video transmission, surveillance services.  (subject to discussion, S. Okubo)	
37	Table 2	•	mandatory audio modes for RAST-P, RAST-L	•	High quality audio be mandated such as G.728, MPEG1 audio?  (subject to discussion, S. Okubo)	
38	Table 4	•	*36 The support of AAL-1 functions in the RAST-L terminal case might be provided by a gateway (at the premises side of the boarder) between the (public) B-ISDN network and (private) ATM LAN.	•	See the discussion in Section 2.8.5 2) / AVC-854R.	
39	Table 5	•	U-U signalling	•	H.245 is mandatory for all terminal types, while DSM-CC is optional.  See 2.8.5 3) / AVC-854R.	
40	Table 5	•	U-N signalling	•	Q,2931 is mandatory for all terminal types, while DSM-CC is optional. 	
41	5.5	•	2nd paragraph, principals	•	principles	
42	5.5	•	*38 {Editor: We need to address the following questions regarding the usage of DSM-CC in conjunction with Q.2931 and H.245:
-	Does DSM-CC user-to-user or user-to-network messages play a role in identifying the remote terminal type and/or exchanging capability messages?
-	If Q.2931 is the only mechanism available for identifying terminal types at the beginning of the call, does that mean that all H.310 terminals (i.e., including unidirectional terminals) need to support Q.2931 signaling.
-	It is clear that unidirectional H.310 terminals have to support DSM-CC functions. Do we need to identify what DSM-CC user-to-user, user-to-network, software-download, and other functions that should be mandatory and/or optional in H.310 terminals? Or, it is good enough to point to the DSM-CC specification only without further clarifying what is the minimum set of functions that must be supported?
-	It is clear that the main reason for advocating the support of DSM-CC functions by bidirectional H.310 terminals is to enable these terminals to provide broadcast and entertainment applications (e.g., a RAST terminal can be used as a VOD set-top-box). Beyond this point, is there any other reason why a bidirectional H.310 terminals needs to support DSM-CC functions? If the answer to the last question is that there is no other reason for bidirectional H.310 terminals to support DSM-CC, then I think we should have the support of DSM-CC by bidirectional H.310 terminals optional.
	If we decide that the support of DSM-CC by bidirectional H.310 terminals is optional (or mandatory for that matter), do we need to be more specific about what DSM-CC functions that should be considered?}  	

-	To a certain extent.  See AVC-838 and Section 2.7.3/AVC-854R.

-	Yes, except for PVC cases.

-	No discussion at the Yokosuka meeting.

-	Agreed.

	No discussion at the Yokosuka meeting.	
43	5.5	•	Item 5, "...in-band signaling during the call will be based on either H.245 or DSM-CC messages ..."	•	DSM-CC may be invoked after the H.245 capability exchange.  DSM-CC may be used in case of new H.3?? terminals.  See Section 2.8.5 3) / AVC-854R	
44	5.5.1	•	Phase A1, "Broadband-High Level Information (B-HLI) "	•	Broadband-High Layer Information	
45	5.5.1	•	*39 {Editor: it seems that there might be a big advantage in identifying an H.310 terminal type and its AAL capabilities. The Editor proposes that the group consider allocating the following codes for identifying H.310 terminal types:
-	H.310 SOT/AAL-1
-	H.310 SOT/AAL-5
-	H.310 SOT/AAL-1 & AAL-5
-	H.310 ROT/AAL-1
-	H.310 ROT/AAL-5
-	H.310 ROT/AAL-1 & AAL-5
-	RAST-P
-	RAST-P/AAL-5
-	RAST-L/AAL-1
-	RAST-L/AAL-5
-	RAST-L/AAL-1 & AAL-5
}	•	AAL should have been decided before the call establishment in case of the "1 VC  solution", while in case of the "2 VC solution" the choice of AAL is carried out through the H.245 capability exchange .  Hence, AAL indication  combined with ROT/SOT/RAST may not be necessary (though subject to verification).  See Annex ?? to AVC-854R.	
46	5.5.1	•	*40 {Editor: These procedures need the following  clarifications:
-	First, can we rely 100% on the delivery of B-HLI information elements to terminals?. If the answer is yes, then this approach might work. If the answer is no, then what is the alternative for (a) distinguishing between H.320/H321 and H310 terminals, and (b) identifying H.310 terminal types? When a RAST H.310 terminal can’t verify that the remote terminal is another H.310, it seems that the safe thing to do is to use the initial VC to transmit H.221 framed signal with G.711 and H.242 messages in BAS just as done in H.320/H.321 terminals.
-	Second, if we assume that the above scenario occurs (i.e., the two terminals can not identify themselves to each other and an H.320/H.321 mode of communication is established over the initial VC) while the two terminals are actually H.310 RAST terminals, is it possible to use some kind of an escape mechanism (e.g., a new H.245 escape code in H.242 which is only recognizable by H.310 terminals) to start an H.245 session between the two H.310 terminals. This may require allocating a new BAS code for an H.245 capability which would be ignored by H.320/H.321 terminals but recognized by H.310 terminals.
-	Third, there is still the AAL type issue. In other words, when an H.310 RAST terminal selects AAL-5 in the Q.2931 SETUP message with the intention of using the VC for transmitting H.245 messages (over AAL-5), then what would be the solution if that terminal finds-out (or infer by not receiving the desired B-HLI information element) that the remote terminal is an H.320/H.321 terminal? In fact, if the remote terminal is an H.320/H.321 terminal type, most likely the call will be rejected (either by a N-ISDN/B-ISDN I.580 Interworking Unit or by an H.321 terminal) if the calling terminal requests an AAL-5 based VC. 
-	Forth, if the call is rejected as in the last example, can this rejection be used as an indication that the remote terminal is an H.320/H.321 one, and then the calling H.310 terminal can use that to retry the Q.2931 call set-up procedure with selecting AAL-1 with the intention of transmitting H.221 framed signal over the initial VC.}	

-	We are relying on the B-HLI information for H.310 terminal type compatibility.  We will ask SG11 the universal availability of the information element.  

	When a call from H.310 RAST fails, the remote terminal may be a fax or other clearly incompatible machine.  To assume it is H.320 may be successful.

-	No discussion in Yokosuka.

-	No discussion in Yokosuka.

-	No discussion in Yokosuka.
	
47	5.5.1	•	*41 {Editor: Do we need to be more specific in here? Do we need to outline some rules on how to identify the highest mode of communications?}		
48	5.5.1	•	*42 {Editor: Do we need, at this stage of the call, to identify which terminal is the H.245 Master and which one is the Slave? If we do, can we always assume that the calling and called terminals are the H.245 Master and Slave, respectively, for the default H.245 channel over the initial VC? Or, do we need to use the H.245 Master/Slave determination procedure to identify who is the master and who is the slave? And, if we decide that a particular terminal is the Master, does this terminal stays the Master of all logical channels established over a given VC and during the remaining of the call (over that VC)? Also, should the Master (or calling) terminal be responsible for identifying the communication mode(s) for the audiovisual channel (e.g., video and audio modes, bitrates, etc.)?} 		
49	5.5.1	•	*43 {Editor: After both terminals exchange capabilities, and after determining the appropriate parameters for the additional VC and the desired audiovisual logical channels and their modes of communication (for the other VC), can the terminals drop the first (initial) VC and establish a new one with the desired Q.2931 parameters and a predetermined set of audiovisual logical channels? It seems that this may work if (a) all of the predetermined logical channels use the same AAL type, (b) all of the logical channels get multiplexed prior to the AAL SAP, and (c) one of the (predetermined) logical channels should be for communicating H.245 messages over the new (and only) VC. Or, the establishment of an additional VC is always the only way to get around this issue? For RAST terminals we know that they have to support at least two VCs for audiovisual communication (for interworking with H.320/H.321 terminals). Therefore, this may not be a major issue for RAST terminals. what’s about unidirectional terminals?}		
50	5.5.1	•	*45 {Editor: Can the H.230-like C&I messages defined in H.245 be used here? One issue I see with the way that these messages are currently defined in H.245 is that they can not be synchronized with the video signal? Is this assessment correct? It seems that it would be very desirable to have messages that are already defined in H.245 to be used for this purpose. This may require adding additional video-synchronization fields to the current H.230-like C&I messages in H.245.}	•	See AVC-835 and Section 2.8.2 / AVC-854R.	

Note 1 - *nn indicates the footnote number in AVC-821.
Note 2 - Blank indicates that there was no discussion at the Yokosuka meeting due to time constraint.
Note 3 - Reference to "AVC-854R" is the main body of AVC-854R.

Annex 9 to AVC-854R

Report of the H.245 discussion in the LBC meeting in Darmstadt

Title:	Agreed changes to H.245.
Destination:	SG15 Experts' Group for Video Coding and Systems in ATM and Other 
	Network Environments.
Origin:	SG15 LBC Rapporteur's Experts Group
Approval:	SG15 LBC Rapporteur's Experts Group
Submitted for:	Information
Contact:	Bill Welsh, BT Labs, Ipswich IP5 7RE, UK.
	Tel: +44 1473 643810
	Fax: +44 1473 643791
	e-mail: welsh_w_j@bt-web.bt.co.uk
 	  
Attachment:	LBC-95-261_ADDENDUM

We wish to draw your attention to the attachment which is the addendum to the report of the H.245 ad-hoc committee (submitted to the AVC group as AVC-829). This lists the agreements made concerning each of the numbered items on the ad-hoc report as well as agreements made regarding other documents submitted to our meeting.

In particular, we wish to draw your attention to the comments made regarding the document submitted to our meeting as LBC-95-307 (author:- Dale Skran).

- END -

ITU Telecommunications Standardisation Sector	LBC-95-261_ADDENDUM
Study Group 15, Working Party 15/1
Experts' Group on Very Low Bitrate Video Telephony	Darmstadt, 17-20 October, 1995

Title:		Report of the H.245 Ad Hoc Committee
Source*:	Chairperson H.245 Ad Hoc Committee

A meeting of the H.245 ad-hoc committee was held on the 16/10/95. During the LBC meeting, the H.245 group met jointly with systems and multiplex.

A number of documents were submitted pertaining to H.245 and these were considered in turn. They are listed below:

261	-	Report of H.245 ad hoc (version which appeared on the LBC reflector)	
248rev	-	Master-slave determination procedures, S.Dunstan.	
265	-	B-LCSE modification and illustrations, S.Dunstan.	
266	-	Informative appendix on H.245 procedures, S.Dunstan.	
292	-	Proposed changes to H.245, H.Singh.	
296	-	Bi-directional logical channel signalling, M.Nilsson.	
305	-	Proposal for adding a simple ACK/NACK of H.222 information to H.245, B.Haskell.	
307	- 	Mapping H.221/H.230 commands to H.245 commands and related issues, D.Skran.	
308	-	Need for H.245 to support addressing and association of media streams carried over separate network connections, Q10/8.	
313	-	Comments on bi-directional signalling, Japan.	
314	-	Request for H.245 syntax from SAVD, C.Hansen.	
331	-	Actions to be taken when certain exception conditions occur, H.Singh.	

It was decided to work through the ad-hoc report Doc 261 and introduce the contributions which related to particular points as they arose.

Each of the numbers below relates to an item within Doc 261.

1) After discussion, it was decided that the text was satisfactory and it was agreed to leave it as is.

2) Appendix I (informative appendix on ASN.1) is correct. Tutorial in X.691 has errors, it has material (re. constrained integer) which is different from the normative text in X.691. It was agreed to ask  the editor of ASN.1 if he could check section 6 (the syntax) and Appendix I of H.245.

3) This was resolved after considering point 10. It was decided to adopt the second suggested fix and change the syntax accordingly.

4) Agreed to leave text as is.

5) This was handled later in the discussion on Doc 331.

6) This was discussed and resolved later when item 18 was considered.

7) Agreed to insert this.

8) Agreed to put comment in syntax that this is not optional in first TerminalCapabilitySet sent and modify corresponding part of  Section 7.

9) The alternative syntax in Annex I of Doc 261 was considered. No real problem was discovered in the current syntax after close inspection and it was decided to leave it as is. However, it was decided to add text for clarification in order to distinguish the case where the capability structure is used in a capability exchange and where it is used in an open logical channel PDU.

10) After consideration of Doc 261 Annex 2 it was decided to adopt the syntax therein. It was thought that the decision to adopt the second proposed fix in item 3) would necessitate increasing the allowable number of entries in a capabilityTable. Therefore, it was agreed to change the SET SIZE range  of  CapabilityTableEntryNumbers to (1..65535), and put in a tableEntryCapacityExceeded cause in terminalCapabilitySetReject for receivers which could not store a long list of capabilities. This would be used to return the highest table entry number which the receiver could store or else that it could not store any of the capabilities sent to it. Proposed syntax is given below:

TerminalCapabilitySetReject	::=SEQUENCE
{
	sequenceNumber	SequenceNumber,
	cause		CHOICE
	{
		unspecified	NULL,
		undefinedTableEntryUsed	NULL,
		descriptorCapacityExceeded	NULL,
		tableEntryCapacityExceeded	CHOICE
		{
			highestEntryNumberProcessed	capabilityTableEntryNumber,
			noneProcessed	NULL
		}
		...
	},
	...
}

11)  It was agreed to change the protocol slightly as described in solution 2. It was also agreed to number the figures in Section 8 which were spread over several pages as parts (i) (ii) (iii) etc.

12) It was expected that the H.323 people would produce a contribution on this at the AVC meeting. It was agreed to defer this for them to handle.

13) It was agreed to leave text as is and leave it to gateway implementors to decide how to handle interworking problems between two terminals using different master-slave determination procedures.

14) It was agreed to add a note for clarification to the effect that the leading bit is the most significant bit as is specified in X.691.

15) It was agreed to accept this.

16) This was resolved later in the discussion on bi-directional logical channel signalling.

17) This was discussed later when Doc 307 was considered (see below).

18) Document 265 was disregarded on S.Dunstan's instruction and the proposal in Doc 296 was considered . It was decided to adopt this proposal with some modifications. There was discussion about when a transmitter can start to transmit.  It was suggested that we keep Mike Nilsson's proposal with some modifications but that we go back to the former procedure in that the responder has to send open logical channel with associated channel number after sending the OpenLogicalChannelAck (NB now a master can make use of associated channel number since the situation is symmetrical).

Now we need to have reverse logical channels parameters and associated logical channel number as a CHOICE OPTIONAL in an OpenLogicalChannelPDU. This suggestion was accepted.

In OpenLogicalChannelReject, it was agreed to add a new cause ie that is there is potential conflict. Slave can only reject on grounds of capability. Logical channel close needs to be clarified as does the text in Annex 3 Note.2. It was agreed to add some plain language examples.

It was agreed to insert some text as a suggestion to an implementor (ie a should not a shall) to the effect that if a terminal has not sent its transmit capabilities and it receives a bi-directional open channel request, if the terminal rejects the request it may send a bi-directional open channel request with alternative bi-directional channel parameters.

 In CloseLogicalChannelAck, it was agreed to put reverseLogicalChannelNumber OPTIONAL.

With this modification a transmitter can start to transmit as soon as it received  the OpenLogicalChannelAck for its open logical channel request (case of uni-directional channels) and as soon as it receives the OpenLogicalChannelAck for the logical channel opened in the reverse direction (case of bi-directional channel).

If a request to open either half of the bi-directional channel is rejected then the other channel is closed.

19) Document 266 - it was thought that the timing diagrams were useful but the other figures did not really make interpretation of the state transition diagrams and SDLs in Section 8 any clearer. We encourage the AVC group to clarify this informative appendix.

20) Item b. of Doc 292 proposes that the problem described in item a. of Doc 248rev does not really exist. It proposes to keep the  existing master-slave determination procedure and add the sentence from Doc-292 item b. to section 8.2.1 of H.245. Also to transcribe the guideline in item b. and add this into Section 8.2.1 also. To add changes to tables 17 and 19 and a change to SDL in figure 4. It was considered that this proposal was simpler than the one proposed in Stuart Dunstan's Doc 248rev or the proposal in Annex 4 of Doc 261 and it was agreed to adopt it.

21) We defer this  for the AVC group to address.

Discussion of documents not fully considered in items above

Doc. 305 - this proposes codepoints for H.222 information. The author intends to submit a revised document to the ATM meeting next week. There was some feeling that it would be better to put the codepoint in as a multiplex capability under H.222 but that we did not feel too strongly about this and would leave it to the AVC group to decide.

Doc. 307 - We felt that there are too many questions in this document to enable us to add anything to H.245 but that this could be a good start for a new  recommendation on an interworking adaptor or for one covering multipoint and interworking for H.320/H.245 systems in general. We wish to express our interest to the AVC group in the progression  of this work. It was thought that the  document could become more than just a part of H.323 (see line at bottom of page 1), but rather become a more general document.

Doc 308 - We felt it more appropriate that the AVC group should consider this liaison.

Doc 313 - These concerns were also addressed in Doc 331 below.

Doc. 314 - SAVD liaison regarding additions to H.245 for V.dsvd.  There was some feeling about presence of DSVDcontrol in DataApplicationCapability not being the best place for it. However, it was eventually agreed that this would interfere least with the structure of H.245. Chris Hansen has provided syntax and semantics for the editor to insert. 

Doc 331 - This document proposes additions to H.324 concerning actions to be taken when certain exception conditions occur. It is considered that only Capability Exchange and Master Slave Determination procedures of H.245 need to have exception handling procedures.  Exception handling for all the remaining H.245 procedures may be addressed as design issues by individual implementations. Although it was first proposed that this exception handling should be put into H.324, it seemed that any terminal using H.245 would wish to use this, and it was decided to put in into H.245.

 In item a. it is proposed that if timer T101 expires while awaiting a response to the initial terminalCapabilitySetRequestPDU, the terminalCapabilitySet message shall be transmitted up to N201 times. In item b. it is proposed that if time T106 expires while waiting for a response to a masterSlaveDeterminationRequest PDU, the masterSlaveDetermination message shall be transmitted up to N206 times. If a masterSlaveDeterminationRejectResponsePDU is received with cause identical numbers, the masterSlaveDetermination message shall be transmitted up to N2061 times.

The text in item a. will be used to amend the text and SDLs for the Capability Exchange Signalling Entity and the text in item b. will be used to amend the text and SDLs for the Master Slave Determination Signalling Entity.

Other items

Since the G.723 document submitted to Geneva for approval will not contain silence suppression, it was agreed to add codepoints to the g723 codepoint in AudioCapability to allow future terminals to indicate if they have this capability or not.

-END-

Annex 10 to AVC-854R

H.245 changes and additions for H.323

I	Changes Required in the Current H.245 prior to Decision

Changes in the ASN.1 are indicated with non-bold italicized text.

H261VideoCapability	::=SEQUENCE
{
	qcifMPI	INTEGER (1..4) OPTIONAL,	-- units 1/29.97 Hz
	cifMPI	INTEGER (1..4) OPTIONAL,	-- units 1/29.97 Hz
	temporalSpatialTradeOffCapability	BOOLEAN,
	maxBitRate		INTEGER (1..30),		-- units of 64Kbps
	...
}

Add the same field to H263VideoCapability as well.  This is needed for interworking since transfer rates are no longer available to imply codec capabilities.

MiscellaneousCommand	::=SEQUENCE
{
	logicalChannelNumber	LogicalChannelNumber,
	type		CHOICE
	{
		equaliseDelay	NULL,	-- same as  H.230 ACE
		zeroDelay	NULL,	-- same as  H.230 ACZ
		
		multipointModeSymmeterize	NULL,	-- same as MCC plus modes as well
		videoFreezePicture	NULL,
		videoFastUpdatePicture	NULL,

		videoFastUpdateGOB	SEQUENCE
		{
			firstGOB	INTEGER (0..17),
			numberOfGOBs	INTEGER (1..18)
		},

		videoTemporalSpatialTradeOff	INTEGER (0..31),	-- commands a trade-off value

		videoSendSyncEveryGOB	NULL,
		videoSendSyncEveryGOBCancel	NULL,

		...
	},

	...
}

MiscellaneousIndication	::=SEQUENCE
{
	logicalChannelNumber	LogicalChannelNumber,
	type		CHOICE
	{
		logicalChannelActive	NULL,	-- same as H.230 AIA and VIA
		logicalChannelInactive	NULL,	-- same as H.230 AIM and VIS

		multipointConference	NULL,	-- Indicates connection to H.243 
					   MCU(reception of MCC),
					   but with FlowControl used 
					   to control rates.
		cancelMultipointConference	NULL,	--
		multipointZeroComm	NULL,	-- same as H.230 MIZ
		cancelMultipointZeroComm	NULL,	-- same as H.230 cancel MIZ

		multipointSecondaryStatus	NULL,	-- same as H.230 MIS
		cancelMultipointSecondaryStatus	NULL,	-- same as H.230 cancel MIS

		videoIndicateReadyToActivate	NULL,	-- same as H.230 VIR

For both MiscellaneousIndications and MiscellaneousCommands substitute  "same as H.230" for "like H.230" which implies it is not the same.

In section 7.9.2 of H.245,  change the text as follows:

multipointConference, cancelMultipointConference, multipointZeroComm, cancelMultipointZeroComm, multipointSecondaryStatus, and cancelMultipointSecondaryStatus shall have the same meaning as MIC, cancelMIC, MIZ, cancelMIZ, MIS and cancelMIS respectively, as defined in H.230.

multipointConference indicates that the terminal is joined to an H.243 multipoint conference, and the terminal is expected to obey bit rate symmeterization.  However, bit rate symmeterization will be enforced via FlowControl messages.  A terminal in  receipt of multipointConference shall always become the slave in the master/slave determination process; i.e. it shall always follow the MCU. Note that multipointConference has exactly the same meaning has MCC in H.230  Note that multipointConference, like MCC, does not require mode symmetry.

In section 7.8.5, add text as follows:

multipointModeSymmeterize indicates that a terminal in receipt should follow whatever mode changes are issued by the sending terminal or MCU.  If the terminal is in receipt of multipointConference, this symmeterization of mode is mandatory.  An example of a mode change is an audio coding change from G.711 to G.728.

II	Proposed Additions to H.245 For the First Revision1.

At the Oct. 24-27 Yokosuka ATM and other Networks meeting consideration was given to AVC 852, AVC 825, and AVC 842,  and the material below represents a consenus view of the changes needed in H.245 for the support of H.323.  Some of these changes may also be useful to H.324 and H.310 terminals. The primary goal of the H.323 experts is to promode full interoperability with existing and future H.320 terminals.

This proposal contains only proposed additions to H.245, supporting arguments for these additions can be found in AVC-825 and AVC-843. 

New text is italicized non-bold.  It is recognized that in some cases needed H.245 text is missing; the ASN.1 is believed sufficient to convey the nature of the additions needed and the text will be provided later.

1	PDUs Related to Interworking with H.320

Generally, all H.245 PDUs are assumed to address the H.323 gateway acting as an H.323 terminal.  The only exceptions are commands that specifically request the terminal to perform an action on the H.320 side.  Areas where this is needed include loopbacks, encyption, and ns-cap/ns-com.

The ability to address the gateways for initiating loopbacks on the WAN side is needed. Thus three new loopback commands are needed that are intended to initiate an end-to-end loopback on the WAN side.  The loopbacks currently in H.245 would be interpreted as being terminated by the gateway between the H.323 terminal and the WAN, while the new loopbacks would indicate a request for the gateway to send H.230 loopbacks on the WAN side toward an H.320 terminal.  It has been decided that it is not really possible to translate H.320 loopbacks into H.323 loopbacks on the LAN side, so there is no need for a set of commands in the WAN to LAN direction.  The following ASN.1 is needed:

MaintenanceLoopRequest	::=SEQUENCE
{
	sequenceNumber	SequenceNumber,
	type		CHOICE
	{
		systemLoop	NULL,
		mediaLoop	LogicalChannelNumber,
		logicalChannelLoop	LogicalChannelNumber,
		auH230Loop	NULL,
		vidH230Loop	NULL,
		digH230Loop	NULL,
		offH320Loop	NULL,
		...
	},
	...
}

Add to Section 7.7.1 Maintenance Loop Request:

auH230Loop requests an interworking device or gateway to send the H.230 command Au-loop to the attached H.320 terminal.
vidH230Loop requests an interworking device or gateway to send the H.230 command Vid-loop to the attached H.320 terminal.
digH230Loop requests an interworking device or gateway to send the H.230 command Dig-loop to the attached H.320 terminal.

PDUs for Ns-cap/Ns-coms and CIC-cap

Capability		::=CHOICE
{
	nonStandard	NonStandardParameter,
	nonStandardH320	NonStandardParameter,
	miscellaneous Capability	MiscellaneousCapability,

	receiveVideoCapability	VideoCapability,
	transmitVideoCapability	VideoCapability,
	receiveAndTransmitVideoCapability	VideoCapability,

	receiveAudioCapability	AudioCapability,
	transmitAudioCapability	AudioCapability,
	receiveAndTransmitAudioCapability	AudioCapability,

	receiveDataApplicationCapability	DataApplicationCapability,
	transmitDataApplicationCapability	DataApplicationCapability,
	receiveAndTransmitDataApplicationCapability	DataApplicationCapability,

	h233EncryptionTransmitCapability	BOOLEAN,
	h233EncryptionReceiveCapability	SEQUENCE
	{
		h233IVResponseTime	INTEGER (0..255),	-- units 							    milliseconds	
		...
	},

	...
}

NonStandardPDU	::=SEQUENCE
{
	nonStandardData	NonStandardParameter,
	nonStandardH320Data	NonStandardParameter,
	...
}

MiscellaneousCapability	::=SEQUENCE
{
	chairControlCapability	BOOLEAN,
	...
}

When nonStandardH320Data is sent, the gateway sends the information on to the H.320 side rather than acting on the data itself.  When nonStandardH320 capability is sent, the H.323 gateway  passes the capability  on to the H.320 terminal as an ns-cap.

PDUs to turn on the diagnostic identifier.

DiagnosticRequest	::=SEQUENCE
{
	diagnosticIdentifier	OCTET STRING,
	...
}

DiagnosticResponse	::=SEQUENCE
{
	...
}

VideoCapability	::=CHOICE
{
	nonStandard	NonStandardParameter ,
	h261VideoCapability	H261VideoCapability,
	h262VideoCapability	H262VideoCapability,
	h263VideoCapability	H263VideoCapability,
	mpeg1VideoCapability	mpeg1VideoCapability,
	h261AnnexDCapability	BOOLEAN,
	...
}

mpeg1VideoCapability	::=CHOICE
{
	...
}

Add to Section 7.2.2.5

mpeg1VideoCapability: indicates ISO/IEC 11172-2 [Ref] capabilities.

DataProtocolCapability	::=SEQUENCE
{
	nonStandard	NonStandardParameter,
	v14buffered	BOOLEAN,
	v42lapm	BOOLEAN,	-- may negotiate to V.42bis
	hdlcFrameTunneling	BOOLEAN,
	transparent	BOOLEAN,
	v120	BOOLEAN,	-- as in H.230
	...
}

MiscellaneousCommand	::=SEQUENCE
{
	logicalChannelNumber	LogicalChannelNumber,  (how do we indicate all or none??)
	type		CHOICE
	{
		equaliseDelay	NULL,	-- like H.230 ACE
		zeroDelay	NULL,	-- like H.230 ACZ
		
		multipointModeSymmeterize	NULL,	-- same as MCC plus modes as well
		terminalIdRequest	NULL,	-- translates into TCI or TCS-2
		terminalListRequest	NULL,	-- same as H.230 TCU

		broadcastMe	NULL	-- same as H.230 MCV
		cancelBroadcastMe	NULL,	-- same as Cancel-MCV

		makeTerminalBroadcaster	SEQUENCE	-- same as H.230 VCB
		{
			mcuNumber	INTEGER(0..192),
			terminalNumber	INTEGER(0..192)
		}
		cancelMakeTerminalBroadcaster	NULL,	--same as H.230 cancel-VCB

		sendThisSource	SEQUENCE	-- same as H.230 VCS
		{
			mcuNumber	INTEGER(0..192),
			terminalNumber	INTEGER(0..192)
		}
		cancelSendThisSource	NULL,	--same as H.230 cancel-VCS

		dropTerminal	SEQUENCE	-- same as H.230 CCD
		{
			mcuNumber	INTEGER(0..192),
			terminalNumber	INTEGER(0..192)
		}
		
			makeMeChair	NULL,		-- same has H.230 CCA
			cancelMakeMeChair	NULL,		-- same as H.230 CIS

			dropConference	NULL,		-- same as H.230 CCK

			enterH243Password	NULL,		-- same as H.230 TCS1
			enterH243TerminalId	NULL,		-- same as H.230 TCS2
			enterH.243ConferenceId	NULL,		-- same as H.230 TCS3

			requestTerminalId	NULL,		-- same as TCP
		{
			mcuNumber	INTEGER(0..192),
			terminalNumber	INTEGER(0..192)
		}

		videoFreezePicture	NULL,
		videoFastUpdatePicture	NULL,

		videoFastUpdateGOB	SEQUENCE
		{
			firstGOB	INTEGER (0..17),
			numberOfGOBs	INTEGER (1..18)
		},

		videoTemporalSpatialTradeOff	INTEGER (0..31),	-- commands a trade-off value

		videoSendSyncEveryGOB	NULL,
		videoSendSyncEveryGOBCancel	NULL,

		...
	},

	...
}

TerminalIdResponse	::=SEQUENCE
{
	terminalId	OCTET STRING,		-- as per H.230
	...
}

This could be used to respond to TCP, TCS1/2/3  - but is this the H.245 way?
Suggestions?? This would make it equivalent to TIP and IIS.

TerminalListResponse	::=SEQUENCE
{
	terminalNumbers	SEQUENCE,		-- as per H.230 TIL
	{
		mcuNumber	INTEGER(0..192),
		terminalNumber	INTEGER(0..192)
	}
	...
}

VideoCommandReject	::=NULL			-- same as H.230 VCR

MakeMeChairResponse	::=NULL			-- same as H.230 CCR
{
	grantedChairToken	NULL,			-- same as H.230 CIT
	deniedChairToken	NULL,			-- same as H.230 CCR
}

MiscellaneousIndication	::=SEQUENCE
{
	logicalChannelNumber	LogicalChannelNumber,
	type		CHOICE
	{
		logicalChannelActive	NULL,	-- like H.230 AIA and VIA
		logicalChannelInactive	NULL,	-- like H.230 AIM and VIS

		multipointConference	NULL,	--								Indicates connection to H.243 MCU(reception of MCC),
			 	but with FlowControl used to control rates.
		cancelMultipointConference	NULL,	--

		multipointZeroComm	NULL,	-- like H.230 MIZ
		cancelMultipointZeroComm	NULL,	-- like H.230 cancel MIZ

		multipointSecondaryStatus	NULL,	-- like H.230 MIS
		cancelMultipointSecondaryStatus	NULL,	-- like H.230 cancel MIS

		videoIndicateReadyToActivate	NULL,	-- like H.230 VIR

		sbeNumber	INTEGER (0..9),	-- same as H.230 SBE Number
		
		terminalNumberAssign	SEQUENCE	-- same as H.230 TIA
		{
			mcuNumber	INTEGER(0..192),
			terminalNumber	INTEGER(0..192)
		}

		terminalJoinedConference	SEQUENCE	-- same as H.230 TIN
		{
			mcuNumber	INTEGER(0..191),
			terminalNumber	INTEGER(0..191)
		}

		terminalLeftConference	SEQUENCE	-- same as H.230 TID
		{
			mcuNumber	INTEGER(0..192),
			terminalNumber	INTEGER(0..192)
		}

		seenByAtLeastOneOther	NULL,	-- same as H.230 MIV
		cancelSeenByAtLeastOneOther	NULL,	-- same as H.230 cancel MIV

		seenByAll	NULL,	-- like H.230 MIV
		cancelSeenByAll	NULL,	-- like H.230 MIV

		terminalYouAreSeeing	SEQUENCE	-- same as H.230 TIN
		{
			mcuNumber	INTEGER(0..192),
			terminalNumber	INTEGER(0..192)
		}

		requestForFloor	NULL,	-- same as H.230 TIF

		videoTemporalSpatialTradeOff	INTEGER (0..31),	-- indicates current trade-off

		...
	},
	...
}

2	PDUs to distribute multicast information

Note: this section is based on the idea that the terminal may generate a multicast address for additional channels (e.g. a second video channel) and ask the MC to distribute it.  Another consistant approach is to have the terminal request the MC to allocate and distribute a multicast address; this centralizes multicast address allocation in the MC.  These ideas require further consideration.

Used by the H.323 MC to distribute multicast addresses.

CommunicationModeCommand                                       ::=CHOICE
{
          unicast	                                                      NULL,
          multicastTable                                                  SET SIZE (1..256) OF MulticastTableEntry
}

Used by the H.323 terminal to request the conference mode (multicast vs unicast)

CommunicationModeRequest                                           ::=NULL
{
}

CommunicationModeResponse                                       ::=CHOICE
{
          unicast	                                                    NULL,
          multicastTable                                                SET SIZE (1..256) OF MulticastTableEntry
}

Used by the H.323 MC to distribute multicast addresses.

MulticastTableEntry                                                ::=SEQUENCE
{
          DataType                                                       CHOICE
         {
                   videoData                                              NULL,
                   videoControl                                         NULL,
                   audioData                                             NULL,
                   audioControl                                         NULL,
                   data                                                       NULL
         }
         multicastAddress                                             OCTET STRING,
         portNumber                                                     INTEGER (0..65535)
        }

3	Extensions to fields in existing PDUs

Additions are shown in italics and bold.
3.1	Extend TerminalCapabilitySet Request PDU

TerminalCapabilitySet                                      ::=SEQUENCE
{
         sequenceNumber                                      SequenceNumber,
          protocolIdentifier                                    OBJECT IDENTIFIER,
          multiplexCapability                                 MultiplexCapability OPTIONAL,
          capabilityTable                                        SET SIZE (1..256) OF CapabilityTableEntry OPTIONAL,
          capabilityDescriptors                               SET SIZE (1..256) OF CapabilityDescriptor OPTIONAL,
         conferenceCapability                               ConferenceCapability OPTIONAL
}

ConferenceCapability		::=SEQUENCE
{
    mcCapability                                 Sequence
   {
        centralizedConferenceMC       BOOLEAN OPTIONAL,	        multicastConferenceMC          BOOLEAN OPTIONAL
   }
             -- terminals unicast a/v to MCU, MCU unicasts a/v to terminals
   centralizedConference                              BOOLEAN,                    -- this is the mandatory capability!
              -- all endpoints multicast a/v
   decentralAudioVideoConference             BOOLEAN OPTIONAL,
              -- terminals multicast video, unicast audio to MCU, MCU unicasts audio to terminals 
   decentralVideoCentralAudioConference BOOLEAN OPTIONAL,
              -- terminals unicast a/v to MCU, MCU multicasts a/v
   hybridConference                                      BOOLEAN OPTIONAL,
              -- terminals multicast video, unicast audio to MCU, MCU multicasts audio to terminals
   hybridVideoCenralAudioConference      BOOLEAN OPTIONAL
}
3.2	Extend AudioCapability Description

In the comments before Audio Capability, add the following comment:

-- For an H.22Z multiplex, the integers indicate the maximum number of audio frames per packet.

The size of a frame is defined in H.22Z.
3.3	Extend OpenLogicalChannel Request PDU for RTCP Channel

Note that the RTP headers may change before the receiver processes the  logical channel re-open; thus the RTP header is considered the controlling information concerning mode.  This issue and its implications require further discussion.

DataType                                                            ::=CHOICE
{
          nonStandard                                            NonStandardParameter,
          nullData                                                  NULL,
          videoData                                                videoCapability,
          audioData                                                audioCapability,
          data                                                          DataApplicationCapability,
          encryptionData                                         encryptionMode,
          videoControl                                           MediaControlCapability,
          audioControl                                           MediaControlCapability
}

MediaControlCapability	::=SEQUENCE
  {
    AssociatedLogicalChannel	INTEGER(1..65535),
    ...
  }

LogicalChannelMultiplexParameters                 ::=CHOICE
{
         h222LogicalChannelParameters                222LogicalChannelParameters,
         h223LogicalChannelParameters                223LogicalChannelParameters,
         h22zLogicalChannelParameters              h22zLogicalChannelParameters
}

h22zLogicalChannelParameters                           ::=CHOICE
{
         unicastChannel			UnicastParameters,
        multicastChannel			MulticastParameters,
}

UnicastParameters                           ::=SEQUENCE
{
        GuaranteedDelivery                                   BOOLEAN         -- select reliable transport
}

MulticastParameters                           ::=SEQUENCE
{
             
        multicastAddress                                        OCTET STRING,
        portNumber                                               INTEGER (0..65535),
}

3.4	Extend OpenLogicalChannelACK Response PDU

OpenLogicalChannelACK			::=SEQUENCE
{
         logicalChannelNumber                             LogicalChannelNumber,
         transportChannel                                       INTEGER(0..65535), OPTIONAL -- (e.g.  UDP port)
          ...
}
3.5	Add Cause Codes to OpenLogicalChannelReject Response PDU

OpenLogicalChannelReject                                 ::=SEQUENCE
{
         logicalChannelNumber                               logicalChannelNumber
         cause
         {
                    	unspecified                                          	NULL,
                    	dataTypeNotSupported                       	NULL,
                    	dataTypeNotAvailable                        	NULL,
                    	unknownDataType                              	NULL,
                   	 multicastAddressInvalid                     	NULL,		-used by MC
	 multicastportNumberNotAvailable   	INTEGER(0..65535),	-used by MC
		The last two may not be in the spirit of H.242/H.245 since they are returned after
		the sender violates the "never send what is not in the receiver cap set" rule.
	multicastNotAllowed	                    	 NULL,		-used by MC
	unicastNotAllowed		 NULL
         }
}

4	General Comments
1)	In Section 1 Scope, change “H.222.0 and H.223” to “H.222.0, H.223, and
	 H.22Z”.
2)	In Section 2 References, Add references to H.22Z and H.323.

END