- sg16-avd - lists.packetizer.com

Re: contributions for Dublin meeting
by Orit Levin 18 Oct '01

18 Oct '01

Hello all! I have just uploaded the revised version of H.323 Annex O "Use of Internet Protocols with H.323 Systems" as an AVD-2118.zip to ftp://standard.pictel.com/avc-site/Incoming for your review. Best Regards, Orit Levin Chief Architect RADVISION Inc. TEL: +1.201.529.4300 x 230 FAX: +1.201.529.3516 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Document AVD-2139 uploaded
by Horvath Ernst 18 Oct '01

18 Oct '01

AVD-2139 Draft Rec. H.MMS.1 has been uploaded. Ernst Horvath Siemens AG ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Contributions on ETS Uploaded
by Folts, Harold 17 Oct '01

17 Oct '01

Greetings, I have uploaded two contributions for the Dublin meeting to the "Incoming" directory. They are as follows: ADV-2106R1 - Extensively revised white paper on the Emergency Telecommunications Service ADV-2108 - Security for ETS See you in Dublin Hal <<Harold (Hal) C. Folts (E-mail).vcf>>

1 0

contributions for Dublin meeting
by Glen Freundlich 16 Oct '01

16 Oct '01

Dear Colleagues, The current document list for the Dublin meeting can be found at ftp://standard.pictel.com/avc-site/0110_Dub/0110_Dub.htm; documents are at ftp://standard.pictel.com/avc-site/0110_Dub. Inactive links on document list indicate documents which have not yet been uploaded. This Friday (19 October) is the deadline for registering a document for the meeting. Please upload your documents by Monday, 22 October, to allow others time to review your documents. Regards, Glen Freundlich

1 0

Document AVD-2157 uploaded
by Horvath Ernst 16 Oct '01

16 Oct '01

AVD-2157 "Liaison from ECMA: Two new standards for interworking between H.323 and QSIG" has been uploaded to the /Incoming folder of the avc-site. The ZIP file contains three ECMA documents: two draft ECMA standards and a cover sheet. Ernst Horvath Siemens AG ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Implementors Guide not normative?
by Paul Long 11 Oct '01

11 Oct '01

(This is the continuation of a thread from the IETF reflector for RFC 3015, a.k.a. Megaco, since it really just relates to SG16. Note also that this thread also applies to H.323, et al.!) Christian, After further consultation and research, it appears that you are correct--the ITU-T IG is _not_ normative and never has been: ITU-T Recommendation A.3, Amendment 1 states: "2.10.10 implementors' guide: An implementors' guide is a document which records all identified defects (e.g. typographical errors, editorial errors, ambiguities, omissions or inconsistencies, and technical errors) associated with a Recommendation or a set of Recommendations and their status of correction, from their identification to final resolution. An implementors' guide is issued by the ITU-T following agreement by a Study Group. Typically, defect corrections are first collected in an implementors' guide and, at a time deemed appropriate by the Study Group, they are used to produce a corrigendum or are included as revisions to a Recommendation." So the IG is just a central place to temporarily record for public review things that 1. can be published in a corrigendum like the X.691 Corrigenda 1, 2, and 3 or 2. need to be fixed in the next revision, e.g., H.248v2. Until the contents of the H.248 IG is rolled into one or the other of these two ITU-T publications, it has no normative force. The immediate impact is that H.248v1 is defined solely by the Recommendation, warts and all. Until and unless an H.248 Corrigendum 1 is Decided, H.248v1 (06/00) is apparently not implementable. :-) We can work on a Corrigendum for v1 if we want an implementable v1 or just abandon v1 altogether and choose the second path by rolling the IG into H.248v2 as soon as possible. Another possibility for future revisions to H.248 is to add an explicit "forward reference" to the IG in the Recommendation so that the Recommendation itself makes the IG normative. Don't know if this'll fly with the ITU-T, though. NOTE: It doesn't really matter what "normative" means because that's not at issue. Use whatever word(s) you want, but the point is that the IG does not contain requirements, is not a standard, does not actually modify a Recommendation, and is therefore merely a peripheral, historical artifact of the standards-making ITU-T process. Paul Long ipDialog, Inc. -----Original Message----- From: megaco-admin(a)ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of Christian Groves Sent: Tuesday, October 09, 2001 10:40 PM To: Paul Long Cc: megaco(a)ietf.org Subject: Re: [Megaco] What exactly constitutes Version 1 ? Paul, >From my understanding (A series of recommendations) an IG is an historical document detailing the defect and the steps leading to its correction. An amendment/corrigenda to a recommendation performs the actual normative correction. Whilst I think IG is a practical way of detailing all the changes and has been the accepted method in sg16, the question is how do non-SG16 groups normatively refer to the IG? Another issue is that an IG is not translated for non-english speakers. They need to be able to do the updates too. The status of the IG is probably best discussed on the SG16 mailing list. However, if we issue a H248v2 then we don't have the above problems. Regards, Christian Paul Long wrote: > > Christian, > > The IG not normative? Back when H.324 was developed, its IG was definitely > not normative because it was truly an _implementer's guide_, like the name > indicates, and not a corregendum, like they are now. It was my understanding > that as of H.323, which would now include H.248, "IGs" became normative. > However, the only thing I can find that says that they are anything close to > normative is the statement in the IGs that, "[This document] must be read in > conjunction with the Recommendation to serve as an additional authorative > source of information for implementors." > > I've always been told that IGs are normative, that version X of a > Recommendation is defined by the Recommendation _and_ its corresponding IG, > so I suppose it comes down to how you interpret this statement. > Unfortunately, the Recommendations themselves do not make any reference to > their corresponding IG. > > Finally, I believe that it is the concensus that the IG is normative, based > on the statement I cited, above. > > Paul Long > ipDialog, Inc. > > -----Original Message----- > From: megaco-admin(a)ietf.org [mailto:megaco-admin@ietf.org]On Behalf Of > Christian Groves > Sent: Tuesday, October 09, 2001 8:03 PM > To: 'megaco(a)ietf.org' > Subject: Re: [Megaco] What exactly constitutes Version 1 ? > > What is the problem to limit features? The whole idea of the list and > contributions to SG16 is that proposals are presented, discussed and > accepted or not. It is this step that weeds out the harmful ideas. So I > don't buy that emotional argument. > > I don't agree that the implementors' guide just fixed a few bugs. Look > at the size of it now and it doesn't fix all problems ie. exceeding > message sizes. It has become unwieldly to use the original spec. We need > something that other standards bodies can reference. An implementors' > guide isn't normative. > > As for the new features they are fixing things that are needed in real > systems and its because of experience that they've been added. ie. > Individual auditing so that you don't blow out the message size on the > reply, procedures to handle the case where a reply message will exceed > message size, having all descriptors being extended by packages so you > can introduce new features without protocol updates. > > I don't think that because of the state (or lack of it) of individual > companies implementations that this should prevent the standard from > moving forward. > > Cheers, Christian ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

5 8

Pairing of RTP channels
by OKUBO Sakae 11 Oct '01

11 Oct '01

Dear SG16 experts, In the context of AVD-2134 "UDP port number assignment in the H.323 system", I have a couple of questions on the RTP/RTCP and H.323/H.245 design philosophies behind the pairing of a forward direction RTP channel and its CORRESPONDING reverse direction RTP channel. RTP transmission is uni-directional, but its associated RTCP channels are bi-directional. Even if media RTP packets flow one way, its RTCP packets flow two ways conveying receiving report and sender info. Presumably to reduce the number of ports and the number of UDP packets for RTCP, two RTP channels in different directions are paired. If terminal A is sending a media to terminal B and receiving the same type of media from terminal B, RTCP SR packets contain both sender info regarding media transmission from A to B and reception report regarding media transmission from B to A. The first question is: Q1 - What two RTP transmissions are paired? From the RTP/RTCP design point of view, any pair seems alright as far as they are dealing with the same type of media like audio, video, data. Is this understanding correct? Related to this question, we saw the attached posting referring to "Section 6.2.8.2 Logical channel signalling" of H.323. The correspondence of two media channels of different directions is given by sessionID in H.245. Default sessionIDs 1, 2 and 3 are defined for audio, video and data. The second question is: Q2 - What are these pre-assigned sessionIDs meant for? sessionID=1 audio is almost certain that it is for bi-directional conversational speeches (or "main audio"). How about sessionID=2 video? It will probably be for bi-directional participants images for videophone and videoconferencing (or "main video"). One way video may deliver participants images, but the reverse direction video may deliver VTR presentation. Even for this case, sessionID=2 can be used. So the notion of "main video" may help us. Or the former video uses sessionID=2 and the latter video uses sessionID=4, for example? How about data? sessionID=3 is for T.120 or another data? A related question is: Q3 - Can the slave side send a media with one of those pre-assigned sessonIDs, audio with sessionID=1 for example? H.245 stipulates that the master side assigns sessionID values and that the slave starts OpenLogicalCannel (OLC) with sessionID=0 and the master assigns a sessionID value. The master should always start OLC in the H.323 communication? If the slave starts OLC with sessionID=1, the master acknowledges the OLC or rejects it? In any case, both terminals should have the same understanding on what is the media for sessionID=1, 2, 3. Since H.323/H.245 is flexible in the number of media channels simultaneously used, we may have a case of multiple audios or multiple videos in a single H.323 communication. Let us take a case of terminal A sending only a conversational speech while terminal B sending a conversational speech plus a presentation sound. A natural thinking is that two way speeches are paired with sessionID=1. However it may be OK that one way speech and reverse direction presentation sound are paired with sessionID=1 and the remaining reverse direction speech is widowed with sessionID=5? The above notion of main audio and auxiliary audios does not give a solution? Each terminal define its main audio transmission as well as multiple auxiliary audio transmissions if available. Two way main audios are paired with sessionID=1, two way auxiliary audios are paired next regardless of their contents in the order of OLCs with sessionID=x assigned by the master, and so on. One way auxiliary audio may remain without its corresponding auxiliary audio. If we have common understanding or common practice on the above questions, then it will be worth documenting it in some part of H.323. Best regards, OKUBO Sakae ********************************************************* Global Information and Telecommunication Institute (GITI) Waseda University 29-7 Waseda University Bldg. 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan e-mail: okubo(a)giti.waseda.ac.jp Tel: +81 3 3204 8194 Fax: +81 3 5286 3832 ********************************************************* >Date: Mon, 13 Aug 2001 15:06:54 -0400 >From: Medhavi Bhatia <mbhatia(a)NEXTONE.COM> >Subject: RTCP port in H.323 logical channels > >Hi, > >A question about mediaControl ports in Logical channels: > >Can an endpoint A open a logical channel to another endpoint B (in non >fast start mode), specify control channel port X, and respond to B's OLC >with a media control port Y, where X and Y are different ? Assuming the >OLCs are for the same sessions. > >The H.323 spec specifies that X and Y must be the same for fast start >scenarios. For a non fast start case, if they must be different, what is >the behavior of the endpoint B in that case ? > >thanks - Medhavi. > > ---------- > >Date: Mon, 13 Aug 2001 18:27:20 -0400 >From: Anatoli Levine <alevine(a)RADVISION.COM> >Organization: RADVISION Inc. >Subject: Re: RTCP port in H.323 logical channels >Comments: To: Medhavi Bhatia <mbhatia(a)nextone.com> > >Medhavi, > >X and Y can't be different. According to H.323 standard: >"6.2.8.2 Logical channel signalling >... >Logical channels shall be opened using the following procedure: >... >If a corresponding reverse channel is opened for a given existing RTP >session (identified by the RTP sessionID), the mediaControlChannel >Transport Addresses exchanged by the openLogicalChannel process shall be >identical to those used for the forward channel. " > >Anatoli ---------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: Implementors Guide not normative?
by Tom-PT Taylor 10 Oct '01

10 Oct '01

Would it make sense for the IETF to apply its process to take an integrated document through to RFC? Then it would be clear that H.248v2 is truly an up-version with new features. -----Original Message----- From: Terry L Anderson [mailto:tla@LUCENT.COM] Sent: Wednesday, October 10, 2001 2:07 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Implementors Guide not normative? True! Since most of us thought it always was. But it might be better to fix our process properly. Q.14/16 folks seem to use "Amendments". T.38 for example, has Ammendments 1,2,3 & 4 approved. These contain additional Annexes as well as modifications to T.38, often using language little different from our IG. Perhaps, our IG could be simply converted into an Amendment periodically and approved. (Actually it would need to be split into separate amendments for each recommendation). These would need to follow AAP rules for approval rather than simply being approved at a SG meeting. Amendments are supposes to be limited to no more often than every two years (like new versions), but there is an exception for minor purely editorial changes or corrections due to an "oversight", so I think we would have no restrictions on the changes we have been putting into IGs. A.11 states that "Minor modifications may be covered by publishing amendments or corrigenda rather than reissuing the complete Recommendation." I cannot find a defined difference between "amendments" and "corrigenda". Paul Long wrote: > Terry, > > Or we could just maintain the status quo by all agreeing with a wink ;-) > that IGs _are_ normative regardless of what Resolution 1 says. > > Paul Long > ipDialog, Inc. > > -----Original Message----- > From: Terry L Anderson [mailto:tla@lucent.com] > Sent: Wednesday, October 10, 2001 10:11 AM > To: Paul Long > Cc: ITU-SG16(a)mailbag.cps.INTEL.COM > Subject: Re: Implementors Guide not normative? > > Recommendation A.3 is no longer in affect (status: withdrawn) but Resolution > 1 of the > new Study Period WTSA-2000, > Resolution 1 - Rules of procedure of the ITU Telecommunication > Standardization > Sector (ITU-T) > has similar definitions (with a little less detail of process). > > 9.7 Correction of defects > When a study group identifies the need for implementors to be made aware of > defects > (e.g. typographical errors, editorial errors, ambiguities, omissions or > inconsistencies and technical errors) in a Recommendation, one mechanism > that may be > employed is an Implementors' Guide. This Guide is an historical document > recording all > identified defects and their status of correction, from their identification > to final > resolution, and would be issued in the study group's COM series of > documents. > Implementors' Guides shall be approved by the study group and made available > to the > public. > > It is still clear that IGs simply record to correction process and are not > themselves > normative corrections. > > I agree with Paul that we need to issue a Corrigendum or a new version with > the IG's > corrections before they become normative. We should do this as quickly as > legally > possible, which I believe is to prepare something for which "consent" can be > approved > at SG16 in Feb 2002 and then approved by AAP a few weeks later. It seems to > me the > large number of changes accumulated to date suggest that a V2 would be alot > easier to > use (I believe a Corrigendum would still be published as differences). > Perhaps we > should then have a strategy of issuing Corrigenda periodically for V2 rather > than only > IGs. > > [snip] > > -- > > ------------------------------------------------------------ > Terry L Anderson mailto:tla@lucent.com > Tel:908.582.7013 Fax:908.582.6729 > Lucent Technologies/INS/Voice Over IP Access Networks > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Lucent Technologies/INS/Voice Over IP Access Networks Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

1 0

Test Message: ITU-SG16@MAILBAG.INTEL.COM
by Reddy, Paul K 09 Oct '01

09 Oct '01

Your message is being returned to you unprocessed because it appears to have already been distributed to the ITU-SG16 list. That is, a message with identical text (but possibly with different mail headers) has been posted to the list recently, either by you or by someone else. If you have a good reason to resend this message to the list (for instance because you have been notified of a hardware failure with loss of data), please alter the text of the message in some way and resend it to the list. Note that altering the "Subject:" line or adding blank lines at the top or bottom of the message is not sufficient; you should instead add a sentence or two at the top explaining why you are resending the message, so that the other subscribers understand why they are getting two copies of the same message. ------------------------ Rejected message (13 lines) -------------------------- Received: from FMSMSX017.fm.intel.com (fmsmsx017.fm.intel.com [132.233.42.196]) by mailbag.cps.intel.com (8.9.3/8.9.3/d: relay.m4,v 1.6 2000/11/24 22:10:56 iwep Exp iwep $) with ESMTP id SAA22978 for <ITU-SG16(a)MAILBAG.INTEL.COM>; Tue, 9 Oct 2001 18:12:40 -0700 (PDT) Received: by fmsmsx017.fm.intel.com with Internet Mail Service (5.5.2653.19) id <4LAWLARR>; Tue, 9 Oct 2001 18:08:42 -0700 Message-ID: <8A9A5F4E6576D511B98F00508B68C20A5F9365(a)orsmsx106.jf.intel.com> From: "Reddy, Paul K" <paul.k.reddy(a)intel.com> To: "'ITU-SG16(a)MAILBAG.INTEL.COM'" <ITU-SG16(a)MAILBAG.INTEL.COM> Subject: Test message Date: Tue, 9 Oct 2001 18:10:36 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

FW: Draft H.248 Annex M.1
by Tom-PT Taylor 05 Oct '01

05 Oct '01

AVD-2119, Draft Annex M.1 to H.248 (Advanced Audio Server Packages), has been uploaded to the Incoming directory. -----Original Message----- From: Glen Freundlich [mailto:ggf@avaya.com] Sent: Thursday, September 06, 2001 2:31 PM To: Taylor, Tom-PT [NORSE:B881:EXCH] Subject: Re: Draft H.248 Annex M.1 Hi Tom, Use AVD-2119. Glen -------------------- 2119 Q.3 H.248 Annex M.1, Advanced Audio Server Packages Editor Tom-PT Taylor wrote: > Please give me an AVD number for the following: > Draft H.248 Annex M.1, Advanced Audio Server Packages > Source: Editor > > Tom Taylor > taylor(a)nortelnetworks.com > Ph. +1 613 736 0961 (ESN 396 1490) >

1 0

updated AVD-2110a, AVD-2111a, AVD-2112a
by Euchner Martin 05 Oct '01

05 Oct '01

AVD-2110a, 2111a and AVD-2112a have been uploaded to the Incoming directory area. All three of them contain minor changes and improvements over previously posted contributions. (and as a side effect, I'm curious to see how well Greg's new anti-spam procedure actually works). Kind Regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 47713 | Siemens AG | ICN M SR 3 mailto:Martin.Euchner@icn.siemens.de <mailto:Martin.Euchner@icn.siemens.de> | mailto:martin.euchner@ties.itu.int <mailto:martin.euchner@ties.itu.int> | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/sr/pages/122/122_euchner.htm <http://intranet.icn.siemens.de/marketing/cs27/> | D-81359 Muenchen Internet: http://www.siemens.de <http://www.siemens.de> | __________________ | Germany ----------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Is H.225.0 Progress message really optional though it is used in Fast Start ?
by Lyons, Terry 05 Oct '01

05 Oct '01

H.323 v4 says: 8.1.7 Fast connect procedure . . . When the called endpoint desires to proceed with the Fast Connect procedure, it sends a Q.931 message (Call Proceeding, Progress, Alerting, or Connect) containing a fastStart element selecting from amongst the OpenLogicalChannel proposals offered by the calling endpoint. However, H.225.0 says that Progress is CM to receive and act on. Does that mean that a receiver can ignore Progress and believe that Fast Start was refused? The transmitter and receiver can then disagree about whether Fast Start concluded. How should we resolve the inconsistency? - TLyons(a)sonusnet.com +1 732 625-3003 ext 212 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

New ITU-SG16 Mail List Procedures Implemented for Trial Period
by Meyer, Greg W 02 Oct '01

02 Oct '01

All ITU-SG16 Mail List Users: Please note that the mail list, itu-sg16(a)mailbag.intel.com, has a new two-step proceedure for sending mail to the list. Here's how it works: 1. Compose your message. 2. Send it to ITU-SG16(a)MAILBAG.INTEL.COM 3. You will receive a "confirmation" message from LISTSERV(a)MAILBAG.INTEL.COM 4. Reply to the confirmation message with "OK" (without the quotes) in the body. OK, that's four steps but only two "sends." Each confirmation message contains the instructions on how to reply. This procedure will help reduce spam and other unauthorized mail. For security purposes, NO ONE should have any mail list (esp. the ITU-SG16 mail list) in their email address book. Most viruses use the address book information to propogate so we strongly request that you look through your address book and remove this and all other mail lists. This new procedure will be tried through the month of October. Please let me know (directly) if there's any mail list service that is being prohited or significantly inhibited. I'll be especially intested in long times (>10 minutes) before receiving the confirmation message. Our testing to date shows that listserv responds quickly. I was strongly(!) motivated to make this change after that last spam ("Excellent Colon Cleanser"). Thanks, Greg Meyer Intel Corporation mailto:greg.w.meyer@intel.com +1.503.264.9506 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

EXCELLENT COLON CLEANSER
by cowboy1965＠btamail.net.cn 01 Oct '01

01 Oct '01

1 0

Re: Meeting Reminder
by Neal J. King 01 Oct '01

01 Oct '01

I received no confirmation, but they confimed my reservation when I called them. Neal -----Original Message----- From: Euchner Martin [mailto:Martin.Euchner@ICN.SIEMENS.DE] Sent: Friday, September 28, 2001 3:51 AM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: AW: Meeting Reminder Has anyone registered with the Dublin hotel received already a confirmation back? I'm not absolutely certain, if they have received my reservation request. Kind Regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | ICN M SR 3 mailto:Martin.Euchner@icn.siemens.de <mailto:Martin.Euchner@icn.siemens.de> | mailto:martin.euchner@ties.itu.int <mailto:martin.euchner@ties.itu.int> | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/sr/pages/122/122_euchner.htm <http://intranet.icn.siemens.de/marketing/cs27/> | D-81359 Muenchen Internet: http://www.siemens.de <http://www.siemens.de> | __________________ | Germany ----------------------------------------------------------------------- -----Ursprüngliche Nachricht----- Von: Paul E. Jones [SMTP:paulej@PACKETIZER.COM] Gesendet am: Freitag, 28. September 2001 09:44 An: ITU-SG16(a)mailbag.cps.INTEL.COM Betreff: Meeting Reminder Wichtigkeit: Hoch Dear Experts, I just wanted to remind you that today is the last day to reserve your room for the Rapporteur's meeting in Dublin at the special discounted rate. If you have not already done so, I encourage you to make that reservation. Also, don't forget to send me an e-mail to let me you that you will be attending the meeting. Best Regards, Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Proposed Change to ITU-SG16 Mail List Procedures
by Chip Sharp 28 Sep '01

28 Sep '01

Most listserv software allows you to configure it so that only list members can send email to the list. If you configured the mail list in this manner, then only list members could send email. If someone sends spam, you remove that member from the list. Since most abusive spam is automatically generated, it is doubtful the originator will go through the trouble of subscribing to the list before sending. The downside is that people who monitor the list behind a mail exploder (or newsgroup) will not be able to post without subscribing individually. Anyway, this is another option to think of. Chip At 09:16 PM 9/25/2001, Meyer, Greg W wrote: >Dear ITU-SG16 Experts: > >I have noticed a dramatic increase in SPAM on the ITU-SG16 mail list. As >administrator of the list, I would like to hear about a proposed change that >will decrease the amount of SPAM and other mail messages including >potentially harmful email (viruses, etc.). > >I can set LISTSERV to require the sender of a message to acknowledge the >message before LISTSERV will send it. So to send a message, you would send >it in the usual way but before it gets sent to the mail list, LISTSERV will >send you a message. If you respond to the message, you authorize LISTSERV to >send the message. Since most SPAM is spoofed, the "sender" will not >acknowledge LISTSERV and the message will not get sent. > >I would appreciate hearing if there are any concerns with this method before >I implement it. I will follow-up this email later to announce what action I >have taken to this ITU-SG16 list. > >Thank you, > >Greg Meyer >Intel Corporation >email: greg.w.meyer(a)intel.com > >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >For help on this mail list, send "HELP ITU-SG16" in a message to >listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

AW: Meeting Reminder
by Euchner Martin 28 Sep '01

28 Sep '01

Has anyone registered with the Dublin hotel received already a confirmation back? I'm not absolutely certain, if they have received my reservation request. Kind Regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | ICN M SR 3 mailto:Martin.Euchner@icn.siemens.de <mailto:Martin.Euchner@icn.siemens.de> | mailto:martin.euchner@ties.itu.int <mailto:martin.euchner@ties.itu.int> | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/sr/pages/122/122_euchner.htm <http://intranet.icn.siemens.de/marketing/cs27/> | D-81359 Muenchen Internet: http://www.siemens.de <http://www.siemens.de> | __________________ | Germany ----------------------------------------------------------------------- -----Ursprüngliche Nachricht----- Von: Paul E. Jones [SMTP:paulej@PACKETIZER.COM] Gesendet am: Freitag, 28. September 2001 09:44 An: ITU-SG16(a)mailbag.cps.INTEL.COM Betreff: Meeting Reminder Wichtigkeit: Hoch Dear Experts, I just wanted to remind you that today is the last day to reserve your room for the Rapporteur's meeting in Dublin at the special discounted rate. If you have not already done so, I encourage you to make that reservation. Also, don't forget to send me an e-mail to let me you that you will be attending the meeting. Best Regards, Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Release complete reason
by Francois Audet 28 Sep '01

28 Sep '01

Hi guys, What is the meaning of releaseCompleteReason=invalidRevision in RELEASE COMPLETE? Does it mean invalid revision of H.225.0? Or is it more general (like invalid versionId in the vendorId field for example). I suspect it is supposed to mean invalid revision of H.225.0. It isn't documented in H.225.0 (or H.323). I also suspect that if you want to do anything fancy like rejecting a call based on vendorId/productId/versionId, you'd should use the nonStandardReason? Any views? ---- François AUDET, Nortel Networks mailto:audet@nortelnetworks.com <mailto:audet@nortelnetworks.com> , tel:+1 408 495 3756

2 1

Meeting Reminder
by Paul E. Jones 28 Sep '01

28 Sep '01

Dear Experts, I just wanted to remind you that today is the last day to reserve your room for the Rapporteur's meeting in Dublin at the special discounted rate. If you have not already done so, I encourage you to make that reservation. Also, don't forget to send me an e-mail to let me you that you will be attending the meeting. Best Regards, Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Proposed Change to ITU-SG16 Mail List Procedures
by Meyer, Greg W 26 Sep '01

26 Sep '01

"This looks to be heading towards a "vote" situation." Actually no, I wasn't looking for votes. I wanted to know if there were any issues with my proposal; if the proposed change would either prohibit or significantly inhibit the intended purpose of the mail list. I've seen many great responses and very much appreciate the feedback. A major consideration for any change is the ability to send and receive mail in a timely manner. Any change that requires more administrative time will surely impact timely service since this is not my primary job function and I travel frequently (periods of not having access). I think Chris' summation below is accurate and, with few exceptions, will impact the subscribers minimally while according some degree of immunity to spam and other unauthorized use of the mail list. I would like to implement the proposal for a 30-day trial period. At the end of the period (end of Oct), I will see how much spam and other unauthorized mail went through compared to the last 30 days and also ask for feedback from you (the subscribers). My intention is to make the ITU-SG16 mail list better, not worse. So if it becomes clear that there are significant issues during the trial, I will terminate it and return to the current method (open to all who send without the "authorization" step). Clearly, Mr. Okubo's point of Listserv's timely response period will determine whether the proposed change is acceptable. In my experience, the vast majority of Listserv responses are within a few minutes (usually less than one minute). However, I have seen some extended delays when major network issues are experienced (Code Red, Nimda, etc.). These have been the exceptions and the purpose of a 30-day trial is to determine if extended delays are more prevalent than I believe them to be. I will do some testing prior to going live with the change. My target start is Monday, Oct 1. Again, I appreciate your feedback and look forward to making the ITU-SG16 list better for your use. Thanks, Greg Meyer Intel Corporation mailto:greg.w.meyer@intel.com +1.503.264.9506 -----Original Message----- From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] Sent: Wednesday, September 26, 2001 8:30 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Proposed Change to ITU-SG16 Mail List Procedures This looks to be heading towards a "vote" situation. I vote for the two-stage process. Most people read lots, post occasionally, and this solution only introduces a slight pain when posting, is minimal work for the list administrator and, most importantly, keeps the list open. Regards, Chris -- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Proposed Change to ITU-SG16 Mail List Procedures
by Meyer, Greg W 26 Sep '01

26 Sep '01

Dear ITU-SG16 Experts: I have noticed a dramatic increase in SPAM on the ITU-SG16 mail list. As administrator of the list, I would like to hear about a proposed change that will decrease the amount of SPAM and other mail messages including potentially harmful email (viruses, etc.). I can set LISTSERV to require the sender of a message to acknowledge the message before LISTSERV will send it. So to send a message, you would send it in the usual way but before it gets sent to the mail list, LISTSERV will send you a message. If you respond to the message, you authorize LISTSERV to send the message. Since most SPAM is spoofed, the "sender" will not acknowledge LISTSERV and the message will not get sent. I would appreciate hearing if there are any concerns with this method before I implement it. I will follow-up this email later to announce what action I have taken to this ITU-SG16 list. Thank you, Greg Meyer Intel Corporation email: greg.w.meyer(a)intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

5 4

Re: Proposed Change to ITU-SG16 Mail List Procedures
by Skran, Dale 26 Sep '01

26 Sep '01

Sounds like a great idea. Dale Skran -----Original Message----- From: Meyer, Greg W [mailto:greg.w.meyer@INTEL.COM] Sent: Tuesday, September 25, 2001 9:17 PM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: Proposed Change to ITU-SG16 Mail List Procedures Dear ITU-SG16 Experts: I have noticed a dramatic increase in SPAM on the ITU-SG16 mail list. As administrator of the list, I would like to hear about a proposed change that will decrease the amount of SPAM and other mail messages including potentially harmful email (viruses, etc.). I can set LISTSERV to require the sender of a message to acknowledge the message before LISTSERV will send it. So to send a message, you would send it in the usual way but before it gets sent to the mail list, LISTSERV will send you a message. If you respond to the message, you authorize LISTSERV to send the message. Since most SPAM is spoofed, the "sender" will not acknowledge LISTSERV and the message will not get sent. I would appreciate hearing if there are any concerns with this method before I implement it. I will follow-up this email later to announce what action I have taken to this ITU-SG16 list. Thank you, Greg Meyer Intel Corporation email: greg.w.meyer(a)intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Proposed Change to ITU-SG16 Mail List Procedures
by Les Brown 26 Sep '01

26 Sep '01

Hal, The problem with this approach is that many companies use an outgoing email address that is different/modified from the users incoming address, so users would have to register both addresses (once they figure out that they have 2 addresses). I had this problem with a list that I maintained, so I found it easier to open it up to allow anyone to post to it. Les Brown At 08:46 AM 9/26/2001 -0400, you wrote: >Greetings, > >There is also another way to limit posting to the list that does not involve >the two-step process. The list can be limited so that only those registered >for the list can post to it. I know that is a feature of majordomo that I >use for some of my lists. > >Hal > > > -----Original Message----- > > From: Meyer, Greg W [mailto:greg.w.meyer@INTEL.COM] > > Sent: Tuesday, September 25, 2001 9:17 PM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Proposed Change to ITU-SG16 Mail List Procedures > > > > > > Dear ITU-SG16 Experts: > > > > I have noticed a dramatic increase in SPAM on the ITU-SG16 > > mail list. As > > administrator of the list, I would like to hear about a > > proposed change that > > will decrease the amount of SPAM and other mail messages including > > potentially harmful email (viruses, etc.). > > > > I can set LISTSERV to require the sender of a message to > > acknowledge the > > message before LISTSERV will send it. So to send a message, > > you would send > > it in the usual way but before it gets sent to the mail list, > > LISTSERV will > > send you a message. If you respond to the message, you > > authorize LISTSERV to > > send the message. Since most SPAM is spoofed, the "sender" will not > > acknowledge LISTSERV and the message will not get sent. > > > > I would appreciate hearing if there are any concerns with > > this method before > > I implement it. I will follow-up this email later to announce > > what action I > > have taken to this ITU-SG16 list. > > > > Thank you, > > > > Greg Meyer > > Intel Corporation > > email: greg.w.meyer(a)intel.com > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)mailbag.intel.com > > > >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >For help on this mail list, send "HELP ITU-SG16" in a message to >listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

AW: Proposed Change to ITU-SG16 Mail List Procedures
by Euchner Martin 26 Sep '01

26 Sep '01

Greg, I appreciate your initiative to reduce the email spam on this list. I understand that spam is at least annoying, but sometimes even dangerous when viruses are conveyed. Of course, an effective countermeasure is required, that is also simple to use. While I'm not a mailing list expert and do not know about the particular constraint of this list, my understanding is, that posting a message to this list now would become a 2 stage process. This could counter the spam but at the price of user friendliness. My slight concern is, that some people might feel discouraged to post something just because the procedure sounds complicated. As traffic has already decreased considerably as compared to former years, we should seek for a procedure that does not put burden on the honest users. I'm not certain whether anybody can send stuff to this list, regardless of being subscribed or not. Thus, this sounds as a minimal precaution to make sure that any posting origins just from an authorized email address, where authorization means that the originator has been registered by the mailing list administrator. Is the listserv system able to check this? Would this help? Kind Regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | ICN M SR 3 mailto:Martin.Euchner@icn.siemens.de <mailto:Martin.Euchner@icn.siemens.de> | mailto:martin.euchner@ties.itu.int <mailto:martin.euchner@ties.itu.int> | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/sr/pages/122/122_euchner.htm <http://intranet.icn.siemens.de/marketing/cs27/> | D-81359 Muenchen Internet: http://www.siemens.de <http://www.siemens.de> | __________________ | Germany ----------------------------------------------------------------------- -----Ursprüngliche Nachricht----- Von: Meyer, Greg W [SMTP:greg.w.meyer@INTEL.COM] Gesendet am: Mittwoch, 26. September 2001 03:17 An: ITU-SG16(a)mailbag.cps.INTEL.COM Betreff: Proposed Change to ITU-SG16 Mail List Procedures Dear ITU-SG16 Experts: I have noticed a dramatic increase in SPAM on the ITU-SG16 mail list. As administrator of the list, I would like to hear about a proposed change that will decrease the amount of SPAM and other mail messages including potentially harmful email (viruses, etc.). I can set LISTSERV to require the sender of a message to acknowledge the message before LISTSERV will send it. So to send a message, you would send it in the usual way but before it gets sent to the mail list, LISTSERV will send you a message. If you respond to the message, you authorize LISTSERV to send the message. Since most SPAM is spoofed, the "sender" will not acknowledge LISTSERV and the message will not get sent. I would appreciate hearing if there are any concerns with this method before I implement it. I will follow-up this email later to announce what action I have taken to this ITU-SG16 list. Thank you, Greg Meyer Intel Corporation email: greg.w.meyer(a)intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

5 4

Re: Proposed Change to ITU-SG16 Mail List Procedures
by Tom-PT Taylor 26 Sep '01

26 Sep '01

For the reasons Dr. Okubo cited, Martin's two-stage procedure is probably better for the purpose. I've administered the Megaco list on three systems now: majordomo, listserv, and mailman. Of them all, only mailman allows me to specify spam filters, to a limited extent. I have to be extremely careful, because IETF rules really do not permit any hint of moderation of true list discussion. However, it's amazing how effective a simple rule like: "Hold messages without a specific addressee" can be. -----Original Message----- From: Folts, Harold [mailto:foltsh@NCS.GOV] Sent: Wednesday, September 26, 2001 8:47 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Proposed Change to ITU-SG16 Mail List Procedures Greetings, There is also another way to limit posting to the list that does not involve the two-step process. The list can be limited so that only those registered for the list can post to it. I know that is a feature of majordomo that I use for some of my lists. Hal > -----Original Message----- > From: Meyer, Greg W [mailto:greg.w.meyer@INTEL.COM] > Sent: Tuesday, September 25, 2001 9:17 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Proposed Change to ITU-SG16 Mail List Procedures > > > Dear ITU-SG16 Experts: > > I have noticed a dramatic increase in SPAM on the ITU-SG16 > mail list. As > administrator of the list, I would like to hear about a > proposed change that > will decrease the amount of SPAM and other mail messages including > potentially harmful email (viruses, etc.). > > I can set LISTSERV to require the sender of a message to > acknowledge the > message before LISTSERV will send it. So to send a message, > you would send > it in the usual way but before it gets sent to the mail list, > LISTSERV will > send you a message. If you respond to the message, you > authorize LISTSERV to > send the message. Since most SPAM is spoofed, the "sender" will not > acknowledge LISTSERV and the message will not get sent. > > I would appreciate hearing if there are any concerns with > this method before > I implement it. I will follow-up this email later to announce > what action I > have taken to this ITU-SG16 list. > > Thank you, > > Greg Meyer > Intel Corporation > email: greg.w.meyer(a)intel.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0