audio call Thursday: Minutes

Nancy-M Greene ngreene at NORTELNETWORKS.COM
Thu Apr 8 16:23:28 EDT 1999


Minutes of the IETF/ITU Megaco/H.GCP audio call held April 8, 1999, 11am-1pm
EDT

22 people participated, with participants from IETF Megaco, and from ITU-T
SG16.

Topics discussed:
a) issues with the current Megaco protocol internet-draft
(draft-ietf-megaco-protocol-00.txt)
b) status on folding this work into H.gcp
c) report on US Study Group D meeting April 6th/99
d) miscellaneous

Action items:
i) Next version of documents:
April 9th:
   Bryan Hill will release the current version of H.gcp
April 16th:
   Brian Rosen will release an new version of the Megaco protocol
internet-draft. He will coordinate with Bryan Hill, to also get out a new
version of H.gcp at that time that is as identical as possible to the new
internet-draft.

ii) Tom Taylor volunteered to produce write-up explaining two approaches for
handling H.320 gateways - input will come from email msgs sent out on this
topic by Brian Rosen and Paul Sijben.

iii) Tom Taylor will put together an Issues List, where each issue is
described, zero or more resolutions proposed, and  there will be a tag
marking the issue as open or closed. All editor's notes will be pulled out
of the body of the internet-draft/H.gcp, and put in the issues list, with
references back to the internet-draft. The issues list will be included in
each revision of the internet-draft/H.gcp.

Next meeting:
- no date was set for an audio call. There was some discussion on having one
some time before April 21st. If one is scheduled, it will be announced on
the ITU-SG16 and megaco reflectors.

Detailed report:

Brian Hill opened the meeting.

a) issues with the current Megaco protocol internet-draft
(draft-ietf-megaco-protocol-00.txt)
As stated above, Tom Taylor will put together an Issues List, where each
issue is described, zero or more resolutions proposed, and  there will be a
tag marking the issue as open or closed. All editor's notes will be pulled
out of the body of the internet-draft/H.gcp, and put in the issues list,
with references back to the internet-draft. The issues list will be included
in each revision of the internet-draft/H.gcp.

Issues discussed in the audio call today:

1) association of contexts and terminations  - is the context model, with
one media type per context, adequate for multimedia?

Tom Taylor says he believes the current context model with one media type
per context is adequate. Brian Rosen explained that keeping it this way
simplifies things for the common case where there is just one media type per
call (i.e. audio). Paul Sijben would still prefer to allow multiple media
types per context. When there was just one media type, the fields
identifying media type, or separate media streams would be optional. Brian
Rosen is still not convinced.

Conclusion: Tom Taylor volunteered to produce a write-up explaining the two
approaches for handling H.320 gateways - input will come from email msgs
sent out on this topic by Brian Rosen and Paul Sijben. We agreed that
figures for this discussion can be distributed in pdf instead of ascii.

Discussion on what you would need to synchronize between contexts:
- lip synch - issue - do you link contexts, or do you link a particular
termination in a context to a particular termination in another context? How
do you know that the video stream going out is the one that you want to lip
sync with the audio stream going out? If you were lipsynching the current
speaker and you knew that both the audio and video were of the current
speaker, you could lipsync the contexts. But what if the video stream going
out was NOT the one related to the audio?
- synchronize closed captioning
- synchronize the switching of streams being sent based on current speaker

2) H.245 capability negotiation
Tom Taylor explained that the capability negotiaton stage is done between
MGCs, and thus does not need to be expressable in the Megaco protocol - this
negotiation is done BEFORE connection setup. Audit allows the MGC to
discover what capabilities the MG has, but it does not give information on
mutually exclusive choices based on processing power availability, for
example.

Need to walk through the example of Test Case 1 that Tom put out before the
last IETF meeting, where the terminating MG may choose G.711 or G.729 - does
the originating MG reserve both G.711 and G.729 for the termination, or just
one of the two, and then modify it based on what the terminating MG chose?
The test case allows G.711 in one direction and G.729 in the other.

3) attributes per termination class
- these need more detail

4) how to extend the protocol
- this needs to be spelled out

5) event handling
- currently an event is identified to the MGC with an eventId - Paul Sijben
suggested that it would be better to use a terminationId

6) terminationIds
- there was a question whether terminationIds were logical or physical,
i.e., would you put the word audio in a terminationId to make it a logical
name? The answer was NO, a terminationId is a name of a physical
termination, not a logical one.

7) transport issues
There was discussion on what to use for interoperability purposes until the
actual transport is agreed on. Some people wanted to mandate TCP for the MG,
others said UDP + the message acks, + the addition of timers would be
better. Are there MG manufacturers that do not want to put TCP in their MGs,
even if only for demonstration purposes? If there is opposition to TCP even
for demonstration purposes, then we would go with UDP + message acks, +
timers. Chip Sharp reminded us that SGCP worked just fine with UPD, acks,
and timers.  ===> An issue for the mailing list.

8) security issues - no one had issues with security as it is described in
the Megaco protocol internet-draft

9) syntax issues - discussion on this issue was deferred

10) Handling of NAS
- can the protocol handle dial-out? this should be no problem - indication
that the NAS wishes to dial out would be an event from the NAS (MG) to the
MGC (NAS Controller), then the MGC issues an Add into a new context.
- if the MGC does directory lookup to an AAA server, and there are Radius
attributes to pass to the NAS, these need to be spelled out
===> need to make sure the foundations are in place to handle NAS. If
termination classes, etc. for NAS are not ready for this internet-draft,
they can go in as a separate RFC. But we will try to get them ready in time.

b) status on folding this work into H.gcp
As mentioned in the Action Items list above, Brian Hill, the H.gcp editor,
will be releasing the current version of H.gcp tommorrow. It has much of the
Megaco internet-draft folded into it. Everyone agreed that we want to keep
these two protocols aligned, and identical if at all possible. When Brian
Rosen releases a new version of the internet-draft by April 16th, he will
coordinate with Bryan Hill to get this version into a new version of H.gcp
as well.

A question was asked on what a determined document means in the ITU? Tom
Taylor answered that it means the technical directions are firmly set.

A document that is to be decided at an ITU meeting must be ready four months
before the actual meeting. In this case, it means it must be ready by Nov/99
(white paper deadline) to be decided at the Feb/2000 SG16 meeting.

If interoperability testing of the protocol starts in early fall, there will
be time to feed any corrections needed into the protocol before the Nov/99
white paper deadline.

With all this cooperation, there is a feeling that there is a good chance to
get one common protocol document between the IETF and the ITU.

c) report on US Study Group D meeting April 6th/99
It seems there is still an issue that the US may oppose determining a
document they haven't seen yet, unless there is "overriding industry
interest" in having the document determined. So, any US company interested
in having H.gcp determined should make their interest in determining H.gcp
known.

d) miscellaneous
Chip Sharp asked who is using H.226. No one on the call was.

Meeting Conclusion: See above for action items.

-end of the meeting-

Nancy
--------------------------------------------------------------------------
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