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@vocaltec.com

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

Please respond to Tom-PT Taylor taylor@NORTELNETWORKS.COM

To: MEGACO@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.