- sg16-avd - lists.packetizer.com

Geneva Meeting
by Bilalis Zacharias 22 Dec '99

22 Dec '99

Dear Mr. Okubo, concerning the contributions, it is not yet clear to me to who I have to mail them. Could you tell me? By the way do you know where I can find Annex A to TSB Circular 182 of 7 April 1999 (contributions submission)? Thanks in advance Best Regards / Mit freundlichen Grüssen Zacharias Bilalis SIEMENS ICN WN CS EC D12 > Schertlinstr. 8 > D-81359 Muenchen > Germany > Tel: + 49 89 722 28391 Fax: + 49 89 722 61243 Mail to: zacharias.bilalis(a)icn.siemens.de

2 1

New H.323 Implementors Mailing List
by Chris Wayman Purvis 22 Dec '99

22 Dec '99

All, I would like to invite all interested parties to join a new mailing list to discuss H.323 implementation issues. Jeff Pulver has kindly agreed to host the new list at pulver.com. To join, send a mail to <majordomo(a)pulver.com> with the subject blank and the text "subscribe h323implementors" in the body of the mail. You should then receive instructions on usage of the list. The new list exists purely to discuss H.323 implementation issues, much as the IMTC's H.323 implementors list has in the past, including implementation discussion on H.225.0, H.245, H.235, H.450.x and all other standards in the H.323 "raft". The reason for the existence of the new list is the IMTC's move to making their mailing lists "closed" (ie open only to members of the IMTC, excluding a number of people with a lot of H.323 knowledge). Note that the implementors list has distinct aims and objectives from this list. The implementors list offers help to people implementing current standards, while this list looks towards future development of the standards. Issues are sometimes raised on the implementors list, however, that lead eventually to improvements in the standards, normally via this list and the implementor's guide. I look forward to seeing you on the new list. Regards, Chris -- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001

1 0

Hot Topic - Call for Paper
by Jorg Nonnenmacher 17 Dec '99

17 Dec '99

------- Blind-Carbon-Copy X-Mailer: exmh version 2.0.2 2/24/98 To: nonnen(a)research.bell-labs.com Subject: Hot Topic - Call for Paper Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 17 Dec 1999 15:31:10 -0500 From: Jorg Nonnenmacher <nonnen(a)starling.research.bell-labs.com> CALL FOR PAPERS: Special Issue of Computer Communications on Integrating Multicast into the Internet --------------------------------------- CFP URL: http://www.cs.ucsb.edu/~almeroth/COMCOM:cfp.html Journal URL: http://www.elsevier.com/inca/publications/store/5/2/5/4/4/0/ TOPICS: The amount of bandwidth available in the Internet is increasing dramatically, both in the backbone networks, as well as in the last mile (broadband access). One consequence is that the delivery of high-quality multimedia data will become feasible, and multimedia data, including audio and video, will become the dominant traffic. As more users gain access to broadband services, new applications and services will become possible. The result will be a growing demand for large-scale multimedia applications and services. Multicasting as a pure networking solution to the transport of media is recognized as offering economies-of-scale for large-scale applications. Multicast is also believed to enable applications which provide service to thousands, even millions of customers. While there has been significant research work on multicast, efforts to successfully deploy a production service have lagged. Reasons range from frequently changing protocols, management and engineering problems, legacy hardware limitations, traffic conflicts with unicast, etc.. This special issue focuses on research issues dealing with the challenges of deploying multicast in the network. Specific topics include, but are not limited to: * Multicast Congestion Control * Multicast Overlay Networks * Next-Generation Multicast Routing Algorithms * Multicast Media Transport * Security for Multicast-Based Services * Multicast Traffic Engineering and Management * Multicast Pricing and Quality of Service GUEST EDITORS: Kevin Almeroth Jorg Nonnenmacher Department of Computer Science Network Research Dept, Lucent Technologies University of California 600-700 Mountain Avenue Santa Barbara, CA 93106-5110 Murray Hill, NJ 07974-0636 Phone: +1(805) 893-2777 Phone: +1(908) 582-1707 Fax: +1(805) 893-8553 Fax: +1(908) 582-6632 Email: almeroth(a)cs.ucsb.edu Email: nonnen(a)research.bell-labs.com IMPORTANT DATES: Paper Submission Deadline: February 1, 2000 Feedback to Authors: May 1, 2000 Final Manuscripts Due: June 1, 2000 Publication Date: Fall 2000 SUBMISSION INSTRUCTIONS: Authors are requested to send e-mail to one or both of the Guest Editors (almeroth(a)cs.ucsb.edu, nonnen(a)research.bell-labs.com) giving a URL from where a postscript or PDF file can be downloaded. Successfully received papers will be acknowledged. AUTHOR INFORMATION: Submissions made to the special issue should not have appeared in, or been submitted to other archival publications. All papers will be subjected to the journal's usual refereeing process. ------- End of Blind-Carbon-Copy

1 0

Re: H 323 on corporate intranets
by Paul Long 17 Dec '99

17 Dec '99

Richard, You're right, this _is_ the wrong place! :-) These kinds of queries should be directed to, for example, the USENET newsgroup, comp.dcom.videoconf. You would get better user response, fewer vendor responses, and irritate a lot fewer people. Paul Long Smith Micro Software, Inc. -----Original Message----- From: Harkness, Richard C To: ITU-SG16(a)MAILBAG.INTEL.COM Sent: 12/16/99 2:21 PM Subject: H 323 on corporate intranets I am new to this site/list or whatever so please excuse me if I am in the wrong place for the following. Boeing wants to begin experimenting with VTC over IP. I want to talk with persons who have tried to implement H 323 video conferencing on their corporate intranet at rates of about 384 kbps. Anyone interested in sharing their experience please call Rich Harkness at (425) 865-4426. or repond by e-mail to: richard.c.harkness(a)boeing.com Leads to any other good sources (beside the VTC vendors) would be also appreciated. Thanks

1 0

Annex L Conference Call Minutes
by Dave Walker 17 Dec '99

17 Dec '99

Here are the minutes to the conference call that was held on Wednesday to discuss the H.323 Annex L stimulus protocol. My sincere thanks to all who participated! Attendees: Francois Audet, Orit Levin, Bob Gilman, Markku Korpi, Bob Callaghan, Vineet Kumar, Dave Walker 1. Positioning Annex L - H.450 should be described by what it can do, rather than what it can't do (as I did in the annotated agenda I sent out on Monday). It's main goal is networking interoperability, not providing all features required for PBX replacement. - H.323 provides some support for what are considered as supplementary services, such as identification services, call transfers, etc. It should be noted that use of Annex L may require that some "native" features, such as call id, may have undesirable interactions with the stimulus control and might have to be disabled. H.323 provides the basic call mechanism that is used by Annex L. - An extensive discussion of positioning with H.248 took place. It was suggested that the choice of H.248 or Annex L for features would be influenced by the implementation's point of departure. Gateway based implementations may have a preference for H.248, whereas Gatekeeper based implementations have a natural preference for Annex L. A prime goal is to keep H.248 line side packages and Annex L functionally similar. H.248 based endpoints tend to be unaware of call state. There was dissent among participants as to whether Annex L endpoints would be call state aware. H.323 currently allows a call to be established and used, as and when required, for multiple media connections. This permits an endpoint to initiate a call, signalling only, and to maintain it essentially forever; Annex L could be used to provide all other control. Analogies to existing systems can be made, however it was suggested that although H.323 may allow this, it is not necessarily desirable, especially from the point of interoperability. It was pointed out that endpoints which depend almost entirely on Annex L would need to be able to at least re-direct incoming Setup messages to their Gatekeeper in order to approach H.323 compliance. It was suggested that this issue be entirely removed from Annex L. While there was some concern that this would lead to implementation difficulty, the consensus seemed to support removal. - It was emphasized that we should strive for as much commonality with H.248 line side as possible. A highly desirable solution would be to simply reference the appropriate packages and specify the encoding mechanism to be used for H.323 stimulus. This would ensure future alignment. - It was agreed that H.323 Annex K is not intended to provide device control, its role is orthogonal to Annex L. WML transport can be provided by the generic tunnelling mechanism being developed for QSIG (H.323 Annex M). 2. Requirements - Everyone agreed that Unicode is needed. The issue is that both ends must realize that Unicode is being used. I suggested that support could be declared/configured using the management part of Annex L. An alternative is to use an escape code (0xff was suggested), which would indicate that the IE contains Unicode. This might require that we choose a flavour of Unicode - UTF-8 seems to be wildly popular. This discussion evolved into a discussion of the extensive use of "antique" ANSI escape sequences in the draft. - It was agreed that the level of complexity in the screen control section (3.1.1) of the draft was excessive. Endpoints which are capable of such sophistication should be capable of supporting some other protocol for display management. I suggested that only cursor positioning and erase capabilities were really required. This had some support until it was suggested that bandwidth is not at so much of a premium as in days of yore, so that a Gatekeeper requiring full control over a screen could simply re-write the entire display whenever it needed. This would require that Annex L point out that a Display IE always rewrites the entire screen. As Display IE is limited to 80 octets, which could be far fewer than 80 display characters depending on the flavour of Unicode, there may have to be some sort of continuation indicator. - The understandable preference for not being required to parse the entire Display IE was expressed. This led to a discussion of how other usages of Display in the current draft could be addressed. Specifically, how to control indicators. - Since the issue of adding support for (Q.932) Feature Activation and Feature Indication Information Elements was on the table, it was agreed that using FI to control indicators would be a cleaner solution that Display. However, a possible problem with this approach is that FA and FI are not supported in any version of H.225.0, so backwards compatibility would be compromised. There is a paragraph in H.225.0 which may allow earlier version EPs to use these IEs, but it is unclear. The paragraph, found in section 7.1, "Use of Q.931", states that "EPs may interpret and generate optional IEs defined below", but "also may interpret other IEs of ... other Q-series ... protocols". So interestingly, the word "generate" is missing from the second statement, so that EPs may not be permitted to generate FA and FI IEs, even if they are allowed to interpret them. On the other hand, the recommendation doesn't explicitly state that they may not be generated. Furthermore, it is unknown whether popular H.323 stacks support this. - The point was made that if we decide to pick up FA and FI, that it will not be sufficient to simply reference Q.932, rather Annex L will have to explicitly describe how and what these IEs are used for. In addition, the extent to which Annex L should explicitly list FA Feature Ids was uncertain, as was any view on re-using Ids already defined by other ITU recommendations. It was suggested that predefining a few could help ensure some degree of interoperability. This is the approach that has been followed for other encodings in Annex L, where a set of predefined elements is provided along with a mechanism for configuring nonstandard extensions. - FA/FI could be useful for replacing most, if not all, of the escape sequence mechanisms introduced into the Display and Keypad IEs. However, whether FI could be used to replace the currently suggested use of the Signal IE was not discussed. A Feature Id could be assigned to particular tone patterns, with the status value in the FI indicating whether the tone should be started or stopped. 3. Plans - We have to verify whether FA/FI are usable. This is certainly a way forward. I propose that minimal usage of Display and Keypad be maintained as an option, but significantly stripped down as described above. Allowing FA/FI has implications to the management part of the protocol. - The draft needs one or two usage examples illustrating how the procedures may be used. - Minimal requirements need to be defined. Optional functionality needs to be clearly described. There may be different levels of conformance: e.g. FA/FI, keypad/display, etc. Unless very carefully done, this will make it very difficult to ensure interoperability.

1 0

Re: [Robustness] Conference Call
by K. Jagannath Rao 17 Dec '99

17 Dec '99

very good! -----Original Message----- From: Kumar, Vineet [mailto:vineet.kumar@INTEL.COM] Sent: Friday, December 10, 1999 10:36 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: [Robustness] Conference Call i plan to attend. vineet -----Original Message----- From: Steve.Edgar(a)NOKIA.COM [mailto:Steve.Edgar@NOKIA.COM] Sent: Thursday, December 09, 1999 12:57 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: [Robustness] Conference Call The conference call for robustness, arranged by Maureen Stillman, is scheduled for Tuesday, December 14th at 11:00 AM EST USA. Conf call number: 613-688-2795 Access code 9234# Please send e-mail to maureen.stillman(a)nokia.com if you plan to attend. Failure scenarios will be discussed. Please send failure scenarios to the Study Group 16 mailing list.

1 0

H.323 Mobility: Updated MTD-06 (Functional Architecture Diagram)
by Jaakko Sundquist 17 Dec '99

17 Dec '99

Hi Ed & all, As was agreed I updated the H.323 Mobility Functional Architecture Diagram. The diagram is included in the document I'm sending. The document itself is an updated version of MTD-06, with some of the text (as well as the diagram) updated and the example scenarios taken out (as they did not make as much sense after the changes in the diagram). Please note also that on the first page of the document I have listed the companies that agreed on the diagram being a part of the Annex H draft. I was not quite sure which companies were present in the telephony conference, so I listed only those that I felt were surely there. If there is a mistake in the list, please let me and the Annex H editor, Mr. Martinez, know about it (and I apologize already beforehand for my mistake) and we will correct it. We should also probably have a discussion about the diagram in the mailing list. It seems to me that, especially if the Hinter interface is accepted, there may be some quite unnecessary interfaces in the diagram now... I will also upload the diagram to: ftp://standard.pictel.com/avc-site/Incoming/H323_Mobility/ Have a nice weekend (studying the wonderful possibilities of H.323 Mobility :-) <<MTD-06a.zip>> - Jaakko Sundquist ------------------------------------------------------- In a hole in the ground there lived a hobbit. Not a nasty, dirty, wet hole, filled with the ends of worms and an oozy smell, nor yet a dry, bare, sandy hole with nothing in it to sit down on or to eat: it was a hobbit-hole, and that means comfort. -------------------------------------------------------

1 0

H 323 on corporate intranets
by Harkness, Richard C 16 Dec '99

16 Dec '99

I am new to this site/list or whatever so please excuse me if I am in the wrong place for the following. Boeing wants to begin experimenting with VTC over IP. I want to talk with persons who have tried to implement H 323 video conferencing on their corporate intranet at rates of about 384 kbps. Anyone interested in sharing their experience please call Rich Harkness at (425) 865-4426. or repond by e-mail to: richard.c.harkness(a)boeing.com Leads to any other good sources (beside the VTC vendors) would be also appreciated. Thanks

1 0

Re: [Robustness] A couple comments on D.225
by Roy, Radhika R, ALARC 16 Dec '99

16 Dec '99

Hi, Offer and All: With respect to AT&T's proposal (D.225), 3Com's views can be summarized as follows: 1. Support distributed GK architecture (not the hierarchical model) 2. Treat the GK as a monolithic entity 3. Reduce the number of GK subcomponents into two categories: Registration/Pre-call (e.g., RAS) and Call Related issues (e.g., Q.931/932, H.245) If we are in agreement about those three items, we can start bringing follow-up contributions along those lines. With respect to hierarchical model, I'd like to point out that BEs that perform the "clearing house" functions work almost in a hierarchical fashion. If necessary, we can also examine whether the extension that will be made in H.323 protocol to enhance the reliability/robustness of the GK of the distributed model is also good for the hierarchical model. I also plan to attend the conf call on January 6. Happy Holidays and have a wonderful New Year!! Best regards, Radhika R. Roy, AT&T +1 732 420 1580 rrroy(a)att.com > -----Original Message----- > From: Offer Pazy [SMTP:Offer_Pazy@EUR.3COM.COM] > Sent: Wednesday, December 15, 1999 7:21 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: [Robustness] A couple comments on D.225 > > Hello, > > I hope that this is the right forum, procedure and timing for commenting > on the > D.225 document. If not, please use moderate flames only.... > > In general, I like the models presented and I think they serve a useful > starting > point. I would like to offer two simplifications: > > 1. Distributed Vs hierarchical architectures: > > I don't see the value of having a special hierarchical case. As suggested > in > D.225, we must avoid single point of failures. The node at the top of the > diagram (figure 7) is such a point unless we introduce redundancy for it > as > well. When we do so, we go back to the general distributed case where each > node > has a primary GK of a zone plus zero or more backup GKs for other zones. > My view > is that describing the model in this way is simpler than having two > distinct > cases, > > 2. D.225 proposes that the three internal "components" of a GK should be > exposed > and that redundancy mechanisms should be defined for them. I wonder if we > should > not keep this as an implementation issue. After all, GKs are defined in > H.323 as > containing all these three components and there was no intention (I > believe) to > force end-points to distinguish between a failed GK and the failure of one > of > its subcomponents. To formalize such granularity would require us to > answer > questions such as: What happens if the Q.931 component of GK A fails but > its > H.245 component is running OK, and the backup of the Q.931 of GK A resides > with > GK B whose RAS component has failed? Or, what happens when an endpoint is > registered with GK A but uses GK B (GK-routed) as the originating GK when > the > Q.931 component of A has failed? etc. etc. Clearly this is a complex > problem to > solve. > > Instead I believe we should concentrate on treating the GK as a monolithic > entity which 1) has fail-stop semantics and 2) a backup entity is backing > up the > GK as a whole as opposed to having a backup for each subcomponent. From > the > standard and protocols stand-point this will suffice. Clearly, > implementors > will have to invest efforts in designing their GK architectures in the > most > fault tolerant manner (and may use some of the ideas presented in D.225), > but > this should really be out of scope for the standard as long as the > semantics of > a failed GK are clearly defined. > > A slightly different way to look at the proposal in D.225 is to reduce the > number of GK subcomponents from three (RAS, Q.931, H.245) to two: > Registration > issues and "a particular call"-related issues. As can be noticed, this > idea does > not just decrease the granularity (which by itself simplifies things), but > also > shifts the focus of the model from that of an implementation view to a > more > behavioral view. It can be argued that H.323 endpoints already have to > distinguish between the registration process and failures and the process > of > call establishment and control. > > Offer

1 0

[Robustness] telecon scheduled - January 6, 2000
by Maureen Stillman 16 Dec '99

16 Dec '99

The next Robustness telecon is scheduled for January 6 at 11AM EST USA. Details on the conference bridge will be sent after the turn of the millenium. We made significant progress during our last telecon. I will send out the minutes by Monday, December 20. The topic for the next telecon is to review the draft submission which is the result of our last several discussions. Radvision will write the text for the submission and circulate it prior to the January 6 telecon. Please send me e-mail if you wish to join the telecon. Thanks. -- maureen Maureen Stillman Member of Scientific Staff Voice: (607)273-0724 x62 Nokia IP Telephony Fax: (607)275-3610 127 W. State Street Mobile: (607)227-2933 Ithaca, NY 14850 e-mail: maureen.stillman(a)nokia.com www.nokia.com

1 0