- sg16-avd - lists.packetizer.com

APC Documernt number
by Noriko Hosokawa 08 Oct '99

08 Oct '99

Dear Senthil In response to your request, APC-1705 and APC-1706 have been allocated to your contributions. APC-1705 > Source: Nokia > Title: On H.323 QoS APC-1706 > Source: Nokia > Title: On H.323 Mobility 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 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 1708 1709 1710 ---------------------------------------------------------------------------- ----

1 0

APC Document number
by Noriko Hosokawa 08 Oct '99

08 Oct '99

Dear Francois Audet In response to your request, APC-1703 and APC-1704 have been allocated to your contributions. APC-1703 > Source: Nortel Networks > Title: Tones and announcement in fast start APC-1704 > Source: Nortel Networks > Title: Modification to gateway decomposition architecture 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 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 1706 1708 1709 1710 ----------------------------------------------------------------------------

1 0

Uploaded
by Francois Audet 07 Oct '99

07 Oct '99

The following contributions have been uploaded in the incoming directory: APC-1656 Tunnelling of signalling messages in H.225.0 APC-1657 Applicability of tunnelling mechanism to QSIG ----- François Audet Tel:+1 408 565 5675 mailto:audet@NortelNetworks.com Nortel Networks Fax:+1 408 565 2375 http://www.NortelNetworks.com

1 0

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 07 Oct '99

07 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 07 Oct '99

07 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 07 Oct '99

07 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

Re: APC Number
by Sakae OKUBO 06 Oct '99

06 Oct '99

Dear contributors, The following APC numbers have been allocated to your contributions: Mr. Potter, APC-1683 >Title: ISUP Transport in H.225 using a Generic, Extensible Framework. > >Source: Morgan Potter, BT. Mr. Anderson, APC-1684 >Title: Multiple UsageIndications in Annex G >Source: Terry Anderson, Lucent Technologies and Lior Moscovici, >VocalTec > >Abstract: Specifying the meaning and use of multiple usageIndication >messages for a single call. >Purpose: for discussion APC-1685 >Title: Using CPL with H.323 >Source: Terry Anderson, Lucent Technologies >Abstract: The use of Call Processing Language (CPL) with H.323 will >require changes to both H.323 and the current CPL draft. This >document descibes some of the issues and the work that must be done. Mr. Bowen, APC-1686 >Source: Editor (R Bowen) >Title: Draft H.225.0 v4" Mr. Coldren, APC-1687 >SOURCE* : Lucent Technologies >TITLE : H.323 Annex F Hookflash Signaling Enhancements >PURPOSE : Proposal Mr. Hellstrom, APC-1688 >Source: Gunnar Hellstr $BSN (B, LM Ericsson >Title: H.323 Annex G Text Conversation, draft >Purpose: Discussion >Abstract: Some small changes are made after Berlin to the text >conversation annex G to H.323. APC-1689 >Source: Gunnar Hellstr $BSN (B, Ericsson >Title: RTP-Text for H.323 Annex G Text Conversation >Purpose: Information >Abstract: An RTP embedding of T.140 is specified in the IETF avt. APC-1690 >Source: Gunnar Hellstr $BSN (B, Ericsson >Title: F.MCVS conversation service description with Total >Conversation and Text telephony. >Purpose: Information and discussion >Abstract: Draft service description, with Total Convaersation and >Text Telephony included APC-1691 >Source: Gunnar Hellstr $BSN (B, LM Ericsson >Title: H.248 packages and additions for text telephony and total >conversation. >Purpose: Discussion and proposal >Abstract: A collection of proposed additions to H.248 and its annexes >for gateways supporting Total Conversation including text telephony . Mr. Qiaobing Xie, APC-1692 >Source: Motorola >Title: Using SCTP as an Alternate H.248 Transport Mr. Jones, APC-1693 >Source: Editor (P Jones) >Title: H.323 Implementers Guide 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: Looking for H.323 Annex docs
by Offer Pazy 05 Oct '99

05 Oct '99

Michaela, This is what I have. Not sure that is the latest. I think (but again not sure) that these annexes will only be part of REV4, not REV3 (See attached file: H323_AnnexF-05-ncm.doc)(See attached file: H323_AnnexF_comments.doc) Michaela Goffri <Michaela_Goffri(a)3COM.COM> on 10/05/99 11:23:44 AM Please respond to Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)mailbag.cps.intel.com> Sent by: Michaela Goffri <Michaela_Goffri(a)3COM.COM> To: ITU-SG16(a)mailbag.cps.intel.com cc: (Offer Pazy/IL/3Com) Subject: Looking for H.323 Annex docs Hi, Does anyone know where I can get the H.323: Annex F and Annex J documents? Thanks, Michaela

1 0

Re: Looking for H.323 Annex docs
by Euchner Martin 05 Oct '99

05 Oct '99

Draft H.323 Annex J as APC-1674 will be shorty finalized and presented at the next Rapp. meeting. Approved recommendation H.323 Annex F is available from the ITU. 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: Michaela Goffri [SMTP:Michaela_Goffri@3COM.COM] > Sent: Tuesday, October 05, 1999 11:24 AM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Looking for H.323 Annex docs > > Hi, > > Does anyone know where I can get the H.323: Annex F and Annex J documents? > > Thanks, > Michaela

1 0

Looking for H.323 Annex docs
by Michaela Goffri 05 Oct '99

05 Oct '99

Hi, Does anyone know where I can get the H.323: Annex F and Annex J documents? Thanks, Michaela

1 0

Re: Document Submission
by Sakae OKUBO 05 Oct '99

05 Oct '99

Dear Skip Cave, In response to your request, APC-1682 has been allocated to your contribution. SC> DOCUMENT TITLE: Media Redirection and Replication SC> SC> PURPOSE: The contribution proposes that the functional SC> entities described in this SC> contribution be included in the H.323 V4 document. SC> SC> ABSTRACT: This contribution identifies and describes SC> the requirements for a SC> distributed switching/conferencing functionality in H.323 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 ***********************************************************

1 0

H.323 Annex E: sequence numbering?
by Manoj Paul 04 Oct '99

04 Oct '99

Hi All, I have a few concerns about H.323 Annex E proposed document. My reference is the "Proposed changes to H.323 Annex E" document which was presented at Santiago meeting of SG13/16. Section E.1.3.2 states Serial Model. It says that Annex E stack will wait until a positive reply is returned * for the same Session-Identifier *. This means that an outgoing Annex E PDU can only contain multiple payloads of the same session only. Second, it implies that the sequence number (which is present in Annex E PDU header) must be unique now across < sender host+port, rcv host+port, session-id>. We can not make sequence number unique across <sender host+port, rcv host+port> only, because the message sequences should be blocking only for same session-identifier, as stated by the NOTE appended below section E.1.3.2. The Annex E Ack message, however, only contains the sequence number of Annex E PDU. How can the sender of an Annex E PDU will distinguish for what session's PDU this ack has come for? Because sender might have sent Annex E PDUs with the same sequence number for different sessions over a given < sender host+port, rcv host+port>. Am I missing something here. I will appreciate any clarifications on the above. regards, Manoj Paul.

2 1

Re: APC Numbers
by Roy, Radhika R, ALARC 04 Oct '99

04 Oct '99

Dear Mr. OKUBO: I am sending this mail again. Please issue the APC numbers for three contributions as indicated earlier. Best regards, Radhika R. Roy, AT&T > -----Original Message----- > From: Roy, Radhika R, ALARC > Sent: Thursday, September 30, 1999 1:57 PM > To: 'okubo(a)giti.or.jp' > Subject: APC Numbers > > Dear Mr. OKUBO: > > Please provide APC numbers for the following contributions (expected to be > joint contributions along with other companies, but the names of other > companies will be provided at the time of actual distribution): > > 1. Call Flows Supporting H.323 QOS > 2. Extensions of H.225.0 and H.225.0 Annex G Signaling Messages and their > ASN.1 Syntax to Support H.323 QOS > 3. Framework for Mapping of H.323 QOS over Packet-based Networks > > Best regards, > > Radhika R. Roy > AT&T > + 1 732 420 1580

1 0

AW: [Q] H.323 supplementary services
by Karl.Klaghofer＠ICN.SIEMENS.DE 04 Oct '99

04 Oct '99

It is Study Group 16 (Question 13) who standardizes Supplementary Services for H.323 (i.e. the H.450 series). You should use this list and/or the h323implementors(a)imtc.org list for questions related to H.450 supplementary services for H.323. Karl > -----Ursprüngliche Nachricht----- > Von: Lee Hyoung soo [SMTP:soo@LGIC.CO.KR] > Gesendet am: Mittwoch, 29. September 1999 07:39 > An: ITU-SG16(a)mailbag.cps.intel.com > Betreff: [Q] H.323 supplementary services > > Is there any study group or mailing list related with supplementary > services > in H.323? > > best wishes, > > soo.

1 0

I have seen it
by Lenny 03 Oct '99

03 Oct '99

FREE E-COMMERCE WHEN YOU HOST WITH US!! Tired of expensive e-commerce software, set up fees and leasing contracts? Here is the deal: You host your site with us and you get free E -Commerce, including a merchant account, real-time software and shopping cart. If you wish to stay with your current hosting company you still can get the same deal. Check it out first and make an informed decision. You have never seen a package deal like this before: * Your own merchant account with one of the lowest rates in the industry * Real-Time software to accept VISA, MASTERCARD, AMEX, DISCOVER/NOVUS, DINERSCLUB/CARTE BLANCHE, JCB * Direct deposit within 48 hrs into your checking account * Shopping Cart store front software with an easy to use web based interface * Real-Time Credit Card Processing software * Virtual terminal for phone/fax/mail orders * E-mail receipts * Recurring billing feature with batch uploads * Automatic batch closing * Address verification system (AVS) * Back office to 24/7 access account history * 50 MB (megabytes) of disk space * 30 GB (gigabyte) of data transfer per month * 25 POP3 E-mail accounts * Unlimited alias E-mail addresses * Live web site statistics * Unlimited FTP uploads * Anonymous FTP * CGI directory for your own scripts * Site control panel * Installation included * Tech support included All this and more when you sign up for our E-Commerce Hosting plan for ONLY $69.95 per month and a one time set up fee of $199.00. That's right. NO ADDITIONAL SET UP FEES or application fees for your merchant account real-time software or shopping cart storefront. A one-stop E-Commerce solution. And the best is: NO LEASING, NO LONG TERM COMMITMENT. YOU CAN CANCEL ANYTIME. We are also specialized in TOP 10 search engine placement for the BIG 8: AltaVista Infoseek HotBot Excite Aol NetFind Lycos WebCrawler Yahoo We guarantee your TOP10 placement or our service is FREE. Request our free E-mail information by replying to: mailto:qwen76@yahoo.com?subject=INFO_PLEASE **************************************************** Remove at mailto:veng91@netscape.net?subject=remove ****************************************************

1 0

Re: Q12-14/16 Red Bank meeting
by Reddy, Paul K 01 Oct '99

01 Oct '99

Dear Mr. Sakae OKUBO, My name is Paul K. Reddy from Intel Corporation, I am requesting you to assign an APC numbers for the contributions I want to bring to New Jersey's SG-16 Q13/16 meeting. Contribution 1: Source: Intel Title: The H.323 terminal with secured software based Universal Subscriber Identification Module (USIM) and Inter-working Function with PLMN(public land and mobile networks). Contribution 2: Source: Intel Title: User Mobility and Service Mobility services for Wireless Subscribers with H.323 terminals accessing Multimedia over IP (MoIP) and PLMN networks. Thanks for your help. regards, Paul Paul K. Reddy Broadband & IP Telephony Lab, Intel Corporation, 2111 NE 25th Ave., Hillsboro, OR -97124 USA. +1 (503)-264-9896 -----Original Message----- From: Sakae OKUBO [mailto:okubo@GITI.OR.JP] Sent: Thursday, September 30, 1999 1:10 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Q12-14/16 Red Bank meeting Dear Q12-14/16 experts, This is to report that we have obtained the final approval of the SG16 management for holding the Rapporteur meeting in Red Bank during 18-22 October. Please note the following deadlines for submission of your 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 /// The meeting notice is available at: ftp://standard.pictel.com/avc-site/9910_Red/Notice_Red_Bank.txt or http://standard.pictel.com/ftp/avc-site/De_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

draft-04 vs. Results from Berlin
by Nancy-M Greene 30 Sep '99

30 Sep '99

For each point raised at the ITU-T SG16 meeting in Berlin, I have put the reference in the new Megaco/H.248 draft that covers it. This can be used to determine how the current draft implements the desired change requested in Berlin. The Berlin draft is: ftp://standards.nortelnetworks.com/wash99/MegacoH248v9Chgs.doc or ftp://standards.nortelnetworks.com/wash99/MegacoH248v9Chgs.zip The draft-04 of Megaco/H.248 is: ftp://standards.nortelnetworks.com/latest/megaco-h248_protocol.pdf, or ftp://standards.nortelnetworks.com/latest/draft-ietf-megaco-protocol-04.txt Nancy -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com > Technical additions/changes/issues > ---------------------------------------------------- > T1) Section 6.2.2.2: Intercept: added a topology descriptor as a context > parameter, to allow operator intercept, wiretapping - satisfies the > regulatory requirement of only allowing the tapping of one side. Also, > removed InterceptToken from ABNF - this is done using context parameters > instead. ***Need to review this topology descriptor proposal to see > whether > it works, and whether it could be covered already in another way, using > the > muxing descriptor for example. > see draft-04 7.1.16 Topology Descriptor > T2) Section 6.2.3.3: TerminationIds - Changed "arbitrary string" to > "arbitrary schema" so it is not tied to a text encoding (there may be a > better word). Note that there is NO special meaning about the / character. > Added "In a text encoding of this protocol". Added sentence > "TerminationIDs > of physical Terminations are provisioned in the Media Gateway". > Re-included > text describing use of hierarchical terminationIds. > see draft-04 Section 6.2.2 > T3) Section 6.2.3.5: ***Make sure the parameter tables from the Santiago > text go in an annex as parameters of one of the basic packages. These > parameters would be included in the LocalDescriptor. > see draft-04 Annex D. > T4) Section 6.2.3.5: ***There is still an issue with tx and rx descriptor > names: when you do an add on the RTP termination, in the response you will > get params for RxDescriptor (local information). BUT it is also a transmit > descriptor. So, there is still a wish to call rxDescriptor the > localDescriptor, and txDescriptor the remoteDescriptor. Note added. > In draft-04, the 3 descriptors a StreamDescriptor may have are now called LocalControl, Local, and Remote. > T5) Section 6.2.3.6: ***Issue with ROOT TerminationId - It seems a bit of > a > kludge to use a special ROOT terminationId to refer to the entire MG - can > we make TerminationId optional in AuditValue, AuditCapability? then we > would > not need ROOT. Check effect to ServiceChange. > In draft-04 - ROOT left as is. Useful for applying commands to the properties of the entire MG. > T6) Section 6.3.2.11: ***Need to add a way to configure the level of > embedding of signals/events descriptor, and MGC needs to be able to find > out > the level of embedding. > In draft-04, Embedding is explicitly limited to one level of embedding (see end of 7.1.10). > T7) Section 6.3.2.11: Re-added the sentence saying at least one level of > embedding should be supported. (Why was it removed?) > In draft-04, sentence changed to say that only ONE level of embedding is allowed (see end of 7.1.10). > T8) Sectio 6.3.2.15: DigitMapDescriptor - Added a start timer, ***still > need > to add text for naming/use of transient digit maps. ***Also need to make > sure that if the MG fails to load a digit map, event notification > continues > anyway. > see draft-04 Section 7.1.14 - are two *** points above covered in draft-04? > T9) Section 6.3.2.15: Re-added some of the text in digitMapDescriptor on > wildcarding. > see draft-04 section 7.1.14 > T10) After Section 6.3.3.8: Put/Delete removed - they are for future > consideration. > ok > T11) Section 6.3.2.10, 6.3.4, Annex A, B, C: Text vs binary: Annex A added > for modified ASN.1 that describes the protocol syntax, Annex B for the > ABNF, > and the translation mechanism, and Annex C for the binary and the binary > translation mechanism. > See draft-04 Annexes A, B, C. > Agreements: ABNF remains normative. ASN.1 and compiler to compile into the > ABNF already written, will also be added as normative when they are > available. Sentence added: " This compiler is a living tool that will > likely > be enhanced over time. To start, this tool should be tested to verify that > syntax can be compiled to the ABNF defined below. > > It is expected that industry forums would define profile for use of H.248 > and this would include whether text vs binary is used, as well as which > packages would be used, etc. In Section 6.3.4, sentences added: "MGCs > should > support both encoding formats. MGs may support both formats." > see draft-04 section 7.2.9 Generic Command Syntax: "The protocol can be encoded in a binary format or in a text format. MGCs should support both encoding formats. MGs may support both formats" > T12) Section 6.3.2.10, Annex D: A new proposal has been added for native > encoding of StreamDescriptors (SDP codepoint is still there). Changes made > to ABNF, reference made to SDP RFC, and to native encoding. ***Media > descriptor parameter and value tables put into Annex D - this annex still > needs work. ***Need to add in the sentence: "It is recommended that the > native encoding method for stream descriptors be used when encoding is > binary, and the SDP method be used when the protocol encoding is > text-based." > See draft-04 - Annex D is not complete. > T13) Section 6.4.1, 6.4.3.1,6.4.3.2, 6.4.3.3: Simplify transaction > semantics > - changes to text and to ABNF (Annex B) made: removed the concept of > rollback on transactions - the document did not define how you could roll > back commands that actually cause physical changes on the MG, e.g., > sending > of a signal, subtracting a termination from a context. > > It was decided that in fact, all a transaction does, is ensure that > commands > occur in a particular order, and that no commands after a command that > fails, gets executed. In a TransactionAccept, need to say what a response > is > - added sentence on this. In a TransactionReject, the command that failed > has error code, all the rest of the commands are not executed. > See draft-04 section 8. > T14) Section 6.4.1: Transaction figure - renamed "action" to "contextId". > See draft-04 Figure 5, section 8 > T15) Section 6.5: ***An example use case for text telephony will be added > (need to move all examples to an informative appendix). > Added in draft-04 - See last example in Annex G. > T16) Section 6.6: Transport: Proposed text added - it does not change > current transport functionality in draft-ietf-megaco-protocol-03.txt. > ***Editorial changes to this section will be suggested. > Transport section is draft-04 Section 9; Transport using UDP and ALF is Annex E, Transport using TCP is Annex F > T17) Section 6.7: Security section - some clarifications to text added - > you > do not have to implement AH-in-Megaco/H.248 if you have IPSEC. Only ONE of > the two schemes is used at one time - if IPSEC is on both MGC and MG, it > is > used, otherwise AH-in-Megaco/H.248 is used. Proposed text: "The MG need > only > support IPSEC if it is capable. Otherwise it must support > AH-within-Megaco/H.248." ***Section too long, needs rewording. > see draft-04 Section 10. "Implementations of the MEGACO/H.248 protocol SHALL implement IPsec where the underlying operating system supports IPsec. Implementations of the MEGACO/H.248 protocol using IPv4 SHALL implement the interim AH-within-MEGACO/H.248 scheme. However, this interim scheme SHALL NOT be used when the underlying network layer supports IPsec. IPv6 Implementations are assumed to support IPsec and SHALL NOT use the AH-within-MEGACO/H.248 interim scheme." > T18) Section 6.7: *** Security: request clarification on how the MGC knows > what the security mechanism is that the MG is using, and vice versa. > See draft-04 Section 10. > T19) Section 7: Packages: a proposal for the writing of base packages, > along > with proposals for the base packages will be turned into an internet-draft > and submitted for comment. > See draft-04 Section 12. > T20) Section 7.2: Text added for IANA registration of packages. ***Text > still needs work. Agreed that IANA is the place to register ALL packages. > Suggestion that procedures should say that for ITU-T packages, we would > standardize the first few characters of the package name, and that a > public > document describing the packages are not necessarily required. > See draft-04 Section 13. > T21) Annex B: ***AuditCapabilities - need to allow multiple copies of > descriptors to be returned. ABNF needs to be updated. > See draft-04 Annex B - ABNF allows multiple copies of descriptors. > T22) Annex D, SDP: ***Need to be able to pass a QoS parameter to the MG. > (Note: Place to define this would be in the Package that defines > parameters > to the LocalDescriptor. Also needed in SDP.) > SDP allows a bandwidth parameter - check SDP RFC. > Editorial changes > ------------------------- > E1) Section 1: Have an ITU scope, and an IETF scope. Text that is there is > the ITU scope. > ok > E2) Architecture: Change architecture section back to Santiago determined > version of the text, and move it to H.323, instead of having it as an > annex > to H.248. If architecture is moved out, all definitions (section 3) that > pertain to the architecture section and not the protocol, for example, GK, > can be deleted. (Note - there is still an issue of where the architecture > section will live, but in any case, it will NOT be in the IETF version of > the protocol). > ok - draft-04 has no architecture section. > E3) ***Section 3: Add definition for stream, signal, event (not done yet). > see draft-04 Section 3: definition for stream, descriptor added. Still need to remove defintions of GK, etc, that are no longer referenced in this protocol document. > E4) Requirements section (old section 6) is removed. No need to reference > requirements doc in this document. > ok > E5) Section 6.1:Removed reference to "interface A". > ok > E6) Section 6.2.1, 6.2.3.1: Terminations Basic Concepts, and Overview - > some > wording changes. For example, in the case of intercept for wiretapping, a > third termination in a context does not make the context a conference > bridge. Also conference replaced by association. > see draft-04 Section 6.2 > E7) ***Section 6.2.2.1: Context general - wording changes, still needs > work. > see draft-04 Section 6.1 > E8) Section 6.2.3.1 Change Audit to AuditValue just before Termination > Dynamics section. A few other changes to paragraph describing muxing. > ok, see end of draft-04 Section 6.2 > E9) section 6.2.3.5, 6.2.3.8: The "Support" columns in several tables have > been removed (not relevant now). This makes it look like those entire > tables > have been changed - in fact it is just that a column has been removed. > ok > E10) Section 6.3.2.12: Clarifications made to definition of "brief": "no > timeout value is needed". > see draft-04 section 7.1.11 > E11) Section 6.3.3: Clarified text in Command API describing the syntax > used. > ok > E12) Section 6.3.3.1: Add command - MediaDescriptor now marked as optional > in the text. > see draft-04 section 7.2.1 > E13) section 6.2.3.5: Some clarifications made in the section on > Termination > Properties and Descriptors. > ok > E14) Section 6.2.3.7: Added section for templates, and marked it for > further > study. > for further study sections removed in draft-04. > E15) Section 6.2.3.8: Added section for scripting descriptors (marked for > further study). Make sure we can add them later to the protocol, e.g. make > sure it can be used as an alternative way of describing digit maps. > for further study sections removedin draft-04. Scripting can be added later as a new parameter to commands called a ScriptingDescriptor. > E16) Section 6.3.2.9: LocalDescriptor - mode not defined well - sentence > removed. > Termination state defined in draft-04 Section 7.1.6 (test, in service, out of service), Stream Mode in Section 7.1.8: "The allowed values for the mode parameter are "send only" (sendonly), "receive only" (recvonly), "send/receive" (sendrecv), "inactive" (inactive), "loop back" (looback) and "delete" (delete). "Send" and "Receive" are with respect to the stream within a termination, so that, for example, a stream set to mode=sendonly can talk but it cannot listen. Mode set to delete is used to remove a stream from a termination." > E17) Section 6.3.2.11: ***Question: does loop in eventBuffer mean that > event > is returned each time it occurs without having to resend an > EventsDescriptor > - need to make text clearer. > see draft-04 Section 7.1.6 - is the text clearer now?: "2) BufferedEventNotificationMode - specifies whether the Media Gateway is expected to detect the requested event and notify the controller once (step by step) or repeatedly". > E18) Section 6.3.5: ***Need to renumber error codes (Need to discuss this > - > may be better to leave them with the numbering they have.) > - see draft-04 Section 7.3 - leave numbering as it is > E19) Section 7.2: ***Verify that all places that require IANA registration > in one place are grouped - error codes, packages, - (Events and signals do > NOT need to be registered - they are defined in packages). > > > > Questions > -------------- > Q1) What is the media type parameter of a termination? Is it in the stream > descriptor? or is it at the termination level? In describing the > muxDescriptor, it is stated that the media type of a termination included > in > a mux is set to mux... > erroneous text removed in draft-04 . > Q2) Check semantics in embedded signals - what happens if one of the > signals > fails - is the next signal applied or is it an error? > check. > Q3) Check that you can put two signals on a line and they are mixed. > > Q4) How does MGC to find out if MG supports digit maps? By just sending > them, and the MG ignores them if it wants to? > -------------- > > Nancy > > -------------------------------------------------------------------------- > Nancy M. Greene > Internet & Service Provider Networks, Nortel Networks > T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com >

1 0

FW: Megaco/H.248 Packages Teleconference
by Tom-PT Taylor 30 Sep '99

30 Sep '99

Second try. > -----Original Message----- > From: Taylor, Tom-PT [CAR:B904-I:EXCH] > Sent: Thursday, September 30, 1999 3:17 AM > To: megaco(a)standards.nortelnetworks.com; itu-sg-16(a)mailbag.intel.com > Subject: Megaco/H.248 Packages Teleconference > > I have started by reserving 20 ports for the call -- I expect this will > increase as your requests come in (mailto:taylor@nortelnetworks.com). The > phone number to call is > > +1 919 905 6338 (Nortel attendees call 260 6338). > > Once dialled in, if you have DTMF, dial the following passcode when > prompted: > 209516# > If you do not have DTMF, wait for the operator to come on line and then > state the above passcode. > > If the fact that you have to pay to connect to this number is a barrier to > your participation, please let me know and I'll figure out how to reserve > a > toll-free number instead. > > Tom Taylor > Advisor -- IPConnect Standards > E-mail: taylor(a)nortelnetworks.com (internally, Tom-PT Taylor) > Phone and FAX: +1 613 736 0961

1 0