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

The current list of registered contributions
by Noriko Hosokawa 22 Jul '99

22 Jul '99

Dear Q.12-14/16 experts, Attached please find the current list of registered contributions. Please note that the original APC-1563 from Ericsson has been cancelled and the number is reused for the draft from Editor (Martin Euchner). If you have requested an APC number for your coontribution but is not yet listed, please advise me. 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 Berlin (2-6 August 1999) ------------------------------------------------------------------------ APC- Source Title ------------------------------------------------------------------------ 1555 ITU-T SG8 Recommendation T.38 Indications in Recommendation H.245 (TD1/WP2 of the SG16 Santiago meeting) 1556 ITU-T SG11 Support of IN services for H.323 and other IP Network based terminals (TD4/WP2 of the SG16 Santiago meeting) 1557 ITU-T SG9 Draft New Rec. J.Web "Distribution of Sound and Television Programmes over the Internet "Webcasting"" (TD22/WP2 of the SG16 Santiago meeting) 1558 ITU-T SG2 Routing of Multimedia Connections When Interworking with PSTN, ATM, and IP Networks (TD24/GEN of the SG16 Santiago meeting) 1559 SG16 WP2 Proposed Organisation going forward to new Study Period 1560 Editor (E Martinez) Annex-H (User and Service Mobility in H.323) Proposed Architecture 1561 Editor (G Hellstrom) H.323 Annex G Text Conversation and Text SET 1562 L M Ericsson H.gcp Modification proposals for Text Conversation 1563 Editor Draft H.323 Annex J: Security for H.323 Annex F 1564 L M Ericsson H.224 Modified for text conversation 1565 DataBeam Corporation Usage of Expanded T.35 Country Codes in Recommendations H.225.0,H.245, and H.283 1566 Editor H.243 Draft revised ITU-T Recommendation H.243 (white doc.) 1567 L M Ericsson Generic Service ControlTransport 1568 Lucent and H.245 Generic Capabilities Definition and AT&T H.225 Packetization Specification for the North American Cellular/PCS TDMA Vocoders (ACELP and US1) 1569 BT and Tech- Editorial Clarifications to H.323 and the Know-Ware Implementer's Guide 1570 BT and Tech- Clarifications on Third-Party Pause Know-Ware 1571 Rapporteur for Q.12/16 (S Okubo) Status of Draft Amendment 7 to H.222.0|ISO/IEC 13818-1 -- Carriage of ISO/IEC 14496 (MPEG-4) content over H.222.0|ISO/IEC 13818-1 (MPEG-2) System streams 1572 Editor (K Sakai) Draft Implementor's Guide for H.321 V2 1573 Editor (S Okubo) Draft Implementor's Guide for H.310 V2 1574 SG16 Correspondence Representative to DAVIC (S Okubo) DAVIC work on TV Anytime and TV Anywhere systems 1575 Rapporteur for Q.19/16 (S Hayashi) H.245 Generic Capability Definition and H.225.0 Packetization Specification for G.729 1576 Japan Guideline for assigning the T.35 terminal provider codes in Japan 1577 Oki et al Proposed modifications to resolve the inconsistent ASN.1 syntaxes between T.38 Annex B and H.245 1578 Oki et al Proposed additional liasion to SG8 on T.38 Appnedix II 1579 Hitachi, Ltd. Prototype system of H.262 layered video transmission 1580 Nortel Networks Media Gateway control protocol architecture and requirements 1581 Lucent Technologies and Nortel Networks H.323 v3 and H.225 v3 Support for Improved Alias Registrations 1582 Lucent Technologies H.323 v3 and H.225 v3 Endpoint Registration Clarifications 1583 Siemens AG Error in Coding Bearer Capabilities 1584 Siemens AG Inter-Zone Addressing 1585 Siemens AG Correction of Alias Conflict in H.225.0v3 1586 Siemens AG Identification of Gateway Protocol 1587 Siemens AG Null AliasAddress 1588 SIEMENS Restricted Numbers/Aliases in Supplementary Service APDUs 1589 SIEMENS Work on Supplementary Service Interworking started 1590 SIEMENS Draft H.450.9 "Call Completion Supplementary Services for H.323 1591 AT&T and VocalTec Functional Requirements and Service Classes to Support QOS in H.323 1592 Lucent Technologies Q.SIG Transport in H.323 Systems 1593 PictureTel and Nortel Networks Backward compatibility and clarification text in H.323 Annex C 1594 PictureTel Problem with XRS (Message Not Understood) RAS message 1595 PictureTel Additional information in ARQ for Gateway calls 1596 PictureTel H.245 support for G.722.1 1597 Siemens Feature key management extensions for H.323 SET terminals 1598 VocalTec Adopting a Pragmatic Approach to IPT-IN InterWorking 1599 VocalTec Clarifications to the fast connect procedure 1600 VocalTec Comments on Transporting DTMF in H.323 1601 VocalTec Changes to H.323 to support operation via basic NAT devices 1602 VocalTec et al IN-IPT interworking - feecback from the SG11 Rapporteur meeting 1603 VocalTec Scope definition of Annex D to H.246 1604 VocalTec as Source Changes to H.248 to assure H.323 GW interoperability 1605 Intel Corporation Proposed Terms of Reference for H.323 Mobility 1606 Cisco Systems Proposal for Transporting User Input via RTP 1607 Cisco Systems Proposal for Enforcing Symmetric Codec Operation with Fast Connect 1608 Tech-Know-Ware and Lucent H.GCP/Megaco Structured Message Encoding Using an ASCII Line Format 1609 Lucent Technologies Support for Q.931 TNS and NSF IEs in H.225.0 1610 Q.14 Rapporteur Changes to H.248 Proposed by IETF Megaco ------------------------------------------------------------------------

1 0

None
by Yap Kai Yeow 21 Jul '99

21 Jul '99

subscribe

1 0

Article on H.323 Supplementary Services
by Kaynam Hedayat 21 Jul '99

21 Jul '99

Hello everyone, I would like to bring your attention to a very good article by Vineet Kumar and Markku Korpi on H.323 Supplementary Services. The article appears in the July issue of the IEEE Communications Magazine with the title "Supplementary Services in the H.323 IP Telephony Network". Regards, Kaynam Hedayat

1 0

Re: FW: Internet Telephony
by Pete Cordell 21 Jul '99

21 Jul '99

FYI The May/June issue of IEEE Network was also a special issue on Internet Telephony. Prof Schulzrinne was guest editor which I found quite interesting! Pete ============================================= Pete Cordell pete(a)tech-know-ware.com ============================================= -----Original Message----- From: Callaghan, Robert <Robert.Callaghan(a)ICN.SIEMENS.COM> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> Date: 21 July 1999 18:58 Subject: FW: Internet Telephony >This was posted on the IPTel mailing list. (I wonder why SG16 was >overlooked?) > >Bob > >------------------------------------------------------------------ >Robert Callaghan >Siemens Business Communication Systems >Tel: +1.561.997.3756 Fax: +1.561.997.3403 >Email: Robert.Callaghan(a)ICN.Siemens.com >------------------------------------------------------------------ > > >-----Original Message----- >From: Mohammed Atiquzzaman [mailto:atiq@engr.udayton.edu] >Sent: Wednesday, July 21, 1999 11:20 AM >To: iptel(a)lists.research.bell-labs.com >Subject: CFP: Internet Telephony > > > Call for Papers > Special Issue of IEEE COMMUNICATION MAGAZINE on > > Internet Telephony > >Due to the potential economic advantages, the integration of several media >is desirable and very attractive. Today, however, voice over IP remains >somewhat of a technical novelty, hindred by a number of existing problems >to provide an assured voice quality. The likely prognosis is that over the >next year or two, the advent of Resource Reservation Protocol (RSVP) and >increased enterprise network bandwidth (achieved with ATM WAN services) >could give a boost to voice over IP. This special issue is to bring >experts in the field to share with IEEE COMMUNICATION MAGAZINE readers the >current problems, components, and experiments in "Internet Telephony". >Desirable features of a voice-over-IP system include: > >* Optimal use of bandwidth. >* Capacity management. >* Support of speech quality. >* Flexible integration into voice environment (e.g., PBX). >* Enterprise network ready (support LAN/WAN/Internet protocols for direct > attachment). >* System-level scalability: must be easy to add PBX-side interfaces to > support growth in requirements and appropriate links. >* Network-level scalability: must be able to support mapping of a sufficient > number of extensions (perhaps several thousands) to the respective IP > addresses of the destination gateway. A master database with distributed > upgrade may be desirable. > >IEEE COMMUNICATION MAGAZINE announces a forthcoming issue on "Internet >Telephony". >Prospective authors should follow IEEE COMMUNICATION MAGAZINE guidelines and >submit an electronic (PDF file or a PostScript file viewable by Ghostview) >copy of the manuscript to one of the Guest Editors listed below. Articles >addressing both traditional and innovative products will be given >preference. >Topics include, but are not limited to: > >* Voice over IP/ATM >* IP over ATM/FR for Multimedia >* Traffic Control for Multimedia/Internet Telephony >* QoS Control of Voice over IP >* Evolution of the VPN and PBX environment >* Traffic Capacity Management and Routing Algorithms for Multimedia. > >Full manuscript submission deadline July 31, 1999 >Notification of acceptance October 30, 1999 >Publication Schedule April 2000 > >Mohsen Guizani Ammar Rayes Mohammed >Atiquzzaman >Elec. & Comp. Engr. Director, Solution Arch. Elec. & Comp. >Engr. >Univ. of Missouri-Columbia Traffic Capacity Manag. 300 College Park >5605 Troost Avenue & Planning University of >Dayton >Kansas City, Bellcore, 444 Hoes Lane Dayton, >MO 64110-2823, USA. Piscataway, NJ 08854, USA. Ohio 45469-0226, >USA. >Tel: (816) 235-1550 Tel: (732) 699-3669 Tel. (937) 229 >3183 >Fax: (816) 235-1260 arayes(a)notes.cc.bellcore.com Fax. (937) >229-4529 >guizanim(a)umkc.edu >atiq(a)engr.udayton.edu > > > >--------- >This message came from the IETF IPTEL Working Group Mailing List. >

1 0

MEGACO Multi-Byte numeric quantity encoding
by Lehecka, Gary R (SAIC) 21 Jul '99

21 Jul '99

Hi, Many protocols use some form of "terse mnemonic" text encoding. "Printable" symbols or tokens are chosen for their mnemonic value. Depending on one's point of view, These protocols can be viewed as binary encoded or text encoded. Hopefully, a compromise can be arrived at. Binary and Text encoding camps are arguing for their personal choice of tools. A tie breaker may be how we propose to encode multi-byte numeric quantities. Big Endian, Little Endian, etc. I would imagine that those proposing text encoding might be quicker to reach an agreement, than those proposing binary encoding. Unless those proposing binary encoding are all willing to agree upon something like External Data Representation (XDR) RFC's 1014, 1790, and 1832 by Sun Microsystems. Danny Cohen, "On Holy Wars and a Plea for Peace", IEEE Computer, October 1981. I have not read this, but it sounded appropriate! Thanks, Gary Lehecka LeheckGR(a)BP.Com BP 250 - 3671 US ( 216 ) 586 - 3671

1 0

FW: Internet Telephony
by Callaghan, Robert 21 Jul '99

21 Jul '99

This was posted on the IPTel mailing list. (I wonder why SG16 was overlooked?) Bob ------------------------------------------------------------------ Robert Callaghan Siemens Business Communication Systems Tel: +1.561.997.3756 Fax: +1.561.997.3403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Mohammed Atiquzzaman [mailto:atiq@engr.udayton.edu] Sent: Wednesday, July 21, 1999 11:20 AM To: iptel(a)lists.research.bell-labs.com Subject: CFP: Internet Telephony Call for Papers Special Issue of IEEE COMMUNICATION MAGAZINE on Internet Telephony Due to the potential economic advantages, the integration of several media is desirable and very attractive. Today, however, voice over IP remains somewhat of a technical novelty, hindred by a number of existing problems to provide an assured voice quality. The likely prognosis is that over the next year or two, the advent of Resource Reservation Protocol (RSVP) and increased enterprise network bandwidth (achieved with ATM WAN services) could give a boost to voice over IP. This special issue is to bring experts in the field to share with IEEE COMMUNICATION MAGAZINE readers the current problems, components, and experiments in "Internet Telephony". Desirable features of a voice-over-IP system include: * Optimal use of bandwidth. * Capacity management. * Support of speech quality. * Flexible integration into voice environment (e.g., PBX). * Enterprise network ready (support LAN/WAN/Internet protocols for direct attachment). * System-level scalability: must be easy to add PBX-side interfaces to support growth in requirements and appropriate links. * Network-level scalability: must be able to support mapping of a sufficient number of extensions (perhaps several thousands) to the respective IP addresses of the destination gateway. A master database with distributed upgrade may be desirable. IEEE COMMUNICATION MAGAZINE announces a forthcoming issue on "Internet Telephony". Prospective authors should follow IEEE COMMUNICATION MAGAZINE guidelines and submit an electronic (PDF file or a PostScript file viewable by Ghostview) copy of the manuscript to one of the Guest Editors listed below. Articles addressing both traditional and innovative products will be given preference. Topics include, but are not limited to: * Voice over IP/ATM * IP over ATM/FR for Multimedia * Traffic Control for Multimedia/Internet Telephony * QoS Control of Voice over IP * Evolution of the VPN and PBX environment * Traffic Capacity Management and Routing Algorithms for Multimedia. Full manuscript submission deadline July 31, 1999 Notification of acceptance October 30, 1999 Publication Schedule April 2000 Mohsen Guizani Ammar Rayes Mohammed Atiquzzaman Elec. & Comp. Engr. Director, Solution Arch. Elec. & Comp. Engr. Univ. of Missouri-Columbia Traffic Capacity Manag. 300 College Park 5605 Troost Avenue & Planning University of Dayton Kansas City, Bellcore, 444 Hoes Lane Dayton, MO 64110-2823, USA. Piscataway, NJ 08854, USA. Ohio 45469-0226, USA. Tel: (816) 235-1550 Tel: (732) 699-3669 Tel. (937) 229 3183 Fax: (816) 235-1260 arayes(a)notes.cc.bellcore.com Fax. (937) 229-4529 guizanim(a)umkc.edu atiq(a)engr.udayton.edu --------- This message came from the IETF IPTEL Working Group Mailing List.

1 0

Re: Summary of Megaco Meeting Results
by Derks, Frank 21 Jul '99

21 Jul '99

Tom, in your report on the MEGACO meeting, I saw that the issue of text versus binary still hasn't been resolved in a way that both parties ("IETF" and "ITU") are satisfied. I.e. I do not assume that everybody agreed on a result determined by flipping a coin. I am not sure whether you (or the group) are (is) aware of what's going on in "encoding" land, so I would like to draw the attention to the XER initiative (Xml Encoding Rules). Maybe this will provide a (partial) way out of the impasse. Please have a look at: http://asf.gils.net/xer/standard.html. Regards, Frank ----------------------------------------------------- Frank Derks |Tel +31 35 6893238 | Advanced Development |Fax +31 35 6891030 | Philip Business Communications |P.O. Box 32 | |1200 JD Hilversum | |The Netherlands | ----------------------------------------------------| E-mail: mailto:f.derks@pbc.be.philips.com | WWW: http://www.business-comms.be.philips.com | ----------------------------------------------------- -----Original Message----- From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] Sent: 15 July 1999 22:34 To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Summary of Megaco Meeting Results This is a report on what has happened here in Oslo from the syntax design team meeting Tuesday morning through the full working group meeting this morning. The activities of later Tuesday and Wednesday were controversial, so I am documenting them fairly extensively. Syntax Design Team Meeting The Tuesday morning syntax design team meeting had a number of proposals to consider. We achieved two quick conclusions: not to consider ODL as our syntax specification language, and to split the Audit command into two separate commands, one to discover capabilities, the other to determine existing status. With regard to the ODL contribution, I would like to take note of the hard work which M. Anquetil and his colleagues put into devising complete Megaco syntax specifications not only in ODL but also in ASN.1. >From this beginning we went on to consider a key issue: capability specification syntax, with the Ott and Huitema drafts as our prime source material. We found that the proposal by Ott et al provided one advance on SDP: the ability to include quantitative constraints. Matt Holdrege also pointed out that Tag-Length-Value syntax in the Ott proposal as taken up in the syntax draft by Rosen et al offered the advantage that it would be simple for service providers to modify values in the MG's capability database, the way they modify values for RADIUS. Christian Huitema and Joerg Ott more or less agreed that their respective approaches were equivalent with respect to the expression of mutually exclusive alternatives. At the point where we began to be very interested in the proposal by Ott et al, we realized that, given that it was meant to be a substitute for SDP, our development of it would be an infringement on the mandate of MMUSIC. We ended up concluding that the constraints of the situation required us instead to specify that the MGC MUST in the short term support two different systems for media description and media capabilities: one based on SDP and one to be specified by SG 16 and presumably kinder to H.245. The choice of which system to use would be up to the MG and could be audited as an MG capability. We would reserve room for evolution to a new capability description protocol if one should be produced by MMUSIC. As part of this discussion, we considered the general question of Megaco syntax and whether it should be the Tag-Length-Value system proposed by Rosen et al (which, it was noted, is actually X.409 encoding reinvented). We were unable to come to a consensus on this topic. The meeting ended, as you might expect, with a cry of despair from Brian Rosen. Follow-Up Meeting Another meeting was hastily organized, to take place Tuesday night. It was organized after the first meeting had broken up and was announced by a note on the bulletin board, which meant that word did not reach all members of the design team in time for them to change their plans for the evening. Most but not all of the twenty-odd people in the morning meeting also attended the one in the evening. The evening meeting spent most of its time on the text vs. binary encoding issue in all its variants. The clear consensus of those present was that there were two irreconciliable camps: the IETF consensus would be in favour of text, the SG 16 consensus in favour of binary, regardless of benchmark results. This meant that we had an impasse. The suggestion was made that we toss a coin. This seemed to be the only credible way out of the impasse, so I did so. The "text encoding" side came up. The meeting broke up immediately following this result. Derivation Of EBNF On Wednesday Brian Rosen and Glen Freundlich, acting in place of Bryan Hill, started the work of implementing EBNF syntax descriptions in line with the conclusions of the previous day. They had help from a number of individuals along the way, but this was in effect an editorial exercise starting from the EBNF in draft-ietf-megaco-protocol-01.txt and the parameters shown in the H.GCP draft rather than any sort of design team meeting. The results as presented in this morning's working group meeting were fairly complete. Working Group Meeting As per the previously published agenda, slightly rearranged, the meeting covered three topics: syntax, transport, and packages. Discussion of work plan fell off the end. The syntax discussion began with my presentation of the design team results. Here is my summary as presented to the working group meeting: * Agreed: split Audit into two commands * status discovery * capability discovery * Stymied: new media description and media capability syntax may infringe on MMUSIC (and maybe CONNEG) charters. Hence to be equally fair to SIP and H.323: * MGC must support both SDP and SG 16-determined encoding of H.245 * MG may support either * reserve possibility of migration to new syntax. * Political impasse on encoding. Decided for text by flipping a coin. Issue is relative value of development speed vs. performance. The final point on encoding is problematic, in that the conclusion was reached by a group that was convened without, some will maintain, adequate notice. I hope that I did not improperly influence the working group by presenting this point with the same authority as the earlier points. In any event, the working group appeared to be pleased with the outcome. This ends the controversial part of this summary of results. The rest will be presented more briefly, pending Matt Holdrege's drafting of the minutes. Syntax: discussed use of the application-level Authentication Header and concluded that it would remain an option for use when IPSEC is unavailable. The use of SDP and of other protocols for media description and media capability description will be documented in separate RFCs, one per protocol. Transport: determined a consensus in favour of mandatory support of both TCP and application layer framing in the MGC, with the choice being determined by the MG when it initiates an association. Packages: an editorial team (Mike Kallas and Christian Huitema) was appointed to draft IANA considerations for adding new packages. Package descriptions include termination properties as well as events and signals. One RFC, normatively referenced from the base protocol document, will document the basic Megaco starter set of packages; others can be added through IANA according to the documented procedures. Study Group 16 can also generate package descriptions, probably by adding them as annexes to H.248 (AKA H.GCP). I spoke in the meeting of going to working group and possibly IETF last call in September, before the ITU commits H.248 to ballot. Less optimistic individuals have suggested a joint Megaco/Q.14/16 meeting on the east coast of North America, the week of Sept. 13. Discussions on this point are welcome. Tom Taylor Advisor -- IPConnect Standards E-mail: taylor(a)nortelnetworks.com (internally, Tom-PT Taylor) Phone and FAX: +1 613 736 0961

1 0

Re: Encoding agreement & Interim meeting
by Tom-PT Taylor 21 Jul '99

21 Jul '99

May I point out that the encoding of a substantial portion of each message is in the hands of SG 16? I am talking about the media descriptor portion of the Add, Subtract, Move and Modify commands and the response to the AuditState command, and the media capability descriptor portion of the AuditCapability command. I haven't seen any contributions yet suggesting how to do it -- perhaps I should submit one. Aside from that, I still argue that the coin flip was the only fair way out of a clear impasse. Of course, you're free to argue that the internet and telephony worlds will always be separate and should each go their own way, but this has not been the premise of our work so far. The key point is that a lot of people in Megaco see time to market as a very important issue and were very happy with the way the coin came down. > -----Original Message----- > From: Christian Groves [SMTP:Christian.Groves@ERICSSON.COM] > Sent: Wednesday, July 21, 1999 12:50 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Encoding agreement & Interim meeting > > I would agree with Bob below in that the vast majority of > telecommunications > networks binary is used as an encoding method, its efficient, its > tested, debugged and interoperates but as mentioned elsewhere they're > old arguments but VERY valid. > [[TomT]] ...

1 0

The current list of registered contributions
by Noriko Hosokawa 21 Jul '99

21 Jul '99

Dear Q.12-14/16 experts, Attached please find the current list of registered contributions. Please note that the original APC-1563 from Ericsson has been cancelled and the number is reused for the draft from Editor (Martin Euchner). If you have requested an APC number for your coontribution but is not yet listed, please advise me. 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 Berlin (2-6 August 1999) ------------------------------------------------------------------------ APC- Source Title ------------------------------------------------------------------------ 1555 ITU-T SG8 Recommendation T.38 Indications in Recommendation H.245 (TD1/WP2 of the SG16 Santiago meeting) 1556 ITU-T SG11 Support of IN services for H.323 and other IP Network based terminals (TD4/WP2 of the SG16 Santiago meeting) 1557 ITU-T SG9 Draft New Rec. J.Web "Distribution of Sound and Television Programmes over the Internet "Webcasting"" (TD22/WP2 of the SG16 Santiago meeting) 1558 ITU-T SG2 Routing of Multimedia Connections When Interworking with PSTN, ATM, and IP Networks (TD24/GEN of the SG16 Santiago meeting) 1559 SG16 WP2 Proposed Organisation going forward to new Study Period 1560 Editor (E Martinez) Annex-H (User and Service Mobility in H.323) Proposed Architecture 1561 Editor (G Hellstrom) H.323 Annex G Text Conversation and Text SET 1562 L M Ericsson H.gcp Modification proposals for Text Conversation 1563 Editor Draft H.323 Annex J: Security for H.323 Annex F 1564 L M Ericsson H.224 Modified for text conversation 1565 (P Jones) T.35 (1999) country codes 1566 Editor H.243 Draft revised ITU-T Recommendation H.243 (white doc.) 1567 L M Ericsson Generic Service ControlTransport 1568 Lucent and H.245 Generic Capabilities Definition and AT&T H.225 Packetization Specification for the North American Cellular/PCS TDMA Vocoders (ACELP and US1) 1569 BT and Tech- Editorial Clarifications to H.323 and the Know-Ware Implementer's Guide 1570 BT and Tech- Clarifications on Third-Party Pause Know-Ware 1571 Rapporteur for Q.12/16 (S Okubo) Status of Draft Amendment 7 to H.222.0|ISO/IEC 13818-1 -- Carriage of ISO/IEC 14496 (MPEG-4) content over H.222.0|ISO/IEC 13818-1 (MPEG-2) System streams 1572 Editor (K Sakai) Draft Implementor's Guide for H.321 V2 1573 Editor (S Okubo) Draft Implementor's Guide for H.310 V2 1574 SG16 Correspondence Representative to DAVIC (S Okubo) DAVIC work on TV Anytime and TV Anywhere systems 1575 Rapporteur for Q.19/16 (S Hayashi) H.245 Generic Capability Definition and H.225.0 Packetization Specification for G.729 1576 Japan Guideline for assigning the T.35 terminal provider codes in Japan 1577 Oki et al Proposed modifications to resolve the inconsistent ASN.1 syntaxes between T.38 Annex B and H.245 1578 Oki et al Proposed additional liasion to SG8 on T.38 Appnedix II 1579 Hitachi, Ltd. Prototype system of H.262 layered video transmission 1580 Nortel Networks Media Gateway control protocol architecture and requirements 1581 Lucent Technologies and Nortel Networks H.323 v3 and H.225 v3 Support for Improved Alias Registrations 1582 Lucent Technologies H.323 v3 and H.225 v3 Endpoint Registration Clarifications 1583 Siemens AG Error in Coding Bearer Capabilities 1584 Siemens AG Inter-Zone Addressing 1585 Siemens AG Correction of Alias Conflict in H.225.0v3 1586 Siemens AG Identification of Gateway Protocol 1587 Siemens AG Null AliasAddress 1588 SIEMENS Restricted Numbers/Aliases in Supplementary Service APDUs 1589 SIEMENS Work on Supplementary Service Interworking started 1590 SIEMENS Draft H.450.9 "Call Completion Supplementary Services for H.323 1591 AT&T and VocalTec Functional Requirements and Service Classes to Support QOS in H.323 1592 Lucent Technologies Q.SIG Transport in H.323 Systems 1593 PictureTel and Nortel Networks Backward compatibility and clarification text in H.323 Annex C 1594 PictureTel Problem with XRS (Message Not Understood) RAS message 1595 PictureTel Additional information in ARQ for Gateway calls 1596 PictureTel H.245 support for G.722.1 ------------------------------------------------------------------------

1 0

Re: Encoding agreement & Interim meeting
by Christian Groves 21 Jul '99

21 Jul '99

I would agree with Bob below in that the vast majority of telecommunications networks binary is used as an encoding method, its efficient, its tested, debugged and interoperates but as mentioned elsewhere they're old arguments but VERY valid. I think we need to understand the scope of the H.GGP/248 protocol. Its not just H.323 or SIP networks. The media controller and media gateway architecture and the 'vertical protocol' which it infers has now been adopted by many groups/forums. These include: o MSF who have previously put in requirements on this group o SG16 H.323 o ITU SG11 are working on Bearer independant call control BICC which will need a vertical protocol in the near future o ANSI T1S1 BICC o ETSI SPS1 BICC o Will be used in 3rd Generation Mobile networks These groups have successully worked with binary protocols. o IETF MMUSIC SIP Work with text. o Cable labs <- already chosen MGCP??? o Switch Switch <- already chosen MGCP I think that we should be looking at the medium to long term future of this protocol. If it is to be WIDELY adopted by all groups above then we should be looking at the efficiency and interwork reasons primarily NOT that it only takes 2 weeks, 10 pizzas and a 6 pack to implement and its easy to debug at 3 in the morning. I also think that it is unwise to let a 'toss of a coin' decide the direction that was taken with regards to encoding on H.HCP/248 in this light. Regards, Christian Bob Bell wrote: > > Brian - > > Comments below. > > At 04:06 PM 7/19/99 , Brian Rosen wrote: > >Sorry, you just indeed walked into the sticky part. > > > >There are claims that in fact, the text encoding is SMALLER than > binary > >encoding for > >the kinds of messages we will encounter. This is based on > observation of > >similar > >protocols. > > There may in fact be such claims but in the various communications > protocols I have personally dealt with, it has not been the case. > If someone could point me to some observational data, I would be most > grateful. However, I it still my considered opinion, at this time, > that there is a bias in size toward the text based messaging having > more octets of information. > > > > >Our current consensus opinion is that the difference is almost > certainly in > >the +/- 20% range. That would make encryption arguments pretty > moot. > > A 10% bias, that being the median of your count, means that you can > support 10% less control streams or that your cost is increased 10% > per control stream. That seems to be a significant number to me. > Particularly in the realm of high density environments. > > > > >I assume you did not mean to suggest that text was any more or less > secure; > >just that > >if the messages were bigger, the encryption load would be bigger. > > I agree that there is no diference in the "security" aspect of text vs > binary. > > > > >I will point out that encryption is done over a fixed size datum, > typically > >8 bytes. > >Thus the increment of encryption work is not simply linear. If you > have 9 > >bytes, it > >takes as long to encrypt 10, 11, 12, ... or even 16 bytes (assuming > DES). > >Small > >variations thus have even less effect on encryption speed. > > Assuming that you are correct that the message length is 10% longer > for one form of message. If a typical message is on the order of 100 > octets in length (in view of the Megaco packaging into transactions > and contexts, this is not an unreasonable number), and assuming that > you are using a DES style encryption which uses a block size of 64 > bits or 8 octets, a 100 octet message must be padded to be 104 octets > in length. This requires 13 complete encryption blocks. Adding an > additional 10 octets increases the number of blocks to 14. That is a > 7.7% increase in encryption blocks. While this is no the 10% discussed > above, it is still non-trivial in a large volume project where the > cost is a high consideration. > > > > >Brian > > > > > >-----Original Message----- > >From: Bob Bell [mailto:rtbell@cisco.com] > >Sent: Monday, July 19, 1999 5:43 PM > >To: MEGACO(a)standards.nortelnetworks.com > >Subject: Re: Encoding agreement & Interim meeting > > > > > >It is not my intent to step into an obviously religious war relative > to text > >vs. binary encoding. I would just like to remind the readers on this > list > >that for the purposes of privacy and security on the control > channels, text > >messages typically contain more octets of "plaintext" which must be > >encrypted and decrypted than do binary messages containing the same > level of > >control information. While for workstations and similar devices, this > load > >may be perceived as being a trivial addition, if you are making an > MGC and > >are planning to have hundreds or perhaps thousands of simultaneous > control > >streams active, the additional processing requirements may not be as > easily > >ignored. Perhaps this is a reason to consider the binary encoding > scheme in > >a somewhat more favorable light. > > > >At 02:44 PM 7/19/99 , you wrote: > >>Matt, first off, I suspect you are still talking about the media > descriptor > >>and media capability descriptor components of the protocol. We have > agreed > >>that for these components, each group will use its own encoding, > implying > >>that the MGC must support both. As for the encoding beyond these > two > >items, > >>the conclusion we came to in the "ad hoc" meeting was that Megaco > and SG 16 > >>would always disagree on this issue. There doesn't seem to be any > way to > >>create a higher synthesis, as we could with the context connection > model. > >>As a result, the only way we could meet each other half way was to > have an > >>equal probability that one solution or the other would be chosen. I > would > >>have preferred that the coin flip be done in a combined SG 16/Megaco > >>meeting, but we had the next best thing: both Glen Freundlich (the > SG 16 > >>rapporteur responsible for H.248) and I were there. > >> > >>> -----Original Message----- > >>> From: Michael Thomas [SMTP:mat@CISCO.COM] > >>> Sent: Monday, July 19, 1999 3:18 PM > >>> To: megaco(a)standards.nortelnetworks.com > >>> Subject: Re: Encoding agreement & Interim meeting > >>> > >>> Matt Holdrege writes: > >>> > I guess too much is happening in the design team meetings then. > Well > >>> it's > >>> > out in the open on the list now. I'll put forward that the TLV > >>> structure > >>> > (which allows everything that each side needs) is the best way > to > >>> achieve > >>> > consensus between the IETF and ITU. If we drive too far in > either > >>> > direction, we are not following our directive. > >>> > > >>> > Since as you and others say that there is no major difference > between > >>> text > >>> > or binary, why not choose binary since it is the format that > the ITU > >>> really > >>> > wants and is quite used to. > >>> > >>> Well, text encodings is what IETF "wants and is > >>> quite used to." There are good reasons to use text > >>> such as ease of implementation, debugging, and > >>> interoperability. Thus far nobody's put out any > >>> compelling advantage of a binary encoding over a > >>> text encoding. > >>> > >>> > The result is that we will have a single interoperable standard > and no > >>> one > >>> > can say that it presents any engineering problems. Right? > >>> > > >>> > Since you've chosen text in this ad-hoc meeting, you are almost > >>> > guaranteeing lack of a single standard. > >>> > >>> Let me understand this: are you saying that if > >>> text encoding of the MEGACO *protocol* is choosen > >>> (as it was), that SG16 will pick up its toys and > >>> go home? > >>> > >>> Mike > > > >Bob Bell > >Distinguished Member of the Technical Staff > >Cisco Systems Inc. > >801-294-3034(v) > >801-294-3023(f) > Bob Bell > Distinguished Member of the Technical Staff > Cisco Systems Inc. > 801-294-3034(v) > 801-294-3023(f)

1 0