April 1998 - sg16-avd - lists.packetizer.com

Re: denial of service attacks for H.225.0 call signaling using TC P and UDP transport
by Moore, Mike 30 Apr '98

30 Apr '98

I enter this post with trepidation because I am but a lowly end user of products such as yours, certainly not qualifed to design software. I normally just lurk on the side learning what I can. This issue is near and dear to my job however, so I'm coming out today. If you want to sell product to end users won't you have to take into consideration most of us are installing firewalls that by definition block udp? I plan to replace as much private networking as I can with Internet services starting this year and for the forseeable future. I will not select a product or allow communication with a product that uses udp however. While this protocol was acceptable when my network was totally private, it is not acceptable for communications with unsecured networks, like the Internet no matter how feature rich or easy to implement. If you plan to market to customers like myself who want to communicate safely and privately over the Internet, how will you do this using udp? Mike > -----Original Message----- > From: Hal Purdy [SMTP:khp@RESEARCH.ATT.COM] > Sent: Thursday, April 30, 1998 1:35 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: denial of service attacks for H.225.0 call signaling > using TCP and UDP transport > > At the meeting in Yokosuka in April, two contributions were made which > proposed changes to how H.323 call signaling transport would be > accomplished, especially on IP networks. > > The first is APC-1351 authored by Jorg Ott, Gur Kimchi, and David > Gurle. > The other contribution, APC-1363, was made by Glen Freundlich. AT&T > had > two delegates in attendance, Rajiv Kapoor and Radhika Roy. Our two > delegates expressed security concerns about the signaling approach > suggested in APC-1351. > > I would like to elucidate what our concerns are. APC-1351 suggests the > use of a hybrid UDP/TCP based approach as a better (primarily faster) > way to do H.225.0 call signaling. As the authors point out, there are > some definite advantages to the use of UDP for call signaling. We do > have some concerns about the complexity of the approach since it > involves using both UDP and TCP during different stages of a given > call. > However, in this message I'd like to focus on the security concerns we > have which are based on the danger of "denial of service" attacks. > > Denial of service attacks are attacks whose aim is to attack a network > in such a way as to deny service to users of the network. One well > known > example of denial of service attacks are TCP SYN flood attacks which > attempt to prevent a server from being able to handle valid TCP > connection requests by flooding the server with invalid connection > attempts. A malicious party sends a voluminous number of the first > message in the TCP three-way handshake connection establishment to the > attacked server. This first message is known as a TCP SYN message. For > servers not hardened to this form of attack, the attack works for > several related reasons: 1) the queue size for the half-open > connection > queue was small (originally 5; later ~30) 2) the data structure > objects > which resided on this queue were sizable and thus limited in number > (because of general memory constraints) 3) a linear method was used to > search the queue. Consequently, servers attacked in this way either > ran > out of the data structure objects, ran out of queue space, and/or were > bogged down searching the queue. Fixes have been instituted in many > TCP > stacks to address all three of the above limitations. > > With that background, our concern about a UDP based approach for > handling H.225.0 messages is that a server (e.g. a Gateway or > Gatekeeper) could be overwhelmed with H.225.0 Setup messages and thus > be > unable to serve legitimate connection requests. Applying to H.323 call > signaling the knowledge gained in thwarting TCP SYN attacks, such > attacks can be prevented or at least mitigated by a careful design of > the portion of Q.931 state machine which deals with the initial > H.225.0 > Setup message. In particular, such a design must pay close attention > to > 1) the amount of state information stored when receiving a Setup > message, 2) the size of queues/tables/lists where such state > information > is stored, 3) the efficiency of the algorithms used to search those > queues/tables/lists upon fielding subsequent signaling events, and 4) > the efficiency of the methods used to recognize a particular Setup > message as bonafide, or conversely illegitimate. > > The trouble with using UDP packets to carry the H.225.0 Setup messages > is that each implementation of this portion of the Q.931 state machine > must pay close attention to the above design issues. As those of us > who > write software know, it often takes awhile to get these sorts of > things > right. The advantage of TCP based call signaling is that a great deal > of > thought and effort has already gone into defending against SYN flood > attacks, and thus, any Q.931 state machine implementation can benefit > from TCP stack implementations which incorporate the fixes. Please > understand that I'm not asserting that H.323 Terminals, Gateways and > Gatekeepers that use TCP for call signaling are impervious to denial > of > service attacks. There may be new such attacks that we'll need to be > careful of. I'm merely stating that a TCP based approach starts with > an > advantage in warding off denial of service attacks. > > The approach suggested in APC-1363 is to multiplex call signaling over > one (or a small number) of transport (e.g. TCP) connections. For > denial > of service attacks, this approach seems to have the further advantage > especially for GW to GK and GK to GK communication that the two > parties > to the transport connection can authenticate each other when the > connection is first brought up. Then, with some further (fairly > straightforward) protection against transport session hijacking, the > parties are assured of the legitimacy of the signaling received on > those > few transport connections. For this reason, we currently support the > approach outlined in APC-1363. Again, I'm not stating that these same > advantages can't be gained with a good connectionless design, but such > approaches can't take advantage of the store of knowledge already > embodied in good transport protocol implmentations. > > We are of course interested in an open discussion of this topic. I > would > be particularly interested to hear from H.323/GK/GW software providers > any insights they may have regarding the design of the Q.931 state > machine with respect to the design issues raised above. > -- > Hal Purdy khp(a)research.att.com > AT&T Laboratories w: (973) 360-8636 > 180 Park Avenue, Room C147 fax:(973) 360-8077 > Florham Park, NJ, 07932-0971

1 0

denial of service attacks for H.225.0 call signaling using TCP and UDP transport
by Hal Purdy 30 Apr '98

30 Apr '98

At the meeting in Yokosuka in April, two contributions were made which proposed changes to how H.323 call signaling transport would be accomplished, especially on IP networks. The first is APC-1351 authored by Jorg Ott, Gur Kimchi, and David Gurle. The other contribution, APC-1363, was made by Glen Freundlich. AT&T had two delegates in attendance, Rajiv Kapoor and Radhika Roy. Our two delegates expressed security concerns about the signaling approach suggested in APC-1351. I would like to elucidate what our concerns are. APC-1351 suggests the use of a hybrid UDP/TCP based approach as a better (primarily faster) way to do H.225.0 call signaling. As the authors point out, there are some definite advantages to the use of UDP for call signaling. We do have some concerns about the complexity of the approach since it involves using both UDP and TCP during different stages of a given call. However, in this message I'd like to focus on the security concerns we have which are based on the danger of "denial of service" attacks. Denial of service attacks are attacks whose aim is to attack a network in such a way as to deny service to users of the network. One well known example of denial of service attacks are TCP SYN flood attacks which attempt to prevent a server from being able to handle valid TCP connection requests by flooding the server with invalid connection attempts. A malicious party sends a voluminous number of the first message in the TCP three-way handshake connection establishment to the attacked server. This first message is known as a TCP SYN message. For servers not hardened to this form of attack, the attack works for several related reasons: 1) the queue size for the half-open connection queue was small (originally 5; later ~30) 2) the data structure objects which resided on this queue were sizable and thus limited in number (because of general memory constraints) 3) a linear method was used to search the queue. Consequently, servers attacked in this way either ran out of the data structure objects, ran out of queue space, and/or were bogged down searching the queue. Fixes have been instituted in many TCP stacks to address all three of the above limitations. With that background, our concern about a UDP based approach for handling H.225.0 messages is that a server (e.g. a Gateway or Gatekeeper) could be overwhelmed with H.225.0 Setup messages and thus be unable to serve legitimate connection requests. Applying to H.323 call signaling the knowledge gained in thwarting TCP SYN attacks, such attacks can be prevented or at least mitigated by a careful design of the portion of Q.931 state machine which deals with the initial H.225.0 Setup message. In particular, such a design must pay close attention to 1) the amount of state information stored when receiving a Setup message, 2) the size of queues/tables/lists where such state information is stored, 3) the efficiency of the algorithms used to search those queues/tables/lists upon fielding subsequent signaling events, and 4) the efficiency of the methods used to recognize a particular Setup message as bonafide, or conversely illegitimate. The trouble with using UDP packets to carry the H.225.0 Setup messages is that each implementation of this portion of the Q.931 state machine must pay close attention to the above design issues. As those of us who write software know, it often takes awhile to get these sorts of things right. The advantage of TCP based call signaling is that a great deal of thought and effort has already gone into defending against SYN flood attacks, and thus, any Q.931 state machine implementation can benefit from TCP stack implementations which incorporate the fixes. Please understand that I'm not asserting that H.323 Terminals, Gateways and Gatekeepers that use TCP for call signaling are impervious to denial of service attacks. There may be new such attacks that we'll need to be careful of. I'm merely stating that a TCP based approach starts with an advantage in warding off denial of service attacks. The approach suggested in APC-1363 is to multiplex call signaling over one (or a small number) of transport (e.g. TCP) connections. For denial of service attacks, this approach seems to have the further advantage especially for GW to GK and GK to GK communication that the two parties to the transport connection can authenticate each other when the connection is first brought up. Then, with some further (fairly straightforward) protection against transport session hijacking, the parties are assured of the legitimacy of the signaling received on those few transport connections. For this reason, we currently support the approach outlined in APC-1363. Again, I'm not stating that these same advantages can't be gained with a good connectionless design, but such approaches can't take advantage of the store of knowledge already embodied in good transport protocol implmentations. We are of course interested in an open discussion of this topic. I would be particularly interested to hear from H.323/GK/GW software providers any insights they may have regarding the design of the Q.931 state machine with respect to the design issues raised above. -- Hal Purdy khp(a)research.att.com AT&T Laboratories w: (973) 360-8636 180 Park Avenue, Room C147 fax:(973) 360-8077 Florham Park, NJ, 07932-0971

1 0

Re: No subject given
by Marty Wells 30 Apr '98

30 Apr '98

Please do not SPAM on this channel!

1 0

None
by Q4224＠HOTMAIL.COM 29 Apr '98

29 Apr '98

Please take 2 minutes of your time to read this letter and consider what it says. Like the instructions say, read it, print it, then read it again! thank you $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ This is a LEGAL, MONEY-MAKING PHENOMENON. PRINT this letter, read the directions, THEN READ IT AGAIN !!! You are about to embark on the most profitable and unique program you may ever see. Many times over, it has demonstrated and proven its ability to generate large amounts of cash. This program is showing fantastic appeal with a huge and ever-growing on-line population desirous of additional income. This is a legitimate, LEGAL, money-making opportunity. It does not require you to come in contact with people, do any hard work, and best of all, you never have to leave the house, except to get the mail and go to the bank! "This truly is that lucky break you've been waiting for! Simply follow the easy instructions in this letter, and your financial dreams can come true! When followed correctly, this electronic, multi-level marketing program works perfectly...100% EVERY TIME!" Thousands of people have used this program to: - Raise capital to start their own business - Pay off debts - Buy homes, cars, etc., - Even retire! "This is your chance, so don't pass it up!" ---------------------------------------------------------------------------------- OVERVIEW OF THIS EXTRAORDINARY ELECTRONIC MULTI-LEVEL MARKETING PROGRAM ---------------------------------------------------------------------------------- Basically, this is what we do: We send thousands of people a product for $5.00 that costs next to nothing to produce and e-mail. As with all multi-level businesses, we build our business by recruiting new partners and selling our products. Every state in the U.S. allows you to recruit new multi- level business online (via your computer). The products in this program are a series of four business and financial reports costing $5.00 each. Each order you receive via "snail mail" will include: * $5.00 cash * The name and number of the report they are ordering * The e-mail address where you will e-mail them the report they ordered. To fill each order, you simply e-mail the product to the buyer. THAT'S IT! The $5.00 is yours! This is the EASIEST electronic multi-level marketing business anywhere! FOLLOW THE INSTRUCTIONS TO THE LETTER AND BE PREPARED TO REAP THE STAGGERING BENEFITS! ******* I N S T R U C T I O N S ******* This is what you MUST do: 1. Order all 4 reports shown on the list below (you can't sell them if you don't order them). * For each report, send $5.00 CASH, the NAME & NUMBER OF THE REPORT YOU ARE ORDERING, YOUR E-MAIL ADDRESS, and YOUR RETURN POSTAL ADDRESS (in case of a problem) to the person whose name appears on the list next to the report. * When you place your order, make sure you order each of the four reports. You will need all four reports so that you can save them on your computer and resell them. * Within a few days you will receive, via e-mail, each of the four reports. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you. 2. IMPORTANT-- DO NOT alter the names of the people who are listed next to each report, or their sequence on the list, in any way other than is instructed below in steps "a" through "d" or you will lose out on the majority of your profits. Once you understand the way this works, you'll also see how it doesn't work if you change it. Remember, this method has been tested, and if you alter it, it will not work. a. Look below for the listing of available reports. b. After you've ordered the four reports, replace the name and address under REPORT #1 with your name and address, moving the one that was there down to REPORT #2. c. Move the name and address that was under REPORT #2 down to REPORT #3. d. Move the name and address that was under REPORT #3 down to REPORT #4. e. The name and address that was under REPORT #4 is removed from the list and has NO DOUBT collected a very large sum of money. Please make sure you copy everyone's name and address ACCURATELY!!! 3. Take this entire letter, including the modified list of names, and save it to your computer. Make NO changes to the instruction portion of this letter. 4. Now you're ready to start an advertising campaign on the WORLDWIDE WEB! Advertising on the WEB is very, very inexpensive, and there are HUNDREDS of FREE places to advertise. Another avenue which you could use for advertising is e-mail lists. You can buy these lists for under $20/2,000 addresses or you can pay someone a minimal charge to take care of it for you. BE SURE TO START YOUR AD CAMPAIGN IMMEDIATELY! 5. For every $5.00 you receive, all you must do is e-mail them the report they ordered. THAT'S IT! ALWAYS PROVIDE SAME-DAY SERVICE ON ALL ORDERS! This will guarantee that the e-mail THEY send out, with YOUR name and address on it, will be prompt because they can't advertise until they receive the report! ------------------------------------------ AVAILABLE REPORTS ------------------------------------------ ***Order Each REPORT by NUMBER and NAME*** Notes: - ALWAYS SEND $5 CASH FOR EACH REPORT - ALWAYS SEND YOUR ORDER VIA FIRST CLASS MAIL - Make sure the cash is concealed by wrapping it in at least two sheets of paper - On one of those sheets of paper, include: (a) the number & name of the report you are ordering, (b) your e-mail address, and (c) your postal address. _________________________________________________________________ REPORT #1 "HOW TO MAKE $250,000 THROUGH MULTI-LEVEL SALES" Q4224 P.O. Box 5085 Hickory, NC 28603 ORDER REPORT #1 FROM: _________________________________________________________________ REPORT #2 "MAJOR CORPORATIONS AND MULTI-LEVEL SALES" BTL P.O. Box 1104 Ft. Gibson, OK 74434 ORDER REPORT #2 FROM: _________________________________________________________________ REPORT #3 "SOURCES FOR THE BEST MAILING LISTS" Pulse Web Ventures P.O. Box 2577 Muskogee, OK 74402 ORDER REPORT #3 FROM: _________________________________________________________________ REPORT #4 "EVALUATING MULTI-LEVEL SALES PLANS" KBL P.O. Box 624-4960 Irvine, CA 92616-4960 ORDER REPORT #4 FROM: ____________________________________________________________ ---------------------------------------------------------------- HERE'S AN EXAMPLE OF HOW THIS AMAZING PLAN CAN MAKE YOU $MONEY$ ---------------------------------------------------------------- Let's say you decide to start small just to see how well it works. Assume your goal is to get 10 people to participate on your first level. (Placing a lot of FREE ads on the internet will EASILY get a larger response.) Also assume that everyone else in YOUR ORGANIZATION gets ONLY 10 downline members. Follow this example to achieve the STAGGERING results below. 1st level--your 10 members with $5............................$50 2nd level--10 members from those 10 ($5 x 100)...............$500 3rd level--10 members from those 100 ($5 x 1,000)..........$5,000 4th level--10 members from those 1,000 ($5 x 10,000)......$50,000 THIS TOTALS --------------------------------------------->$55,550 Remember friends, this assumes that the people who participate only recruit 10 people each. Think for a moment what would happen if they got 20 people to participate! Most people get 100's of participants! THINK ABOUT IT! Your cost to participate in this is practically nothing (surely you can afford $20). You obviously already have an internet connection and e-mail is FREE!!! REPORT#3 shows you the most productive methods for bulk e-mailing and purchasing e-mail lists. Some list & bulk e-mail vendors even work on trade! About 250,000 new people get online every month, just on one service alone! *******TIPS FOR SUCCESS******* * TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and follow the directions accurately. * Send for the four reports IMMEDIATELY so you will have them when the orders start coming in because: When you receive a $5 order, you MUST send out the requested product/report to comply with the U.S. Postal & Lottery Laws, Title 18,Sections 1302 and 1341 or Title 18, Section 3005 in the U.S. Code, also Code of Federal Regs. vol. 16, Sections 255 and 436, which state that "a product or service must be exchanged for money received." * ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE. * Be patient and persistent with this program. If you follow the instructions exactly, the results WILL undoubtedly be SUCCESSFUL! * ABOVE ALL, HAVE FAITH IN YOURSELF AND KNOW YOU WILL SUCCEED! *******YOUR SUCCESS GUIDELINE******* Here are some guidelines to follow that can better guarantee your success: If you don't receive 10 to 20 orders for REPORT #1 within two weeks, continue advertising until you do. Then, a couple of weeks later you should receive at least 100 orders for REPORT #2. If you don't, continue advertising until you do. Once you have received 100 or more orders for REPORT #2, YOU CAN RELAX, because the system is already working for you, and the cash will continue to roll in! THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down on the list, you are placed in front of a DIFFERENT report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. If you want to generate more income, send another batch of e-mails (500,000 or more) and start the whole process again! There is no limit to the income you will generate from this business! You can also ask a qualified bulk e-mailer for tips on what is working the best. Find out if he or she is participating in the program. NOTE: If you need help with starting a business, registering a business name, how income tax is handled, etc., contact your local office of the Small Business Administration (a Federal agency) for free help and answers to questions. Also, the Internal Revenue Service offers free help via telephone and free seminars about business taxes. *******T E S T I M O N I A L S******* This program does work, but you must follow it EXACTLY! Especially the rule of not trying to place your name in a different position, it won't work and you'll lose a lot of potential income. I'm living proof that it works. It really is a great opportunity to make relatively easy money, with little cost to you. If you do choose to participate, follow the program exactly, and you'll be on your way to financial security. Sean McLaughlin, Jackson, MS My name is Frank. My wife, Doris, and I live in Bel-Air, MD. I am a cost accountant with a major U.S. Corporation and I make pretty good money. When I received the program I grumbled to Doris about receiving "junk mail." I made fun of the whole thing, spouting my knowledge of the population and percentages involved. I "knew" it wouldn't work. Doris totally ignored my supposed intelligence and jumped in with both feet. I made merciless fun of her, and was ready to lay the old "I told you so" on her when the thing didn't work... well, the laugh was on me! Within two weeks she had received over 50 responses. Within 45 days she had received over $147,200 in $5 bills! I was shocked! I was sure that I had it all figured and that it wouldn't work. I AM a believer now. I have joined Doris in her "hobby." I did have seven more years until retirement, but I think of the "rat race" and it's not for me. We owe it all to MLM. Frank T., Bel-Air, MD I just want to pass along my best wishes and encouragement to you. Any doubts you have will vanish when your first orders come in. I even checked with the U.S. Post Office to verify that the plan was legal. It definitely is! IT WORKS!!! Paul Johnson, Raleigh, NC The main reason for this letter is to convince you that this system is honest, lawful, extremely profitable, and is a way to get a large amount of money in a short time. I was approached several times before I checked this out. I joined just to see what one could expect in return for the minimal effort and money required. To my astonishment, I received $36,470.00 in the first 14 weeks, with money still coming in. Sincerely yours, Phillip A. Brown, Esq. Not being the gambling type, it took me several weeks to make up my mind to participate in this plan. But conservative that I am, I decided that the initial investment was so little that there was just no way that I wouldn't get enough orders to at least get my money back. Boy, was I surprised when I found my medium-size post office box crammed with orders! For awhile, it got so overloaded that I had to start picking up my mail at the window. I'll make more money this year than any 10 years of my life before. The nice thing about this deal is that it doesn't matter where in the U.S. the people live. There simply isn't a better investment with a faster return. Mary Rockland, Lansing, MI I had received this program before. I deleted it, but later I wondered if I shouldn't have given it a try. Of course, I had no idea who to contact to get another copy, so I had to wait until I was e-mailed another program... 11 months passed then it came...I didn't delete this one!...I made more than $41,000 on the first try!! D. Wilburn, Muncie, IN This is my third time to participate in this plan. We have quit our jobs, and will soon buy a home on the beach and live off the interest on our money. The only way on earth that this plan will work for you is if you do it. For your sake, and for your family's sake don't pass up this golden opportunity. Good luck and happy spending! Charles Fairchild, Spokane, WA ORDER YOUR REPORTS TODAY AND GET STARTED ON YOUR ROAD TO FINANCIAL FREEDOM!!!

1 0

H.243 revision decided in March 97
by Li Yan 29 Apr '98

29 Apr '98

Dear Mr. Okubo and Mr. Thom, Where can I find the newest H.243 document? I cannot find it in nither DraftRec/ nor 9703_Gen/ in ftp://standard.pictel.com/avc-site/. By the way, is the revision decided in March 97 the newest one? Thanks. I really appreciate your help! Li Yan **************************************************************** Lucent Technologies Phone: 732-957-3877 2E-433, 200 Laurel Ave., Fax: 732-957-5627 Middletown, NJ, 07733 E-amil:lyan@lucent.com U.S.A. ****************************************************************

1 0

Draft report of the Yokosuka meeting
by Sakae OKUBO 29 Apr '98

29 Apr '98

Dear Q.12-14 colleagues, I have placed APC-1372 (report if the Yokosuka meeting) at: ftp://standard.pictel.com/avc-site/Incoming/APC-1372.zip Please review it and return your comments, if any, in a week time. Then I will move it to /9804_Yok. I have a little belatedly edited TD-24, TD-16, TD-17, TD-18 and other relevant TDs. Note to Mr. Skran: I took my liberty to move the text regarding H.323 Annex G terms of reference to Annex 9 and changed "fixed capability terminals" to "single use devices" in the list of possible future works (Item 15 in Section 5.6.1.2). Best regards, Sakae OKUBO GCL Tel: +81 3 5351 0181 Fax: +81 3 5351 0184 e-mail: okubo(a)gctech.co.jp

1 0

H.332 and H.323 Annex D white papers on ftp site
by Kumar, Vineet 23 Apr '98

23 Apr '98

Dear H.323 Colleagues: I have uploaded the H.323 Annex D, and H.332 white papers in the Incoming directory of the PictureTel web site. The files are: h332-white-final-dls.doc - H.332 white paper; additions are RFC # for SDP, and a statement on using the back-off algorithm for the BYE message. h323-annexD-wht-chg.doc - H.323 Annex D with change marks h323-annexD-wht-nchg.doc - H.323 Annex D with no change marks Please review the documents and provide any comments. vineet ----------------------------------------------------------- Vineet Kumar Intel Corporation, JF3-212 2111 NE 25th Avenue Hillsboro, OR 97124-5961 (+1) 503-264-3439 (phone) (+1) 503-264-3375 (fax)

1 0

FW: VoIP Numbering Plan Vs. Domain names. IPNP
by Tom-PT Taylor 23 Apr '98

23 Apr '98

There was a flurry of discussion on the IPTEL list this morning about VoIP addressing and the like. This message was forwarded as part of the discussion. > SEE Below... Please contact me or Anne Brown <Anne.Brown.arbrown(a)nt.com > <mailto:Anne.Brown.arbrown@nt.com> > of Nortel directly .... your timing > is > excellent. > The IETF AD took 164 resolution off the agenda for IPTEL since they > thought > IPTEL bit off more than it could chew. > > > > To All, > > This correspondence is to invite you to participate in a work group, > April 27, 98 in Anaheim, CA to establish an Internet Telephony Directory > solution and service. Directory is the keystone to scalability and > interconnection of Internet Telephony services. The promise of Internet > Telephony cannot be realized unless there is a serious and realistic > effort to develop and deploy a global trusted Internet Directory scheme > for the Telephony Domain. And this will not happen without the > cooperation > of the major players from the beginning. > At the next Electronic Messaging Association (EMA) meeting, the Internet > Telephony Directory (ITD) Pilot Working Group will discuss solutions for > an ITD framework. A deliverable of the WG will be an Internet draft to > be proposed to the IETF as a standards track RFC. A second deliverable > will > be the establishment of a pilot service, perhaps run by a trusted > third-party. The proposed draft which comes out of EMA will be used to > launch an IETF WG at the next IETF meeting. > You need not be a member of EMA to attend this first WG meeting but you > must > register. Attendance for committee meetings is free. > Besides agreement to work toward a common solution, this WG also requires > commitment form interested parities to contribute and/or prime these > deliverables. Participants should be prepared to discuss deliverables and > should be in a position to go back to their respective companies to > solicit > commitment to work toward a common solution and to commit resources. > The following companies have thus far expressed an interest in this > initiative: > Lucent > Microsoft > Cisco > Intel > VocalTec > Nortel > > Please pass this invitation on to others whom you feel should be involved > in > this work. > This work is being done in the EMA because the ITD problem is 1% > technical and 99% commercial and political. Also the requirement for a > pilot makes it outside the scope of the IETF. The initial Internet draft > proposal and service pilot will be developed via at face-to-face meetings > at > EMA, which supports technical and marketing streams. This work is not > being > done in application specific forums because it is outside of the scope of > voice over IP, Internet fax, voice messaging, vpn, conferencing or other > Internet Telephony applications. > Attached is the WG charter and meeting details. Richard Shockey’s > “Internet > Telephony Domain Service: A Business Case for Action” will also be sent to > this list shortly, along with “ ITD: Overview of the Proposed EMA Pilot > WG”. > Regards, > Anne Brown (Nortel) > ITD Pilot Working Group Chair, EMA > ************************************************************************* > > Charter: Internet Telephony Directory Pilot Working Group > Description: > End-users are faced with a wide variety of telephony applications with > overlapping directory needs. The most common being the ability to locate > address information for a targeted recipient, given only a telephone > number. > The goal of this work effort is to evaluate in a pilot, existing directory > standards-based solutions. > The pilot will provide direct feedback to vendors, service providers, and > standards developers about what approaches are effective and which need to > be changed. The pilot will also provide information to corporations about > how to best plan, deploy and use directories in the telephony area and how > to reduce their costs and risks. > Scope: > Note that this group is not solving routing problems. Nor is it > defining any particular Internet Telephony service. What it will do is > define an ITD framework to support the retrieval of destination address > and > additional service-specific information such as supported capabilities. > Users and applications should not have to know anything but the E.164 > telephone number in order to obtain this information. > The individual directory schemas, which will define which attributes are > used for which Internet Telephony services, are outside the scope of > this WG. Each directory schema will be defined in the group or forum > that is tasked with defining standards for that particular service. For > example, the voice messaging directory schema < > draft-ema-vpimdir-schema-00.txt.> was defined in EMA. The schema for > Internet fax will most likely be defined in the fax working group of the > IETF. > The trial service will allow the exploration of governance and > administration issues. > Deliverables: > An RFC, describing an ITD framework, for proposal as an Internet-Draft for > IETF standards track. > A pilot service, perhaps through tender, to prove the concept and to > address > various issues including: > * Allowing users to administer a single directory structure used by > multiple applications > * Simplified provisioning of shared directories > * Security > > Time frame: > The work group will start in April, 98 and will propose a pilot to be > conducted in the Summer and Fall of 1998 and to be completed by the end > of the year. The RFC final should result, at the end of the year, both > from lessons learned from the pilot and from feedback from the IETF WG. > Q and A: > Below are several relevant questions and answers raised during early > discussions: > Q. Why is the Voice Messaging Committee examining this kind of issue? > A. For the same reason that the EMA was a good place for Voice Messaging > to be moved into the broader messaging framework. The Voice Messaging > Committee will allow participants develop issues specific to > telecommunications and Internet telephony. Once these are better > understood, > the EMA forum will allow discussions between end-users and vendors with a > wide variety of messaging, security, and directory backgrounds. > Q. How is this different from the VPIM directory effort? > A. The VPIM directories effort has developed a schema and a shared > directory pilot focused on voice messaging. VPIM directories are only > one part of the broader Internet telephony and telecommunications > directory picture. This work group would examine directories from a much > broader perspective. > Q. Isn’t this already being done in other telephony groups? > A. There are groups such as the Voice over IP forum and the ???. It is > anticipated that the Voice Messaging Committee will liaise with these > groups and will formulate joint efforts as needed. However, the EMA is a > very good place to start this directory discussion as it applies to > corporations and to issues beyond those related to specific IP protocols. > Q. Who would be participating? > A. Participation is open. It is likely that vendors and service > providers would provide the initial effort to get the pilot defined and > initiated. At that point it is hoped that corporations would participate > in the pilot both as sites and for evaluations, comment and feedback. > Q. What is the Voice Message Committee Charter? > A. The EMA Voice Messaging Committee facilitates the integration of voice, > telephony, and CTI with other messaging media. This Committee will > address > the enhanced interoperability of voice based applications by building > consensus and encouraging standards for voice based platforms. This > committee will also represent the voice and telephony technology issues in > the general work of the EMA. > > ***************************** > Meeting Details > Monday, April 27, 98 > Time to be announced. > You need not be a member of EMA to attend this first WG meeting. > Meeting Details: > Anaheim Marriott > Orange County Ballroom, Salons 1-4 > Anaheim, CA > > The Anaheim Marriott is across the street from the Anaheim Hilton and the > Anaheim Convention Center—site of EMA’98. > Committee meeting attendance is FREE to employees of EMA member > companies, but you must reserve your place by returning the Committee > registration form <http://www.ema.org/html/at_work/committe/regform.htm > <http://www.ema.org/html/at_work/committe/regform.htm> > > to EMA by Monday, April 20 to ensure that you can participate. Please > Note: > Committee meeting registration is completely separate from EMA’98 > registration. > For more details see < > http://www.ema.org/html/at_work/committe/cwgmeet.htm> > <http://www.ema.org/html/at_work/committe/cwgmeet.htm>> . > For more information about EMA Committees, see < http://www.ema.org/ > <http://www.ema.org/> > or > contact: > Paul Moniz, Vice President, > (Tel. 703/524-5550 x. 231 or Internet: paul.moniz(a)ema.org > <mailto:paul.moniz@ema.org> , X.400: G=paul; S=moniz; O=ema; A=mci; C=us) > Electronic Messaging Association > 1655 North Fort Myer Drive, Suite 500 > Arlington, VA 22209 > T: 703/524-5550 F: 703/524-5558 > > > ####################### > > > Internet Telephony Domain Service > A Business Case for Action > April 1, 1998 > > > Richard Shockey > 8045 Big Bend Blvd > Suite 110 > St. Louis, MO > Voice 314.918.9020 > Fax 314.918.9015 > Mail rshockey(a)ix.netcom.com <mailto:rshockey@ix.netcom.com> > > > > > > Historical Introduction > Over the past several years it has been manifestly self evident that > traditional telephony applications such as voice and fax can be > transported > over public and private packet routed networks [The Internet] in parallel > to > the General Switched Telephone Network [GSTN]. Hundreds of new products > and > services have been developed and introduced to make Internet Telephony a > reality. Tens of millions of dollars in Research and Development funds > have > been spent by technology companies creating a comprehensive suite of > standards and processes to enable wide spread deployment. > The promise of Internet Telephony cannot be realized unless there is a > serious and realistic effort to develop and deploy a global trusted > Internet > Directory scheme for the Telephony Domain. > Internet Telephony must be made as transparent and as easy to use as > traditional analog phone calling. Internet Telephony must be able to > promise advanced services, such as video and not just toll avoidance > As it stands now there is no practical method by which a individual can > place a Internet Telephone Call using a GSTN phone number that crosses > Internet domains. Internet Telephony cannot scale on either a wide area or > global basis. > Major corporations and institutions have spent billions of dollars > deploying > TCP/IP networks for both internal and wide area applications. Major > service > providers including current ILEC’s and CLEC’s and PTT authorities are > looking to deploy advanced service offerings based on TCP/IP networking. > There is a strong desire to optimize the return on investment on these > networks as well as provide advanced communications services currently > unavailable on analog based GSTN networks. The Problem... > With all of the work that has been done in developing standards and > interoperability processes within the Internet Telephony industry a major > problem has been left undone. > How do you locate an Internet Telephony user and identify what resources > are > available to that user? > Telephony addressing has always been numeric in nature, unlike Internet > applications which rely on easy to understand and remember character based > names, such as www.telephony.com <http://www.telephony.com> . Internet > applications have always relied on PC or other terminals that have 101 > character keyboards or other similar devices. > There are literally hundreds of millions of “terminals”, namely telephone > key sets that do not have keyboards. There should be a way to > transparently > permit these devices to access IP related services, principally real time > voice, fax or video like services. > This author is reminded of the famous scene in the movie 2001 where the > director of the space agency Heywood Floyd, while stopping over on the > space > station places a video phone call to his family. He used nothing more that > a > traditional 12 button telephone key pad to complete the call. Why not > make > these services available NOW! > > All of technical pieces of the puzzle are in place except one. > The Market > It should be noted that some estimates by NationsBanc Montgomery > Securities > and the Frost and Sullivan research firm have indicated the IP telephony > market place could grow to 2.5 billion dollars within 3 years. This is a > substantial number, even though technology industry market research is > notoriously suspect. > This potential market could be impaired if Internet Telephony is not made > as > simple and transparent to use as traditional telephony. > It is useful to note again that Internet Telephony is not just about toll > avoidance. There will be toll savings to institutions and enterprises over > the short term, however it is the ability to deliver advanced telephony > services such as video, color fax or easy to set up conference calling > that > is the ultimate goal of this technology as well as unify the management of > networks across the enterprise. > The Solution > A system must be devised to allow any Internet Telephony Application > [Voice. > Fax, Video, etc] application to “resolve” the address of the Internet > Telephony user or resource using nothing more that a GSTN number to place > the call. > This requirement demands that an independent trusted 3rd party Internet > Telephony Directory Service [IDTS] must be developed, deployed and > maintained to service the upper level infrastructure of telephony related > applications. > There are several possible approaches to the problem including LDAP/X.500 > and DNS. > What is lacking is the specific plan to achieve a solution and the > commitment of major industry players to deploy a working experiment. It > is > the opinion of this author that of all the possible approaches, the > technology of the existing DNS system offers a proven and scaleable > solution. > What the Solution is NOT! > Many attempts and proposals have been made over the past several years to > look at Internet Directory services, IMHO these proposals have been much > too > expansive in scope. They have attempted to “End World Hunger”, so to > speak. > They have not focused on the specific needs of a single application such > as > telephony. > > ] > The ITDS is not a “Universal Telephony Directory Assistance” or “White > Pages”. It is nothing more and nothing less than a method to resolve the > “telephony service address” and discover user capabilities based on the > knowledge of a GSTN number. > For instance: > 13149189020 resolves to > gate.domain.com and/or ldap.domain.com or > john.smith(a)domain.com <mailto:john.smith@domain.com> . > The use of LDAP in this example could offer real time telephony > applications > the OPTION of sending an SMTP voice-fax-video message or set up a session > based service. > Comprehensive directory services raise serious questions of individual > privacy and security that must be taken into account in the selection of > any > technology that addresses this problem. Issues of interoperability or > settlements among providers are considered out of scope for this proposal. > The Task > In order to preserve ,protect and defend the investments the technology > industry has made in Internet Telephony, advance the state of the art and > grow the market for these services, collective action must be taken now to > develop ITDS. > It is the belief of this author that the effort must be based on the > common > agreements of several select companies with serious economic interests in > this area. Only those companies with significant financial and personnel > resources to commit to the task should be directly involved in the early > stages of development. > Significant questions must be sorted out. Agreement and concessions by > known competitors will have to be made. > The Organization > Decisions need to be made quickly on what should be the proper “home” for > such a effort. There are many alternatives. Clearly standards work would > proceed through traditional venues such as the IETF or ITU. Actual > sponsorship of a experimental ITDS root system might be though an > organization such as the EMA but for practical as well as legal matters > it > is suggested that 2 not for profit legal entities be set up. One in > Canada > and one in the United States to share responsibility for an experimental > server system and eventually take over the responsibility of > administration > for a ITDS for the North American Numbering Plan area [ 1 ] It would be > anticipated that entities wishing to participate in the experimental > servers > system would manage numbers within their own national country codes or > zones > [Britain - 44, Japan -77, etc] > The Politics > There should be no illusion in any ones mind that this effort, especially > if > it is supported by major industry participants will immediately come under > public and political scrutiny by the technology industry and governments. > The establishment of, for that matter, even the suggestion of an effort to > establish of any form or alternative application specific root system on > the > Internet carries risk. It should be noted that there continues to be a > legal > and technical uproar that surrounding the Top Level Domain administration > of > the Internet and the administration of .COM by Network Solutions, Inc. > under > its contract to the National Science Foundation by the authority on the > IANA. > Should the task of setting up a experimental ITDS be successful it will be > inevitable that the developers of such a system seek ...indeed demand some > form of legal sanction from appropriate regulatory authorities. It is the > opinion of this author that the eventual settlement of the tldDNS issue > may > provide an appropriate model to recommend for long term ITDS governance as > well. > > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > Richard Shockey > 8045 Big Bend Blvd. Suite 110 > St. Louis, MO 63119 > Voice 314.918.9020 > Fax 314.918.9015 > INTERNET Mail & IFAX : rshockey@i <mailto:rshockey@ix.netcom.com> > x.netcom.com > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > --------- > This message came from the IETF IPTEL Working Group Mailing List.

1 0

Fwd: sourceInfo in H.225.0 Setup message
by Chris Purvis WVdevmt-WS 23 Apr '98

23 Apr '98

All, I'm resending this (originally sent it to the h323 implementors list) and forwarding it additionally to other people in the hope of getting a reply! If anybody is using this field for anything at all, PLEASE tell me what you want in it! My apologies to those on multiple lists, who will receive this multiple times, but I could really do with some responses and didn't get any from the obvious list! Chris ------------------------------------- All, What purpose do the sourceInfo and destinationInfo fields have in H.225.0 messages such as Setup and Alerting? The description in H.225.0 says that it "contains an EndpointType to allow the called party to determine whether the call involves a gateway or not". The specific questions that arise are: 1) What difference does it make? Why does anybody care whether there's a gateway in the call? 2) What information do vendors intend to supply in any of the gatewayInfo, terminalInfo or mcuInfo fields in the EndpointType? I note that only the gatewayInfo field has standard parameters defined, which allows you to specify what protocol you're gatewaying to. Whilst this might be useful information to supply in registrations with a gatekeeper, how does it help an endpoint in the call signalling phase? 3) What is the "correct" procedure for a gatekeeper that is routing these messages (or a proxy, come to that)? Should it a) Pass these fields through unchanged? b) Put in its own information instead of what's already there? (i.e. build a new EndpointType element with GatekeeperInfo supplied and filling in the vendor field with vendor information for the gatekeeper) or c) Add its own information to what has already been supplied? Note that, bearing in mind that the call may easily be routed by two gatekeepers - even without any enhancements to interGK communication - this means that only information from the destination endpoint's gatekeeper will be present? Again, should the vendor information within the EndpointType SEQUENCE be that of the GK, or whatever was supplied by the original calling entity? Chris ---------------------------------------- Dr Chris Purvis - Senior Development Engineer, WAVE CC Software Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. Phone:+44 1753 661359 email: cpurvis(a)madge.com

1 0

Photos of Yokosuka Meeting
by Hidenobu Harasaki 23 Apr '98

23 Apr '98

Dear Yokosuka meeting participants, and Mr. Webber, I have uploaded pictures.tar to avc-site/Incoming. The file contains 55 shots taken by a digital camera at Yokosuka Rapporteur meeting site and welcome party restaurant. Mr. Webber, would you please extract pictures from the tar archive? Mr. Campos-Neto, "conference.jpg" is the shot that you requested. The shot shows how we set up 10Base-T hubs in a meeting room. Best regards, Hidenobu Harasaki harasaki(a)ccm.CL.nec.co.jp Principal Researcher C&C Media Research Labs., NEC Corporation Phone: +81 44 856 8083 Fax: +81 44 856 2232

2 1

PLEASE REVIEW: meeting report Q13, revised TD-14, TD-15 upload to ftp site
by Dale L. Skran 21 Apr '98

21 Apr '98

Yokosuka meeting attendees: I have just uploaded to the incoming directory of ftp site the following documents: td-14-sg8-annxB-liaision-v2-chgs-accepted.doc the doc below with changes accepted td-14-sg8-annxB-liaision-v2.doc change marks showing changes discussed on the final day of the meeting td-15-revised-chgs-accep-323 annex D.doc the doc below with changes accepted td-15-revised-323 annex D.doc change marks showing changes discussed on the final day of the meeting td-17-yokosuka-v2.doc revised Q13 meeting notes with change marks Please review all these documents and send your comments to the mailing list. I would like to finalize the meeting report this week, and recall that we have a May 11 white paper deadline for H.323 Annex D. URGENT ISSUE: In the meeting report, I note a problem with forward references in T.38 Annex B to H.245 version 5 (and also in H.323 Annex D even if it was delayed). As you recall, at the meeting we decided to move the T.38 related changes from V4 to V5; I believe that this was over-hasty and that the changes should go in the H.245 V4 white paper. Comments? Dale Skran Q13 Rapporteur

2 1

add to list
by Randy Pope 21 Apr '98

21 Apr '98

Randy_Pope(a)stg.sel.sony.com

2 1

(no subject)
by Liang Jun Ming 19 Apr '98

19 Apr '98

I'm a student of FuDan University,Shanghai,China. I want to get some information and application on T.105(SBV Application Layer Protocol and BIS). Could you give me some advice? I appreciate for your lift!

1 0

Documentation of the Yokosuka meeting
by Sakae OKUBO 19 Apr '98

19 Apr '98

Dear Q.12-14 colleagues, All the APC-numbered documents and Temporary Documents are now avialable at ftp://standard.pictel.com/avc-site/9804_Yok/. 9804_Yok.html is their index. Please note, however, that some output TDs such as meeting report of each Question need be revised to incorporate the discussion at the closing session last Friday. They will be uploaded with indication such as r, r1, ... Please also note that APC-1372 will be the integrated meeting report assembling TD-24(general), TD-16(Q.12), TD-17(Q.13), TD-18(Q.14). Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151-0053 Japan or okubo(a)mxz.meshnet.or.jp ********************************************************************

1 0

June meeting date
by Joerg Ott 16 Apr '98

16 Apr '98

Toby, TD-1 of this meeting specifies 8-11 June in Cannes. I haven't heard anything during this week that this should change (again). Joerg At 12:32 15.04.98 -0700, you wrote: >Do we have definite dates and location for the June Q12-14 meeting? > > -- Toby >___________________________________________________________ >Toby L. Nixon, Senior Business Development Manager >Microsoft Corporation, ICU - OEM & SI Group >One Microsoft Way, Redmond WA 98052 USA >+1 (425) 936-2792 Fax: +1 (425) 936-7329 >mailto:tnixon@microsoft.com > >

1 0

Re[2]: Far-end camera control for H.323
by Roni Even 15 Apr '98

15 Apr '98

Vineet, In H.281 each new message is replacing the previous one if it came from the same source with the same action. If you send a start pan right with timeout 300msec and the next message is continue the same action for 100 msec, the receiver upon getting the continue message restart the timer. Regards Roni Even _______________________ Reply Separator _______________________ Subject: Re: Far-end camera control for H.323 Author: <ITU-SG16(a)MAILBAG.INTEL.COM> at internet Date: 15/4/98 9:37 I agree that Acks are not needed and we should not try to over-engineer. But there needs to be a mechanism so that the user can stop the camera motion within a reasonable time after issuing STOP. This can be accomplished by having the receiver (one with the camera) look-ahead for STOP messages in its receive buffer. When it sees the STOP message it should ignore any CONTINUE messsages in its buffer which are ahead of the STOP. What I have described above is not something to be standarized but we could include it as a guidance to the implementors. vineet ______________________________ Reply Separator _________________________________ Subject: Far-end camera control for H.323 Author: Dave Lindbergh [SMTP:lindbergh@itu.ch] at MSXGATE Date: 4/14/98 11:58 PM Dear SG16 colleagues, Just to repeat and amplify our Yokosuka comments on APC-1356 (Intel) and APC-1366 (Accord) regarding Far End Camera Control (FECC) for H.323: In general, PictureTel supports the idea of basing H.323 FECC on H.281. We think the following points are important: 1) A general goal should be that H.323 FECC should be interoperable via a gateway with H.281-based FECC on H.320 systems (note that H.324 also uses H.281 FECC) 2) H.281 should be sent over UDP as a separate media stream, and not over TCP (such as H.245). We believe that H.281 must be transported using techniques suitable for a media stream, thus preserving the real-time relationships between control activation, hold, and deactivation which are represented by the H.281 Start, Continue, and Stop messages. 3) Any solution must address capability exchange including which endpoints have controllable cameras, how many cameras, what controls are available (pan, tilt, zoom, focus, etc.), preset positions available, etc. The existing H.281 system uses H.224 for capability exchanges of this sort. One solution would be to perform a similar function using H.245 cap exchange. Another would be to simply encapsulate the entire H.224/H.281 stack within a UDP media stream (this would simplify gateways). 4) Any solution must address multipoint use. One possibility is to adopt a solution similar to V.CHAT/T.CHAT: A simple H.281 UDP encapsulation for point-to-point use, and a very simple T.120 "wrapper" around H.281 for multipoint use. Note that the T.120 could reside either in endpoints or be proxied from the point-to-point mode at the MC. 5) To improve reliability on congested networks, rather than using TCP, redundant transmission of H.281 messages via UDP might be used. 6) To support future applications such as machine-driven pointing and operation on highly congested networks, the H.281 message set should be extended to add new absolute and/or relative positioning commands (probably in units of field of view rather than angular units). Long-term, a migration to these new commands could occur, while retaining compatibility with the existing H.281 start/stop motion model. 7) We are unsure how adding ACKs to Start/Continue/Stop messages (as suggested by Intel) is helpful. --Dave Lindbergh, PictureTel ------------------------------------------------------------------- Dave Lindbergh Email: lindbergh(a)pictel.com PictureTel Corporation Voice: +1 978 623 4351 100 Minuteman Road - M/S 635 Fax: +1 978 749 2804 Andover MA 01810 USA H.320 video by arrangement PGP fingerprint: C8 3E 28 69 53 0A 4B 87 EF E0 11 CD AC 87 4D CD -------------------------------------------------------------------

1 0

Re: Far-end camera control for H.323
by Toby Nixon 15 Apr '98

15 Apr '98

Do we have definite dates and location for the June Q12-14 meeting? -- Toby ___________________________________________________________ Toby L. Nixon, Senior Business Development Manager Microsoft Corporation, ICU - OEM & SI Group One Microsoft Way, Redmond WA 98052 USA +1 (425) 936-2792 Fax: +1 (425) 936-7329 mailto:tnixon@microsoft.com

1 0

Re: Far-end camera control for H.323
by Kumar, Vineet 15 Apr '98

15 Apr '98

I agree that Acks are not needed and we should not try to over-engineer. But there needs to be a mechanism so that the user can stop the camera motion within a reasonable time after issuing STOP. This can be accomplished by having the receiver (one with the camera) look-ahead for STOP messages in its receive buffer. When it sees the STOP message it should ignore any CONTINUE messsages in its buffer which are ahead of the STOP. What I have described above is not something to be standarized but we could include it as a guidance to the implementors. vineet ______________________________ Reply Separator _________________________________ Subject: Far-end camera control for H.323 Author: Dave Lindbergh [SMTP:lindbergh@itu.ch] at MSXGATE Date: 4/14/98 11:58 PM Dear SG16 colleagues, Just to repeat and amplify our Yokosuka comments on APC-1356 (Intel) and APC-1366 (Accord) regarding Far End Camera Control (FECC) for H.323: In general, PictureTel supports the idea of basing H.323 FECC on H.281. We think the following points are important: 1) A general goal should be that H.323 FECC should be interoperable via a gateway with H.281-based FECC on H.320 systems (note that H.324 also uses H.281 FECC) 2) H.281 should be sent over UDP as a separate media stream, and not over TCP (such as H.245). We believe that H.281 must be transported using techniques suitable for a media stream, thus preserving the real-time relationships between control activation, hold, and deactivation which are represented by the H.281 Start, Continue, and Stop messages. 3) Any solution must address capability exchange including which endpoints have controllable cameras, how many cameras, what controls are available (pan, tilt, zoom, focus, etc.), preset positions available, etc. The existing H.281 system uses H.224 for capability exchanges of this sort. One solution would be to perform a similar function using H.245 cap exchange. Another would be to simply encapsulate the entire H.224/H.281 stack within a UDP media stream (this would simplify gateways). 4) Any solution must address multipoint use. One possibility is to adopt a solution similar to V.CHAT/T.CHAT: A simple H.281 UDP encapsulation for point-to-point use, and a very simple T.120 "wrapper" around H.281 for multipoint use. Note that the T.120 could reside either in endpoints or be proxied from the point-to-point mode at the MC. 5) To improve reliability on congested networks, rather than using TCP, redundant transmission of H.281 messages via UDP might be used. 6) To support future applications such as machine-driven pointing and operation on highly congested networks, the H.281 message set should be extended to add new absolute and/or relative positioning commands (probably in units of field of view rather than angular units). Long-term, a migration to these new commands could occur, while retaining compatibility with the existing H.281 start/stop motion model. 7) We are unsure how adding ACKs to Start/Continue/Stop messages (as suggested by Intel) is helpful. --Dave Lindbergh, PictureTel ------------------------------------------------------------------- Dave Lindbergh Email: lindbergh(a)pictel.com PictureTel Corporation Voice: +1 978 623 4351 100 Minuteman Road - M/S 635 Fax: +1 978 749 2804 Andover MA 01810 USA H.320 video by arrangement PGP fingerprint: C8 3E 28 69 53 0A 4B 87 EF E0 11 CD AC 87 4D CD -------------------------------------------------------------------

1 0

Re: Far-end camera control for H.323
by Roni Even 15 Apr '98

15 Apr '98

Dear SG16 Colleagues, I read Dave Lindbergh's comments and found them important in order to go on with a solution for FECC. Following are my remarks to the points below. 1. I agree with this point. 2. I want to mention that if we are going to use one TCP connection for multiple calls ( See Lucent's APC) than there may be a problem with real time in the H.245 channel. Like my APC mentioned I think that both ways will work. 3. If a UDP channel is the solution than we can use the open logical channel ack message to send the FECC capabilities (see APC-1366). 4. In a multipoint environment using a UDP solution we can open this channel directly between the end points that want to have an FECC session. The exception will be in centralised conferences or centralised video conferences. We can add a "chair control" service requiring the end point who wants to start an FECC session to ask permission from the active MC. 5. OK 6. There was an APC from IBM for h.281 in the past addressing this issue. 7. I agree that ACKs is not needed. If a UDP solution is what we are going to do, does it mean that we need a new h.xxx. Roni Even Accord Video Telecommunication. ______________________________ Reply Separator _________________________________ Subject: Far-end camera control for H.323 Author: <ITU-SG16(a)MAILBAG.INTEL.COM> at internet Date: 4/15/98 2:58 AM Dear SG16 colleagues, Just to repeat and amplify our Yokosuka comments on APC-1356 (Intel) and APC-1366 (Accord) regarding Far End Camera Control (FECC) for H.323: In general, PictureTel supports the idea of basing H.323 FECC on H.281. We think the following points are important: 1) A general goal should be that H.323 FECC should be interoperable via a gateway with H.281-based FECC on H.320 systems (note that H.324 also uses H.281 FECC) 2) H.281 should be sent over UDP as a separate media stream, and not over TCP (such as H.245). We believe that H.281 must be transported using techniques suitable for a media stream, thus preserving the real-time relationships between control activation, hold, and deactivation which are represented by the H.281 Start, Continue, and Stop messages. 3) Any solution must address capability exchange including which endpoints have controllable cameras, how many cameras, what controls are available (pan, tilt, zoom, focus, etc.), preset positions available, etc. The existing H.281 system uses H.224 for capability exchanges of this sort. One solution would be to perform a similar function using H.245 cap exchange. Another would be to simply encapsulate the entire H.224/H.281 stack within a UDP media stream (this would simplify gateways). 4) Any solution must address multipoint use. One possibility is to adopt a solution similar to V.CHAT/T.CHAT: A simple H.281 UDP encapsulation for point-to-point use, and a very simple T.120 "wrapper" around H.281 for multipoint use. Note that the T.120 could reside either in endpoints or be proxied from the point-to-point mode at the MC. 5) To improve reliability on congested networks, rather than using TCP, redundant transmission of H.281 messages via UDP might be used. 6) To support future applications such as machine-driven pointing and operation on highly congested networks, the H.281 message set should be extended to add new absolute and/or relative positioning commands (probably in units of field of view rather than angular units). Long-term, a migration to these new commands could occur, while retaining compatibility with the existing H.281 start/stop motion model. 7) We are unsure how adding ACKs to Start/Continue/Stop messages (as suggested by Intel) is helpful. --Dave Lindbergh, PictureTel ------------------------------------------------------------------- Dave Lindbergh Email: lindbergh(a)pictel.com PictureTel Corporation Voice: +1 978 623 4351 100 Minuteman Road - M/S 635 Fax: +1 978 749 2804 Andover MA 01810 USA H.320 video by arrangement PGP fingerprint: C8 3E 28 69 53 0A 4B 87 EF E0 11 CD AC 87 4D CD -------------------------------------------------------------------

1 0

Far-end camera control for H.323
by Dave Lindbergh 15 Apr '98

15 Apr '98

Dear SG16 colleagues, Just to repeat and amplify our Yokosuka comments on APC-1356 (Intel) and APC-1366 (Accord) regarding Far End Camera Control (FECC) for H.323: In general, PictureTel supports the idea of basing H.323 FECC on H.281. We think the following points are important: 1) A general goal should be that H.323 FECC should be interoperable via a gateway with H.281-based FECC on H.320 systems (note that H.324 also uses H.281 FECC) 2) H.281 should be sent over UDP as a separate media stream, and not over TCP (such as H.245). We believe that H.281 must be transported using techniques suitable for a media stream, thus preserving the real-time relationships between control activation, hold, and deactivation which are represented by the H.281 Start, Continue, and Stop messages. 3) Any solution must address capability exchange including which endpoints have controllable cameras, how many cameras, what controls are available (pan, tilt, zoom, focus, etc.), preset positions available, etc. The existing H.281 system uses H.224 for capability exchanges of this sort. One solution would be to perform a similar function using H.245 cap exchange. Another would be to simply encapsulate the entire H.224/H.281 stack within a UDP media stream (this would simplify gateways). 4) Any solution must address multipoint use. One possibility is to adopt a solution similar to V.CHAT/T.CHAT: A simple H.281 UDP encapsulation for point-to-point use, and a very simple T.120 "wrapper" around H.281 for multipoint use. Note that the T.120 could reside either in endpoints or be proxied from the point-to-point mode at the MC. 5) To improve reliability on congested networks, rather than using TCP, redundant transmission of H.281 messages via UDP might be used. 6) To support future applications such as machine-driven pointing and operation on highly congested networks, the H.281 message set should be extended to add new absolute and/or relative positioning commands (probably in units of field of view rather than angular units). Long-term, a migration to these new commands could occur, while retaining compatibility with the existing H.281 start/stop motion model. 7) We are unsure how adding ACKs to Start/Continue/Stop messages (as suggested by Intel) is helpful. --Dave Lindbergh, PictureTel ------------------------------------------------------------------- Dave Lindbergh Email: lindbergh(a)pictel.com PictureTel Corporation Voice: +1 978 623 4351 100 Minuteman Road - M/S 635 Fax: +1 978 749 2804 Andover MA 01810 USA H.320 video by arrangement PGP fingerprint: C8 3E 28 69 53 0A 4B 87 EF E0 11 CD AC 87 4D CD -------------------------------------------------------------------

1 0

APC-1359
by Kiyoshi SAKAI 12 Apr '98

12 Apr '98

Dear Mr. Okubo and Q.12-14 colleagues, I have uploaded the following file to the "avc-site/Incoming" directory; apc-1359.zip: Proposed addition to H.245 for the AAL1/5 conversion gateway capabilities The zip-file contains a Word95/6.0(US version) compatible document. I'm very sorry for very late submission. Regards, ********************************************************************** Kiyoshi Sakai Media Processing Laboratory Multimedia Systems Labs. FUJITSU LABORATORIES LTD. Tel. : +81 44 754 2679 Fax. : +81 44 754 2347 E-mail : sakai(a)flab.fujitsu.co.jp **********************************************************************

1 0

Re: request for APC numbers
by Sakae OKUBO 12 Apr '98

12 Apr '98

Dear Dale, In response to your request, APC-1368 has been allocated to your contribution as attached. Many apologies for my losing your original request dated 3 April Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151-0053 Japan or okubo(a)mxz.meshnet.or.jp ******************************************************************** ----------------------------------------------------------------------- APC- Source Provisional Title ----------------------------------------------------------------------- 1328 Siemens Proposal for Call Hold Supplementary service in H.323 (H.450.Hold) 1329 Siemens Proposal for Call Park/Call Pickup supplementary service in H.323 (H.450.Park+Pickup) 1330 Siemens Proposal for Call Waiting Supplementary Service H.323 (H.450.CallWaiting) 1331 RADVision A proposal for RTP/RTCP addresses use during the Fast Connect Procedure 1332 RADVision Remarks on H.225.0 1333 Editor Drat Amendment 5 to H.222.0 1334 Editor Draft Annex I to H.225.0 1335 Editor Darft H.245 V4 1336 Editor Darft H.310 V2 1337 Editor Draft H.bmultipoint 1338 Editor Draft Annex D to H.323 1339 PictureTel Proposals and General Comments for H.323 Annex C 1340 Mitel Message Waiting Indication Supplementary Service in H.323 1341 3Com, Ascend, Deutsche Telecom, France Telecom, GPT, Hewlett-Packard, Intel, Lucent Technologies, Post & Telecom Austria (PTA), Siements, VocalTec Inter-Gatekeeper Communication Requirements (H.323 Annex G) 1342 ETSI Communication from EP TIPHON to ITU SG16 on Codec support for H.323 1343 MPEG Liaison response regarding DMIF 1344 Editor H.246 Work Plan and Discussion 1345 VideoServer/Intel Proposal for H.MediaMIB 1346 VideoServer Proposal for H.225 Call Signalling MIB 1347 VideoServer Proposal for H.225 RAS MIB 1348 VideoServer Proposal for H.245 MIB 1349 Cisco Proposal for H.323 Gatekeeper MIB 1350 VideoServer Proposal for H.323 Terminal MIB 1351 multiple Faster connect for H.323 terminals 1352 Editor Draft H.323 v2 Implementers Guide 1353 Intel Proposals and general comments for Inter-Gatekeeper Communications 1354 IBM Comment to the current H.323 endpoint registration procedure 1355 IBM Coding of the MultipointCapabilitys within the H2250Capability data structure 1356 Intel Proposal for Real Time Device Control in H.323 1357 NTT DoCoMo The support of MPEG-4 video in H.324 terminals 1358 Secretary of Meeting Host Organization Network configuration of Yokosuka Rapporteur Meeting 1359 Fujitsu Proposed addition to H.245 for the AAL1/5 conversion gateway capabilities 1360 RADVision Comments on H.235: H.323 Procedures 1361 RADVision GK's role in up-to-date H.323 architecture 1362 Editor Corrections to Decided H.225.0 V2 1363 Lucent H.225 Signaling Enhancements 1364 Madge Networks Comment on the current limitations in H.225.0 v2 for signalling call setup parameters for an outgoing SCN call 1365 VTEL A MIB for audiovisual communication terminals 1366 Accord Real Time Device Control in H.323 1367 TELES Outline of H.323 Usage for Terminals with Fixed Capabilities 1368 Ascend Supporting Multiple Calls on a single TCP link between GW and GK -----------------------------------------------------------------------

1 0

Contributions for the Yokosuka meeting
by Sakae OKUBO 11 Apr '98

11 Apr '98

Dear Q.112-14 colleagues, So far I have listed from APC-1328 to 1366 as contributions to the Yokosuka meeting as attached. The following are yet to be uploaded. APC-1338 APC-1344 APC-1345 APC-1350 APC-1351 APC-1359 APC-1365 As we lost another incoming mails during 16:00 Thursay - 10:00 Friday (Tokyo time) without advising the sender, I may have missed your important messages. Please send them again to me if any. Many apologies about this. To those who are coming to Yokosuka, I wish you safe trips. See you next week. Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151-0053 Japan or okubo(a)mxz.meshnet.or.jp ******************************************************************** ----------------------------------------------------------------------- APC- Source Provisional Title ----------------------------------------------------------------------- 1328 Siemens Proposal for Call Hold Supplementary service in H.323 (H.450.Hold) 1329 Siemens Proposal for Call Park/Call Pickup supplementary service in H.323 (H.450.Park+Pickup) 1330 Siemens Proposal for Call Waiting Supplementary Service H.323 (H.450.CallWaiting) 1331 RADVision A proposal for RTP/RTCP addresses use during the Fast Connect Procedure 1332 RADVision Remarks on H.225.0 1333 Editor Drat Amendment 5 to H.222.0 1334 Editor Draft Annex I to H.225.0 1335 Editor Darft H.245 V4 1336 Editor Darft H.310 V2 1337 Editor Draft H.bmultipoint 1338 Editor Draft Annex D to H.323 1339 PictureTel Proposals and General Comments for H.323 Annex C 1340 Mitel Message Waiting Indication Supplementary Service in H.323 1341 3Com, Ascend, Deutsche Telecom, France Telecom, GPT, Hewlett-Packard, Intel, Lucent Technologies, Post & Telecom Austria (PTA), Siements, VocalTec Inter-Gatekeeper Communication Requirements (H.323 Annex G) 1342 ETSI Communication from EP TIPHON to ITU SG16 on Codec support for H.323 1343 MPEG Liaison response regarding DMIF 1344 Editor H.246 Work Plan and Discussion 1345 VideoServer/Intel Proposal for H.MediaMIB 1346 VideoServer Proposal for H.225 Call Signalling MIB 1347 VideoServer Proposal for H.225 RAS MIB 1348 VideoServer Proposal for H.245 MIB 1349 Cisco Proposal for H.323 Gatekeeper MIB 1350 VideoServer Proposal for H.323 Terminal MIB 1351 multiple Faster connect for H.323 terminals 1352 Editor Draft H.323 v2 Implementers Guide 1353 Intel Proposals and general comments for Inter-Gatekeeper Communications 1354 IBM Comment to the current H.323 endpoint registration procedure 1355 IBM Coding of the MultipointCapabilitys within the H2250Capability data structure 1356 Intel Proposal for Real Time Device Control in H.323 1357 NTT DoCoMo The support of MPEG-4 video in H.324 terminals 1358 Secretary of Meeting Host Organization Network configuration of Yokosuka Rapporteur Meeting 1359 Fujitsu Proposed addition to H.245 for the AAL1/5 conversion gateway capabilities 1360 RADVision Comments on H.235: H.323 Procedures 1361 RADVision GK's role in up-to-date H.323 architecture 1362 Editor Corrections to Decided H.225.0 V2 1363 Lucent H.225 Signaling Enhancements 1364 Madge Networks Comment on the current limitations in H.225.0 v2 for signalling call setup parameters for an outgoing SCN call 1365 VTEL A MIB for audiovisual communication terminals 1366 Accord Real Time Device Control in H.323 -----------------------------------------------------------------------

3 2

address for subscription
by David Bukovinsky 10 Apr '98

10 Apr '98

Sorry for sending this out on this list - can someone send me the email address of the server, and the appropriate message body, to subscribe to the ITU list? thanks, and apologies for sending this out in this forum. --dave ---------------------------------------------------------------------------- ---------------------------------------------- Dave Bukovinsky d.bukovinsky(a)cablelabs.com Project Director, Software Architectures (303) 661-3862 CableLabs, Inc.

1 0

uploaded documents
by George Kajos 10 Apr '98

10 Apr '98

Hello folks, I have uploaded apc1345a.zip, apc-1346.zip, apc-1347.zip, apc-1348.zip, and apc-1349.zip. Mr. Webber please delete apc-1345.zip from the incoming directory in favor of apc1345a.zip. Thank you, George Kajos

1 0

APC-1330 uploaded
by Markku Korpi 10 Apr '98

10 Apr '98

All, I have uploaded the contribution APC-1330 on Call Waiting supplementary service to the PictureTel incoming site (It is in Word 8.0/'97 format) Regards Markku Korpi ------------ Markku Korpi Siemens, 4900 Old Ironsides Dr., P.O.Box 58075, Santa Clara CA 95054 Phone: +1 408 492 7328, E-mail: korpim(a)sbs.de

1 0

APCs 1331, 1332, 1360, 1361
by Orit Levin 09 Apr '98

09 Apr '98

Dear Mr. Okubo! I have uploaded the following APCs to the Incoming Directory: 1331 RADVision A proposal for RTP/RTCP addresses use during the Fast Connect Procedure 1332 RADVision Remarks on H.225.0 1360 RADVision H.235: Comments on H.323 Procedures 1361 RADVision GK's role in up-to-date H.323 architecture Best Regards, Orit Levin RADVision Inc., Mahwah, NJ Tel: 201-529-4300 ext. 230 Fax: 201-529-3516 E Mail: orit(a)radvision.com

1 0

APC-1340 MWI Supplementary Service for H.323
by Dave Walker 09 Apr '98

09 Apr '98

Dear Colleagues, I have uploaded APC-1340, Message Waiting Indication Supplementary Service in H.323, to standard.pictel.com/avc-site/Incoming. Regards, Dave Walker. -- D. R. Walker Mitel Corp, Kanata, ON, CANADA email: dave_walker(a)mitel.com phone: (613) 592-2122 x1613

1 0

APC-1364 uploaded
by Michele Bozier WVdevmt-WS 09 Apr '98

09 Apr '98

All, I have uploaded APC-1364 - " Comment on the current limitations in H.225.0 v2 for signalling call setup parameters for an outgoing SCN call" to the ftp server. Regards Michele Bozier ---------------------------------------- Michele Bozier Principal Development Engineer Madge Networks, Wexham Springs, Framewood Rd, Wexham, Slough SL3 6PJ, England Tel: +44(0)1753 661331 Fax: +44(0)1753 661011 email:mbozier@madge.com

1 0

Re: request for apc number
by Sakae OKUBO 09 Apr '98

09 Apr '98

Dear Roni Even, In response to your requests, APC-1366 has been allocated to your contribution as attached. Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151-0053 Japan or okubo(a)mxz.meshnet.or.jp ******************************************************************** ----------------------------------------------------------------------- APC- Source Provisional Title ----------------------------------------------------------------------- 1328 Siemens Proposal for Call Hold Supplementary service in H.323 (H.450.Hold) 1329 Siemens Proposal for Call Park/Call Pickup supplementary service in H.323 (H.450.Park+Pickup) 1330 Siemens Proposal for Call Waiting Supplementary Service H.323 (H.450.CallWaiting) 1331 RADVision A proposal for RTP/RTCP addresses use during the Fast Connect Procedure 1332 RADVision Remarks on H.225.0 1333 Editor Drat Amendment 5 to H.222.0 1334 Editor Draft Annex I to H.225.0 1335 Editor Darft H.245 V4 1336 Editor Darft H.310 V2 1337 Editor Draft H.bmultipoint 1338 Editor Draft Annex D to H.323 1339 PictureTel Proposals and General Comments for H.323 Annex C 1340 Mitel Message Waiting Indication Supplementary Service in H.323 1341 3Com, Ascend, Deutsche Telecom, France Telecom, GPT, Hewlett-Packard, Intel, Lucent Technologies, Post & Telecom Austria (PTA), Siements, VocalTec Inter-Gatekeeper Communication Requirements (H.323 Annex G) 1342 ETSI Communication from EP TIPHON to ITU SG16 on Codec support for H.323 1343 MPEG Liaison response regarding DMIF 1344 Editor H.246 Work Plan and Discussion 1345 VideoServer/Intel Proposal for H.MediaMIB 1346 VideoServer Proposal for H.225 Call Signalling MIB 1347 VideoServer Proposal for H.225 RAS MIB 1348 VideoServer Proposal for H.245 MIB 1349 Cisco Proposal for H.323 Gatekeeper MIB 1350 VideoServer Proposal for H.323 Terminal MIB 1351 multiple Faster connect for H.323 terminals 1352 Editor Draft H.323 v2 Implementers Guide 1353 Intel Proposals and general comments for Inter-Gatekeeper Communications 1354 IBM Comment to the current H.323 endpoint registration procedure 1355 IBM Coding of the MultipointCapabilitys within the H2250Capability data structure 1356 Intel Proposal for Real Time Device Control in H.323 1357 NTT DoCoMo The support of MPEG-4 video in H.324 terminals 1358 Secretary of Meeting Host Organization Network configuration of Yokosuka Rapporteur Meeting 1359 Fujitsu Proposed addition to H.245 for the AAL1/5 conversion gateway capabilities 1360 RADVision Comments on H.235: H.323 Procedures 1361 RADVision GK's role in up-to-date H.323 architecture 1362 Editor Corrections to Decided H.225.0 V2 1363 Lucent H.225 Signaling Enhancements 1364 Madge Networks Comment on the current limitations in H.225.0 v2 for signalling call setup parameters for an outgoing SCN call 1365 VTEL A MIB for audiovisual communication terminals 1366 Accord Real Time Device Control in H.323 -----------------------------------------------------------------------

1 0

APC-1336
by Kiyoshi SAKAI 09 Apr '98

09 Apr '98

Dear Mr. Okubo and Q.12-14 colleagues, I have uploaded the following file to the "avc-site/Incoming" directory; apc1336.zip: Draft H.310 version 2 The zip-file contains a Word95/6.0(US version) compatible document. If you have any problems to read the file, please let me know. Regards, ********************************************************************** Kiyoshi Sakai Media Processing Laboratory Multimedia Systems Labs. FUJITSU LABORATORIES LTD. Tel. : +81 44 754 2679 Fax. : +81 44 754 2347 E-mail : sakai(a)flab.fujitsu.co.jp **********************************************************************

1 0

Multiple RAS messages per PDU?
by Paul Long 09 Apr '98

09 Apr '98

6.1/H.225.0v2 says, "When messages are sent on the reliable H.245 control channel, more than one message may be sent within the boundaries defined by the reliable transport PDU as long as whole messages are sent;" However, nothing is said about whether more than one _RAS_ message may be sent "within the boundaries defined by the _un_reliable transport PDU as long as whole messages are sent." Are we allowed or prohibited from packing RAS messages, or is this just not addressed in the Recommendation? Paul Long Smith Micro

2 1

APC-1357/dpc
by Toshiro Kawahara 09 Apr '98

09 Apr '98

Dear Mr. Okubo, and experts, I have uploaded APC-1357 into avc-site/Incoming directory. Regards, Toshiro -- Toshiro Kawahara <kawahara(a)spg.yrp.nttdocomo.co.jp> NTT Mobile Communications Network, Inc. TEL: +81 468 40 3518 FAX: +81 468 40 3788 $B2O86 (B $BIRO/ (B (in Japanese)

1 0

APC-1335 (H.245V4) Uploaded
by Mike Nilsson 08 Apr '98

08 Apr '98

I have uploaded APC-1335 to the ftp server. This contains the latest text for H.245 version 4. It includes the determined text from Geneva and has been rearranged to include syntax, semantics, and procedures, in three new annexes. Best regards Mike Nilsson ************************************************************************ * Mike Nilsson Tel: +44 1473 645413 * * Video Processing Unit Fax: +44 1473 643791 * * Centre for Human Communications Email: mike.nilsson(a)bt-sys.bt.co.uk * * BT Laboratories [MLB3/11] * * Martlesham Heath * * Ipswich IP5 7RE * * UK * ************************************************************************

1 0

Updated information on Yokosuka meeting
by Kiyoshi SAKAI 08 Apr '98

08 Apr '98

Dear Q.11-14/16 colleagues, >> Attached please find the updated invitation for the next experts group >> meeting in Yokosuka(14-17, April). It contains general information about >> the meeting. >> The attached zip file contains a "Word97/6.0" compatible document. >> We will send you the one in text-only format as soon as possible. Here is the updated invitation in text-only form. Full document including all the appendices will be distributed at the meeting. Best regards, from the meeting hosts; Hidenobu HARASAKI (NEC) Kiyoshi SAKAI(Fujitsu Lab.) ********************************************************************** Kiyoshi Sakai Media Processing Laboratory Multimedia Systems Labs. FUJITSU LABORATORIES LTD. Tel. : +81 44 754 2679 Fax. : +81 44 754 2347 E-mail : sakai(a)flab.fujitsu.co.jp ********************************************************************** ---- Cut here --------------------------------------------------------- ITU-T Study Group 16 Q11-14 joint Rapporteur Meeting Yokosuka, Japan 14-17 April 1998 GENERAL INFORMATION Secretariat Hosts: Fujitsu, NEC, Canon, GCL, Hitachi, JVC, KDD, Matsushita, Mitsubishi, MPT, NTT, NTT DoCoMo, OKI, Sharp, Toshiba, TEPCO, TTC CONTENTS 1. VENUE------------------------------------- 3 2. TRANSPORTATION---------------------------- 3 3. MEETING ROOM ----------------------------- 7 4. SECRETARIAT------------------------------- 7 5. FILE SERVER and INTERNET ACCESS 7 6. NAME TAGS -------------------------------- 8 7. PIGEONBOX SERVICE------------------------- 8 8. BULLETIN BOARD SERVICE--------------- 8 9. COPY SERVICE-------------------------------- 8 10. BREAK-------------------------------------- 8 11. LUNCH-------------------------------------- 8 12. RECEPTION------------------------------ 9 13. MEDICAL CARE------------------------------- 9 14. BANKING AND CREDIT CARDS---------- 9 15. RESTAURANTS INFORMATION---------- 10 APPENDICES: Appendix 1: Train and bus timetable Appendix 2: Yokosuka Research Park Center Appendix 3: Restaurants information 1. Venue YPR Building No. 1 ("Ichibankan") Yokosuka Research Park, YRP Center 3-4 Hikarino-oka, Yokosuka, 239-0847, Japan 2. TRANSPORTATION 2.1. Transportation from Narita Airport to the hotel The Yokosuka Prince Hotel is just in front of Shioiri station at Kehin-kyuko line. There are some alternative ways from Narita Airport to Shioiri station as follows. The Alt.1 or Alt.2 seems to be the easiest way but still challenging, especially for those who visit Japan for the first time. Alt.1: Take JR (Narita Express or NEX, all reserved seats) to Yokohama and change to Keihin-kyuko line to take an express train(signed in red) bound for Misaki-guchi(). Get off at Shioiri Station (5th stop by counting Yokohama as the first stop, 4530 yen. Note: Since Narita Express departs the airport every hour, additional 30 minutes(in average) waiting time should be considered. There is another type of Keihin-kyuko express( signed in green) which does NOT stop at Shioiri. Alt.2: Take Airport Limousine Bus to Yokohama (YCAT) and change to Keihin-kyuko line to take an express train(signed in red) bound for Misaki-guchi. Get off at Shioiri (3850 yen). Note: Bus traveling hour varies depending on traffic condition. Since Airport Limousine Bus departs the airport every 20 minutes, additional 10 minutes (in average) waiting time should be considered. There is another type of Keihin -kyuko express(signed in green) which does NOT stop at Shioiri. Alt.3: Take JR line(Airport Narita) to Yokosuka (2520 yen). For JR line(Airport Narita), it is recommended to take a Green Car(first class) for your convenience with additional 1900 yen. Note: Since Airport Narita departs the airport every hour, additional 30 minutes (in average) waiting time should be considered. Alt.4: Take Keisei Limited Express to Aoto and change to Keiyu Limited Express bound for Misaki-guchi. Get off at Shioiri Station (1900 yen). Note: Since Keisei Limited Express departs the airport every 20 minutes, additional 10 minutes (in average) waiting time should be considered. You can also find other possible ways from Narita Airport to Shioiri at the following YRP web site; http://www.yrp.com/access/access.htm In addition, following web sites will be helpful to you; - About Narita airport: http://www.narita-airport.or.jp/airport_e/index_e.html - Access from Narita Airport to downtown Tokyo and Yokohama including JR Narita Express, Keisei Limited express and Limousine Bus Timetables; http://www.narita-airport.or.jp/airport_e/access_e/access_index.html 2.2 Transportation from the hotel to the meeting site Alt1: Train and Bus >From Yokosuka Prince Hotel to YRP, 1.walk to Shioiri station. 2.buy a 230-yen ticket, and take a train bounded for Misakiguchi. 3.get off at YRP Nobi station, which is 6th stop. See Keikyu Tourist Guide for more information. Note: The station name was changed from Nobi to YRP Nobi on April 1. 4.wait for a bus at Bus stand No.1 and get on a bus indicated *4, *5 or *6 (* indicates a Japanese letter). 5. drop 180 yen into a fare box, when the bus stops at YRP Center. The following time schedule is suggested because the meeting is scheduled to start at 9:00. Please be careful that bus schedule will be changed on April 16 which is the third day of the meeting. Table 1: Suggested train and bus timetable Shioiri Station to YRP Nobi Station by train Tuesday, April 14 and Wednesday, April 15 7:21 --> 7:36 7:41 --> 7:59 7:54 --> 8:12 8:14 --> 8:32 8:34 --> 8:48 8:43 --> 8:57 8:55 --> 9:09 YRP Nobi Station to YRP Center by bus Tuesday, April 14 and Wednesday, April 15 7:41 --> 7:50 8:06 --> 8:16 8:20 --> 8:30 8:36 --> 8:46 8:52 --> 9:02 (Late) 9:02 --> 9:12 (Late) 9:17 --> 9:27 (Late) Shioiri Station to YRP Nobi Station by train Thursday, April 16 and Friday, April 17 7:21 --> 7:36 7:41 --> 7:59 7:54 --> 8:12 8:04 --> 8:24 8:14 --> 8:32 8:34 --> 8:48 8:43 --> 8:57 8:55 --> 9:09 YRP Nobi Station to YRP Center by bus Thursday, April 16 and Friday, April 17 7:40 --> 7:50 7:54 --> 8:04 8:10 --> 8:20 8:22 --> 8:32 8:27 --> 8:37 8:40 --> 8:50 8:54 --> 9:04 (Late) 9:04 --> 9:14 (Late) 9:15 --> 9:25 (Late) Alt2: Train and Taxi If your party is three or four, taking a taxi from YRP Nobi station to YRP Center might be an alternative. >From Yokosuka Prince Hotel to YRP, Steps 1 thru 3 are the same as section 2.1. 4. take a taxi to YRP. It will cost less than 1000 yen. Note: Only five or six station based taxies are operating. Alt3: Taxi It will cost about 4000 yen from Yokosuka Prince Hotel to YRP Center by taxi. 3. MEETING ROOM See Appendix 2 "YRP Center Building No. 1 ("Ichibankan" in Japanese) Floor Layout" Meeting room is normally open from 09:00 at YRP Hall, Conference Room 1, 2 and 4 in Ichibankan. Please confirm the meeting room allocation announced on the Bulletin Board everyday. 4. SECRETARIAT Staff room is located on the third floor and normally opens from 8:30 to 18:00. The room name is "Seminar Room 2". TEL: +81 468 47 5043 FAX: +81 468 47 5044 Please note that the both numbers are available for domestic calls in Japan and international calls from outside Japan only. International uses from Japan to any other countries are not available, and please use the public pay phone. The following computer hardware and software will be available at staff room during the meeting: *Two IBM compatible personal computers with Word 97 for Windows95 Laser printers are also available for above computers. 5. FILE SERVER and INTERNET ACCESS AC power (100 Volt) and 10Base-T port are available in any conference room. Please bring your own LAN interface device and Unshielded Twisted Pair(UTP) cable with enough length(at least 3m long), if you want to connect your notebook PC to the LAN. DHCP server will automatically assign your IP address from private address space (i.e. 192.168.0.0/24). If your computer does not accept DHCP protocol, please contact Mr. Harasaki for your IP address assignment. Setup microsoft network client and NetBIOS on a top of TCP/IP protocol, because the file server is Unix machine with Samba daemon.The workgroup and computer name of the file server is "itu-t" and "fileserver", respectively. The meeting site is connected to the Internet with 128Kbps dedicated line.The router with network address translation and IP masquerade functions will translate your private IP address to one from global IP addresses allocated from an internet provider. 6. NAME TAGS Rapporteur meeting participants are kindly requested to always put on the name tag in YRP. Whenever entering YRP, the delegates are checked at the entrance. 7. PIGEONBOX Documents and messages will be placed in the pigeonboxes in front of YRP Hall. You can keep your documents during the meeting in your pigeon box. 8. BULLETIN BOARD SERVICE The change of meeting schedule and other information is indicated on the Bulletin Board in the lobby. 9. COPY SERVICE Anyone who request making copies, please bring documents to the staff room on the third floor. 10. BREAK Beverage and Confectioneries are served in the lobby. 11. LUNCH Lunch will be available at the restaurant "Roseteria", which is next to the Ichibankan building. (There are no restaurants near YRP) 12.RECEPTION The delegates are invited to the following Reception. Wednesday, April 15, 1998 A tour bus will leave YRP at 18:00. The party will be held in a casual seafood restaurant in Yokoyama Bayside Marina.A tour bus will take you back to Yokosuka Prince Hotel before 22:00. The host organization is preparing the party for all the participants. If you will not attend the reception for some reasons, please advise us on your registration. 13. MEDICAL CARE For emergency medical care, please contact the Secretariat. 14. BANKING AND CREDIT CARDS 14-1 Banking Most major banks have branches near your hotel. You can exchange TC/foreign currency at Yokosuka Prince Hotel (Shioiri station) Yokohama Bank (Yokosuka-Chuo station) Suruga Bank (Yokosuka-Chuo station) Banking hours: 9:00 - 15:00 on Monday to Friday closed on Saturdays and Sundays Foreign currencies can be exchanged at the airport upon arrival. Major hotels have foreign exchange facilities. 14-2 Credit Cards CD is available at Okadaya More's City: VISA <The Shopping Center next Yokosuka-Chuo station (Keikyu Line)> 15. RESTAURANTS INFORMATION See Appendix 3

1 0

Global IP addresses for Yokosuka Rapporteur Meeting
by Hidenobu Harasaki 08 Apr '98

08 Apr '98

Dear Yokosuka Rapporteur Meeting Participants, At the meeting site in Yokosuka Research Park, internet access will be available via router with NAT and IP masquerade. As you may need IP addresses for allowing telnet to your organization throught firewalls, I would like to list them as below. Allocated global address space is 210.162.213.176/29. 210.162.213.176 (subnet itself) 210.162.213.177 gate.q11q12q13q14-unet.ocn.ne.jp 210.162.213.178 host1.q11q12q13q14-unet.ocn.ne.jp 210.162.213.179 host2.q11q12q13q14-unet.ocn.ne.jp 210.162.213.180 host3.q11q12q13q14-unet.ocn.ne.jp 210.162.213.181 host4.q11q12q13q14-unet.ocn.ne.jp 210.162.213.182 host5.q11q12q13q14-unet.ocn.ne.jp 210.162.213.183 (broadcast address) Above addresses and DNS entries are only available from April 13 through April 17 in JST. Please be aware that above one global address will be shared by more than 30 computers. Please do not forget to bring a UTP cable with at least 3 meter long. Best regards, Hideh Hidenobu Harasaki harasaki(a)ccm.CL.nec.co.jp Principal Researcher C&C Media Research Labs., NEC Corporation Phone: +81 44 856 8083 Fax: +81 44 856 2232

1 0

Updated information on Yokosuka meeting
by Kiyoshi SAKAI 08 Apr '98

08 Apr '98

Dear Q.11-14/16 colleagues, Attached please find the updated invitation for the next experts group meeting in Yokosuka(14-17, April). It contains general information about the meeting. The attached zip file contains a "Word97/6.0" compatible documents. We will send you the one in text-only format as soon as possible. Looking forward to seeing you soon. Best regards, from the meeting hosts; Hidenobu HARASAKI (NEC) Kiyoshi SAKAI(Fujitsu Lab.) ********************************************************************** Kiyoshi Sakai Media Processing Laboratory Multimedia Systems Labs. FUJITSU LABORATORIES LTD. Tel. : +81 44 754 2679 Fax. : +81 44 754 2347 E-mail : sakai(a)flab.fujitsu.co.jp **********************************************************************

1 0

APC-1337.doc and APC-1358.doc
by Hidenobu Harasaki 08 Apr '98

08 Apr '98

Dear Mr. Okubo, and Q.12-14 Experts, I have uploaded APC-1337 (Draft Recommendation H.bmultipoint) and APC-1358 (Network configuration of Yokosuka Rapporteur Meeting) into avc-site/Incoming directory. If you have any problem on opening those files, please let me know. APC-1337 is created by Microsoft Word Version 7.0. APC-1358 is created by Microsoft Word 97 SR-1 and saved as Word 5.x format. Best regards, Hidenobu Harasaki harasaki(a)ccm.CL.nec.co.jp Principal Researcher C&C Media Research Labs., NEC Corporation Phone: +81 44 856 8083 Fax: +81 44 856 2232

1 0

Re: APCs 1352, 1353
by Sakae OKUBO 08 Apr '98

08 Apr '98

Dear Jim, > I have placed the APCs in the incoming directory of the avc-site. > > (apc1352.zip and apc1353.zip) They have been moved to /9804_Yokdirectory as APC-1352.zip and APC-1353.zip. Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151-0053 Japan or okubo(a)mxz.meshnet.or.jp ********************************************************************

1 0

APC numbers for the Yokosuka meeting
by Sakae OKUBO 08 Apr '98

08 Apr '98

Dear Glenn Freundlich, Michele Bozier, Joon Maeng, In response to your requests, APC-1362 throguh 1365 have been allocated to your contributions as attached. Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151-0053 Japan or okubo(a)mxz.meshnet.or.jp ******************************************************************** ----------------------------------------------------------------------- APC- Source Provisional Title ----------------------------------------------------------------------- 1328 Siemens Proposal for Call Hold Supplementary service in H.323 (H.450.Hold) 1329 Siemens Proposal for Call Park/Call Pickup supplementary service in H.323 (H.450.Park+Pickup) 1330 Siemens Proposal for Call Waiting Supplementary Service H.323 (H.450.CallWaiting) 1331 RADVision A proposal for RTP/RTCP addresses use during the Fast Connect Procedure 1332 RADVision Remarks on H.225.0 1333 Editor Drat Amendment 5 to H.222.0 1334 Editor Draft Annex I to H.225.0 1335 Editor Darft H.245 V4 1336 Editor Darft H.310 V2 1337 Editor Draft H.bmultipoint 1338 Editor Draft Annex D to H.323 1339 PictureTel Proposals and General Comments for H.323 Annex C 1340 Mitel Message Waiting Indication Supplementary Service in H.323 1341 3Com, Ascend, Deutsche Telecom, France Telecom, GPT, Hewlett-Packard, Intel, Lucent Technologies, Post & Telecom Austria (PTA), Siements, VocalTec Inter-Gatekeeper Communication Requirements (H.323 Annex G) 1342 ETSI Communication from EP TIPHON to ITU SG16 on Codec support for H.323 1343 MPEG Liaison response regarding DMIF 1344 Editor H.246 Work Plan and Discussion 1345 VideoServer/Intel Proposal for H.MediaMIB 1346 VideoServer Proposal for H.225 Call Signalling MIB 1347 VideoServer Proposal for H.225 RAS MIB 1348 VideoServer Proposal for H.245 MIB 1349 Cisco Proposal for H.323 Gatekeeper MIB 1350 VideoServer Proposal for H.323 Terminal MIB 1351 multiple Faster connect for H.323 terminals 1352 Editor Draft H.323 v2 Implementers Guide 1353 Intel Proposals and general comments for Inter-Gatekeeper Communications 1354 IBM Comment to the current H.323 endpoint registration procedure 1355 IBM Coding of the MultipointCapabilitys within the H2250Capability data structure 1356 Intel Proposal for Real Time Device Control in H.323 1357 NTT DoCoMo The support of MPEG-4 video in H.324 terminals 1358 Secretary of Meeting Host Organization Network configuration of Yokosuka Rapporteur Meeting 1359 Fujitsu Proposed addition to H.245 for the AAL1/5 conversion gateway capabilities 1360 RADVision Comments on H.235: H.323 Procedures 1361 RADVision GK's role in up-to-date H.323 architecture 1362 Editor Corrections to Decided H.225.0 V2 1363 Lucent H.225 Signaling Enhancements 1364 Madge Networks Comment on the current limitations in H.225.0 v2 for signalling call setup parameters for an outgoing SCN call 1365 VTEL A MIB for audiovisual communication terminals -----------------------------------------------------------------------

1 0

Please bring 70 copies
by Sakae OKUBO 07 Apr '98

07 Apr '98

Dear Yokosuka meeting contributors, As the number of registered participants is reaching 70, please bring or send 70 copies of your contributions even though electronic access to the documents will be provided at the meeting site as in Hertzlia. We would appreciate your cooperation to reduce the cost of on-site copying. Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151-0053 Japan or okubo(a)mxz.meshnet.or.jp ********************************************************************

1 0

Re: APC-1354 and APC-1355
by Sakae OKUBO 07 Apr '98

07 Apr '98

Dear Mr. Truong, > FYI, I just uploaded the two documents APC-1354 and 1355 into the > Incoming directory. These two documents have been moved to /9804_Yok directory in zipped form. Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151-0053 Japan or okubo(a)mxz.meshnet.or.jp ********************************************************************

1 0

Re: APC-1341 & APC-1342
by Sakae OKUBO 07 Apr '98

07 Apr '98

Dear Mr. Kimchi, > (See attached file: APC-1341.doc)(See attached file: APC-1342.doc) > > I have tried to place these in the "incoming" directory, but for some > reason could not. They have been placed at /9804_Yok directory in zipped form. Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151-0053 Japan or okubo(a)mxz.meshnet.or.jp ********************************************************************

1 0

Re: Additional APC numbers
by Sakae OKUBO 07 Apr '98

07 Apr '98

Dear Ms. Orit Levin, In response to your request, APC-1360 and 1361 have been allocated to your contributions as attached. Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151-0053 Japan or okubo(a)mxz.meshnet.or.jp ******************************************************************** ----------------------------------------------------------------------- APC- Source Provisional Title ----------------------------------------------------------------------- 1328 Siemens Proposal for Call Hold Supplementary service in H.323 (H.450.Hold) 1329 Siemens Proposal for Call Park/Call Pickup supplementary service in H.323 (H.450.Park+Pickup) 1330 Siemens Proposal for Call Waiting Supplementary Service H.323 (H.450.CallWaiting) 1331 RADVision A proposal for RTP/RTCP addresses use during the Fast Connect Procedure 1332 RADVision Remarks on H.225.0 1333 Editor Drat Amendment 5 to H.222.0 1334 Editor Draft Annex I to H.225.0 1335 Editor Darft H.245 V4 1336 Editor Darft H.310 V2 1337 Editor Draft H.bmultipoint 1338 Editor Draft Annex D to H.323 1339 PictureTel Proposals and General Comments for H.323 Annex C 1340 Mitel Message Waiting Indication Supplementary Service in H.323 1341 multiple Inter-Gatekeeper Communication Requirements (H.323 Annex G) 1342 ETSI Communication from EP TIPHON to ITU SG16 on Codec support for H.323 1343 MPEG Liaison response regarding DMIF 1344 Editor H.246 Work Plan and Discussion 1345 VideoServer/Intel Proposal for H.MediaMIB 1346 VideoServer Proposal for H.225 Call Signalling MIB 1347 VideoServer Proposal for H.225 RAS MIB 1348 VideoServer Proposal for H.245 MIB 1349 Cisco Proposal for H.323 Gatekeeper MIB 1350 VideoServer Proposal for H.323 Terminal MIB 1351 multiple Faster connect for H.323 terminals 1352 Editor Draft H.323 v2 Implementers Guide 1353 Intel Proposals and general comments for Inter-Gatekeeper Communications 1354 IBM Comment to the current H.323 endpoint registration procedure 1355 IBM Coding of the MultipointCapabilitys within the H2250Capability data structure 1356 Intel Proposal for Real Time Device Control in H.323 1357 NTT DoCoMo The support of MPEG-4 video in H.324 terminals 1358 Secretary of Meeting Host Organization Network configuration of Yokosuka Rapporteur Meeting 1359 Fujitsu Proposed addition to H.245 for the AAL1/5 conversion gateway capabilities 1360 RADVision Comments on H.235: H.323 Procedures 1361 RADVision GK's role in up-to-date H.323 architecture -----------------------------------------------------------------------

1 0

APC document numbers
by Sakae OKUBO 06 Apr '98

06 Apr '98

Dear Mr. Kawahara Mr. Harasakai and Mr. Sakai, In response to your request, APC-1357, 1358 and 1359 have been allocated to your contributions as attached. Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151-0053 Japan or okubo(a)mxz.meshnet.or.jp ******************************************************************** ----------------------------------------------------------------------- APC- Source Provisional Title ----------------------------------------------------------------------- 1328 Siemens Proposal for Call Hold Supplementary service in H.323 (H.450.Hold) 1329 Siemens Proposal for Call Park/Call Pickup supplementary service in H.323 (H.450.Park+Pickup) 1330 Siemens Proposal for Call Waiting Supplementary Service H.323 (H.450.CallWaiting) 1331 RADVision A proposal for RTP/RTCP addresses use during the Fast Connect Procedure 1332 RADVision Remarks on H.225.0 1333 Editor Drat Amendment 5 to H.222.0 1334 Editor Draft Annex I to H.225.0 1335 Editor Darft H.245 V4 1336 Editor Darft H.310 V2 1337 Editor Draft H.bmultipoint 1338 Editor Draft Annex D to H.323 1339 PictureTel Proposals and General Comments for H.323 Annex C 1340 Mitel Message Waiting Indication Supplementary Service in H.323 1341 multiple Inter-Gatekeeper Communication Requirements (H.323 Annex G) 1342 ETSI Communication from EP TIPHON to ITU SG16 on Codec support for H.323 1343 MPEG Liaison response regarding DMIF 1344 Editor H.246 Work Plan and Discussion 1345 VideoServer/Intel Proposal for H.MediaMIB 1346 VideoServer Proposal for H.225 Call Signalling MIB 1347 VideoServer Proposal for H.225 RAS MIB 1348 VideoServer Proposal for H.245 MIB 1349 Cisco Proposal for H.323 Gatekeeper MIB 1350 VideoServer Proposal for H.323 Terminal MIB 1351 multiple Faster connect for H.323 terminals 1352 Editor Draft H.323 v2 Implementers Guide 1353 Intel Proposals and general comments for Inter-Gatekeeper Communications 1354 IBM Comment to the current H.323 endpoint registration procedure 1355 IBM Coding of the MultipointCapabilitys within the H2250Capability data structure 1356 Intel Proposal for Real Time Device Control in H.323 1357 NTT DoCoMo The support of MPEG-4 video in H.324 terminals 1358 Secretary of Meeting Host Organization Network configuration of Yokosuka Rapporteur Meeting 1359 Fujitsu Proposed addition to H.245 for the AAL1/5 conversion gateway capabilities -----------------------------------------------------------------------

1 0

Help for an announcement of computer setup at Yokosuka Rapporteur meeting
by Hidenobu Harasaki 05 Apr '98

05 Apr '98

Dear Q.11-14 Yokosuka Rapporteur meeting participants, I am sorry that this mail is not a contribution nor a meeting announcement. Today I need someone's help for computer setup announcement. AC power and 10Base-T port are available at Yokosuka Rapporteur meeting site. We will also prepare a DHCP server for easy IP address assignment, a filer server for document exchange and a router for the Internet access. I am now preparing a final meeting announcement, and I would like to include a section describing "How to setup your computer at the meeting site". But I am afraid whether the following announcement is adequate or not. ------------------------------------------------------------------------ 5. FILE SERVER and INTERNET ACCESS AC power (100 volt) and 10Base-T port are available in any conference room. DHCP server will automatically assign your IP address from private address space (i.e. 192.168.0.0/24). If your computer does not accept DHCP protocol, contact Mr. X for your IP address assignement. Setup microsoft network client and NetBIOS on a top of TCP/IP protocol, because the file server is Unix machine with Samba daemon. The workgroup and computer name of the server is "xxxx" and "yyyyyy", respectively. The meeting site is connected to the Internet with 128Kbps dedicated line. The router with network address translation (NAT) and IP masquerade functions will translate your private IP address to one from global IP addresses allocated from an internet provider. ------------------------------------------------------------------------ Q1. With the above announcement, can you setup your own laptop by yourself? Q2. Should I include the following detailed Windows95 setup procedure? Start -> Setup -> Control panel -> Network -> "TCP/IP -> your Eternet I/F" property -> IP address Q3. Is the above detailed procedure correct in Windows 95 English version? Q4. Is the description "setup microsoft network client and NetBIOS on a top of TCP/IP protocol" correct? Looking forward to your help. Hidenobu Harasaki harasaki(a)ccm.CL.nec.co.jp Principal Researcher C&C Media Research Labs., NEC Corporation Phone: +81 44 856 8083 Fax: +81 44 856 2232

1 0

Re: APC number
by Sakae OKUBO 03 Apr '98

03 Apr '98

Dear Mr. Kumar, In response to your request, APC-1356 has been allocated to your contribution as attached. Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151-0053 Japan or okubo(a)mxz.meshnet.or.jp ******************************************************************** ----------------------------------------------------------------------- APC- Source Provisional Title ----------------------------------------------------------------------- 1328 Siemens Proposal for Call Hold Supplementary service in H.323 (H.450.Hold) 1329 Siemens Proposal for Call Park/Call Pickup supplementary service in H.323 (H.450.Park+Pickup 1330 Siemens Proposal for Call Waiting Supplementary Service H.323 (H.450.CallWaiting) 1331 RADVision A proposal for RTP/RTCP addresses use during the Fast Connect Procedure 1332 RADVision Remarks on H.225.0 1333 Editor Drat Amendment 5 to H.222.0 1334 Editor Draft Annex I to H.225.0 1335 Editor Darft H.245 V4 1336 Editor Darft H.310 V2 1337 Editor Draft H.bmultipoint 1338 Editor Draft Annex D to H.323 1339 PictureTel Proposals and General Comments for H.323 Annex C 1340 Mitel Message Waiting Indication Supplementary Service in H.323 1341 multiple Inter-Gatekeeper Communication Requirements (H.323 Annex G) 1342 ETSI Communication from EP TIPHON to ITU SG16 on Codec support for H.323 1343 MPEG Liaison response regarding DMIF 1344 Editor H.246 Work Plan and Discussion 1345 VideoServer/Intel Proposal for H.MediaMIB 1346 VideoServer Proposal for H.225 Call Signalling MIB 1347 VideoServer Proposal for H.225 RAS MIB 1348 VideoServer Proposal for H.245 MIB 1349 Cisco Proposal for H.323 Gatekeeper MIB 1350 VideoServer Proposal for H.323 Terminal MIB 1351 multiple Faster connect for H.323 terminals 1352 Editor Draft H.323 v2 Implementers Guide 1353 Intel Proposals and general comments for Inter-Gatekeeper Communications 1354 IBM Comment to the current H.323 endpoint registration procedure 1355 IBM Coding of the MultipointCapabilitys within the H2250Capability data structure 1356 Intel Proposal for Real Time Device Control in H.323 -----------------------------------------------------------------------

1 0

Re: Document registration
by Sakae OKUBO 03 Apr '98

03 Apr '98

Dear Mr. Truong, In response to your request, APC-1354, 1355 have been allocated to your contributions as attached. Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151-0053 Japan or okubo(a)mxz.meshnet.or.jp ******************************************************************** ----------------------------------------------------------------------- APC- Source Provisional Title ----------------------------------------------------------------------- 1328 Siemens Proposal for Call Hold Supplementary service in H.323 (H.450.Hold) 1329 Siemens Proposal for Call Park/Call Pickup supplementary service in H.323 (H.450.Park+Pickup 1330 Siemens Proposal for Call Waiting Supplementary Service H.323 (H.450.CallWaiting) 1331 RADVision A proposal for RTP/RTCP addresses use during the Fast Connect Procedure 1332 RADVision Remarks on H.225.0 1333 Editor Drat Amendment 5 to H.222.0 1334 Editor Draft Annex I to H.225.0 1335 Editor Darft H.245 V4 1336 Editor Darft H.310 V2 1337 Editor Draft H.bmultipoint 1338 Editor Draft Annex D to H.323 1339 PictureTel Proposals and General Comments for H.323 Annex C 1340 Mitel Message Waiting Indication Supplementary Service in H.323 1341 multiple Inter-Gatekeeper Communication Requirements (H.323 Annex G) 1342 ETSI Communication from EP TIPHON to ITU SG16 on Codec support for H.323 1343 MPEG Liaison response regarding DMIF 1344 Editor H.246 Work Plan and Discussion 1345 VideoServer/Intel Proposal for H.MediaMIB 1346 VideoServer Proposal for H.225 Call Signalling MIB 1347 VideoServer Proposal for H.225 RAS MIB 1348 VideoServer Proposal for H.245 MIB 1349 Cisco Proposal for H.323 Gatekeeper MIB 1350 VideoServer Proposal for H.323 Terminal MIB 1351 multiple Faster connect for H.323 terminals 1352 Editor Draft H.323 v2 Implementers Guide 1353 Intel Proposals and general comments for Inter-Gatekeeper Communications 1354 IBM Comment to the current H.323 endpoint registration procedure 1355 IBM Coding of the MultipointCapabilitys within the H2250Capability data structure -----------------------------------------------------------------------

1 0

Re: APC requests
by Sakae OKUBO 03 Apr '98

03 Apr '98

Dear Jim, In response to your request, APC-1352, 1353 have been allocated to your contributions as attached. Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151-0053 Japan or okubo(a)mxz.meshnet.or.jp ******************************************************************** --------------------------------------------------------------------- APC- Source Provisional Title --------------------------------------------------------------------- 1328 Siemens Proposal for Call Hold Supplementary service in H.323 (H.450.Hold) 1329 Siemens Proposal for Call Park/Call Pickup supplementary service in H.323 (H.450.Park+Pickup 1330 Siemens Proposal for Call Waiting Supplementary Service H.323 (H.450.CallWaiting) 1331 RADVision A proposal for RTP/RTCP addresses use during the Fast Connect Procedure 1332 RADVision Remarks on H.225.0 1333 Editor Drat Amendment 5 to H.222.0 1334 Editor Draft Annex I to H.225.0 1335 Editor Darft H.245 V4 1336 Editor Darft H.310 V2 1337 Editor Draft H.bmultipoint 1338 Editor Draft Annex D to H.323 1339 PictureTel Proposals and General Comments for H.323 Annex C 1340 Mitel Message Waiting Indication Supplementary Service in H.323 1341 multiple Inter-Gatekeeper Communication Requirements (H.323 Annex G) 1342 ETSI Communication from EP TIPHON to ITU SG16 on Codec support for H.323 1343 MPEG Liaison response regarding DMIF 1344 Editor H.246 Work Plan and Discussion 1345 VideoServer/Intel Proposal for H.MediaMIB 1346 VideoServer Proposal for H.225 Call Signalling MIB 1347 VideoServer Proposal for H.225 RAS MIB 1348 VideoServer Proposal for H.245 MIB 1349 Cisco Proposal for H.323 Gatekeeper MIB 1350 VideoServer Proposal for H.323 Terminal MIB 1351 multiple Faster connect for H.323 terminals 1352 Editor Draft H.323 v2 Implementers Guide 1353 Intel Proposals and general comments for Inter-Gatekeeper Communications ---------------------------------------------------------------------

1 0

APC numbered documents for the Yokosuka meeting
by Sakae OKUBO 02 Apr '98

02 Apr '98

Dear Q.12-14/16 colleagues and meeting participants, 1. To those who intend to submit contributions Please advise me of your document source and title, then I will allocate APC-13nn number. Please use okubo(a)gctech.co.jp AND okubo(a)mxz.meshnet.or.jp due to the change of GCL Internet environments. My particular request is that if you have sent me your request of document numbers these 30 hours and have not received my response, please send it again to okubo(a)mxz.meshnet.or.jp. It seems that all incoming mails to okubo(a)gctech.co.jp are now in the spool and will be dispatched some time later. 2. To those who upload contributions Please upload them to ftp://standard.pictel.com/avc-site/Incoming then I will move them to ../9804_Yok directory after virus scanning, zipping, renaming if necessary. 3. To those who retrieve contributions They are available either at /9804_Yok directory or /Incoming directory. Please be advised that /9804_Yok/9804_Yok.html shows all the contributions. If the document number indicates link, then it has already been submitted and retrievable. Very recent submissions may be still at /Incoming directory. Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151-0053 Japan or okubo(a)mxz.meshnet.or.jp ********************************************************************

1 0

Re: APC number
by Sakae OKUBO 01 Apr '98

01 Apr '98

Dear Mr. Kimchi In response to your request, APC-1351 has been allocated to your contribution as attached. Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151-0053 Japan or okubo(a)mxz.meshnet.or.jp ******************************************************************** --------------------------------------------------------------------- APC- Source Provisional Title --------------------------------------------------------------------- 1328 Siemens Proposal for Call Hold Supplementary service in H.323 (H.450.Hold) 1329 Siemens Proposal for Call Park/Call Pickup supplementary service in H.323 (H.450.Park+Pickup 1330 Siemens Proposal for Call Waiting Supplementary Service H.323 (H.450.CallWaiting) 1331 RADVision A proposal for RTP/RTCP addresses use during the Fast Connect Procedure 1332 RADVision Remarks on H.225.0 1333 Editor Drat Amendment 5 to H.222.0 1334 Editor Draft Annex I to H.225.0 1335 Editor Darft H.245 V4 1336 Editor Darft H.310 V2 1337 Editor Draft H.bmultipoint 1338 Editor Draft Annex D to H.323 1339 PictureTel Proposals and General Comments for H.323 Annex C 1340 Mitel Message Waiting Indication Supplementary Service in H.323 1341 multiple Inter-Gatekeeper Communication Requirements (H.323 Annex G) 1342 ETSI Communication from EP TIPHON to ITU SG16 on Codec support for H.323 1343 MPEG Liaison response regarding DMIF 1344 Editor H.246 Work Plan and Discussion 1345 VideoServer/Intel Proposal for H.MediaMIB 1346 VideoServer Proposal for H.225 Call Signalling MIB 1347 VideoServer Proposal for H.225 RAS MIB 1348 VideoServer Proposal for H.245 MIB 1349 Cisco Proposal for H.323 Gatekeeper MIB 1350 VideoServer Proposal for H.323 Terminal MIB 1351 multiple Faster connect for H.323 terminals ---------------------------------------------------------------------

1 0