August 1997 - sg16-avd - lists.packetizer.com

APC document registration
by Sakae Okubo 27 Aug '97

27 Aug '97

Dear Mr. Webber, This is to confirm your withdrawal of APC-1290: Transaction TCP for Improved H.323 Signaling. This number is reallocated to Mr. Toga's draft H.235. Dear Mr. Yan and Mr. Toga, The following APC numbers have been allocated to your contributions. Attached please find the current list of registered documents. APC-1290 (Draft) Editors draft of H.235 APC-1305 H.245based, H.243-like conference session control for H.bmultipoint APC-1306 (Proposal) Fast Connect Sequence for H.323 APC-1307 (Proposal) RTP payload alignment for H.245/IETF Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151 Japan ******************************************************************** Document registration for the Sunriver meeting (8-11 September 1997) These documents will be uploaded to: ftp://itu-t:sg15!avc@ftp.gctech.co.jp/9709_Sun/ and its mirror in the US: ftp://standard.pictel.com/avc-site/9709_Sun/ Please take a look at 9709_Sun.html for their availability. --------------------------------------------------------------------- Number Source Provisional Title --------------------------------------------------------------------- APC-1250 DAVIC CFP9 - IP based technologies APC-1251 CNET Proposal for the use of Reed-Solomon codes in H.321 terminals. Application in video satellite communications. Experimental results on real communications. APC-1252 Editor Draft ITU-T H.450.1 APC-1253 Editor Draft ITU-T H.450.2 APC-1254 Editor Draft ITU-T H.450.3 APC-1255 Editor Draft H.323 Version 2 APC-1256 Editor Draft H.332 APC-1257 Editor Draft H.225.0 Version 2 APC-1258 Editor Draft H.321 Version 2 APC-1259 Editor Draft H.310 Version 2 APC-1260 Editor Initial draft of H.bmultipoint APC-1261 Editor Draft Annex C to H.323 APC-1262 Microsoft et al Specific Text Changes for Enhanced DTMF Support APC-1263 CNET Proposal of an ATC class for terminal H.321 version2 APC-1264 Ascend More Accurate Call Information in the Direct Call Model APC-1265 Q13 Rap Overall DTMF Directions for H.323 APC-1266 Ascend et al Using H.323 call control for Fax over IP APC-1267 Databeam T.120 Security Requirements APC-1268 MPEG Proposed Liaison between DMIF adn ITU-T SG16 TD 38 Geneva March 1997, July 25, 1997 APC-1269 MPEG MPEG-4 Overview, July 1997 APC-1270 MPEG DMIF (Delivery Multimedia Integration Framework) ISO/IEC 14496-6 WD 1.0, July 1997 APC-1271 Siemens H.235: Message Integrity for the H.225.0 RAS channel - Revised APC-1272 Q.2931 Editor Prososed Changes to Q.2931 APC-1273 Vocaltec A URL for H.323 Calls APC-1274 Vocaltec A URL for RAS Requests APC-1275 Vocaltec ACF & LCF messages should contain Endpoint Type APC-1276 Vocaltec Using the transport layer address within H.323 PDUs for Transparent Firewall Operation APC-1277 Vocaltec DTMF Signaling with H.323 APC-1278 Vocaltec Access Tokens within H.323 APC-1279 Vocaltec Dynamic Change of IP Address in Registration APC-1280 Vocaltec A Progress UUIE for Answer Supervision APC-1281 Vocaltec ICF Message to Enable Reliability and Security APC-1282 Vocaltec Announcing a Q.931 message within an IRR APC-1283 Vocaltec H.245 Support for GSM Speech Codecs APC-1284 Vocaltec Corrections to the Endpoint Structure APC-1285 BT Use of H.245 in Supplementary Services APC-1286 BT Fast Call Setup with Minimal Change APC-1287 BT Extensions to H.323 for operation over Frame Relay APC-1288 BT Conversational URLs APC-1289 Editor H.MediaMIB Progress Report and Draft APC-1290 Editor Editors draft of H.235 APC-1291 Mitel Re-determination of Master-Slave Status APC-1292 Mitel Call Transfer with Consultation Call for Gatekeeper-Routed Model APC-1293 VideoServer Support of ConferenceAlias in H.323 Revision 2 APC-1294 VideoServer Observations on H.MediaMIB Draft APC-1295 Editor Draft H.246 APC-1296 Editor H.323 additions for H.245 Version 3 APC-1297 PictureTel General Comments and Proposals for H.323, H.225, H.245, and H.450.X APC-1298 Rap Q12 Proposed Amendments to the common text ITU-T Recommendation H.222.0|ISO/IEC 13818-1 APC-1299 Japan Proposed additions to H.310 and H.245 - procedures for intercommunication between H.310 RAST-1 and RAST-5 terminals APC-1300 Japan Proposed correction of Recommendation H.310 regarding the H.3230/H.321 interoperation mode stack of RAST-5 terminals APC-1301 Japan Audiovisual signal processing in H.bmultipoint Multipoint Processor APC-1302 Cisco QoS Control in H.323 Version 2 using RSVP APC-1303 IBM Text proposal for APC-1218 "Clarification on the H.323 Ad-Hoc Conferencing Expansion" APC-1304 PictureTel "replacementFor" Text APC-1305 Lucent H.245based, H.243-like conference session control for H.bmultipoint APC-1306 Intel Fast Connect Sequence for H.323 APC-1307 Intel RTP payload alignment for H.245/IETF ---------------------------------------------------------------------

1 0

Re: Multicasting SETUP for user location
by Pete Cordell 27 Aug '97

27 Aug '97

Nadia, I was under the illusion that there was a range of multicast addresses that were allocated for site specific definition. I have looked through the assigned numbers list and can not find such a range. Therefore, you are right. If there is interest in the proposal it will be necessary to get IANA to assign some numbers. Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 643791 ================================= >---------- >From: Nadia KAUSAR[SMTP:N.Kausar@CS.UCL.AC.UK] >Sent: 27 August 1997 10:10 >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Re: Multicasting SETUP for user location > >Pete > >I was reading your proposal on the multicasting setup for H.323 family. >What >sort of mechanism are you assuming will be used to allocate these >multicast >addresses? (If I am right, you are saying that we already have a >multicast >address and the terminal connects to that) but the allocation of >addresses is >a problem issue on its own. May be something like mark handley's work >on sdp >and the address allocation would be useful... > >Nadia >

1 0

Re: Multicasting SETUP for user location
by Nadia KAUSAR 27 Aug '97

27 Aug '97

Pete I was reading your proposal on the multicasting setup for H.323 family. What sort of mechanism are you assuming will be used to allocate these multicast addresses? (If I am right, you are saying that we already have a multicast address and the terminal connects to that) but the allocation of addresses is a problem issue on its own. May be something like mark handley's work on sdp and the address allocation would be useful... Nadia

1 0

Document registration
by Sakae Okubo 26 Aug '97

26 Aug '97

Dear SG16 colleagues, Attached please find an updated list of APC document registration. Please note that I have registered APC-1298 from Q.12 Rapporteur, three contributions (APC-1299, 1300, 1301) from Japan, and APC-1302, 1303, 1304 in response to the following requests: Dear Mr. Petrack, >>if it is possible to change the titles in the text file and the html >>file in accordance with the titles below. This has been actioned. Dear Mr. Hussein Salama, >>Would you please assign an APC number to a contribution from Cisco >>Systems to the SG16 Sunriver meeting. the contribution is titled: >>"QoS Control in H.323 Version 2 using RSVP." It is an updated >>version of the APC we presented at the previous meeting. APC-1302 has been allocated to your contribution. Dear Mr. Linh Truong, >>I'd very appreciate if you could give me an APC number for the >>following contribution: >> Source: IBM, >> Title: "Text proposal for APC-1218 "Clarification on the >> H.323 Ad-Hoc Conferencing Expansion" ", Purpose: proposal. APC-1303 has been allocated to your contribution. Dear Mr. Lindbergh, >>I plan to request an APC number and post the final version late >>this week; Please use APC-1304 for your contribution. Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151 Japan ******************************************************************** Document registration for the Sunriver meeting (8-11 September 1997) These documents will be uploaded to: ftp://itu-t:sg15!avc@ftp.gctech.co.jp/9709_Sun/ and its mirror in the US: ftp://standard.pictel.com/avc-site/9709_Sun/ Please take a look at 9709_Sun.html for their availability. --------------------------------------------------------------------- Number Source Provisional Title --------------------------------------------------------------------- APC-1250 DAVIC CFP9 - IP based technologies APC-1251 CNET Proposal for the use of Reed-Solomon codes in H.321 terminals. Application in video satellite communications. Experimental results on real communications. APC-1252 Editor Draft ITU-T H.450.1 APC-1253 Editor Draft ITU-T H.450.2 APC-1254 Editor Draft ITU-T H.450.3 APC-1255 Editor Draft H.323 Version 2 APC-1256 Editor Draft H.332 APC-1257 Editor Draft H.225.0 Version 2 APC-1258 Editor Draft H.321 Version 2 APC-1259 Editor Draft H.310 Version 2 APC-1260 Editor Initial draft of H.bmultipoint APC-1261 Editor Draft Annex C to H.323 APC-1262 Microsoft et al Specific Text Changes for Enhanced DTMF Support APC-1263 CNET Proposal of an ATC class for terminal H.321 version2 APC-1264 Ascend More Accurate Call Information in the Direct Call Model APC-1265 Q13 Rap Overall DTMF Directions for H.323 APC-1266 Ascend et al Using H.323 call control for Fax over IP APC-1267 Databeam T.120 Security Requirements APC-1268 MPEG Proposed Liaison between DMIF adn ITU-T SG16 TD 38 Geneva March 1997, July 25, 1997 APC-1269 MPEG MPEG-4 Overview, July 1997 APC-1270 MPEG DMIF (Delivery Multimedia Integration Framework) ISO/IEC 14496-6 WD 1.0, July 1997 APC-1271 Siemens H.235: Message Integrity for the H.225.0 RAS channel - Revised APC-1272 Q.2931 Editor Prososed Changes to Q.2931 APC-1273 Vocaltec A URL for H.323 Calls APC-1274 Vocaltec A URL for RAS Requests APC-1275 Vocaltec ACF & LCF messages should contain Endpoint Type APC-1276 Vocaltec Using the transport layer address within H.323 PDUs for Transparent Firewall Operation APC-1277 Vocaltec DTMF Signaling with H.323 APC-1278 Vocaltec Access Tokens within H.323 APC-1279 Vocaltec Dynamic Change of IP Address in Registration APC-1280 Vocaltec A Progress UUIE for Answer Supervision APC-1281 Vocaltec ICF Message to Enable Reliability and Security APC-1282 Vocaltec Announcing a Q.931 message within an IRR APC-1283 Vocaltec H.245 Support for GSM Speech Codecs APC-1284 Vocaltec Corrections to the Endpoint Structure APC-1285 BT Use of H.245 in Supplementary Services APC-1286 BT Fast Call Setup with Minimal Change APC-1287 BT Extensions to H.323 for operation over Frame Relay APC-1288 BT Conversational URLs APC-1289 Editor H.MediaMIB Progress Report and Draft APC-1290 PictureTel Transaction TCP for Improved H.323 Signaling APC-1291 Mitel Re-determination of Master-Slave Status APC-1292 Mitel Call Transfer with Consultation Call for Gatekeeper-Routed Model APC-1293 VideoServer Support of ConferenceAlias in H.323 Revision 2 APC-1294 VideoServer Observations on H.MediaMIB Draft APC-1295 Editor Draft H.246 APC-1296 Editor H.323 additions for H.245 Version 3 APC-1297 PictureTel General Comments and Proposals for H.323, H.225, H.245, and H.450.X APC-1298 Rap Q12 Proposed Amendments to the common text ITU-T Recommendation H.222.0|ISO/IEC 13818-1 APC-1299 Japan Proposed additions to H.310 and H.245 - procedures for intercommunication between H.310 RAST-1 and RAST-5 terminals APC-1300 Japan Proposed correction of Recommendation H.310 regarding the H.3230/H.321 interoperation mode stack of RAST-5 terminals APC-1301 Japan Audiovisual signal processing in H.bmultipoint Multipoint Processor APC-1302 Cisco QoS Control in H.323 Version 2 using RSVP APC-1303 IBM Text proposal for APC-1218 "Clarification on the H.323 Ad-Hoc Conferencing Expansion" APC-1304 PictureTel "replacementFor" Text ---------------------------------------------------------------------

1 0

MCU features
by Ray Jang 26 Aug '97

26 Aug '97

I'm not sure if this is the right email address, but here goes... We at Starvision are developing a broadband MCU product. The first phase of our product is now complete. It is a prototype which performs parallel real-time video processing on up to 10 video streams. Some features currently implemented are arbitrary scaling, panning, positioning, z-buffering, alpha-blending, chroma-keying, text overlay and graphics overlay. The platform can support any combination of # of conferences and # per conference up to a total of 10. Currently control of the A/V feature set is proprietary. The next phase of our development is to increase the number of user streams supported in the MCU, to provide transport over ATM and to conform as close as we can to current and developing ITU standards. Among many of the issues we're investigating, one of the items in question is the issue of the overlap in functionality between H.245 and T.120. Our MCU has many audio/video processing features currently not defined in either H.245 or T.130. In H.323, Section 6.6, it is stated that "criteria for which [video] sources and how many are mixed is determined by the MC until other controls are defined. The use of the T.120-Series Recommendations for these control functions is for further study." Is there anywhere I can be pointed to for information and discussion regarding these multipoint A/V control functions? I would think that this is not something that would go into the H.245 spec. Is the current thought to use T.130? Any info is much appreciated. -- Ray Jang Technical Leader, R&D Starvision Multimedia http://www.starvision.com

1 0

Revised H.245 ReplacementFor Appendix
by Dave Lindbergh 26 Aug '97

26 Aug '97

Dear SG16 colleagues, Attached is a revised (dated 1997-08-25) version of the H.245 appendix (non-normative) and H.245/H.323 text (normative) for "ReplacementFor". It is just 3 pages long. I plan to request an APC number and post the final version late this week; I'll try to incorporate any comments in that version. The main changes from the 1997-07-30 version are: 1) H.323 RSVP procedures are mentioned in the appendix, based on the Cisco proposals. 2) The new LC transport addresses are required to be the same as the original transport addresses, to allow changing the RSVP bandwidth before getting the OLCAck. I've _not_ mentioned anything about Flow Control to support RSVP, as this seems to be unrelated to RepFor; whatever is defined for this will apply equally whether RepFor is used or not. For those who read the 1997-07-30 version, I've marked the changes in yellow highlight; this will be removed from the final APC document. --Dave L. ------------------------------------------------------------------- Dave Lindbergh Email: lindbergh(a)pictel.com Manager, Technical Standards Group Voice: +1 508 623 4351 PictureTel Corporation Fax: +1 508 749 2804 100 Minuteman Road - M/S 635 H.320: +1 508 437 0265 (twice) Andover MA 01810 USA http://standards.pictel.com PGP fingerprint: C8 3E 28 69 53 0A 4B 87 EF E0 11 CD AC 87 4D CD -------------------------------------------------------------------

1 0

Re: H.245 ReplacementFor Appendix
by Dave Lindbergh 25 Aug '97

25 Aug '97

Mike, Hussein, (and all), Thanks for your comments on the ReplacmentFor text. I'm trying to wrap up a revised contribuiton for SunRiver this week. I would appreciate your thoughts on the following: At 02:44 PM 8/14/97 +0100, nilsson_m_e(a)bt-web.bt.co.uk wrote: >I am concerned about adding a FlowControl field to the >OpenLogicalChannelAck message. This could make things very complicated >in the future when people start to use this for something else, >something that was not intended and something that we have not even >thought about yet. I propose to not mention this issue in the ReplacementFor text, since I think it is a generic issue with RSVP support and has nothing to do with ReplacementFor in particular. We can modify the appendix example text in SunRiver (or even after) based on however the group decides to handle this. >From Dave's document REPFR_AP.DOC, concerned with the replacementFor >mechanism, the reason for creating this mechanism is quite clear, and >it is very useful. > >However, I think we should clarify how much flexibility is allowed. >In particular, how long can the transmitter wait before sending >CloseLogicalChannel for the first channel? Can it delay sending this >for sometime, and switch between the two channels? No, this is not intended to be allowed. It's purely for a one-time mode switch. >in his example is >it possible to start with G.723, then send G.711-OpenLogicalChannel with >replacementFor=G.723, switch to G.711, then at some later time switch >to G.723 again, and then perhaps back to G.711? No this should not be allowed. I'll clarify both the example appendix and the proposed normative semantics for H.245 on this point. >If we want to allow this then we should clarify this in the proposed >appendix, and perhaps change the terminology replacementFor to, say, >alternativeTo. If we do not, then we should ensure some strong >normative wording is added about sending CloseLogicalChannel >immediately after receiving the other OpenLogicalChannelAck, and add a >note specifically outlawing this scenario. I'll propose some text along the lines you suggest. (That we do not want to allow this.) ------------------------------------------------------------------- Dave Lindbergh Email: lindbergh(a)pictel.com Manager, Technical Standards Group Voice: +1 508 623 4351 PictureTel Corporation Fax: +1 508 749 2804 100 Minuteman Road - M/S 635 H.320: +1 508 437 0265 (twice) Andover MA 01810 USA http://standards.pictel.com PGP fingerprint: C8 3E 28 69 53 0A 4B 87 EF E0 11 CD AC 87 4D CD -------------------------------------------------------------------

1 0

Contributions uploaded -- Please note some changes in Titles
by Scott Petrack 25 Aug '97

25 Aug '97

Okubo-san and SG16 colleagues, I have uploaded all but one of our contributions. APC-1278 should be ready within a day or two. I have altered a few of the titles from what I asked of Okubo-san earlier. Okubo-san, if it is possible to change the titles in the text file and the html file in accordance with the titles below, I should be very grateful indeed. I am sorry for the trouble this might cause. APC-1273 A URL for H.323 Calls APC-1274 A URL for RAS requests APC-1275 ACF & LCF messages should contain Endpoint Type APC-1276 Using the transport layer address within H.323 PDUs for Transparent Firewall Operation APC-1277 DTMF Signaling with H.323 APC-1278 Access Tokens within H.323 (to be uploaded soon) APC-1279 Dynamic Change of IP Address in Registration APC-1280 A Progress UUIE for Answer Supervision APC-1281 ICF Message to Enable Reliability and Security APC-1282 Announcing a Q.931 message within an IRR APC-1283 H.245 Support for GSM Speech Codecs APC-1284 Corrections to the Endpoint Structure Here is a one-line summary of each contribution: 1. APC-1273 A URL for H.323 Calls (A set of requirements for the H.323 URL and a proposal. Our solution ensures that any remote info can be coded, but also allow for user-friendly URLs where possible). 2. APC-1274 A URL for RAS requests (A similar proposal for RAS requests. We need ras: URLs to enable sending LRQs from Web Pages, and also to allow Web-based call management). 3.APC-1275 ACF & LCF messages should contain Endpoint Type (Need to be able to tell if you?re calling a gateway or terminal and which vendor and version) 4.APC-1276 Using the transport layer address within H.323 PDUs for Transparent Firewall Operation (A PDU can set transport addresses to 0.0.0.0, meaning use the address from the transport layer. Needed for transparent proxies/firewalls/GKs and for apps that don?t know their own address). 5. APC-1277 DTMF Signaling with H.323 (Contains a much simplified version of Microsoft's proposal with similar semantics) 6.APC-1278 Access Tokens within H.323 (The semantics of AccessTokens within H.323) 7.APC-1279 Dynamic Change of IP Address in Registration (reregistration in the event of an crash) 8.APC-1280 A Progress UUIE for Answer Supervision (To signal to caller that ?you can talk now?) 9.APC-1281 ICF Message to Enable Reliability and Security (An option to ack unsolicited IRRs) 10.APC-1282 Announcing a Q.931 message within an IRR (An option for direct calls to inform the GK that a message was sent or received) 11.APC-1283 H.245 Support for GSM Speech Codecs (The audio caps structure for GSM) 12.APC-1284 Corrections to the Endpoint Structure (destExtraCallInfo and remoteExtensionAddress need to be added to the Endpoint structure) Note that 8,9, and 10 offer an alternative to Ascend?s contribution (APC-1264) about "call accounting." We are very sympathetic to Ascend's concern, but have real problems with their proposed solution. Our solution contains theirs, but we believe avoids some pitfalls. Our contributions were written before we saw APC-1264, but we added some text to relate them directly to APC-1264. Scott

1 0