snmp audio call of 7/27/98
George Kajos
gkajos at VIDEOSERVER.COM
Mon Jul 27 12:36:00 EDT 1998
Hello folks,
Attached are the minutes of the 7/27/98 audio call. Our next call is
Wednesday 7/29/98 at 11:00-1:00PM EST. Please let me know if you wish to
have a number for the call.
Thanks,
George Kajos
gkajos at videoserver.com
VideoServer, Inc.
63 Third Avenue
Burlington, MA. 01803
781-505-2193 (tel)
781-505-2101 (fax)
SQ16 Q14 Multimedia Management Information Base
Audio Call 7/22/98 Minutes
Agenda
1. Review of Zvi Mizrahy*s email regarding gateway MIB proposal
2. Reiew of Orit Levin*s document discussing H.323 MIBs
3. Discussion of MIB hierarchy picture from Joon Maeng
4. IETF BOF
Participants:
Mike Thatcher, Cisco
Zvi Mizrahy, Prina Vortman, IBM Haifa
Orit Levin, RadVision
Bill Strahm, Mark Baugher, Intel
Nicole Gallant, Nortel
Don Milotte, James Pansarasa, Picturetel
Joon Maeng, VTEL
Jackson Wynn, White Pine
George Kajos, Irina Suconick, Don Dewar, VideoServer
H.323/H.320 Gateway
We reviewed Zvi*s mail message. The points are repeated and annotated
below:
1) The Gateway MIB will include the following subtrees :
h323gwSystemDescription (new)
h323gwCapabilities (new)
h323gwConfiguration
h323gwStatistics
h323gwCalls
h323gwConnections
h323gwNotifications
h323gwCommands
We also suggest to add an empty subtree for private vendor information.
There was general agreement to the hierarchy, except in the
h323gwCommands subtree. Here there was some discussion about what is
appropriate for standardization and what should be vendor specific. The
approach seemed to be to limit the tree to general commands relevant to a
gateway application, but people probably need to see more details. It
was pointed out that the MIB could contain an OID which could point to a
vendor specific MIB as part of the standard MIB.
2) The structure of the MIB should be flexible as possible to allow
future extensions, for example , plugging in other types of endpoint
protocols. The concept of "call connections" suggested in the proposal
supports this.
There was agreement to this principle, after a review of the relationship
between calls (end to end) and connections (endpoint to gateway) in terms
of scope.
3) The "IP" connection type should be changed to "H323" connection type.
Some of the variables defined by this connection might overlap with
other MIBs such as the RTP MIB. This is still opened for discussion.
There was agreement to this principle
4) The MIB should contain an "H320" connection type in addition to the
"H323" and the "PSTN" connections. A point to point call is represented
by an H323 connection + either an H320 or PSTN connection. In addition,
each call has also some common information . We have also suggested a
'sub connection' entity that allow to distinguish between audio, video or
fax information for each connection type. IBM Haifa will appreciate
contributions for the H320 connection type.
There was agreement to this principle. VTEL and VideoServer agreed to
help with the H.320 representation.
5) The "storage connection" should be taken out, possibly to a private
vendor information.
6) The Hardware group will be taken out to a private MIB, as this
represents a vendor type of information.
7) The issue of the location of the gateway MIB has been agreed. It will
be placed under the H323media MIB.
There was agreement to points 5-7.
8) The issue of representing conference (multipoint) calls in the gateway
MIB is still under debate. IBM is convinced that multiway calls should be
able to be described in the gateway MIB despite the fact that the MCU is
responsible for these types of calls.
This is still an open issue. While most agree with this view, the general
architecture of a gateway needs to be finalized. This was discussed in
much greater detail in the minutes from the 7/08/98 call.
9) The gateway MIB will use conventions or 'enumerated types' that should
be added to the textual conventions MIB proposal ( TBD).
There was agreement to this. Zvi should send Mike Thatcher proposed
changes.
H.323 MIBs
We reviewed the H.323 MIBs by the following the outline presented in Orit
Levin*s document. From section 2.1 H225-MIB, we agreed to change the
indices of the h225ConnectionsTable to
h225SrcCallSignallingAddressTag H323TAddressTag,
h225SrcCallSignallingAddress Taddress,
h225CallId H323GlobalIdentifier
and agreed to add clarifying text that in order to support H.323v1
instances, h225CallId should be filled with default value ZERO of an
appropriate type and length.
>From section 2.2 RAS-MIB we agreed to change the indices of the
RegistrationTable to:
RegistrationSrcCallSignallingAddressTag H323TAddressTag,
RegistrationSrcCallSignallingAddress Taddress,
>From section 2.3 RAS-MIB we agreed to change the indices of the
RegistrationAliasTable to:
RegistrationSrcCallSignallingAddressTag H323TAddressTag,
RegistrationSrcCallSignallingAddress Taddress,
registrationAliasIndex Integer32
>From section 2.4 RAS-MIB we agreed to change the indices of the
AdmissionTable to:
admissionCallSignalingAddressTagH323 H323AddressTag,
admissionSrcCallSignallingAddress Taddress,
admissionDstCallSignallingAddress Taddress,
admissionCallId H323GlobalIdentifier,
admissionAnswerCall Boolean
and greed to add clarifying text that in order to support H.323v1
instances, h225CallId should be filled with default value ZERO of an
appropriate type and length. Orit volunteered to supply a description of
the uses of the callSignalling addresses in the various tables; for
instance when its used as a listen port and when it*s a dynamic port.
The discussion around section 2.5 H.245-MIB centered on combining the
various tables into a single table and how to refer them back to the
H.323 call. There was general agreement to the idea of using a single
H245CallIndex. Further discussion was focused on how to represent the
H245 capabilities. Orit agreed to try to draft an example of how she
would represent the capabilities.
Joon Maeng*s Hierarchy picure
Joon sent a hierarchy diagram to the mailing list. In principle, people
tended to agree with the top level view presented in the picture for how
to represent a gateway and MCS, but the meeting was near closing and we
agreed to take up again the following week.
IETF
Our request for a BOF at the Chicago, IETF meeting (8/24-8/28) has been
accepted by the IETF Operations and Maintenance Area Directors Bert
Wijnen and Harald Avelstrad.
Next Meeting:
Wednesday, July 29, 1998 11:00 - 1:00 PM EST. Please send mail
gkajos at videoserver.com for a bridge port number.
Current Action Items:
1. George Kajos - Publish meeting minutes (this report) and schedule next
conference.
2. George Kajos - Confer with ISO and IETF network management experts
regarding placement of H.Multimedia MIB.
3. Group - Admission table indices - See updated RasV2Mib.rtf for CallID
change and text in report
4. Group - Admission and CallSignalling Tables index correlation. -
closed 7/22/98
5. VideoServer - Generate MC and MP proposal - See h323MCmib.rtf on
Picturetel site.
6. George Kajos - Generate BOF request to O&M Area Director - Sent on
7/13/98; accepted 7/27/98.
7. George Kajos/ Mark Baugher - Set up a mail reflector which can be used
for IETF input and access - George does not think VideoServer will be
able to do this and Mark Baugher said he would look into whether Intel
can take this on. - Intel created HMIBS on 7/17/98
8. Contributors - place any updated the MIB proposals on the Picturetel
reflector. The current status is:
Avc-site\9806_Can\APC-1380 - overview
Avc-site\9806_Can\APC-1387 - textual conventions
Avc-site\9806_Can\APC-1388 - RTP
Avc-site\9806_Can\APC-1389 - H.323 Call Signaling
Avc-site\Incoming\RasV2Mib.rtf - H.323 RAS
Avc-site\9806_Can\APC-1391 - H.323 Terminal
Avc-site\9806_Can\APC-1392 - H.323 Gatekeeper
Avc-site\Incoming\APC1393 - Gateway
Avc-site\Incoming\h323MCmib.rtf - H.323 MC
Avc-site\9806_Can\APC-1396 - H.320 Terminal
Avc-site\9806_Can\APC-1397 - H.320 Call Signaling
Avc-site\9806_Can\APC-1398 - H.221
Avc-site\9806_Can\APC-1399 - H.320 Multipoint Control Unit
Avc-site\9806_Can\APC-1400 - H.245
The working proposal is that any updates will be placed in incoming by
identifying name and
Mr. Okubo and the mailing list will be informed.
9. Group - Gateway - we have to decide the architectural model for a
gateway, what are the standard pieces, should multiway connections be
modeled, etc.?
10. Group - Review all MIB proposals - ongoing
11. Orit Levin - send MIB critique to the mailing lists - done 7/21/98
12. Zvi Mizrahy - send update to the gateway proposal to the mailing list
- done 7/21/98
13. Group - Review MC MIB
More information about the sg16-avd
mailing list