- sg16-avd - lists.packetizer.com

Upload APC-1553
by Roni Even 10 Feb '99

10 Feb '99

MR Okubo, Sorry for the delay. I uploaded the APC-1553 to the pictel incoming folder. Roni Even ********************************************** Roni Even VP Product Marketing Accord Video Telecommunication Email: roni_e(a)accord.co.il Tel: +972-3-9251412 Fax: +972-3-9211571 *************************************************** > -----Original Message----- > From: Sakae OKUBO [SMTP:okubo@GITI.OR.JP] > Sent: Wednesday, February 10, 1999 6:24 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Documents yet to be uploaded > > Dear Monterey meeting contributors, > > At 13:00 Wednesday (Tokyo time), there are several documents missing > in the > ftp site as in the attached list. As to * marked documents, I received > advice of understandable reasons for delay. > > Please upload (again) your documents if they are listed below. > Apologies in > case I mishandled them. > > Best regards, > > Sakae OKUBO (Mr.) > *********************************************************** > Waseda Research Center > Telecommunications Advancement Organization of Japan (TAO) > 5th Floor, Nishi-Waseda Bldg. > 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo > 169-0051 Japan > Tel: +81 3 5286 3830 > Fax: +81 3 5287 7287 > e-mail: okubo(a)giti.or.jp > *********************************************************** > > Documents yet to be uploaded (13:00 Wednesday 10 Febraury, Tokyo) > * to be posted after the ATMF meeting this week > ** to be posted after reflecting the current proposals > *** to be posted Thursday night > ---------------------------------------------------------------------- > APC- Source Title > ---------------------------------------------------------------------- > 1496 Editors (D Gurle, G Kimchi) > Editorial changes to H.323 Annex E text > 1501 Editor (J Ott) H.323 Annex F White Paper (for a final review) > 1502 Teles OpenLogicalChannel structures for Annex F > 1510 Madge Networks cryptoTokens in H.225.0 Annex G > *1516 ATMF "H.323 Over ATM Media Transport" specification > *1517 ATMF H.245 codepoint for transport of compressed RTP > over AAL5 > *1518 ATMF GIT for the transporting the portNumber > 1524 BT, Mitel H.245 Pre-Opened Channels > **1544 Editor (G Freundlich) > Draft H.225.0 V3 > ***1547 Chairman, IETF Megaco Working Group > Media Gateway Control Protocol Architecture and > Requirements > 1548 PictureTel Suggested changes to H.341(H.MediaMIB) > 1549 PictureTel, VideoServer > Correction of problems related to MCV in H.230 > and H.243 > 1553 Accord Video Telecommunication > H.323 changes for multi point support > ----------------------------------------------------------------------

1 0

apc-1500 uploaded
by Bryan Hill 10 Feb '99

10 Feb '99

Mr. Okubo, I have uploaded apc-1500.zip to the avc-site/incoming directory. Best Regards, Bryan _________________________________________________________ Bryan Hill VideoServer Inc. (781) 505-2159 bhill(a)videoserver.com <mailto:bhill@videoserver.com>

2 1

SG16 meeting in Santiago
by Sakae OKUBO 10 Feb '99

10 Feb '99

Dear Q.12-14/16 experts, WP2/16 Rapporteurs has received the following message from Mr. Tosco to confirm the next SG16 meeting being held in Chile during 18-28 May 1999 (17 May is planned for a seminar). FT> I am glad to inform you that on the night of Friday 5 February 1999 FT> Mr. Bigi received the confirmation of the invitation from Chile and FT> the information needed for preparing the convening letter. Best regards, Sakae OKUBO (Mr.) *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0

Documents yet to be uploaded
by Sakae OKUBO 09 Feb '99

09 Feb '99

Dear Monterey meeting contributors, At 13:00 Wednesday (Tokyo time), there are several documents missing in the ftp site as in the attached list. As to * marked documents, I received advice of understandable reasons for delay. Please upload (again) your documents if they are listed below. Apologies in case I mishandled them. Best regards, Sakae OKUBO (Mr.) *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** Documents yet to be uploaded (13:00 Wednesday 10 Febraury, Tokyo) * to be posted after the ATMF meeting this week ** to be posted after reflecting the current proposals *** to be posted Thursday night ---------------------------------------------------------------------- APC- Source Title ---------------------------------------------------------------------- 1496 Editors (D Gurle, G Kimchi) Editorial changes to H.323 Annex E text 1501 Editor (J Ott) H.323 Annex F White Paper (for a final review) 1502 Teles OpenLogicalChannel structures for Annex F 1510 Madge Networks cryptoTokens in H.225.0 Annex G *1516 ATMF "H.323 Over ATM Media Transport" specification *1517 ATMF H.245 codepoint for transport of compressed RTP over AAL5 *1518 ATMF GIT for the transporting the portNumber 1524 BT, Mitel H.245 Pre-Opened Channels **1544 Editor (G Freundlich) Draft H.225.0 V3 ***1547 Chairman, IETF Megaco Working Group Media Gateway Control Protocol Architecture and Requirements 1548 PictureTel Suggested changes to H.341(H.MediaMIB) 1549 PictureTel, VideoServer Correction of problems related to MCV in H.230 and H.243 1553 Accord Video Telecommunication H.323 changes for multi point support ----------------------------------------------------------------------

1 0

Maximize Your Website's Traffic!!
by jfillmore23＠MYMAIL.COM 09 Feb '99

09 Feb '99

Maximize your website's traffic. INCREASE YOUR SEARCH ENGINE RANK! If your Web site isn't getting the traffic it should, it's likely that it's not ranked well on the major Internet search engines. According to recent Internet E-commerce studies, over 90% of consumers find the Web sites they visit by using eight major search engines, which are Yahoo!, Excite, AltaVista, Infoseek, Lycos, Web Crawler, HotBot, and Northern Light. If your website isn't located in the top-30 listings of these engines, chances are your site will never be seen. The single most important thing you can do to increase your Web site's traffic is to increase your search engine ranking. ------------- "PUT YOUR NAME IN LIGHTS -- List your business with search engines to make sure potential customers can find it." -- BIZ Excite, PC Computing magazine, November 1998 ------------- THE BASICS: HOW SEARCH ENGINES RANK YOUR SITE When you submit your website to a search engine to be indexed in its database, it sends a "robot" to scan your page. Using complex algorithms to rank your page for keyword relevance, the "robot" determines whether you'll be ranked number 1 or 1,000,000 when potential visitors conduct a search looking for sites like yours. Because the search engines are constantly changing their algorithms to provide users with the best possible search results, there's only one true solution to high search engine placement--us. In short, submission alone isn't enough. *Good search engine ranking* is critical to your site's success. ------------- HERE'S WHAT WE DO -- A UNIQUE, SUCCESSFUL APPROACH In order to counter the ever-changing search engine algorithms, we create an entire series of "entry pages" that are optimized for the search engines--one for every keyword (or keyword phrase) that you provide. Each entry page is optimized for a different set of algorithm variables. In other words, instead of having only *one* page struggling to rank well on all engines, we create separate, search engine-specific entry pages for each keyword. As a result, your pages rank well because they contain information relevant to search queries that are related to your industry. ------------- HOW ENTRY PAGES AFFECT YOUR WEB SITE'S CURRENT STRUCTURE Put simply, they don't. When creating entry pages we *do not* make any changes to the existing structure, content, or functionality of your current site. The entry pages act as a welcome screen for your Web site when people enter from your highly ranked link on the search engine. The pages will say a few introductory words about your site, which are keyword and/or keyword phrase rich, and then provide a link that asks the visitor to "Click Here To Enter," which moves them directly to your current homepage. ------------ HERE'S WHAT WE DON'T *EVER* DO TO HELP YOUR SEARCH ENGINE RANK We *will not* build pages for irrelevant--yet "popular"--keywords. Also, we will *never* "spamdex" pages. "Spamdexing" is "stuffing" a Web page full of words for the search engine's robots. You may have seen spamdexing, which is placing many words in the same text color as a background onto a Web page. Spamdexing will actually get your pages "kicked" from search engine indexes. What we *will* do is simply present very relevant keywords for your site to the search engines in the way that they "like" to see it. ------------- "It's simple: If they can't find you on the search engines, they can't buy from you." -- J. LeRoss, Internet Sales Consultant ------------ HOW WELL DOES THE SERVICE WORK? We'll send you a detailed report of your current search engine ranking on "The Big Six" engines before we begin. Then, once your new entry pages have been indexed, we'll send you a second report showing how they've ranked. Here's a sampling of some results we've acheived for previous clients. (These examples are for competitive keywords--not just obscure words on which no one is conducting searches.) <> 6 top-10 rankings on Infoseek for different relevant keywords <> 18 top-10 rankings across the major search engines <> 3 top-10 rankings on Alta Vista for one keyword <> 16 total *number one* rankings <> 40 top-30 rankings, spread across the different engines. <> 1 to 2 hits per week increased to 500 per day <> 45,000 hits per month grew to 108,000. ------------ HOW MUCH DOES YOUR SERVICE COST? Our basic services start at only $385. The basic package includes: <> Construction of optimized entry pages for up to 20 keywords -- This gives you good "coverage" in your industry <> Submission of the keyword-dense entry pages to the "Big Six" search engines When you contact us, ask about other services we provide that may be able to help your Internet initiatives succeed. We have special services that can be tailored for your specific Internet marketing needs. ------------ HOW DO I GET STARTED? <> Call us--we'll answer any questions you may have and provide a no-cost initial consultation. (888) 283-2050 <> Submit your keywords and/or keyword phrases (up to 20) to us ------------ COMMENTS FROM CLIENTS "Frankly, I'm impressed with the foregoing. So many solicitations from email sources turn out to be a phone line that hooks up to a voice mail system that is designed to give the impression of size, and people who never return phone calls/messages. . . So its a pleasant surprise to find that someone at the other end is really operating as a business!!!" --Alan B. "Incredible! Our site is now receiving more hits in a day than we used to get in an entire month. [My boss] is still eating his words." -- Bob W. "I knew the search engines were a fantastic marketing tool, but my company simply didn't have the time to devote to search engine placement. It has proven to be the best money we've ever spent on marketing." -- Shelley H. "I worked for weeks to get good search engine placement, but I could never crack the top 80 . . . my site was deserted. Within a month [after using your service], I'd had more hits than I'd had in the last year. I wouldn't believe it if it hadn't happened to me." -- Chris L. ------------ OUR JOB: INCREASE YOUR WEB SITE'S RANKING. We can't guarantee that better ranking will increase the number of visitors that "surf" to your Web site. Some highly-ranked websites still don't get much traffic--much depends on your particular industry and choice of keywords. However, high rankings, in most cases, do mean increased Web site traffic. And, we have never failed to increase a client's ranking. Ever. ------------ CONTACT A REPRESENTATIVE: Search Engine Success Group - Call us at: (888) 283-2050 ----------------------- If you've received this message in error--and are not interested in our services--please click reply or call, (888)-248-2236, and we'll remove you from our list.

1 0

APC-1537 and APC-1538 Uploaded
by Tom-PT Taylor 09 Feb '99

09 Feb '99

APC-1537 and APC-1538 have been uploaded to the Incoming directory. APC-1547 should be available Thursday night. Tom Taylor E-mail: taylor(a)nortelnetworks.com (internally Tom-PT Taylor) Tel.: +1 613 765 4167 (internally 395-4167) FAX: +1 613 763 7236 (internally 393-7236)

1 0

None
by Bicakcilar A.S. - T.Alayli 09 Feb '99

09 Feb '99

Dear Responsible person, We produce some surgical equipment, such as surgical operation lamps. But the reflectors that we use for our operation lamps are, not as good as we want to. If you have some reflectors that we can use for our operation lamps, please inform me, as soon as possible.If you wanna fax me; Fax:00(90) 212 635 12 10 Thanks for your interest, Tuba ALAYLI Product Manager talayli(a)bicakcilar.com

1 0

Re: Relationship of H.323 and H.245 versions
by Pete Cordell 09 Feb '99

09 Feb '99

Dear All, Just to clarify why the original question was asked,.... It can be readily observed that functionality can be added to H.245 without affecting H.225. (For example, object oriented caps which enables H.RDC etc) They are also functionally separate items. In telco parlance (sorry!) H.225 is call control (or user invitation etc) and H.245 is bearer control (or media control). It is quite legitimate for them to evolve at different paces as to a large degree they are orthogonal items. At a technical level I can see no benefit from inferring the version number of one from the version number of the other (any examples welcome) as these are basically two functional sub-systems working autonomously with only loose coupling (e.g. start, stop etc). Also, as a gatekeeper can do call re-routing as defined in H.450 - assuming that the gatekeeper wants to relay messages as much as possible to allow the full functionality of the attached endpoints to be realised and not dumb-down the messaging to its level - an endpoint may well receive different versions of H.245 as the life of the call evolves (e.g. first connect to IVR, then route to agent, then connect to sales etc). In this case inferring the H.245 version of the endpoint that you are connected to, say, third in a set of re-routes from the H.225 version of the first endpoint you are connected to is totally bogus. However, to make life easier, if for marketing/procurement purposes alone, it does make sense for an H.323 version to require a minimum level of support from H.225 and H.245. As H.323 and H.225 are intimately linked, saying that the H.323 version is one and the same as the H.225 version is no problem. However, in a technology that is in its infancy and still trying to find its feet in terms of how people want to use it, it seems unreasonable to link H.245 versions explicitly in with the H.225 issue cycle if modifying H.245 allows more timely adaptation to perceived evolving market needs. For this reason I believe that the relationship of the H.245 version should be of the "or later" type so that exploitation of enhancements to H.245 do not need to wait for a new issue of H.323. As an example of why this is attractive, it may be the case that there are no changes needed to justify an H.225 version 4. However, enhancements may be made to H.245 after H.225 version 3 is issued. What would we do with H.323/H.225 in this case? Regards, Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Santo Wiryaman[SMTP:swiryaman@VIDEOSERVER.COM] >Reply To: Mailing list for parties associated with ITU-T Study Group 16 >Sent: 05 February 1999 13:36 >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Re: Relationship of H.323 and H.245 versions > >Jim, >I do support this position. Thanks. >-santo > >> -----Original Message----- >> From: Jim Toga [SMTP:jim.toga@INTEL.COM] >> Sent: Thursday, February 04, 1999 6:29 PM >> To: ITU-SG16(a)mailbag.cps.intel.com >> Subject: Re: Relationship of H.323 and H.245 versions >> >> Chris (and others) >> >> I'm penning up text (proposed) for the implementers guide. (Which I will >> post here for comments by tommorow) At this point I'm going to go with >> Paul's suggestion below even in light of your comments. Here's the >> reasoning: >> >> If the GK is routing H.225.0 and _not_ H.245 (which is for further study, >> btw) then is should _not_ be messing with any syntax/encoding that it >> absolutely does not understand (for exactly this reason). If it is >> routing >> both, then it can 'proxy' and give what-ever 'face' revision to the >> protocol that it wants (as long as it is consistent). >> >> I think what we gain by constraining the mix'n-match is consistency and >> predictability. The cost is that, as we revise the 'umbrella' H.323 >> Recommendation - products may have to support 'sets' of H.225.0/H.245 to >> play in multiple worlds. I don't see any great _system_ advantage to >> allowing vendors to provide a complete hodge-podge of stack revisions. >> (This is orthogonal to allowing vendors to provide a hodge-podge of stack >> support - H.235, annex E, annex G etc...) >> >> Regards, >> jimt. >> >> >> At 12:36 PM 2/1/99 -0000, you wrote: >> >Paul (and others), >> > >> >Consider the case of a v1 gatekeeper routing H.225.0 and NOT H.245 in a >> call >> >between two v2 endpoints. The gatekeeper certainly MAY relegate the >> H.225.0 >> >messages to v1. This may be a policy decision, or it may be due to stack >> >capabilities. Note that the gatekeeper may not always desire to relay >> >messages entirely transparently, and is entirely within its rights to >> make >> >this sort of alteration (although people writing H.323 stacks for >> >gatekeepers would probably be well advised to implement relaying of >> messages >> >or message fragments). Certainly the standard should not mandate that >> >message relay should be entirely transparent. Anyway, the upshot of this >> is >> >that all H.225.0 messages in the call will be relegated to v1 by the >> >gatekeeper. The H.245 session runs directly end-to-end and will hence be >> >version 3, so both endpoints in the call need to be able to cope with an >> >H.245 session of a different version from that implied by the H.225.0 >> >session. >> > >> >Similar discrepancies may occur in the opposite direction (later version >> of >> >H.225.0 than H.245) for similar, but marginally more complex reasons. >> > >> >So what do we gain by insisting on an endpoint supporting EXACTLY version >> 3 >> >of H.245 if it happens to be EXACTLY version 2 of H.225.0 and vice versa? >> >Although I agree that it is what is currently specified I'm unconvinced >> it >> >buys us anything. >> > >> >Regards, >> >Chris >> > >> >> -----Original Message----- >> >> From: Paul Long [mailto:Plong@SMITHMICRO.COM] >> >> Sent: 29 January 1999 8:09 >> >> To: ITU-SG16(a)MAILBAG.INTEL.COM >> >> Subject: Re: Relationship of H.323 and H.245 versions >> >> >> >> >> >> Gary, >> >> >> >> You be the judge: >> >> >> >> Summary/H.323v2: "Products claiming compliance with Version 2 >> >> of H.323 shall >> >> comply with all of the mandatory requirements of this >> >> document, H.323 (1998), >> >> which references H.225.0 (1998) and H.245 (1998). Version 2 >> >> products can be >> >> identified by H.225.0 messages containing a >> >> protocolIdentifier = {itu-t (0) >> >> recommendation (0) h (8) 2250 version (0) 2} and H.225.0 >> >> messages containing a >> >> protocolIdentifier = {itu-t (0) recommendation (0) h (8) 245 >> >> version (0) 3}." >> >> >> >> Assuming this text is normative, H.323v2 uses H.225.0v2 and >> >> H.245v3. Period. >> >> >> >> IMO, we will be asking for big trouble if we at some point >> >> decide that one can >> >> mix and match versions and even use subsets or supersets of a >> >> particular >> >> version. Whatever interoperability problems we have now will >> >> be magnified many >> >> times over if we head down that slippery slope. >> >> >> >> Paul Long >> >> Smith Micro Software, Inc. >> >> >> >> -----Original Message----- >> >> From: Gary A. Thom [SMTP:gthom@DELTA-INFO.COM] >> >> Sent: Friday, January 29, 1999 1:37 PM >> >> To: ITU-SG16(a)MAILBAG.INTEL.COM >> >> Subject: Re: Relationship of H.323 and H.245 versions >> >> >> >> One more question???? >> >> >> >> >> >> > Dave, >> >> > >> >> > Sorry, but I won't be in Monterey. >> >> > >> >> > I agree with what you say, except that I would go >> >> further and state >> >> that there >> >> > is always a one-to-one mapping between H.225.0 and H.245 >> >> protocolIdentifiers >> >> > via H.323. For example, >> >> > >> >> > H.225.0v1 => H.323v1 => H.245v2 and H.245v2 => >> >> H.323v1 => >> >> H.225.0v1 >> >> > H.225.0v2 => H.323v2 => H.245v3 and H.245v3 => >> >> H.323v2 => >> >> H.225.0v2 >> >> > >> >> > This is already implied by the Summary section of >> >> H.323 starting >> >> with version >> >> > 2. I think it's clear, but you could add >> >> clarification text if you >> >> like. IOW, >> >> > for example, an EP cannot use H.245v2 and H.225.0v2 >> >> in the same >> >> call. >> >> > >> >> >> >> But can H.225.0 V2 (H.323 V2) and H.245V4 (or 5) be >> >> used in the same >> >> call??? >> >> >> >> Gary >> >> >> >> ------------------------------------------------------ >> >> Name : Gary A. Thom >> >> Company: Delta Information Systems, Inc. >> >> Address: 300 Welsh Rd., Bldg 3 >> >> Horsham, PA 19044 USA >> >> Phone : +1-215-657-5270 Fax : +1-215-657-5273 >> >> E-mail : gthom(a)delta-info.com >> >> ------------------------------------------------------ >> >> >> > >> +1-503-264-8816(voice) Intel - Hillsboro, OR >> mailto:jim.toga@intel.com mailto:james.toga@ties.itu.int >> PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41 >

1 0

(no subject)
by Deepak Kudachi 09 Feb '99

09 Feb '99

subscribe itu-sg16 kudachid(a)mahindrabt.com Deepak kudachi

1 0

APC-1539
by Louis Christodoulides 09 Feb '99

09 Feb '99

Dear Mr. Okubo, I have uploaded APC-1539.zip in the avc-site/Incoming directory. regards, ------------ Louis Christodoulides tel:+44 171 728 1698 Inmarsat email: louis_christodoulides(a)inmarsat.org 99 City Road London EC1Y 1AX ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com **********************************************************************

1 0

Fwd: standard.pictel.com
by Sakae OKUBO 09 Feb '99

09 Feb '99

Dear Mr. Luthi, I wrote in my previous message, > I cannot login the PictureTel ftp site these three hours (around noon > Tuesday, Tokyo time). Something may be wrong with the server. but it is OK now (17:00 Tokyo time, Tuesday). Apologies for disturbing you. Best regards, Sakae OKUBO (Mr.) *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0

APC-1536/Q11-I-03 uploaded
by Hidenobu Harasaki 09 Feb '99

09 Feb '99

Dear Q.11 and Q.12-14 Experts, > I cannot login the PictureTel ftp site these three hours (around noon > Tuesday, Tokyo time). Something may be wrong with the server. The server is now up, and I have uploaded APC-1536/Q11-I-03. This contribution has Q.11 and Q.12-14 document numbers. Best regards, Hidenobu Harasaki harasaki(a)ccm.CL.nec.co.jp Manager, Research C&C Media Research Labs., NEC Corporation Phone: +81 44 856 8083 Fax: +81 44 856 2232

1 0

standard.pictel.com
by Sakae OKUBO 08 Feb '99

08 Feb '99

Dear Mr. Luthi, I cannot login the PictureTel ftp site these three hours (around noon Tuesday, Tokyo time). Something may be wrong with the server. Best regards, Sakae OKUBO (Mr.) *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0

APC-1522, APC-1523 available
by Dave Walker 08 Feb '99

08 Feb '99

Dear Colleagues, Please find attached zip files containing APC-1522 and APC-1523. Network problems are preventing me from uploading to the PictureTel site. I will do so as soon as possible. Regards, Dave Walker Mitel Corp.

1 0

Final list of input contributions
by Sakae OKUBO 08 Feb '99

08 Feb '99

Dear Q.12-14/16 experts, I have completed the list of input documents for the Monterey meeting as attached by assigning APC-1539 to Louis Christodoulides, Inmarsat (this is reuse of a withdrawn contribution) and APC-1553 to Roni Even, Accord. Please all the contributors upload your contributions as soon as possible so that concerned members can review them in advance of the meeting. Best regards, Sakae OKUBO (Mr.) *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** Documents for the Q.12-14/16 Monterey meeting (15-18 February 1999) ---------------------------------------------------------------------- APC- Source Title ---------------------------------------------------------------------- 1486 SG11 Q.20/11 DSS2 protocol provision of adaptive timing recovery used for transmitting clock 1487 SG9 Q.31/9 Progress report on Webcasting 1488 MPEG Liaison statement from SC 29/WG 11 to ITU-T SG 16/Q 11, 12, 13 and 14 on MPEG-4 Systems on H.32X 1489 MPEG Liaison statement from SC 29/WG 11 to ITU-T SG 16/Q11, 12, 13, and 14 on MPEG-4 Audio on H.32X 1490 MPEG Liaison statement from SC 29/WG 11 to ITU-T SG 16/Q12 on Common Text Recommendations 1491 Nokia GSM in H.323 1492 AT&T H.323 Differentiated Services and Their Protocol Architectures 1493 AT&T Viewgraphs presentation for "H.323 Differentiated Services and Their Protocol Architectures" 1494 AT&T TIA/EIA IS-641 Enhanced Full-Rate Speech Codec for H.323 1495 Editor (G Kajos) Changes to H.341 Annexes 1496 Editors (D Gurle, G Kimchi) Editorial changes to H.323 Annex E text 1497 TIPHON Requirements for a Protocol at Reference Point N: Media Gateway Controller to Media Gateway 1498 VTEL H.323 QoS (Quality of Service) in the Policy Based Network 1499 VTEL Slides Presentation for H.323 QoS (Quality of Service) in the Policy Based Network 1500 Editor (B Hill) Gateway Control Protocol H.GCP 1501 Editor (J Ott) H.323 Annex F White Paper (for a final review) 1502 Teles OpenLogicalChannel structures for Annex F 1503 PTS Sweden H.323 Annex "Text", Text Conversation Capable SUD 1504 PTS Sweden Text conversation in H.323 1505 Editor (M Korpi) Draft H.450.8 - Conference out of Consultation Supplementary Service for H.323 1506 Siemens CallIdentifier and ConferenceIdentifier value setting in H.450.2and H.450.3 1507 PictureTel Fixing inconsistency between Annex E and H.283 and Annex G 1508 Chairman WP2/13 Status report on AAL2 signalling and switching 1509 Q12 Rapporteur Draft H.321 Implementors Guide 1510 Madge Networks cryptoTokens in H.225.0 Annex G 1511 Madge Networks Master/slave determination for inter-zone calls in H.323 environments where gatekeepers are routing H.245 signalling 1512 Madge Networks Submissions for the H.323 implementer's guide 1513 Ascend Extension Proposals for Gateway MIB of H.341 1514 Siemens Comparison of Tunneling and Interworking 1515 Siemens H.450.x - Tunneling of External protocols 1516 ATMF "H.323 Over ATM Media Transport" specification 1517 ATMF H.245 codepoint for transport of compressed RTP over AAL5 1518 ATMF GIT for the transporting the portNumber 1519 Korea Telecom Dynamic Multicast Tree Building Procedure 1520 Nortel Networks Corrections to H.323 and H.245 regarding fast start procedures 1521 Bosch, Ericsson, NTT DoCoMo Request to support full MPEG-4 functionality in H.324 terminals 1522 Mitel Additions to the H.323 Implementors Guide 1523 Mitel Comments on H.323 Annex F 1524 BT, Mitel H.245 Pre-Opened Channels 1525 Editor (G Fruendlich) H.225.0 Annex G white draft from the editor 1526 Editor (G Fruendlich) H.225.0 Annex G Clarifications and Improvements 1527 Lucent Caller ID Support 1528 Lucent Name Identification Features 1529 Lucent Media Device Control Protocol (MDCP) 1530 Lucent Support for Wireless Coders in H.323 1531 Lucent ISUP-Based Signaling for H.225 Control 1532 TAO Consideration of MPEG-2 stream packetization 1533 Editor (J Toga) Proposed text for H.323 Implementers Guide 1534 LM Ericsson Generic Mechanism for SS7 Transport in H323 based networks 1535 Siemens Need for Services and Procedures for Charging, Accounting and Advice of Charge in H.323 1536 NEC Layered coding and bitrate/bandwidth scalability for speech/audio coding 1537 Nortel Networks Requirements Across the B, C, and D Interfaces of a Decomposed Gateway 1538 Nortel Networks Requirements For Tunneling of ISUP and Other Protocols 1539 Inmarsat Satellite component of IMT-2000 1540 LM Ericsson Adding pricing information to terminals in call 1541 LM Ericsson Use of GRQ for inter-gatekeeper discovery 1542 LM Ericsson Extending the pregranted ARQ 1543 LM Ericsson Indication of H.323 Annex E capabilities to gatekeeper 1544 Editor (G Freundlich) Draft H.225.0 V3 1545 Lucent Internal Connection Model for Generic Media Gateways 1546 Ascend, ITXC, Lucent, OzEmail Interline, Siemens, VocalTec Comments on H.225.0 Annex G 1547 Chairman, IETF Megaco Working Group Media Gateway Control Protocol Architecture and Requirements 1548 PictureTel Suggested changes to H.341(H.MediaMIB) 1549 PictureTel, VideoServer Correction of problems related to MCV in H.230 and H.243 1550 Bellcore Media Gateway Control Protocol (MGCP) 1551 Nokia Comments to Annex G 1552 VocalTec Token OID for Crypto Tokens 1553 Accord Video Telecommunication H.323 changes for multi point support ----------------------------------------------------------------------

1 0

APC1533 Uploaded
by Jim Toga 08 Feb '99

08 Feb '99

All, The current rev of apc1533.zip is in the incoming directory. Regards, jimt. +1-503-264-8816(voice) Intel - Hillsboro, OR mailto:jim.toga@intel.com mailto:james.toga@ties.itu.int PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41

1 0

documents uploaded
by Glen Freundlich 08 Feb '99

08 Feb '99

Dear Mr. Okubo, I have uploaded APCs 1526, 1527, 1528, 1530, 1531, 1545, and 1546 into the Incoming directory of the avc ftp site. Regards, Glen Freundlich -- Glen Freundlich ggf(a)lucent.com Lucent Technologies office: +1 303 538 2899 11900 N. Pecos fax: +1 303 538 3907 Westminster, Colorado 80234 USA

1 0

Text conversation documents uploaded
by Gunnar Hellstrom 08 Feb '99

08 Feb '99

The documents APC1503a.zip and APC1504.zip, introducing text conversation in the H.323 environment have been uploaded to the incoming directory of the FTP-site for the upcoming q13 meeting. Best regards Gunnar Hellström Representing the National Post and Telecom Agency, Sweden. ------------------------------------------------ Gunnar Hellström Omnitor AB Alsnögatan 7, 4tr S-116 41 Stockholm SWEDEN Tel +46 751 100 501 Fax +46 8 556 002 06 E-mail: gunnar.hellstrom(a)omnitor.se WWW: www.omnitor.se ------------------------------------------------

1 0

APC-1550 uploaded
by Hong Liu 08 Feb '99

08 Feb '99

Hi, all, I have uploaded APC-1550.zip to the incoming directory. --Hong

1 0

Uploads
by Chris Purvis 08 Feb '99

08 Feb '99

APC-1511 uploaded as APC-1511b.doc (connectivity problems caused abortion of APC-1511.doc & APC-1511a.doc - sorry!) APC-1512 uploaded as APC-1512.doc -- Dr Chris Purvis - Senior Development Engineer, WAVE CC Software Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. ENGLAND Phone: +44 1753 661 359 email: cpurvis(a)madge.com

1 0

Re: Implementers Guide- pls review
by Chris Purvis 08 Feb '99

08 Feb '99

Jim (and all interested parties), > My comments below... (I'm cc' this sg16 list so that others > will understand the 'tweaks' from what had been posted > previously) Fine. >> 1. Your reworking of the UDP Port usage question appears to be >> self-inconsistent and talks round the fundamental problem >> rather than fixing >> it (it both sanctions and forbids the use of port 1718 for >> unicast LRQ). >> The essential problem is that the usage of port 1718 is NOT >> directly related to the discovery issue. I believe my solution >> is clearer as well as requiring less in the way of changes in >> H.225.0. > I thought the fundamental problem was that a receiving GK had > no reliable way to detect whether a message had arrived via > multicast or unicast. Mythinking was that the > multicastaddress:1718 VS the localaddress:1718, would > be enough of a differentiator. In any case port 1719 was > always relegated to unicast. The point that came up at interop was that many IP stacks do not communicate to the app above them the difference between receiving on multicastaddress:1718 and localaddress:1718 - they map to sockets entirely based on port number. Hence to gatekeepers running on these IP stacks, messages received on localaddress:1718 will look like multicast messages. > I see your point, but I believe we cannot arbitrarily make > unicast on port 1718 'illegal.' It is tighter ( and > therefor not backward compatible) with current v1 and v2 > specs. I also do not know the impact would be on existing > products. I guess I would be more comfortable with a > (strong) _should_ with respect to multi-cast only on port > 1718. This by the way is why there is _should_ statement > in the new existing text that I sent out. > I will make these changes and see if they are acceptable by others. How about a "shall" on transmitting on port 1718 for multicast, 1719 for unicast - but also require that gatekeepers will listen on both for unicast packets. The point is that with many IP stacks the gatekeeper can do no better than guess, but we might as well require future endpoints to give gatekeepers the best possible chance to guess right! I would also suggest that continuing to call port 1718 the "UDP Discovery Port" and then giving example of LRQs (which are NOT discovery messages as I understand the term) being sent there will be rather confusing to someone reading the standard for the first time! How about adding some text to my proposed solution, leaving it something like this (I quote the whole lot because not everyone's seen what I sent you before...): ---start soln--- Bring the standard into line with the most common usage by replacing the table from H.225.0 section 19.1.1.1 with the following: UDP Address for multicast communication with gatekeepers: 224.0.1.41 UDP port for multicast communication with gatekeepers: 1718 UDP port for unicast RAS communication where no other agreement exists: 1719 Note that "other agreement" may include registration of an endpoint with a gatekeeper. A gatekeeper should treat GRQ or LRQ messages unicast to port 1718 as if they had been received by multicast. ---end soln--- This asks gatekeeper to behave in the "best" way that is possible with many IP stacks. [Multiple aliases] > I am in favor of resloving this during the meeting. I take it from this that you'd like me to present this as part of my submission. Regards, Chris -- Dr Chris Purvis - Senior Development Engineer, WAVE CC Software Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. ENGLAND Phone: +44 1753 661 359 email: cpurvis(a)madge.com

1 0

Re: Implementers Guide- pls review
by Jim Toga 08 Feb '99

08 Feb '99

Frank Thanks for the text. I will use it instead of my poorer attempt.... Regards, jimt. At 11:40 AM 2/8/99 +0100, Derks, Frank wrote: >Hi Jim, > >I just had a quick look at the text that you included for the description of >TPKT. I would like to suggest the following text as a replacement: > >"A TPKT is a packet format as defined in IETF RFC1006. It is used to delimit >individual messages (PDUs) within the TCP stream, which itself provides a >continuous stream of octets without explicit boundaries. A TPKT consists of >a one octet version number field, followed by a one octet reserved field, >followed by a two octet length field, followed by the actual data. The >version number field shall contain the value "3", the reserved field shall >contain the value "0". The length field shall contain the length of the >entire packet including the version number, the reserved and the length >fields as a 16-bit big-endian word." > >Frank > > >----------------------------------------------------- >Frank Derks |Tel +31 35 6893238 | >Advanced Development |Fax +31 35 6891030 | >Philip Business Communications |P.O. Box 32 | > |1200 JD Hilversum | > |The Netherlands | >----------------------------------------------------| >E-mail: mailto:f.derks@pbc.be.philips.com | >WWW: http://www.business-comms.be.philips.com | >----------------------------------------------------- > > <<Frank Derks (E-mail).vcf>> > > >Attachment Converted: "c:\users\jtoga\mail\J-attach\Frank Derks (E-mail)3.vcf" > +1-503-264-8816(voice) Intel - Hillsboro, OR mailto:jim.toga@intel.com mailto:james.toga@ties.itu.int PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41

1 0

Re: Implementers Guide- pls review
by Jim Toga 08 Feb '99

08 Feb '99

Chris, My comments below... (I'm cc' this sg16 list so that others will understand the 'tweaks' from what had been posted previously) Best Regards, jimt. At 12:18 PM 2/8/99 -0000, you wrote: >Jim, > >I've drawn up a list of proposals for the implementer's guide, which I was >planning to put in as my own contribution. It can remain as a separate >contribution for the meeting, or some or all of it can be subsumed into >yours, as you see fit. I've attached it to this mail. Specific comments: > >1. Your reworking of the UDP Port usage question appears to be >self-inconsistent and talks round the fundamental problem rather than fixing >it (it both sanctions and forbids the use of port 1718 for unicast LRQ). >The essential problem is that the usage of port 1718 is NOT directly related >to the discovery issue. I believe my solution is clearer as well as >requiring less in the way of changes in H.225.0. I thought the fundamental problem was that a receiving GK had no reliable way to detect whether a message had arrived via multicast or unicast. My thinking was that the multicastaddress:1718 VS the localaddress:1718, would be enough of a differentiator. In any case port 1719 was always relegated to unicast. I see your point, but I believe we cannot arbitrarily make unicast on port 1718 'illegal.' It is tighter ( and therefor not backward compatible) with current v1 and v2 specs. I also do not know the the impact would be on existing products. I guess I would be more comfortable with a (strong) _should_ with respect to multi-cast only on port 1718. This by the way is why there is _should_ statement in the new existing text that I sent out. I will make these changes and see if they are acceptable by others. > >2. I've drawn something up on the multiple aliases question. I think >something ought to be agreed and put into the guide asap - and I think this >will only happen by being presented to a meeting and argued over. I'm happy >for this, as something a bit controversial, to be kept as my separate >contribution, but I'd like to think there was some chance of getting it into >the guide at this cut in some form or other. I am in favor of resloving this during the meeting. >I'll put in my contribution, containing whatever you leave me, first thing >in MY morning tomorrow (ie the middle of tonight your time). > >Regards, >Chris >-- >Dr Chris Purvis - Senior Development Engineer, WAVE CC Software >Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. ENGLAND >Phone: +44 1753 661 359 email: cpurvis(a)madge.com > +1-503-264-8816(voice) Intel - Hillsboro, OR mailto:jim.toga@intel.com mailto:james.toga@ties.itu.int PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41

1 0

Re: TPKT in H.225.0
by Drage, Keith 08 Feb '99

08 Feb '99

ITU-T is not "reluctant" to create the references to external organisations. It has made a set of rules for such references, and has then failed so far to get them to work. The rules are contained in Recommendation A.5 published in 1998. ITU-T SG9 recently tried to use these rules, and fell foul of the very precise nature of these rules. The recent ITU-T SG chairmen's meeting discussed this, and I believe identified that the rules were not meant to be this restrictive, and not meant to be applied on a per recommendation / reference basis, i.e. once IETF had been identified as a suitable organisation fulfilling all the rules, it did not repeatedly need to prove its suitability. I understand SG9 will be attempting more Recommendation references to external organisations in the near future, and in ITU-T SG11, we will also be attempting to do this. Keith Drage Siemens Communication Systems Limited Nottingham UK > -----Original Message----- > From: Jim Toga [SMTP:jim.toga@INTEL.COM] > Sent: Thursday, February 04, 1999 4:04 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: TPKT in H.225.0 > > I am working on some (initial) text for the Implementers Guide. I > will > welcome additions/modifications at the Rapportours meeting...... > > > jimt. > > At 02:03 PM 2/4/99 +0100, Derks, Frank wrote: > >Hi Tom, > > > >I couldn't find it either and I suspect that it couldn't be in > because the > >ITU is very reluctant to reference any non-ITU material. Furthermore, > >RFC1006 encompasses a lot more than just the bit(s) that are used for > >H.225.0, so even referring to this RFC does not clarify it all. I > think some > >work should be spent on this. > > > >Frank > > > >-----Original Message----- > >From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] > >Sent: 02 February 1999 22:12 > >To: ITU-SG16(a)MAILBAG.INTEL.COM > >Subject: Re: TPKT in H.225.0 > > > > > >I'd swear the reference to RFC1006 used to be in H.225.0 Appendix D, > but I > >can't find it there now. > > > >> -----Original Message----- > >> From: Derks, Frank [SMTP:F.Derks@PBC.BE.PHILIPS.COM] > >> Sent: Tuesday, February 02, 1999 4:05 AM > >> To: ITU-SG16(a)MAILBAG.INTEL.COM > >> Subject: Re: TPKT in H.225.0 > >> > >> Hi Paul, > >> > >> I received two responses to my question, one from you and one from > Tom > >> Taylor. The fact that there are at least two people that know about > it > >> (and > >> several dozens more that have actually implemented the protocol > stacks), > >> makes it hard to believe that this is an "oversight" in the > >> recommendation. > >> In fact, not knowing about this makes it impossible to implement an > >> interoperable protocol stack! Shouldn't action be taken to get this > into > >> the > >> recommendation ASAP (e.g. through the Implementor's Guide)? > >> > >> Regards, > >> > >> Frank > >> > >> -----Original Message----- > >> From: Paul Long [mailto:Plong@SMITHMICRO.COM] > >> Sent: 01 February 1999 18:50 > >> To: ITU-SG16(a)MAILBAG.INTEL.COM > >> Subject: Re: TPKT in H.225.0 > >> > >> > >> TPKT is defined in RFC 1006. Not identifying TPKT was an oversight > that > >> has > >> never been fixed in the Recommendation. > >> > >> Paul Long > >> Smith Micro Software, Inc. > > > +1-503-264-8816(voice) Intel - Hillsboro, OR > mailto:jim.toga@intel.com mailto:james.toga@ties.itu.int > PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41

1 0

Monterey contributions uploaded
by Klaghofer Karl ICN IB NL IP 7 08 Feb '99

08 Feb '99

The following three contributions have been uploaded to the Incoming directory of the standard.pictel.com ftp site: APC-1505.zip APC-1506.zip APC-1535.zip Regards, Karl ------------------------------------------------ Karl Klaghofer, Siemens AG, Dpmt. ICN IB NL IP7 Hofmannstr. 51, D-81359 Munich, Germany Tel.: +49 89 722 31488, Fax.: +49 89 722 37629 e-mail: karl.klaghofer(a)vs.siemens.de

1 0