ITU Telecommunication Standardization Sector	Document AVC-906R
Study Group 15	27 February 1996
Experts Group for Video Coding and Systems	Version 3
in ATM and Other Network Environments

Source:	RAPPORTEUR (Sakae OKUBO)	
Title:	REPORT OF THE TWENTY-FIRST EXPERTS GROUP MEETING IN IPSWICH (16-19 January 1996)	
Purpose:	Report	
Status	Confirmed by the participants	

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

1. General
2. H.310 discussion
3. H.225.0 discussion
4. H.323 discussion
5. H.245 discussion
6. Future work
7. Interactions with other groups
8. Future meeting

1.	General

1.1	Introduction

The twenty-first meeting of the Experts Group was held under chairmanship of Rapporteur (Mr. Sakae Okubo) during 16-19 January 1996 in The Suffolk Grange Hotel, Ipswich, UK, at the kind invitation of BT Labs.  At the start of the meeting, Mr. Geoff Morrison, Manager Video Processing, 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.225.0, H.310 and H.323 were chaired by respective Editors; Mr. Dale Skran, Mr. Sakae Okubo (on behalf of Mr. Hayder Radha) and Mr. Gary Thom.

At the end of the meeting, Rapporteur thanked the hosting organization for providing us excellent facilities and services to support the meeting.  Mr. Geoff Morrison celebrated the successful completion of the first phase work of the Experts Group since its first meeting in November 1990.

1.2	Documentation (TD-2)

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

1.3	Review of the activities since the previous meeting

1.3.1 Experts Group Yokosuka meeting in October 1995 (AVC-854R)

The following actions were taken after the meeting:

•	Submission of TDs for decision or determination of Draft Recommendations 
•	Correspondence to SA&A/ATMF regarding H.310 ROT codepoint
•	Correspondence to Q.10/8 regarding T.120/H.245 protocol stacks and correlation ID
•	Correspondence to Q.15/11 regarding connection delay and B-HLI

1.3.2 MPEG meeting in November 1995 (AVC-858)

The following items were introduced as of our particular interest:

•	Corrigenda to H.262|ISO/IEC 13818-2
•	RTI
•	DSM-CC

1.3.3 SG15 meeting in November 1995 (AVC-860,871)

The following items were introduced as of our particular interest:

•	Draft Recommendations decided
•	Draft Recommendations determined
•	New Questions

1.3.4 WP2/13 meeting in November 1995

Rapporteur reported that the corrupted data delivery option in I.363.5 had been agreed upon for the decision of SG13 in April 1996.

1.3.5 ATMF meeting in December 1995 (AVC-903)

Mr. Jeff Lynch drew attention of the meeting to the completion of VoD Specification and the liaison statement regarding the Q.2931 B-HLI codepoint.

1.3.6 Current status of H-series Recommendations (AVC-880)

Rapporteur summarized the current status of H-series Recommendations for audiovisual communication systems in various network environments.

1.4	Identification of open issues (AVC-867; TD-3, 5)

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

2.	H.310 discussion

2.1	Start up procedures (AVC-872)

2.1.1 Choice of "2 VC solution"

The meeting agreed to the proposal in AVC-872 to adopt the "2 VC solution" for H.310.  Interaction between the call arrival and alerting the human user needs further study with respect to audio communication start up and charging aspects.  If we do not alert at the initial call, the initial call is charged even if there is eventually no response to the second call.

2.1.2 Hook for the future inclusion of "1 VC solution"

There was some support for the approach of dropping the initial VC as in AVC-872, but the meeting concluded that H.310 text should say  "single VC solution is under study" without mentioning a particular method.

2.1.3 Signalling parameters for the initial VC

The meeting agreed to the inclusion of Annex 3 to AVC-872 as an Annex to H.310, putting items without sufficient information to "under study".

2.1.4 Liaison to SG11 regarding call setup delay

The liaison response to SG11 which was produced at the Yokosuka meeting (Annex 4 to AVC-854R) was amended as in Annex 3 to this report by incorporating the conclusion of adopting the "2 VC solution" in H.310

2.2	H.310 terminal type 

2.2.1 Definition of H.310 terminal type (AVC-873, 880, 883, 899, 905; TD-4)

The following items were discussed:

•	Relationship between H.310 ROT/SOT and other standard terminals (3.3/AVC-873, 899)
•	Relationship between H.310, J.82 and H.222.1 (AVC-883)
•	Scope of H.310, provision for separate Recommendations covering other type of terminals 
•	Configuration of RAST-C H.320/H.321 communication mode (Figure in AVC-880)
•	Interworking requirements for different types in H.310 (TD-4)
•	Definition of H.310 terminal types: distinction between public network and customer premises network is necessary (TD-4)

During the discussion, the following comments and conclusions were obtained:

•	Description of corrupted data delivery as proposed in AVC-883 is not appropriate for H.310; it is rather to be in H.222.1.

•	There may be three alternatives in the ATMF specifications which currently refer to the H.310 ROT codepoint;

-	Strike out the reference to H.310 ROT, leave the matter to users.
-	Use J.82 codepoint.
-	Reconsider close coupling between H.310 ROT and H.245

•	We need a mechanism to identify different terminal types conforming to different standards as far as they are not compatible in their basic forms.  A desire was expressed to reduce number of similar fragmented specifications from the manufacture point of view.

•	Since it has been agreed that RAST-5 may not be directly connected to the public network, an explicit wording is necessary in H.310.

•	The definition of terminal types was finalized as in Table 2/H.310 based on Table 1/TD-4.  The meeting agreed to the classification according to audiovisual transfer capabilities and supported AAL(s), recognizing that the distinction between RAST-P and RAST-C is not clear with respect to technical specifications.

•	H.310 mandates naked AAL1 if it is supported and recommends support of optional FEC only and/or long interleaver.  Recommended options are:

-	RAST: FEC without long interleaver
-	ROT/SOT: long interleaver

	Other options can be used through H.245 capability exchange procedures.

•	ROT/RAST interworking is required for H.310 if they have matching audiovisual capabilities and AAL.

•	H.310 ROT should be simple as basic as possible.  A particular favoring view of a manufacturer was expressed that to support everything is not acceptable without knowing the market needs.

•	Our response to the ATMF liaison (AVC-903) is based on the following guidelines:

-	Objective of compatibility checking is to avoid call establishment for incompatible combinations.
-	By adding necessary options to H.310 RAST, it can become conformant to J.82 or other standards.
-	When J.82 terminal profile is defined, it should have a separate codepoint.

2.2.2 Compatibility check by B-HLI (AVC-873, 905)

The following items were discussed:

•	Objective of compatibility checking through Q.2931 messages
•	Impact of composite terminal
•	Indication by enumeration
•	Response from the called terminal regarding terminal protocol choice
•	Communication with SG11

During the discussion, the following comments and conclusions were obtained:

•	The meeting reached a common understanding regarding the objective of compatibility checking as stated in AVC-873.

•	Taking into account that the service negotiation in N-ISDN had been considered, but did not bear fruit, we should formulate functional requirements for SG11 in forms of a diagram.  SG11 is responsible for the mechanism to achieve required functionalities.

•	The meeting recognized the necessity of the called terminal indicating a chosen terminal protocol.

•	Original approach for use of B-LLI taken at the Kamifukuoka meeting was intended for negotiation because it can support multiple identifiers and indication of the chosen identifier.

*	Indication of preference for multiple terminal protocols is desired; simple order would be sufficient.

*	When we indicate preference by listing the order, a composite terminal requires a separate codepoint like "H.310", "T.120", "H.310 and T.120" as discussed in AVC-873.

•	We need B-HLI codepoints for at least 9 types of H.310, and plus others to be covered by separate Recommendations.

2.2.3 Text for communication with SG11 (TD-6)

Based on the discussions and conclusions as stated above, a draft liaison to SG11 was produced as TD-6.  There was a comment that charging aspect should also be communicated with SG11 in the light of that use of user to use signaling has been considered to avoid unnecessary establishment of VCs (network resources).  However, allocating separate codepoints to different H.310 terminal types was understood to serve for this purpose.

The meeting agreed to the draft with some amendments and the final text is contained in Annex 4 to this report.

The meeting also agreed to use this text as liaison statements to SA&A/ATMF and SG11.

2.3	Transfer rate (AVC-876)

The meeting agreed to the proposed mandatory rates, 6.144 Mbit/s and 9.216 Mbit/s.

2.4	Video frame synchronous C&I (AVC-875, 900)

The meeting considered the following items for the H.310 specification for VFS C&I signals:

•	Syntax
•	Semantics and procedures
•	Text for inclusion in Draft H.310

The meeting obtained the following conclusions:

•	Support of this specification is required for all H.310 terminals.

•	The syntax needs some amendments:

-	Byte alignment is automatic.
-	First line of syntax: SET should be changed to CHOICE.
-	Some bits are missing at the end, just copy them from H.245

•	Global support for parsing should be stated in the front line of H.310.  Mr. Morrison undertook to draft this text.

•	Closed caption should be moved to indication.

•	Sections 2, 3/AVC-875 should be transplanted  to H.310.

Mr. Nakaya undertook to generate the text for inclusion in Section 6.3.5.3/H.310 

2.5	Communication protocol (AVC-877, 882, 900)

The meeting agreed to the following actions in response to the questions and comments raised in the input contributions:

•	Value of timers: we specify that H.245 timer values should be more than Q.922 default timer values without mentioning particular value of 5 seconds.

•	Include the annex describing H.245 protocol stack in H.310, which was originally considered for inclusion in H.245.

•	The master slave determination procedure is necessary for the H.310 terminal if we take into account PVC and MCU cases.  H.310 uses the H.245 defined master-slave determination.  We strike out other master-slave related descriptions in AVC-868.

•	The value of retry counter is left to implementation in H.310.

•	Section 5.6 in AVC-877 is used as Text for H.310 with adding description of the master-slave determination and English improvements.

•	Figure 1 in AVC-882 is incorporated into the H.310 text after the list of functionalities to be supported.

•	Text in Section 3/AVC-882 replaces the corresponding text in AVC-877.

•	Definition of "logical channel" (Section 4/AVC-882) should be reflected in H.310.

•	In the second paragraph in Section 5.6.1/AC-877, last two sentences, CAPDESCRIPTORS convey real capabilities.  We clarify that both are mandatory at the start of the communications but one is optional during the communication.

•	It was clarified that the round trip delay DELAY parameter actually indicates inverse of the delay.  We warn by putting a note for interpretation of H.245 in H.310.  Communication with other users LBC, H.323 is required.

2.6	Audio coding (AVC-874)

AVC-874 proposed to mandate MPEG-1 Layer II instead of G.711 for the native H.310 RAST communication mode.  Some other views were expressed:

•	G.711 can be of high quality if the cut-off filter is not used.
•	G.722 should be the choice in the interest of delay.
•	G.711 should be the choice if it is not MPEG-1 Layer II.

The meeting concluded to leave the specification as it is, clarifying that support of both mu and A laws is required.

2.7	Disposition of comments (AVC-868, 872, 882, 883, 900)

2.7.1 AVC-878 and Annex 4 to AVC-872 (TD-12)

Conclusion for each comment raised in AVC-878 and AVC-872 is summarized in Annex 5 to this report.

2.7.2 Section 3/AVC-882

This proposal was accepted.

2.7.3 AVC-883

The proposal regarding the AAL1 and AAL5 description was sorted out as part of the terminal type definition and codepoint.  See Section 2.2 above.

2.7.4 AVC-900 (TD-13)

Conclusion for each comment raised in this contribution is summarized in Annex 6 to this report.

2.7.5 Editor's notes in AVC-868

These were covered the comments in AVC-878 and AVC-900.

2.8	Correlation identification in GIT/Q.2931 (AVC-897, 904)

AVC-897 contains a liaison statement from SG11 Rapporteur meeting which was held in October   Mr. Jeff Lynch checked this against our conclusion at the Yokosuka meeting (Section 2.7.1/AVC-854R) and confirmed that they are in line.

The meeting concluded that we maintain the session ID and resource ID structure for the Correlation ID as in Section 2.7.1/AVC-854R even if the original requirement from SG8 has been changed as seen in AVC-904, except for an obvious error in reference to DSM-CC in Note 3 which should be ITU-T Rec. H.310.

The meeting briefly considered the liaison statement from Q.10/8 (AVC-904).  It was clarified that the H.245 syntax is compatible with the existing one because elements are added after the extension marks.  Further consideration was deferred toward formulating a proposal for H.245 revision.  See Section 5 below.

2.9	ATM network performance (AVC-861, 862)

Response to AVC-861 (liaison statement from SG13 to SG15) was intended, but we could not handle this topic due to the time constraint.

2.10	Editing Draft H.310 (AVC-868; TD-22)

Mr. Mike Nilsson undertook to update AVC-868 reflecting the discussion results during the week.  The outcome was submitted as TD-22.

3.	H.225.0 discussion

3.1	Introduction

Intensive work at the Ipswich meeting resulted in an H.225.0 that it was agreed, after further editorial work, should be issued as a white paper for decision at the May 1996 meeting.  The meeting was split into two sections, one for H.323/H.225.0, and the other for H.310.  The H.323/H.225.0 meeting was jointly chaired by the editors Mr. Gary Thom (Delta) and Mr. Dale Skran (AT&T).  The following indicates major issue resolutions by general topic.  In general, the direction agreed to at the November 1995 SG15/WP1 meeting was confirmed and elaborated.  One addition was to allow the use of Q.95x services on an optional basis.

3.2	Audio/Video Coding

•	An optional mode where packing of audio/video into a single channel is allowed was left for further study.

•	Text describing how G.723, G.728, and G.729 were packetized was added.

•	It was agreed to ask the IETF for payload types for G.723 and G.729, but to use dynamic types as a fallback.

•	There is a limit of at most one video frame per packet; this is intrinsic to RTP.

•	An optional annex describing an RTP header extension for octet count for the number of bytes in a GOB will be added.

•	The alignment of video picture headers with packets only applies to H.263, and since we have no packet format for H.263, this is for further study.

3.3	Use of H.245

•	It was decided to use H.245 logical channel signaling for audio mode changes (AVC-855; 902).

•	It was decided that H.245 messages can be mixed in packets, but they must be whole multiples of the messages (no fragmentation of messages).

•	A variation on the jitter handling procedures proposed in AVC-879 was accepted.

•	Conflicts between H.245 methods and RTP methods were resolved on the basis of a point-by-point comparison rather than a general rule.  For example, in the case of jitter measurement both methods are valid and different while H.245's video commands are used.  RTP's BYE is not used.

•	All channels except T.120 will be uni-directional.

•	Procedures for associating a separate T.120 conference with an H.323 conference were agreed to.

3.4	LAN Specific Issues

•	Broadcast or multicast for GRQ distribution will be specified on a per transport basis in H.225.0 Appendix D.

•	A mixer is not an MCU but also an MCU is not a mixer though it has some characteristics of an MCU.  Also, a gateway (GW) can sometimes be a translator, e.g. if LAN in to LAN out, or LAN-GW-GW-LAN calls.

3.5	RAS Channel Issues

•	It was agreed to make the "unregister" command bi-directional.

•	Add a field to the admissions confirmation that says "send IRR every xx seconds" while on call, including while on hold to lower overhead.

•	Add disconnect as disengage; clarify that release complete is still required if the signaling channel is open.

•	It was decided to change the name of the SRQ/SRR messages to IRQ/IRR to avoid confusion with the status message, and also to add a zero CRV to indicate a desire for information on all active calls.

•	The gatekeeper will optionally be able to assign E.164 addresses in the ACF message as proposed in AVC-895 as modified by various amendments.

3.6	Q.931 Issues

•	It was decided to use Annex D of Q.931 which is the symmetrical mode.

•	A version of AVC-888 was adopted for handling errors and restoring the Q.931 channel.

•	Based on AVC-884, AVC-879, and especially AVC-898 the Q.931 section was revised and updated.

3.7	Call Model

•	The call procedures were modified so that features do not depend on call direction; a terminal with a gatekeeper can force calling terminals to use its gatekeeper.

4. H.323 discussion

4.1	RTP vs H.245

Issue	There are potential conflicts between RTP commands and H.245 commands.

Resolution	Text was developed to specify which commands conflict, and that the H.245 commands should be used.

4.2	Multiple B Channel Call Setup

Issue	How are multiple B channel calls set up?

Resolution	To be resolved by e-mail prior to submitting the white paper. 

4.3	Q.931 User or Network Signalling

Issue	Are terminals, gatekeepers, etc. a user or the network according to the Q.931 procedures?

Resolution	All entities shall be users according to Annex D of Q.931 (symmetric signalling).

4.4	RTP Byte Count

Issue	Is the proposed RTP Byte Count needed?

Resolution	The byte count can be put in the optional RTP header extension.

4.5	Min/Max Buffer Size

Issue	Do we need to specify the min buffer size required and the max buffer size allowed for audio and video?

Resolution	H.2250Skew parameter defined. This can be used to set buffer sizes.

4.6	Max Jitter

Issue	Do we need to specify maximum jitter?

Resolution	Text developed to specify maximum audio jitter.

4.7	Error Recovery

Issue	How are protocol failures and loss of channels handled?

Resolution	Incorporated proposed text on transport failure recovery.

4.8	Calling from bound to unbound terminals

Issue	Call models do not handle all cases including calling from registered to unregistered terminals with gatekeeper call signalling routing.

Resolution	All call models redefined and fence post diagrams generated. These will be incorporated with appropriate text descriptions.

4.9	Usage of Q.931

Issue	What Q.931 messages are mandatory and optional?

Resolution	Text was developed for H.225.0 indicating mandatory and optional messages.

4.10	Ad Hoc Conferencing

Issue	Ad hoc conferencing and multipoint expansion may not be completely specified.

Resolution	Text was developed and incorporated to cover additional cases.

4.11	Supplementary Services

Issue	Should Q.950 supplementary services be permitted?

Resolution	The use of Q.950 supplementary services are optional. Gateways shall pass unrecognized Q.931 messages to the endpoints. H.323 multipoint expansion and transfer capability is mandatory.

4.12	Mode Changing

Issue	Should the logical channels be closed and re-opened in order to change audio and video modes?

Resolution	Yes.

4.13	Call Transfer

Issue	A simple call transfer mechanism was proposed using existing H.225.0 messages. This will facilitate inbound calling through an operator.

Resolution	Capability added.

4.14	T.120 Channel Association

Issue	Can an existing T.120 conference be associated with a new H.323 conference?

Resolution	Text was developed describing the procedures for associating existing T.120 connections with a new H.323 conference.

5.	H.245 discussion 

5.1	Corrections/amendments to H.245 (AVC-881)

The meeting reviewed AVC-881 and decided some follow-up actions as follows:

Section	Review results	
1.1	Editorial.	
1.2	Editorial, not controversial.  No harm if it is not corrected.	
1.3	Editorial, the impact is localized.	
1.4 	Significant, but related to error conditions.  Ask Mr. Stuart Dunstan of the impact.	
2.	Editorial, corrections are for consistency.	
3.1	Same as 2 above.	
3.2	Significant.  Keep as it is, recognizing that the current specification is not ideal; corrections cause incompatibility. 	
3.3	Editorial as in section 2, this is for consistency's sake.  The syntax is correct.	
3.4	The syntax is correct, Table 46 should be corrected.  Sensible designers recognize the error.  This is a defect.	
3.5	Editorial.	
4.1	Take solution c).	
4.2	Check whether the change conforms with Solution c).  Consult with Mr. Stuart Dunstan.  There was a comment that the current description is generic, thus appropriate.	
4.3, 4.4	The resolution depends on the solution chosen; c).	

The meeting agreed to incorporate these changes into revision of H.245 together with the H.323 requirements .  The target is to make a white contribution for the May 1996 meeting of SG15.

5.2	Feedback from H.310 considerations

No items were identified at the moment.

5.3	Feedback from H.323 considerations (AVC-879, 890)

These two contributions form a basis for the white contribution which hopefully will be determined at the May 1996 meeting of SG15.  Mr. Mark Reid will produce a revised version reflecting the agreements for the white contribution.

5.4	Requirements from Q.10/8 regarding T.120 (AVC-904)

AVC-904 discusses amendments of H.245 for addressing and association of media streams carried over separate network connections.  This is beyond what we considered at the Yokosuka meeting (Annex 3 to AVC-854R).

5.5	Necessary actions

Due to lack of time, we could not fully address the H.245 revision.  We will continue to study these items through correspondence and produce a white contribution toward the May 1996 meeting of SG15.  See Section 6.2 below.

6.	Future work (AVC-857, 867)

6.1	Submission of white papers for Draft H.310, H.225.0, H.323 
	(TD-22, 23, 24)

Respective Editors undertake to finalize the draft Recommendations and submit white contributions by the end of January.  Members are requested to assist Editors by providing editorial improvements to TD-22, 23 and 24.  Such comments, if distributed by 24 January at contributor's local time, may be considered at Editor's discretion.

Annexes to H.225.0 reproduces some parts of IETF RFC which requires agreement of the authors.  Procedures for reproducing need be confirmed between IETF and ITU-T.

6.2	Revision of H.245

The Experts Group intends to submit a white contribution for future revision of H.245 two months in advance of the May 1996 SG15 meeting.  Mr. Mike Nilsson undertakes to coordinate activities for this purpose.

6.3	Second phase work (AVC-857, 867, 880)

Rapporteur drew attention of the meeting to the following materials:

•	Study items in the second phase (AVC-867, 880)
•	Draft new questions for the next study period (AVC-857)

Members are requested to study these and contribute to formulating Questions which attract experts.

7.	Interactions with other groups

The meeting decided to correspond with other groups as follows:

Destination	Topic	Material	
SG8	• Session ID (AVC-904)	to be studied (Section 5.4)	
SG9	• Terminal type	Annex 4	
SG11	• Call setup delay	Annex 3	
	• Terminal type	Annex 4	
SG13	• ATM network performance	to be studied (Section 2.9)	
ATMF	• H.310 terminal types	Annex 4	
IETF	• Payload types for G.723 and G.729
• Reproduction of RFC in H.225.0	Section 3.2
Section 6.1	

8. Future meeting

Meeting	Date	Place	Note	
Study Group 15	27 May - 7 June 1996	Geneva		

END

Annexes

Annex 1	Time schedule of the Ipswich meeting	
Annex 2	Documents for the Ipswich meeting	
Annex 3	Liaison statement to SG11 regarding call stup delay	
Annex 4	Liaison statement to SG11 regarding terminal protocol identification	
Annex 5	Disposition of comments to Draft H.310 in AVC-877	
Annex 6	Disposition of comments to Draft H.310 in AVC-900	

Participants of the twenty-first meeting of the Experts Group for Video Coding and Systems in ATM and Other Network Environments held in Ipswich, UK
(16-19 January 1996)

Country 	Name	Organization	
Germany	Mr. Joerg Ott	Technische Universitdt Berlin	
USA	Mr. Fred Baker	Cisco Systems	
	Mr. Narjala Bhasker	Intel	
	Mr. Chuck Bostrom	CLI	
	Mr. Glen Freundlich	AT&T	
	Mr. Tom Geary	Rockwell International	
	Mr. George Kajos	VideoServer	
	Mr. Vineet Kumar	Intel	
	Mr. David Lindbergh	PictureTel	
	Mr. Jeffrey J. Lynch	IBM	
	Mr. John D. Phillippy	InSoft	
	Mr. Mark Reid	PictureTel	
	Mr. Hardish Singh	Integrated Information Technology	
	Mr. Dale Skran	AT&T	
	Mr. Neil Starkey	DataBeam Corp	
	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	
	Mr. Bahman Mobasser	Alcatel	
Israel	Mr. Ami Amir	RADVision	
	Mr. Chouki Idan	RADVision	
Japan	Mr. Keiichi Hibi	Sharp	
	Mr. Yuichiro Nakaya	Hitachi	
	Mr. Sakae Okubo	GCL	
Netherlands	Ms. Mascha van Dort	Royal PTT Netherlands	
UK	Mr. David Beaumont	BT	
	Mr. Peter Cordell	BT	
	Mr. Tim Midwinter	BT	
	Mr. Geoff Morrison	BT	
	Mr. Mike Nilsson	BT	
	Mr. Morgan Potter	BT	
Sweden	Ms. Annika Kilegran	Telia Research	

Annex 1 to AVC-906R

Time schedule of the Ipswich meeting

	Tue 16	Wed 17	Thu 18	Fri 19	
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	√										
	Review of the previous day discussions				√			√				
	Review of this week achievements										√	
	Work plan and work method										√	
											
H.310 sub-group											
	Discussion of open issues		√	√	√							
	H.310 drafting					√	√	√	√			
	H.310 review								√	√		
	Correspondence to SG11				√							
	Amendments to H.245						√					
											
H.323 sub-group											
	Discussion of open issues		√	√	√							
	H.225.0/H.323 drafting					√	√	√	√			
	H.225.0/H.323 review								√	√		
	Amendments to H.245						√					
											
Joint session											
	H.245 							√				

Annex 2 to AVC-906R

Documents for the Ipswich meeting
(16-19 January 1996)

Normal Documents

AVC
 number	Pur-pose	
Title (Source)	
AVC-854R	R	Report of the Twentieth Experts Group meeting in Yokosuka - 24-27 October 1995 (Rapporteur)	
AVC-855	D	Comments on H.225.0 (RADVision)	
AVC-856	D	Comments to the H.323 Draft (RADVision)	
AVC-857	R	Draft new Questions proposed by WP1/15 (WP1/15)	
AVC-858	R	MPEG Meeting in Dallas, Nov. 6 - 10 / 95 (Hideyuki Ueno)	
AVC-859	P	Changes to Rec. H.222.1 following the Yokosuka meeting (Editor - S. Dunstan)	
AVC-860	R	Quick report of the SG15 meeting in Geneva (Rapporteur)	
AVC-861	R	Liaison to SG15 concerning ATM QoS (SG13)	
AVC-862	R	Report of Rapporteur Meeting, Lannion, France,  November 13-17, 1995 (Rapporteur for Question 16/13)	
AVC-863		withdrawn	
AVC-864		withdrawn	
AVC-865		withdrawn	
AVC-866	P	Adaptation of RTP to H.323 (RADVision)	
AVC-867	R	Open issues toward the Ipswich meeting (Rapporteur)	
AVC-868	P	Draft H.310 (Editor - H. Radha)	
AVC-869	P	Draft H.225.0 (Editor - D. Skran)	
AVC-870	P	Draft H.323 (Editor - G. Thom)	
AVC-871	R	Meeting report (Working Party 1/15)	
AVC-872	P	Further considerations regarding the H.310 start up procedures (Japan)	
AVC-873	D&P	Terminal protocol identification by B-HLI (Japan)	
AVC-874	P	Mandatory audio coding for native H.310 mode (Japan)	
AVC-875	P	Semantics of video frame synchronous C&I (Japan)	
AVC-876	P	Common bitrate for H.310 terminals (Japan)	
AVC-877	P	Proposed description of communication protocol in draft Rec. H.310 (Japan)	
AVC-878	D	Comments on draft H.310 (Japan)	
AVC-879	P	H.323, H.225, and H.245 Comments and Assigned Work Items (PictureTel)	
AVC-880	I	Current status of G and H-series Recommendations for audiovisual communication systems (Rapporteur)	
AVC-881	P	Some editorial comments on H.245 (Siemens)	
AVC-882	P	Comments on references to H.245 in H.310 and H.323 (Siemens)	
AVC-883	P	Proposal for amendments to the text of ITU-T Draft Recommendation H.310 (France)	
AVC-884	P	Q.931 Signaling in H.323 (Intel)	
AVC-885	P	Comments for H.323 Registration and Address Translation (Intel)	
AVC-886	D	H.323/H.225.0 Draft Comments and Revisions (Intel)	
AVC-887	P	H.323 Terminal/Gatekeeper Registration  (Intel)	
AVC-888	P	Comments for H.323 Error Recovery  (Intel)	
AVC-889	P	Comments for H.323 Clarification (Intel)	
AVC-890	P	Changes to H.245 in support of H.323 (Editor - Dale Skran) 	
AVC-891	I	Status of RTP (Editor - Dale Skran)	
AVC-892	P	Annex A to H.225.0(RTP/RTCP) (Editor - Dale Skran)	
AVC-893	P	Annex B to H.225.0(RTP profile) (Editor - Dale Skran)	
AVC-894	P	Annex C to H.225.0(H.261 Packetization for RTP) (Editor - Dale Skran)	
AVC-895	P	Proposed Changes in H.323/H.225.0 (Editor - Dale Skran)	
AVC-896	D	Issues Using the Q-series for Supplementary Services in H.323 (Editor - Dale Skran)	
AVC-897	R	Session and Resource / Correlation identification capability of B-ISDN signalling protocols (Rapporteur for Q.15/11)	
AVC-898	P&D	Usage of Q.931 messages in H.225.0 (TUB)	
AVC-899	D	H.310 ROT and SOT terminals (BT)	
AVC-900	D	Comments on H.310 (BT)	
AVC-901	D&P	Modifications to the H.323 AdmissionRequest set of messages (BT)	
AVC-902	D&P	Changing network bandwidth usage within an H.323 conference (BT)	
AVC-903	D	Liaison letter to Rapporteur for ITU-T SG15 Q.2/15 (SA&A/ATMF)	
AVC-904	P	Need for H.245 to support addressing and association of media streams carried over separate network connections (SG8 Q.10/8)	
AVC-905	R	Special report of ITU-T WP1/9 activities (SG15 Liaison Rapporteur to ITU-T SG9)	

Temporary Documents

#	Source	Title	
TD-1	Rapporteur	Agenda (General) for the Ipswich meeting	
TD-2	Rapporteur	Available documents for the Ipswich meeting	
TD-3	Rapporteur	Agenda for H.310 discussion	
TD-4	Rapporteur	Definition of H.310 terminal type	
TD-5	Editor - D. Skran	Open issues in H.225.0	
TD-6	Rapporteur	Draft correspondence to SG11 - terminal protocol identification	
TD-7	J. Toga	Error handling	
TD-8	M. Reid	Jitter and skew proposal	
TD-9	J. Ott	Network/user identification	
TD-10	V. Kumaar	H.245 conflicts and parellels	
TD-11	Editor - S. Okubo	H.310 discussion results	
TD-12	Editor - S. Okubo	Disposition of comments in AVC-878	
TD-13	Editor - S. Okubo	Disposition of comments in AVC-900	
TD-14	Idan	Adaptation of RTP to H.225.0 audio and video	
TD-15	J. Ott	Usage of T.120 in conjunction with H.323	
TD-16	T. Geary	Interoperability of H.323 with V.dsvd terminals	
TD-17	G. Freundlich	Comments regarding H.225.0 messages and H.245 messages in H.323	
TD-18	M. Reid	Call model message flows	
TD-19	F. Baker, G. Freundlich	Additions to network address specification	
TD-20	J. Toga	Multipoint conference	
TD-21	P. Cordell, V. Kumaar	H.323 terminal types for H.245 master slave determination	
TD-22	Editor - S. Okubo	Draft H.310	
TD-23	Editor - D. Skran	Draft H.225.0	
TD-24	Editor - G. Thom	Draft H.323	

END

Annex 3 to AVC-906R

Response to SG11 concerning connection delay and common routing

ITU - Telecommunication Standardization Sector	Temporary Document       
STUDY GROUP 11	Original: English
____________________________
Miyazaki, 29 January - 16 February November 1995

(WP1/11)

QUESTIONS:	Q.10/11 (DSS2), Q.2/15

SOURCE: 	ITU-T SG15, Rapporteur Group for Q.2/15 (Ipswich, 16-19 January 1996)
TITLE:	Liaison response concerning QoS for call setup delay and common routing connections to minimize delay

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

TO:	ITU-T SG11 - WP1/11
APPROVAL:	Agreed at the Rapporteur group meeting
FOR:	Response to your liaison statement and further request of clarification
DEADLINE:	Deadline for reply - 24 May 1996 

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

The SG15 Experts Group for Video Coding and Systems in ATM and Other Network Environments met during 16-19 May 1996 in Ipswich, UK.  This group has been working toward standardization of audiovisual communication systems in B-ISDN and LANs with intention of producing Recommendations H.310, H.321 (B-ISDN) and H.322, H.323 (LANs).

We wish 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 our group and further elaborated at the Ipswich meeting mentioned above.  The results of that review and the remaining items of question or concern are defined below.

1.  QoS for call setup delay 

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 require subsequent addition of one or more channels to an established call (Note), 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 one 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.  We also have an observation of much shorter call setup delays in case of 2 x B communications using N-ISDN.

Note - Draft Recommendation H.310 uses the following procedures to set up an audiovisual communication:

1)	An H.310 terminal (initiating or receiving a call) is able to identify the remote terminal type (H.320/H.321, H.310 RAST, etc.) via Q.2931 signalling at the beginning of the call (i.e., prior to the audiovisual communication).
2)	When two H.310 terminals are communicating, a default H.245 (logical) channel is established over the initial ATM VC at the beginning of the call.
3)	When two H.310 terminals communicate, each terminal indicates its capabilities to the remote terminal using the capabilities exchange messages and procedures described in ITU-T Recommendation H.245.
4)	According to the agreed mode of operation through the H.245 capability exchange procedures, the second VC for audiovisual and other data is established with proper parameters such as bitrates for each direction, AAL.  
5)	An desired audiovisual communication starts.  One or more VCs may be set up according to the negotiation between the two terminals involved.

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 achieved Resolution 1 decision in November 1995; the H.310 recommendation is expected to reach that status 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.

END

Annex 4 to AVC-906R

Liaison statement to SG11 on terminal protocol identification

ITU - Telecommunication Standardization Sector	Temporary Document       
STUDY GROUP 11	Original: English
____________________________
Miyazaki, 29 January - 16 February November 1995

(WP1/11)

QUESTIONS:	Q.10/11 (DSS2), Q.37/9, Q.2/15

SOURCE: 	ITU-T SG15, Rapporteur Group for Q.2/15 (Ipswich, 16-19 January 1996)
TITLE:	Liaison statement on terminal protocol identification

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

TO:	ITU-T SG11 - WP1/11, ITU-T SG9 - WP1/9, SA&A/ATMF
APPROVAL:	Agreed at the Rapporteur group meeting
FOR:	Consideration
DEADLINE:	Deadline for reply - 24 May 1996 

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

The SG15 Experts Group for Video Coding and Systems in ATM and Other Network Environments met during 16-19 May 1996 in Ipswich, UK.  This group has been working toward standardization of audiovisual communication systems in B-ISDN and LANs with intention of producing Recommendations H.310, H.321 (B-ISDN) and H.322, H.323 (LANs).

This document discusses some requirements for the terminal identification through Q.2931 messages taking into account composite broadband audiovisual communication terminals (Part I), and proposes a list of codepoints for terminal protocol identification (Part II).

Part I	Requirements for terminal protocol identification from composite broadband audiovisual communication terminals

1.	Introduction

This part discusses the objectives and a necessary mechanism to identify the terminal protocol compatibility through the out-of-band signalling.  The focus is a composite terminal which may implement multiple terminal protocols e.g. on a PC or a Work Station.

An idea of indicating multiple terminal protocols by enumeration is raised.  Necessity of indicating the choice of terminal protocol by the called terminal is also pointed out.

2.	Purpose of compatibility check through the out-of-band signalling

It is understood from Annex B to Q.2931 that the purpose of compatibility checking is to reject such an incoming call which is clearly incompatible due to different terminal protocols supported by the calling and called terminals.

3.	Terminal implementation

One of the objectives of broadband audiovisual communication systems in B-ISDN environments is to achieve service integration; namely a single terminal is desired to work as multi-function terminals by supporting multiple terminal protocols.

From the implementation point of view, it is probable that a single terminal would support more than one terminal protocols forming a composite terminal, particularly if they are implemented on a PC or a Work Station.

4.	Indication of multiple terminal protocols in Q.2931 messages

4.1	Terminal protocol identification mechanism

Since the composite terminal is believed to be the future direction, we need a terminal protocol identification mechanism beyond the current Q.2931 framework which allows indication of only one protocol in B-HLI.

The following principle is provided for discussion:

1)	According to the wish of calling user, the calling terminal indicates ALL terminal protocols expecting that the called terminal will respond if it supports ANY one of them and is willing to respond.  For example, if the terminal has capabilities of A (say H.310 RAST, receive and send terminal for conversational services), B (say T.120 audiographics over ATM), then it can indicate A and B.  As this method can not express the wish of being responded only when the called terminal is equipped with both A and B, we need definition of C (=A&B) as a new terminal protocol which indicates the use of A and B simultaneously.

2)	According to the wish of called user, the called terminal can program to which calling terminal protocol(s) it will respond.  For example, when the terminal supports both A (say H.310 RAST) and B (say T.120 over ATM) terminal protocols, it can respond to either of the calling side indications:

-	if A is included
-	if B is included
-	only if C is included

The choice is left to the user's wish.

4.2	Methods of indicating multiple terminal protocols

To meet the requirement of indicating that either one of multiple terminal protocols may respond, there are two methods:

Method #1: to structure terminal protocol in a hierarchical way 

                          +-- a
                          |
                   +-- A -+-- b
                   |      |
                   |      +-- c
               X --+
                   |      +-- d
                   |      |
                   +-- B -+-- e
                          |
                          +-- f

Indicating A means that either of a, b or c may be responded while X means that either of A or B (namely either of a, b, c, d, e, or f) may be responded.  This mechanism is necessary if only one information element is conveyed.

Method #2: to enumerate all 

This is a method to list up terminal protocols one by one which can be responded to by the remote partner.

Since the first method needs a neat framework from the start and since we can hardly predict the future of multimedia communications, the second method is practical because of its flexibility.

A simple indication by priority order may be a practical solution.

4.3.	Response from the called terminal

Currently Q.2931 CONNECT message does not include B-HLI (Note).  Hence when the calling terminal has indicated multiple terminal protocols, it can not know what terminal protocol the responding terminal has in the out-of-band signalling.

	Note - Relatedly, it might be useful/necessary to return GIT from the called side.

We need such information to facilitate identification of different in-band signalling protocols (e.g. H.245 control protocol in H.310 terminal and DSM-CC in VoD terminal).

If the indication of the responded terminal protocol is required, Q.2931 needs a new mechanism for this purpose.

4.4	Procedures for terminal protocol identification

A conceptual procedure based on the above consideration is illustrated in the attached figure.

5.	Conclusion

We would like to request SG11 experts to consider the above requirements from composite terminal supporting multiple terminal protocols and provide an appropriate mechanism in the Q.2931 signalling.

Part II	Code points for terminal protocol identification

1.	Introduction

The current B-HLI codepoints listed in the Q.2931 living document are as follows:

-	H.310 ROT & SOT
-	H.310 RAST
-	H.321 (H.320 emulation for ATM)
-	H.320 (N-ISDN videophone)

It contains only two codepoints for native broadband communications: H.310 ROT & SOT and H.310 RAST.  SG15 is going to decide Draft H.310 at its May 1996 meeting and the study so far reveals that we need more codepoints to avoid call establishment between two incompatible terminals.  This need comes from two aspects:

-	progress for the definition of H.310 family of terminal types, 
-	standardization activities in different bodies in the area of audiovisual and multimedia communications.

2.	H.310 terminal types

Profiling of H.310 terminal types is based on the following two functionalities supported:

-	audiovisual transport: receive only (ROT), send only (SOT), receive and send (RAST)
-	AAL: AAL1, AAL5, both AAL1 and AAL5

Hence we now have the following 9 types in Draft H.310:

-	ROT-1, ROT-5, ROT-1&5
-	SOT-1, SOT-5, SOT-1&5
-	RAST-1, RAST-5, RAST-1&5

Out of these terminal types, some combinations can not interwork due to incompatibility of audiovisual transport capability or AAL capability: e.g. ROT-1 and ROT-1, ROT-1 and SOT-5.  Hence we need separate codepoint for each of them.

3.	Terminal protocols defined by other bodies

Currently several organizations are specifying audiovisual and multimedia communication systems for standardization other than SG15; e.g. ITU-T SG9, ATMF, DAVIC.  Their specifications have many components in common but some components specific to each due to different applications and different communication environments.  SG15 experts have considered whether they should be covered by a single Recommendation H.310 or separate recommendations and reached a conclusion that they should be covered by separate Recommendations because the terminals in their basic forms can not interwork due to above mentioned differences.

It should be noted, however, that H.310 terminals can also conform to other standards if they include necessary components as option, hence forming a composite terminal.  The same is true for anticipated terminals conforming to other standards; if they include necessary components as option, then they can perform as H.310 terminals.

4.	List of codepoints

The following list of terminal protocol codepoints is provided for consideration of the SG11 experts:

	- nine H.310 terminal types listed in Section 2 above
	- H.321  (H.320 emulation for ATM)
	- provision for future inclusion of H.31x, H.31y, H.31z, etc.

The last item refers to H.31x, H.31y, H.31z, etc. which are not yet drafted but anticipated to accommodate dedicated application terminals conforming to SG9 J.82, ATMF specifications, DAVIC specifications, etc.  They need separate codepoints from compatibility consideration as discussed in Section 3 above.

Please note that we now believe the codepoint H.320 is not necessary because the H.320 terminal is not accommodated in B-ISDN as it is.  The adaptation of H.320 is defined in H.321.

END

Annex 5 to AVC-906R

Disposition of comments in AVC-878

Comment	Conclusion	
2. Technical comments		
1) Figure 2, note 9)
H.221 is also required in RAST-C?  Or it is in the gateway?	# It is in the gateway.	
2) Section 5.2.1.2, Bidirectional Terminals, last sentence
Reword this sentence according to the discussion of AVC-874.	# It is valid from the conclusion of the Audio coding discussion.	
3) Section 5.2.2.2.1, Unidirectional Terminals, Note 14
This is to be answered.	# No, we need not to define UU inn H.310.
# Jeff Lynch will check Note 15.  Perhaps true.	
4) Section 5.2.2.2.1, Unidirectional Terminals, Note 16
J.82 requires support of AAL1 long interleaver and H.222.0 multiple program TS.  Can H.310 AAL1-based ROT/SOT be identical to the J.82 terminal?

Or minimum H.310 ROT/SOT can be J.82 terminal if those optional enhancements are supported?

# No.

# Yes.	
5) Section 5.2.2.2.3, Note 19
Maximum size of H.245 message is 2048 bytes as agreed in Yokosuka.  AAL-5 CPCS-SDU size should accordingly be defined as 2048 bytes.  See also Annex 3 to AVC-872.	# Agreed, to be stated in the restored Annex.
(AAL-5 CPCS-SDU size should take into account overhead of intermediate layers.)	
6) Section 5.2.2.2.5, last sentence
The minimum number of VC’s that the different types of H.310 terminals will support is under study.  ==> The minimum number of VC’s that the different types of H.310 terminals will support is two.  {depending on the conclusion regarding AVC-872}	# Agreed.	
7) Section 5.2.2.3.1, Editor's note
Remove CBR from "under study" items and include it as part of this Recommendation.	# Agreed.
	
8) Section 5.2.3.2.3, 1st paragraph, Note 22
Support of VFS C&I signals by unidirectional terminals is required since the signals listed are not coupled with bidirectional audiovisual channels.	# Yes, see Geoff Morrison's wording for global requirement of support.	
9) Table 5, Number of ATM VCs, M, O.
one ==> two if AVC-872 is accepted.	# Agreed.	
10) Table 5, Transfer Rate, M
Fill in according to AVC-876 if the proposal is agreed.	# Agreed.  All US ==> 6, 9 Mbit/s as agreed.   Clarify that they are at AAL-SAP.	
11) Section 5.5
Reword according to the agreements regarding AVC-872, AVC-873, AVC-877.	# Add the use of ATMVCIndication before the second call set up.
# The alerting and charging issue is still pending.
# Generalize the reference to Q.2931 B-HLI to "B-BC and other information elements".
# The second call is set up from the calling side of the initial call.	
12) Section 6
The following text is provided as strawman: 
"
H.310 terminals may be used in multipoint configuration through MCUs which may be accommodated in B-ISDN, N-ISDN or other networks.

	....
"	# Agreed.	
13) Section 7
- Audio level setting for G.711, G.722, G.728: see H.320.
- Audio level setting for other audio coding including 11172, 13818 audio is under study.

	# Agreed.	
3. Editorial comments		
1) Global changes
- must, have to ==> shall {according to the convention in Section 3}
- G.723 ==> G.723.1
- might be  ==> may be {according to the convention in Section 3}
- Remove all editor's notes, or change necessary ones to footnotes.
- Change "US" to "under study" where necessary.
- MPEG Layer 1, 2 ==> MPEG Layer I, II {according to ISO/IEC 11172-3}	# Agreed.	
2) Section 1, 4th paragraph
... B-ISDN and a customer-premises ATM network might be needed to provide interoperability functions ...
==> ... B-ISDN and a customer-premises ATM network may be needed to provide interoperability functions ...	# Agreed.	
3) Section 1, 2nd last paragraph, 1st sentence
In addition to supporting VoD services, H.310 unidirectional (ROT and SOT) terminals also support simple audiovisual signal transmission, surveillance, and other services.
==> Since H.310 unidirectional (ROT and SOT) terminals are applied to simple audiovisual signal transmission, surveillance, and other services including VoD services, they should be interoperable with H.310 bidirectional (RAST) terminals as far as they have matching audiovisual and network adaptation capabilities.  	# ... terminals are applied to simple ... ==> ... terminals are applicable to simple ...	
4) Footnote 1
out-of-band ==> out-band {according to H.320}	# Use "out-of-band" consistently.	
5) Section 2 References
[3]	G.723 (1995) ==> G.723.1 (1996)
	...	# Agreed.	
6) Section 3
- Add definition of some terms as Section 3 (ex. bidirectional, audiovisual terminal, broadband audiovisual communication, communication mode, gateway, in-band, out-band, unidirectional audiovisual terminal, etc.)
- Add list of abbreviations as Section 4 (ex. AAL, ATM, B-HLI, B-ISDN, C&I, CBR, CPCS, CPI, CS, DSM-CC, MCU, N-ISDN, PDU, RAST, RAST-C, RAST-P, ROT, SAP, SAR, SOT, SSCOP, SSCS, UNI, VBR, VC, VFS, VoD, etc.)
- Move the current contents to Section 5 Conventions.	# Agreed.  Yuichiro Nakaya will do the work.	
7) Section 5.1, 1st paragraph
The corresponding Recommendations/Draft Recommendations ...
==> The corresponding Recommendations ...	# Agreed.	
8) Figure 2
I.363 should be properly changed to I.363.1 or I.363.5.	# Agreed.	
9) Figure 2 and note 2)
- Clause 1.3 of ISO/IEC 13818-6 states ...
==> Clause 1.5 of ISO/IEC DIS 13818-6 states that AAL5 is a suitable example for ...

- A white box in the DSM-CC stack needs be filled, otherwise "under study" should be indicated.	# Drop DSM-CC part of the stack.	
10) Figure 2, note 3)
Reword according to the conclusion on the T.120 transport through a single VC.	# Drop Note 3.
# Add in Note 1 "protocols stack for T.120 is defined in T.123.
# Add to Note 11  "protocol stack for signaling is defined in Q.2931.	
11) Figure 2, note 6)
Delete this note because H.222.2 is no more intended.  Consequently, renumber the subsequent notes.	# Agreed.
	
12) Figure 2, note 10)
- ... DSS2 is composed of the suite of protocols shown in Table 1.
==> ... DSS2 is composed of the following suite of protocols:
- Delete "Table 1  Summary of DSS2 protocols" because Table 1 appears later in the main body.	# It should have its table number.	
13) Section 5.2, 2nd paragraph
... two classes of communication modes are outlined in Section 5.3
==> .. two classes of communication modes are specified in Section 5.3 	# Agreed.	
14) Section 5.2, II
- ..., H.310 terminals will be able to ...
==> ..., H.310 terminals shall be able to ...
- Q.2931 high-level information messages
==> Q.2931 broadband high-layer information (B-HLI) messages	# "by exchanging terminal type via Q.2931 messages. "{without mentioning B-HLI}	
15) Section 5.2, III, last sentence
- If a capability (audiovisual or another) has to ...
==> If a capability (audiovisual or another) shall ...
- However, the support of H.261 video ...
==> However, the use of H.261 video ... {H.261 shall be supported by H.310 RAST but it is not used in the native mode.}	# Agreed.	
16) Section 5.2.1.1, Unidirectional Terminals, 2nd last paragraph and Section 5.2.1.1, Bidirectional Terminals, 3rd last paragraph
... the video parameters’ constraints outlined in Section 8 of ...
==> ... the video parameters’ constraints specified in Section 8 of ...	# Agreed.
	
17) Section 5.2.2.1, Bidirectional Terminals, 1st paragraph
For RAST-C terminals, the support of H.221 can be achieved either in the terminal or in a gateway (at the customer premises side) between the (public) ISDN and (private) customer premises networks.
==> Need not be singled out?  Or this can be left to the implementation of customer premises network systems as far as they are seen as RAST-P through the gateway?	# To single out gateway support according to the agreed stacks for RAST-1, RAST-5, RAST-1&5.	
18) Section 5.2.2.2, last word
outlined ==> specified	# Agreed.	
19) Section 5.2.2.2.1, Unidirectional Terminals, Note 13
Including optional support of the other type of AAL is acceptable.  This is already implemented in Table 5.	# Define ROT-1&5, SOT-1&5 type.	
20) Section 5.2.2.2.1, Bidirectional Terminals, 4th paragraph
The support of AAL type 5 for the adaptation of H.222.1 multiplexed bitstreams is optional for all H.310 RAST terminals (i.e., RAST-P and RAST-C). H.310 RAST-C terminals, however, must support either AAL type 1 or AAL type 5.  
==> The support of AAL type 5 for the adaptation of H.222.1 multiplexed bitstreams is optional for H.310 RAST-P terminals. H.310 RAST-C terminals, however, must support either AAL type 1 or AAL type 5. 	# Replace with protocol stack diagram and words.  Jeff Lynch undertakes this wording.	
•	(Mike Nilsson) 5.2.2.2.2, do not understand the last sentence.	# Drop the second sentence.	
21) Section 5.2.2.2.3, the last sentence
The sentence looks incomplete.  Some words are missing? (deleting the words “the complete definition” may be enough ).	# Replace with "protocol stack is defined in Annex X."	
22) Section 5.2.2.2.4, 1st sentence
out-of-band ==> out-band	# out-of-band	
23) Section 5.2.2.2.5, 2nd sentence
Additional VC’s might be required ...  ==> Additional VC’s are required ... {depending on the conclusion regarding AVC-872}	# Agreed.	
24) Section 5.2.2.3, 2nd sentence
The transfer rate capabilities of H.310 terminals are defined at the different service access points within the terminal protocol reference models as explained below. ==> The transfer rate capabilities of H.310 terminals are defined at the AAL-SAP (boundary between the AAL and H.222.1 layers in Figure 2).	# Agreed.	
25) Section 5.2.2.3.1, 3rd paragraph
Reword according to the conclusion of AVC-876.	# Agreed.	
26) Section 5.2.2.3.2
State 

- The rate at the AAL-SAP is converted to the ATM cell rate by taking into account the AAL SAR and CS overheads.
- It should be noted that the ATM cell rate is represented by integer number of cells per sec in the ATM Traffic Descriptor of the Q.2931 message, thus rounding up is required.	# This section was dropped, mentioning the bit rate only at AAL-SAP.	
27) Section 5.2.3.1, 2nd paragraph
The support of user-to-network DSM-CC messages ... ==> The optional support of user-to-network DSM-CC messages ...	# State DSM-CC only in the Scope, drop it from all other places.	
28) Section 5.2.3.2.1, 1st paragraph
The exact set of H.245 messages and procedures to be supported by H.310 terminals is under study and will be outlined in the next version of this Recommendation. ==> The exact set of H.245 messages and procedures to be supported by H.310 terminals is specified in Section 5.6.	# Agreed.	
29) Section 5.2.3.2.1, 2nd paragraph
See the comment to Section 5.2.2.1, Bidirectional Terminals, 1st paragraph	# Same as 17).	
30) Section 5.2.3.2.2
The support of user-to-user DSM-CC messages and ... ==> The optional support of user-to-user DSM-CC messages and 	# Same as 27).	
31) Section 5.2.3.2.3, 2nd paragraph, 1st sentence
The syntax for VFS C&I signals is shown Table 1. ==> The syntax for VFS C&I signals is shown in Table 1	# Agreed.	
32) Section 5.2.3.2.3, 2nd paragraph, 2nd sentence
Reword according to the conclusion of AVC-875.	# Replace it with Nakaya's draft.	
33) Section 5.3, 2nd paragraph
It is important to note, however, that H.245 and DSM-CC messages might be carried in a totally separate ATM channel ... ==> It is important to note, however, that H.245 and DSM-CC messages may be carried in a totally separate ATM channel ...	# Drop DSM-CC.  State separate VC as a normal case, H.222.1 multiplexing is an alternative.  Agreed in spirit.  Fine wording is necessary.	
34) Section 5.3, 4th paragraph
H.310 unidirectional (SOT and ROT) terminals only support the native H.310 communication modes. ==> H.310 unidirectional (SOT and ROT) terminals are required to support only the native H.310 communication modes.	# State the other way around.  H.310 .. are not required to support H.320/H.321 mode.	
35) Section 5.3, last paragraph
H.310 bidirectional terminals (RAST-P and RAST-C) support both ... ==> H.310 bidirectional terminals (RAST-P and RAST-C) shall support both ...	# Agreed.	
36) Section 5.4, H.310 Unidirectional Terminals
Remove the 1st sentence.  {This is redundant}	# Agreed.	
37) Section 5.4, H.310 Bidirectional Terminals, 1st paragraph
For interworking with H.320/H.321 terminals, both H.310 RAST-P and RAST-C terminal types should support the H.320 audiovisual modes shown in Table 2. (See Section 9.) 
==> For interworking with H.320/H.321 terminals, both H.310 RAST-P and RAST-C terminal types shall support the H.320 audiovisual modes shown in Table 2. (See Section 9.)	# Agreed.	
38) Table 2, Audio, O
Remove two "MPEG1 L2".	# Agreed.	
39) Table 2, Note 24
Remove this Editor's note.  {If AVC-874 is agreed.}	# Agreed.
	
40) Table 2, Data, M
Change two "US" ==> "-" {indicating nothing is mandated}	# Remove Data Column.	
41) Table 2, Data, O
- All data protocols are optional.  Indicate T.120 or make it completely open (leave it "US").  
- Remove Note 25 if the above is concluded.	# No problem any more if Data columns disappear.	
42) Table 3, Audio, M
Change two G.711 to MPEG1 L2 if AVC-874 is agreed.	# Retained as it is.	
43) Table 3, Audio, O
Add G.711, remove MPEG1 L1 and MPEG1 L2 from the two rows if AVC-874 is agreed.	# Keep as it is.	
44) Table 3, Data, M
Change two "US" ==> "-" {indicating nothing is mandated}	# Remove the whole data columns.	
45) Table 3, Note 27
Remove this Editor's note.	# Agreed.	
46) Table 4, Data, M
Change two "US" ==> "-" {indicating nothing is mandated}	# Removal of the column.	
47) Tables 2,3 and 4
All the entries “G.DSDV” should be changed to “G.DSVD” {G.729 Annex?}	# State Annex to G.729.	
48) Tables 5 and 6
These tables may give the impression that the communication mode is a component to define the terminal type. For example, a RAST(-P or -C) terminal without H.320/H.321 communication mode seems conformant to this Recommendation. Therefore, the tables need to be rearranged to clarify the deference between terminal types and communication modes.	# Represent like
------------------------------------
		| native
RAST-1	|------------------
		| interworking
------------------------------------
	
49) Table 5, RAST-C (Native H.310 Comm. mode)
Split this into two; RAST-C (AAL-1) and RAST-C (AAL-5) for more clarity?  {See also the discussion in AVC-873}.	# See 48)	
50) Table 5, RAST-C (H.320/H.321 Comm. mode), multimedia multiplex and AAL
Table 5, Footnote 33
Clarify its configuration; see AVC-880.	# Reflect the agreed protocol stacks of RAST-1, RAST-5, RAST-1&5.	
51) Table 5, Transfer Rate, O
US ==> nx64 kbit/s {according to the agreement in Yokosuka, Section 2.8.3/AVC-854R}	# Agreed.
# Remove the second paragraph.
# Other optional rates of nx64 kbit/s (n is an integer from 1 to 65535) can be ... 	
52) Table 5, Footnote 31
Remove this note after the Ipswich meeting.
	# Agreed.	
53) Table 6, RAST-C (H.320/H.321 Comm. mode)
Clarify its configuration; see AVC-880.	# Redraw the table according to the agreed types and their stacks.	
54) Section 8.1
Add the following sentence:
"Several methods of error resilience at the video layer are provided as information in Section D.13 of H.262."	# Agreed.	
55) Section 8.2
Add the following sentence:
"An optional method of error resilience is defined in H.222.1 which employs the use of two ATM virtual connections and the modified and restricted use of Data Partitioning specified in H.262."	# Agreed.	
56) Section 9, Figure 4
- Allocate three networks at the corners of an equilateral triangle.
- Distinguish between terminal and gateway by different boxes.

A revised diagram is as follows.	# Agreed.  Change RAST-P, RAST-C to RAST-1, RAST-5, RAST-1&5.
# State in Scope RAST-5 may not be connected to the public network directly.	
57) Section 9.2. (c)
Clarify its configuration; see AVC-880.	# Footnote 43 ==> Note in the main body: H.221/242 for RAST-5 shall be supported through gateway.	
58) Others
Addition of an appendix as in H.324 which defines the general rule for bit and octet order will be helpful. A proposed text is attached as an annex to this document.	# Agreed to include the appendix. 
# MPEG-2 ==> 11172 audio, 13838 audio	

Annex 6 to AVC-906R

Disposition of comments in AVC-900

Comment	Conclusion	
1. Scope
The actual number of different 'profiles' or types of terminal, and the means of referring to them is confusing throughout the document. Sometimes uni-directional and bi-directional are used, sometimes ROT, SOT and RAST. Then later we have RAST-C and RAST-P. The scope says that there are two classes of uni-directional terminal, ROT and SOT, but later we find AAL1 and AAL5 variants.	
# Agreed.  Redefine terminal type.
# Definition of public network, customer premises network needs improvements.
	
It would be much better if all these different terminals are identified in the scope, given names, and then these names are used later in the specification. When a requirement is placed on more than one of these, it should, whenever practical, be written once, rather than repeated, for example, once for RAST and once for ROT and SOT.	# Agreed.	
Throughout the document there are many footnotes. These often contain vital pieces of information. Readability of the document would be greatly improved if these were included in the main body of the text, and preceded by the word 'NOTE', as is usual in ITU Recommendations.	# Agreed.	
2. References
H.245 is not in the list of references.	# Agreed.	
3. Definitions
Shall, Should and May should either be in a section titled Conventions, as in the editors note and in H.324, or at the front of the document, on the same page as the forward, as in H.245. Despite the presence of this clarification, the word 'must' appears quite frequently: all occurrences of 'must' should be changed to 'shall'.	# Agreed.	
There are no definitions or abbreviations. Necessary ones should be defined: RAST, RAST-P, RAST-C, ROT, SOT, DSM-CC, FR-SSCS, CPCS, VC, etc..	# Agreed.	
4. Applications
Should the text of this section be moved to the scope section?	# Agreed.
	
5. System Description
Almost all of the recommendation has been put in this section. A structure similar to that of H.324 may be beneficial: make a section on functional requirements, with subsections on required elements, signalling, multiplex, video, audio and data; and another section on procedures.	# Text is OK, Footnote 3 is misleading, strike it out.	
5.1 System Configuration
Figure 1 does not show H.242, or H.230, but does show H.221. What is the purpose of this figure, given that the protocol reference model is shown on the next page? Perhaps it should be moved to the scope section, as in H.324, especially as the dotted rectangle, labeled H.310, seems to be indicating scope.	# Agreed. 	
Figure 2 is also missing H.242 feeding into H.221. This diagram has been drawn with a different style to the other diagrams, presumably because it has been imported from another package. Could it be redrawn for consistency of style? The notes following the figure need reconsideration now that they are part of H.310. Reference to the RTI in the text and figure should be removed. Whether these notes are needed should be considered. Perhaps the important points could be written into real text rather than notes to a figure.	# Add H.242/H.230. 
# Notes are corrected and retained.  Essential specifications, if any, should be included in the main text.

#5.5 ==>becomes another section 6
#5.6 ==>part of control channel
	
5.2.1.1 Video Capabilities
Is it necessary to go into detail of what can optionally be supported. Surely anything can be optionally supported? It would be better to say that other profiles and levels can be optionally supported.	# Add a caveat for being not exhaustive list.	
There is a paragraph that says that when a conformance point is supported, that the full parameter range shall be supported. H.245 allows terminals to indicate the capability of features of a profile and level, while only having capability for a reduced set of 'level' parameters. This was done as there is little evidence that the parameters put into H.262 for higher profiles and levels were particularly appropriate. A note should be added to clarify this.	# Agreed.	
As earlier, it should be possible to replace all the text about H.263 with a simple statement that terminals may support H.263, including all of its picture formats and options. This protects H.310 from modifications to H.263, which are not of real interest to H.310.	# Leave the tables as they are.  In the main text simple reference to H.263 is sufficient.	
5.2.1.2 Audio Capabilities
Is the ITU-T G-series, with a short list ended with 'etc.', really an audio coding standard? Later, G.711 is a single recommendation (not recommendations).	# Three ==> The following	
Again, is the list of optional G series recommendations really needed? More useful would be a comment that the optional support of these can be determined using H.245.

The terms MPEG-1 and MPEG-2 should be avoided.	# MPEG-1 audio> 11172 audio , MPEG-2 audio ==> 13818 audio
# Add this terminology in Convention.	
5.2.1.3 Data Capabilities
It is strongly recommended that T.84 and T.434 be removed from the list of data protocols as these are very unlikely to be used, particularly as the later paragraph mandates T.120 support when these might be used.

Again, the list of options is unnecessary, but the first sentence could be kept, with the word 'following' removed.	# Remove bulleted items.	
5.2.2.1 Multimedia Multiplex and Synchronisation
It states that for RAST-C terminals, H.221 must be supported in the terminal or in the gateway. How is this difference signalled? that is, how does the gateway know whether it must perform the H.221 multiplexing?	# Settled (definition of terminal types and their stacks).	
5.2.2.2.1 AAL for H.221/H.222.1 Multiplex Audiovisual signals
The paragraph on AAL5 error detection looks mostly inappropriate. 'the CPCS sublayer must use the length field to detect that the right number of bytes has been received' describes an untestable internal design matter. To what higher layer are errors reported? this IS the system recommendation. The whole of this paragraph (and the next?) could be deleted, as this should be in H.222.1.	# Remove the sentences starting with "In addition ... " in the third paragraph, p.17. 	
AAL1 contains many options. It is important to specify which ones are mandatory for RAST. 'Plain' AAL1 should be mandatory: no SDT, no SRTS, no FEC, and no interleaving. Other modes, such as FEC only and FEC and interleaving, both without SDT and without SRTS, could also be recommended, to aid interoperability, including that with J.82.	# Settled (definition of terminal types and their stacks).	
The text suggests that it is possible to have an AAL1 only RAST-C terminal. Is this right, and if so, how is it determined whether the gateway is needed for AAL conversion?	# Settled (definition of terminal types and their stacks).	
5.2.2.2.2 AAL for Data
T.123 should be referenced for the transport of T.120 data, for both single and separate VC cases. The protocol reference model is just for information, as it contains no detail whatsoever. 	# Agreed.	
5.2.2.2.3 AAL for H.245
Reference should be made to an annex that describes how to do this in detail for the single and separate VC cases. This text was originally in H.245, then H.222.1, and should now be put into H.310.	# Retain only the first sentence. 
# Restore the annex. 	
5.2.3.2.3 Video frame synchronous control and indication signalling
To answer the editor's question, these signals should be supported by ROT and SOT terminals. In particular, freeze picture release is needed to restart after a H.245 freeze picture command.	# Agreed.	
Table 1 is presumably ASN.1 notation. It is necessary to say this, and how it should be encoded. Also, it is incomplete as header and trailer stuff are needed. Look at H.245 to see how this has been done.	# Transplant 3 lines in Section 6/H.245.
# Add reference X.691.	
5.4 H.310 Terminal Types
This text defining the different terminal types would be better placed earlier in the document, for example, in the scope.	# Scope includes pointer to the terminal type definition.
# Definition of terminal type: move it before 5.2
# Tables are included in Section 5.2 in appropriate subsections.	
The purpose of the optional columns of the tables in this section is not clear. Are we saying, for example, that H.261 and H.263 are not even optional in ROT and SOT terminals? Would a SOT terminal that was found capable of H.261 be deemed a non-compliant H.310 terminal? Removing the optional columns would make these tables smaller and more readable.	# Tables include options
# Drop data from the table.
# Main text : indicate that others are optional, negotiated through H.245.	
Section 5.2 describes in words what is in the tables of section 5.4. Surely it is better to have the table right after the text that is relevant to it?

What is footnote 31 referring to?	# Agreed to remove footnote 31.	
Footnote 36 lists possible B-HLI codepoints. Entries include SOT AAL1, SOT AAL5, SOT AAL1 and AAL5. Would it be better to allow a set of these to be listed in the Information Element, so that entries of the third type are not needed, and so that a terminal can indicate RAST and ROT/SOT capabilities?	# Footnote 36 should be generalized to Q.2931 message element not specifying B-HLI.	
Footnote 39 asks whether we should be more specific about selecting modes after the capability exchange. Perhaps too much is stated already: why enforce the highest common mode? In any case, with dependent capabilities, what does highest common mode mean? For example, is H.261 QCIF and G.728 higher or lower than H.261 CIF and G.711?	# highest ==> appropriate mode	
Phase A2 should mandate a capability exchange, by invoking the capability exchange protocol. AVC-877 contains suitable text.	# Refer to Hibi's text in the control channel.	
Should phase A2 mandate the master slave determination? It has been stated that this could be ignored and the calling terminal always become the master (or slave), but this suffers two problems. Firstly, it may not be clear which is the calling terminal in the case of using a PVC connection, and secondly, it may prevent an MCU from choosing whether it wants to be the master of slave. It is therefore recommended that the use of the master slave protocol be mandated.	# Mandate master-slave  determination.	
To answer the editor's question, the choice of communication mode can be made by either the master or the slave. It is only in the case of simultaneous conflicting requests that the master takes precedence.	# Remove 40.  Insert this information (first line ) in phase A4.	
Phase B and phase C descriptions require much more detail. Note that H.324 has a complete section on maintenance loops.	# Refer to Mr. Hibi's text.
# Insert new section on maintenance loop from H.323/4.  Refer to Mr. Hibi's text.
Okubo takes care of this.	
Figure 3 shows call procedures for ROT and SOT. This suggests that logical channels are setup and released using PSI and PSM rather than using the acknowledged procedures of H.245. The Yokosuka meeting agreed that ROT and SOT should use acknowledged rather than unacknowledged procedures.	# Strike out right half of Fig.3. 	
Other issues
There has been some confusion about the bit and byte order of H.245. This was addressed in H.324 by the addition of an informative appendix. This could be modified and included in H.310.	# Agreed.	

END