- sg16-avd - lists.packetizer.com

MGCP reference (was Re: Megaco/H.gcp conference call)
by Chip Sharp 29 Jun '99

29 Jun '99

Once or twice is a mistake. When the mistake is continually repeated I wonder... Cisco is NOT an author of MGCP. Referring to MGCP as "Telcordia/Cisco MGCP" denigrates the hard work of the many people that actually did author the draft as well as the many people and companies that contributed. Maybe it isn't convenient to call it Telcordia/Level 3/RSL COM/Vertical/ MGCP? Chip At 06:44 PM 6/16/99 -0400, Nancy-M Greene wrote: ...snip... >mechanism. We need to choose one. There are two proposals on the table: >1) the UDP + timers method in the Telcordia/Cisco MGCP - >draft-huitema-megaco-mgcp-v0r1-05.txt, and ...snip... -------------------------------------------------- Chip Sharp voice: +1 (919) 851-2085 Cisco Systems Consulting Eng. - Telco Reality - Love it or Leave it. --------------------------------------------------

1 0

Re: H.323v3 for decision in September
by Francois Audet 29 Jun '99

29 Jun '99

I'd support this as well: some additional text regarding backward compatibility (use of GIT instead of B-HLI) is required. Along the lines of what was done for H.310 which went throught the same change. François Audet > Hi everyone, > > One of the proposals we are planning to bring to the Berlin > meeting is for > modifications to Annex C. If the additional text is approved > in Berlin will it > be possible to add it to H.323 V3? This is quite important > text since it deals > with backward compatibility of Annex C in H.323 V3 and H.323 V2. > > Regards, > Kaynam Hedayat

1 0

Re: H.323v3 for decision in September
by Kaynam Hedayat 29 Jun '99

29 Jun '99

Hi everyone, One of the proposals we are planning to bring to the Berlin meeting is for modifications to Annex C. If the additional text is approved in Berlin will it be possible to add it to H.323 V3? This is quite important text since it deals with backward compatibility of Annex C in H.323 V3 and H.323 V2. Regards, Kaynam Hedayat "Paul E. Jones" <paul.jones(a)TIES.ITU.INT> on 06/28/99 08:20:51 PM Please respond 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 cc: (bcc: Kaynam Hedayat/PicTel) Subject: H.323v3 for decision in September Folks, We may attempt to decide H.323v3 in September and determine version 4 in February. Mr. Skran has asked that I post the current draft so that people can review the document. This document must be delivered to the ITU by 30 June 1999. (Please note that Annex C/H.323 is also a candidate for decision in Septemer.) This document contains only minor editorial changes to the document that was determined in Santiago. Nonetheless, I encourage you to review the document for any errors or omissions. The change marks indicate all changes that have been made since version 2. Please direct any comments on the document to me. The document can be found here: ftp://standards.pictel.com/avc-site/Incoming/H.323v3-990628.doc Best Regards, Paul E. Jones DataBeam Corporation

2 1

Re: H.323v3 for decision in September
by Pete Cordell 29 Jun '99

29 Jun '99

One issue I was discussing with my BT colleagues was installing an open framework for extensibility and feature negotiation into H.323v3. The motivation for this was to enable transport of SS7, but also other protocols such as DPNSS, (is CAS a digital one?) and so on. If we were to go ahead I guess we would have presented something in Berlin. Given that September is fast approaching waiting for such a scheme to transport things like SS7 does not seem too onerous. Unfortunately my colleagues are out this week, but I will attach the latest text so that people can have early sight of it. Regards, Pete ============================================= Pete Cordell pete(a)tech-know-ware.com ============================================= -----Original Message----- From: Paul E. Jones <paul.jones(a)TIES.ITU.INT> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> Date: 29 June 1999 01:25 Subject: H.323v3 for decision in September >Folks, > >We may attempt to decide H.323v3 in September and determine version 4 in >February. Mr. Skran has asked that I post the current draft so that people >can review the document. This document must be delivered to the ITU by 30 >June 1999. (Please note that Annex C/H.323 is also a candidate for decision >in Septemer.) > >This document contains only minor editorial changes to the document that was >determined in Santiago. Nonetheless, I encourage you to review the document >for any errors or omissions. > >The change marks indicate all changes that have been made since version 2. > >Please direct any comments on the document to me. > >The document can be found here: > >ftp://standards.pictel.com/avc-site/Incoming/H.323v3-990628.doc > >Best Regards, >Paul E. Jones >DataBeam Corporation >

2 1

Re: H.323v3 for decision in September
by Chris Purvis 29 Jun '99

29 Jun '99

Roni, The reason for the addition of this text to H.323v3 was the death of what was formerly known as H.450.8 (SS-CoC, Conference out of Consultation), which I will refer to hereafter as H.450.CoC for convenience. H.450.CoC described an alternative method for setting up conferences out of consultation which, if decided, would have left us with alternative, incompatible methods of achieving the same feature. I wrote documents on the subject for the Monterey meeting (one APC, one TD, if I remember rightly), and a revised version for Santiago, explaining how the behaviour required by H.450.CoC could be achieved without it. It was felt that setting out the procedure in a standard was a useful thing to do, but that H.450.CoC was unnecessarily heavyweight. The natural conclusion of that was to write up the procedures allowed by earlier versions of the standard explicitly in H.323v3. Hence: 1. It IS a minor change, because it doesn't actually change anything (beyond the addition of a single releaseCompleteReason) - it merely sets out how protocol already in existence can be used to achieve a particular aim. 2. Although the text was not agreed in Monterey as part of H.323v3, its basis was discussed at other points in the Monterey meeting as well as at Santiago. 3. It must have some use in the standard, to clear up misconceptions. The writers of H.450.CoC (who are extremely familiar with the H.323 family of standards) obviously felt H.450.CoC was necessary (or they wouldn't have put in the significant effort of writing it!) - whereas you're saying that the text being added was already part of the protocol (with which I agree). I find it hard to see your argument as self-consistent incidentally - if, as you say, the added text is "just a procedure that is already part of the previous text" (with which I agree), then surely as such it constitutes a minor change!? Regards, Chris -- Dr Chris Purvis - Senior Development Engineer, WAVE CC Software Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. ENGLAND Phone: +44 1753 661 359 email: cpurvis(a)madge.com > -----Original Message----- > From: Roni Even [mailto:Roni_e@ACCORD.CO.IL] > Sent: 29 June 1999 8:24 > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323v3 for decision in September > > > Hi, > As far as I see in the Santiago meeting summary the decision was to > decide H.323V3 in 2/00. Where will we decide on 9.99 I did not see any > meeting scheduled. A lot of text was added during the Santiago meeting > about Conference out of Consultation which I see as just a procedure > that already is part of the previous text and I cannot see why it was > added at the first place. I intend to submit an APC about this for the > Berlin meeting. I think that adding two pages of text to the document > that was agreed in Monterey is not a minor change. > > ********************************************** > Roni Even > VP Product Marketing > Accord Video Telecommunication > Email: roni_e(a)accord.co.il > Tel: +972-3-9251412 > Fax: +972-3-9211571 > *************************************************** > > > -----Original Message----- > > From: Paul E. Jones [SMTP:paul.jones@TIES.ITU.INT] > > Sent: Tuesday, June 29, 1999 2:21 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: H.323v3 for decision in September > > > > Folks, > > > > We may attempt to decide H.323v3 in September and determine > version 4 > > in > > February. Mr. Skran has asked that I post the current draft so that > > people > > can review the document. This document must be delivered to the ITU > > by 30 > > June 1999. (Please note that Annex C/H.323 is also a candidate for > > decision > > in Septemer.) > > > > This document contains only minor editorial changes to the document > > that was > > determined in Santiago. Nonetheless, I encourage you to review the > > document > > for any errors or omissions. > > > > The change marks indicate all changes that have been made since > > version 2. > > > > Please direct any comments on the document to me. > > > > The document can be found here: > > > > ftp://standards.pictel.com/avc-site/Incoming/H.323v3-990628.doc > > > > Best Regards, > > Paul E. Jones > > DataBeam Corporation >

1 0

Re: H.323v3 for decision in September
by Roni Even 29 Jun '99

29 Jun '99

Hi, As far as I see in the Santiago meeting summary the decision was to decide H.323V3 in 2/00. Where will we decide on 9.99 I did not see any meeting scheduled. A lot of text was added during the Santiago meeting about Conference out of Consultation which I see as just a procedure that already is part of the previous text and I cannot see why it was added at the first place. I intend to submit an APC about this for the Berlin meeting. I think that adding two pages of text to the document that was agreed in Monterey is not a minor change. ********************************************** Roni Even VP Product Marketing Accord Video Telecommunication Email: roni_e(a)accord.co.il Tel: +972-3-9251412 Fax: +972-3-9211571 *************************************************** > -----Original Message----- > From: Paul E. Jones [SMTP:paul.jones@TIES.ITU.INT] > Sent: Tuesday, June 29, 1999 2:21 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: H.323v3 for decision in September > > Folks, > > We may attempt to decide H.323v3 in September and determine version 4 > in > February. Mr. Skran has asked that I post the current draft so that > people > can review the document. This document must be delivered to the ITU > by 30 > June 1999. (Please note that Annex C/H.323 is also a candidate for > decision > in Septemer.) > > This document contains only minor editorial changes to the document > that was > determined in Santiago. Nonetheless, I encourage you to review the > document > for any errors or omissions. > > The change marks indicate all changes that have been made since > version 2. > > Please direct any comments on the document to me. > > The document can be found here: > > ftp://standards.pictel.com/avc-site/Incoming/H.323v3-990628.doc > > Best Regards, > Paul E. Jones > DataBeam Corporation

1 0

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