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

Queries to support Fax @ GW
by Sunil Mahajan 29 Jun '99

29 Jun '99

Hi, We have some queries related to Fax support at Gateway using H.323 Annex-D and T.38. - How the originating gateway (after detecting CNG) tells/informs the destination Gateway, that the call is a fax call [assuming two gateways are communicating using H.323] - How do we open logical channels for fax communication (T.38) - Annex-D tells that openLogicalChannel can specify TCP/UDP option in the OLC structure - which parameter tells TCP/UDP option in OLC? is it the media transport type in transport capability ? - what kind of capability is specified for fax - is it voice/data ? or a separate capability structure? Any kind of information, help or pointer would be highly appreciated.... Regards, Ravi Kiran Sunil Mahajan

1 0

New T.35
by Paul E. Jones 28 Jun '99

28 Jun '99

Folks, As many of you know, the latest T.35 document supports more than 254 country codes. In the newest document, T.35 says that one or two octets may be used to indicate the country code. If the first octet contains 1111 1111, the second octet will contain the country code. Unfortunately, the syntax in H.245 does not utilize extension markers, so there is no place to hold second octet for the country code. Therefore, I would like to propose that, both for H.225.0 and H.245, we change the comments in the ASN.1 from: t35CountryCode INTEGER(0..255), -- country, as per T.35 t35Extension INTEGER(0..255), -- assigned nationally manufacturerCode INTEGER(0..65535), -- assigned nationally to the following t35CountryCode INTEGER(0..255), -- country, as per T.35 Annex A t35Extension INTEGER(0..255), -- assigned nationally, unless the -- t35CountryCode is 1111 1111, in -- which case this field shall -- contain the country code found -- in T.35 Annex B manufacturerCode INTEGER(0..65535), -- assigned nationally This may be a perversion of the t35Extension field, but we have a limited number of options if we wish to support the usage of two octets for a country code in H.245. What are your opinions? Best Regards, Paul

1 0

h.323 mobile extension
by Edgar Martinez [1] 27 Jun '99

27 Jun '99

Jin and Liao, I will like to inform you that ITU-sg16 has open up two new annexs in H.323 to support mobility. H.323 Mobile Annex It was agreed during the joint meeting with Q11 to create a mobile Annex for H.323. This would take the form of a document or documents that address mobility issues, including: Mobility, including user and service mobility Mobile issues including Layer 2 issues & timers Header compression Handoffs and the H.323 system architecture Next Meeting Decision H.323 Annex H (User and Service Mobility in H.323) E. Martinez (Motorola) H.323 Annex I (Terminal Mobility in H.323) (Toshiba) Attached is the meeting information. I resent this message because the attachments fail to deliver. -- Subject: Re: comments on DTR07001v1_1_2r1 Date: Sun, 27 Jun 1999 07:57:36 +0800 (CST) From: Wan-jiun Liao <wjliao(a)cc.ee.ntu.edu.tw> To: "Edgar Martinez [1]" <martinze(a)cig.mot.com> CC: "Yang, Jin (Jin)" <jinyang(a)lucent.com>, TIPHON_WG7(a)LIST.ETSI.FR, Vli(a)eee.hku.hk, Wan-jiun Liao <wjliao(a)cc.ee.ntu.edu.tw> Dear Edgar and Jin, Thanks for your valuable comments on the part of mobile extensions to h.323. I am the author of this section. The point we would like address for our h.323 mobile extension is that we would like to demonstrate that h.323 provides an excellent environment for mobility support and thus tend to make modifications as few as possible to h.323 for mobility support. In fact, the article has been revised and extended (from infocom'99 one) since I came back from TiPHON meeting at Bangkok in May. Attached please find a copy of new revised version of mh323. Some of your questions may have answered. Re. the following sentences, > My thoughts, rather then propose/add all the mobility extensions to > H.323. > I rather work on how to Tunnel Mobility Management (MM) messages from > the RAN > to a Wireless Call Server (WCS) via H.323. While in the same context > work-out the > WCS interface to the Gatekeeper to Tunnel through the TCAP/MAP messages > to and > from the IP network and the GSM MSC and HLR for interworking. We have a work currently going on with a similar idea to this one. However, we still stick on making as less as possible modification to current h.323 for mobility support. The new work is almost done and will be able to support the IP network and the GSM (or DECT) MSC and HLR for interworking. We may presnet our new work at the next TiPHON's meeting then. Thanks for your comments. Best Reagrds, Wanjiun Liao On Sat, 26 Jun 1999, Edgar Martinez [1] wrote: > Dear Jin, > > I am not the author of the section but I have some comments to add: > > "Yang, Jin (Jin)" wrote: > > > > Dear WG7 "roamers", > > > > I am reading the DTR07001 draft on the part of "mobile extension to H323", > > section 5.11 with the following comments (I will not be able to attend the > > next meeting, so post my comments here): > > > > ..... > > "With H.323, data, voice, and video in an IP call are transmitted using the > > Real-time Transport Protocol [21]. " > > > > data is not using RTP. voice and video does. > > If we change the wording like the following will it be OK? > > "With H.323, voice-data, and video-data in an IP call are transmitted > using the > Real-time Transport Protocol [21]. " > > > > ..... > > "Call setup and other call control signaling messages are carried > > out-of-band, sent through different paths other than those for the payload > > traffic. " > > > > not necessarily different path. > > We can change the text to read: > > "In a reliable network Call setup and other call control signaling > messages > could be sent through different paths other than those for the payload > traffic. " > > -- > *A reliable network are system that have a backup link connection > running a reliable transport protocol like sigtran's CTP. > > > > > > ....... > > "Under the current version of H.323 service scope, however, host mobility is > > forbidden, resulting from the underlying IP mechanism that implicitly > > assumes that a host is fixed. " > > > > Is this true? H323 is OK for mobile hosts if the mobility is provided at > > lower layers, which can be mobile IP based, or replying on layer2,e.g. > > wireless LAN layer 2 mobility support. H323, as an application layer > > protocol can be transparent. > > ...... > > Yes, > > I propose to take out the foolowing: > > >"Under the current version of H.323 service scope, however, host mobility is > >forbidden, resulting from the underlying IP mechanism that implicitly > >assumes that a host is fixed. " > > And replace it with: > > "H323 could support mobile hosts if the mobility is provided at > lower layers e.g., using IPv6, which can be mobile IP based, > or replying on layer2 wireless LAN layer 2 mobility support. > H323, as an application layer protocol can be transparent." > > I tend to agreed with you and hope to see support of TCAP/MAP > support on top of IPv6. > oops! > > > > "Moreover, Voice over IP service is a real-time connection-oriented service > > over packet-switched IP-based networks. Neither the circuit-switched > > cellular phone approach nor the connectionless Mobile IP mechanism is > > capable of providing mobile Internet telephony service. " > > > > why? connection-oriented applications do not necessarily require > > connection-oriented transport. Although Mobile IP, as it is defined at this > > stage, has its limitations/issues for real-time applications in a highly, > > global mobile environment, people are working on it to resove them. > > > > Iam looking towards 3GPP or TIPHON to provide us the option to send VoIP > on > the RAN IU-ps link. Reference to Liassion Statement sent to WG7 Bangkok > 13TD146. As a first step. > > > .... > > "New approaches are required for mobile IP telephony. > > Through proper call setup signaling with the H.323 Gatekeeper, the address > > of the target endpoint (i.e., callee or called party) can be resolved before > > call establishment, enabling the service redirection to be completely > > handled in the application layer. Thus, it realizes mobile IP telephony > > services with IP. This approach enables mobility support without the need > > for additional new entities and with minimal modifications to the H.323 > > standard, allowing such mobile IP telephony service to be a valued-added > > feature in the existing H.323-compliant Internet telephony systems." > > > > what is the extension, at the end? > > > > My thoughts, rather then propose/add all the mobility extensions to > H.323. > I rather work on how to Tunnel Mobility Management (MM) messages from > the RAN > to a Wireless Call Server (WCS) via H.323. While in the same context > work-out the > WCS interface to the Gatekeeper to Tunnel through the TCAP/MAP messages > to and > from the IP network and the GSM MSC and HLR for interworking. > > > > > ------------------------------------------------------------------- > > Mail archive for TIPHON_WG7 can be browsed at the following url : > > > > http://www.etsi.org/tiphon/mailing.htm > > ------------------------------------------------------------------- > -- Edgar Martinez - Principal Staff Engineer Email mailto:martinze@cig.mot.com FAX 1-847-632-3145 - - Voice 1-847-632-5278 1501 West Shure Drive, Arlington Hgts. IL 60004 Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/ Subject: Notice of the Berlin meeting Date: Fri, 25 Jun 1999 15:14:57 +0900 From: Sakae OKUBO <okubo(a)GITI.OR.JP> Reply-To: Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)mailbag.cps.intel.com> To: ITU-SG16(a)mailbag.cps.intel.com To Experts of ITU-T SG16 Q.12/16, Q.13/16 and Q.14/16 Cc Mr. P-A. Probst, Chairman of SG16 Mr. G. Helder, Vice-Chairman of SG16 Mr. F. Tosco, Chairman of WP2/16 Mr. F. Bigi, ITU-TSB Mr. T. Geary, Rapporteur for Q.11/16 Mr. G. Sullivan, Rapporteur for Q.15/16 Mr. J. Ott, Teles Mr. S. Wenger, Teles De Sakae OKUBO Rapporteur for Q.12/16 in ITU-T SG16 TAO Waseda Research Center 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 Dale SKRAN Rapporteur for Q.13/16 in ITU-T SG16 Ascend Communications, Inc. 621 Shrewsbury Avenue Shrewsbury, NJ 07702 USA Tel: +1 908 450 1635 Fax: +1 908 450 1611 E-mail: Dale.Skran(a)ascend.com Glen Freundlich Rapporteur for Q.14/16 in ITU-T SG16 Lucent Technologies 11900 N. Pecos Westminster, Colorado 80234 USA Tel: +1 303 538 2899 Fax: +1 303 538 3907 E-mail: ggf(a)lucent.com ---------------------------------------------------------- Subject: Notice of Q.12-14/16 Rapporteur Meeting in Berlin Date: 25 June 1999 ---------------------------------------------------------- Dear Q.12-14/16 experts, The subject meeting of ITU-T SG16 experts will be held in Berlin, Germany at the kind invitation of TELES AG. Please note that Q.11/16 and Q.15/16 will meet concurrently at the same place and have joint sessions with Q.12-14/16. 1. Date ^^^^^^^ 2 (Monday) - 6 (Friday) August 1999 starting at 9:00 on the first day 2. Venue ^^^^^^^^ GRAND HOTEL ESPLANADE BERLIN Luetzowufer 15 10785 Berlin-Tiergarten Voice: +49 30 254 78-0 Fax: +49 30 265 1171 EMail: info(a)esplanade.de WWW: http://www.esplanade.de/eframe.htm 3. Topics (tentative) ^^^^^^^^^^^^^^^^^^^^^ 1) Review of the relevant group meetings 2) Q.12/16 B-ISDN multimedia systems and terminals - White contribution for H.222.0 Amendment 7 - H.321 v2 Implementers Guide - H.310 v2 Implementers Guide - Work with Q.13 on high quality video transmission over IP - Future AV communication systems 3) Q.13/16 Packet switched multimedia systems and terminals - Finalize white contributions for: * H.323 V3 * H.225.0 V3 * H.450.8 (Name Identification) * H.323 Annex G (Text SET) - Update H.323 Implementers guide - Further Develop: * H.323 Annex F (Secure SET) * H.323 Annex H (User/Service Mobility) * H.323 Annex I (Terminal Mobility) * H.450.9 (Call Completion on Busy) - Work with Q.14 on H.GCP white paper - Work with Q.14 on H.246 Annex C white paper - Work with Q.14 on H.246 Annex D 4) Q.14/16 Common protocols, MCUs and protocols for interworking with H.300-series terminals - Finalize white contributions for: * Prepare H.gcp * Prepare H.246 Annex C * Prepare H.245 V6 * Prepare H.243 V2 * Prepare H.224 V2 - Progress work on IN-H.323 interface (H.246 Annex D) - Update implementers guide 5) Coordination with Q.11/16 and Q.15/16 - System aspects - Video coding aspects 6) Interaction with other groups 7) Future work plan 4. Documents ^^^^^^^^^^^^ /// Registration of the document: by 23 July (Friday) /// /// Distribution of the document: by 26 July (Monday) /// /// Use the ftp site (or e-mail reflector) for distribution /// 1) When you are going to submit a document, please notify S. Okubo as soon as possible, by 23 July (Friday) at the latest. Document number (APC-1nnn) will be allocated. Early indication of your submission plan is welcome and encouraged. Note - Prefix "APC" comes from Atm (Q.12/16), Packet based (Q.13/16) and Common protocols (Q.14/16) based on the coordination with Q.1 ("Q1City"), Q.3 ("T120"), Q.11 ("Q11"), Q.15 ("Q15") groups. 2) You are advised to include a header as follows: ------------------------------------------------------------------ | | | ITU Telecommunication Standardization Sector Document APC-{1nnn}| | Study Group 16 {Version m if relevant}| | Q.12-14/16 Rapporteur Meeting {Date}| | Berlin, 2-6 August 1999 | | | | SOURCE*: { } | | TITLE : { } | | PURPOSE: {Proposal, Discussion, Information, Report, etc.} | | | | _________________________ | | | | | | | | *Contact: Name, e-mail | ------------------------------------------------------------------ 3) All the contributors are requested to distribute their documents as early as possible, at least 7 calendar days in advance of the meeting (26 July or before) by posting them at either of the following: - PictureTel ftp site (please advise S. Okubo of your posting) Site: standard.pictel.com/avc-site Login name: anonymous Directory: Incoming - Q.12-14/16 experts reflector e-mail address: itu-sg16(a)mailbag.jf.intel.com Please avoid the use of reflector when your document is voluminous. 4) Input documents can be retrieved from /9908_Ber directory of the ftp site. 5) Please bring 80 copies of your document to Berlin if it should be in hardcopy. Your cooperation is needed to start the meeting with all the documents at hand; please note that the copying capacity at the meeting site is very limited and expensive. 6) The document distribution / presentation at the meeting will be electronic (i.e. participants must bring their laptops along). 5. Logistic information ^^^^^^^^^^^^^^^^^^^^^^^ Please see the invitation distributed by the meeting host (http://standard.pictel.com/ftp/avc-site/9908_Ber/Invitation.txt). 6. Registration ^^^^^^^^^^^^^^^ To confirm your meeting attendance, please reply directly to TELES using the registration form distributed by the host (http://standard.pictel.com/ftp/avc-site/9908_Ber/registration-form.doc) up to and including 1 July for early regsitration with a meeting fee of DEM 500,00. Please note that after this date, the registration fee becomes DEM 650,00. In addition, please send a separate e-mail registration to Mr. Ott and copy the Rapporteurs on this e-mail. Please use the subject and message body format shown below. To: jo(a)teles.de Cc: okubo(a)giti.or.jp, dskran(a)ascend.com, ggf(a)lucent.com, tom.geary(a)conexant.com, garysull(a)microsoft.com Subject: Berlin meeting registration NAME: COMPANY: EMAIL: ARRIVAL: DEPARTURE: Please attach a *small* photograph of yourself as GIF or JPG format and send this to jo(a)teles.de attached to the registration mail. 7. Hotel Room Reservation ^^^^^^^^^^^^^^^^^^^^^^^^^ Please directly contact GRAND HOTEL ESPLANADE BERLIN mentioning "ITU- Meeting" to obtain the special rate; DEM 280,00 -- approximately USD 150 -- per night including a breakfast buffet for a single/double room. You need to guarantee the room reservation with your credit card. CUTOFF DATE for the special room rate is Thursday, 1 July 1999. We are looking forward to meeting with you in Berlin. Sincerely yours, Sakae OKUBO Dale SKRAN Gary THOM ----------

1 0

Re: Interoperability and Extensibility
by Pete Cordell 25 Jun '99

25 Jun '99

Tom, If you haven't had a chance to read it yet, I think my internet-draft covers off a lot of the syntactic issues on messaging. (Accessible at: http://www.tech-know-ware.com/draft-cordell-messaging-00.txt) On the semantics side, I like the SIP "Require:" construct. This indicates packages or parameters that must be understood. Anything else is optional. The transaction is cancelled if the server doesn't understand something that is required. It's essentially equivalent to 'comprehension required' in Q.931 although its more expressive in what needs to be understood. This is a simple technique, but is actually very powerful. Regards, Pete ============================================= Pete Cordell pete(a)tech-know-ware.com ============================================= -----Original Message----- From: Tom-PT Taylor <taylor(a)NORTELNETWORKS.COM> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> Date: 24 June 1999 19:59 Subject: Interoperability and Extensibility >We face a continuing tension between the requirement to ensure >interoperability and the desirability of minimizing the size of the core >protocol, particularly at the MG. We also have to make sure our protocol >has well-defined procedures for adding both ad hoc (i.e. proprietary or >experimental) and formal extensions. This note suggests some principles >which we should follow in response to these considerations. > >There are really two levels of interoperability to deal with: syntactic (can >the message be parsed?) and semantic (can the message recipient perform the >actions which the sender is requesting?). > >At the syntactic level, I believe that we can agree on these principles: > >I-1: Every message must be fully parsable down to a certain level of detail, >even if it contains extensions unsupported by the recipient. > >I-2: Our protocol document must specify the syntax by means of which >extensions are identified. > >I-3: The protocol must provide the means for the recipient to identify in >its response to any message all unsupported extensions it encountered in >that message. > >There is an open issue here: what is the minimal parsability level we want >to specify? Suggestion: all messages are parsable down to the command and >parameter level at a minimum. Here I use the term "parameter" to imply >either a simple data value or a potentially complex data structure >identified as a syntactic element in our API definitions. The implication >of this suggestion is that extensions can add no new commands, no new >command parameters, only new possible values for command parameters and new >event packages. I'm sure others will have comments on this. > >Now we get to the interesting part: semantic interoperability. I'll start >with what I hope are a couple of obvious statements. > >I-4: Not all implementations will support all event packages, all possible >parameter values, or whatever else we allow to be extended. > >I-5: The protocol definition must include a specification of what the >receiver does if a message contains an unsupported extension. > >On this latter point, do we enforce the transaction concept at all levels >and fail the transaction, requiring the sender to reissue the command >without the offending value? This is definitely a workable solution. We >could go further and introduce the ability to say in a message whether a >given field is a transaction-stopper, but I'm not sure that capability would >be used in practice -- it wasn't when we had it in IPDC. > >Now for the crucial question: if I-4 is true, what criteria do we use to say >what features MUST be supported by any given implementation? Can we >distinguish between required support in MGC implementations, versus required >support in MG implementations? How does each side of the Megaco interface >determine what the other side supports, other than by parsing transaction >rejections? Here are some propositions to use as a basis for discussion: > >I-6: The Megaco/H.GCP specification should be organized into a basic >protocol specification which must be satisfied by all implementations, plus >annexes which are conditionally mandatory. The conditions under which an >annex is mandatory will be stated within the annex itself, to make it >self-contained. > >Some annexes will constitute extensions of the protocol (e.g. event package >specifications) and must therefore be identifiable as such at the syntactic >level. Other annexes may be more like profiles, stating, for example, what >extensions must be supported by an MG or MGC which supports a given >application. An extension identifier for the complete profile is a >"nice-to-have", but would be used only as shorthand in Audit responses, not >in other commands. > >Looking to the future, extensions could be created: >-- by joint Megaco/ITU action, added as new annexes to H.GCP >-- by action of the ITU on its own, added as new annexes to H.GCP or as new >Recommendations. >-- by the IETF on its own, added as new RFCs >In all cases, I suggest that the extensions be registered with IANA in >accordance with procedures and criteria defined in the base protocol >document. > >I-7: As a general principle in deciding what each implementation must >support, MGs should be assumed to be more specialized than MGCs. For >example, we may decide (though I doubt it) that all MGCs must support all >applications documented in the initial Megaco/H.GCP specification, but MGs >may support an arbitrary subset of them. > >This is a debatable principle -- some vendors probably have a different view >of the architecture. I suspect it is the consensus view, however. > >I-8: If at all possible, MGs should hide the details of national and >regional variations in channel-associated signalling from the MGC. > >This is more debatable than I-7. I propose it as a principle on the grounds >that MGs are more likely to be serving customers in only one country or >region than are MGCs, so they will be the more logical point of >specialization. I have a concrete suggestion for our event packages which >may help to support this principle: event descriptor syntax should include >both the abstract event names and specialization identifiers which indicate, >for instance, that the MG should provide busy tone for Country A rather than >Country B to this particular termination. That way the MGC can pass down >information it has received from signalling, while the physical details are >known only to the MG. > > > > > > >Tom Taylor >Advisor -- IPConnect Standards >E-mail: taylor(a)nortelnetworks.com (internally, Tom-PT Taylor) >Phone and FAX: +1 613 736 0961 >

1 0

Notice of the Berlin meeting
by Sakae OKUBO 25 Jun '99

25 Jun '99

To Experts of ITU-T SG16 Q.12/16, Q.13/16 and Q.14/16 Cc Mr. P-A. Probst, Chairman of SG16 Mr. G. Helder, Vice-Chairman of SG16 Mr. F. Tosco, Chairman of WP2/16 Mr. F. Bigi, ITU-TSB Mr. T. Geary, Rapporteur for Q.11/16 Mr. G. Sullivan, Rapporteur for Q.15/16 Mr. J. Ott, Teles Mr. S. Wenger, Teles De Sakae OKUBO Rapporteur for Q.12/16 in ITU-T SG16 TAO Waseda Research Center 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 Dale SKRAN Rapporteur for Q.13/16 in ITU-T SG16 Ascend Communications, Inc. 621 Shrewsbury Avenue Shrewsbury, NJ 07702 USA Tel: +1 908 450 1635 Fax: +1 908 450 1611 E-mail: Dale.Skran(a)ascend.com Glen Freundlich Rapporteur for Q.14/16 in ITU-T SG16 Lucent Technologies 11900 N. Pecos Westminster, Colorado 80234 USA Tel: +1 303 538 2899 Fax: +1 303 538 3907 E-mail: ggf(a)lucent.com ---------------------------------------------------------- Subject: Notice of Q.12-14/16 Rapporteur Meeting in Berlin Date: 25 June 1999 ---------------------------------------------------------- Dear Q.12-14/16 experts, The subject meeting of ITU-T SG16 experts will be held in Berlin, Germany at the kind invitation of TELES AG. Please note that Q.11/16 and Q.15/16 will meet concurrently at the same place and have joint sessions with Q.12-14/16. 1. Date ^^^^^^^ 2 (Monday) - 6 (Friday) August 1999 starting at 9:00 on the first day 2. Venue ^^^^^^^^ GRAND HOTEL ESPLANADE BERLIN Luetzowufer 15 10785 Berlin-Tiergarten Voice: +49 30 254 78-0 Fax: +49 30 265 1171 EMail: info(a)esplanade.de WWW: http://www.esplanade.de/eframe.htm 3. Topics (tentative) ^^^^^^^^^^^^^^^^^^^^^ 1) Review of the relevant group meetings 2) Q.12/16 B-ISDN multimedia systems and terminals - White contribution for H.222.0 Amendment 7 - H.321 v2 Implementers Guide - H.310 v2 Implementers Guide - Work with Q.13 on high quality video transmission over IP - Future AV communication systems 3) Q.13/16 Packet switched multimedia systems and terminals - Finalize white contributions for: * H.323 V3 * H.225.0 V3 * H.450.8 (Name Identification) * H.323 Annex G (Text SET) - Update H.323 Implementers guide - Further Develop: * H.323 Annex F (Secure SET) * H.323 Annex H (User/Service Mobility) * H.323 Annex I (Terminal Mobility) * H.450.9 (Call Completion on Busy) - Work with Q.14 on H.GCP white paper - Work with Q.14 on H.246 Annex C white paper - Work with Q.14 on H.246 Annex D 4) Q.14/16 Common protocols, MCUs and protocols for interworking with H.300-series terminals - Finalize white contributions for: * Prepare H.gcp * Prepare H.246 Annex C * Prepare H.245 V6 * Prepare H.243 V2 * Prepare H.224 V2 - Progress work on IN-H.323 interface (H.246 Annex D) - Update implementers guide 5) Coordination with Q.11/16 and Q.15/16 - System aspects - Video coding aspects 6) Interaction with other groups 7) Future work plan 4. Documents ^^^^^^^^^^^^ /// Registration of the document: by 23 July (Friday) /// /// Distribution of the document: by 26 July (Monday) /// /// Use the ftp site (or e-mail reflector) for distribution /// 1) When you are going to submit a document, please notify S. Okubo as soon as possible, by 23 July (Friday) at the latest. Document number (APC-1nnn) will be allocated. Early indication of your submission plan is welcome and encouraged. Note - Prefix "APC" comes from Atm (Q.12/16), Packet based (Q.13/16) and Common protocols (Q.14/16) based on the coordination with Q.1 ("Q1City"), Q.3 ("T120"), Q.11 ("Q11"), Q.15 ("Q15") groups. 2) You are advised to include a header as follows: ------------------------------------------------------------------ | | | ITU Telecommunication Standardization Sector Document APC-{1nnn}| | Study Group 16 {Version m if relevant}| | Q.12-14/16 Rapporteur Meeting {Date}| | Berlin, 2-6 August 1999 | | | | SOURCE*: { } | | TITLE : { } | | PURPOSE: {Proposal, Discussion, Information, Report, etc.} | | | | _________________________ | | | | | | | | *Contact: Name, e-mail | ------------------------------------------------------------------ 3) All the contributors are requested to distribute their documents as early as possible, at least 7 calendar days in advance of the meeting (26 July or before) by posting them at either of the following: - PictureTel ftp site (please advise S. Okubo of your posting) Site: standard.pictel.com/avc-site Login name: anonymous Directory: Incoming - Q.12-14/16 experts reflector e-mail address: itu-sg16(a)mailbag.jf.intel.com Please avoid the use of reflector when your document is voluminous. 4) Input documents can be retrieved from /9908_Ber directory of the ftp site. 5) Please bring 80 copies of your document to Berlin if it should be in hardcopy. Your cooperation is needed to start the meeting with all the documents at hand; please note that the copying capacity at the meeting site is very limited and expensive. 6) The document distribution / presentation at the meeting will be electronic (i.e. participants must bring their laptops along). 5. Logistic information ^^^^^^^^^^^^^^^^^^^^^^^ Please see the invitation distributed by the meeting host (http://standard.pictel.com/ftp/avc-site/9908_Ber/Invitation.txt). 6. Registration ^^^^^^^^^^^^^^^ To confirm your meeting attendance, please reply directly to TELES using the registration form distributed by the host (http://standard.pictel.com/ftp/avc-site/9908_Ber/registration-form.doc) up to and including 1 July for early regsitration with a meeting fee of DEM 500,00. Please note that after this date, the registration fee becomes DEM 650,00. In addition, please send a separate e-mail registration to Mr. Ott and copy the Rapporteurs on this e-mail. Please use the subject and message body format shown below. To: jo(a)teles.de Cc: okubo(a)giti.or.jp, dskran(a)ascend.com, ggf(a)lucent.com, tom.geary(a)conexant.com, garysull(a)microsoft.com Subject: Berlin meeting registration NAME: COMPANY: EMAIL: ARRIVAL: DEPARTURE: Please attach a *small* photograph of yourself as GIF or JPG format and send this to jo(a)teles.de attached to the registration mail. 7. Hotel Room Reservation ^^^^^^^^^^^^^^^^^^^^^^^^^ Please directly contact GRAND HOTEL ESPLANADE BERLIN mentioning "ITU- Meeting" to obtain the special rate; DEM 280,00 -- approximately USD 150 -- per night including a breakfast buffet for a single/double room. You need to guarantee the room reservation with your credit card. CUTOFF DATE for the special room rate is Thursday, 1 July 1999. We are looking forward to meeting with you in Berlin. Sincerely yours, Sakae OKUBO Dale SKRAN Gary THOM ----------

1 0

Interoperability and Extensibility
by Tom-PT Taylor 24 Jun '99

24 Jun '99

We face a continuing tension between the requirement to ensure interoperability and the desirability of minimizing the size of the core protocol, particularly at the MG. We also have to make sure our protocol has well-defined procedures for adding both ad hoc (i.e. proprietary or experimental) and formal extensions. This note suggests some principles which we should follow in response to these considerations. There are really two levels of interoperability to deal with: syntactic (can the message be parsed?) and semantic (can the message recipient perform the actions which the sender is requesting?). At the syntactic level, I believe that we can agree on these principles: I-1: Every message must be fully parsable down to a certain level of detail, even if it contains extensions unsupported by the recipient. I-2: Our protocol document must specify the syntax by means of which extensions are identified. I-3: The protocol must provide the means for the recipient to identify in its response to any message all unsupported extensions it encountered in that message. There is an open issue here: what is the minimal parsability level we want to specify? Suggestion: all messages are parsable down to the command and parameter level at a minimum. Here I use the term "parameter" to imply either a simple data value or a potentially complex data structure identified as a syntactic element in our API definitions. The implication of this suggestion is that extensions can add no new commands, no new command parameters, only new possible values for command parameters and new event packages. I'm sure others will have comments on this. Now we get to the interesting part: semantic interoperability. I'll start with what I hope are a couple of obvious statements. I-4: Not all implementations will support all event packages, all possible parameter values, or whatever else we allow to be extended. I-5: The protocol definition must include a specification of what the receiver does if a message contains an unsupported extension. On this latter point, do we enforce the transaction concept at all levels and fail the transaction, requiring the sender to reissue the command without the offending value? This is definitely a workable solution. We could go further and introduce the ability to say in a message whether a given field is a transaction-stopper, but I'm not sure that capability would be used in practice -- it wasn't when we had it in IPDC. Now for the crucial question: if I-4 is true, what criteria do we use to say what features MUST be supported by any given implementation? Can we distinguish between required support in MGC implementations, versus required support in MG implementations? How does each side of the Megaco interface determine what the other side supports, other than by parsing transaction rejections? Here are some propositions to use as a basis for discussion: I-6: The Megaco/H.GCP specification should be organized into a basic protocol specification which must be satisfied by all implementations, plus annexes which are conditionally mandatory. The conditions under which an annex is mandatory will be stated within the annex itself, to make it self-contained. Some annexes will constitute extensions of the protocol (e.g. event package specifications) and must therefore be identifiable as such at the syntactic level. Other annexes may be more like profiles, stating, for example, what extensions must be supported by an MG or MGC which supports a given application. An extension identifier for the complete profile is a "nice-to-have", but would be used only as shorthand in Audit responses, not in other commands. Looking to the future, extensions could be created: -- by joint Megaco/ITU action, added as new annexes to H.GCP -- by action of the ITU on its own, added as new annexes to H.GCP or as new Recommendations. -- by the IETF on its own, added as new RFCs In all cases, I suggest that the extensions be registered with IANA in accordance with procedures and criteria defined in the base protocol document. I-7: As a general principle in deciding what each implementation must support, MGs should be assumed to be more specialized than MGCs. For example, we may decide (though I doubt it) that all MGCs must support all applications documented in the initial Megaco/H.GCP specification, but MGs may support an arbitrary subset of them. This is a debatable principle -- some vendors probably have a different view of the architecture. I suspect it is the consensus view, however. I-8: If at all possible, MGs should hide the details of national and regional variations in channel-associated signalling from the MGC. This is more debatable than I-7. I propose it as a principle on the grounds that MGs are more likely to be serving customers in only one country or region than are MGCs, so they will be the more logical point of specialization. I have a concrete suggestion for our event packages which may help to support this principle: event descriptor syntax should include both the abstract event names and specialization identifiers which indicate, for instance, that the MG should provide busy tone for Country A rather than Country B to this particular termination. That way the MGC can pass down information it has received from signalling, while the physical details are known only to the MG. Tom Taylor Advisor -- IPConnect Standards E-mail: taylor(a)nortelnetworks.com (internally, Tom-PT Taylor) Phone and FAX: +1 613 736 0961

1 0

Proposed text for text telephone requirements in megaco
by Gunnar Hellstrom 24 Jun '99

24 Jun '99

Suggested Modifications to draft-ietf-megaco-reqs-03.txt For text telephone support. Issued by Gunnar Hellström L M Ericsson Gunnar.hellstrom(a)omnitor.se The following additions to the megaco requirements spec are intended to cover the needs from text telephony, and its gatewaying to IP text conversation. They are now concentrated in the Application-specific requirements section. Since many of the requirements could as well have been specified under Termination Class Requirements for an Analogue Gateway, section 11.1.5, I want to leave it to the authors of the main document to insert the information where it is appropriate. <<<<<<In 11.2.4, add information about a text telephone capable gateway >>>> 11.2.4. Trunking/Access Gateway with text telephone access ports An access gateway with ports capable of text telephone communication, shall provide communication between text telephones in the SCN and text conversation channels in the packet network. Text telephone capability of ports is assumed to be possible to combine with other options for calls as described in the section on "Adaptable NASes". The port is assumed to adjust for the differences in the supported text telephone protocols, so that the text media stream can be communicated T.140 coded in the packet network without further transcoding. The protocol must be capable of reporting the type of text telephone that is connected to the SCN port. The foreseen types are the same as the ones supported by ITU-T V.18: DTMF, EDT, Baudot-45, Baudot-50, Bell, V.21, Minitel and V.18. It should be possible to control which protocols are supported. The SCN port is assumed to contain ITU-T V.18 functionality. The protocol must be able to control the following functionality levels of text telephone support: a. Simple text-only support: The call is set into text mode from the beginning of the call, in order to conduct a text-only conversation. b. Alternating text-voice support: The call may begin in voice mode or text mode and, at any moment during the call, change mode on request by the SCN user. On the packet side, the two media streams for voice and text must be opened, and it must be possible to control the feeding of each stream by the protocol. c. Simultaneous text and voice support: The call is performed in a mode when simultaneous text and voice streams are supported. The call may start in voice mode and during the call change state to a text-and-voice call. A port may implement only level a, or any level combination including level a. The protocol must support: a. A text based alternative to the IVR functionality of the gateway when the port is used in text telephone mode. b. Selection of what national translation table to be used between the Unicode based T.140 and the 5-7 bit based text telephone protocols. c. Control of the V.18 probe message to be used on incoming calls. <<<< End of 11.2.4 addition >>>>>>> <<< IN 11.2.6 e, add ",text telephone" after "fax" to read like this: >> e. Adaptable NASes: The protocol must be able to support multiple options for an incoming call to allow the NAS to dynamically select the proper type of call. For example, an incoming ISDN call coded for "Speech" Bearer Capability could actually be a voice, modem, fax, text telephone or 56 kbit/s synchronous call. The protocol should allow the NAS to report back to the MGC the actual type of call once it is detected. <<<< end of change for 11.2.6 >>>>> Regards Gunnar Hellström ------------------------------------- Gunnar Hellström Ericsson Home Systems Tel +46 751 100 501 Fax +46 8 556 002 06 e-mail gunnar.hellstrom(a)omnitor.se Video +46 8 556 002 05 -------------------------------------

1 0

Re: Question about text in implementers guide
by Dave Walker 23 Jun '99

23 Jun '99

I don't believe there was any APC. I introduced some ideas and proposed text on the mailing list. The text was revised in response to ensuing discussion and Jim inserted it into the IG draft. I agree it seems contradictory. The way it was written had changed "shall be the first message sent" to "should be the first message sent". The intention was that you wouldn't have to send TCS, but if the peer got totally confused about what was going on without it, the exchange would take place. I believe that the Monterey meeting rejected my "shall" to "should" change but accepted everything else. I unfortunately wasn't present while this item was discussed. However, notice that in the last sentence of the paragraph, the EP "shall" respond to the TCS, and only "should" complete a caps exchange before doing anything else. So the EP can still do things essentially in parallel. As an aside, my belief is that other H.245 procedures besides MSD may be initiated prior to completion of caps exchange, for example, OLC. Regards, Dave Walker Mitel Corporation Ontario, CANADA Chris Purvis wrote: > > Paul, > > No. I think it comes out of things Dave was talking about. Do you recall, > Dave? > > By the way, you guys may as well be the first to know (I'll email the lists > at some point): I'll moving on from Madge in two and a half weeks time, and > although I'll still be in the telecoms industry I don't expect to be active > in the H.323 arena, at least for a while. > > Chris > > > -----Original Message----- > > From: Paul E. Jones [mailto:paul.jones@ties.itu.int] > > Sent: 23 June 1999 2:03 > > To: Chris.Purvis(a)MADGE.COM; pete(a)TECH-KNOW-WARE.COM > > Subject: Re: Re: Question about text in implementers guide > > > > > > Chris, > > > > Do you recall what APC introduced the text? > > > > Paul > > > > ----- Original Message ----- > > From: Chris Purvis <Chris.Purvis(a)MADGE.COM> > > To: <ITU-SG16(a)MAILBAG.INTEL.COM> > > Sent: Wednesday, June 23, 1999 7:00 AM > > Subject: Re: Question about text in implementers guide > > > > > > > Pete, > > > > > > The background is that there should be no good reason for > > not tunnelling > > TCS > > > and MSDet into the same H.225 message. I agree that the > > wording ought to > > be > > > improved (I heard or suggested at Monterey two or three > > alternatives that > > I > > > consider better than the one you quote). > > > > > > Regards, > > > Chris > > > > > > > > > > -----Original Message----- > > > > From: Pete Cordell [mailto:pete@TECH-KNOW-WARE.COM] > > > > Sent: 22 June 1999 9:54 > > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > > Subject: Question about text in implementers guide > > > > > > > > > > > > Dear All, > > > > > > > > The following revised paragraph seems to have been added to > > > > H.323 v3 via the > > > > implementers guide. > > > > > > > > Endpoint system capabilities are exchanged by transmission of > > > > the H.245 > > > > terminalCapabilitySet message. This capability message shall > > > > be the first > > > > H.245 message sent. If prior to successful completion of > > > > terminal capability > > > > exchange, any other procedure fails, (i.e. rejected, not > > > > understood, not > > > > supported) then the initiating endpoint should initiate and > > > > successfully > > > > complete terminal capability exchange before attempting any > > > > other procedure. > > > > An endpoint which receives a terminalCapabilitySet message > > > > from a peer prior > > > > to initiating capabilities exchange shall respond as > > > > required by 6.2.8.1, > > > > and should initiate and successfully complete capabilities > > > > exchange with > > > > that peer prior to initiating any other procedure. > > > > > > > > I'm a bit confused about what it is saying. It seems to be > > > > saying that an > > > > endpoint can send a TCS and prior to receiving the Ack, send > > > > MSD (as there > > > > is really no other procedure that can fail). This is a > > good thing. > > > > However, it then says, that if for some reason you receive > > > > TCS before you > > > > yourself have sent one, then, I think the paragraph is saying > > > > that, you must > > > > send your own TCS, and are not allowed to do MSD until you > > > > get the TCS Ack > > > > back. This is a bad thing. But worse still there seems to > > > > be conflicting > > > > information for what is essentially a minor timing issue. > > > > Could someone > > > > kindly explain to me what the background to it is. > > > > > > > > Thanks, > > > > > > > > Pete > > > > > > > > ============================================= > > > > Pete Cordell > > > > pete(a)tech-know-ware.com > > > > ============================================= > > > > > > >

1 0

Re: Question about text in implementers guide
by Chris Purvis 23 Jun '99

23 Jun '99

Pete, The background is that there should be no good reason for not tunnelling TCS and MSDet into the same H.225 message. I agree that the wording ought to be improved (I heard or suggested at Monterey two or three alternatives that I consider better than the one you quote). Regards, Chris > -----Original Message----- > From: Pete Cordell [mailto:pete@TECH-KNOW-WARE.COM] > Sent: 22 June 1999 9:54 > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Question about text in implementers guide > > > Dear All, > > The following revised paragraph seems to have been added to > H.323 v3 via the > implementers guide. > > Endpoint system capabilities are exchanged by transmission of > the H.245 > terminalCapabilitySet message. This capability message shall > be the first > H.245 message sent. If prior to successful completion of > terminal capability > exchange, any other procedure fails, (i.e. rejected, not > understood, not > supported) then the initiating endpoint should initiate and > successfully > complete terminal capability exchange before attempting any > other procedure. > An endpoint which receives a terminalCapabilitySet message > from a peer prior > to initiating capabilities exchange shall respond as > required by 6.2.8.1, > and should initiate and successfully complete capabilities > exchange with > that peer prior to initiating any other procedure. > > I'm a bit confused about what it is saying. It seems to be > saying that an > endpoint can send a TCS and prior to receiving the Ack, send > MSD (as there > is really no other procedure that can fail). This is a good thing. > However, it then says, that if for some reason you receive > TCS before you > yourself have sent one, then, I think the paragraph is saying > that, you must > send your own TCS, and are not allowed to do MSD until you > get the TCS Ack > back. This is a bad thing. But worse still there seems to > be conflicting > information for what is essentially a minor timing issue. > Could someone > kindly explain to me what the background to it is. > > Thanks, > > Pete > > ============================================= > Pete Cordell > pete(a)tech-know-ware.com > ============================================= >

1 0

Question about text in implementers guide
by Pete Cordell 22 Jun '99

22 Jun '99

Dear All, The following revised paragraph seems to have been added to H.323 v3 via the implementers guide. Endpoint system capabilities are exchanged by transmission of the H.245 terminalCapabilitySet message. This capability message shall be the first H.245 message sent. If prior to successful completion of terminal capability exchange, any other procedure fails, (i.e. rejected, not understood, not supported) then the initiating endpoint should initiate and successfully complete terminal capability exchange before attempting any other procedure. An endpoint which receives a terminalCapabilitySet message from a peer prior to initiating capabilities exchange shall respond as required by 6.2.8.1, and should initiate and successfully complete capabilities exchange with that peer prior to initiating any other procedure. I'm a bit confused about what it is saying. It seems to be saying that an endpoint can send a TCS and prior to receiving the Ack, send MSD (as there is really no other procedure that can fail). This is a good thing. However, it then says, that if for some reason you receive TCS before you yourself have sent one, then, I think the paragraph is saying that, you must send your own TCS, and are not allowed to do MSD until you get the TCS Ack back. This is a bad thing. But worse still there seems to be conflicting information for what is essentially a minor timing issue. Could someone kindly explain to me what the background to it is. Thanks, Pete ============================================= Pete Cordell pete(a)tech-know-ware.com =============================================

1 0