- sg16-avd - lists.packetizer.com

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

30 Jun '99

At 09:53 AM 6/30/99 -0400, Tom-PT Taylor wrote: >Here's a brief history, from my point of view -- others are free to add >their viewpoints. > ...snip... > >May 1998: formal Megaco/H.GCP cooperative arrangement announced. ...snip... I believe the arrangement announced in Santiago has not actually been formalized or confirmed. At least that was the impression I got from Scott's mail. Of course, just because there is no formal arrangement doesn't mean megaco and Q.14 aren't working toward common protocol. Since you brought it up though, :-), what is the status of the arrangement? Chip -------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems Telco Bio-region Reality - Love it or Leave it. --------------------------------------------------

1 0

Re: PDU & ASN parser
by Paul Long 30 Jun '99

30 Jun '99

Guntram, I raised this issue over a year ago. In addition, H.225.0 does not address this issue regarding RAS (it does regarding call signaling), so I suppose one could pack multiple RAS messages per unreliable-transport PDU. As you say, it doesn't make sense to pack messages, and I don't think anyone does it. We should probably add something like the following to section 6.1 of the next revision of H.225.0. "When messages are sent on the H.225.0 RAS channel, only one whole message shall be sent within the boundaries defined by the transport; there shall be no fragmentation of H.225.0 RAS messages across transport PDUs." We should also insert the indicated text, below, into existing text in the same section. "When messages are sent on the reliable H.245 control channel, >>>exactly one message should be sent but<<< more than one message may be sent within the boundaries defined by the reliable transport PDU as long as whole messages are sent;" Paul Long Smith Micro Software, Inc. -----Original Message----- From: Guntram Diehl [SMTP:gdiehl@innovaphone.com] Sent: Wednesday, June 30, 1999 4:14 AM To: 'Bancroft Scott'; 'Srikanth Nayani' Cc: 'h323implementors(a)imtc.org' Subject: RE: PDU & ASN parser Yes this can be done, but does any implementation actually do it? Why would anyone want to do this, it just saves 4 bytes tpkt header per additional H.245 message and it does not change the fragmentation of the whole thing by IP. Or is there another reason why this was specified in the standard this way? Guntram -----Original Message----- From: Bancroft Scott [mailto:baos@OSS.COM] Sent: Wednesday, June 30, 1999 3:54 AM To: Srikanth Nayani Cc: h323implementors(a)imtc.org Subject: Re: PDU & ASN parser On Tue, 29 Jun 1999, Srikanth Nayani wrote: > In the H.225 document chapter 6 mentions that multiple messages can be > sent over the reliable H.245 control channel within the boundaries of the > reliable transport channel . Does that mean that two H.245 PDUs encoded > using PER and whose total encoded length is within the boundary of the > H.245 TCP channel can be merely concatenated and sent as a single payload > of the H.245 TCP channel. > If so how does a ASN.1 decoder know that there are two messages in the > payload and the offset at which the second message starts. An PER decoder does not know that there are two messages in the payload. It does know where the first message ends, so the location of the next message can be derived from this knowledge. ------------------------------------------------------------------------ -- Bancroft Scott Toll Free :1-888-OSS-ASN1 Open Systems Solutions, Inc. International:1-609-987-9073 baos(a)oss.com Tech Support :1-732-249-5107 http://www.oss.com Fax :1-732-249-4636 ------------------------------------------------------------------------ - for list subscription instructions, send email to h323implementors-request(a)imtc.org with text "info" ------------------------------------------------------------------------- for list subscription instructions, send email to h323implementors-request(a)imtc.org with text "info"

2 1

Re: MGCP reference (was Re: Megaco/H.gcp conference call)
by Tom-PT Taylor 30 Jun '99

30 Jun '99

Here's a brief history, from my point of view -- others are free to add their viewpoints. April 1998: Bellcore announces SGCP (Simple Gateway Control Protocol). They have been prototyping for several months. Hong Liu was one of the participants. I have the impression that many of the ideas came from Christian Huitema, including the use of SDP, the separation into local and remote descriptors which are effectively negotiated between MGs, and the use of application-level framing instead of a reliable transport layer. SGCP meets with a hostile reception in SG 16 and TIPHON because of its centralizing architecture, which differs subtly from that of H.323. May 1998: A cluster of activity around the issue of control of VoIP gateways where SS7 is terminated on separate signalling gateways (to conserve point codes). Nortel is proposing the use of an extension of DIAMETER, a protocol under development at the IETF, to do device control. Ascend and Bay have extensions to Q.931 for the purpose, which they eventually rationalize into a single protocol proposal. May 1998: Level 3 announces the formation of a multi-company Technical Advisory Committee to work on an IP Device Control protocol (IPDC). The TAC is presented with a 100-page specification previously developed by Ascend and XCOM as their starting point. Other companies have in-house protocols, and SGCP is also considered, but the TAC ends up using a modified IPDC over a DIAMETER base. IPDC includes the important concepts of event packages and scripts. June 1998: The TAC presents their list of requirements to the H.323 Rapporteurs' meeting in Cannes. Intel presents an abstract proposal for H.323 gateway decomposition. Bellcore presents SGCP. Work on gateway decomposition does get started, despite initial hostility and suspicion. A TIPHON meeting around this time at least became familiar with the topic. August 1998: the Level 3 TAC concludes its work and presents a first draft of IPDC to the IETF and SG 16. All the discussion of SS7 gateways and remote control of VoIP gateways culminates in a Birds of Feather (BOF) session at the IETF. Out of that eventually comes the decision to form two working groups: SIGTRAN (transport of SCN signalling over IP) and MEGACO (Media Gateway Control). That decision doesn't come until December, but in the meantime there is active discussion of issues on the IETF lists. TIPHON adds gateway decomposition to its architecture, but is having trouble getting a firm view of that architecture. September 1998: SG 16 considers gateway decomposition and commits itself to working on the topic. Terms of reference are drawn up, along with a reworking of architectural views initially drawn up in June. Bellcore and Level 3 announce a merger of SGCP and IPDC into MGCP. The latter is mostly SGCP with the addition of event packages and termination wildcarding syntax. November 1998: TIPHON architectural views are settling down. Lucent brings in MDCP (Media Device Control Protocol) as a hand-written draft to the SG 16 Rapporteurs' meeting in Torino. This is completely different from MGCP, particularly in its connection model. December 1998: first meeting of the Megaco working group at the IETF. A first draft of a requirements document comes out shortly thereafter. March 1998: a bitter debate over connection model at the Monterey Rapporteurs' meeting. In a procedure unusual for SG 16, the MDCP connection model is chosen via an indicative poll. April 1998: compromise reached at last on the connection model, at the IETF. The new model accommodates all of the additional requirements which have arisen beyond the original design premises of SGCP, and improves on both the SGCP/MGCP and MDCP models. May 1998: formal Megaco/H.GCP cooperative arrangement announced. > -----Original Message----- > From: Derks, Frank [SMTP:F.Derks@PBC.BE.PHILIPS.COM] > Sent: Wednesday, June 30, 1999 6:24 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: MGCP reference (was Re: Megaco/H.gcp conference call) > > HI Nancy, > > maybe it is a good idea to post the history of all these protocols and > their > relations (if any) to this list? > > Frank > > -----Original Message----- > From: Nancy-M Greene [mailto:ngreene@NORTELNETWORKS.COM] > Sent: 29 June 1999 21:34 > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: MGCP reference (was Re: Megaco/H.gcp conference call) > > > Chip, you are right, the name Telcordia/Level 3/RSL COM/Vertical MGCP is > not > convenient. Christian has already made the same comment you have. I said > in > reply to him, and to the list, that I did make an error in adding Cisco to > the qualifier for MGCP. Since then, I refer to the new Megaco protocol as > the Megaco protocol, or the Megaco/H.gcp protocol, and to MGCP as MGCP. > > Since a new version of MGCP has come out, version 1, > (draft-huitema-megaco-mgcp-v1-00.txt), this distinction is even more > necessary. It makes sense that megaco is part of the file name, because > there are parts of MGCP that still need to be turned into RFCs for > packages > for the Megaco/H.gcp protocol, but it means the new Megaco/H.gcp protocol > can never really be called MGCP - it is too confusing. It would be good at > some point to pull the packages out of MGCP to stand alone as a separate > document for Megaco. And perhaps the UDP + timers part of MGCP so that it > can stand beside TUDP, MDTP, and TCP as alternatives for Megaco transport. > > Nancy > -------------------------------------------------------------------------- > Nancy M. Greene > Internet & Service Provider Networks, Nortel Networks > T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com > > > ---------- > > From: Chip Sharp[SMTP:chsharp@cisco.com] > > Sent: Tuesday, June 29, 1999 2:53 PM > > To: Greene, Nancy-M [CAR:5N10:EXCH]; ITU-SG16(a)mailbag.cps.intel.com; > > megaco(a)standards.nortelnetworks.com > > Subject: MGCP reference (was Re: Megaco/H.gcp conference call) > > > > 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. > > -------------------------------------------------- > >

2 1

Extra Time For Megaco
by Tom-PT Taylor 30 Jun '99

30 Jun '99

We will use our Tueday morning slot for a syntax design team meeting. I suspect I should keep that down to around 20 people maximum, or we won't get anywhere. Send me an E-mail if you want to participate. The proposals on the table are: -- what I would call status quo: the SDP proposals carried over from MGCP See draft-ietf-megaco-protocol-01.txt, draft-huitema-megaco-discuss-sdp-01.txt -- the new proposals worked out by Messrs. Ott, Kimchi, Sijben, and Rosen. (I have been quite properly taken to task for not checking with them before implying that they had failed to come through. They have originated three I-Ds in all.) See draft-rosen-megaco-structures-and-encoding-00.txt, draft-kimchi-megaco-discuss-caps-00.txt, draft-ott-mmusic-cap-00.txt -- Pete Cordell's proposal for text-encoded ASN.1 See draft-cordell-messaging-00.txt -- the proposal by Messrs. Anquetil and Conte for ASN.1/OMG-IDL See draft-anquetil-megaco-asn1-idl-syntax-00.txt Tom Taylor Advisor -- IPConnect Standards E-mail: taylor(a)nortelnetworks.com (internally, Tom-PT Taylor) Phone and FAX: +1 613 736 0961

1 0

Re: MGCP reference (was Re: Megaco/H.gcp conference call)
by Derks, Frank 30 Jun '99

30 Jun '99

HI Nancy, maybe it is a good idea to post the history of all these protocols and their relations (if any) to this list? Frank -----Original Message----- From: Nancy-M Greene [mailto:ngreene@NORTELNETWORKS.COM] Sent: 29 June 1999 21:34 To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: MGCP reference (was Re: Megaco/H.gcp conference call) Chip, you are right, the name Telcordia/Level 3/RSL COM/Vertical MGCP is not convenient. Christian has already made the same comment you have. I said in reply to him, and to the list, that I did make an error in adding Cisco to the qualifier for MGCP. Since then, I refer to the new Megaco protocol as the Megaco protocol, or the Megaco/H.gcp protocol, and to MGCP as MGCP. Since a new version of MGCP has come out, version 1, (draft-huitema-megaco-mgcp-v1-00.txt), this distinction is even more necessary. It makes sense that megaco is part of the file name, because there are parts of MGCP that still need to be turned into RFCs for packages for the Megaco/H.gcp protocol, but it means the new Megaco/H.gcp protocol can never really be called MGCP - it is too confusing. It would be good at some point to pull the packages out of MGCP to stand alone as a separate document for Megaco. And perhaps the UDP + timers part of MGCP so that it can stand beside TUDP, MDTP, and TCP as alternatives for Megaco transport. Nancy -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com > ---------- > From: Chip Sharp[SMTP:chsharp@cisco.com] > Sent: Tuesday, June 29, 1999 2:53 PM > To: Greene, Nancy-M [CAR:5N10:EXCH]; ITU-SG16(a)mailbag.cps.intel.com; > megaco(a)standards.nortelnetworks.com > Subject: MGCP reference (was Re: Megaco/H.gcp conference call) > > 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

Reminders for the Berlin meeting
by Sakae OKUBO 30 Jun '99

30 Jun '99

Dear Q.12-14/16 experts, 1. The cut off date is Thursday, 1 July for both the early registration saving DEM 150 and the ESPLANDE hotel room reservation. See the following documents: http://standard.pictel.com/ftp/avc-site/9908_Ber/Notice_Berlin.txt http://standard.pictel.com/ftp/avc-site/9908_Ber/Invitation.txt http://standard.pictel.com/ftp/avc-site/9908_Ber/registration-form.doc They are the meeting notice, the invitation from the meeting host informing the logistics and the meeting registration form (not hotel reservation form). I have found that the hotel room can be reserved via the web page mentioning "ITU-Meeting". 2. Pleaser register your contributions as soon as possible. Without a sufficient number of contributions, the SG16 management would not justify holding a Rapporteur meeting. Please note that this time I am assisted by Ms. Noriko Hosokawa for assigning document numbers and managing the files at the ftp site. Please accept any confusion we might make. 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.gcp/megaco news
by Glen Freundlich 30 Jun '99

30 Jun '99

As we mentioned during the Santiago meeting, the IETF meeting is the week of July 11. During this meeting, there will be continued work on H.gcp/megaco as is the normal case at IETF meetings. However, there will be no special Q.14 rapporteur session. Nonetheless, it would be appropriate for folks interested in H.gcp to participate in the IETF megaco work, either in the meeting or over the megaco mail reflector. Regards, Glen -- Glen Freundlich ggf(a)lucent.com Lucent Technologies office: +1 303 538 2899 11900 N. Pecos fax: +1 303 538 3907 Westminster, Colorado 80234 USA

1 0

H.225 V3 for decision in September
by Glen Freundlich 30 Jun '99

30 Jun '99

Colleagues, I've placed 2 files in the Incoming directory of the pictel ftp site: h225v301.zip - the determined H.225 V3 from the Santiago meeting with change marks showing the additions and modifications to V2 to reach V3 h225v3dec.zip - the determined H.225 V3 with changes accepted and ASN.1 cleaned up and reformatted (but I've not yet had a chance to compile the ASN.1) As you may have seen in the mail from Paul Jones, we need to deliver the files on June 30. I know this is not much warning, but I would really appreciate any comments or corrections folks might have - a sanity check from another set of eyes is always helpful. Regards, Glen -- Glen Freundlich ggf(a)lucent.com Lucent Technologies office: +1 303 538 2899 11900 N. Pecos fax: +1 303 538 3907 Westminster, Colorado 80234 USA

1 0

Re: MGCP reference (was Re: Megaco/H.gcp conference call)
by Nancy-M Greene 29 Jun '99

29 Jun '99

Chip, you are right, the name Telcordia/Level 3/RSL COM/Vertical MGCP is not convenient. Christian has already made the same comment you have. I said in reply to him, and to the list, that I did make an error in adding Cisco to the qualifier for MGCP. Since then, I refer to the new Megaco protocol as the Megaco protocol, or the Megaco/H.gcp protocol, and to MGCP as MGCP. Since a new version of MGCP has come out, version 1, (draft-huitema-megaco-mgcp-v1-00.txt), this distinction is even more necessary. It makes sense that megaco is part of the file name, because there are parts of MGCP that still need to be turned into RFCs for packages for the Megaco/H.gcp protocol, but it means the new Megaco/H.gcp protocol can never really be called MGCP - it is too confusing. It would be good at some point to pull the packages out of MGCP to stand alone as a separate document for Megaco. And perhaps the UDP + timers part of MGCP so that it can stand beside TUDP, MDTP, and TCP as alternatives for Megaco transport. Nancy -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com > ---------- > From: Chip Sharp[SMTP:chsharp@cisco.com] > Sent: Tuesday, June 29, 1999 2:53 PM > To: Greene, Nancy-M [CAR:5N10:EXCH]; ITU-SG16(a)mailbag.cps.intel.com; > megaco(a)standards.nortelnetworks.com > Subject: MGCP reference (was Re: Megaco/H.gcp conference call) > > 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

Joint Session In Oslo
by Tom-PT Taylor 29 Jun '99

29 Jun '99

I have the possibility of a meeting room which would hold 40 people on Tuesday morning at the Oslo IETF meeting. Could we make creative use of that, either by holding a syntax design team meeting or by holding a meeting specializing in H.GCP topics of particular interest to SG 16? Note that a full Megaco meeting is typically 225 or so people. Tom Taylor Advisor -- IPConnect Standards E-mail: taylor(a)nortelnetworks.com (internally, Tom-PT Taylor) Phone and FAX: +1 613 736 0961

1 0

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

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