Subject: Re: Interop > Re: Proposal: explain MEGACO protocol RFC status e xplicitly

From: Peter Blatherwick <[email-masked]>
Date: Thu, 23 Mar 2000 08:06:22 -0600

I like the idea of a test suite.  It would allow us to quickly verify the
basic mechanics in an agnostic way.  This would not test the specific
packages, which of course also need to be interoped, and would not be a
"test in practice".  Of course designing the suite would take some time.

I still believe that deciding some simple, real, applications would be a
VERY good step as well, real soon.  Test suite would be an initial step only
in my mind.  Real applications is what we're trying to get to after all, and
we'll learn a lot more about the practical aspects through these.

My 0.02.  (How much is that in Oz dollars, converted from Canadian?)

-- Peter

> -----Original Message-----
> From: Christian Groves [SMTP:[email-masked]]
> Sent: 23 Mar, 2000 01:01
> To:   [email-masked]
> Subject:      Re: Interop > Re: Proposal: explain MEGACO protocol RFC
> status  explicitly
>
> G'Day Brian,
>
> Thanks for the update. Can you elaborate on the "home" of this effort? I
> know you've done some work in MSF on this. Can you provide some info to
> the list if you have more details of what is to be tested and what the
> current plans are?
>
> Is it necessary to organise a "home" for this effort? Sigtran it seems
> are doing a protocol interop test without having to go to another forum.
> Interested parties are getting together. Perhaps someone who
> participates in the Sigtran interop can comment? Perhaps we could do
> something similar for Megaco?
>
> I'm glad that the first step with not be part of a larger effort and
> will be done on simple devices. The question is what sort of devices and
> what packages?
>
> I've envisaged that the test could be done as you say between Megaco MGC
> and Megaco MG and would be agnostic of the application and many
> packages. I saw that we test the root package as it has protocol
> specific information and perhaps a specifically developed test package
> that has a number of properties, signals, events, statistics labelled in
> a very generic way. I didn't see that we would do a simple IP phone or
> trunking GW interop. After all we just need to test the Megaco
> mechanisms.
>
> A test profile containing test cases and scripts could then be defined
> to test the various protocol mechanism employed to relay the properties,
> signals, events and statistics.
>
> We can worry about format and reporting of the interop event when we get
> closer to it.
>
> Cheers, Christian
>
> "Rosen, Brian" wrote:
> >
> > I have been planning to (help) organize early interoperability
> > testing.  There is some experience in PacketCable and ISC
> > in testing MGCP that we can leverage.
> >
> > I have been looking for a "home" for this effort, and hope
> > to have that worked out soon.
> >
> > I believe the first testing will NOT be part of a larger testing
> > effort, and we will pair Megaco MGCs with Megaco MGs for testing.
> > First tests will be done with "simple" devices - no more than
> > a subset of the packages defined in the original document.
> > We may have a test profile to offer well in advance of the test
> > that will improve the probability of many MGCs and MGs to try.
> > There will be some scripts available.
> >
> > It will be open to all who have devices to test.  It will be
> > "private" - no observers, just engineer to engineer.  The only
> > reports issued will be summary in nature and limited to areas
> > of confusion or other protocol documentation issues.
> >
> > I'd like to hear from people implementing the protocol when they
> > would be ready to start testing.  I may have a "co-sponsor",
> > but others are welcome if they are interested.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Christian Groves [mailto:[email-masked]]
> > > Sent: Tuesday, March 21, 2000 10:27 PM
> > > To: [email-masked]
> > > Subject: Interop > Re: Proposal: explain MEGACO protocol RFC status
> > > explicitly
> > >
> > >
> > > G'Day all,
> > >
> > > Chip raises an interesting issue of interoperability tests.
> > > The current
> > > plans for such testing seems to me to be ambiguous at best.
> > >
> > > Due to the generic nature of Megaco it seems to me to be
> > > quite difficult
> > > to test. From what I have seen (please correct me if this isn't the
> > > case) is that Megaco/H248 is planned to be tested as part of a larger
> > > application test. ie. trunking gateway, IP phone etc. This to
> > > me seems a
> > > lot of overhead just to test the megaco protocol. It also seems to put
> > > certain players of the interop test. ie. if I make SIP GW which have
> > > h248 but the interop test covers IP phones how do I get my
> > > Megaco stack
> > > tested???
> > >
> > > Are there any initiatives where something similar to the following
> > > approach is taken? Do people see merit in this?
> > > o The test is a test of the protocol mechanisms.
> > > o Test between 2 boxes (PCs, workstations etc) that implement
> > > H248 with
> > > the necessary SW to drive the test. These boxes would be application
> > > agnostic.
> > > o A test package could be developed with "dummy" properties, events,
> > > signals etc.
> > > o A test case document which lists test cases for a good coverage test
> > > of Megaco. These test cases could describe what should occur at dummy
> > > event detection.
> > >
> > > The aim of the approach is an interop where people who intend to
> > > implement Megaco but not in one of the proposed applications can test
> > > there stacks without having to implement an entire application.
> > >
> > > If anyone has any information of the current status of Megaco interops
> > > can they please share it on the list.
> > >
> > > Cheers, Christian
> > >
> > >
> > > Chip Sharp wrote:
> > > >
> > > > As a further clarification, independent of any judgement on
> > > megaco/H.248 in
> > > > particular, publication of any RFC as Proposed Standard is really a
> > > > snapshot of the development of the protocol.  At the point
> > > of publication
> > > > of the RFC as Proposed Standard, the protocol is considered
> > > stable enough
> > > > to begin implementation, perform interoperability tests and
> > > perhaps get
> > > > some deployment experience (not necessarily in production networks).
> > > >
> > > > If during this process, problems are found in the protocol
> > > and corrections
> > > > are needed, a new RFC can be published with the corrections
> > > while still
> > > > remaining in Proposed Standard state.
> > > >
> > > > There is no requirement to implement an I-D before it moves
> > > to Proposed
> > > > Standard.  Sometimes this is done and it definitely helps
> > > to get this
> > > > experience to learn the ins and outs as the protocol is
> > > developed, but it
> > > > is not required.
> > > >
> > > > As far as megaco/H.248 is concerned, I do believe something like
> > > > implementer's agreements (or profiles) will have to be
> > > worked out for
> > > > interoperability reasons for specific applications since
> > > there are so many
> > > > options and different ways of doing the same thing.
> > > Although there are
> > > > details we all don't agree on, the IP Phone profile is one
> > > attempt at doing
> > > > this for an IP Phone application.
> > > >
> > > > One thing to keep in mind is that before megaco can move to
> > > Draft Standard
> > > > in IETF, all options that don't have multiple interoperable
> > > implementations
> > > > have to be removed.
> > > >
> > > > Chip
> > > >
> > > > At 08:50 AM 3/21/00 -0500, Rosen, Brian wrote:
> > > > >I disagree with your assessment of the state of the protocol.
> > > > >
> > > > >While there have been a series of text change proposals made
> > > > >in the last few weeks, all of them have either been requests
> > > > >to clear up language, or proposals to fix some minor errors for
> > > > >unusual circumstances.  In no case, AFAIK, would any of the changes
> > > > >invalidate any existing implementation by more than a very minor
> > > > >addition.  There are no plans for any major changes to syntax,
> > > > >and no changes at all to semantics, unless you consider
> > > clarification
> > > > >of intent to be a semantic change.  I don't understand the
> > > "transport
> > > > >syntax" part at all, unless you are thinking about the ITU work
> > > > >on ATM transport and SCTP annexes, which will not carry
> > > through to the
> > > > >IETF version on present plans.
> > > > >
> > > > >There will be an erratum published with the RFC.  Together, they
> > > > >should provide a stable basis for the protocol.  The
> > > document is large.
> > > > >In any such document, there are things that could use more
> > > explanation.
> > > > >While an implementor's guide has been discussed, it has not yet
> > > > >been decided if we will need one.  I suspect we will.  The
> > > guide will
> > > > >not, if I have anything to do with it, change the protocol at all.
> > > > >If it needs to be changed, we will have to have a new RFC.
> > > > >
> > > > >Brian
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Pekka Pessi [mailto:[email-masked]]
> > > > > > Sent: Tuesday, March 21, 2000 8:35 AM
> > > > > > To: [email-masked]
> > > > > > Subject: Proposal: explain MEGACO protocol RFC status explicitly
> > > > > >
> > > > > >
> > > > > >         Hello all,
> > > > > >
> > > > > >         The current MEGACO/H.248 draft,
> > > > > > draft-ietf-megaco-protocol-07.txt,
> > > > > >         is still ongoing work. AFAIK the protocol is still
> > > > > > incomplete and
> > > > > >         largely unimplementable. A reference implementation
> > > > > > has just been
> > > > > >         started.  The working group is planning to
> > > change the protocol
> > > > > >         semantics and transport syntax. There would be
> > > no point in
> > > > > >         publishing the document as an RFC, if this were an
> > > > > > IETF-only project
> > > > > >
> > > > > >         As I have understood, publishing incomplete
> > > recommendations is
> > > > > >         business as usual in ITU-T due to practical
> > > reasons. The ITU-T
> > > > > >         recommendations must be approved using
> > > time-consuming formal
> > > > > >         process, including a ballot. So, the finalized ITU-T
> > > > > > specification
> > > > > >         actually consists of a recommendation document
> > > > > > together with an
> > > > > >         Implementor's Guide correcting the errors and
> > > omissions in the
> > > > > >         recommendation document. IG may contain major
> > > changes that are
> > > > > >         incompatible with the published recommendation
> > > > > > document.  Also, when
> > > > > >         referring to a ITU-T specification, like
> > > H.323v2, people are
> > > > > >         actually referring to the recommendation
> > > together with the
> > > > > >         respective implementor's guide.
> > > > > >
> > > > > >         The ITU-T process is (or at least should be)
> > > familiar to the
> > > > > >         developers using ITU-T recommendations.
> > > However, in Internet
> > > > > >         community people are expecting that the RFC is not
> > > > > > just a snapshot
> > > > > >         of an on-going work. They don't anticipate that there
> > > > > > is a companion
> > > > > >         document possibly changing the base protocol in
> > > every turn.
> > > > > >
> > > > > > Proposal
> > > > > >
> > > > > >         I propose that the MEGACO RFC should contain a
> > > > > > paragraph explaining
> > > > > >         the status of the text, ie. that the protocol will be
> > > > > > changed by an
> > > > > >         Implementors' Guide published soon. The MEGACO
> > > RFC should also
> > > > > >         recommend that any reference to it must also be
> > > > > > accompanied with a
> > > > > >         note explaining the status of the RFC, and a
> > > reference to the
> > > > > >         Implementors' Guide.
> > > > > >
> > > > > >         Best regards,
> > > > > >                                         Pekka Pesi
> > > > > >
> > > >
> > > > Support NetAid!  http://www.netaid.org
> > > > --------------------------------------------------
> > > > Chip Sharp                 Consulting Engineering
> > > > Cisco Systems              Telco Bio-region
> > > > Reality - Love it or Leave it.
> > > > --------------------------------------------------
> > >

---

From: Christian Groves <[email-masked]>
Date: Fri, 24 Mar 2000 11:47:13 +1100

G'Day Pete,

I am proposing that a test suite is a first step towards more of a full
interop test. I think that to satisfy IETF requirements what we need is
a simple protocol test. Applications such as Tiphon, IP phones, MSF,
BICC etc are best interop tested as a whole in the relevant
organisations. These depend on several elements working ie. RTP stack,
codecs, etc. Real applications are of course the aim at the end of the
day but we need to start somewhere.

My 5c worth (we don't 1 or 2 cent coins in OZ)

Cheers, Christian

Peter Blatherwick wrote:
>
> I like the idea of a test suite.  It would allow us to quickly verify
> the basic mechanics in an agnostic way.  This would not test the
> specific packages, which of course also need to be interoped, and
> would not be a "test in practice".  Of course designing the suite
> would take some time.
>
> I still believe that deciding some simple, real, applications would be
> a VERY good step as well, real soon.  Test suite would be an initial
> step only in my mind.  Real applications is what we're trying to get
> to after all, and we'll learn a lot more about the practical aspects
> through these.
>
>      Subject:        Re: Interop > Re: Proposal: explain MEGACO
>      protocol RFC status  explicitly
>
>      G'Day Brian,
>