Megaco Protocol - IETF/ITU conf call minutes

Greene, Nancy-M [CAR:5N10:EXCH] ngreene at americasm01.nt.com
Mon Mar 29 15:53:55 EST 1999


Here are the minutes from the call today. Please email me any corrections. I
tried to pair comments made with the person that made them - I may have made
some errors, and I know I missed the names of some of the people commenting.



Nancy (ngreene at nortelnetworks.com)
-----------------------------------------------------------

Megaco Protocol presentation to IETF megaco and ITU SG16 participants
March 29/99 10am-12pm EST
=================================================

Present: The number of ports being used went as high as 47, and was about 45
on average. Number of participants was higher since a number of people were
sharing ports.

Chair of the call: Glen Freundlich (ggf at lucent.com)
Minutes:  taken by Nancy Greene (ngreene at nortelnetworks.com)

NOTE: In keeping with IETF and ITU procedures, the audio call cannot make
binding decisions. It is a tool for the chairs and editors, and the
participants of both the IETF and ITU working groups, to gauge support for
the protocol, and to raise issues with the protocol. Issues may be raised in
either an audio call, or on the mailing list (megaco at baynetworks.com). These
minutes are going to both the Megaco and ITU-SG16 mailing lists.

Meeting summary:
--------------------------
Glen Freundlich summed up results of the meeting. The goal of the meeting
was two fold:
1) it was the first opportunity for people to look at the output from the
Megaco protocol design/drafting group.
2) it was an opportunity for people to pose questions on the draft.

He saw no opposition to the connection model proposed in the Megaco protocol
I-D (ftp://www.ietf.org/internet-drafts/draft-ietf-megaco-protocol-00.txt).
To date, the Megaco protocol I-D has been run through audio call scenarios
for 3-way call, for call waiting, ... However, it needs to be tested with
multimedia scenarios. Any input in this area is appreciated. 

Because there seems to be agreement on the connection model, Bryan Hill, the
H.gcp editor, will start pulling related sections from the Megaco protocol
I-D into H.gcp. 

Glen will hold another audio call next week to see where we stand, and to
look towards adding more sections to H.gcp from the Megaco protocol I-D.

For the ITU-T SG16 May meeting, H.gcp needs to contain:
- a connection model
- a set of commands
- a start on parameters for those commands
- generic syntax
- and a list of issues to resolve.


Protocol timetable:
--------------------------
IETF Megaco:
- Proposed Standard by summer/99
- interoperability testing in fall/99
- Draft Standard in Feb/2000

This matches up closely with the ITU-T SG16 schedule:
- planning to get H.gcp determined in May/99
- planning to get H.gcp decided in Feb/2000

IETF/ITU collaboration:
-------------------------------
Question raised: will the two protocols be identical?

Tom Taylor proposes two options:
1) SG16 and Megaco completely agree on the protocol requirements. If this is
the case, the protocol will be identical

2) Each group has some requirements that are different from the other group.
In this case, there would be agreement on a core protocol, and then
additional parts would be defined by each group.

BUT how to do this in practice? Tom said that if a huge roadblock comes up
again, we would form a new design team to work out a solution. 

Tom asked whether the group on the call agreed that the Megaco protocol I-D
was a reasonable basis for H.gcp. Feeling was that it is, but that we need
to do multimedia call walkthroughs. Mike Buckley had some concern about the
definition of a context, but thought that the basic model is workable.
Mauricio Arango thought it was a good model for multimedia. Ami Amir raised
issue about associating contexts. Glen asked the H.320 experts to look at
the protocol and see if we need to modify the connection model.


Next audio call:
----------------------
Probably next Thursday April 8/99, same time. Confirmation of date & time
and the call details will be out later this week.


Use of mailing lists:
---------------------------
It was agreed that we would try to keep all technical discussion of the
Megaco protocol on the megaco at baynetworks.com mailing list. 

Invitations to audio calls, and audio call minutes will be sent to both the
megaco at baynetworks.com and to the ITU-SG16 at mailbag.intel.com mailing lists.

Tom Taylor took the action of posting to each list, how to join the other
one.

Detailed minutes:
------------------------
Brian Rosen presented the Megaco protocol draft
(ftp://www.ietf.org/internet-drafts/draft-ietf-megaco-protocol-00.txt). He
first noted that this draft is open for discussion. It is not cast in stone.
If changes need to be made to any part, they will be made, if they are
deemed necessary to satisfy the requirements of the protocol, and agreed to
by the group.

1. New connection model
- concept of a termination - have permanent (e.g. DS0) and ephemeral (e.g.
RTP port) terminations
- a termination is named with a terminationId, this name can have wildcards,
for example to allow the MG to choose the actual physical termination, or to
request notification of an event that occurs on any DS0
- concept of a context - can add, subtract, modify terminations in a
context. A context is created when the first termination is added to it, and
goes away when the last termination is subtracted from it.
- a context can have parameters associated with it - for example, a video
mixing context may have parameters to describe how the video is to be mixed
- mosaic, or current speaker/last speaker, ...
- a termination class defines parameters on a typical termination - e.g. DS0
Termination Class, RTP Termination Class
- Signals can be attached to a termination class, events can occur at a
termination class, and the MGC can specify which ones it wants to be
notified about.
- packages define signals and events
- a termination class can have more than one package that apply to it
- event naming structure allows package name to be put in front of the event
name
- question: how do you apply a call waiting tone? - answer - it is a signal
that you apply to a termination

1.1 Proposed Changes and Issues:
a. Tom Taylor proposed a more general definition for context: every
termination in a context has connectivity with all other terminations in the
context.

b. Raised by Mauricio Arango: you may want to be able to create a context
with parameters before adding any terminations to it - (e.g. turing machine)
- may want to mark a context with the max # of terminations at creation
time. - BUT this may bring lack of flexibility - may be better to let the MG
decide, as new terminations are added to a context, whether it is able to
mix them in. For example, instead of marking a context with one particular
type of codec, it is more flexible to let the MG decide what transcoding
needs to be done in a context as a function of the types of terminations
added to it.

c.  Raised by a few people: we need to see whether we need a meta definition
of a "call" in the MG, so that the MG can link together related contexts.
May be needed for lipsynch between a call's video context and its audio
context. Instead of introducing a callId, this could be done using
parameters on each context referring to the other one. Benefit of a callId
is that the MGC can bring down the entire call by just referring to the
callId. (Note: "call" may be the wrong word - if we need it, let's try to
invent a new name).

d. Raised by Steve Davies: with H.320, the MG has one physical termination
with audio, video and data on it - can a termination be in more than one
context? no - so need to separate the different media out of this physical
termination before creating the contexts.

e. Raised by Tom Taylor: need to see whether it is feasible to have
decomposed H.320 gateways - if it is necessary (people say yes), then need
to be sure the Megaco protocol can handle it.


2. Commands
- grouped into commands within an action per context, and one or more
actions are grouped into a transaction. Transaction is all or nothing.
- Add, Modify, Subtract each can contain local and remote terminiation
descriptors, signalling descriptor, an events descriptor, and a digit map
descriptor
- question on how to change an event description for a termination - answer:
use Modify - can do it within a context, or outside a context - if it is
outside the context (i.e. using the NULL context), then that is how you
change the default parameters for that termination.
- MGCP's NotificationRequest is now covered in Modify

3. Multimedia and Contexts and Terminations
- a termination only belongs to one context
- for multimedia, there is one context per media type
- just as you have separate RTP flows for different media types, you have
separate contexts.

3.1 Issues
a. Paul Sijben noted that when you try to use the Megaco protocol with
H.320, there may be problems with the model - Paul will bring these up on
the mailing list.

Also, see Issue c in 1.1 above.

4. H.245 & SDP
- Tom Taylor explained that H.245 has at least 2 purposes: 1) for capability
negotiation, and 2) for specification of open logical channel. The scope of
the Megaco protocol is 2). Capability negotiation may use H.245 between
MGCs, but the Megaco protocol is between MGC and MG. SDP may be good enough
to be used between the MGC and the MG. Discussion still open here. Need to
allow for an environment where H.245 may not be involved.
- with H.263 - H.245 provides a tag to link together 2 RTP streams - need to
be able to carry this tag from the MGC to the MG.

5. underspecifying termination descriptors
- can be used as a way to tell the MG to use default values for the
termination
- a termination learns its default values at MG boot-up time
- MGC can change these values using Modify with context set to NULL.

6. underspecifying terminationIds
- provides a way of setting default parameters for a T1 for example

7. Case: two audio contexts - in different MGs, and in the same MG
- can the connection model handle this? Yes
- protocol should need to keep track of where resources are.
- it is up to the MGC to know what contexts are associated with a call.

8. overview of Audit, Notify, ServiceChange
- ServiceChange - MG can use it upon reboot, to register itself with an MGC 
- MG knows which MGC to send this msg to from some method outside the scope
of this protocol (pre-provisioned, for example).
- MGC learns capabilities of MG using Audit. - can learn codecs

8.1 Issue
- need a way for MGC to learn the QUANTITY of codecs an MG has!

9. overview of Security
- this is security between an MGC and an MG
- interim method is specified for when an MG does not have IPSEC

10. Question on scope of the protocol
- check the requirements draft:
ftp://standards.nortelnetworks.com/megaco/docs/minn99
- Steve Davies brought up point that some aspects of the Megaco protocol
overlap with Policy server protocol proposals. 

11. Can MG do coded renegotiation?
- David Featherstone asked if an MG can negotiate use of a new codec on its
own 
- Brian Rosen answered that with AAL2 profiles, the MG can

Issue:
a. MGC may need to be involved - for example if the Quality goes down too
low, call may no longer be billable. Solution - create an event to notify
the MGC for this case.

12. How does the MGC find out RTP interfaces?
- should be able to do this using Audit in the NULL context.

13. IVR - still open for discussion
- view IVR as a termination
- issue is how much signalling effort do you need to add to the protocol? 
- simply playing msgs is ok - they just look like events
- problem is when you want to put time and money values into it for example,
you have x minutes left on your calling card. - this may be out of the scope
of the Megaco protocol

14. QoS reservation
- needs more discussion

****see Meeting summary above for audio call conclusions.

end of minutes.





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



More information about the sg16-avd mailing list