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

Re: [Megaco] H.248v2
by Christian Groves 31 Oct '01

31 Oct '01

GDay Tom, My suggestion would be rather to have a phone or video conference/s for the issues. That way all active interested parties can attend. As highlighted by others on the list in this current climate some people are unable to travel to meetings. This would also elimate throwing decisions over the fence and people complaining that they weren't part of the process. I had in mind a moderated conference by yourself as Megaco Chairman and Glen Fruendlich as SG16 Q.3 Rapportuer. This conference should be for active participants rather than those just listening in. That way both groups have input and are part of any decisions even if the decisions don't favour them. Regards, Christian Tom-PT Taylor wrote: > > We started to debate H.248v2 this morning. There will definitely be a > document put out for approval in February. At a minimum it will > contain the merged Implementor's Guide and H.248v1. The debate is > over what else it might contain. > > I will ask for time for a WG meeting. We will probably have some > discussion of our own, and we can also tackle some of the less > tractable issues from the list. > > Tom Taylor > taylor(a)nortelnetworks.com > Ph. +1 613 736 0961 (ESN 396 1490) > _______________________________________________ Megaco mailing list Megaco(a)ietf.org http://www1.ietf.org/mailman/listinfo/megaco

1 0

TD-05 and TD-19 available
by Euchner Martin ICN M SR 3 26 Oct '01

26 Oct '01

Folks, please find attached two TDs. Sorry for posting document here around but, for some couple of days, I have not been able to upload them to the Incoming FTP directory. So if anyone has access, please do on my behalf. Thank you. TD-05 "Agenda SG16 WP2 Q.G Meeting, Dublin, IR, 29 October- 2 November 2001" TD-19 "Liaison to Q.G/16 from SG9 on J.170 Security Issues" Have a good and safe trip to Dublin and CU there! <<TD-5.zip>> <<TD-19.zip>> With 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@ties.itu.int | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/sr/pages/122/122_euchner.htm | D-81359 Muenchen Internet: http://www.siemens.de/ | __________________ | Germany -----------------------------------------------------------------------

2 1

Re: [Megaco] Contribution AVD-2173 -- Implications Of Context At tribute Descri ptors
by Tom-PT Taylor 26 Oct '01

26 Oct '01

You're undoubtedly right on date -- the great IETF legal intercept debate occurred in the fall, following Megaco discussion of the same topic. I had Red Bank in mind, but this is one thing that didn't happen in Red Bank. Nevertheless, the fact that contributions are going in to the present meeting to fill in gaps kind of makes my point. We really didn't think context properties through, so that up to now they haven't had the same solid foundation as termination properties. I'm arguing we need more time to think through the semantic issues at the least, and to make sure that the protocol aspects are as regular as we can make them. Agreed that you can't drop existing properties on the floor. But we can do something like requiring that the new form be used when later-version implementations are talking to each other. -----Original Message----- From: Christian Groves [mailto:Christian.Groves@ericsson.com.au] Sent: Thursday, October 25, 2001 9:08 PM To: Taylor, Tom-PT [CAR:B881:EXCH] Cc: 'megaco(a)ietf.org'; 'itu-sg16(a)mailbag.intel.com' Subject: Re: [Megaco] Contribution AVD-2173 -- Implications Of Context Attribute Descri ptors G'Day Tom, For the record context properties were added in August 1999, to put that in context (pardon the pun) the handling of "context" (ie. linking, unlinking) was still being discussed in May 1999. So I don't think it was a last minute addition. I believe that with the contribution to this meeting (AVD-2120) and the ones to the previous meeting on this topic address the concerns in your bullet points. These use already established methods in H.248 to achieve your points (obviously there are some syntax additions). Can you please give some specific examples of what is not covered? Regarding the deprecation of existing context properties I believe this is pretty much out of the question as these are being used in implementations today. Regards, Christian Tom-PT Taylor wrote: > > My apologies for the late delivery of this contribution. For the moment I'm > locked out of the PictureTel server, so here's the text: > > TITLE: Implications Of Context Attribute Descriptors > > ___________________ > > Summary > > This contribution is written to express concern over the proposed inclusion > of context attribute descriptors in H.248v2. This innovation is seen upon > reflection as a major change in the H.248 protocol architecture, and > threatens the coherence of the protocol. > It is proposed as an alternative that we gain further experience by seeing > if it is possible to avoid the specification of new context properties while > solving the problems of MCU decomposition. When we are satisfied that we > can enunciate clear criteria for adding properties to contexts as opposed to > terminations and further, that we are aware of all of the implications of > context properties for the protocol, we can proceed to update the protocol > accordingly. > > 1. Introduction > > H.248v1 defines three context properties: the Topology Descriptor, the > Emergency flag, and the Priority flag. These additions were desirable, but > were made at a fairly late stage in the development of the protocol. As a > result, the work was done in an ad hoc manner and introduced irregularities > into the operation of the protocol. > > Delayed Contribution 129 (Porto Seguro) proposed the introduction of a > context attributes descriptor to contain new context properties and to allow > addition of such properties in packages. On the one hand, the present > contribution argues that this step, while desirable, does not go far enough > to assimilate context properties into the overall protocol structure. On > the other hand, introduction of the ability to define context properties in > packages at this stage in the development of the protocol may cause > confusion and threaten protocol interoperability at a practical level. > > 2. A Complete Implementation Of Context Properties > > A complete implementation of context properties requires that the protocol > satisfy the following requirements: > * there is a well-defined method for setting property values; > * there is a well-defined method for modifying or clearing property > values; > * there is a well-defined method for auditing values that have been > set on a context; > * it would be highly desirable to have a method for determining what > context properties an MG supports. > > Beyond these protocol matters come questions of semantics. We must decide > whether the permissible properties of a context can depend on what media are > flowing in it, or on the properties of the terminations currently in the > context. Since the active streams are a property of a context, we must > decide whether context properties can be associated with specific streams, > and if so, what syntax is used for the purpose. There are undoubtedly other > issues which may come to light. > > As a possibly controversial final step, it would seem desirable to > assimilate the existing context properties into the new syntactic structures > which would evolve. With appropriate requirements for transitional > interworking, the existing syntax for topology and the emergency and > priority flags should be deprecated and counterparts should be defined > within the context attribute descriptor. > > 3. Potential Confusion > > The final point this contribution makes is that if we do not establish a > clear definition within the protocol specification of which properties > should be context attributes and which should be termination properties, > packages will inevitably be defined which solve the same problem with > differing mechanisms. This will be unhelpful to achieving the > interoperability of different implementations. > > 4. Conclusion and Proposal > > Context attributes should be formalized only after careful study of all of > the issues. In concrete terms, this contribution proposes either that the > generalization of context attributes should be left to H.248v3 or else that > H.248v2 be delayed beyond the proposed February 2002 target. > > Tom Taylor > taylor(a)nortelnetworks.com > Ph. +1 613 736 0961 (ESN 396 1490) > > > _______________________________________________ > Megaco mailing list > Megaco(a)ietf.org > http://www1.ietf.org/mailman/listinfo/megaco ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

[Megaco] Contribution AVD-2173 -- Implications Of Context Attribute Descri ptors
by Tom-PT Taylor 26 Oct '01

26 Oct '01

My apologies for the late delivery of this contribution. For the moment I'm locked out of the PictureTel server, so here's the text: TITLE: Implications Of Context Attribute Descriptors ___________________ Summary This contribution is written to express concern over the proposed inclusion of context attribute descriptors in H.248v2. This innovation is seen upon reflection as a major change in the H.248 protocol architecture, and threatens the coherence of the protocol. It is proposed as an alternative that we gain further experience by seeing if it is possible to avoid the specification of new context properties while solving the problems of MCU decomposition. When we are satisfied that we can enunciate clear criteria for adding properties to contexts as opposed to terminations and further, that we are aware of all of the implications of context properties for the protocol, we can proceed to update the protocol accordingly. 1. Introduction H.248v1 defines three context properties: the Topology Descriptor, the Emergency flag, and the Priority flag. These additions were desirable, but were made at a fairly late stage in the development of the protocol. As a result, the work was done in an ad hoc manner and introduced irregularities into the operation of the protocol. Delayed Contribution 129 (Porto Seguro) proposed the introduction of a context attributes descriptor to contain new context properties and to allow addition of such properties in packages. On the one hand, the present contribution argues that this step, while desirable, does not go far enough to assimilate context properties into the overall protocol structure. On the other hand, introduction of the ability to define context properties in packages at this stage in the development of the protocol may cause confusion and threaten protocol interoperability at a practical level. 2. A Complete Implementation Of Context Properties A complete implementation of context properties requires that the protocol satisfy the following requirements: · there is a well-defined method for setting property values; · there is a well-defined method for modifying or clearing property values; · there is a well-defined method for auditing values that have been set on a context; · it would be highly desirable to have a method for determining what context properties an MG supports. Beyond these protocol matters come questions of semantics. We must decide whether the permissible properties of a context can depend on what media are flowing in it, or on the properties of the terminations currently in the context. Since the active streams are a property of a context, we must decide whether context properties can be associated with specific streams, and if so, what syntax is used for the purpose. There are undoubtedly other issues which may come to light. As a possibly controversial final step, it would seem desirable to assimilate the existing context properties into the new syntactic structures which would evolve. With appropriate requirements for transitional interworking, the existing syntax for topology and the emergency and priority flags should be deprecated and counterparts should be defined within the context attribute descriptor. 3. Potential Confusion The final point this contribution makes is that if we do not establish a clear definition within the protocol specification of which properties should be context attributes and which should be termination properties, packages will inevitably be defined which solve the same problem with differing mechanisms. This will be unhelpful to achieving the interoperability of different implementations. 4. Conclusion and Proposal Context attributes should be formalized only after careful study of all of the issues. In concrete terms, this contribution proposes either that the generalization of context attributes should be left to H.248v3 or else that H.248v2 be delayed beyond the proposed February 2002 target. Tom Taylor taylor(a)nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490) _______________________________________________ Megaco mailing list Megaco(a)ietf.org http://www1.ietf.org/mailman/listinfo/megaco

2 1

Re: AVD-2159, 2161, 2162 & 2163 uploaded
by Reddy, Paul K 24 Oct '01

24 Oct '01

Hi Everybody, I have uploaded the following documents into AVS-Site Incoming directory: AVD-2159.zip : Q5/16: Presence Services requirements (Stage1) from 3GPP SA1 group AVD-2161.zip: Q5/16: Mobile Presence and Instant Messaging TOR (Terms of Reference) AVD-2162.zip: Q5/16: XML based protocol for Mobile Presence and Instant messaging AVD-2163.zip: Q5/16: Inter-working function between existing Presence and IM systems (e.g., AOL, MSN etc.) and Mobile Presence and IM systems based on XML based protocols regards, Paul Rapporteur of Q5/16 Intel Labs

1 0

ADV 2106R2
by Folts, Harold 23 Oct '01

23 Oct '01

Greetings, I have made a few more revisions to this document as a result of comments received and translating it into the IETF Internet-Draft format. I uploaded it to the "incoming" directory. See you in Dublin. Hal <<Harold (Hal) C. Folts (E-mail).vcf>>

2 1

Document AVD-2109 has been uploaded
by Sasha Ruditsky 22 Oct '01

22 Oct '01

Hello all! The first version of H.460.3 "Presence in H.323 Systems" has been just uploaded as AVD-2109.zip to ftp://standard.pictel.com/avc-site/Incoming for your review. Best Regards, Sasha Ruditsky RADVISION Inc. TEL: +1.201.529.4300 x 243 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

AVD-2128, 2129, 2130 uploaded
by Terry L Anderson 22 Oct '01

22 Oct '01

I have uploaded the following documents for the Dublin meeting AVD-2128 H.248 Implementors Guide AVD-2129 Draft of Proposed H.248 Annex M_KA: KeepAlive Package for H.248 AVD-2130 Draft of Proposed LineTest Package for H.248 -- ------------------------------------------------------------ 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

Re: Documents AVD-2145 uploaded
by BOUGANT François FTRD/DAC/ISS 22 Oct '01

22 Oct '01

Dear all, The following contribution has been uploaded to the "incoming" directory : - AVD-2145 (source: France Telecom ; title : the User Service Profile in Multimedia Management databases ; purpose : proposal) Best regards François Bougant France Telecom ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

AVD-2166 upload
by POSE Laurent FTRD/DAC/ISS 22 Oct '01

22 Oct '01

Hello, The following contribution has been uploaded to /Incoming of the ftp site. AVD-2166 Source: FranceTelecom Title: Inconsistency between implementer's guide and H.225.0 on IE Redirecting number, Best Regards, Laurent Posé. France Telecom.

1 0

AVD-2169, 2170 & 2171 uploaded
by CHAPRON Jean-Emmanuel FTRD/DAC/ISS 22 Oct '01

22 Oct '01

Bonjour, Following AVDs have been uploaled to the Incoming Directory at the picturetel site.: 2169 Q.3 H.248 profile for controlling MG between cable networks and PSTN 2170 Q.3 H.248 profile for Audio Servers on cable networks 2171 Q.3 H.248 Annex M.1: speaking digits according to national requirements Regards, Jean-Emmanuel Chapron ``` (o o) ----------oOO--(_)-OOo-------------- Jean-Emmanuel CHAPRON FRANCE TELECOM R&D DAC/ACE 38-40 rue du général Leclerc 92794 Issy-les-Moulineaux Cedex 9 - France Tel: +33 1 45 29 64 50 -------------------------------------

1 0

[Q.3/16][megaco] AVD-2164 Corrections to H.248 Annex F uploaded
by Gunnar Hellstrom 21 Oct '01

21 Oct '01

I have uploaded AVD-2164 Corrections to H.248 Annex F to the incoming directory of the avc-site for the coming Q.3/16 meeting in Dublin. Source: Editor. Content: Additions to H.248 Implementor guide with corrections for minor errors in H.248 Annex F. The contribution contains the corrected Annex as an attachment. Best regards -------------------------- Gunnar Hellström Tel +46 708 204 288 E-mail gunnar.hellstrom(a)omnitor.se WWW: http://www.omnitor.se _______________________________________________ Megaco mailing list Megaco(a)ietf.org http://www1.ietf.org/mailman/listinfo/megaco

1 0

AVD-2172, Open Issues In H.248 Annex M.1
by Tom-PT Taylor 19 Oct '01

19 Oct '01

AVD-2172, Open Issues In H.248 Annex M.1, has been uploaded to the Incoming directory at the PictureTel site. Tom Taylor taylor(a)nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490)

1 0

Documents AVD-2144 and AVD-2154 uploaded
by BOUGANT François FTRD/DAC/ISS 19 Oct '01

19 Oct '01

Dear all, The following contributions have been uploaded to the "incoming" directory : - AVD-2144 (source: editor ; title : plan for H.MMS.0 draft ; purpose : proposal) - AVD-2154 (source: editor ; title : technical contents for H.MMS.0 draft ; purpose : proposal and discussion) Best regards François Bougant France Telecom ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

AVD-2156 has been uploaded
by OKUBO Sakae 19 Oct '01

19 Oct '01

Dear SG16 experts, AVD-2156 has been uploaded to /Incoming of the PictureTel ftp site: Source: Waseda University Title: Pairing of the "corresponding" RTP channels Purpose: Proposal Abstract: Clarification of the H.323 specification is proposed for the subject matter based on the e-mail discussion following the submission of AVD-2134. 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 ********************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

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 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