- sg16-avd - lists.packetizer.com

Fw: Contribution number
by Noriko Hosokawa 24 Sep '99

24 Sep '99

Dear Mr.Francois Audet In response to your request, APC-1656 and APC-1657 have been allocated to your contributions. > Source: Nortel Networks APC-1656 > Title: Tunnelling of signalling messages in H.225.0 APC-1657 > Title : Applicability of signalling tunnelling mechanism to Q.SIG 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 *********************************************************** Documents for Q.12-14/16 Rapporteur meeting in Red Bank (18-22 October 1999) The documents can be retrieved as ftp://standard.pictel.com/avc-site/9910_Red/APC-1???.??? or http://standard.pictel.com/ftp/avc-site/9910_Red/APC-1???.??? ------------------------------------------------------------------------ APC- Source Title ------------------------------------------------------------------------ 1645 TIPHON Proposal for an H.323 "Security Profile" 1646 Motorola Annex-H(User and Service Mobility in H.323) 1647 Lucent Mobility Agents in H.323 Reference Architecture 1648 Lucent Registration Procedure for Wireless Mobile H.323 Terminals 1649 Lucent Mobility States for the Mobile H.323 Terminals 1650 Lucent H.245 Generic Capabilities Definition and H.225 Packetization Specification for the Cellular/PCS CDMA EVRC Voice Codec. 1651 AT&T H.323 Mobility Architecture and Protocol for Terminal, User, and Service Mobility 1652 AT&T Viewgraph Presentation of H.323 Mobility Architecture and Protocol for Terminal, User, and Service Mobility 1653 PictureTel Proposed text for G.722.1 capabilities in the H.323 Implementor's Guide 1654 Nortel ISO/IEC 11571 addressing in H.323 Annex V Networks 1655 Hitachi Ltd. Real-time system of H.262 layered video transmission 1656 Nortel Networks Tunnelling of signalling messages in H.225.0 1657 Nortel Networks Applicability of signalling tunnelling mechanism to Q.SIG 1658 Editor (K Klaghofer) Draft H.450.9 Call Completion Supplementary Services for H.323 1659 1660 1661 ---------------------------------------------------------------------------- ----

1 0

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

APC Document number
by Noriko Hosokawa 21 Sep '99

21 Sep '99

Dear Mr.Toshiaki Suzuki In response to your request, APC-1655 has been allocated to your contribution. APC-1655 > Title : Real-time system of H.262 layered video transmission > Source : Hitachi Ltd. 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 *********************************************************** Documents for Q.12-14/16 Rapporteur meeting in Red Bank (18-22 October 1999) The documents can be retrieved as ftp://standard.pictel.com/avc-site/9910_Red/APC-1???.??? or http://standard.pictel.com/ftp/avc-site/9910_Red/APC-1???.??? ------------------------------------------------------------------------ APC- Source Title ------------------------------------------------------------------------ 1645 TIPHON Proposal for an H.323 "Security Profile" 1646 Motorola Annex-H(User and Service Mobility in H.323) 1647 Lucent Mobility Agents in H.323 Reference Architecture 1648 Lucent Registration Procedure for Wireless Mobile H.323 Terminals 1649 Lucent Mobility States for the Mobile H.323 Terminals 1650 Lucent H.245 Generic Capabilities Definition and H.225 Packetization Specification for the Cellular/PCS CDMA EVRC Voice Codec. 1651 AT&T H.323 Mobility Architecture and Protocol for Terminal, User, and Service Mobility 1652 AT&T Viewgraph Presentation of H.323 Mobility Architecture and Protocol for Terminal, User, and Service Mobility 1653 PictureTel Proposed text for G.722.1 capabilities in the H.323 Implementor's Guide 1654 Nortel ISO/IEC 11571 addressing in H.323 Annex V Networks 1655 Hitachi Ltd. Real-time system of H.262 layered video transmission 1656 1657 ---------------------------------------------------------------------------- ----

1 0

Megaco/H.248 reqs -06
by Nancy-M Greene 21 Sep '99

21 Sep '99

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 Douglas Clowes 20 Sep '99

20 Sep '99

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

Contribution uploaded
by Francois Audet 20 Sep '99

20 Sep '99

Contribution APC-1654 ISO/IEC addressing in H.323 Appendix V has been uploaded to the incoming directory. ----- François Audet Tel:+1 408 565 5675 mailto:audet@NortelNetworks.com <mailto:audet@NortelNetworks.com> Nortel Networks Fax:+1 408 565 2375 http://www.NortelNetworks.com <http://www.nortelnetworks.com/>

1 0

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

20 Sep '99

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. All my comments are in the text below. 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 3:00 AM To: Euchner Martin Cc: El-Gebaly, Hani; inowag(a)imtc.org Subject: RE: Security At 14:10 1999-09-17 +0200, Euchner Martin wrote: >Douglas and Hani, > > >first I would like to confirm, that Annex J applies the method as described by Hani in a previous mail. > >Let's assign some mnemonics to the procedures on the table for easier discussion and let's call this method the "emptying method" as the ICV/hash field is emptied before the calculation. > >Douglas proposed two alternative methods for computing ICVs or hash values: >The first method - let's call it the "substitution method" for short - works in a similar way as the emptying method except that there is only one ASN.1 pass and the hash/icv value has to be located in the coded ASN.1 by a particular (unambiguous) bit pattern. > >I would name the other proposed method as the "envelope method" as new ASN.1 syntax is put around the protected message. > >While it is true that the emptying method suffers from the versioning problem, I do not quite understand why this does not apply also to the substitution method. How does a receiver with a lower protocol version know which fields to exclude the recomputation of? Also I doubt that the trail and error method for locating the bitpattern is efficient. Firstly, I am assuming that the Message Authentication Code ((H)MAC) is being performed over the entire message. I'm not sure if this assumption is common to us all, hence I am explicitly stating it here. This implies that there are *no* fields to be excluded from any recomputation. This is correct. In "authenticaton & integrity" mode of Annex J, the (H)MAC is computed over the entire message after the message has been ASN.1 encoded into a bitstring. This step is done by the sender as well as the receiver. For your substitution method, I think you are right and the method described should work without any versioning problems. I guess that the crucial procedure at the receiver is roughly as follows: 1) receive the message 2) locate and find the sender's hash value; call this result RV. Actually, how does the receiver know where to find the hash bits in the message bitstring? The position of the hash value may vary from one RAS message to another. This sounds like a problem.... Any ideas please? The only way I could think of is to ASN.1 decode the message, and then re-encode it with a known (default) pattern and find that pattern in the received message. The position of the hash value in the received message should correspond to the found position of the known pattern. Is it guaranteed that this procedure works independently of protocol versions??? 3) reset the hash value bits in the received message to some default pattern, then recompute the keyed hash over the message; call the result HV 4) compare HV == RV etc .... Since the computation is over a bit string of unknown/indeterminate construction, versioning cannot affect the result, because at the time you generate or check the hash, you don't even care that it's an encoded message, much less PER encoded, or even ASN.1, or even RAS/Annex G - it's just a bit string. If I'm not clear on that, let me know and I'll try again to explain it. Secondly, as long as the "bitpattern" is sufficiently random, it is very unlikely to occur in the message randomly - one in 2^96, 2^128, or 2^160 depending on algorithm. Of course, if one uses zeroes or spaces or the gatekeeperId, it's more likely, but if one uses the HMAC from the previous message as the bitpattern, you might get a collision every few years/millenia. > >I'm not quite certain whether I fully understood the envelope method. Is it true that the BESTP could be a RRQ for example, while the ABESTP would be the actual message sent through the wire? How does this method address the versioning issue? What happens when BESTP sees some extensions? Again, the versioning is not an issue, because the thing that is being signed/encrypted is just a bitstring. The checking/decrypting independent of the contents. It's an encapsulation or tunnelling mechanism, independent of what is being encapsulated or tunnelled. >If this is the case then it is probably already far too late for changing to the envelope method if it works at all. It appears to me that H.225.0 would have to be changed fundamentally. Well, not really too late, and it could be made to work, but that is more properly a subject for the SG16 list, rather than the iNOW! list. Since the GRQ/GCF can indicate that the enveloped method is supported, and should be employed, it's just a simple versioning issue. This will test my understanding of ASN.1 and PER encoding... (someone correct me if I'm wrong). In H.225.0, RasMessage is a PDU and is identified in the encoded message by a tag value. I believe that H323-UserInformation is another. These are differentiated in an inbound PDU by their tag value (and channel). Let's invent a new H.225.0 PDU call SecurityMessage, defined as: SecurityMessage ::= SEQUENCE { encryptionAlgorithm OBJECT IDENTIFIER OPTIONAL, encryptionParams ParamS OPTIONAL, signatureAlgorithm OBJECT IDENTIFIER OPTIONAL, signatureParams ParamS OPTIONAL, messageText OCTET STRING, signatureText OCTET STRING OPTIONAL } toBeSecured TYPE-IDENTIFIER.&Type(RasMessage) The message could be signed, or encrypted, or signed and encrypted, or neither (in which case it should be just a plain RAS message). * Signed only: encode the RAS PDU into the toBeSecured octet string, and place in the messageText OCTET string. Compute the signature into signatureText. Set signatureAlgorithm and signatureParams with appropriate values. * Encrypted only: encode the RAS PDU into the toBeSecured OCTET string and encrypt, placing the ciphertext result into messageText. Set encryptionAlgorithm and encryptionParams with appropriate values. * Signed and Encrypted: encode the RAS PDU into the toBeSecure OCTET STRING. Compute the signature into signatureText. Encrypt toBeSecured into messageText. Set the algorithm OIDs and params with appropriate values. Possible variations include: o Encrypt the signatureText with the same algorithm and params used on messageText. o Next the signature structure within the encrypted structure - SecurityMessage ::= SEQUENCE { encryptionAlgorithm OBJECT IDENTIFIER OPTIONAL, encryptionParams ParamS OPTIONAL, encryptedText OCTET STRING, } SignedRasMessage { signatureAlgorithm OBJECT IDENTIFIER OPTIONAL, signatureParams ParamS OPTIONAL, signatureText OCTET STRING OPTIONAL, signedText OCTET STRING } ToBeEncrypted TYPE-IDENTIFIER.&Type(SignedRasMessage) ToBeSigned TYPE-IDENTIFIER.&Type(RasMessage) The process: encode the RAS message, as ToBeSigned, into signedText. If signing, set signatureAlgorithm and signatureParams and calculate signatureText. Encode SignedMessage into encryptedText. If encrypting, set encryptionAlgorithm and encryptionParams, and encrypt encryptedText. In either case, and in H.235 as it stands, ParamS would be redefined as: ParamS ::= SEQUENCE { ranInt INTEGER OPTIONAL, iv8 IV8 OPTIONAL, ..., keySequenceId INTEGER(0..??) OPTIONAL } to accommodate a change in keys for delayed and out of order message delivery. >Finally, the ICV field is no longer always at the end of the message as certain H.225.0 v3 RAS messages have been extended by new fields since version 2. Well, I had the H.225.0 AnnexG messages in mind when I said that, and even then, it's not literally true. But it doesn't matter logically, as long as you can find the correct part. >Comments please. > > >Regards > >Martin. > Regards, Douglas

1 0

Re: Questions on H.235
by Euchner Martin 20 Sep '99

20 Sep '99

Douglas, please see my answers below in the text. 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 1:38 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Questions on H.235 At 12:01 1999-09-17 +0200, Euchner Martin wrote: >Douglas, > >as I pointed out in a former email, I'm adding the source identifier to the ClearToken in H.235v2. As you said this will improve the security. > > >On the other hand however, there is a specific problem using the destination identifier on multicast RAS messages like GRQ for example: Most of the recipients would then think that the received message is not destined for them. This was therefore the reason to use the source identifier instead of the destination identifier on GRQ (in violation of ISO protocols). > >For unicast RAS messages, I could add the destination identifier of course. But I do not know how to handle the multicast RAS message in a better way. Using This would result at least in a partial improvement. OK, I forgot the multicast case. However, the generalId should, IMHO, be either that of the recipient (unicast) or not present (multicast), rather than that of the sender as shown. H.235v2 fixes this. >Yes, H.235v2 is on its way and I am already preparing a new, improved version. You will see this version at the upcoming Rapporteurs meeting in October soon. So far, no modified version of H.235 has been presented. While you're at it, 10.3.2 method for forming a key from a password is embarrassingly weak. A short password ('X' for example) produces a key which is mostly zero bits. Even a longer pass phrase will prod use a key with high order bits set to zero in each byte, and similar characteristics reducing a keys strength significantly. Most credible schemes would use a hash function (MD5 or SHA1) over the pass phrase, and would not fill out the pass phrase with zeroes. The amount of entropy in such a key will be very low, and one should not use such a key for bulk encryption. To do so would provide an attacker with a large amount of cryptotext, some of which will be known, enabling a known-cryptotext attacks. An additional key generation/exchange mechanism should be employed. It is true that 10.3.2 does not provide absolute security . A more secure way would be to use hashed passwords instead of the plain PW as you wrote. However, the entropy does not increase effectively by hashing. Thus, implementations should check and avoid weak passwords by some means. Anyway, the (hashed) password is not applied to bulk encryption; rather it is used for registration and authentication purposes. >Denial of service attacks: It seems that this is an issue as you described. A good countermeasure is to include a sequence number into the signed message. The receiver should check the sequence number and should verify the signature before proceeding any further. This should be fixed as well in H.235v2. In UDP based protocols, strict sequencing is not possible, because message order and delivery and duplication are not guaranteed. An eavesdropper can easily generate a sequence number in the range, so a legitimate message will duplicate an illegitimate message sequence number. A signature is a more secure check. a) correct: strict sequencing on UDP does not work. RAS/Annex J uses the randomVal as a counter, making several messages with the same timestamp unique. This allows to detect duplicated messages. b) When message integrity is applied to the entire message, an attacker no longer is able to generate fake messages just by guessing the counter, as the attacker cannot compute the correct hash without possessing the password. >Generally, I agree with you that the procedure described in B.4.2 using the XOR does not really provide any reasonable security. This method just provides a certain (instance) authentication of just one message field (the GK-identifier); any other field in the RAS message is not authenticated or protected by any means; thus replay or modification attacks on these parts are possible without detection. To be honest with you, I don't like procedure B.4.2 either for these reasons. Anyway, B.4.2 due to its weak security is therefore not part of H.323 Annex J. Good. It should not be part of H.235 either. Even if we all agree to remove B.4.2, does the ITU procedure (maintaining backwards compatibility) allow us to do? >A much more secure protocol is thus being applied in H.323 Annex J: Protection of the entire RAS message using either HMAC-SHA1 (with a symmetric key/password) and rapid integrity checking, or an RSA-SHA1/RSA-MD5 digital signature. I understand that HMAC-xxx-96 gives away less information on the key, and should be preferred for a long term password based mechanism. Sounds as a good suggestion. Annex J will reflect this change. >Let me just mention that when a message gets lost, B.4.2 says that the most recent random should be used. Trouble is that, for a time, neither party knows that a message is lost. If I send you an xRQ and you send me a new random in the xCF, which random do you use to check my next message? It needs to be different depending on whether the xCF was lost or not. If you use the new one, and my next transmission is a retransmit of the original xRQ, will you reject it because it doesn't use the new random? You will have to check both. If I send you an xRQ that lives for a while in a router queue, receive a new random and use it in a message that arrives at you before the earlier one (out of order reception happens) and you check it against the new random, it matches. When the first message arrives, it has the old random. Will you reject it or ignore it? Either way, will I understand that I have to recompute it and send it again. If you reject it, I may fail the operation. If you ignore it, I may resend the same bit-pattern with the old random. This issue is closely linked with B.4.2; luckily, Annex J does not reference it. >Diffie-Hellman on Call Signaling channel: H.323 Annex J addresses two scenarios: In a small closed environment with shared secrets among all the participants. Then "signing" Diffie-Hellman tokens can be done by the shared secret and using an HMAC-SHA1 (see the baseline profile). The much more scaleable scenario is satisfied with digital certificates and cryptographic signature upon the Diffie-Hellman tokens (see the sophisticated profile). Again, HMAC-SHA1-96 seems the preferred mechanism in IPsec (RFC-2403 and 2402). see some lines above: Annex J will use the truncated hashing I agree with you there, but wonder if it's better to sign the entire message, just the DH component, or both. Actually, Annex J offers both methods: signing the entire message or signing only a subset including the DH params. Regards, Douglas >Regards, > >Martin.

1 0

Media Gateway Control 99 : Call for paper
by Peter Lewis 20 Sep '99

20 Sep '99

Paris, France, 15-17 December 1999 Media Gateway Control 99 Conference. MGCP, Megaco, H.248. How to assure convergence between IP and PSTN networks. Technical challenges, trials, interoperability tests, normalization work. Call for papers: www.upperside.fr/bamgc.htm Thanks

1 0

reminder for Red Bank meeting
by Glen Freundlich 20 Sep '99

20 Sep '99

Dear Colleagues, This is just a reminder that the hotel where we are holding the upcoming Q.11-15 meeting will hold a block of rooms until this Wednesday, 22 September. Also, please remember to register for the meeting as described in the meeting announcement so that we can plan for the size of the meeting. Regards, Glen -- Glen Freundlich ggf(a)lucent.com Lucent Technologies office: +1 303 538 2899 11900 N. Pecos fax: +1 303 538 3907 Westminster, Colorado 80234 USA

1 0

Re: Queries on RAS security !!
by Euchner Martin 20 Sep '99

20 Sep '99

Aparna, please note, that Jim Toga is no longer editor of H.235. I took over responsibility to carry on H.235 version 2. Anybody with questions, suggestions and improvements should get in touch with me therefore. 1. Relation of registration info by GK: The GK can associate the registration information through the delivered endpointID and callID. Further on, commercially available stacks offer identifications means by messages handles or simply IP addresses for example. All this could be useful in keeping track of state and context. 2. Key update: H.235 offers a key update (key refreshment) procedure for the media session key; this procedure is not applicable to RAS for the following reasons: a) Passwords are subscription-based information. The subscription procedure (registration, obtaining, refreshing PWs) are not part of the recommendation. This all can be achieved by some means out-of-band. By such a procedure you can also refresh your passwords of course. b) Diffie-Hellman keys act as a master key. There is no explicit key update procedure for such keys. Implicitly, you could terminate (close) the connection and immediately re-open/reregister; thereby establishing automatically a new key. 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: Aparna Saha [SMTP:apsaha@HSS.HNS.COM] Sent: Monday, September 20, 1999 6:45 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Queries on RAS security !! Hi Jim, I have a few queries related to H.235, specifically, RAS security. This is regarding the RAS procedures for authentication . During the GRQ-GCF exchange, the security info ( the secret key and the algorithmId ) gets established with the GK. For the subsequent RRQ, how does the GK relate the RRQ with the info stored ? Is there any mechanism for refreshing keys in RAS ? Thanks and regards, Aparna.

1 0

Registration of participation and contribution
by Sakae OKUBO 20 Sep '99

20 Sep '99

Dear Q12-14/16 experts, This is to encourage you to make the subject registrations as soon as possible. Rapporteurs need the final approval of the SG16 management for holding the Red Bank meeting where indication of a sufficient number of participants and contributions are required. 1. Registration of participation To register your meeting attendance, please send an e-mail registration of the following form: To: rrroy(a)att.com, eileen.patterson(a)ascend.com Cc: okubo(a)giti.or.jp, dskran(a)ascend.com, ggf(a)lucent.com, tom.geary(a)conexant.com, garysull(a)microsoft.com Subject: Red Bank meeting registration Name: Company: Arrival: Departure: Special needs: 2. Registration of contributions /// Registration of the document: by 8 October (Friday) /// /// Distribution of the document: by 11 October (Monday) /// /// Use the ftp site (or e-mail reflector) for distribution /// When you are going to submit a document, please notify S. Okubo as soon as possible, by 8 October (Friday) at the latest. Document number (APC-1nnn) will be allocated. Early indication of your submission plan is welcome and encouraged. 3. Further details Please see the meeting notice: ftp://standard.pictel.com/avc-site/9910_Red/Notice_Red_Bank.txt or http://standard.pictel.com/ftp/avc-site/9910_Red/Notice_Red_Bank.txt 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 ***********************************************************

1 0

Queries on RAS security !!
by Aparna Saha 20 Sep '99

20 Sep '99

Hi Jim, I have a few queries related to H.235, specifically, RAS security. This is regarding the RAS procedures for authentication . During the GRQ-GCF exchange, the security info ( the secret key and the algorithmId ) gets established with the GK. For the subsequent RRQ, how does the GK relate the RRQ with the info stored ? Is there any mechanism for refreshing keys in RAS ? Thanks and regards, Aparna.

1 0

APC Document Numeber
by Noriko Hosokawa 20 Sep '99

20 Sep '99

Dear Mr. Francois Audet In response to your request, APC-1654 has been allocated to your contribution. APC-1654 > Title: ISO/IEC 11571 addressing in H.323 Annex V > Source: Nortel Networks 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 *********************************************************** Documents for Q.12-14/16 Rapporteur meeting in Red Bank (18-22 October 1999) The documents can be retrieved as ftp://standard.pictel.com/avc-site/9910_Red/APC-1???.??? or http://standard.pictel.com/ftp/avc-site/9910_Red/APC-1???.??? ------------------------------------------------------------------------ APC- Source Title ------------------------------------------------------------------------ 1645 TIPHON Proposal for an H.323 "Security Profile" 1646 Motorola Annex-H(User and Service Mobility in H.323) 1647 Lucent Mobility Agents in H.323 Reference Architecture 1648 Lucent Registration Procedure for Wireless Mobile H.323 Terminals 1649 Lucent Mobility States for the Mobile H.323 Terminals 1650 Lucent H.245 Generic Capabilities Definition and H.225 Packetization Specification for the Cellular/PCS CDMA EVRC Voice Codec. 1651 AT&T H.323 Mobility Architecture and Protocol for Terminal, User, and Service Mobility 1652 AT&T Viewgraph Presentation of H.323 Mobility Architecture and Protocol for Terminal, User, and Service Mobility 1653 PictureTel Proposed text for G.722.1 capabilities in the H.323 Implementor's Guide 1654 Nortel ISO/IEC 11571 addressing in H.323 Annex V Networks 1655 1656 ---------------------------------------------------------------------------- ----

1 0

Re: Questions on H.235
by Douglas Clowes 19 Sep '99

19 Sep '99

At 12:01 1999-09-17 +0200, Euchner Martin wrote: >Douglas, > >as I pointed out in a former email, I'm adding the source identifier to the ClearToken in H.235v2. As you said this will improve the security. > > >On the other hand however, there is a specific problem using the destination identifier on multicast RAS messages like GRQ for example: Most of the recipients would then think that the received message is not destined for them. This was therefore the reason to use the source identifier instead of the destination identifier on GRQ (in violation of ISO protocols). > >For unicast RAS messages, I could add the destination identifier of course. But I do not know how to handle the multicast RAS message in a better way. Using This would result at least in a partial improvement. OK, I forgot the multicast case. However, the generalId should, IMHO, be either that of the recipient (unicast) or not present (multicast), rather than that of the sender as shown. >Yes, H.235v2 is on its way and I am already preparing a new, improved version. You will see this version at the upcoming Rapporteurs meeting in October soon. So far, no modified version of H.235 has been presented. While you're at it, 10.3.2 method for forming a key from a password is embarrassingly weak. A short password ('X' for example) produces a key which is mostly zero bits. Even a longer pass phrase will prod use a key with high order bits set to zero in each byte, and similar characteristics reducing a keys strength significantly. Most credible schemes would use a hash function (MD5 or SHA1) over the pass phrase, and would not fill out the pass phrase with zeroes. The amount of entropy in such a key will be very low, and one should not use such a key for bulk encryption. To do so would provide an attacker with a large amount of cryptotext, some of which will be known, enabling a known-cryptotext attacks. An additional key generation/exchange mechanism should be employed. >Denial of service attacks: It seems that this is an issue as you described. A good countermeasure is to include a sequence number into the signed message. The receiver should check the sequence number and should verify the signature before proceeding any further. This should be fixed as well in H.235v2. In UDP based protocols, strict sequencing is not possible, because message order and delivery and duplication are not guaranteed. An eavesdropper can easily generate a sequence number in the range, so a legitimate message will duplicate an illegitimate message sequence number. A signature is a more secure check. >Generally, I agree with you that the procedure described in B.4.2 using the XOR does not really provide any reasonable security. This method just provides a certain (instance) authentication of just one message field (the GK-identifier); any other field in the RAS message is not authenticated or protected by any means; thus replay or modification attacks on these parts are possible without detection. To be honest with you, I don't like procedure B.4.2 either for these reasons. Anyway, B.4.2 due to its weak security is therefore not part of H.323 Annex J. Good. It should not be part of H.235 either. >A much more secure protocol is thus being applied in H.323 Annex J: Protection of the entire RAS message using either HMAC-SHA1 (with a symmetric key/password) and rapid integrity checking, or an RSA-SHA1/RSA-MD5 digital signature. I understand that HMAC-xxx-96 gives away less information on the key, and should be preferred for a long term password based mechanism. >Let me just mention that when a message gets lost, B.4.2 says that the most recent random should be used. Trouble is that, for a time, neither party knows that a message is lost. If I send you an xRQ and you send me a new random in the xCF, which random do you use to check my next message? It needs to be different depending on whether the xCF was lost or not. If you use the new one, and my next transmission is a retransmit of the original xRQ, will you reject it because it doesn't use the new random? You will have to check both. If I send you an xRQ that lives for a while in a router queue, receive a new random and use it in a message that arrives at you before the earlier one (out of order reception happens) and you check it against the new random, it matches. When the first message arrives, it has the old random. Will you reject it or ignore it? Either way, will I understand that I have to recompute it and send it again. If you reject it, I may fail the operation. If you ignore it, I may resend the same bit-pattern with the old random. >Diffie-Hellman on Call Signaling channel: H.323 Annex J addresses two scenarios: In a small closed environment with shared secrets among all the participants. Then "signing" Diffie-Hellman tokens can be done by the shared secret and using an HMAC-SHA1 (see the baseline profile). The much more scaleable scenario is satisfied with digital certificates and cryptographic signature upon the Diffie-Hellman tokens (see the sophisticated profile). Again, HMAC-SHA1-96 seems the preferred mechanism in IPsec (RFC-2403 and 2402). I agree with you there, but wonder if it's better to sign the entire message, just the DH component, or both. Regards, Douglas >Regards, > >Martin.

1 0

Re: [Fwd: Re: [Fwd: [Fwd: [Fwd: Re: H.323 mobility first draft]]] ]
by Roy, Radhika R, ALARC 17 Sep '99

17 Sep '99

Hi Ed: I appreciate your reply. To support wireless handset in pure H.323 environment, we may think couple of scenarios: 1. Wireless LAN, 2. H.323 Wireless handset (2a. WAU that is NOT aware of H.323, 2b. WAU that is H.323-aware), and 3. (Non-H.323) wireless handset interfacing an H.323 system via a IWF (GW). In addition, we also have situations what mobile IP [IETF] is dealing with. I would call this as scenario 4. H.323 needs not to be aware of the radio link environment in scenarios 1 and 2a and, the H.323 mobility solution is independent of the lower link layer. The general H.323 mobility problem needs to address intra-zone, inter-zone, and inter-domain mobility management (change of point-of-attachment [network, zone, domain]) before bringing the radio link issues. In this context, we need to address (GK) discovery, registration, location updates, call establishment, roaming, and handover in the H.323 layer. We will find that H.323 needs extensions to support mobility. In scenario 2b (I guess is that your contribution is primarily concerned with) is a special case. That is, WAU is both H.323- and radio link-ware. As a result, your contribution is proposing some extensions in H.323 to deal with this situation. This is a very interesting situation that we need to consider as a special case. What I would suggest that let us address this situation in the light of cases 1, 2a, and 4 where the H.323 mobility solution is provided without being aware of the radio link. Then, we need to address scenario 4: For example, cellular-PSTN and H.323 Mobile system interworking. We have drafted this requirement as the "INTERWORKING." In this context, we might see that H.323 may need more extensions to support mobility. That is, the radio traffic that you are concerned with may be dealt later once we see that we have solved the mobility problems in the H.323 layer. Then, we can apply it in some specific scenarios like the radio environment as you have started (scenario 2b). The point is that the general solution should also be capable to solve the problem that you have undertaken (if needed some extensions can be made). The question is: what would be the approach to solve the H.323 mobility in the H.323 layer? The paper of W. Liao published in the INFOCOM'99 conf provides some ideas. This paper might be a good start to solve the mobility problem in the H.323 layer. However, we have to go a long way to meet all requirements of mobility in H.323 beyond what has been discussed in this paper. As APCs indicated, more contributions (e.g., AT&T, Lucent, others) are coming in the upcoming Red Bank (Oct 18-22) conf. With respect to the MC (not necessarily MCU) to provide the handoff, it can be placed with the GK, GW, or other entities (e.g., WAU) as needed. This might be an option for implementations. However, handoff will be in the H.323 layer (Please also see the above paper). Then, we can translate this into the corresponding radio layer. The handoff in the radio layer can be implementation specific. In fact, we might need all functionalities that you have proposed in the radio layer. Again, your contributions have provided valuable insights to address H.323 mobility problems. Hope this will help. Best regards, Radhika > -----Original Message----- > From: Edgar Martinez [1] [SMTP:martinze@CIG.MOT.COM] > Sent: Wednesday, September 15, 1999 10:44 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: [Fwd: Re: [Fwd: [Fwd: [Fwd: Re: H.323 mobility first > draft]]]] > > Hi Roy, > > Just to take this off-line for the moment, but only for clarification. > > If we support a H.323 wireless handset in a pure H.323 environment. Where > do > you see the AIR interface access to the H.323 network? In the context > of a pure IP mobile network without interworking. What I mean is do > we only provide a BTS access to the network run all the radio traffic > through > the > network. Or do we provide something like a RAN (WAU) > to handle the radio traffic on the edges?. > > The radio traffic that I been mentioning is not directly related to H.323 > call > setup > that is Mobile Terminal paging and all radio channel management functions. > > But, whether we use a BTS or WAU for wireless access to the IP > network will greatly influence the way we do handovers in a pure > IP network. This does not affect roaming. > > One suggestion you provided on handover was using the MCU, > I could work with that. But something like the WAU can provide > the MCU function in the edges between H.323 (MT to MT), or MT to PC. > Since the only device that requires handover is the wireless > Mobile Terminal (MT). > > Best Regards, > > Ed > > > "Roy, Radhika R, ALARC" wrote: > > > Hi Ed: > > > > I understand your approach. Your approach is an INTERWORKING between the > > H.323 and PSTN-Wireless networking environment. > > > > First, we need to solve all mobility problems in the H.323 layer. Once > we > > solve H.323 mobility problems in a transport independent way, we can > then > > implement that solution in a special "INTERWORKING" environment: H.323 > > system (e.g., IP network) with an interface (e.g., WAU) to the > PSTN-wireless > > system. > > > > There are two steps: 1. Solve the mobility problems in H.323 layer > > (Terminal, User, and Service Mobility) and 2. Implement the H.323 > mobility > > problems in specific networking environments for "Interworking". > > > > The H.323 mobility problems solved in the H.323 layer should be > applicable > > for all circumstances. For example, > > > > 1. Mobile IP (IETF) > > 2. PSTN-wireless (PLMN) > > 3. Emerging mobile and wireless networks > > > > That is, the general H.323 mobility solution will also complement the > > solution that you are proposing. There may be some differences in > approach > > that you are proposing, but it (H.323 mobility) will achieve the same > > objectives what your contribution is up to. In fact, I welcome your > > contribution because it has provided us valuable insights of the > mobility > > problems in the context of H.323 and PSTN-Wireless networking > environment. > > > > Best regards, > > Radhika > > > > > -----Original Message----- > > > From: Edgar Martinez [1] [SMTP:martinze@CIG.MOT.COM] > > > Sent: Tuesday, September 14, 1999 9:21 PM > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > Subject: Re: [Fwd: Re: [Fwd: [Fwd: [Fwd: Re: H.323 mobility first > > > darft]]]] > > > > > > Thank you all for your comments. > > > > > > Roelands Marc wrote: > > > > > > > Hi all, > > > > > > > > I am struggling with some conceptual problems concerning the Annex-H > > > > proposal of Edgar Martinez, feeling that this has some commonality > with > > > the > > > > remarks of Roberto Winkler and Simon Binar on it. IMHO, the proposed > > > > architecture, and especially the WAU and the GK, are mixing all > kinds of > > > > mobility related functionality in a single, strongly coupled, > > > > do-it-all-in-H.323 layer, involving radio access up to H.323 > application > > > > layer. > > > > > > I believe there is a clear separation of functional requirements > between > > > the > > > radio control > > > functions of the WAU, and the Network control and Mobility Management > > > functions > > > in the GK. Would it make everyone happy if we called WAU RAN? For > network > > > efficiency > > > the WAU would handle all the Radio link resources at the edges, > thereby > > > preventing > > > traffic overloading on the network. > > > > > > > > > > > > > > > Specifically, I have some difficulties with the following: > > > > > > > > 1. No clear division in terminal and user mobility aspects in the > basic > > > > H.323 architecture is taken as a starting point: shouldn't there be > > > > specified somewhere in general, in conjunction with the H.323 set of > > > > protocols, that IP addresses represent terminals in an IP network, > and > > > that > > > > users can only be represented by logical names from a directory > (i.e. > > > > aliases), and whether an "endpoint" is a user or a terminal? If this > is > > > > decided on, the H.323 registration procedure is just what is needed > to > > > have > > > > user mobility, by dynamically associating a logical user name with > one > > > or > > > > multiple terminals upon user request. With terminals identified by > IP > > > > addresses, terminal mobility would further be strictly a network > access > > > > problem. > > > > > > > > 2. Annex-H is supposed to handle user and service mobility, so why > would > > > the > > > > handover problem, as any other terminal mobility related problem, be > > > handled > > > > here instead of independently in Annex-I? > > > > > > In the second day of the Ad-hoc SG-16 meeting, some of us discussed, > > > the possibility of combining Annex H and I, if no contributions came > > > in for Annex-I. > > > > > > > > > > > > > > > > > > 3. Mobility is not an issue in H.323 alone, e.g. consider roaming > and > > > > handover for a connection-oriented data application, so why should > it be > > > > handled in H.323 on its own? Or put otherwise, is H.323 support > really > > > > required on a terminal in order to be able to roam, as a user of > some > > > > service, or as a terminal accessing a network? > > > > > > I specifically asked where do we focus, and was told to assume that > > > there will be H.323 wireless sets. And focus only on H.323 terminals, > > > to get the work started. And that other types of terminals would > > > be handled separately. > > > > > > > > > > > > > > > 4. Although the proposal pays attention to the identification of > several > > > > degrees of locality for roaming and handover, solving all control > issues > > > > (radio access, IP-networking, etc.) in a single application layer > still > > > > leads to both resource sub-optimality and complexity. E.g. why > should > > > the > > > > WAU be aware of anything having to do with (user) mobility > management? > > > > > > I believe there is a misunderstanding the mobility management > > > and services is handle by in the network e.g, GK. > > > The Radio Resource management is at the edges which is aware > > > of the terminals radio links. > > > > > > > > > > > > > > > Instead I would propose to use an approach of highly independent > layers, > > > > following good Internet tradition, and solving the problems as > locally > > > as > > > > possible (both geographically and architecturally). Here's the > layers I > > > > think at least should be distinguished: > > > > > > > > - MAC level: terminal micro-mobility across radio cells, ethernet > > > segments, > > > > etc. can exist without any consciousness of this at the IP level > (e.g. > > > using > > > > wireless LAN tunneling techniques); > > > > > > > > - IP network level: terminal macro-mobility across the Internet > should > > > be > > > > invisible to higher layers (e.g. by means of Mobile IP v4 or v6 and > the > > > > improvements suggested for delay-sensitive traffic like RTP streams: > > > Mobile > > > > IP HAWAII, or draft-elmalki-mobileip-fast-handoffs-01 to name but a > few; > > > > note that route optimization is also worked on in this area); > > > > > > > > - "terminal real-time signaling" application level: the level where > > > > telephony and MM signaling like H.323 can be placed (restricting GW > and > > > GK > > > > functionality to strictly this level); here Annex-H might define > > > transport > > > > for additional parameters and vertical signaling, useful for serving > the > > > > "user services" application level (below); at this lowest > application > > > level > > > > packet to circuit switched network boundaries may be crossed (cf. > the > > > > evolving traditional telephony networks vs. the Internet); > > > > > > > > - "user services" application level: user and service mobility takes > > > place > > > > here, making use of a network- (and H.323) independent naming system > > > > (directories using e.g. DNS, LDAP schemas, etc.) and e.g. back-end > > > services, > > > > "behind" or "on top of" one or several GKs for realizing UM, user > > > mobility > > > > support for a larger scope than just H.323, smart user assistance, > etc.. > > > > > > > > This approach has not only the general advantage that every layer > can > > > evolve > > > > technically independent of all others, it also has the specific > > > advantage > > > > that it realizes true consolidation of mobility for telephony and > > > > traditional data applications. > > > > > > > > As a last point, it is not clear to me at which of these levels > H.450 > > > would > > > > belong. As it is specified now it is on top of H.323, but suppose > one > > > would > > > > like to adopt a service provision model where a user could subscribe > to > > > a > > > > telephony-related service , wouldn't it be nice then to be able to > offer > > > > this across different telephony technologies (a bit like where IN > aims > > > at)? > > > > A comparison to using a HTTP service control layer (Annex-K) might > be > > > > interesting here. > > > > > > > > I cannot imagine that these fundamental issues where not previously > > > > discussed in ITU-T SG16 or Tiphon WG7, so if anyone can give me some > > > > arguments why an approach as I tried to describe here could not be > > > followed, > > > > I would be glad to know about it. > > > > > > Your comments are very good and your suggestions are very applicable > to > > > what we are working on, but unless a contribution is presented to the > > > proper > > > groups e.g., ITS-sg16 q13/14 they would just fade away. ITU > > > recommendations > > > are contribution driven. > > > > > > Best Reagrds, > > > Ed > > > > > > > > > > > > > > > Regards, > > > > Marc Roelands > > > > Siemens ICN Atea > > > > Atealaan 34 > > > > B-2200 Herentals > > > > Belgium > > > > Tel.: +32 14253965 > > > > Fax: +32 14222994 > > > > E-mail: marc.roelands(a)siemens.atea.be > > > > > > > > -----Original Message----- > > > > From: Roberto Winkler [mailto:wnk@FUB.IT] > > > > Sent: Tuesday, September 14, 1999 10:34 AM > > > > To: TIPHON_WG7(a)LIST.ETSI.FR > > > > Subject: Re: [Fwd: Re: [Fwd: [Fwd: [Fwd: Re: H.323 mobility first > > > > darft]]]] > > > > > > > > Jin, Edgar, > > > > > > > > If I may try to give my 2 cents in this discussion, I think that the > > > > problems/weakness of 3GPP considered systems (which Edgar is > speaking > > > > about) cannot match with the faults identified by Lucent's > contribution, > > > > which is focused on the unique issue of R99 terminal support in the > All > > > IP > > > > R00 network. Considering these 3GPP contributions does not help in > > > > understanding Edgar's point of view. > > > > I have already sent a few e-mails to comment the proposed mobile > H.323 > > > > architecture and would like to summarize here my view, hoping to get > > > > reactions: > > > > - the role and reason for being of WAU is unclear (as TIPHON is > focused > > > on > > > > user and service mobility, why worry about the access medium ?) > > > > - the redefinition of several RAS channel messages is confusing (why > > > does > > > > the RAS channel terminates at WAU ?) > > > > - protocol stacks and interface definitions are missing from the > > > picture. > > > > > > > > best regards > > > > > > -- > > > Edgar Martinez - Principal Staff Engineer > > > Email mailto:martinze@cig.mot.com > > > FAX 1-847-632-3145 - - Voice 1-847-632-5278 > > > 1501 West Shure Drive, Arlington Hgts. IL 60004 > > > Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ > > > Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/ > > -- > Edgar Martinez - Principal Staff Engineer > Email mailto:martinze@cig.mot.com > FAX 1-847-632-3145 - - Voice 1-847-632-5278 > 1501 West Shure Drive, Arlington Hgts. IL 60004 > Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ > Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/

1 0