- sg16-avd - lists.packetizer.com

Re: Minutes form the 7/15/98 SNMP audio
by George Kajos 21 Jul '98

21 Jul '98

Sorry George Kajos VideoServer, Inc 63 Third Avenue Burlington, MA 01803 781-505-2193 (phone) 781-505-2101 (fax) -----Original Message----- From: Mailing list for parties associated with ITU-T Study Group 16 [mailto:ITU-SG16@mailbag.jf.intel.com] Sent: Tuesday, July 21, 1998 3:37 PM To: ITU-SG16 Subject: Re: Minutes form the 7/15/98 SNMP audio Hi! You missed my name in the list of participants. I'll attend tomorrow's call. Thanks. Regards, Joon

1 0

H.225.0 Annex G
by Glen Freundlich 21 Jul '98

21 Jul '98

There will be another conference call to discuss H.225.0 Annex G: date: 23 July (Thursday) time: 9:00am Mountain Time (8:00 Pacific, 11:00 Eastern, etc) bridge number: +1 630 224 4444 code: 870682 duration: 1 hour Tentative agenda: - wrap up system organization discussion - set initial scope (i.e., contents for September determination) - identify open issues - set work plan Notes from last call: Most of the call was spent … [View More]

1 0

Minutes form the 7/15/98 SNMP audio meet
by George Kajos 21 Jul '98

21 Jul '98

Hello folks, Attached are the minutes from last week's call. Please let me know if you desire a number for this week. Thanks, George Kajos gkajos(a)videoserver.com VideoServer, Inc 63 Third Avenue Burlington, MA 01803 781-505-2193 (phone) 781-505-2101 (fax) SQ16 Q14 Multimedia Management Information Base Audio Call 7/15/98 Minutes Agenda 1. Review of H.323 MIBs and RTP MIB proposals 2. Review of H.320 MIB proposals 3. APC 1393 GW contribution 4. IETF BOF Participants: Mike Thatcher, Cisco … [View More]Zvi Mizrahy, Prina Vortman, IBM Haifa Orit Levin, RadVision Bill Strahm, Mark Baugher, Intel Nicole Gallant, Nortel Don Milotte, James Pansarasa, Picturetel Chris Grindel, PacNetX Jackson Wynn, White Pine George Kajos, Irina Suconick, Don Dewar, VideoServer H.323 MIB Proposals In last weeks' meeting it was suggested that we review the existing body of work for any issues. Orit said she was working on a critique that wasn't ready in time for the meeting, but some of the big picture items were discussed in advance of Orit sending the paper to the mailing list. RAS The first agenda item was RAS. The main focus of conversation was the admissionTable indices. This has been on the agenda as action item 3 for a couple of months. Orit's proposal is to use CallID, and the source and destination callSignalling addresses instead of the source and destination RASAdresses. There are a couple of major benefits of this proposed change. The first is that the CallID is unique across all connections. The major disadvantage is that the field is not defined for reverion 1 endpoints. The major benefit of using the Call addresses instead of the RAS addresses is that they are TCP addresses instead of UDP addresses and more likely to be unique because at revision 2 of the specification mulitple connections weren't being multiplexed over the TCP port. The previous objection to the CallSignalling addresses is that the specification at revision 2 has them marked as optional. Orit pointed out that they are not optional according to the revision 2 implementer's guide. The group will consider this change during the week, but most people were largely favorable to the change. The index for the registration table was also discussed at length. Orit proposed using the endpointIdentifier. However, at present it is defined to be 128 characters and would the OID would exceed the limits of SNMP. George volunteered to talk to Jim Toga and Dale Skran to see if might be acceptable to limit endpointIdentifier to 64 characters. CallSignalling The next MIB to be reviewed was the H.225 CallSignalling MIB proposal. The main suggestion was to add the CallID to the Connection Table. This was also agreed upon after the Cannes meeting, but the version on the Picturetel site hasn't been updated yet. H.245 Orit's general comments on the H.245 MIB were that it was not well organized and didn't follow the protocol specification. We postponed discussing this MIB under Orit can complete her critique and send it to the mailing list. Gatekeeper The main suggestion is that the zone table should be updated to reflect the emerging GK-GK developments in the standard. This might be problematic because the GK-GK work is in version 3 of H.323 and the target for determination is version 2. RTP Mark discussed that he had prepared a RTP session mapping table in support of mixers and MCUs and was considering reissuing the IETF draft. George remarked that as the original requester of the table, it might be more appropriate to create such a table in the MP and gateway MIBs rather than burden the RTP MIB with trying to support a generic mapping function. Textual Conventions Mike Thatcher and Zvi Mizrahy agreed to work together to add more common definitions and conventions to the textual conventions to improve commonality and reuse. H320 MIB Proposals There was no input on the H320 proposals during this call. Gateway After a lengthy discussion during the 8th of July call regarding architecture, scope and charter, it was agreed that Zvi would send out an update of where he thought the present state of agreements were. IETF We have officially requested a BOF for this work from the IETF Operations and Maintenance Area Directors Bert Wijnen and Harald Avelstrad. Next Meeting: Wednesday, July 22, 1998 11:00 - 1:00 PM EST. Please send mail gkajos(a)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. 5. VideoServer - Generate MC and MP proposal 6. George Kajos - Generate BOF request to O&M Area Director - Sent on 7/13/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\APC-1380 - overview Avc-site\APC-1387 - textual conventions Avc-site\APC-1388 - RTP Avc-site\APC-1389 - H.323 Call Signaling Avc-site\Incoming\RasV2Mib.rtf - H.323 RAS Avc-site\APC-1391 - H.323 Terminal Avc-site\APC-1392 - H.323 Gatekeeper Avc-site\Incoming\APC1393 - Gateway Avc-site\APC-1396 - H.320 Terminal Avc-site\APC-1397 - H.320 Call Signaling Avc-site\APC-1398 - H.221 Avc-site\APC-1399 - H.320 Multipoint Control Unit Avc-site\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 12. Zvi Mizrahy - send update to the gateway proposal to the mailing list [View Less]

2 2

Re: Minutes form the 7/15/98 SNMP audio meet
by Joon Maeng 21 Jul '98

21 Jul '98

Hi! You missed my name in the list of participants. I'll attend tomorrow's call. Thanks. Regards, Joon

1 0

H.323 MIB Tables: APC-1316
by Orit Levin 21 Jul '98

21 Jul '98

Hello all! (This message is redundant for those who are registered to HMIBS) This is the draft for "Tables' indexes rearrangement" proposal. (It should have been the APC-1316 in Cannes...) I haven't addressed the "Capability Exchange Tables" of H.245. I think they also should reflect the H.245 definitions, but it is not strictly H.323 and can wait one additional week. Best Regards, Orit Levin RADVision Inc., 575 Corporate Drive - Suite 420 Mahwah, NJ 07430 Tel: 201-529-4300 (230) Fax: 201-529-3516

1 0

ITU SNMP Audio Call Minutes 7/8/98
by George Kajos 14 Jul '98

14 Jul '98

Hello folks, The next SNMP audio call is 7/15/98 (Wednesday) at 11:00 AM EST. If you'd like a number please send email to: gkajos(a)videoserver.com. Thanks, George Kajos VideoServer, Inc 63 Third Avenue Burlington, MA 01803 781-505-2193 (phone) 781-505-2101 (fax) Below are the minutes of the 7/8/98 call: -------------------------------------------------------------------------- ----------------- SQ16 Q14 Multimedia Management Information Base Audio Call 7/8/98 Minutes Agenda 1. IETF … [View More]submission/coordination 2. APC 1393 GW contribution Participants: Zvi Mizrahy, Pnina Vortman, IBM Haifa Orit Levin, RadVision Bill Strahm, Mark Baugher, Intel Nicole Gallant, Nortel David Walker and Annette Lanteigne, Mitel George Kajos, Irina Suconick, VideoServer IETF Since the previous meeting on June 22, George sent mail to Bert Wijnen and Harald Avelstrad to request an IETF working group for H.Multimedia MIB. Bert responded and requested the following next steps: 1. write-up an agenda and a goal for the BOF at Chicago 2. find a proposed chair (could be George Kajos) 3. get the current work published as one or more I-Ds (internet-drafts) 4. setup a mailing list that people can use to dicsuss the drafts and issues related to the documents. During the meeting George stated that he would draft an agenda and volunteer to chair the BOF. The draft agenda will be sent to Bert Wijnen and Harald Avelstrad on Monday 7/13. Mark Baugher will check if Intel will can support the mail reflector. There is still too much work to do on the existing MIB proposals to comply with 3 before the BOF. The overall structure of the IETF submissions will have to be discussed at the BOF if one is approved. A recurring issue, discussed at this and previous meetings, is whether the work is going to be performed at the IETF or the ITU-T. One aspect of the issue is how to serve two masters. The model discussed at both the ITU meetings and in the reply from Bert Wijnen is the details of content are clearly ITU charter work, while SNMP and MIB format and organization are inputs we expect to be likely from the IETF. The current ITU-T plan is to prepare the H.Multimedia MIB document for September determination. This will allow companies to start developing SNMP applications and get experience with the MIB proposals. The hope is that enough experience will be obtained to allow the work to reach decision in April 1999. This is analogous with the methodology used in the IETF where Internet-Drafts are expected to be implemented and reported on before going to RFC status. Gateway - Zvi & Pnina Two weeks ago Zvi submitted the gateway proposal to the meeting group and George placed in the avc-site\Incoming directory on the Picturetel reflector as APC-1393.zip. In email with Mr. Okubo, he approved of using the incoming directory if he and Mr. Webber of Picturetel are kept informed. This is to prevent misuse of the Picturetel resources. Item 8 below is an updated list of what is on the Picturetel reflector and what has been updated since the Cannes meeting. The IBM gateway proposal is a very comprehensive work. Its focus is significantly more than an H.323/H.320 gateway. For example, the connections can be point to point and multiway. In another example, among the defined connection types are PSTN and storage connections. This aspect of the proposal made George Kajos try to move discussion away from where to place the MIB in the OID tree and start the discussion by focussing what it is we are trying to define in this work. For example, what is the high level architecture of a gateway? The two models below were introduced as possible examples of what could be used as the basis for modeling a gateway. Model 1: n by n Gateway +-----+ H.323 ------+ +-----H.320 or PSTN +-----+ Model 2: generalized Gateway Storage connections | +--+--+ H.323 ------+ +-----H.320 +--+--+ | PSTN The first model depicts a point to point gateway with one side being H.323. This model forces one side to be H.323 and then it makes sense to place it under the H.323 OID hierarchy. The second model is a generalized gateway. It makes sense to be able to manage such a device but concern was expressed that this gateway night be beyond the charter of a H.323 version 2 device. Other opinions were that it doesn't make sense to design standard MIBs unless there is a specification to point to. Mark pointed out we need MIB specs that result in independent, interoperable implementations; for this reason we need to stick to the protocol specs as closely as possible. The H.246 document has a fairly complete definition of an H.323/H.320 gateway in Annex A and a start towards a H.323/PSTN gateway in Annex B. This is the model that George felt the group should start with or we could be beyond both our charter and our ability to agree on what the standard pieces are. More general gateway models are being discussed in conjunction with H.323 Version 3 and other IETF work. At the Cannes meeting it was agreed to try to focus on H.323 Version 2 and to meet market place for management of deployed H.323 devices. The proposal was for people to thing about these issues over the next week and we would discuss it in the next call. Because this charter of the work issue came up, some expressed opinions we might want to start with something clearly defined like a H.323/H.320 and make it extensible as possible to other gateway types. Examples were that other network and terminal types such as H.310 and H.324 should be able to be plugged into the framework. This was generally agreed to. Another primary architectural issue was that of multipoint and multiway connections. To illustrate the point, the following are some of the ways to create a multiway call. A multiway connection can be supported on some network fabrics such as Frame relay and ATM. They can be created at the network layer using IP multicast. They can be comprised of multiple circuits on a PBX, and they can be created by replicating at the server in MCUs. The focus of the discussion then was how many of these are actually to be modeled as a gateway call? Still the general tone of the discussion was that multiway calls should be able to be described in the MIB. Other editorial comments were discussed. One was that common conventions should be used across all of the MIBs. This makes for consistency across all of the MIBs. Another was that Pnina mentioned that IBM was willing to put the Hardware and Storage sections in a private MIB. Other Orit made the point that the work is going too fast. George disagreed and felt that it is imperative to get a document ready for determination in September in order that companies in the group would be able to start developing the MIBs in time for the April decision process. George made the point that all the proposals are on the Picturetel web site in a public place and that very little actual feedback had been received by any of the authors. It is a point that will be discussed off line with the SG16 Q12, 13, 14 rapporteurs. Next Meeting: Wednesday, July 15, 1998 11:00 - 1:00 PM EST. Please send mail gkajos(a)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 4. Group - Admission and CallSignalling Tables index correlation. 5. VideoServer - Generate MC and MP proposal 6. George Kajos - Generate BOF request to O&M Area Director 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. 8. Contributors - place any updated the MIB proposals on the Picturetel reflector. The current status is: Avc-site\APC-1380 - overview Avc-site\APC-1387 - textual conventions Avc-site\APC-1388 - RTP Avc-site\APC-1389 - H.323 Call Signaling Avc-site\Incoming\RasV2Mib.rtf - H.323 RAS Avc-site\APC-1391 - H.323 Terminal Avc-site\APC-1392 - H.323 Gatekeeper Avc-site\Incoming\APC1393 - Gateway Avc-site\IAPC-1396 - H.320 Terminal Avc-site\IAPC-1397 - H.320 Call Signaling Avc-site\IAPC-1398 - H.221 Avc-site\IAPC-1399 - H.320 Multipoint Control Unit Avc-site\IAPC-1400 - H.245 The working proposal is that any updates be placed in incoming by identifying name and Mr. Okubo and the mailing list 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 11. Group - Determine whether they would be in attendance at Chicago IETF BOF [View Less]

1 0

H.225.0 Annex G discussion
by Glen Freundlich 13 Jul '98

13 Jul '98

If you sat in on the Annex G conference call on Thursday, July 9, please send me email. Thanks, Glen -- Glen Freundlich ggf(a)lucent.com Lucent Technologies office: +1 303 538 2899 11900 N. Pecos fax: +1 303 538 3907 Westminster, Colorado 80234 USA

1 0

None
by dorothy＠radvision.com 10 Jul '98

10 Jul '98

Revital Cohen <revitalc(a)radvision.rad.co.il>, <Rick_Flott(a)vtel.com>, <stevek(a)vidya.net>, <t120-interest(a)world.std.com>, <vescera(a)cbgw2.lucent.com>, <vescera(a)lucent.com>, <yaelg(a)radvision.rad.co.il> Reply-To: dorothy(a)radvision.com Errors-To: dorothy(a)radvision.com X-URL: http://www.radvision.com Subject: RADVision Software User Group Dear H.323 Software Licensee: As you know, we are now in the process of planning programs to … [View More]

1 0

Implementers Guide
by Jim Toga 09 Jul '98

09 Jul '98

Greetings, Attached please find the updated Rev2 Implementers Guide. All of the changes highlighted in gray text are post Cannes meeting. I have not incorporated any of the ICV changes as it doesn't seem like we have reached any clear solution...... Best Regards, jimt. ***************************************************** *** +1-503-264-8816(voice) Intel - Hillsboro, OR. *** *** mailto:jim.toga@intel.com mailto:james.toga@ties.itu.int *** *** PGP keyID 36 07 … [View More]

1 0

Re: Annex G Conference Call
by Roy, Radhika R, ALTEC 09 Jul '98

09 Jul '98

Hi Everyone, I have to get any clear ideas for many issues especially when we talk about the things like "DIAMETER", clearing house, mobility, and other things not to speak about scalability of proposed solutions in the context large-scale networks (also be applicable for all packet networks conectionless and/or connection oriented in any combination). So, any pre-conceived solutions based on some high-level statements are not good enough to build confidence that those solutions will provide … [View More]the right solutions. As a first step, my proposal is as follows: 1. Define the requirements for the clearing house function in the context of our overall solutions 2. What mobility problems we are going to address? There are many aspects of mobility problems: some of them may be related to the network, and may be independent of H.323, while others might have impact on H.323 especially for the GK when addressing, BW/QOS, and other functions are concerned. 3. What is "DIAMETER" ? I have seen few sentences in the last Cannes conf in the context of the H.323. It does not tell me anything. I scanned the IETF's contributions, and I am yet to understand how this is applicable in the context of inter-GK communications. A full contribution is supposed to be made before we understand what is the impact of this solution in the context of H.323. (My understandin is that it has taken a significant amount of time to go from "RADIUS" to "DIAMETER" by the IETF. Do we want to draw a conclusion by seeing a 2-page contribution and few minutes of conf call?) 4. The kind of architectural solutions that we might have to consider for inter-GK communications (it is not a trivial task). I hope that we can minimize our confusions during the conference call if we can clarify the above things over emails or writing contributions between now and the next conf call so that all of us understand what we talking about. Let us remember: if we create a standard, we have to do it RIGHT. Thanks, Radhika R. Roy AT&T, USA (732) 949 8657 rrroy(a)att.com > ---------- > From: Jim Toga[SMTP:jim.toga@INTEL.COM] > Sent: Thursday, July 09, 1998 12:22 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Annex G Conference Call > > Orit (and others), > > If you've been around Intel much you know that when a meeting ends a > certain time - it ends at exactly that time. |:-o Sorry about the > abrupt cutoff, they gave us the 5min warning and then started the > stop-watch..... > > I agree entirely with the sentiments below. The only problem being > solved at this point is the address resolution (broken record here...). > > We should definitely move forward on a more general purpose solution to > solve accounting/billing, resource usage etc... (which may someday be > better than the simple message extentions that we're developing here). > > At first blush, Diameter looks like it might have promise but it needs a > number of things all of which will require more time than is reasonable to > wait for inter-domain 323 address resolution. > > 1) It needs a IETF WG home (currently an 'individual' contribution?) > 2) It needs further development for application extentions to enable all > of the services we described (and will come up with) > 3) It needs to get on the standards track and move through it to RFC > status. > > > I think we would all look forward to some concrete remarks on making the > current syntax less vague. > > With respect to NAI, that works well for DN related naming but what do we > do about PSTN resolves?....(e.g calling to PSTN from IP) > > > > At 11:34 AM 7/9/98 -0400, you wrote: > >>>> > > Hello again! > > > What happened to the Conference Call? > Was it my fault? Did I talk too much (sorry about that)? > > > My last words were (I am not sure you could hear) there are two > things to do: > 1. Intel's proposal can be adopted (as "an interim" solution for > specific "address resolution" problem) , but in order to be interoperable > and useful > it should be, in my opinion, more tide: > - less flexible syntax > - defined push mechanism > Jim, do you mind send to you some concrete remarks? What do you > think about using NAI instead? > 2. In parallel, I believe, we have start working towards the more > complete solution, starting from the "architectural" definition and things > that we want to accomplish "as far as we can see now". > > > Orit Levin > RADVision Inc., > 575 Corporate Drive - Suite 420 > Mahwah, NJ 07430 > Tel: 201-529-4300 (230) > Fax: 201-529-3516 > > > <<<< > > > > > > ***************************************************** > *** +1-503-264-8816(voice) Intel - Hillsboro, OR. > *** > *** mailto:jim.toga@intel.com mailto:james.toga@ties.itu.int *** > *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41 *** > ***************************************************** > [View Less]

1 0