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

Message Structure in H.225.0 Annex G
by Lior Moscovici 07 Oct '99

07 Oct '99

It was brought to my attention, that one of the last revisions to Annex G before decision was omitted in the decided version due to my fault as an editor. This is the syntax of the Annex G message: Message ::= SEQUENCE { body AnnexGMessageBody, common AnnexGCommonInfo, ... } Since the "common" part includes the Sequence Number and other information needed for lower level treatment of the message, this part should be decoded first, and the natural order should have been reversed. This is important since the size of the "body" is not fixed, and for cases in which there is an error in the encoding of the body. Message ::= SEQUENCE { common AnnexGCommonInfo, body AnnexGMessageBody, ... } This was proposed in the SG16 meeting in Santiago, but during the editing session, it was omitted. Since this is already decided, and the change breaks possible existing implementations, changing it now is next to impossible. I would like to explore how "impossible" it is: I have a reason to believe that there are no officially released products that implement Annex G, so if absolute consensus is reached, we may have a chance to change it in the Red Bank meeting. I know this brings painful memories with the H.235 ClearToken, and I really don't want this to cause frustration and pain. Therefore I ask everyone whom it might concern, to say if he has any objection in making the change. If there is even only one objection, I will drop everything, but if there is none, I will submit this to the Red Bank meeting. Even then, the acceptance is not guaranteed. Lior Lior Moscovici Program Manager, Servers Group R&D VocalTec Communications Ltd. Voice: +972 9 9707767 E-mail: liorm(a)vocaltec.com Fax: +972 9 9561867

1 0

List of contributions for the Red Bank meeting
by Sakae OKUBO 07 Oct '99

07 Oct '99

Dear Q12-14/16 experts, Please find attached the current list of registered documents. Please advise me if your contributions is missing. 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 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 et al Call Flows Supporting H.323 QOS 1669 AT&T et al 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 et al Framework for Mapping of H.323 QOS over Packet-based Networks 1671 Intel The H.323 terminal with secured software based Universal 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 1701 1702 1703 1704 1705 1706 1708 1709 1710 ---------------------------------------------------------------------------- ----

1 0

Re: APC Number
by Sakae OKUBO 06 Oct '99

06 Oct '99

Dear Archana Nehru, In response to your request, APC-1699 has been allocated to your contribution. Source: Trillium Digital Systems Title: Modifications to the H.225 Annex G protocol 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

Re: Document Submission
by Sakae OKUBO 06 Oct '99

06 Oct '99

Dear Mr. Burkert, In response to your request, APC-1698 has been allocated to your contributions. > Document Title: Progressive AV coding for packet switched lossy > networks - a principle approach > > Source: Frank Burkert, Siemens AG > J $B]S (Bgen Pandel, Siemens AG > Thomas Stockhammer, Munich University of Technology > > Scope: Contribution to H.323 Annex I, Packet Switched Visual > Telephone Systems Over Error Prone Channels 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

Re: Request for APC number
by Sakae OKUBO 06 Oct '99

06 Oct '99

Dear Mr. Skjaeran, In response to your request, the following APC numbers have been allocated to your contributions: APC-1696 > Title: Draft H.323 Annex K (HTTP based service control) > Source: Editor (E.Skjaeran, Ericsson) APC-1697 > Title: Additions of codepoints to H.225.0 for service control channel > Source: Ericsson (E.Skjaeran) 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

Capability Exchange procedures
by Derks, Frank 06 Oct '99

06 Oct '99

Dear All, I just went through the descriptions of the Capability Exchange in both the H.323 and the H.245 documents and it would seem that they are not quite clear. The first two sentences in the first paragraph in H.245, "5.2 Capability Exchange", seem to mean that a terminal should not send any media that "can not be received" by the receive terminal. The only way to achieve this is that the receive terminal send a TCS Reject for all those media types that it can not receive. However, the third sentence contradicts this by stating that those capabilities that are not understood (or can be used) should be ignored. Furthermore, the fourth sentence states that not understood extensions to a capability that is understood (and can be used) should be ignored, which could result in unsuccessful communication. So how should this paragraph be read. The second paragraph in H.245, "5.2 Capability Exchange", states: "The total capability of a terminal to receive and decode various signals is made known to the other terminal by transmission of its capability set." I would say that the "total capability" includes both the receive and the transmit capabilities and not just its "receive (and decode)" capabilities. Furthermore, most of section 5.2 talks about capabilities and not about their exchange. The fourth paragraph in H.245, "5.2 Capability Exchange", states: "The absence of _a_ transmit capability indicates that ....". This phrasing (the "a") suggests that the absence of just one of the capabilities indicates that no choices are offered. Section 7.2.3 "Terminal Capability Set Acknowledge", states: "This is used to confirm receipt of a TerminalCapabilitySet from the peer CESE". In other words upon reception of a TCS, the Acknowledge should always be sent. So when should a Reject be sent? The logical succession of TCS messages between two CESEs is not well documented and clarifying text is required to make this clear. 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 | -----------------------------------------------------

2 1

Re: request for APC number
by Sakae OKUBO 06 Oct '99

06 Oct '99

Dera Ms. Greene, > Title: Megaco/H.248 Requirements - Liaison reply from IETF Megaco WG > Source: IETF Megaco Working Group > Contact: Nancy Greene (ngreene(a)nortelnetworks.com) APC-1695 has been allocated. 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

G.723.1 vs. G.723
by Paul Long 06 Oct '99

06 Oct '99

What is the difference between G.723.1 and G.723? And I don't mean the numerical difference, as in 0.1 :-) Are they the same thing, and people are just being imprecise when they refer to G.723.1 as "G.723?" For SuperOp! scheduling, they were both listed as two of the possible audio codecs, as if they were different. Does anyone truly support G.723 but not G.723.1? If so, I've never come across such an implementation. Also, what is the history of G.723.1? I believe the current version is something called 5.1. Is this correct? Were there some intermediate versions? Paul Long Smith Micro Software, Inc.

2 1

Re: G.723.1 vs. G.723
by Sebestyen Istvan ICN WN ES SP 4 06 Oct '99

06 Oct '99

Paul, G.723 was an old ITU-T Recommendation that has been withdrawn and has nothing to do with G.723.1. So, when people today use G.723 they usually mean G.723.1. For the software version this is a bit confusing: For the most current version it is best to look up the ITU-T Database: http//www.itu.int. Unfortunately, in the text of the Recommendation no reference is made to the actual C-Code version (we have requested to have a better version control for the future Recommendations). On the top of it since C-Code is also a program (contains as many bugs as any other program...:-( ), in some of the past SG meeting bugs were corrected (so you have to go through the SG16 reports). I am not sure whether eventually the bug corrections have been also incorported into the C-Code that the ITU is currently selling as the latest version. So, my message is that extrem care is needed not to miss something. Regards, Istvan -------------------------------------------------------------------------- Dr. Istvan Sebestyen Siemens AG, ICN WN ES SP 4, Hofmannstr. 51 D-81359 Munich Tel:+49-89-722-47230 Fax:+49-89-722-47713 E-Mail: istvan.sebestyen(a)icn.siemens.de Intranet:http://netinfo.icn.siemens.de/es/team/essp/team/essp4 ---------------------------------------------------------------------------- ---------------- > ---------- > From: Paul Long[SMTP:plong@SMITHMICRO.COM] > Reply To: Mailing list for parties associated with ITU-T Study Group > 16 > Sent: Wednesday, October 06, 1999 5:29 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: G.723.1 vs. G.723 > > What is the difference between G.723.1 and G.723? And I don't mean the > numerical difference, as in 0.1 :-) Are they the same thing, and people > are > just being imprecise when they refer to G.723.1 as "G.723?" For SuperOp! > scheduling, they were both listed as two of the possible audio codecs, as > if > they were different. Does anyone truly support G.723 but not G.723.1? If > so, > I've never come across such an implementation. Also, what is the history > of > G.723.1? I believe the current version is something called 5.1. Is this > correct? Were there some intermediate versions? > > Paul Long > Smith Micro Software, Inc. >

1 0

Re: APC Number
by Sakae OKUBO 06 Oct '99

06 Oct '99

Dear Mr. Potter, > Title: Object Profile for ISUP Transport in H.225 using Generic Extensible > Framework. > > Source: Tony Stephens, BT. APC-1694 has been allocated to your contribution. 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