H.GCP / Megacop capabilities desctriptors issue

[Hong Liu]

Gur,

Thanks for writing up the informal discussion we had last week in Bangkok
during the ETSI TIPHON meeting there. However, I would like to clarify what we
had discussed there during a brief coffee break, which seems to be quite
different than what you summarized in the email.

First of all, I would like to point out that this was an INFORMAL meeting and
the meeting was very brief (less than 30 mins I believe). It just so happened
that some of us were in Bangkok attending ETSI TIPHON meeting, and we were
available for a discussion on SDP vs. H.245. What we agreed there should not be
contrued or perceived as the position statements from ETSI TIPHON. (This is to
clarify with the people on the list who were not in that meeting.)

Second, what we had agreed, as I recalled, is that there is a need to address
the capability description issue in SDP in the MEGACO/H.GCP work. That is the
only agreement we had in that meeting. Nothing more, nothing less. We also
discussed referring to a capability by name or by value, but no conclusion was
made. By the same token, we discussed the issue of state synchronization
between MGC and MG, as an example of capability description exchange. But
again, no conclusion was made. In short, all we agreed is that there is a
technical problem that needs to be addressed.

So the only relevant part of your email regarding the meeting is the last part
(after I am suggesting that:...), even though I disagree with some of the
wording there (see above). The arguments you made in the email (points 1-6)
were only your personal opinions, which shall not be interpreted as the general
agreements among the participants in that meeting.

Finally, I would say that the email address you used is somewhat confusing. I
guess it would be better if you identify yourself in the email.

Regards,

--Hong

H323MAIL wrote:

> 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").
>
> 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.
>
> 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.
>
> 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")
>
> 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.
>
> 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.