ITU-T Telecommunication Standardization Sector	Working Document No. APC-1326
STUDY GROUP 16 Contribution	Original: English

__________________________

Sunriver, 08-11 September 1997

Question(s):	3, 12, 13, 14/16
Source:	TELES AG
Contact:	Jörg Ott			Voice:	+49 421 218-2085 / +49 30 314-73389
		jo@teles.de			Fax:	+49 421 218-7000

Title:		Meeting Report on the Second Meeting of IMTC Ad-Hoc Group on Harmonization
		of Conferencing Protocols
Purpose:	Information

Attached is the meeting report of the second meeting of the IMTC Ad-Hoc Group on Harmonization of Conferencing Protocols.

Meeting Report

Second Meeting of IMTC Ad-Hoc Group on Harmonization of Conferencing Protocols
Databeam Corp. - Lexington, KY USA - August 18-20 1997

Contact:	Jörg Ott (TELES AG)
		Voice	+49 421 218-2085 / +49 30 314-73389
		Fax	+49 421 218-7000
		E-Mail	jo@teles.de

0.	Executive Summary of Results

1.	The July proposal for a unified T.120/H.3xx conference control model (”H.UNIFIED”) was recognized as not viable and that continuing development with separate H.245/H.225.0 control for audio and video, and T.120 control for data is the only immediate path forward.

2.	The group recommends that SG16 H.3xx Questions should examine some of the directly applicable T.120 features, such as such as registry, collapsing caps, and the ability to make substantial upgrades to client nodes without automatically requiring upgrades to infrastructure nodes as part of a long-term plan for H.3xx.

3.	The group made specific suggestions (to be reconsidered by Q14/16) for short-term issues on how to harmonize combined T.120/H.3xx conferences within the existing model.

4.	The group believes philosophically that standards without a critical mass of support (even if no opposition) should NOT be approved. Standards which are approved, without broad industry consensus, lead to backward-compatibility issues as needs and issues not previously considered are not covered properly.  Therefore, we propose to SG16 that T.130 should NOT be approved at this time, due to the lack of a positive industry consensus on the need for most of its functions.  This should be reconsidered in the future, when industry feels the need for this functionality.  This philosophy should be applied to other proposed standards which are primarily advocated by a very few companies, and which do not command widespread interest from industry.

5.	SG16 should consider possibly taking Remote Device Control out of the T.130 draft and approving it separately in some form; but this is not seen as highly urgent.

6.	No further meetings of this IMTC Ad-Hoc group are needed.

1.	Opening / Contributions

The meeting opened Monday morning at 9am and was chaired by Jörg Ott of Teles.

The following contributions were identified:

•	Databeam: ”Coordinating T.120 and H.323”

•	Ascend: ”Comments on ‘Meeting Report IMTC Ad-Hoc Group on Harmonization of Conferencing Protocols’ ”

•	Nortel: ”DRAFT for a Rapporteur’s group STUDY GROUP 16  CONTRIBUTION”

•	”Minutes of the last meeting of this IMTC Ad-hoc group”

2.	Revisit the problem definition

The first step in the meeting was to revisit the problem definition that formed the basis for the discussion in Andover and that led to the criticized result of the previous meeting.

It was pointed out that in the entire area of T and H series coordination, two distinct issues can be identified this group may deal with:
•	T.130 vs. H.3xx/H.245: how to include T.130 services in the H-series in order to avoid burdening simple terminals with having to implement a full T.120 environment.
•	T.124 vs. H.245/H.225.0: how to integrate conference control and caps exchange that currently provide to  large degree overlapping functionality in two different places.
Both of these comprise long-term as well as short-term issues.

As starting point for further discussions, Dave Lindbergh gave an overview of the discussion the group had at the July meeting.  In particular, he described the course of the meeting and the motivation for the individual steps taken.  This review included in particular the twelve guiding principles for the discussions held in Andover and the Core as well as the Extended Requirements that resulted from those discussions.

In this context, the Ascend contribution was reviewed.  An overview of the historic development of T.120 was given: according to Ascend, T.120 was meant to provide enhanced conference facilities for H.320 terminals because of the shortcomings of H.230/H.242 BAS signaling; this, however, would not apply to H.3xx systems based on the more powerful control mechanisms of H.245.  Hence, control functionality to be mandated in H.3xx systems should solely be based on H.245 while T.120 mechanisms were applicable only to the data portion of a multimedia conference.

This reflects the philosophical differences in the way the role of T.120 conference control functionality is perceived in the H series and the T series working groups.  As Jeff Bernstein pointed out, in the development of T.120, Q10/8 designed a control protocol (T.124) and a set of application protocols all of which use the same infrastructure for multipoint communication (T.122, T.123, and T.125).  The intent of Q10/8 was that this infrastructure would eventually provide a unified conference control mechanism for audio/video/data multimedia conferences. On the other hand, the H series working groups developing Recommendations for audiovisual communication systems perceived T.120 as an indivisible whole all components of which are applied to data conferencing only.

It was observed that the original intent of the T.120 group seems to be irrelevant now, since the common perception in the marketplace is that T.120 is applied only for data applications.  It was concluded that this perception is unlikely to change for the current (and possibly next) generation of multimedia terminals and hence any further work of the IMTC Ad-Hoc group has to focus on placing commonly required control functions in H.245.

Following this discussion, the five (one through five) possible approaches from the Andover meeting were extended by proposals six and seven:

•	Proposal 1: H.245 only, w/H.243
•	Proposal 2: Mandate T.124/T.132
•	Proposal 3: Do both H.245 (baseline) and T.120 (preferred) IRON RULE: We will not further extend H.245 with respect to conference control functions.
•	Proposal 4: ”H.130”: Replaces H.245 but as T.120 app
•	Proposal 5: H.245 only point-to-point, proxy T.120/T.130
•	Proposal 6: Extend H.245 to include desirable services following the model of T.124 (which was already debated in some discussions in Andover)
•	Proposal 7: Decide on a case by case basis where to put new and to mandate existing functionality using an agreed set of criteria

It was noticed that the IRON RULE stated in the minutes from Andover was worded much stronger than the intention was.

It was decided to pursue proposal 7 to address short term needs, with the option of considering proposal 6 (being orthogonal to proposal 7) for mid-term development of H.245.  With proposal 6, the issue was raised of what the criteria should be, upon which such decisions should be based

These criteria were left unspecified by the group, but vague ideas about potential criteria include:

•	Complexity of a service
•	point-to-point vs. multipoint protocol operation 
	(point-to-point is not necessarily a special case of multipoint since point-to-point protocols are typically much simpler compared to multipoint protocols)
•	centralized vs. decentralized control
•	for existing functions: is it already specified, implemented, and known to work

A concern was raised that whatever the criteria were, people would tend to bend them make everything e.g. simple enough to fit into H.245, just to avoid having to bear the ”burden” of T.124 for simple/point-to-point/central/... operation – which subsequently may require significant extra (duplicated) work to allow complex/multipoint/decentralized/... scenarios to work.

Another issue that was raised: if the same type of service existed in both H.245 and T.120 for potentially different application scenarios (see the above potential criteria), (how) would a hand-over from one protocol to the other take place.  It was suggested and finally accepted that this is not an issue of standardization and that there should be no relationship between the two solutions.  Rather, either implementations or the user herself had to deal with such problems.

The result from Andover to mandate that all calls / conferences lead with H.323 was confirmed in this meeting.

For this meeting (as well as the future) the group decided to deal with the conference control harmonization issues as follows:

Short-term
The group decided that it had to sort out the short-term issues as identified in the Andover meeting.  An additional item to consider is how to run T.130 in a terminal without requiring the T.120 infrastructure.

Long-term
It was decided to redefine the ”iron rule” to meet proposal 7: new functions / services will be examined on a case by case and identify where they do belong (T.120/T.130 vs. H.245).  It should be allowed only in rare cases to put them into both places.

Organization
The group decided that for better future coordination, rather than having an ”external” coordination body, work on all the protocols / services relevant to audiovisual and conference control should be moved into a single place (e.g. Q14/16).  As a consequence, the IMTC Ad-Hoc group will dissolve itself and not meet again.

3.	Short-term Issues

The list of short-term issues captured at the previous meeting of the Ad-Hoc group was reviewed.  As seventh issue, running T.130 purely based upon H.245 was added (Ascend contribution).  The assumption is that remote camera control (or in general: remote device control) is of primary interest; no further services of immediate importance were identified.

The review of the issues (see attachment III) revealed that consensus is found among the members of the group about how to deal with all issues except for #2.  Issues #1, #3, #4, #5, and #6 require immediate further actions to be taken by individual companies for the Sunriver meeting, and the respective work items were assigned.

In this context, the Databeam contribution was reviewed.  This contribution addresses issues #1, #5, and parts of #4 and #6 and Databeam will re-submit the contribution to the Q3/16 Rapporteur’s meeting in Sunriver to fully address these issues.

No consensus could be reached about Issue #2.  The alternatives discussed include:

•	extending Appendix I of T.124 to cover all H.32x systems rather than only H.320.
•	disallowing the use of weak password mechanisms entirely since they provide no security, particularly in the Internet environment H.323 may be used in.

The group concluded that this issue should be raised at the Sunriver meeting in September and that contributions on solving this issue are solicited.  In Sunriver, a joint meeting of Q3 and Q14 experts should be able to find a satisfying solution.

With respect to issue #3, TELES will provide a contribution to the Sunriver Rapporteur’s meeting extending Appendix I of T.124 to cover all H.245-based terminals in addition to H.320 terminals.

Issue #4 is resolved by the Databeam contribution as a harmonization issue between T.120 and H.323.  However, the issue of finding out about on-going conferences remains as a pure H.323 problem.  This was considered to be beyond the scope of this Ad-Hoc group, and hence no further actions were deemed necessary.  It was noted that at the Hertzliya meeting, a contribution on such a conference query mechanism was presented but rejected by the standards group. The contributors as well as Q12, Q13, and Q14 are encouraged re-investigate the possible solutions to this problem.

The discussion of issue #7 led to the conclusion that it is unclear whether the T.130 services as defined will eventually be accepted by the industry.  Hence, it was deemed premature to work out the technical details (which would require significant effort).  Also, it was found that the demand for such services (from industry) has only been guessed but not been proven so far.  Finally, the expertise for carrying out this task was clearly not present at the meeting of the Ad-Hoc group.

The conclusion was that – within the organizational setting of Q14/16, potentially dealing with all conference and audiovisual control issues – Q14/16 would be the place for achieving feasible and commonly accepted results, rather than this Ad-Hoc group.  Hence, Q14/16 is encouraged to take on this role and to develop the necessary (extensions/modifications to existing) Recommendations for audiovisual control in teleconferences as soon as this need is perceived by the industry.

The resulting issues list with the proposed solutions and all the necessary actions to be taken is enclosed as Attachment III.

4.	Long-term Issues

The meeting was focused on addressing short-term needs and hence the long-term issues were considered only at a very high level – by outlining general directions rather than performing detailed technical work.

As stated repeatedly, a T.120-based solution is not viable in the immediate future because of the perceived complexity.  Hence, no further work is undertaken in this direction, and the corresponding result from Andover is discarded.

The group believes philosophically that standards without a critical mass of support (even if no opposition) should NOT be approved, as one day industry may need such a function.  In that case the group does not want backward-compatibility issues to arise and does not want industry to be burdened with a possibly broken solution.  For the T.130 Recommendations on audiovisual control, the IMTC Ad-Hoc group does not see enough demand from the industry and nor the willingness to buy into such a complex solution – both of which is reflected in a clear lack of interest and active participation in the standardization process.  Therefore, the IMTC Ad-Hoc group proposes to SG16 that T.130 should NOT be approved at this time, due to the lack of a positive industry consensus on the need for most of its functions.  This should be reconsidered in the future, when industry feels the need for this functionality.  This philosophy should be applied to other proposed standards which are primarily advocated by a very few firms, and which do not command widespread interest from industry.
  As already mentioned in section 2, the group has chosen the procedural process to address further harmonization issues in the future (solution three of agenda item 4.c): the responsibility should lie within the ITU-T and Q14/16 seems to be the appropriate group to address these issues.

It was also pointed out that with the current pace of the standardization process, a very large number of standards have been produced in a very short time frame (the last two to three years) and that implementations of actual products have a hard time keeping up with that pace.  In order to keep standards close to real industry and customer needs, it was concluded that standardization efforts in the near future should focus on cleaning up and solidifying existing standards rather than addressing new fields.

For the long-term development of H.245, the IMTC Ad-Hoc group sees benefits in adding concepts from T.124.  Potentially desirable revisions and extensions may include:
•	Providing application-independent capability exchange mechanisms with generic collapsing rules to allow keeping terminals (and gateways) independent of the infrastructure components (such as MCs), e.g. for the deployment of new features.
•	Definition of registry and arbitration mechanisms as defined in T.124.
•	This may optionally mean to consider a concept of T.120-style Application Protocol Entities for H.245 where H.245 only provides the mechanisms but has no knowledge of audio or video capabilities at all.
However, the group felt that this makes the design of H.245 more complex and – as with T.120 – incurs an acceptance barrier, since implementation would have to migrate in the long run to benefit from the new concepts.  Like T.130, pursuing this approach is considered premature for the time being, but participants are encouraged to think about those issues.

5.	Draft output report as contribution to upcoming SG16 Question meetings.

There will be no single common contribution as an outcome from this meeting.  However, preparation of two company contributions is solicited:
•	Databeam is to rewrite its contribution on short-term issues to cover the agreements reached during the meeting
•	TELES is to prepare a contribution on T.124 Appendix I to cover issue #3 of the short term list.
Both contributions will be circulated to give other companies the opportunity to support a contribution thus turning it into a multi-company contribution.

6.	Adjourn

The meeting was adjourned at noon of 20 August 1997. 

As stated before, this IMTC Ad-Hoc group is dissolved hereby and will not meet again.

7.	Attachments

Attachment I:	Meeting Agenda
Attachment II:	Participant List
Attachment III: 	Short term issues, solutions, and assigned work items

Attachment I: Meeting Agenda
Agenda

Second Meeting of IMTC Ad-Hoc Group on Harmonization of Conferencing Protocols
DataBeam Corp. - Lexington, KY USA - August 18-20 1997

The meeting will start at 9am each morning, unless adjusted during the meeting.

Meeting Agenda:

1. 	Preliminaries
a. 	Host welcome; meeting logistics
b. 	Attendee introductions
c. 	Pass around attendance list
d. 	Review and approval of agenda

2. 	Revisit the problem definition 

3.	Short-Term Issues
a. 	Review of short-term issues captured at previous meeting (attached)
b. 	Correct and add to list as needed
c. 	Propose solutions to issues listed or assign work items
(this includes writing up a solution for remote device control based on H.323)

4. 	Discussion of Long-Term Issues
a. 	Review response at Redmond Q3/16 meeting to our July meeting report
b. 	Revisit July conclusions: Is there really a problem?   Is there:
•	Potential future duplication of functionality?
•	Confusion re H-vs.-T conflicts?  Re terminology?
•	Need to rev network infrastructure to support new services?
•	Other?
c. 	Propose approach to deal with long-term issues, if any.  Possible solutions:
•	Solution 1: Ignore issues; allow whatever happens to happen
•	Solution 2: Set an architecture to define future path
•	Solution 3: Define procedural process to address problems
•	Other possible solutions?

5. 	Draft output report as contribution to upcoming SG16 Q meetings.

Attachment II: Participant List

Name	Company	E-Mail	Phone	
Pat Galvin	DataBeam	pgalvin@databeam.com	+1 704 324 4711	
Brian Pulito	DataBeam	bpulito@databeam.com	+1 606 245 3564	
Bill Quinn	DataBeam	bquinn@databeam.com	+1 606 425 3695	
Neil Starkey	DataBeam	nstarkey@databeam.com	+1 606 425 3503
Fax: +1 606 425 3528	
John D’Alicandro	Delta Information Systems	jpd@delta-info.com	+1 215 657 5270 x40	
Greg Kisor	Intel	gkisor@ibeam.intel.com	+1 503 264 9324	
Andy Franklin	Lucent Technologies	adfranklin@lucent.com	+1 303 538 4071	
Tom Taylor	Northern Telecom (Nortel)	taylor@nortel.com	+1 613 765 4167	
Jeff Bernstein	PictureTel	jeff@pictel.com	+1 508 623 4349	
Mark Duckworth	PictureTel	duckworthm@pictel.com	+1 508 623 4484	
Dave Lindbergh	PictureTel	lindbergh@pictel.com	+1 508 623 4351
Fax: +1 508 749 2804	
Markku Korpi	Siemens	korpim@sbs.de	+49 89 722 34570
Fax: +49 89 722 23977	
Don Piercy	Starvision	dpiercy@starvision.com	+1 604 205 5504	
Jörg Ott	Teles AG	jo@teles.de	+49 421 218 2085
Fax: +49 421 218-7000	
Glenn Stewart	VideoServer	Gstewart@videoserver.com	+1 617 505 2204	

Attachment III: Short-term Issues List
(”proposed solutions” are from our July meeting – to be revisited!)

1.	Issue: There are two ways to start a data-only conference that are not interoperable.  How should these be harmonized?
Detail: For establishing a connection in which only T.120 data applications are to be used (at least initially), there are multiple incompatible methods.  On each network type (POTS, ISDN, LAN, ATM) there are two ways defined – H.3xx and T.120-only.  Since there is no mandate to support both methods (although H.323 does suggest doing so), devices supporting only one method will not interoperate with devices supporting only the other.  Additionally, if a call was started using T.120-only, there is no clearly defined procedure for switching to H.3xx in order to add audio and/or video to the call.
Proposed Solution: All calls should lead with H.3xx even if they are data-only (H.3xx)
•	Describe what legacy is, and state that leading with H.323 is the way to go!
•	Put into T.120
•	Allow 1503 as well as dynamic ports for the OpenLogicalChannel (H.323 only).
•	Put into H.323
•	Follow the Databeam proposal (H.323 only).
•	Put into H.323
•	Session ID #3 should be the default for the T.120 data session (H.323 only).
•	Put into H.323
•	There shall be only one T.120 conference per H.3xx conference (H.3xx).
•	Put into T.120
Assigned work item: parts of Databeam proposal to be extended (Databeam).
2.	Issue: There are two mechanisms for entering passwords when joining a meet-me conference.  How should they be harmonized?
Detail: H.243/H.245 and T.124 both provide mechanisms for password entry for joining meet-me conferences.  Without clarification, it may be ambiguous how an MCU determines which password mechanism to use (or whether to use one or both), and how a terminal should respond to each.  It is possible that misinterpretation of this could result in, for example, the inability to enter a password due to a mismatch between the protocol supported in the MCU and the protocol supported in the terminal, or a user being prompted twice to enter a password into a conference (and not necessarily knowing whether the passwords should be the same or different, or which is which).
Proposed Solution: Use T.124 Appendix I (”Relationship of T.120 to H.243 in H.320 Conferences”) and extend the principles there to cover all network cases, including H.323, H.324, and H.310.
•	The following rules should be applied for all kinds of H.3xx systems (including H.320!).
•	Modify the Appendix of T.124 accordingly.
•	Add a note: The simple password mechanisms of H.245 and T.124 don’t provide real security.
•	Add this to the appropriate documents related H.245 as well as T.124.
•	If you have already entered one password and are subsequently asked for a second one, the local user interface may attempt to re-use the first password automatically.  If the authentication fails for the second step, a different password is required (and the user needs to be prompted for the second password).

As an MCU, you may choose to ask for just one password and apply this to both audiovisual and data parts of the conference .
This requires an implementor’s note that at least a second try for providing any of the  passwords 
•	Affects T.124, H.245, and H.243
There is no consensus among the parties that this is the right approach.
Contributions are solicited for Sunriver (which may propose alternative solutions to the problem).
Joint meeting of Q.14 and Q.3 in Sunriver is considered the appropriate place to sort out the details.
•	If H.235 authentication is used, recommend not to use the H.245 password scheme.
Use of T.124 authentication with the Top GCC Provider requires further study.  This is
to be addressed by the group working jointly on T.120 and H.3xx security.
•	Contributions are solicited for the Sunriver meeting to sort out the details.

3.	Issue: How can you tell if an H.3xx device and a T.120 device are co-resident (in addressing terms)?
Detail: H.243/H.245 and T.124 both provide mechanisms for identifying a far-end device via an address (Terminal Number in the case of H.243/H.245, and Node ID in the case of T.124).  For a device that implements both protocols, there is, in general, no well-defined means to determine whether a particular Terminal Number corresponds to the same device as a Node ID.  This is useful, for example, in determining the complete roster of devices in a conference (where the roster is the union of the list of H.243/H.245 devices and T.120 devices – but without incorrectly duplicating nodes which support both protocols).  As an additional example, this would be useful in something like highlighting the T.128 shared application windows corresponding to the current video broadcaster.
Proposed Solution: Use T.124 Appendix I (”Relationship of T.120 to H.243 in H.320 Conferences”), description of AlternativeNodeID field usage, and extend the principles there to cover all network cases, including H.323, H.324, and H.310.
•	Follow the proposed solution.
•	No terminal label is available in the point-to-point case; doesn’t matter as T.120 roster contains only one other site. 
•	Should be added to the Appendix of T.124
Work item: provide the extensions to T.124 Appendix I (TELES).

4.	Issue: How should H.225.0 ConferenceGoal be used in cases where the caller doesn’t know its intent until after the T.124 exchange?
Detail: On connection establishment, the ConferenceGoal parameter must be filled in with either ‘create’, ‘join’, or ‘invite’.  In the case of ad-hoc conferences, the rules for using these parameters are made clear in H.323.  However, there are cases where the calling device may not know its intent until after determining the nature of the device that it called.  For example, upon T.124 Query (which must occur after the H.225.0 establishment), a caller may determine that the called site is an MCU with conferences available to join, or that the MCU that wishes to invite it into an existing conference, or that the called site is a terminal to which it should automatically connect.  If the calling site does not know a priori the nature of the device being called, it is not clearly defined which value of ConferenceGoal should be used.
If one of the existing ConferenceGoal values is chosen as a default to cover this case, it must also be possible for the called site to unambiguously determine what action to take when the ConferenceGoal is received (e.g., if ‘create’ is the default, does reception of ‘create’ mean that the caller wishes a new conference to be created or that the caller doesn’t know what it wants to do yet).
Alternatives:
•	Following the Databeam proposal resolves this as a harmonization issue.
•	However, a pure H.323 issue remains: In the absence of a-priori knowledge, where does a caller know from which conference goal to specify?
•	A-priori knowledge may be gained via arbitrary mechanisms one of which should be explicitly allowed: a separate T.124 query independent of the H.323 conference?  To which address?
•	What are the issues to be addressed:
1.	Find a list of conferences from an MCU (if you already know that you are calling an MCU).
2.	Define an unambiguous way to find out whether to join or create conference on a called system without having a-priori information about the remote system or the conference.
•	pure H.323 issues, don’t address them here
Work item: none for this group (besides mentioning the above in this report).
5.	Issue: The relationship between the rules for establishing T.120 connections in H.323 and the rules defined in T.124 should be clarified.
Detail: H.323 states that ”The winner of the H.245 master/slave determination process shall have the option of being the upper node in the T.120 connection.”  It is not clear by what procedure this option is to be exercised.  Presumably this does not mean that the master should take on the role of ‘caller’ in the T.124 sense, but rather it should use its declaration in the T.124 Query to influence the result.  If so, this should be made clear.  It should also be made clear how the T.124 ‘caller’ is determined when used in H.323 (presumably it is the H.323 call initiator).
The specific recommendation in H.323 on how the master can control who will become the Top Provider results in a problem.  That recommendation says ”if an endpoint is the Active MC of a conference which includes T.120, and it wishes to become the T.120 top provider (e.g. the Data MP), it should declare itself to be a T.120 MCU…”  In the case of a terminal making an ad-hoc call to another terminal, if the called terminal becomes the Active MC, and wishes to be the Data MP, by the rule above it should declare itself a T.120 MCU.  However, by the rules in T.124, the caller may interpret this as an indication to prompt the user to select a conference to join.  In the case of an ad-hoc call, this behavior would be inappropriate.  However, if the called site were indeed an MCU, this behavior would be appropriate.  Unfortunately the indications from the called site are identical in either case so the caller cannot distinguish between the two.
•	change the questionable text in H.323 along the lines of the Databeam proposal
•	keep master/slave in parallel to T.120 topology
•	specific changes to H.323
Work item: is covered by the Databeam proposal addressing issue #1.
6.	Issue: The meaning of each level of disconnect (physical, H.245, T.120, …) needs clarification.
Detail: Some particular points of ambiguity are:
•	On T.120 disconnect, in an H.3xx call, does this imply disconnecting only the data applications and T.120 stack, or does it imply that the entire H.3xx connection is to be disconnected?

•	With the idea of H.3xx taking the lead, bringing down T.120 does only affect the data part of the conference; H.3xx remains unaffected.
•	T.124 (clean up the current statements about physical connections to be more explicit)
•	Repeat the same statement in H.323
(don’t take any actions right now for the other H.3xx)
•	How does bringing down an H.323 connection affect a correlated T.120 connection?

•	Bringing down the Logical Channel in which T.120 is run / with which T.120 is associated, implies termination of the T.120 connection.
•	H.323 specific (obvious in the other cases)

Work item: will be included in the Databeam proposal.
•	On T.120 or H.3xx disconnect, does this imply that the physical connection is to be disconnected (in the case of switched networks), or should physical disconnection be done separately to allow, for example, a terminal to disconnect from one conference on an MCU and attempt to join another without reestablishing the physical connection?

•	We do not address the issue of when the physical connection has to be brought down.  However, it is noted that experts dealing with H.3xx matters should tackle this problem.

Work item: none in this group.

Agreed procedures for getting the results of this meeting into the standards process:

•	prepare individual contributions that are ”signed” by those supporting them
•	contributions will be discussed in Sunriver in the relevant Rapporteur’s groups
•	contributions shall contain replacement / additional text ready to go into the standards
•	eventually, agreed changes will be put forward as Rapporteur’s contributions to the working party meeting
•	 

7.	Issue: How to provide T.130 (camera control, any others?) functionality?

•	Follow the procedural approach and move T.130 (along with T.124) into Q14/16.
•	Within this group, the need for T.130 functionality was not perceived sufficiently urgent to undertake the necessary efforts to start specification of a subset of existing T.130 over H.245 as a contribution for Sunriver.
•	There may be support for taking Remote Device Control out of the T.130 drafts  and approving it separately in some form; but even this is not seen as highly urgent.
•	We encourage those experts with particular interest in audiovisual control aspects to pursue this work within the appropriate Rapporteur groups.
•	We do suggest that Q14/16 be the place where this work shall be carried out.