Hi All,
H.GCP version I promised for today will not be available until Monday. . .
I need the weekend to finish it off, Sorry about they delay
Have a good weekend,
Bryan
-----Original Message-----
From: Greene, Nancy-M [CAR:5N10:EXCH]
[SMTP:ngreene@americasm01.nt.com]
Sent: Thursday, April 08, 1999 4:23 PM
To: 'megaco(a)baynetworks.com'; 'itu-sg16(a)mailbag.intel.com'
Subject: audio call Thursday: Minutes
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@nortelnetworks.com
