H.GCP is about gateway recomposition, not decomposition..

[Boaz Michaely]

Dear Tom and all,
I fear that the most important aspect of our work is somewhat neglected :
interoperability.

Specifically, any working "decomposed" gateway today is obvisouly based on
one of the ancestors of MGCP.
On the other hand, the vast majority of VoIP traffic generating systems are
pure H.323.

Clearly, interoperability in this sense means that a MEGACO compliant MGC
will also be a H.GCP compliant MGC.
We must make sure that implementing MGC's this way is trivial, while
concentrating on audio-only aspects, *as a guideline*, may make this target
more difficult to achieve.
On the other hand, adhering to the concepts agreed upon in Santiago should
not slow down the megaco work, which in my mind is really at the detail
level.

In parallel, megaco expert participation is required in refining H.GCP, to
ensure the very same target.

(Tom, hope you had a nice vacation at your daughter's :-)

Boaz.

Boaz Michaely
VocalTec Communications Ltd
e-mail boaz at vocaltec.com






Tom-PT Taylor <taylor at NORTELNETWORKS.COM> on 02/06/99 04:49:47 PM

Please respond to Tom-PT Taylor <taylor at NORTELNETWORKS.COM>

To:   MEGACO at STANDARDS.NORTELNETWORKS.COM
cc:    (bcc: Boaz Michaely)
Subject:  Priorities and Relevance




The feeling I get is that it won't hurt to focus our efforts for the next
few weeks on creating a draft which provides a consistent, implementable
audio-only version of the protocol, while preserving compatibility with
multimedia contexts.  Then we can spend July getting a joint H.GCP/Megaco
draft ready for the SG 16 Berlin meeting.

The items that need change to ensure compatibility with the ultimate
H.GCP/Megaco solution are:
- associating send/receive status with the medfia flows rather than the
whole termination, to allow finer control
- using MIME encapsulation when reporting capabilities in response to
audits, as Christian has suggested.  I'd like this to be present because I
think MMUSIC may eventually come up with a better solution to reporting
capabilities than SDP, yet one which maps easily to the latter or to H.245.

I'm assuming that for circuit terminations the bearer name is used as the
termination name (as it is now).  The bearer list is only needed if you
introduce the circuit multiplex termination class.  That should be a
routine
extension of the basic protocol, without implications for MGs which don't
support it.