September 1999 - sg16-avd - lists.packetizer.com

ICIP-99 and Packet Video 2000
by Sakae OKUBO 24 Sep '99

24 Sep '99

Dear SG16 colleagues, Please find attached the following calls in the areas close to that of our standardization efforts: - ICIP-99 Call for participation, 24-28 October 1999 in Kobe (Japan) - Packet Video Workshop Call for papers, 1-2 May 2000 in Cagliari (Italy) Best regards, Sakae OKUBO (Mr.) *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ------------------------< ICIP-99 >------------------------------- ICIP-99 Tutorials The IEEE 1999 International Conference on Image Processing October 24-28, 1999, International Conference Center Kobe - Kobe, JAPAN Tutorials will be held Sunday, October 24, 1999 Please select from below, and note that some sessions are given in parallel. Tutorial day is Sunday, October 24, 1999. Tutorials Cost 12,000 JPY for Non-Students and 6,000 JPY for Students who register in advance, 17,000 JPY and 6,000 JPY for those who register after September 6, 1999 or later, respectively. Tutorial-only registration will be available exclusively on-site. All-Day Session: 9:00 AM-12:00 Noon & 2:00 PM-5:00 PM Session SF1: Introduction to Multimedia Systems and Standards A. M. Tekalp (Univ. of Rochester) , A. Puri (ATT Research Labs.) Morning Tutorials (Select One): 9:00 AM-12:00 Noon Session SA1: Content Security & Data Hiding in Digital Media A.N. Akansu (New Jersey Inst. of Tech.), E.J. Delp (Purdue Univ.) Session SA2: Intelligent Multimedia Processing T.Chen (Carnegie-Mellon Univ.), J.N.Hwang (Univ. of Washington), S.Y. Kung (Princeton Univ.) Session SA3: Model-Based Halftoning T. N. Papas (Bell Laboratories, Lucent Technologies), D. L. Neuhoff (Univ. of Michigan) Afternoon Sessions (Select One): 2:00 PM-5:00 PM Session SP1: The JPEG 2000 C. Christopulos (Ericsson Telecom), A. N. Skodras (Univ. of Patras) Session SP2: Biometrics: Techniques for Personal Identification A. K. Jain (Michigan State Univ.) , L. Hong (Visionics), S. Pankanti (IBM T. J. Watson Research Center) Session SP3: Introduction to Medical Image Processing M. Analoui (Indiana Univ.) Session SP4: Image and Video Recovery Aggelos K. Katsaggelos (Northwestern Univ.) Early Registration Deadline September 6, 1999 For more details on the rest of the ICIP-99 program, visit: http://icip99.ozawa.ics.keio.ac.jp/ General Chair:Yasuhiko Yasuda, Waseda University Conference Manager: Shingo Abe, J Communications, Email: abes(a)pop16.odn.ne.jp ------------------------< PV-2000 >----------------------------- CALL FOR PAPERS --------------- ================= PACKET VIDEO 2000 ================= The 10th International Packet Video Workshop 1-2 May 2000 Forte Village Resort, Cagliari, Sardinia, Italy http://www.diee.unica.it/pv2000/ ------------------------------------------------------------------------ The 10-th edition of the International Packet Video Workshop (PV 2000) will be held in the middle of the Mediterranean Sea, at the Forte Village Resort near Cagliari (Sardinia island), Italy. The workshop is devoted to present technological advancements and innovations in video communications over packet networks, in particular, the Internet. Packet Video Workshops have been unique in providing a common ground for people from video coding and networking fields. Presentations on theory and practice, standards activities, and business and consumer applications are encouraged. We cordially invite you to take part in this workshop by submitting your work and look forward to welcome you in Sardinia in May 2000 for what will be a rewarding and exciting experience! Francesco G.B. De Natale and Daniele D. Giusto PV2000 General Chairs, University of Cagliari, Italy ---------------------------------------------------------------------- TECHNICAL COMMITTEE CHAIRS Leonardo Chiariglione, CSELT, Italy Maurizio D $B=D (Bina, Cefriel and Politecnico di Milano, Italy ---------------------------------------------------------------------- TECHNICAL COMMITTEE (members) John Arnold, Univ. New South Wales, Australia Andrea Basso, AT&T, USA Stephen Casner, CISCO, USA Shih-Fu Chang, Columbia University, USA M. Reha Civanlar, AT&T, USA Jon Crowcroft, Univ. College London, UK Edward Delp, Purdue Univ., USA Touradj Ebrahimi, EPFL, Switzerland Mohamed Ghanbari, Univ. Essex, UK Barry G. Haskell, AT&T, USA Yu Hen Hu, Univ. Wisconsin, USA Aggelos Katsaggelos, Northwestern Univ., USA Jae-Kyoon Kim, Samsung, Korea Faouzi Kossentini, Univ. British Columbia, Canada C.-C. Jay Kuo, Univ. Southern California, USA Steven McCanne, U.C. Berkeley, USA James Modestino, Rensselaer Polytechnic Institute, USA Geoff Morrison, BT, UK Hans-Georg Musmann, TU Hannover, Germany Sakae Okubo, Telecommunications Adv. Org., Japan Naohisa Ohta, Sony, Japan Joerg Ott, Univ. Bremen, Germany Fernando Pereira, Instituto Superiore T $B;D (Bnico, Portugal Majid Rabbani, Eastman Kodak, USA Amy Reibman, AT&T, USA Philippe Salembier, UPC, Spain Henning Schulzrinne, Columbia Univ., USA Gary Sullivan, Microsoft, USA A. Murat Tekalp, Univ. Rochester, USA Thierry Turletti, INRIA, France John Woods, Rensselaer Polytechnic Institute, USA Stephan Wenger, TU Berlin, Germany Hiroshi Yasuda, Tokyo Univ., Japan ------------------------------------------------------------------------ PUBLICATIONS AND DEMOS Luigi Atzori, University of Cagliari, Italy ------------------------------------------------------------------------ TECHNICAL PROGRAM The technical program of Packet Video 2000 will consist of invited talks, submitted paper presentations, poster sessions and demos. Topics of interest include, but are not limited to: Video processing and transmission Video streaming over the Internet Network adaptive video coding and transport Packetized video for home LANs Packetized video for wireless/mobile systems Packet video protocols and storage formats Layered coding for error resilience and heterogeneous networks Packet loss resilient coding and transport Terminal and server architectures for Internet TV Efficient transcoding for heterogeneous networks Congestion control Error concealment Pre and post-processing for picture quality enhancement Statistical multiplexing for greater network and terminal utilization Traffic shaping for efficient network and terminal utilization Interstream synchronization for multiple video presentations Packet network performance modeling and evaluation Rate control for VBR video Standards: MPEG4, MPEG7, H.263, H.323, RTP, RTSP, SIP, SDP Multicasting, MBONE applications Implementations and commercial applications ------------------------------------------------------------------------ BEST PAPER AWARD The author of the best paper will receive a $250 prize and a diploma suitable for framing. ------------------------------------------------------------------------ SUBMISSIONS Please submit an electronic manuscript written in Word or HTML, not exceeding 10 printed pages. We will produce a CD-ROM (pdf format) containing all the accepted papers. Submit your work in ONE of the following forms: 1) a Word document OR 2) a set of HTML files organized in a single directory to: pv2000(a)diee.unica.it Detailed instructions for authors and help with manuscript preparation can be found on the conference web page. ------------------------------------------------------------------------ SUBMISSION DEADLINES Paper submission: December 15, 1999, Notification of acceptance: February 29, 2000 Final paper delivery: March 31, 2000 ------------------------------------------------------------------------ LOCAL ARRANGEMENTS PV2000 Organizing Committee Dept. of Electrical and Electronic Engineering University of Cagliari Piazza d'Armi 09123 Cagliari, Italy pv2000(a)diee.unica.it

1 0

Re: Megaco/H.248 reqs -06
by Tom-PT Taylor 24 Sep '99

24 Sep '99

No. I never did get to talk to you in Oslo. Sorry about that, but maybe we can get together in Redbank. Tom Taylor > -----Original Message----- > From: Irina Suconick [SMTP:isuconick@VIDEOSERVER.COM] > Sent: Tuesday, September 21, 1999 4:41 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Megaco/H.248 reqs -06 > > This document mentions H.248 MG requirements for the MIB. Is any > work being started on the MIB? > Irina. > > > > -----Original Message----- > > From: Nancy-M Greene [SMTP:ngreene@NORTELNETWORKS.COM] > > Sent: Monday, September 20, 1999 10:39 PM > > To: ITU-SG16(a)mailbag.cps.INTEL.com > > Subject: Megaco/H.248 reqs -06 > > > > The text below lists additions and clarifications made to > > <draft-ietf-megaco-reqs-05.txt>, and now found in > > <draft-ietf-megaco-reqs-06.txt>. > > > > Until it is available in the IETF I-D directory, you can get a copy of > it > > at: ftp://standards.nortelnetworks.com/megaco/docs/latest > > > > It includes clarifications asked for by ITU-T SG16 at their Berlin > > meeting. > > > > If there are no more comments on this requirements draft, then I would > > ask Tom Taylor to send it for WG last call. > > > > Note that there are references to fill in, and a few editor's notes to > > remove. I will do this in a few days if there are no other comments. > > > > Nancy > > > > > > ------------- > > > > > > 5.4. Signal/Event Processing and Scripting > > > > l. Provide an extension mechanism for implementation defined events > > and signals with, for example, IANA registration procedures. [ADD > > FOLLOWING > > SENTENCE:]It may be useful to have an Organizational Identifier (i.e. > ITU, > > ETSI, > > ANSI. . .) as part of the registration mechanism. > > > > 5.6. Test Support > > > > b. Specifically support [DELETE103, 105, and 108 ] test line operation > > [ADD] > > (e.g. > > 103, 105, 108). > > > > > > 5.8. Signalling Control > > > > Establishment and provisioning of signalling backhaul channels (via > > SIGTRAN for example is out of scope. [QUESTION: WHY was this marked as > out > > of > > scope?] Answer: it has been decided that this capability is not > > fundamental > > to the protocol, so can be kept out of scope, and handled some other > way. > > > > 6.1. Resource Status Management > > > > c. Provide a method for the MGC to request that the MG release all > > resources [ADD THE FOLLOWING] under the control of a particular MGC [END > > OF > > ADD] > > currently in use, or reserved, for any or all connections. > > > > 6.2. Resource Assignment > > > > c. Allow the use of DNS names and IP addresses to identify MGs and > > MGCs. [ADD FOLLOWING SENTENCE] This shall not preclude using other > > identifiers > > for MGs or MGCs when other non IP transport technologies for the > protocol > > are > > used. > > > > > > 8.1 MG-MGC Association Requirements > > > > b. Allow multiple MGCs to send control messages to an MG. Thus, the > > protocol must allow control messages from multiple [DELETE] IP > > [ADD]signalling > > addresses to a single MG. > > > > 7.3 MIB Requirements > > > > [ADD c.] > > c. H.248 MG MIB must support spirit of H.341 by either the MG, MGC, or > > both > > acting > > together. > > > > > > 8.2. Performance Requirements > > > > d. Support peak calling rates (e.g. in the order of 140 calls/second) > at > > the > > MGC on a moderately loaded [DELETE IP] IP network. > > > > > > 11. Requirements specific to particular bearer types > > > > Table 1: Bearer Types and Applications > > > > Bearer Type Applications Transit Network > > ================================================================ > > > > [ADD FR] > > > > Multimedia H.323 H.323 Multimedia IP, ATM, FR > > Gateway and MCU > > [REPLACE SS7 with IP, ATM, FR] > > Multimedia H.320 H.323 GW and MCU ISDN, IP, ATM, FR > > > > > > 11.1.1. Requirements for TDM PSTN (Circuit) > > > > b. Missing - inconsistent numbering - renumber section > > > > > > 11.1.3.3. Media adaptation > > > > b. Allow [ADD AAL1] AAL1/AAL2 multiple narrow-band calls to be mapped > to > > a > > single > > VCC. > > [ADD For AAL2] For AAL2, these calls are differentiated within each > > VCC > > by a AAL2 > > channel > > identifier. An AAL2 connection may span more than 1 VCC and transit > > AAL2 switching devices. ATMF standards are working on an end-to-end > > AAL2 connection identifier as part of the AAL2 signalling > > set.[REPLACE > > LAST > > SENTENCE WITH:] ITU Q.2630.1 defines an end-to-end identifier the Served > > User > > Generated Reference (SUGR). It carries information from the originating > > user > > of the > > AAL2 signalling protocol to the terminating user transparently and > > unmodified. > > > > > > 11.2.10. Multipoint Control Units > > > > [ADD g.] > > g. The ability for the MG to function as an H.323 MP, and for the MGC to > > function > > as an H.323 MC, connected by this protocol (MEGACOP/H.248). It should > be > > possible > > for audio, data, and video MG/MPs to be physically separate while being > > under the > > control of a single MGC/H.323 MC. > > -------------- > > > > > -------------------------------------------------------------------------- > > Nancy M. Greene > > Internet & Service Provider Networks, Nortel Networks > > T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com

1 0

Re: Hard Copies of Red Bank contributions
by Euchner Martin 23 Sep '99

23 Sep '99

I'm also a bit concerned about that enormous number of copies to bring in. Do we have some experiences from the Berlin Meeting, how many copies actually have been used? I assume that this number is far below 80. May be 40 is still sufficient. Alternatively, it might be a good idea to print 2 pages on one sheet in order to save trees and reduce weight! Martin. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 636-46201 | Martin Euchner Fax : +49 89 636-48000 | Siemens AG | ZT IK 3 mailto:Martin.Euchner@mchp.siemens.de | Intranet: http://zt-security.mchp.siemens.de/Standardization/ITU-T_SG16/index.html | Otto-Hahn-Ring 6 Internet: http://www.siemens.de | D-81730 Muenchen | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Karl.Klaghofer(a)ICN.SIEMENS.DE [SMTP:Karl.Klaghofer@ICN.SIEMENS.DE] Sent: Wednesday, September 22, 1999 3:37 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Hard Copies of Red Bank contributions The meeting notice states "bring 80 copies of your document to Red Bank if it should be in hardcopy". Is there a clear rule whether hard copies are required at the meeting or not ? Remark: 80 copies of voluminous contributions (e.g. updated draft standards) is a lot of pounds ! Thanks, Karl Klaghofer ------------------------------------------------ Karl Klaghofer, Siemens AG, Dpmt. ICN IB NL D1 Hofmannstr. 51, D-81359 Munich, Germany Tel.: +49 89 722 31488, Fax.: +49 89 722 37629 e-mail: karl.klaghofer(a)icn.siemens.de

2 1

Upload of White Paper for Version 6 of H.245
by mike.nilsson＠BT.COM 23 Sep '99

23 Sep '99

I have uploaded a draft of the White Paper for version 6 of H.245 to: ftp://standard.pictel.com/avc-site/Incoming/h245wcmj.zip Please send comments as soon as possible as this will have to be submitted to the ITU at the end of September. Best regards Mike Nilsson ********************************************************************** * Mike Nilsson Tel: +44 1473 645413 * * Applications Technology Group Fax: +44 1473 645011 * * Internet and Multimedia Applications Email: mike.nilsson(a)bt.com * * BT Advanced Communications Technology Centre [B54 Room 94] * * Adastral Park * * Martlesham Heath * * Ipswich IP5 3RE * * UK * **********************************************************************

3 2

Re: Upload of White Paper for Version 6 of H.245
by mike.nilsson＠BT.COM 23 Sep '99

23 Sep '99

Rich, There is nothing in the latest version of H.245 relating to this. My understanding is that we sent a liaison to SG8 identifying two possible solutions to the problem, and gave them a deadline of 18 October (i.e. The New Jersey meeting) for response. Hopefully the issue can be resolved in NJ and the result included in H.245 V6 in February. Best regards Mike ********************************************************************** * Mike Nilsson Tel: +44 1473 645413 * * Applications Technology Group Fax: +44 1473 645011 * * Internet and Multimedia Applications Email: mike.nilsson(a)bt.com * * BT Advanced Communications Technology Centre [B54 Room 94] * * Adastral Park * * Martlesham Heath * * Ipswich IP5 3RE * * UK * ********************************************************************** > -----Original Message----- > From: Rich Bowen [SMTP:rkbowen@CISCO.COM] > Sent: Wednesday, September 22, 1999 7:17 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Upload of White Paper for Version 6 of H.245 > > Mike, > > In the Berlin meeting report, APC-1644a, it was noted that there > was an inconsistency in the ASN.1 with respect to T.38. A liaison > (TD-43a) was to be sent to SG 8 suggesting two possible solutions > in H.245 v6, but no decision was indicated as to which of the > two solutions would be used. > > Do you know the current status of this issue? I noticed that neither > of the suggested solutions appears in the white paper for H.245 v6. > > Thanks, > Rich > -------------------------------------------------------------------- > Richard K. Bowen Cisco Systems, Inc. > rkbowen(a)cisco.com Research Triangle Park, NC > -------------------------------------------------------------------- > mike.nilsson(a)BT.COM wrote: > > > > I have uploaded a draft of the White Paper for version 6 of H.245 to: > > > > ftp://standard.pictel.com/avc-site/Incoming/h245wcmj.zip > > > > Please send comments as soon as possible as this will have to be > submitted > > to the ITU at the end of September. > > > > Best regards > > > > Mike Nilsson > > > > ********************************************************************** > > * Mike Nilsson Tel: +44 1473 645413 * > > * Applications Technology Group Fax: +44 1473 645011 * > > * Internet and Multimedia Applications Email: mike.nilsson(a)bt.com * > > * BT Advanced Communications Technology Centre [B54 Room 94] * > > * Adastral Park * > > * Martlesham Heath * > > * Ipswich IP5 3RE * > > * UK * > > **********************************************************************

1 0

Hard Copies of Red Bank contributions
by Karl.Klaghofer＠ICN.SIEMENS.DE 22 Sep '99

22 Sep '99

The meeting notice states "bring 80 copies of your document to Red Bank if it should be in hardcopy". Is there a clear rule whether hard copies are required at the meeting or not ? Remark: 80 copies of voluminous contributions (e.g. updated draft standards) is a lot of pounds ! Thanks, Karl Klaghofer ------------------------------------------------ Karl Klaghofer, Siemens AG, Dpmt. ICN IB NL D1 Hofmannstr. 51, D-81359 Munich, Germany Tel.: +49 89 722 31488, Fax.: +49 89 722 37629 e-mail: karl.klaghofer(a)icn.siemens.de

2 1

AW: H.450 support
by Karl.Klaghofer＠ICN.SIEMENS.DE 22 Sep '99

22 Sep '99

Alex, The B side that does not support H.450 may just ignore the received supplementary service request. I.e. ROSE at the originating side has to figure out that the other side does not support H.450 (i.e. if no return result, return error or return reject is received from B to a supplementary service request). Although the User-User Information element itself is mandatory, the h4501SupplementaryService apdu is optional. Even in Q.931, sending a STATUS message in case of "optional, unrecognized Information elements received" is just optional. I.e., I recommend not to rely on receiving a STATUS message from the B side in your scenario. In a similar case - in case of optional information element received with contents error - H.323 Implementers guide even requires to just ignore the IE (but act on the rest of the message). Note: If at least H.450.1 is supported by the B side, then B has to respond according to the "interpretation apdu" setting. Karl Klaghofer > -----Ursprüngliche Nachricht----- > Von: Alex Chatilov [SMTP:achatilov@email.msn.com] > Gesendet am: Donnerstag, 16. September 1999 07:57 > An: ITU-SG16(a)mailbag.cps.intel.com > Betreff: H.450 support > > Hello, > > I have a question about how to detect does remote endpoint supports H.450 > (without using a timer)? Is it clear that receiving endpoint has to replay > with a STATUS message in case when it receive an H.450 related FACILITY > message? > > Assume that we have: > > Originator side sent: > -------------------- > > FACILITY > FacilityIE > (length=0) > ... > User-UserIE > H323-UserInformation > h323-UU-PDU > h323-message-body = empty > ... > h4501SupplementaryService > (H.450.x request) > ... > ... > ... > > Remote side received FACILITY, here is no > support for H.450, so we will respond with > STATUS message where the causeIE = > 100 (invalid IE contents), or > 99 (Information element/parameter non-existent > or not implemented), or > 97 (Message type non-existent or not implemented) > > STATUS > ... > CauseIE > ... > cause = XX > diagnostics = YY > ... > > Am I right? > > Thank you, > Alex

1 0

Re: Megaco/H.248 reqs -06
by Brian Rosen 21 Sep '99

21 Sep '99

No, want to start such an effort? Volunteers accepted! Brian > -----Original Message----- > From: Irina Suconick [mailto:isuconick@VIDEOSERVER.COM] > Sent: Tuesday, September 21, 1999 4:41 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: Megaco/H.248 reqs -06 > > > This document mentions H.248 MG requirements for the > MIB. Is any > work being started on the MIB? > Irina. > > > > -----Original Message----- > > From: Nancy-M Greene [SMTP:ngreene@NORTELNETWORKS.COM] > > Sent: Monday, September 20, 1999 10:39 PM > > To: ITU-SG16(a)mailbag.cps.INTEL.com > > Subject: Megaco/H.248 reqs -06 > > > > The text below lists additions and clarifications made to > > <draft-ietf-megaco-reqs-05.txt>, and now found in > > <draft-ietf-megaco-reqs-06.txt>. > > > > Until it is available in the IETF I-D directory, you can > get a copy of it > > at: ftp://standards.nortelnetworks.com/megaco/docs/latest > > > > It includes clarifications asked for by ITU-T SG16 at their Berlin > > meeting. > > > > If there are no more comments on this requirements draft, > then I would > > ask Tom Taylor to send it for WG last call. > > > > Note that there are references to fill in, and a few > editor's notes to > > remove. I will do this in a few days if there are no other comments. > > > > Nancy > > > > > > ------------- > > > > > > 5.4. Signal/Event Processing and Scripting > > > > l. Provide an extension mechanism for implementation > defined events > > and signals with, for example, IANA registration > procedures. [ADD > > FOLLOWING > > SENTENCE:]It may be useful to have an Organizational > Identifier (i.e. ITU, > > ETSI, > > ANSI. . .) as part of the registration mechanism. > > > > 5.6. Test Support > > > > b. Specifically support [DELETE103, 105, and 108 ] test > line operation > > [ADD] > > (e.g. > > 103, 105, 108). > > > > > > 5.8. Signalling Control > > > > Establishment and provisioning of signalling backhaul channels (via > > SIGTRAN for example is out of scope. [QUESTION: WHY was > this marked as out > > of > > scope?] Answer: it has been decided that this capability is not > > fundamental > > to the protocol, so can be kept out of scope, and handled > some other way. > > > > 6.1. Resource Status Management > > > > c. Provide a method for the MGC to request that the MG release all > > resources [ADD THE FOLLOWING] under the control of a > particular MGC [END > > OF > > ADD] > > currently in use, or reserved, for any or all connections. > > > > 6.2. Resource Assignment > > > > c. Allow the use of DNS names and IP addresses to identify MGs and > > MGCs. [ADD FOLLOWING SENTENCE] This shall not preclude using other > > identifiers > > for MGs or MGCs when other non IP transport technologies > for the protocol > > are > > used. > > > > > > 8.1 MG-MGC Association Requirements > > > > b. Allow multiple MGCs to send control messages to an MG. > Thus, the > > protocol must allow control messages from multiple [DELETE] IP > > [ADD]signalling > > addresses to a single MG. > > > > 7.3 MIB Requirements > > > > [ADD c.] > > c. H.248 MG MIB must support spirit of H.341 by either the > MG, MGC, or > > both > > acting > > together. > > > > > > 8.2. Performance Requirements > > > > d. Support peak calling rates (e.g. in the order of 140 > calls/second) at > > the > > MGC on a moderately loaded [DELETE IP] IP network. > > > > > > 11. Requirements specific to particular bearer types > > > > Table 1: Bearer Types and Applications > > > > Bearer Type Applications Transit Network > > ================================================================ > > > > [ADD FR] > > > > Multimedia H.323 H.323 Multimedia > IP, ATM, FR > > Gateway and MCU > > [REPLACE SS7 with IP, ATM, FR] > > Multimedia H.320 H.323 GW and MCU ISDN, IP, ATM, FR > > > > > > 11.1.1. Requirements for TDM PSTN (Circuit) > > > > b. Missing - inconsistent numbering - renumber section > > > > > > 11.1.3.3. Media adaptation > > > > b. Allow [ADD AAL1] AAL1/AAL2 multiple narrow-band calls > to be mapped to > > a > > single > > VCC. > > [ADD For AAL2] For AAL2, these calls are > differentiated within each > > VCC > > by a AAL2 > > channel > > identifier. An AAL2 connection may span more than 1 > VCC and transit > > AAL2 switching devices. ATMF standards are working on > an end-to-end > > AAL2 connection identifier as part of the AAL2 signalling > > set.[REPLACE > > LAST > > SENTENCE WITH:] ITU Q.2630.1 defines an end-to-end > identifier the Served > > User > > Generated Reference (SUGR). It carries information from the > originating > > user > > of the > > AAL2 signalling protocol to the terminating user transparently and > > unmodified. > > > > > > 11.2.10. Multipoint Control Units > > > > [ADD g.] > > g. The ability for the MG to function as an H.323 MP, and > for the MGC to > > function > > as an H.323 MC, connected by this protocol (MEGACOP/H.248). > It should be > > possible > > for audio, data, and video MG/MPs to be physically separate > while being > > under the > > control of a single MGC/H.323 MC. > > -------------- > > > > > -------------------------------------------------------------- > ------------ > > Nancy M. Greene > > Internet & Service Provider Networks, Nortel Networks > > T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com >

1 0

Re: Megaco/H.248 reqs -06
by Irina Suconick 21 Sep '99

21 Sep '99

This document mentions H.248 MG requirements for the MIB. Is any work being started on the MIB? Irina. > -----Original Message----- > From: Nancy-M Greene [SMTP:ngreene@NORTELNETWORKS.COM] > Sent: Monday, September 20, 1999 10:39 PM > To: ITU-SG16(a)mailbag.cps.INTEL.com > Subject: Megaco/H.248 reqs -06 > > The text below lists additions and clarifications made to > <draft-ietf-megaco-reqs-05.txt>, and now found in > <draft-ietf-megaco-reqs-06.txt>. > > Until it is available in the IETF I-D directory, you can get a copy of it > at: ftp://standards.nortelnetworks.com/megaco/docs/latest > > It includes clarifications asked for by ITU-T SG16 at their Berlin > meeting. > > If there are no more comments on this requirements draft, then I would > ask Tom Taylor to send it for WG last call. > > Note that there are references to fill in, and a few editor's notes to > remove. I will do this in a few days if there are no other comments. > > Nancy > > > ------------- > > > 5.4. Signal/Event Processing and Scripting > > l. Provide an extension mechanism for implementation defined events > and signals with, for example, IANA registration procedures. [ADD > FOLLOWING > SENTENCE:]It may be useful to have an Organizational Identifier (i.e. ITU, > ETSI, > ANSI. . .) as part of the registration mechanism. > > 5.6. Test Support > > b. Specifically support [DELETE103, 105, and 108 ] test line operation > [ADD] > (e.g. > 103, 105, 108). > > > 5.8. Signalling Control > > Establishment and provisioning of signalling backhaul channels (via > SIGTRAN for example is out of scope. [QUESTION: WHY was this marked as out > of > scope?] Answer: it has been decided that this capability is not > fundamental > to the protocol, so can be kept out of scope, and handled some other way. > > 6.1. Resource Status Management > > c. Provide a method for the MGC to request that the MG release all > resources [ADD THE FOLLOWING] under the control of a particular MGC [END > OF > ADD] > currently in use, or reserved, for any or all connections. > > 6.2. Resource Assignment > > c. Allow the use of DNS names and IP addresses to identify MGs and > MGCs. [ADD FOLLOWING SENTENCE] This shall not preclude using other > identifiers > for MGs or MGCs when other non IP transport technologies for the protocol > are > used. > > > 8.1 MG-MGC Association Requirements > > b. Allow multiple MGCs to send control messages to an MG. Thus, the > protocol must allow control messages from multiple [DELETE] IP > [ADD]signalling > addresses to a single MG. > > 7.3 MIB Requirements > > [ADD c.] > c. H.248 MG MIB must support spirit of H.341 by either the MG, MGC, or > both > acting > together. > > > 8.2. Performance Requirements > > d. Support peak calling rates (e.g. in the order of 140 calls/second) at > the > MGC on a moderately loaded [DELETE IP] IP network. > > > 11. Requirements specific to particular bearer types > > Table 1: Bearer Types and Applications > > Bearer Type Applications Transit Network > ================================================================ > > [ADD FR] > > Multimedia H.323 H.323 Multimedia IP, ATM, FR > Gateway and MCU > [REPLACE SS7 with IP, ATM, FR] > Multimedia H.320 H.323 GW and MCU ISDN, IP, ATM, FR > > > 11.1.1. Requirements for TDM PSTN (Circuit) > > b. Missing - inconsistent numbering - renumber section > > > 11.1.3.3. Media adaptation > > b. Allow [ADD AAL1] AAL1/AAL2 multiple narrow-band calls to be mapped to > a > single > VCC. > [ADD For AAL2] For AAL2, these calls are differentiated within each > VCC > by a AAL2 > channel > identifier. An AAL2 connection may span more than 1 VCC and transit > AAL2 switching devices. ATMF standards are working on an end-to-end > AAL2 connection identifier as part of the AAL2 signalling > set.[REPLACE > LAST > SENTENCE WITH:] ITU Q.2630.1 defines an end-to-end identifier the Served > User > Generated Reference (SUGR). It carries information from the originating > user > of the > AAL2 signalling protocol to the terminating user transparently and > unmodified. > > > 11.2.10. Multipoint Control Units > > [ADD g.] > g. The ability for the MG to function as an H.323 MP, and for the MGC to > function > as an H.323 MC, connected by this protocol (MEGACOP/H.248). It should be > possible > for audio, data, and video MG/MPs to be physically separate while being > under the > control of a single MGC/H.323 MC. > -------------- > > -------------------------------------------------------------------------- > Nancy M. Greene > Internet & Service Provider Networks, Nortel Networks > T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com

1 0

Re: Security - H.235 message integrity
by Euchner Martin 21 Sep '99

21 Sep '99

Douglas, thanks a lot for the detailed explanation. I'm quite convinced now that the substitution method really works without the versioning drawback of the emptying method. As I do not have a clear feeling what the other people think about this approach; I added your substitution method as proposal to the Annex J profile for the time being. Discussion should resolve which way to go.... Regards, Martin. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 636-46201 | Martin Euchner Fax : +49 89 636-48000 | Siemens AG | ZT IK 3 mailto:Martin.Euchner@mchp.siemens.de | Intranet: http://zt-security.mchp.siemens.de/Standardization/ITU-T_SG16/index.html | Otto-Hahn-Ring 6 Internet: http://www.siemens.de | D-81730 Muenchen | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Douglas Clowes [SMTP:dclowes@OZEMAIL.COM.AU] Sent: Monday, September 20, 1999 11:55 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Security - H.235 message integrity Martin, Firstly, I hope that the mechanism for encoding the HMAC is well understood, and the reason for using HMAC-SHA1-96 (RFC-2404). Secondly, the decoding: The message which arrives is a bucket of bits, inside a TPKT. (It would be nice to have something in the TPKT to tell us whether the message contained is encrypted, but it doesn't. :-( ) If it's encrypted, assume you can tell and decrypt it. This is what the HMAC has been calculated over, with the HMAC field set to zeroes. Decode the message and extract the HMAC from the data tree. This bit string occurs in the message where the HMAC is stored, and it is a random pattern produced by the HMAC function of the sender - it is *very* unlikely to occur in the message more than once. Search the message for the bitstring, if you don't find it, check your source code and PER decoder. To be safe, copy the message to a buffer, set the located bitstring to zero in the copy, and compute the HMAC. If it matches, the message is OK. If the HMAC does not match, search from the previously located bitstring plus one. If you get a second match - copy, zero-fill, compute-HMAC and compare as before. Repeat until you get to the end of the message or match the HMAC. No re-encoding of the message is required, nor is it desirable. Apart from retrieving the HMAC from the message, the HMAC location and recomputation is completely independent of whether the message is RAS or Annex G, much less which version. Hence it is completely version-safe. For non-repudiation, you must use public-private key pairs and certificates. The message is signed by computing the HASH as above, and then encrypting that hash with the private key.The receiver computes the HASH as before, decrypts with the public key, and compares the result. If they match, the message is OK, and was created by the holder of the private key. If a proxy is to change components, then the proxy will have to recompute the MAC (keyed or signed) using its own credentials. In this case it is the proxy that is attempting to guarantee the integrity and authenticity of the message, so the EP MAC is destroyed. If you want to just authenticate just a few fields, so a proxy/firewall can change parts of the message, and the other endpoint can check the few, it is best to compute the authentication code on the unencoded fields. This can be done in a hashed CryptoToken, with the hashed values included or not in the CryptoToken. Extreme care must be taken to ensure that the rules for encoding the ToBeHashed are well specified. Regards, Douglas At 19:08 1999-09-20 +0200, Euchner Martin wrote: >Douglas, > >first of all, I'm glad to see a very interesting and fruitful discussion here. Thus, I would rather carry on these specific topics about the syntax and procedures on the SG16 discussion list and hear also other people's opinions about that. > [snip]

1 0