REMINDER:Megaco/H.gcp call May 11th

[Nancy-M Greene]

Thanks for the Fwd Massimo, since I am
not on the exploder for SG16.... Here are my comments
based on my remeberances from our conversations...

Massimo Lucchina wrote:
> >X-SMAP-Received-From: outside
> >X-Lotus-FromDomain: VOCALTEC
> >Date:         Fri, 7 May 1999 07:56:47 +0200
> >Reply-To: Mailing list for parties associated with ITU-T Study Group 16
> >              <ITU-SG16 at mailbag.cps.intel.com>
> >Sender: Mailing list for parties associated with ITU-T Study Group 16
> >              <ITU-SG16 at mailbag.cps.intel.com>
> >From: H323MAIL <H323MAIL at VOCALTEC.COM>
> >Subject:      H.GCP / Megacop capabilities desctriptors issue
> >Comments: To: ITU-SG16 at mailbag.cps.intel.com,
> >          MEGACO at STANDARDS.NORTELNETWORKS.COM
> >To: ITU-SG16 at mailbag.cps.intel.com
> >
> >Dear GCPers/MEGACOPers
> >
> >There has been some discussion lately on the suitability
> >of standard SDP for expressing the capabilities of MGs.  At the
> >TIPHON meeting in Bangkok (some of us <are> having fun) we held an
> >informal meeting with participants from Telcordia, VocalTec, Siemens,
> >Ascend, Motorola, Dialogic and Lucent (forgive me if I forgot someone).
> >
> >There was general agreement (by which I do NOT mean consensus...) that
> >the use of SDP in Megacop as it currently stands is a problem:
> >
> >1. SDP cannot express inartistic hardware limitations, such as mutually
> >   exclusive sets of capabilities (e.g. "I can do 24 x GSM and 24 x 723 but
> >   not at the same time").
>

Yes..

> >2. This has two implications:
> >
> >   * either the MG cannot express these limitations, which means that it
> >     will reject many commands from the MGC, as the MGC is unaware of the
> >     limitations (we called it "reject floods").
> >
> >   * or the MG will have to be designed (with extra DSP/memory for example)
> >     to not have any limitations that cannot be expressed using SDP.
> >
> >   If you build hardware, this is immediately obvious.
>

I don't think we reached any conclusions about "reject flood" or other
limitations based on hardware et.al.
It may be that the author of this (which I cannot tell from the From:
line) is reflecting
a problem that they themselves have.. I do think it is a matter of
individual postition...


> >3. Interoperability between decomposed GWs and simple 323 endpoints will
> >   be effected, as many calls will fail due to capabilities (and current
> >   resource use implications) not being correctly represented to the call
> >   signalling layer.
>
> What was stated is that interop with 323 endpoints is a must and therefore the issue has to be studied

agreed... we were to study this item... no conclusion was reached in the
group...

> >4. That the current method of expressing capabilities (regardless of SDP)
> >   is "by Value" and should be "by Reference", where:
> >
> >   * a master-set of  capabilites is represented at the root level,
> >     and references to it are used when issueing commands;
> >
> >   * leaf-nodes only contain logical references:
> >     (e.g. "I am a T1 line, I can do 24 x Cap-1 OR 22 x Cap-2")
>

I liked this idea, by reference is always nice :)


> >5. That the discussion of "SDP Vs. H.245" is inherently flawed, as:
> >
> >   * SDP is only capabilities descriptors, and H.245 is also multiple sets
> >of
> >     procedures (master/slave, caps-exchange, OLCs, conferencing control).
> >
> >   * The issue is whether we should be using H.245 CAPABILITIES DESCRIPTORS
> >     irrelevant of packetizarion, not the actual procedures of H.245.
> >
> >   * that talking about H.245 does not immediately mean ASN.1 PER.
>

Yes we did  agree that a starting point (not the final solution) to
look at fixing this problem is with the CAPABILITIES DESCRIPTORS of
H.245.

That is not to say we would use H.245 procedures and it is not to say
that the current H.245 descriptors could not be enhanced and improved in
a yet undetermined way... All we agreed is H.245 CD's are a good place
to start to fix the problem...

> >6. That the internal model is not consistent (this may have been
> >   corrected in the latest draft from Brian) - by this I mean that
> >
> >   * The MGC knows what the state of it's MG is because it is the only
> >     entity that can change it (one-to-one relationship); and
> >
> >   * if the state of the MG changed NOT DUE TO A COMMAND FROM THE MGC,
> >     the MG must report this to the MGC.
> >
> >   * This handles failures (where some trunk-group went out of service)
> >     and when the resources of multiple logical MGs are an expression of
> >     on physical MG.
> >I am suggesting that:
> >
> >   *  We acknowledge the limitation of SDP and find a solution that works,
> >      this is where people will write contributions.  Whatever we choose is
> >      in any-case no longer compliant SDP.
> >
> >   * we change the capabilities descriptors (that we choose based on the
> >     previous point...) to be "by reference".
> >
> >   * that we clarify the internal consistency model.
>
Yes, some improvement will be needed... the above is your suggestion on
how to improve it. I think we reached a point that we all agree we have
some issues to address... we did not come anywhere near agreement on
how to fix the problems.... But of course the first step to fixing
a problem is to recognize that you have one :)


Cheers
R
--
Randall R. Stewart
Member Technical Staff
Network Architecture and Technology (NAT)
847-632-7438 fax:847-632-6733