Megaco/H.gcp conference call

[Nancy-M Greene]

Minutes of the Megaco/H.gcp conference call held June 16th/99, 11amET to
1:50pmET

Number of participants: about 30, including Megaco, SG16, and Megaco/SG16
participants

The meeting was structured around the following agenda points - they are
each addressed below.

1) Termination naming - hierarchical or logical, or a combination with
TerminationId + Bearer?
2) handling multplexing terminations - as in H.gcp? or as a new context
type?
3) allowing one BearerDescriptor, and multiple MediaDescriptors per
termination - acceptable?
4) decision on transport
5) proposal for tagging the MediaDescriptor with its encoding: SDP or H.GCP
6) proposal for text vs binary encoding of the protocol
(draft-huitema-megaco-sdp-discuss-01.txt)
7) multimedia vs monomedia contexts (related to #3)
8) code points process
9) naming an editor team for a combined IETF/SG16 document, document format

***NOTE, if you wish to start a new discussion thread on any of the topics
below, PLEASE put a relevant subject on your msg (e.g. Subject: Issue #1) ,
and do not simply reply to this email.

***Another NOTE: all internet-drafts relevant to Megaco are at available at:
ftp://standards.nortelnetworks.com/megaco/docs/Oslo99/  , as well as at
ftp://ftp.ietf.org/internet-drafts


Issue #1) Termination naming - hierarchical or logical, or a combination
with TerminationId + Bearer?   &
Issue #2) handling multplexing terminations - as in H.gcp? or as a new
context type?
-------------
- Question: Is a circuit that is outside a context a kind of termination, or
a separate construct? Much discussion from Brian Rosen, Paul Sijben, John
Segers, Mike Buckley, Fernando Cuervo, Tom Taylor. There seemed to be
consensus that a circuit is a kind of termination. However, it was brought
up by Fernando Cuervo that if we consider the concept of resources for
function keys, indicators, displays, softkeys, and dialpads, that are
outside a context, as described in the IP Phone draft
(draft-blatherwick-megaco-ipphone-00.txt), then perhaps we could consider a
circuit as a resource when it is outside a context.

- note that an issue had come up on the list that management issues may be
out of scope of Megaco. In fact, COT cannot be considered management - it is
part of ISUP call control and setup, so we need a way of expressing COT
across the Megaco boundary.

- it was agreed that the definition of an MG is: an MG does media adaptation
and connections, nothing more - There was discussion on whether an MG knows
about the concept of "users".

Conclusion:
a) We need better definitions of Termination and Context, and THEN define
how to create a multiplex using terminations and contexts.

b) Brian Rosen  and Paul Sijben agreed to talk about Issues #1 and #2
tommorrow (June 17th) and post a msg to the Megaco mailing list. If there is
consensus on the outcome of their conversation, this issue is closed, if
not, Tom Taylor will appoint a design team to come up with a solution within
a week.


Issue #3) allowing one BearerDescriptor, and multiple MediaDescriptors per
termination - acceptable?

- related to #1 and #2 - not discussed - wait to see output from Brian Rosen
and Paul Sijben.


Issue #4) decision on transport
-------------
Conclusion:
- agreed that the Megaco protocol must define something for transport. We
need something for fragmentation, and need to define the timers that the MGC
and MG will use, how they will use them (i.e. what will the retry mechanism
be), and be able to suggest default values for them. The transport solution
itself could be in a separate document.

- agreed that both MGC and MG "must" implement some kind of "UDP + timers"
mechanism. We need to choose one. There are two proposals on the table:
1) the UDP + timers method in the Telcordia/Cisco MGCP  -
draft-huitema-megaco-mgcp-v0r1-05.txt, and
2) Transaction UDP + Timers (TUDP) - draft-cuervo-megaco-tudp-00.txt - This
one has just come out, and addresses the needs of Megaco - people are
invited to read it and comment on it.

- agreed that the MGC and MG both "may" implement TCP.


Issue #5) proposal for tagging the MediaDescriptor with its encoding: SDP or
H.GCP     &
Issue #6) proposal for text vs binary encoding of the protocol
(draft-huitema-megaco-sdp-discuss-01.txt)
-------------
- as with the transport issue, we need to nail down this issue asap, so that
the protocol can begin to be implemented

- there was a desire to go with what we have already, which means SDP, but
there is still the issue of and/or capability syntax to be added to the SDP

- it was mentioned that we need to be able to express all codec parameters
in SDP and in H.245 - Christian Huitema has built comparison tables for this
already - see draft-huitema-megaco-sdp-discuss-01.txt

Conclusion:
- agreed that we will wait a week for Joerg Ott and Gur Kimchi to put a
proposal on the table that allows us to express and/or syntax for stating
codec capabilities - for example an MG can support both G.723 and GSM, but
not both at the same time.

- Tom Taylor will probably pull together a small design team to bring this
issue to conclusion within the next week and a half.


Issue #7) multimedia vs monomedia contexts (related to #3)
-------------
- not discussed, although there seems to be consensus for multimedia
contexts.


Issue #8) code points process
-------------
- Tom Taylor brought up the issue of having a registry to define code points
for Megaco.

- discussed that if we had a single registry, say IANA, then we could
possibly modify H.245 to use code points coming out of IANA

- there is a precedent for this: H.245 refers to IANA-defined RTP payload
types.

Conclusion:
- look at new object oriented extension for defining codepoints in H.245 (in
the H.245 coming out of Santiago)

- if this is used, then IANA could define the codepoints, and it would be
possible to add them to H.245 using the object oriented extension mechanism
without having to change H.245 (NOTE: not sure if I got this right...)


Issue #9)  naming an editor team for a combined IETF/SG16 document, document
format
-------------
- addressed in Tom's email - see below:
> ----------
> From:         Taylor, Tom-PT [CAR:5V00-I:EXCH]
> Sent:         Wednesday, June 16, 1999 2:23 PM
> To:   megaco at standards.nortelnetworks.com
> Subject:      Working Methods For Our Protocol Document
>
> We came to several conclusions on the Megaco/H.GCP conference call today
> regarding the mechanics of developing the protocol draft:
> *       Brian Rosen and Bryan Hill are officially co-editors of the
> document, from both the IETF and the ITU point of view.  (There may be ITU
> legalities to be fulfilled before that is fully so).
> *       We are going with a single document from here on.  That is, the
> next
> document merges the Megaco and H.GCP drafts.
> *       Our working documentation will be in the form of PDF files posted
> on
> the web site.  Of course, when it is time to create an RFC, this will be
> turned into text and Postscript.
>
> I have to ask: will this final point cause anyone major difficulties?  Is
> anyone in a position where they cannot read Adobe PDF?  One drawback I can
> think of is the inability to cut and paste quotations from the document
> when
> suggesting changes.  Is this a major hangup, and if so, what suggestions
> for
> work-arounds?
>
> Tom Taylor
>
-----------
Once again, if I have made any errors or omissions in these minutes, please
let me know. Thanks to those who joined the call.

Nancy
--------------------------------------------------------------------------
Nancy M. Greene
Internet & Service Provider Networks, Nortel Networks
T:514-271-7221 (internal:ESN853-1077) E:ngreene at nortelnetworks.com