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

H283 decided document is available
by Mark Duckworth 25 Sep '99

25 Sep '99

I uploaded it to the ftp site. ftp://standard.pictel.com/avc-site/Incoming/H283_decided.zip Mark

2 1

Re: New T.35
by Paul Long 30 Jun '99

30 Jun '99

Paul, Could we run into problems with some country actually using the extension field? (I think the US always defines it to be zero.) I don't see any other alternative, though. Paul Long Smith Micro Software, Inc. -----Original Message----- From: Paul E. Jones [SMTP:paul.jones@TIES.ITU.INT] Sent: Monday, June 28, 1999 9:31 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: New T.35 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

5 5

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

30 Jun '99

It's for real. Honestly speaking, there is much wariness on the IETF side, but so long as the outcome continues to be sensible the agreement is holding. > -----Original Message----- > From: Chip Sharp [SMTP:chsharp@cisco.com] > Sent: Wednesday, June 30, 1999 1:40 PM > To: Taylor, Tom-PT [CAR:5V00-I:EXCH]; ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: MGCP reference (was Re: Megaco/H.gcp conference call) > > 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 Sherlock, Stuart 30 Jun '99

30 Jun '99

Would someone please unsubscribe me. Thanks Stuart Sherlock -----Original Message----- From: Paul Long [mailto:Plong@SMITHMICRO.COM] Sent: Wednesday, June 30, 1999 9:28 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: PDU & ASN parser 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 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