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

APC-1658 uploaded
by Karl.Klaghofer＠ICN.SIEMENS.DE 12 Oct '99

12 Oct '99

I have uploaded APC-1658 Draft H.450.9 "Call Completion Supplementary Services" to the Incoming directory yesterday. Regards, Karl Klaghofer Siemens AG

1 0

Uploaded APC-1701
by Takashi Suzuki 12 Oct '99

12 Oct '99

Dear Q.12-14 Experts, I have uploaded APC-1701 - Multiplexed stream transmission over H.323 logical channel to the Incoming directory. Best regards, Takashi Suzuki NTT DoCoMo Multimedia Laboratories TEL: +81 468 40 3515 FAX: +81 468 40 3788

1 0

List of contributions for the Red Bank meeting
by Noriko Hosokawa 12 Oct '99

12 Oct '99

Dear Q12-14/16 experts, Please find attached the current list of registered contributions with uploading status as of 15:30 (Tokyo time) Tuesday. All of the uploaded files have been moved to /9910_Red directory. Please advise me if the source, title or status of your contribution is not correctly recorded. 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???.??? * Yet to be uploaded. # Advice of delaying has been received. ------------------------------------------------------------------------ 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 Nokia Functional Requirements for H.323 Annex H (Terminal, User and Service Mobility) * 1660 Mitel Proposed H.323 Annex L (Stimulus Protocol) 1661 VocalTec Communications Ltd. Resolution of H.245 ambiguity when using Fast Connect procedure * 1662 VocalTec Communications Ltd. et. al. Changes to H.323 to support operation behind basic NAT devices - version 2 1663 Editor (I Suconick) H.341 V2 contribution 1664 AT&T H.323 User, Service, and Service Provider Mobility Framework for Multimedia Intelligent Networking 1665 AT&T Viewgraph Presentation of H.323 User, Service, and Service Provider Mobility Framework for Multimedia Intelligent Networking 1666 Nortel and Siemens Megaco/H.248 Generic Packages 1667 Editor (P Jones) H.323v4 draft 1668 AT&T,VocalTec, Alcatel, Motorola, and 3Com Call Flows Supporting H.323 QOS 1669 AT&T,VocalTec, Alcatel, Motorola, and 3Com Extensions of H.225.0 and H.225.0 Annex G Signaling Messages and their ASN.1 Syntax to Support H.323 QOS 1670 AT&T,VocalTec, Alcatel, Motorola, and 3Com Framework for Mapping of H.323 QOS over Packet-based Networks * 1671 Intel The H.323 terminal with secured software based Universa Subscriber Identification Module (USIM) and Inter-working Function with PLMN (public land and mobile networks) * 1672 Intel User Mobility and Service Mobility services for Wireless Subscribers with H.323 terminals accessing Multimedia over IP (MoIP) and PLMN networks * 1673 Hughes Software Systems Redundancy and Fault Tolerance Procedures in H.323 1674 Editor (M Euchner) H.323 Annex J: Security for H.323 Annex F 1675 Editor (M Euchner) H.235 Version 2 1676 Siemens AG ClearToken enhancement in H.235 Version 2 1677 Siemens AG AES support in H.235 Version 2 1678 Siemens AG Elliptic curve support in H.235 Version 2 1679 Siemens AG Security Profile negotiation in H.235 Version 2 * 1680 SG16 management Draft Questions for SG16 WP2 for the new study period 1681 Siemens AG Identification of Gateway Protocol * 1682 InterVoice Media Redirection and Replication 1683 BT ISUP Transport in H.225 using a Generic, Extensible Framework * 1684 Lucent Technologies and VocalTec Multiple UsageIndications in Annex G * 1685 Lucent Technologies Using CPL with H.323 1686 Editor (R Bowen) Draft H.225.0 v4 * 1687 Lucent Technologies H.323 Annex F Hookflash Signaling Enhancements 1688 Editor (G HellstromR H.323 Annex G Text Conversation, draft 1689 Ericsson RTP-Text for H.323 Annex G Text Conversation 1690 Ericsson F.MCVS conversation service description with Total Conversation and Text telephony 1691 Ericsson H.248 packages and additions for text telephony and total conversation. 1692 Motorola Using SCTP as an Alternate H.248 Transport 1693 Editor (P Jones) H.323 Implementers Guide * 1694 BT Object Profile for ISUP Transport in H.225 using Generic Extensible Framework 1695 IETF Megaco Working Group Megaco/H.248 Requirements - Communication from IETF 1696 Editor (E.Skjaeran, Ericsson) H.323 Annex K (HTTP based service control) 1697 Ericsson (E.Skjaeran) Additions of codepoints to H.225.0 for service control channel * 1698 Siemens,Munich University of Technology Progressive AV coding for packet switched lossy networks - a principle approach 1699 Trillium Digital Systems Modifications to the H.225 Annex G protocol 1700 Rapporteur of Q.19/16 Support of proposed modifications on H.245 ASN.1 * 1701 NTT DoCoMo Multiplexed stream transmission over H.323 logical channel 1702 NEC Editorial errors in H.245 version 4, version 5 1703 Nortel Networks Tones and announcement in fast start 1704 Nortel Networks Modification to gateway decomposition architecture * 1705 Nokia On H.323 QoS 1706 Nokia On H.323 Mobility * 1707 Editor (P Jones) Early Termination of Fast Connect Procedure in H.323 1708 Cisco Systems Early Closure of the Call Signaling Channel 1709 Marc Roelands, Siemens ICN On Terminals, Users, Services and Mobility in H.323 1710 Lucent Technologies Changes to H.248 to allow use in non-IP environments 1711 Lucent Technologies, Tech-know-ware ASN.1 syntax definition for H.248 1712 Lucent,Ericsson,Tech-Know-Ware H.248/Megaco Structured Message Encoding using a Text Line Format 1713 LM Ericsson H.248 Line Encoding 1714 LM Ericsson H.248 IANA consideration for Package extension 1715 LM Ericsson H.248 Signal Direction 1716 LM Ericsson Cause Handling in H248 1717 LM Ericsson H.248 Functional Outage 1718 LM Ericsson H.248 ServiceChange 1719 LM Ericsson Monitoring in H248 1720 LM Ericsson H.248 Event Enhancements 1721 LM Ericsson H.248 Multiple Virtual MG Enhancements 1722 ITU-TSB (Frank Cohen) Terminology difference between T.35 and H.225.0 1723 LM Ericsson H.248 Priority calls 1724 LM Ericsson Native Descriptors in H248 1725 LM Ericsson H.248 Signalling Transport Converter for MTP 1726 LM Ericsson H.248 Description of the generic signalling 1727 Editor (Christian Groves) Draft H.246 Annex C 1728 LM Ericsson Negotiation of Protocol Capabilities in H225 RAS 1729 LM Ericsson Sigtran in H225 1730 LM Ericsson Architectural strives for Conversational Multi Media with Multi Access 1731 LM Ericsson Layered Mobility Management architecture in MultiMedia/ MultiAccess 1732 Cisco Systems Proposed FacilityReason Codepoint for New Tokens 1733 Cisco Systems Addition of Billing Information to RAS Messages * 1734 Cisco Systems Support for Multiple Payload Types in Logical Channels #* 1735 Editors (John Segers, Brian Rosen) Draft H.248 1736 FORE Systems H.248 Transport for ATM * 1737 BT Methods of transporting ISUP across H.323: Issues for consideration 1738 Editor (Barry Aronson) H.323 Annex I Terms of Reference, v2 * 1739 Teles et al H.323 robustness mechanisms * 1740 Teles et al Organizing work on H.323 - SIP - Interworking * 1741 RADVision Clarifications for Fast Connect Procedure * 1742 RADVision Clarifications for the use of Call Signaling Address in H.225.0 SETUP Procedure * 1743 Q.14 Rapporteur Resolving References to IETF Documents in H.248 ---------------------------------------------------------------------------- ----

1 0

Text conversation contributions APC-1688 1689 1690 1691 uploaded
by Gunnar Hellstrom 12 Oct '99

12 Oct '99

The following contributions to the Q11-15/16 meeting next week from Ericsson covering Text Conversation and Total Conversation are uploaded and available from standard.pictel.com/avc-site/9910-red apc-1688 H.232 Annex G Text Conversation and Text SET apc-1689 RTP-Text for H.323 Annex G Text Conversation apc-1690 F.MCVS conversation service description with Total Conversation and Text Telephony apc-1691 H.248 packages and additions for text telephony and Total Conversation Regards Gunnar Hellstrom ---------------------------------------------- Gunnar Hellström LM Ericsson Sweden E-mail gunnar.hellstrom(a)omnitor.se Tel +46 8 556 002 03 Mob. +46 708 204 288 Video and V.18 text tel +46 8 556 002 05 Fax +46 8 556 002 06 ------------------------------------------

1 0

Uploaded APC-1695
by Nancy-M Greene 11 Oct '99

11 Oct '99

I have uploaded APC-1695 - Megaco/H.248 Requirements - Communication from the IETF Megaco WG. Nancy -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com

1 0

APC-1702 uploaded
by Hidenobu Harasaki 11 Oct '99

11 Oct '99

Dear Q.12-14 Experts, I have uploaded APC-1702 titled "Editorial Errors in H.245 version 4, 5 and 6" to the Incoming directory. I must apologize for not meeting the upload deadline. Best regards, Hidenobu Harasaki harasaki(a)ccm.CL.nec.co.jp Manager, Research C&C Media Research Labs., NEC Corporation Phone: +81 44 856 8083 Fax: +81 44 856 2232

1 0

Re: H.323v3 Final Text Posted - correction
by Sakae OKUBO 11 Oct '99

11 Oct '99

/// Correction to the file name, thanks to Mr. Jones's advice /// Dear Mr. Michaely, > It is not there now. Has it been moved elsewhere ? It has been moved to the following place: ftp://standard.pictel.com/avc-site/9909_Gen/H323v3_decided_990930.zip or http://standard.pictel.com/ftp/avc-site/9909_Gen/H323v3_decided_990930.zip Please note that /Incoming is a temporary storage place, all the files there are moved to directories according to the meeting date & place. Please also note that there is an index file like 9909_Gen.txt in each directory which assists you to find a file. 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

APC-1699
by Archana Nehru 11 Oct '99

11 Oct '99

Hi all, I have uploaded the APC-1699 into the incoming directory. Please note that the APC-1699_final.doc is the correct version of the document. The APC-1699.doc present in the directory is corrupted and needs to be removed. Thanks Archana ________________________________________________________________________ Archana Nehru : Trillium Digital Systems, Inc E-mail: archie(a)trillium.com : Los Angeles, California Phone: +1 310 442 9222 ________________________________________________________________________

1 0

APC-1699
by Archana Nehru 11 Oct '99

11 Oct '99

Please find enclosed the APC-1699 for submission to the Red bank meeting. Somehow the security server is not allowing me to upload the file in the incoming directory. Thanks Archana ________________________________________________________________________ Archana Nehru : Trillium Digital Systems, Inc E-mail: archie(a)trillium.com : Los Angeles, California Phone: +1 310 442 9222 ________________________________________________________________________

1 0

[Fwd: The IETF's position on technology to support legal intercept]
by Christian Groves 11 Oct '99

11 Oct '99

G'Day all, This may be of some interest. Cheers, Christian -------- Original Message -------- Subject: The IETF's position on technology to support legal intercept Date: Mon, 11 Oct 1999 15:47:10 -0400 From: The IESG <iesg-secretary(a)ietf.org> Reply-To: raven(a)ietf.org To: IETF-Announce: ; CC: raven(a)ietf.org The use of the Internet for services that replace or supplement traditional telephony is, predictably, causing discussions in many countries about the point at which special rules about telephony services begin to apply to Internet service providers. In many countries, these rules could impose new legal obligations on ISPs, particularly requirements to comply with requests from law enforcement agencies or regulators to intercept, or gather and report other information about, communications. For example many traditional telephony devices, especially central-office switches, sold in those countries are required to have built-in wiretapping capabilities to allow telephone carriers to fulfill these obligations. A number of IETF working groups are currently working on protocols to support telephony over IP networks. The wiretap question has come up in one of these working groups, but the IESG has concluded that the general questions should be discussed, and conclusions reached, by the entire IETF, not just one WG. The key questions are: "should the IETF develop new protocols or modify existing protocols to support mechanisms whose primary purpose is to support wiretapping or other law enforcement activities" and "what should the IETF's position be on informational documents that explain how to perform message or data-stream interception without protocol modifications". We would like to encourage discussion of these questions on the new raven(a)ietf.org mailing list. Subscription requests should be mailed to raven-request(a)ietf.org OR subscribe via the web at http://www.ietf.org/mailman/listinfo/raven Time will be allocated at the Plenary session at the November IETF to discuss this orally and try to draw a consensus together. (PLEASE DISCUSS THIS ON THE NEW MAILING LIST AND NOT ON THE GENERAL IETF LIST) In addition to the general questions identified above, we believe it would be helpful for mailing list comments to address the following more specific questions: Adding wiretap capability is by definition adding a security hole. Considering the IETF's commitment to secure protocols, is it a reasonable thing to open such a hole to meet these requirements? Should the IETF as an international standards organization shape its protocols to support country-specific legal requirements? If the companies who employ the IETF participants and deploy the IETF's technology feel that having wiretap capability is a business necessity due to the regulatory requirements in the countries where they want to sell their products, would that make a difference to the IETF position on this subject? What is the appropriateness or feasibility of standardizing mechanisms to conform to requirements that may change several times over the life cycle of equipment built to conform to those standards? When IPv6 was under development, the IETF decided to mandate an encryption capability for all devices that claim to adhere to those standards. This was done in spite of the fact that, at the time the decision was made, devices meeting the IPv6 standard could not then be exported from the U.S. nor could they be used in some countries. Is that a precedent for what to do in this case? Could the IETF just avoid specifying the part of the technology that supports wiretapping, presumably assuming that some industry consortium or other standards organization would do so? Would letting that responsibility fall to others weaken the IETF's control over its own standards and traditional areas? If these functions must be done, is it better for the IETF to do them so that we can ensure they are done in the most secure way and, where permitted by the regulations, to ensure a reliable audit capability? What would the image of the IETF be if we were to refuse to standardize any technology that supported wiretapping? In the Internet community? In the business community? To the national regulatory authorities? The goal of the mailing list and then plenary session is to address the broad policy and direction issue and not specific technical issues such as where exactly in an architecture it would be best to implement wiretapping if one needed to do so. Nor are they to address what specific functions might be needed to implement wiretapping under which countries' laws. The intent is basically to discuss the question of what stance the IETF should take on the general issue.

1 0