ITU Telecommunication Standardization Sector	Document AVC-1001
Study Group 15	Version 1
Q.2&3/15 Rapporteur Meeting	17 September, 1996
Eibsee, 24-27 September 1996

SOURCE	:	BT
TITLE 	:	DSM-CC / T.120 Coordination Group Status Report
PURPOSE	:	For Information

Background 
Both DSM-CC and T.120 provide session management functionality and are gaining increasing acceptance within industry for interactive multimedia retrieval services (IMRS) and conferencing services, respectively. One such industry forum, the Digital Audio-Visual Council (DAVIC), has produced a specification which adopts DSM-CC for IMRS. Future releases of DAVIC specifications plan to include conversational services and consequently may consider the use of the ITU-T T.120 series Recommendations. It is therefore essential that the roles of DSM-CC and T.120 are fully understood. Furthermore, as both standards impact on terminal design, it seems sensible to try and achieve rationalisation of the terminal functions covered by both standards.

In February 1996 a BT initiative was taken to form an ad-hoc steering group, known as the DSM-CC/T.120 Coordination Group (DTCG), whose prime objective was to coordinate technical solutions for the integration of DSM-CC and T.120 environments (see Appendix 1).

Progress
Since February, the DTCG has held a number of audioconferences and meetings within ITU-T SG8/Q10 to progress the integration work. ITU-T SG8/Q10 has now effectively taken on the role of resolving the various technical issues impacting on DSM-CC/T.120 integration, along with the assistance of the ISO/IEC MPEG/DSM-CC group and the DTCG.

The initial focus of the DTCG work has been to coordinate the drafting of the relevant standards to allow DSM-CC compliant terminals to participate in T.120/T.130 audio-visual conferences. Major progress has been made by the DTCG since February (see Appendix 2), namely:
1.	The DTCG responded to the request for comments on DSM-CC DIS, asking for support for ‘server initiated transactions’ which was subsequently incorporated in the DSM-CC IS.
2.	The DTCG assisted SG8/Q10 create an initial draft for T.130 Annex A (see Appendix 3).
3.	The DTCG coordinated the production of a contribution on draft text for DAVIC’s CFP6 on Communicative Services.

Future Work
The DTCG will continue to fulfill its original objectives with the cooperation of ITU-T SG8/Q10 and ISO/IEC MPEG/DSM-CC. Plans are in hand, working within the framework of T.130, to support access of DSM-CC managed retrieval services by T.130 compliant terminals. A key aim of the DTCG is to assist DAVIC and the IMTC in specifying standards based interoperable solutions for interactive multimedia services.

Appendix 1: DTCG Meeting Report (February 1996)
Appendix 2: DTCG Meeting Report (August 1996)
Appendix 3: T.130 Annex A Draft: Integration of DSM-CC & T.120 (COM8 - WD-29Rev., August 1996)

DTCG Meeting Report (February 1996)

Distribution:	See Annex A

Source:	DSM-CC/T.120 Coordination Group

Contact:	David O. Beaumont
		Centre for Human Communications
		pp B62 - 4/17A
		BT Laboratories
		Ipswich, IP5 7RE
		UK

		E-mail:	Dave.Beaumont@bt-sys.bt.co.uk
		Tel:		+44 1473 642888
		Fax:		+44 1473 643791

Introduction
On 26-27 February 1996, at the invitation and initiative of BT, an ad-hoc coordination meeting between individual experts of ISO/IEC MPEG/DSM-CC and ITU-T T.120 was held in Ipswich, UK (an attendance list is shown in Annex B). 

The objective of the meeting was to:
1) Identify if inter-working between DSM-CC and T.120 environments is possible and if the possibility exists then...
2) Map out a way forward
3) Identify who should do the work.

Background
Both DSM-CC and T.120 provide session management functionality and are gaining increasing acceptance within industry for interactive multimedia retrieval services (IMRS) and conferencing services, respectively. One such industry forum, the Digital Audio-Visual Council (DAVIC), has produced a specification which adopts DSM-CC for IMRS. Future releases of DAVIC specifications plan to include conversational services and consequently may consider the use of the ITU-T T.120 series Recommendations. It is therefore essential that the roles of DSM-CC and T.120 are fully understood. Futhermore, as both standards impact on terminal design, it seems sensible to try and achieve rationalisation of the terminal functions covered by both standards.

General Conclusions
The consensus of the group was that convergence of functionality between DSM-CC and T.120 is possible.

1.	There are numerous scenarios where mixed conferencing (T.120) and interactive video services (DSM-CC) are desirable.
2.	Initial proposals will be done by the experts in both DSM-CC (ISO/IEC JTC1/SC29/WG11) and T.120 (ITU-T Q10/8). Detailed work on enhancements to DSM-CC and T.120 will be carried out in the respective standards bodies. There is no intention to start another standards initiative, but to act as an enabler to achieve convergence within the existing standards bodies.
2. 	There is significant value that can be achieved by having T.120/DSM-CC protocol aware terminals that are using both standards unchanged.
3. 	It is desirable to work towards alignment/enhancement of functional capabilities of T.120 real-time services extensions (T.130) and DSM-CC to improve mapping between the two standards.
4. 	All work will be open to examination by any interested party.

Technical Conclusions
1.	The T.120/DSM-CC aware terminals would have an application that reconciles T.130/DSM-CC common functions.
3. 	Must reconcile interface or protocol name spaces.
4. 	Descriptors or other syntax may need to be added to DSM-CC to meet the needs of T.120.
5. 	DSM-CC download could be used to enable a DSM-CC node for T.120.
6. 	A combination of standard T.120 facilities (MBFT, Invoke, Registry) can be used to deliver DSM-CC capabilities to a T.120 node.
7. 	T.120 should be capable of operating over a DSM-CC established link (possibly extend T.123).
8. 	DSM-CC should be capable of operating over a T.120 transport (video streams out‑of-band to T.123).
9. 	Tighter integration of DSM-CC and T.130 is possible and desirable.
10. 	Integration and interworking should be investigated between DSM-CC Servers and T.120/H.320 Multipoint Communication Units (MCUs).
Work Items
1.	We suggest that the short term process be to create informative guidelines for both standards which suggests how inter-operation to its counterpart is feasible. The expectation is that these guidelines will present: (a) a reference model, (b) a terminology section which defines a common volcabulary, (c) a section which lists each standard’s components and their counterparts, and (d) the specifics for how to inter-operate from one standard to the other.
2.	Identify where enhancements to the existing protocols would facilitate interoperability. The desired process will be to forward recommendations of these enhancements to their respective standards bodies. This includes the following recommendations:
•	DSM-CC group to investigate additional resource descriptors to meet the needs of T.120.
•	T.120 group to investigate additional profiles to support the intended underlying networks of DSM-CC.
•	Investigate enhancements to DSM-CC U-U to enable shared services.
•	Investigate enhancements to T.120 interfaces to present an IDL interface to the services.
3.	Provisional date for first output to be presented and discussed at the ITU-T Q10/8 rapporteur meeting in Boston (week 22-26 April).

Annex A - Distribution List
Leonardo Chiariglione
Convenor of ISO/IEC JTC1 SC29 WG11 (MPEG)
	
Bruce DeGrasse
Rapporteur for ITU-T Q10/8 (T.120)
	
Sakae Okubo
Rapporteur for ITU-T Q2/15 (Experts group for video coding & systems in ATM & other network environments)
	
Jules Bellisio
Chairman of DAVIC
	
Neil Starkey
President of IMTC
	
George Dobrowski
Chairman of ATM Forum Technical Committee

DTCG Meeting Report (August 1996)

This coordination activity was based on work within the DTCG and ITU-T SG8/Q10 at the SG8/Q10 meeting in Santa Rosa, CA, USA on 6-9 August 1996, and included an audioconference with Nortel delegates.

Objectives:
The overall objective was to keep SG8 (T.120) informed on developments for the coordination and integration of T.120 and DSM-CC. The key objectives were:
1) Review progress within DSM-CC to comply with SG8 liaison (Boston: April)
2) Review SG8/Q10 T120C-WD 29
3) Actions for DAVIC
4) Future actions for DTCG

Progress
1) Review of DSM-CC
- As a result of SG8's Boston meeting (April), a liaison was sent to DSM-CC requesting clarification on aspects of DSM-CC and the need for support for "server initiated transactions".
- A subsequent DTCG audioconferences were held to clarify its response (via companies or national bodies) to the DSM-CC DIS.
- The DSM-CC adhoc editing meeting (June) accepted the DTCG requirement and edited the DSM-CC IS accordingly.
- DSM-CC's reply was reviewed and it was agreed that SG8 needed to request the allocation of  Resource Ids in DSM-CC for T.120 communication.
- It was agreed to send a liaison to the DSM-CC group thanking it for its assistance and formally requesting the allocation of 2 Resource Ids: T120RequestForCommunication and T120ReadyToCommunicate.
- Dave Beaumont agreed to deliver a draft of the liaison to Chris Adams (Chairman of DSM-CC) on Friday 9 August, prior to the formal liaison being sent.

2) Reviewed WD 29
- WD 29 (ITU-T SG8/Q10 August) covered various conferencing scenarios for T.120 support using DSM-CC compliant terminals.
- It was agreed that this document was very useful and an enhanced version would be useful input to DAVIC for Communicative Services.

3) Actions for DAVIC
- A number of companies had planned to put forward candidate text for the release of DAVIC CFP6 due in September.
- The main CFP6 topics of interest were: Communicative Services and Multiplayer Games.
- It was agreed that an audioconference would be held on 19 August to discuss possible text for DAVIC's CFP6.

4)  Future actions for DTCG
- DSM-CC support for T.120 compliant terminals (i.e. retrieval services) are to be covered by T.130
- Investigate the most time efficient methods for downloading T.120 code and initiate a comms. link.

AOB
- The next meeting of DSM-CC is at Foz de Iguacu, Brazil on 18-22 Nov. 1996
- Two activities are continuing in DSM-CC: Conformance Testing (Leader - Tim Addington [SA]) and an ad hoc group on DSM-CC extensions (Vahe Balabanian [Nortel])
- DVB have adopted DSM-CC U-U and part of U-N.

- Next meeting of ITU-T SG8/Q1 is in Germany in September, where Greg Kisor [Intel] will brief SG8/Q10 on the output from DAVIC and CFP6 Text.

ITU Telecommunication
Standardisation Sector
(ITU-T)
Period: 1993-1996		COM 8-WD-29Rev
August1996
Original: English
18 September, 1996	
Santa Rosa 5-9 August 1996
Question:  10/8
STUDY GROUP 8 – CONTRIBUTION
SOURCE:	Q10/8 rapporteur	
CONTACT:	Trevor Peers,
BT Labs,
Martlesham Heath,
IPSWICH,
Suffolk,
UK IP5 7RE.
Nancy Greene
Nortel
P.O. Box 3511 Station C
Ottawa, ON K1Y 4H7
CANADA 
	Tel: +44 1473 647697
Fax: +44 1473 643791
E-Mail: peers_t_w@bt-web.bt.co.uk

Tel: +613 763 9789
Fax: +613 763 8904
E-Mail: ngreene@nortel.ca	
TITLE:	T.130 Annex A Draft Revision 1: Integration of DSM-CC & T.120	

T.130 Annex A Draft: Integration of DSM-CC & T.120	
 Rationale

The DSM-CC and T.120 specifications evolved in answer to specific services, interactive television video on demand in the case of the former and multimedia conferencing in the case of the latter.  Both specifications have common functions as well as dedicated functions.  Since the target of both specifications is the user terminal (a set top box or a workstation) this annex provides a number of conference scenarios that work towards integrating the common functions of both DSM-CC and T.120 to the largest extent possible and increasing the services available to the user by pooling the features, functions and services of each specification. See also Chapter 12 and Annex M of the DSM-CC International Standard [1].
 Initial Conditions for a DSM-CC Terminal

Initial conditions assumed for each DSM-CC terminal are as stated in DSM-CC Section 5.7.1 [1], and are summarized here:
1.	Lower layer Network stacks are present
2.	The DSM-CC terminal has a globally unique clientId (20 octet ISO NSAP address).
3.	The DSM-CC terminal contains Service location information, i.e. the serverId to reach the Service Domain for conference information (This may be passed to a terminal in a DSM-CC U-N PassThruReceipt message).
4.	The DSM-CC terminal contains a compatibilityDescriptor that distinguishes the Client profile ( system hardware and software descriptors, and descriptors for the network protocols the Client supports). This descriptor can identify the protocol to be used for Download, or the DSM-CC Section 7 Download can be used.
5.	DSM-CC User-Network Session Protocol and Download Protocols are present, as well as transaction timeout values for each of these protocols, are present.
6.	DSM-CC User-User Session local object and Download local object are present.
7.	A DSM-CC Main Resident Application is running and knows how to respond to DSM-CC PassThruReceipt and PassThru messages.
 Conference SCENARIOS
In this section the following Conference Scenarios for DSM-CC Terminals are presented:
•	Meet-Me Conference Scenario, where a Terminal uses a DSM-CC Conference Server to find out conference information.
•	Browsing for a Conference Scenario, where a DSM-CC Conference Server application provides a directory of conferences any user may join. Once the user selects a conference, the required T.120 code is automatically downloaded to the Terminal.
•	Dial-Out Conference Scenario where a Conference Server asks each potential conference participant whether it is available to join a T.120 conference, and if so, requests the Terminal to download the T.120 code, and gives the Terminal the required conference information to join the conference.
•	Server-aided Point-to-Point Conference, where each Terminal sets up a DSM-CC session with a Conference Server. The Conference Server then adds DSM-CC connection resources for T.120 use, with the endpoints of each connection marked as being the two terminals in the point-to-point conference. [NOTE: This requires the definition of a new DSM-CC resource descriptor that allows a resource to be part of two sessions. ISO/IEC will put in place a procedure to define new resource descriptors on an as-needed basis.]
•	Direct Point-to-Point Conference, where the Calling Terminal initiates the DSM-CC session directly with the Called Terminal. The Called Terminal thus requires DSM-CC “Server” code in order to be able to add DSM-CC connection resources for T.120 use to the DSM-CC session set up between the two Terminals.
 T.120/ DSM-CC General Model and Definitions

FIGURE 1/T.130 General Model for T.120 and DSM-CC Services
 Definitions
Conference Server	A Conference Server contains information on reserved Meet-Me conferences, and on conferences in progress that a terminal may join. For Dial Out conferences, the Conference Server is the one that issues the DSM-CC PassThruReceipt messages to Terminals prompting them to set up a DSM-CC session and then join the Dial Out conference. For the Direct Point-to-Point Conference Scenario, the Conference Server may initiate a connection between two terminals.	
DSM-CC “Server” Code	DSM-CC code required for a Terminal to respond to a DSM-CC SessionSetupIndication, and for a Terminal to add/delete DSM-CC resources to/from a DSM-CC session. This is a subset of the DSM-CC code normally associated with a DSM-CC Server.	
MCU Server	The MCU Server provides T.120 Conferencing Services to Terminals. It does not need to have any knowledge of DSM-CC. 
The MCU Server may also provide a bridge at the T.120 level to other T.120 MCUs outside of this Service Domain.	
Service Domain	A Terminal can be connected to any Server in a Service Domain through the addition of DSM-CC resources to an existing DSM-CC session within that Service Domain. There is no need to initiate a new DSM-CC session when a Terminal moves from one Server to another within a Service Domain.
A Terminal does not belong to a particular Service Domain - there is no restriction on which Service Domain a Client can be connected to.	
T.120 Code	T.120 code required for a Terminal to create/join a T.120 conference	
Terminal	A DSM-CC Client, such as a set top box, that, with the appropriate code, is capable of participating in a T.120 conference.	
White Pages Server	This Server provides a Terminal with the address of other Terminals. It is accessed when one Terminal wishes to establish a point-to-point conference with another Terminal (used for both the Server-aided and Direct Point-to-Point Conference Scenarios)	
 Meet Me Conference Scenario for DSM-CC Terminals
The Meet Me Conference scenario sets up a three-party conference between an MCU and two Terminals. Meet Me conference information is first retrieved by the Terminals from the Conference Server. 

No change would be required to this conference scenario if more than two Terminals were to join the conference.

FIGURE 2/T.130 Meet Me Conference, Steps marked on the DSM-CC/T.120 General Model

FIGURE 3/T.130 Meet-Me Conference, T.120 Code present on Conference Server
Table 1/T.130 Meet Me Conference Steps
Steps	Description	
1-2	The Terminal initiates a DSM-CC session with the Conference Server.	
3	The Conference Server adds connection resources for the download of the DSM-CC U-U code required by the terminal to access the Conference Server application. Taps for the resources are passed to the Terminal in the SessionSetupResponse/Confirm (Steps 4-5). In an ATM environment, these connection resources would be added using Q.2931 SETUP messages.	
4-5	The Conference Server responds to the DSM-CC SessionSetupRequest/Indication, and includes taps for the download connection resources added in Step 3.	
6	DSM-CC U-U Library code is downloaded to each Terminal. This code is the Terminal part of the application on the Conference Server that provides the terminal with information on conference reservations and conferences in progress. See section 3.2.1 for discussion of the assumptions made here.	
7, 8	The Terminal retrieves the address (serverId) of the MCU Server from Conference Server, and other required conference parameters (may include information on network type) using DSM-CC U-U interfaces.

How the Terminal communicates with the MCU Server is determined by the SRM: the SRM is aware of the connection type (network, intermediate devices) required to communicate with the MCU Server.	
9	At this point, since the Terminal has selected a T.120 conference and T.120 code is about to be downloaded to the Terminal, the Conference Server can now begin adding DSM-CC connection resources for T.120 use. Whether this happens during the download (Step 10) or after or before does not matter. In this scenario, the resources are added in Steps 11-14.	
10	The Terminal downloads T.120 code (as required). In this scenario it is assumed that the T.120 code is available from the Conference Server and can be downloaded over the same connections used to download the U-U Directory code. Other methods of downloading the T.120 code are possible and are outlined in section 3.2.1.	
11-14	The Conference Server adds DSM-CC connection resources for the T.120 conference.	
15	Assuming the MCU Server is in the same Service Domain as the Conference Server, there is no need to establish a new DSM-CC session - the DSM-CC session already established in Steps 1-2, 4-5 is sufficient. Thus, the Conference Server passes to the MCU Server, in a proprietary manner, the resourceIds for the DSM-CC connection resources for T.120 use.	
16	T.120 taps are passed to the T.120 code present on the Client. Using these taps, and the conference information retrieved from the Conference Server, the Terminal joins the conference. Since this is a Meet Me Conference, it is assumed that the MCU Server has already created the conference.	
17	Subsequent Terminals that join this Meet Me Conference follow the same Steps 1-16.	
 Assumptions made for this scenario, and possible variations

The following assumptions are made:
•	that DSM-CC U-U Library code is used to build an application that provides information on conference reservations i.e. reserved meet-me conferences, and provides the same information that would be available using T.120 GCC Conference Query. 

If this is not the case, Steps 6-8 would be skipped. Once T.120 code had been downloaded  and DSM-CC connection resources for T.120 use set up using DSM-CC AddResource/SessionSetup messages, then T.120 GCC Conference Query could be invoked to get required conferencing parameters before invoking T.120 GCC Conference Create or Join to the Meet Me conference.

•	that the Conference Server and T.120 Code Server are co-located and thus can use the same download connection resources for downloading code to the Terminal. 

Other downloading possibilities exist: 
a) If the Conference Server and the T.120 Code Server are not co-located, but are in the same Service Domain, new DSM-CC connection resources would need to be added between the T.120 Code Server and the Terminal before the T.120 code could be downloaded. 
b) If the T.120 Code Server is in a different  Service Domain, a new DSM-CC session would need to be established with the T.120 Code Server before the T.120 code could be downloaded.
c) A third possiblity is not to use DSM-CC Download functionality at all. The T.120 code could be downloaded using any other available download protocol between the T.120 Code Server and the Terminal.

•	that the Conference Server is in the same Service Domain as the MCU Server. 

If this is not the case, a new DSM-CC session would need to be established with the MCU Server. The MCU Server would then be required to add the DSM-CC connection resources for T.120 use before the Terminal starts up the T.120 code to join the conference. HOWEVER, this means the MCU Server would require knowledge of DSM-CC. This may not be desireable.
 Browsing a DSM-CC Directory for a Conference
In the Browsing Scenario, the Conference Server application provides a directory of conferences any user may join. Once the user selects a conference, the required T.120 code is automatically downloaded to the Terminal. The steps followed for this Scenario are identical to those for the Meet Me Conference Scenario above.
 Dial Out Conference
In the Dial-Out Conference scenario, DSM-CC PassThruReceipt messages are used by the Conference Server to prompt each Terminal to set up a DSM-CC session and download appropriate T.120 code so that the Terminal can accept a T.120 call.

FIGURE 4/T.130 Dial Out Conference, Steps marked on the DSM-CC/T.120 General Model

FIGURE 5/T.130 Establishing a Dial Out Conference with DSM-CC Terminals

Table 2/T.130 Steps for Dial-Out Conference
Steps	Description	
1-2	The Conference Server sends a DSM-CC PassThruReceipt message to the Terminal asking whether it wishes to accept the T.120 call. This message identifies the serverId of the MCU hosting the conference. The Conference Server and MCU may be either a single entity or separate entities. In this scenario, they are separate entities, but within the same Service Domain. See section 3.4.1 for discussion of the assumptions made.	
3-4	The Terminal responds with DSM-CC PassThruReceiptResponse message to the Conference Server indicating whether it will accept the call.	
5-6	In this scenario it is assumed that the T.120 code is available from the Conference Server. The Terminal sets up a session with the Conference Server to be able to download the T.120 code.	
7	The Conference Server adds connection resources for the download of the DSM-CC U-U code required by the terminal to access the Conference Server application. In an ATM environment, these connection resources would be added using Q.2931 SETUP messages.	
8-9	Taps for the resources are passed to the Terminal in the SessionSetupResponse/Confirm.	
10	At this point, since the Terminal has set up a session to download T.120 code to the Terminal, the Conference Server can now begin adding DSM-CC connection resources for T.120 use. Whether this happens during the download (Step 11) or after or before does not matter. In this scenario, the resources are added in Steps 12-15.	
11	The Terminal downloads T.120 code (as required). Other methods of downloading the T.120 code are possible and are outlined in another section.	
12-15	The Conference Server adds DSM-CC connection resources for T.120 use.	
16	Assuming the MCU Server is in the same Service Domain as the Conference Server, there is no need to establish a new DSM-CC session - the DSM-CC session already established to download the T.120 code is sufficient. Thus, the Conference Server passes to the MCU Server, in a proprietary manner, the resourceIds for the DSM-CC connection resources for T.120 use.	
17	T.120 taps are passed to the T.120 code present on the Client. Using these taps, and the conference information retrieved from the Conference Server, the Terminal joins the conference. Since this is a Dial Out Conference, it is assumed that the MCU Server has already created the conference.	
18	The Conference Server “dials out” to all subsequent Terminals which then join the conference: Steps 1-17 above are thus repeated for each subsequent Terminal.	
 Assumptions made for this scenario, and possible variations

The following assumptions are made:
•	that the Conference Server is co-located with the T.120 Code Server, or is in the same Service Domain as the T.120 Code Server. 

If the T.120 Code Server were in a different Service Domain, the same session established to get the T.120 code could not be used for the DSM-CC resources allocated for T.120 use - a new session would have to be established.

•	that the Conference Server is in the same Service Domain as the MCU Server. 

If this is not the case, a new DSM-CC session would need to be established with the MCU Server. The MCU Server would then be required to add the DSM-CC connection resources for T.120 use before the Terminal starts up the T.120 code to join the conference. HOWEVER, this means the MCU Server would require knowledge of DSM-CC. This may not be desireable.
•	
 Server-aided Point-to-Point Conference for DSM-CC Terminals
In this scenario, the point-to-point conference between two DSM-CC terminals is actually set up by a third party, the Conference Server.

FIGURE 6/T.130 Server-aided Point-to-Point Conference, Steps marked on the DSM-CC/T.120 General Model

FIGURE 7a/T.130 Establishing a Server-aided Point-to-Point Conference with DSM-CC Terminals

FIGURE 7b/T.130 Establishing a Server-aided Point-to-Point Conference with DSM-CC Terminals
Table 3/T.130 Server-aided Point-to-Point Conference -  Steps
Steps	Description	
1-2	The Calling Terminal initiates a DSM-CC session with the White Pages Server.	

3	The White Pages Server adds connection resources for the download of the DSM-CC U-U code required by the terminal to access the White Pages Server application. Taps for the resources are passed to the Terminal in the SessionSetupResponse/Confirm. In an ATM environment, these connection resources would be added using Q.2931 SETUP messages.	
4-5	The White Pages Server responds to the DSM-CC SessionSetupRequest/Indication, and includes taps for the download connection resources added in Step 3.	
6	DSM-CC U-U Library code is downloaded to the Terminal.	
7	The Terminal retrieves the address (clientId) of the Called Terminal and MCU Server & Conference Server from White Pages Server, and other required conference parameters (may include information on network type) using DSM-CC U-U interfaces.

How the Terminal communicates with the MCU Server & Conference Server is determined by the SRM: the SRM is aware of the connection type (network, intermediate devices) required to communicate with Servers.	
8	Assuming the White Pages Server is in the same Service Domain as the Conference & T.120 Code Server, there is no need to establish new DSM-CC session to the Conference & T.120 Code Server - the DSM-CC session already established in Steps 1-2, 4-5 is sufficient. Thus, the White Pages Server passes to the Conference & T.120 Code Server, in a proprietary manner, the resourceIds for the DSM-CC connection resources for download use. These will be used in Step 26.

How and when these resourceIds are passed is proprietary. They need not be passed until the Conference Server requests them in a proprietary manner from the White Pages Server. This need not happen until just before Step 26.

If the Terminal subseqently issues another U-U Open Directory request expecting to access the White Pages Server, it is up to the Conference Server to either re-transfer the request to the White Pages Server along with the resourceIds, or to refuse the request with an appropriate error code. It should be reasonable to require the Conference Server to recognise the request as being directed to the White Pages Server and to re-direct it there. This is a proprietary matter.	
9-10	The Calling Terminal sends a DSM-CC PassThruReceipt message to the Conference Server specifying conference parameters (conference name, conection model (who calls who),...)  in order to determine whether the called party is present and willing to participate in a conference.
Note: This information could be sent to the Conference Server in Step 7. If so, Steps 9-10 and 16-17 are not required.	
11-12	The Conference Server sends a new DSM-CC PassThruReceipt message to the Called Terminal asking whether the called party is present and wishes to participate in a conference.	
13-14	The Called Terminal responds to the DSM-CC PassThruReceipt message indicating whether it wishes participate in a conference.	
15	At this point, if the Called Terminal has positively responded to in the DSM-CC PassThruReceipt message, the Conference Server can now begin adding DSM-CC connection resources for T.120 use. Whether this happens during the download (Step 26) or after or before does not matter. In this scenario, the resources for T.120 use are added in Steps 23-25.	
16-17	The Conference Server responds to the Calling Terminal’s earlier DSM-CC PassThruReceipt message with the information from the Called Terminal. These Steps are omitted if Steps 9-10 were omitted.	
18-19	The Called Terminal, if it wishes to receive the call, sets up a DSM-CC session with the T.120 Code Server.	
20	The T.120 Code Server adds connection resources for the download of the T.120 code. Taps for the resources are passed to the Terminal in the SessionSetupResponse/Confirm in Steps 21-22. In an ATM environment, these connection resources would be added using Q.2931 SETUP messages.	
21-22	The T.120 Code Server responds to the DSM-CC SessionSetupRequest/Indication, and includes taps for the download connection resources added in Step 20.	
23-25	The Conference Server adds DSM-CC connection resources for the T.120 conference. 

One method to accomplish this is for the Conference Server to ask the SRM to establish a point-to-point call between the Calling Terminal (Client) and the Called Terminal (Client). This is a resource that is added to one of the sessions and shared with the other. This may require a new resource descriptor for sharing a resource between two sessions to be added to DSM-CC: The SRM would present a Client View resource descriptor to the Called Terminal with its sessionId (session A) and the common resourceNum, and would present a Client View resource descriptor to the Calling Terminal with its sessionId (session B) and the common resourceNum. DSM-CC Annex D scenarios 1c and 3c (Figures 13-19, 13-21 in [1]) allow for this case: the SRM requires “join” capabilities to join two connection together. 

Alternatively, so-called Network methods can be used where the Calling or Called Terminal uses native network signalling to set up the connection. (DSM-CC Annex D scenarios 2a, 3a [1]).	
26	If the conference will take place, that is the DSM-CC PassThruReceipt message contained a positive response, the Calling Terminal downloads T.120 code. In this scenario it is assumed that the T.120 code is available from the Conference Server and can be downloaded over the same connections used to download the U-U Library code. Other methods of downloading the T.120 code are possible and are outlined in Section 3.5.1.	
27	The Called Terminal downloads T.120 code.	
28	The Called Terminal generates a DSM-CC PassThru message to the SRM indicating that it has completed the T.120 code download.	
29	The SRM routes the DSM-CC PassThru message to the Calling Terminal.	
30	On each Terminal, T.120 taps are passed to the T.120 code present on the Terminal. This could be done any time after Steps 24b and 25b.	
31	Using the T.120 taps, and the conference information retrieved from the Conference Server, the Calling Terminal creates a conference with the Called Terminal the conference.	
 Assumptions made for this scenario, and possible variations

The following assumptions are made:
•	that DSM-CC U-U Library code is used to build an application that provides information on Terminal addresses.

•	that DSM-CC Download functionality is used. 

Other downloading possibilities exist: 
a) If the Conference Server and the T.120 Code Server are not co-located, but are in the same Service Domain, new resources would need to be added between the T.120 Code Server and the Terminal before the T.120 code could be downloaded. 
b) If the T.120 Code Server is in a different Service Domain, a new DSM-CC session would need to be established with the T.120 Code Server before the T.120 code could be downloaded.
c) A third possiblity is not to use DSM-CC Download functionality at all. The T.120 code could be downloaded using any other available download protocol between the T.120 Code Server and the Terminal.
	
•	That the Conference Server is capable of sending a DSM-CC PassThruReceipt message to any Terminal, no matter where it may be.
 Direct Point-to-Point Conference for DSM-CC Terminals
In this scenario, the point-to-point conference between two Terminals is set up directly by one of the Terminals. The Server is used for White Pages information and to download T.120 code, but the actual DSM-CC session is set up between the two terminals, and not through a Conference or MCU Server. 

Whether Direct Point-to-Point Conferences using DSM-CC are  possible within a DSM-CC Network depends on: 
•	whether there is the extra functionality available from the SRM in the Network to be able to redirect DSM-CC SessionSetup, DSM-CC PassThruReceipt and DSM-CC PassThru request messages to a Terminal instead of to a Server, and on 
•	whether a Terminal can acquire the DSM-CC “Server” code it needs to be able to add resources to a DSM-CC session.

These issues still need to be resolved and are for further study.

FIGURE 8/T.130 Direct Point-to-Point Conference, Steps marked on the DSM-CC/T.120 General Model

FIGURE 9a/T.130 Establishing a Direct Point-to-Point conference with DSM-CC Terminals

FIGURE 9b/T.130 Establishing a Direct Point-to-Point conference with DSM-CC Terminals

Table 4/T.130 Direct Point-to-Point Conference - Steps
Steps	Description	
1-2	The Calling Terminal initiates a DSM-CC session with the White Pages Server.	
3	The White Pages Server adds connection resources for the download of the DSM-CC U-U code required by the Terminal to access the White Pages Server application. Taps for the resources are passed to the Terminal in the SessionSetupResponse/Confirm. In an ATM environment, these connection resources would be added using Q.2931 SETUP messages.	
4-5	The White Pages Server responds to the DSM-CC SessionSetupRequest/Indication, and includes taps for the download connection resources added in Step 3.	
6	DSM-CC U-U Library code is downloaded to the Terminal.	
7	The Terminal retrieves the address (clientId) of the Called Terminal & Conference Server from White Pages Server, and other required conference parameters (may include information on network type) using DSM-CC U-U interfaces.

How the Terminal communicates with the Called Terminal is determined by the SRM: the SRM is aware of the connection type (network, intermediate devices) required to communicate with Servers and other Terminals.	
8	Assuming the White Pages Server is in the same Service Domain as the Conference & T.120 Code Server, there is no need to establish a new DSM-CC session to the Conference & T.120 Code Server from the Calling Terminal- the DSM-CC session already established in Steps 1-2, 4-5 is sufficient. Thus, the White Pages Server passes to the Conference & T.120 Code Server, in a proprietary manner, the resourceIds for the DSM-CC connection resources for download use. These will be used in Step 18.

How and when these resourceIds are passed is proprietary. They need not be passed until the Conference Server requests them in a proprietary manner from the White Pages Server. This need not happen until just before Step 18.

If the Terminal subseqently issues another U-U Open Directory request expecting to access the White Pages Server, it is up to the Conference Server to either re-transfer the request to the White Pages Server along with the resourceIds, or to refuse the request with an appropriate error code. It should be reasonable to require the Conference Server to recognise the request as being directed to the White Pages Server and to re-direct it there. This is a proprietary matter.	
9, 10	The Calling Terminal sends a DSM-CC PassThruReceipt message to the Called Terminal specifying conference parameters (conference name, conection model (who calls who),...)  in order to determine whether the called party is present and willing to participate in a conference. 

Extra functionality may be required in the SRM to allow it to route the message directly to a Terminal instead of to a Server.	
11-12	The Called Terminal responds to the DSM-CC PassThruReceipt message indicating whether it wishes participate in a conference. This message is routed through the SRM to the Calling Terminal.	
13-14	The Called Terminal, if it wishes to receive the call, must get the T.120 code, and for this scenario, must have the DSM-CC “Server” code so that it can add resources to a DSM-CC session. First, the Called Terminal sets up a DSM-CC session with the T.120 Code Server.	
15	The T.120 Code Server adds connection resources for the download of the T.120 code. Taps for the resources are passed to the Terminal in the SessionSetupResponse/Confirm in Steps 16-17. In an ATM environment, these connection resources would be added using Q.2931 SETUP messages.	
16-17	The T.120 Code Server responds to the DSM-CC SessionSetupRequest/Indication, and includes taps for the download connection resources added in Step 15.	
18	If the conference will take place, that is the DSM-CC PassThruReceipt message contained a positive response, the Calling Terminal downloads T.120 code. In this scenario it is assumed that the T.120 code is available from the Conference Server and can be downloaded over the same connections used to download the U-U Library code. Other methods of downloading the T.120 code are possible and are outlined in Section 3.6.1.	
19	The Called Terminal downloads T.120 code.	
20	The Called Terminal downloads the DSM-CC “Server” code that will allow the Terminal to add DSM-CC resources to a DSM-CC session.

This assumes that DSM-CC “Server” code has been made available for Clients.	
21-22	The Called Terminal generates a DSM-CC PassThru message to the Calling Terminal indicating that it has completed the T.120 code and the DSM-CC “Server” code downloads, and is thus ready to receive the DSM-CC session setup request, and subsequently the T.120 conference call.

At this point, the Called Terminal now waits for the Calling Terminal to set up a DSM-CC session with it.	
23-24	The Calling Terminal (Client) now establishes a DSM-CC session directly with the Called Terminal (Server). (Alternatively, the Calling Terminal may use an out of band method to establish the physical connection to the Called Terminal.)

For this to work, the SRM must have the functionality to be able to route a SessionSetupRequest from a Client to another Client, and not just to Servers.	
25	The Called Server adds DSM-CC connection resources for T.120 use. Taps for the resources are passed to the CallingTerminal in the SessionSetupResponse/Confirm. In an ATM environment, these connection resources would be added using Q.2931 SETUP messages.	
26-27	The Called Terminal responds to the DSM-CC SessionSetupRequest/Indication, and includes taps for the download connection resources added in Step 25.	
28	On each Terminal, T.120 taps are passed to the T.120 code present on the Terminal.	
29	Using the T.120 taps, and the conference information retrieved from the Conference Server, the Calling Terminal creates a conference with the Called Terminal the conference.	
 Assumptions made for this scenario, and possible variations

The following assumptions are made:
•	that DSM-CC U-U Library code is used to build an application that provides information on Terminal addresses. 
•	
•	that DSM-CC Download functionality is used. 

Other downloading possibilities exist: 
a) If the Conference Server and the T.120 Code Server are not co-located, but are in the same Service Domain, new resources would need to be added between the T.120 Code Server and the Terminal before the T.120 code could be downloaded. 
b) If the T.120 Code Server is in a different  Service Domain, a new DSM-CC session would need to be established with the T.120 Code Server before the T.120 code could be downloaded.
c) A third possiblity is not to use DSM-CC Download functionality at all. The T.120 code could be downloaded using any other available download protocol between the T.120 Code Server and the Terminal.

•	that DSM-CC “Server” code has been made available on the T.120 Code Server for Clients to download on request.

•	that the SRM has the functionality to be able to route a SessionSetupRequest from a Client to another Client, and not just to Servers.
	
•	that the SRM is capable of sending a DSM-CC messages to any Terminal/Client, no matter where it may be.
 Defining the T.120 Communication Request PassThruReceipt and PassThru messages

For the Dial Out  and Point-to-Point Conference scenarios, the DSM-CC PassThruReceipt message is used to determine Terminal willingness to join a conference before the establishment of a DSM-CC session, and the DSM-CC PassThru message is used in the Point-to-Point Conference scenarios to tell the Calling Terminal when the Called Terminal has completed its download of T.120 code.

To use the DSM-CC PassThruReceipt and PassThru messages for T.120 Communication Requests, passThruTypes and the corresponding userData are defined in this section. [To officially define this information, it must be brought to the ISO/IEC group administering the passThruType codes. Thus the Santa Rosa Aug/96 meeting sent a liaison to ISO/IEC WG11 requesting two passThruType values described in Table 5 below .]

The following defines the passThruType T120Comm for a T.120 Communication Request/Response and the associated userData of for this type of  PassThruReceipt message.

Table 5/T.130 DSM-CC passThruType value for T.120 use
passThruType	Value	Description	
T120RequestForCommunication	0x0001 (2 bytes)	indicates that this PassThru message or PassThruReceipt message holds a request for T.120 communication. (See Tables 6, 7).	
T120ReadyTo
Communicate	0x0002 (2 bytes)	indicates that this PassThru message is telling the recipient that the sender is ready to participate in a T.120 conference. (See Table 8).	

Table 6/T.130 T120RequestForCommunicationRequestUserData
Syntax	Num of Bytes	
T120RequestForCommunicationRequestUserData() {		
   userId	20 - OSI NSAP address, as defined in DSM-CC Table 4-58 User-to-Network Session Message Field Data Types [1]	
   conferenceName	as indicated in T.124	
   conferencePassword	as indicated in T.124	
}		

userId indicates the identifier for the User with which this User shall proceed to set up a DSM-CC session with, to subsequently join a conference. If userId is 0, the recipient of this message just arranges to have the T.120 code downloaded and will wait to have a DSM-CC session established with it, will add the DSM-CC resources for T.120 use, and will then wait to receive a GCCConferenceCreate request - (this is the Direct Point-to-Point Conference scenario). The format of the userId field is defined in DSM-CC Table 4-58 User-to-Network Session Message Field Data Types [1].

conferenceName indicates the name of the conference. This may be NULL if userId is 0.

conferencePassword indicates the password for the conference. This may be NULL.
NOTE: this userData description for conferencePassword needs to be expanded to indicate whether or not a password is required, whether a password in the clear is present, whether the password is communicated to the Terminal out of band,...

Table 7/T.130 T120RequestForCommunicationResponseUserData
Syntax	Num of Bytes	
T120RequestForCommunicationResponseUserData() {		
   response	1	
}		

response indicates whether or not the client wishes to join the conference: rspNo = 0x01, rspYes = 0x02.

Table 8/T.130 T120ReadyToCommunicateUserData
Syntax	Num of Bytes	
T120ReadyToCommunicateUserData() {		
   t120Ready	1	
}		

t120Ready indicates whether or not the sender is ready to communicate: rspNo = 0x01, rspYes = 0x02.
 Accessing DSM-CC Services from a T.120 Terminal
	
1.	One or more nodes within the conference may act as gateways to the DSM-CC domain.
2.	DSM-CC U-U Services (e.g. Directory Services) may be accessed via T.RPC (Remote Procedure Call - to be defined) to the Gateway which forwards the requests to the DSM-CC Server (see figure 7).  In this case there is no requirement for DSM-CC Servers to support T.120.

FIGURE 7/T.120:DSM-CC
Accessing DSM-CC Services from a T.120 Node

From a DSM-CC perspective, the Gateway is the DSM-CC Client; likewise from a T.120 perspective, the Gateway is the DSM-CC Server.

Open issues:
•	Figure 7 illustrates a simple case where a single T.120 node is accessing DSM-CC U-U Services.  However, if multiple T.120 nodes attempt to access the same DSM-CC Service simultaneously, the Gateway may need to arbitrate between conflicting requests from those nodes.
•	How are real time streams originating in a DSM-CC domain introduced into a T.120 conference domain? 
•	What is the relationship between the DSM-CC U-U Stream Service and T.13x for control of real time streams?
•	T.120 Application Protocol  needs to be defined to allow T.120 client to download & install DSM-CC U-U code and obtain DSM-CC device id and obtain appropriate DSM-CC U‑N configuration details.   This is the ‘Virtual’ Set-Top concept and is for further study.
 References
[1] ISO/IEC JTC1/SC29/WG11/N1300p1, Information technology - Generic coding of moving pictures and associated audio information - Part 6: Extension for  Digital Storage Media Command and Control (DSM-CC) ISO/IEC 13818-6 International Standard, output from Tampere, Finland meeting, July, 1996.