ITU Telecommunication Standardization Sector  Document              APC-1424
Study Group 16
Q.12-14/16 Rapporteur Meeting                                                          4-June-1998
Cannes, 8-11 June 1998							

SOURCE*:	SIEMENS
TITLE  :	Clarification of requirements for Point-to-Point H.323 
Communication on ISDN needed
PURPOSE: 	Discussion

__________________________________________________________________

*Contact: Istvan Sebestyen, E-mail: istvan.sebestyen@pn.siemens.de

The following are taken from the Report of the Yokosuka meeting (04/98):
 
“APC-1369 [France Telecom] “Proposed Mechanisms for Point-to-Point H.323 Communications on ISDN” [Joint with Q11, Q14]

A variety of problems were pointed out by Mr. Lindbergh.  He calls for direct reference to V.140 rather than repetition of figures from these standards.  A spirited discussion followed.  It will be reviewed by Q11 and Q13, and discussed on the reflector as well.  It was suggested that this might be an Appendix to H.323 rather than an Annex so that H.320/H.324 on ISDN remains the formal recommendation of the ITU-T while recognizing that H.323 will be used over point-to-point links using PPP, and that it is in the interest of the ITU-T to promote interoperability in this situation.  Mr. Blin of France Telecom will continue to develop this as editor, either as an annex or appendix.”

I believe the reason for the “spirited discussion” is that there were/are no agreed requirements of what should be the target of standardization:

The “target scenarios” I can think of (which might not be the actual, or all intended targets…) are the following:

Scenario 1: Use of N-ISDN and PPP as “Access Network” to an IP based H.323 Multimedia Terminal.

Scenario 2: Use of N-ISDN as transport network for H.323 Multimedia terminals located on N-ISDN.

If the target is Scenario 1 then the service quality you are getting in less critical (After all you are getting a “Non-guaranteed quality of service”). Usage: For people not having IP network terminating points at their terminal end will be able to communicate with an IP based H.323 terminal, even if the quality on 2-B channels are not perfect. On 1-B channel due to the high overhead of IP only limited quality audio-visual communication can be expected. On a 384 kbit/s or 2 Mb N-ISDN connection you can expect sufficiently good multimedia service quality, provided along the entire end-to-end connection you have no bottleneck in service quality.

If the target is Scenario 2 then we have to keep the following requirements in mind:

1	On N-ISDN the ITU-T has already specified two terminal types H.320 and H.324. Both can interwork with one other, H.324 is basically a dual-mode terminal also supporting H.320. If the ITU-T also place a new type of terminal on N-ISDN, such as H.323, then the minimum common set of interoperability has also be provided, thus it also has to be dual mode terminal supporting H.320 as common base. It must be guaranteed to the user that all H.32x Multimedia Terminals on the N-ISDN can seemlessly interwork with one other, as an average user will likely not have an understanding why his H.32x terminal can not interwork with an other H.32x terminal on the same network.
2	The expected “quality of service” has to be assured on all type of terminals. The bottleneck of H.320 and H.324 communication of low-bitrate (1B or 2B channels) N-ISDN is the video and audio quality (including delay). For H.323 on lower bitrates (1B and 2B channels) the quality is even more of a problem, as the overhead of packetization reduces the bandwidth for the transport of audio and video information. On 384kbit/s or 2Mbits/s the effect of overhead is not critical. Therefore, it must be evaluated by conducted subjective tests whether the quality of H.323 multimedia terminal for audio visual purposes (i.e. videotelephony) on 1 and 2 B-Channels is still acceptable to normal users. Otherwise this might have an overall negative effect on the general acceptance of quality of multimedia services over N-ISDN, as again the average user will likely not make any distinction between the various H.32x terminal types.