October 2001 - sg16-avd - lists.packetizer.com

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

12 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 10 Oct '01

10 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 02 Oct '01

02 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