- sg16-avd - lists.packetizer.com

Report of the Geneva meeting AVD-2833
by OKUBO Sakae 16 Dec '05

16 Dec '05

Dear SG16 WP2/16 experts, Mr. Seong-Ho Jeong, meeting organizer, has completed to edit the report of the Q.2,3,4,5,21,22,24 and 25 Rapporteur meeting held in Geneva during 28 November - 2 December 2005. This is now available at the avc-site: http://ftp3.itu.int/av-arch/avc-site/2005-2008/0511_Gen/AVD-2833.zip -- Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering Waseda University ****************************************************************** Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan H.323 videoconferencing: arranged by advice ******************************************************************

1 0

Re: H.248.1 - Examples for the Usage of the Statistics Descriptor
by Christian Groves 15 Dec '05

15 Dec '05

Hello Albrecht, The contribution certainly covers most use cases. I'm a little concerned that a 20 page appendix is an overkill for the description of statistics. I don't think the setting / resetting / deactivation is sufficiently different from normal properties/parameters to justify this amount of specification. If we go down the approach of document every case for the setting of statistics, do we need another appendix to show everycase for the setting of properties? another one to show call flows for the setting of signals. I think it is better to concentrate of the source of confusion and fix this rather than try to respecify the whole functionality. Unfortunately I couldn't make it to the last meeting to see the depth of confusion. Regards, Christian Albrecht.Schwarz(a)alcatel.de wrote: >Dear All! > >With regards to our discussions last WP2/16 meeting and: > > >>This is why I believe contributions are needed to April's meeting. >> >> > >I'd like to inform you that we drafted a contribution with a first >proposal: > >See in >http://ftp3.itu.int/av-arch/avc-site/Incoming/ > >file: > >http://ftp3.itu.int/av-arch/avc-site/Incoming/Alcatelt1%20T05-SG16-060403-D… > >After intensive studies of § 7.1.15 we did finally come to the conclusion >what a new Appendix for H.248.1 on"Practices on Statistics ? Exemplary Use >Cases" could be one way forward. > >Comments? >Albrecht > >PS >Yangbo, >the specific capability you are looking for is in IV.5.7 > > >----- Forwarded message from Kevin Boyle <kboyle(a)nortel.com> ----- > Date: Fri, 2 Dec 2005 10:06:14 -0500 > From: Kevin Boyle <kboyle(a)nortel.com> >Reply-To: Kevin Boyle <kboyle(a)nortel.com> > Subject: RE: 1 Comm. with 2 Descr.;RE: Attach; Re: TD-46-1 6.4 >Clarification of statistic reset capability > To: albrecht.schwarz(a)ties.itu.ch, Yangbo Lin <linyangbo(a)huawei.com> > >There is certainly no *documented* capability in H.248 to allow the MGC >to assign a value to a statistic. This is why I believe contributions >are needed to April's meeting. > >Kevin > >-----Original Message----- >From: albrecht.schwarz(a)ties.itu.ch [mailto:albrecht.schwarz@ties.itu.ch] > >Sent: Friday, December 02, 2005 10:03 AM >To: Yangbo Lin >Cc: albrecht.schwarz(a)ties.itu.ch; Boyle, Kevin [NCRTP:3Z40:EXCH]; >albrecht.schwarz(a)ties.itu.ch; geoff.hunt(a)bt.com; >arturo.martin-de-nicolas(a)ericsson.com; cdahm(a)cisco.com; Christian Groves >Subject: Re: 1 Comm. with 2 Descr.;RE: Attach; Re: TD-46-1 6.4 >Clarification of statistic reset capability > >Firstly, the MGC as master and "prime served user" for H.248 statistics >may perform any operation(as defined by H.248) on statistics. > >Secondly: > > >>This capability is not in the existing protocol. >> >> >I think that all outlined scenarios in these emails are syntactically, >and even semantically in line with H.248.1. >Could find sth against it in the spec. > >Albrecht > > >Quoting Yangbo Lin <linyangbo(a)huawei.com>: > > > >>In my understanding, the statistic only operated by the MG, and the >>MGC can only disable or enable it. This setting the statistic to zero >>actually give the MGC the capability to interrupt the operation of >>statistic arbitrarily as it will. This capability is not in the >> >> >existing protocol. > > >> ----- Original Message ----- >> From: albrecht.schwarz(a)ties.itu.int >> To: Kevin Boyle >> Cc: Yangbo Lin ; albrecht.schwarz(a)ties.itu.ch ; geoff.hunt(a)bt.com ; >>arturo.martin-de-nicolas(a)ericsson.com ; cdahm(a)cisco.com ; Christian >> >> >Groves > > >> Sent: Friday, December 02, 2005 3:30 PM >> Subject: RE: 1 Comm. with 2 Descr.;RE: Attach; Re: TD-46-1 6.4 >>Clarification of statistic reset capability >> >> >> Yangbo, >> any "reset" operation comes finally down to the defined "data type" >>and "value >> range" of a dedicated statistic. >> Reset means setting to the "initial value". >> The initial value in the context of statistics is typically either >> a) value = 0, or >> b) value = 'unknown' (e.g., certain VoIP metrics). >> >> Of course the name/value combination in the context of a desired >>reset operation >> makes perhaps only sense for case (a), and I'm fairly sure, is only >>required for >> case (a). >> But I will check out also potential metrics of type (b). >> >> Albrecht >> >> PS >> Do you have already a specific statistic of type (b) in mind? >> >> >> Quoting Kevin Boyle <kboyle(a)nortel.com>: >> >> > The intent is that the statistic will be explicitly set to 0. Of >> > course, other statistics may need to be reset to some other >> >> >default > > >> > value. This puts the onus on the MGC to know what the "reset >> >> >value" of > > >> > all supported statistics are. >> > >> > So, the "0" is not a flag, it is a value. There is no exceptional >> > request here. This syntax is legal, but the way to handle it in >> >> >the MG > > >> > is currently undefined in the spec. >> > >> > Kevin >> > >> > >> > ________________________________ >> > >> > From: Yangbo Lin [mailto:linyangbo@huawei.com] >> > Sent: Friday, December 02, 2005 9:11 AM >> > To: Boyle, Kevin [NCRTP:3Z40:EXCH]; albrecht.schwarz(a)ties.itu.ch >> > Cc: geoff.hunt(a)bt.com; albrecht.schwarz(a)ties.itu.ch; >> > arturo.martin-de-nicolas(a)ericsson.com; cdahm(a)cisco.com; Christian >>Groves >> > Subject: Re: 1 Comm. with 2 Descr.;RE: Attach; Re: TD-46-1 6.4 >> > Clarification of statistic reset capability >> > >> > >> > Maybe I misunderstand, you mean the "SA{pkg/stat1=0}" represents >> > the resetting? Is the "0" a reset flag or only a value? Does it >> >> >request > > >> > the MG to deal with the "0" exceptionally? Moreover, what will >>happen if >> > the "0" is a valid value of the parameter and no resetting value? >> > >> > >> > ----- Original Message ----- >> > From: Kevin Boyle <mailto:kboyle@nortel.com> >> > To: Yangbo Lin <mailto:linyangbo@huawei.com> ; >> > albrecht.schwarz(a)ties.itu.ch >> > Cc: geoff.hunt(a)bt.com ; albrecht.schwarz(a)ties.itu.ch ; >> > arturo.martin-de-nicolas(a)ericsson.com ; cdahm(a)cisco.com ; >> >> >Christian > > >> > Groves <mailto:cngroves@bigpond.net.au> >> > Sent: Friday, December 02, 2005 2:51 PM >> > Subject: RE: 1 Comm. with 2 Descr.;RE: Attach; Re: >> > TD-46-1 6.4 Clarification of statistic reset capability >> > >> > The concept would look like this:(assume pkg/stat1 and >> > pkg/stat2) >> > >> > !/3 [12.34.56.78]:2944 >> > T=123{C=12{MF=term1{AT{SA{pkg/stat1}},SA{pkg/stat1=0,pkg/stat2}}}} >> > >> > This would lead to the following response: >> > >> > !/3 [12.34.56.79]:2944 >> > P=123{C=12{MF=term1{pkg/stat1=123}}} >> > >> > Because this behavior is currently undocumented in the >> > spec, this will require a contribution to Q3 in April. Albrecht >> >> >has > > >> > agreed to bring such a contribution. >> > >> > Kevin >> > >> > >> > ________________________________ >> > >> > From: Yangbo Lin [mailto:linyangbo@huawei.com] >> > Sent: Friday, December 02, 2005 8:45 AM >> > To: albrecht.schwarz(a)ties.itu.ch; Boyle, Kevin >> > [NCRTP:3Z40:EXCH] >> > Cc: geoff.hunt(a)bt.com; >> > albrecht.schwarz(a)ties.itu.ch; >> >> >arturo.martin-de-nicolas(a)ericsson.com; > > >> > cdahm(a)cisco.com >> > Subject: Re: 1 Comm. with 2 Descr.;RE: Attach; >> > Re: TD-46-1 6.4 Clarification of statistic reset capability >> > >> > >> > Do you mean that a Modify command with three >> > descriptors, i.e. Audit Descriptor (for read), Statistics >> >> >Descriptor > > >> > excluding the statistic (for disable and remain) and Statistics >> > Descriptor including the statistic (for re-enable and reset) in >> >> >order? > > >> > Is it valid in protocol about including two Statistics Descriptors >> >> >in > > >> > one command? >> > >> > >> > ----- Original Message ----- >> > From: albrecht.schwarz(a)ties.itu.int >> > <mailto:albrecht.schwarz@ties.itu.int> >> > To: Kevin Boyle >> > <mailto:kboyle@nortel.com> >> > Cc: geoff.hunt(a)bt.com >> > <mailto:geoff.hunt@bt.com> ; linyangbo(a)huawei.com >> > <mailto:linyangbo@huawei.com> ; albrecht.schwarz(a)ties.itu.ch >> > <mailto:albrecht.schwarz@ties.itu.ch> ; >> > arturo.martin-de-nicolas(a)ericsson.com >> > <mailto:arturo.martin-de-nicolas@ericsson.com> ; cdahm(a)cisco.com >> > <mailto:cdahm@cisco.com> >> > Sent: Friday, December 02, 2005 1:53 PM >> > Subject: 1 Comm. with 2 Descr.;RE: >> > Attach; Re: TD-46-1 6.4 Clarification of statistic reset >> >> >capability > > >> > >> > >> > We did discuss a potential improvement >> > over lunch: >> > >> > 1 Modify Command with an Audit >> > Descriptor (for read) & Statistics Descriptor >> > (for reset) >> > >> > This solution is syntactically correct, >> > requires only a single H.248 Command, >> > and ensure processing in order. >> > >> > I'll bring a correspondent contribution >> > to next meeting for updating IMGs (V2 & V3). >> > >> > - Albrecht >> > >> > Quoting Kevin Boyle <kboyle(a)nortel.com>: >> > >> > > While I think that is a valid >> > optimization, I am not sure we can place >> > > it in the protocol spec. The spec >> > already goes out of its way to >> > > require that transactions, actions and >> > commands are executed in order. >> > > Given this, I am not sure that we can >> > put text in that allows an >> > > explicit exception for this operation. >> > > >> > > This then becomes an implementation >> > detail. As far as I am concerned, >> > > as long as the MG executes the >> > commands (in this case, report the stat >> > > and clear it) it does not really >> > matter whether that is done one command >> > > at a time or in an optimized >> > "one-step" fashion. >> > > >> > > Kevin >> > > >> > > >> > > ________________________________ >> > > >> > > From: geoff.hunt(a)bt.com >> > [mailto:geoff.hunt@bt.com] >> > > Sent: Friday, December 02, 2005 6:40 >> > AM >> > > To: linyangbo(a)huawei.com; Boyle, Kevin >> > [NCRTP:3Z40:EXCH]; >> > > albrecht.schwarz(a)ties.itu.ch >> > > Cc: >> > arturo.martin-de-nicolas(a)ericsson.com; cdahm(a)cisco.com >> > > Subject: RE: Attach; Re: TD-46-1 6.4 >> > Clarification of statistic >> > > reset capability >> > > >> > > >> > > Is it possible to recommend that a >> > gateway which *can* do >> > > lookahead across the commands in a >> > transaction, and sees read-and-reset >> > > commands combined like this, *should* >> > do the read-and-reset atomically? >> > > This could ensure that no value which >> > should contribute to the statistic >> > > is lost between read and reset. >> > > >> > > I'm sorry I don't understand H.248 in >> > enough depth and detail to >> > > know whether there is any fundamental >> > objection to this :( >> > > >> > > ________________________________ >> > > >> > > From: Yangbo Lin >> > [mailto:linyangbo@huawei.com] >> > > Sent: 02 December 2005 11:28 >> > > To: Kevin Boyle; >> > albrecht.schwarz(a)ties.itu.ch >> > > Cc: >> > arturo.martin-de-nicolas(a)ericsson.com; Hunt,RG,Geoff,XDE81 >> > > R; cdahm(a)cisco.com >> > > Subject: Re: Attach; Re: TD-46-1 6.4 >> > Clarification of statistic >> > > reset capability >> > > >> > > >> > > OK, I just ignored this more efficient >> > way, then we have a great >> > > idea and a good example. Now the only >> > leaving problem is how to avoid >> > > the lost about the extreme value >> > between the two command. I hope we can >> > > discuss and resolve it in Q3 as early >> > as possible. >> > > >> > > >> > > ----- Original Message ----- >> > > From: Kevin Boyle >> > <mailto:kboyle@nortel.com> >> > > To: albrecht.schwarz(a)ties.itu.ch >> > > <mailto:albrecht.schwarz@ties.itu.ch> >> > ; Yangbo Lin >> > > <mailto:linyangbo@huawei.com> >> > > Cc: >> > arturo.martin-de-nicolas(a)ericsson.com >> > > >> > <mailto:arturo.martin-de-nicolas@ericsson.com> ; >> >> >geoff.hunt(a)bt.com > > >> > > <mailto:geoff.hunt@bt.com> ; >> > cdahm(a)cisco.com <mailto:cdahm@cisco.com> >> > > Sent: Friday, December 02, 2005 12:05 >> > PM >> > > Subject: RE: Attach; Re: TD-46-1 6.4 >> > Clarification of >> > > statistic reset capability >> > > >> > > I think this is a great idea. I look >> > forward to your >> > > contribution in >> > > April. Maybe you can use the example >> > I cooked up in my >> > > earlier email as >> > > a start! ;) >> > > >> > > Kevin >> > > >> > > -----Original Message----- >> > > From: albrecht.schwarz(a)ties.itu.ch >> > > [mailto:albrecht.schwarz@ties.itu.ch] >> > > >> > > Sent: Friday, December 02, 2005 6:03 >> > AM >> > > To: Yangbo Lin >> > > Cc: albrecht.schwarz(a)ties.itu.ch; >> > Boyle, Kevin >> > > [NCRTP:3Z40:EXCH]; >> > > albrecht.schwarz(a)ties.itu.ch; >> > > arturo.martin-de-nicolas(a)ericsson.com; >> > > geoff.hunt(a)bt.com; cdahm(a)cisco.com >> > > Subject: Re: Attach; Re: TD-46-1 6.4 >> > Clarification of >> > > statistic reset >> > > capability >> > > >> > > See previous eamils. >> > > >> > > Nevertheless, there is a demand for >> > examples in order to >> > > illustrate the >> > > application of the Statistics >> > Descriptor capabilities. >> > > Just the note that I'll draft some >> > examples for next >> > > meeting. >> > > >> > > Albrecht >> > > PS >> > > My motivation is that I think that the >> > Statistics >> > > Descriptor is a fairly >> > > powerful tool due to: >> > > >> > > The Statistics Descriptor may contain, >> > according syntax >> > > specifications >> > > in Annex A and Annex B of H.248.1, >> > either * an empty >> > > list ("empty >> > > Statistics Descriptor"), or * an >> > explicit list of >> > > name/value pairs [NVP; >> > > (statistic name)/(statistic value); >> > statistic name is >> > > defined by >> > > PackageID/StatisticID], or * an >> > explicit list of >> > > statistic names without >> > > correspondent values (note: >> > > statistic value is optional), or >> > > * an explicit list of names and >> > name/value combinations. >> > > This syntactical definition of the >> > protocol allows a >> > > fairly flexible >> > > usage of the Statistics Descriptor. >> > Some examples may >> > > illustrate some >> > > use use cases. >> > > >> > > >> > > >> > > Quoting Yangbo Lin >> > <linyangbo(a)huawei.com>: >> > > >> > > > How can we perform read and/or >> > disable in one command? >> > > The statistic >> > > > included in the descriptor means it >> > should be read, >> > > and the statistic >> > > > excluded from the descriptor means >> > it should be >> > > disable. This seems a >> > > > conflict. So the read, disable and >> > re-enable need >> > > three commands, it >> > > > is too inefficient and do not >> > resolve problem, >> > > especially for the >> > > > extreme parameter. It is just the >> > cause we proposed >> > > the universal >> > > > resetting mechanism which want to >> > resolve the problem >> > > in one command. >> > > > >> > > > ----- Original Message ----- >> > > > From: >> > albrecht.schwarz(a)ties.itu.int >> > > > To: Kevin Boyle >> > > > Cc: albrecht.schwarz(a)ties.itu.ch ; >> > > linyangbo(a)huawei.com ; >> > > > >> > arturo.martin-de-nicolas(a)ericsson.com ; >> > > geoff.hunt(a)bt.com ; >> > > > cdahm(a)cisco.com >> > > > >> > > > Sent: Friday, December 02, 2005 >> > 11:17 AM >> > > > Subject: RE: Attach; Re: TD-46-1 >> > 6.4 Clarification >> > > of statistic >> > > > reset capability >> > > > >> > > > >> > > > I think >> > > > * we should be explicit that the >> > 1st Modify >> > > inherently supports >> > > > "Statistic read" >> > > > operation, in addition to the >> > "disable operation", >> > > > >> > > > and if this is true >> > > > * an additional AuditValue prior >> > to the first Modify >> > > is thus not >> > > > required. >> > > > >> > > > The assumption is that a dedicated >> > Statistics >> > > Descriptor setting in >> > > > the 1st >> > > > Modify allows "read and/or >> > disable" in one step. >> > > > My second assumption is, that the >> > 1st Modify may be >> > > replace by >> > > > AuditValue to get >> > > > adequate "read and/or disable" >> > operations in one >> > > step. >> > > > >> > > > If my understanding is correct, >> > then I'd like to >> > > propose to >> > > > a) replace "to disable" by " to >> > read and/or to >> > > disable", and >> > > > b) replace "the MGC may send a >> > Modify ..." by "the >> > > MGC may send a >> > > > Modify or >> > > > AuditValue ..." >> > > > >> > > > Albrecht >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > Quoting Kevin Boyle >> > <kboyle(a)nortel.com>: >> > > > >> > > > > I like the points raised by your >> > suggested text. >> > > How about this: >> > > > > >> > > > > For terminations not in the NULL >> > Context, the MGC >> > > may send a >> > > Modify >> > > > > Command with a Statistics >> > Descriptor to disable >> > > one or more >> > > statistics >> > > > > followed by a second Modify >> > Command including a >> > > Statistics >> > > > Descriptor to >> > > > > re-enable those statistics. As >> > explained above, >> > > this has the >> > > effect of >> > > > > resetting the included >> > statistics. By bundling >> > > the two commands >> > > > > together into the same action or >> > transaction, the >> > > MGC can minimize >> > > the >> > > > > time during which statistics are >> > not collected by >> > > the MG. >> > > > > >> > > > > If this looks OK, I will alter >> > the IG and upload >> > > it as 46a. >> > > > > >> > > > > Kevin >> > > > > >> > > > > -----Original Message----- >> > > > > From: >> > albrecht.schwarz(a)ties.itu.ch >> > > > >> > [mailto:albrecht.schwarz@ties.itu.ch] >> > > > > >> > > > > Sent: Friday, December 02, 2005 >> > 4:24 AM >> > > > > To: Boyle, Kevin >> > [NCRTP:3Z40:EXCH] >> > > > > Cc: >> > albrecht.schwarz(a)ties.itu.ch; >> > > linyangbo(a)huawei.com; >> > > > > >> > arturo.martin-de-nicolas(a)ericsson.com; >> > > geoff.hunt(a)bt.com; >> > > > > cdahm(a)cisco.com >> > > > > Subject: Attach; Re: TD-46-1 6.4 >> > Clarification of >> > > statistic reset >> > > > > capability >> > > > > >> > > > > Not sure whether attachment was >> > delivered. >> > > > > Again ... >> > > > > >> > > > > >> > > > > Quoting >> > albrecht.schwarz(a)ties.itu.int: >> > > > > >> > > > > > Kevin, >> > > > > > >> > > > > > pls find attached comments to >> > > > > > "6.4 Clarification of >> > statistic reset >> > > capability". >> > > > > > >> > > > > > Like to offer following change >> > proposals: >> > > > > > - "prior to Subtract" (of >> > course it's >> > > semantically correct) >> > > > > > - add AuditValue, >> > > > > > - add one or two Notes in >> > order to incate >> > > Statistic Descriptor >> > > > details >> > > > > >> > > > > > (this is important usage >> > information IMHO) >> > > > > > >> > > > > > Albrecht >> > > > > >> > > > > >> > > > > >> > > > > >> > > > >> > > > >> > > > >> > > >> > > >> > > >> > > >> > > >> > > >> > >> > >> > >> > >> > >> >> >> >> >> > > > > > > >----- End forwarded message ----- > > > > > >

1 0

H.248.1 - Examples for the Usage of the Statistics Descriptor
by Albrecht.Schwarz＠alcatel.de 15 Dec '05

15 Dec '05

Dear All! With regards to our discussions last WP2/16 meeting and: > This is why I believe contributions are needed to April's meeting. I'd like to inform you that we drafted a contribution with a first proposal: See in http://ftp3.itu.int/av-arch/avc-site/Incoming/ file: http://ftp3.itu.int/av-arch/avc-site/Incoming/Alcatelt1%20T05-SG16-060403-D… After intensive studies of § 7.1.15 we did finally come to the conclusion what a new Appendix for H.248.1 on"Practices on Statistics ? Exemplary Use Cases" could be one way forward. Comments? Albrecht PS Yangbo, the specific capability you are looking for is in IV.5.7 ----- Forwarded message from Kevin Boyle <kboyle(a)nortel.com> ----- Date: Fri, 2 Dec 2005 10:06:14 -0500 From: Kevin Boyle <kboyle(a)nortel.com> Reply-To: Kevin Boyle <kboyle(a)nortel.com> Subject: RE: 1 Comm. with 2 Descr.;RE: Attach; Re: TD-46-1 6.4 Clarification of statistic reset capability To: albrecht.schwarz(a)ties.itu.ch, Yangbo Lin <linyangbo(a)huawei.com> There is certainly no *documented* capability in H.248 to allow the MGC to assign a value to a statistic. This is why I believe contributions are needed to April's meeting. Kevin -----Original Message----- From: albrecht.schwarz(a)ties.itu.ch [mailto:albrecht.schwarz@ties.itu.ch] Sent: Friday, December 02, 2005 10:03 AM To: Yangbo Lin Cc: albrecht.schwarz(a)ties.itu.ch; Boyle, Kevin [NCRTP:3Z40:EXCH]; albrecht.schwarz(a)ties.itu.ch; geoff.hunt(a)bt.com; arturo.martin-de-nicolas(a)ericsson.com; cdahm(a)cisco.com; Christian Groves Subject: Re: 1 Comm. with 2 Descr.;RE: Attach; Re: TD-46-1 6.4 Clarification of statistic reset capability Firstly, the MGC as master and "prime served user" for H.248 statistics may perform any operation(as defined by H.248) on statistics. Secondly: >This capability is not in the existing protocol. I think that all outlined scenarios in these emails are syntactically, and even semantically in line with H.248.1. Could find sth against it in the spec. Albrecht Quoting Yangbo Lin <linyangbo(a)huawei.com>: > In my understanding, the statistic only operated by the MG, and the > MGC can only disable or enable it. This setting the statistic to zero > actually give the MGC the capability to interrupt the operation of > statistic arbitrarily as it will. This capability is not in the existing protocol. > > ----- Original Message ----- > From: albrecht.schwarz(a)ties.itu.int > To: Kevin Boyle > Cc: Yangbo Lin ; albrecht.schwarz(a)ties.itu.ch ; geoff.hunt(a)bt.com ; > arturo.martin-de-nicolas(a)ericsson.com ; cdahm(a)cisco.com ; Christian Groves > Sent: Friday, December 02, 2005 3:30 PM > Subject: RE: 1 Comm. with 2 Descr.;RE: Attach; Re: TD-46-1 6.4 > Clarification of statistic reset capability > > > Yangbo, > any "reset" operation comes finally down to the defined "data type" > and "value > range" of a dedicated statistic. > Reset means setting to the "initial value". > The initial value in the context of statistics is typically either > a) value = 0, or > b) value = 'unknown' (e.g., certain VoIP metrics). > > Of course the name/value combination in the context of a desired > reset operation > makes perhaps only sense for case (a), and I'm fairly sure, is only > required for > case (a). > But I will check out also potential metrics of type (b). > > Albrecht > > PS > Do you have already a specific statistic of type (b) in mind? > > > Quoting Kevin Boyle <kboyle(a)nortel.com>: > > > The intent is that the statistic will be explicitly set to 0. Of > > course, other statistics may need to be reset to some other default > > value. This puts the onus on the MGC to know what the "reset value" of > > all supported statistics are. > > > > So, the "0" is not a flag, it is a value. There is no exceptional > > request here. This syntax is legal, but the way to handle it in the MG > > is currently undefined in the spec. > > > > Kevin > > > > > > ________________________________ > > > > From: Yangbo Lin [mailto:linyangbo@huawei.com] > > Sent: Friday, December 02, 2005 9:11 AM > > To: Boyle, Kevin [NCRTP:3Z40:EXCH]; albrecht.schwarz(a)ties.itu.ch > > Cc: geoff.hunt(a)bt.com; albrecht.schwarz(a)ties.itu.ch; > > arturo.martin-de-nicolas(a)ericsson.com; cdahm(a)cisco.com; Christian > Groves > > Subject: Re: 1 Comm. with 2 Descr.;RE: Attach; Re: TD-46-1 6.4 > > Clarification of statistic reset capability > > > > > > Maybe I misunderstand, you mean the "SA{pkg/stat1=0}" represents > > the resetting? Is the "0" a reset flag or only a value? Does it request > > the MG to deal with the "0" exceptionally? Moreover, what will > happen if > > the "0" is a valid value of the parameter and no resetting value? > > > > > > ----- Original Message ----- > > From: Kevin Boyle <mailto:kboyle@nortel.com> > > To: Yangbo Lin <mailto:linyangbo@huawei.com> ; > > albrecht.schwarz(a)ties.itu.ch > > Cc: geoff.hunt(a)bt.com ; albrecht.schwarz(a)ties.itu.ch ; > > arturo.martin-de-nicolas(a)ericsson.com ; cdahm(a)cisco.com ; Christian > > Groves <mailto:cngroves@bigpond.net.au> > > Sent: Friday, December 02, 2005 2:51 PM > > Subject: RE: 1 Comm. with 2 Descr.;RE: Attach; Re: > > TD-46-1 6.4 Clarification of statistic reset capability > > > > The concept would look like this:(assume pkg/stat1 and > > pkg/stat2) > > > > !/3 [12.34.56.78]:2944 > > T=123{C=12{MF=term1{AT{SA{pkg/stat1}},SA{pkg/stat1=0,pkg/stat2}}}} > > > > This would lead to the following response: > > > > !/3 [12.34.56.79]:2944 > > P=123{C=12{MF=term1{pkg/stat1=123}}} > > > > Because this behavior is currently undocumented in the > > spec, this will require a contribution to Q3 in April. Albrecht has > > agreed to bring such a contribution. > > > > Kevin > > > > > > ________________________________ > > > > From: Yangbo Lin [mailto:linyangbo@huawei.com] > > Sent: Friday, December 02, 2005 8:45 AM > > To: albrecht.schwarz(a)ties.itu.ch; Boyle, Kevin > > [NCRTP:3Z40:EXCH] > > Cc: geoff.hunt(a)bt.com; > > albrecht.schwarz(a)ties.itu.ch; arturo.martin-de-nicolas(a)ericsson.com; > > cdahm(a)cisco.com > > Subject: Re: 1 Comm. with 2 Descr.;RE: Attach; > > Re: TD-46-1 6.4 Clarification of statistic reset capability > > > > > > Do you mean that a Modify command with three > > descriptors, i.e. Audit Descriptor (for read), Statistics Descriptor > > excluding the statistic (for disable and remain) and Statistics > > Descriptor including the statistic (for re-enable and reset) in order? > > Is it valid in protocol about including two Statistics Descriptors in > > one command? > > > > > > ----- Original Message ----- > > From: albrecht.schwarz(a)ties.itu.int > > <mailto:albrecht.schwarz@ties.itu.int> > > To: Kevin Boyle > > <mailto:kboyle@nortel.com> > > Cc: geoff.hunt(a)bt.com > > <mailto:geoff.hunt@bt.com> ; linyangbo(a)huawei.com > > <mailto:linyangbo@huawei.com> ; albrecht.schwarz(a)ties.itu.ch > > <mailto:albrecht.schwarz@ties.itu.ch> ; > > arturo.martin-de-nicolas(a)ericsson.com > > <mailto:arturo.martin-de-nicolas@ericsson.com> ; cdahm(a)cisco.com > > <mailto:cdahm@cisco.com> > > Sent: Friday, December 02, 2005 1:53 PM > > Subject: 1 Comm. with 2 Descr.;RE: > > Attach; Re: TD-46-1 6.4 Clarification of statistic reset capability > > > > > > We did discuss a potential improvement > > over lunch: > > > > 1 Modify Command with an Audit > > Descriptor (for read) & Statistics Descriptor > > (for reset) > > > > This solution is syntactically correct, > > requires only a single H.248 Command, > > and ensure processing in order. > > > > I'll bring a correspondent contribution > > to next meeting for updating IMGs (V2 & V3). > > > > - Albrecht > > > > Quoting Kevin Boyle <kboyle(a)nortel.com>: > > > > > While I think that is a valid > > optimization, I am not sure we can place > > > it in the protocol spec. The spec > > already goes out of its way to > > > require that transactions, actions and > > commands are executed in order. > > > Given this, I am not sure that we can > > put text in that allows an > > > explicit exception for this operation. > > > > > > This then becomes an implementation > > detail. As far as I am concerned, > > > as long as the MG executes the > > commands (in this case, report the stat > > > and clear it) it does not really > > matter whether that is done one command > > > at a time or in an optimized > > "one-step" fashion. > > > > > > Kevin > > > > > > > > > ________________________________ > > > > > > From: geoff.hunt(a)bt.com > > [mailto:geoff.hunt@bt.com] > > > Sent: Friday, December 02, 2005 6:40 > > AM > > > To: linyangbo(a)huawei.com; Boyle, Kevin > > [NCRTP:3Z40:EXCH]; > > > albrecht.schwarz(a)ties.itu.ch > > > Cc: > > arturo.martin-de-nicolas(a)ericsson.com; cdahm(a)cisco.com > > > Subject: RE: Attach; Re: TD-46-1 6.4 > > Clarification of statistic > > > reset capability > > > > > > > > > Is it possible to recommend that a > > gateway which *can* do > > > lookahead across the commands in a > > transaction, and sees read-and-reset > > > commands combined like this, *should* > > do the read-and-reset atomically? > > > This could ensure that no value which > > should contribute to the statistic > > > is lost between read and reset. > > > > > > I'm sorry I don't understand H.248 in > > enough depth and detail to > > > know whether there is any fundamental > > objection to this :( > > > > > > ________________________________ > > > > > > From: Yangbo Lin > > [mailto:linyangbo@huawei.com] > > > Sent: 02 December 2005 11:28 > > > To: Kevin Boyle; > > albrecht.schwarz(a)ties.itu.ch > > > Cc: > > arturo.martin-de-nicolas(a)ericsson.com; Hunt,RG,Geoff,XDE81 > > > R; cdahm(a)cisco.com > > > Subject: Re: Attach; Re: TD-46-1 6.4 > > Clarification of statistic > > > reset capability > > > > > > > > > OK, I just ignored this more efficient > > way, then we have a great > > > idea and a good example. Now the only > > leaving problem is how to avoid > > > the lost about the extreme value > > between the two command. I hope we can > > > discuss and resolve it in Q3 as early > > as possible. > > > > > > > > > ----- Original Message ----- > > > From: Kevin Boyle > > <mailto:kboyle@nortel.com> > > > To: albrecht.schwarz(a)ties.itu.ch > > > <mailto:albrecht.schwarz@ties.itu.ch> > > ; Yangbo Lin > > > <mailto:linyangbo@huawei.com> > > > Cc: > > arturo.martin-de-nicolas(a)ericsson.com > > > > > <mailto:arturo.martin-de-nicolas@ericsson.com> ; geoff.hunt(a)bt.com > > > <mailto:geoff.hunt@bt.com> ; > > cdahm(a)cisco.com <mailto:cdahm@cisco.com> > > > Sent: Friday, December 02, 2005 12:05 > > PM > > > Subject: RE: Attach; Re: TD-46-1 6.4 > > Clarification of > > > statistic reset capability > > > > > > I think this is a great idea. I look > > forward to your > > > contribution in > > > April. Maybe you can use the example > > I cooked up in my > > > earlier email as > > > a start! ;) > > > > > > Kevin > > > > > > -----Original Message----- > > > From: albrecht.schwarz(a)ties.itu.ch > > > [mailto:albrecht.schwarz@ties.itu.ch] > > > > > > Sent: Friday, December 02, 2005 6:03 > > AM > > > To: Yangbo Lin > > > Cc: albrecht.schwarz(a)ties.itu.ch; > > Boyle, Kevin > > > [NCRTP:3Z40:EXCH]; > > > albrecht.schwarz(a)ties.itu.ch; > > > arturo.martin-de-nicolas(a)ericsson.com; > > > geoff.hunt(a)bt.com; cdahm(a)cisco.com > > > Subject: Re: Attach; Re: TD-46-1 6.4 > > Clarification of > > > statistic reset > > > capability > > > > > > See previous eamils. > > > > > > Nevertheless, there is a demand for > > examples in order to > > > illustrate the > > > application of the Statistics > > Descriptor capabilities. > > > Just the note that I'll draft some > > examples for next > > > meeting. > > > > > > Albrecht > > > PS > > > My motivation is that I think that the > > Statistics > > > Descriptor is a fairly > > > powerful tool due to: > > > > > > The Statistics Descriptor may contain, > > according syntax > > > specifications > > > in Annex A and Annex B of H.248.1, > > either * an empty > > > list ("empty > > > Statistics Descriptor"), or * an > > explicit list of > > > name/value pairs [NVP; > > > (statistic name)/(statistic value); > > statistic name is > > > defined by > > > PackageID/StatisticID], or * an > > explicit list of > > > statistic names without > > > correspondent values (note: > > > statistic value is optional), or > > > * an explicit list of names and > > name/value combinations. > > > This syntactical definition of the > > protocol allows a > > > fairly flexible > > > usage of the Statistics Descriptor. > > Some examples may > > > illustrate some > > > use use cases. > > > > > > > > > > > > Quoting Yangbo Lin > > <linyangbo(a)huawei.com>: > > > > > > > How can we perform read and/or > > disable in one command? > > > The statistic > > > > included in the descriptor means it > > should be read, > > > and the statistic > > > > excluded from the descriptor means > > it should be > > > disable. This seems a > > > > conflict. So the read, disable and > > re-enable need > > > three commands, it > > > > is too inefficient and do not > > resolve problem, > > > especially for the > > > > extreme parameter. It is just the > > cause we proposed > > > the universal > > > > resetting mechanism which want to > > resolve the problem > > > in one command. > > > > > > > > ----- Original Message ----- > > > > From: > > albrecht.schwarz(a)ties.itu.int > > > > To: Kevin Boyle > > > > Cc: albrecht.schwarz(a)ties.itu.ch ; > > > linyangbo(a)huawei.com ; > > > > > > arturo.martin-de-nicolas(a)ericsson.com ; > > > geoff.hunt(a)bt.com ; > > > > cdahm(a)cisco.com > > > > > > > > Sent: Friday, December 02, 2005 > > 11:17 AM > > > > Subject: RE: Attach; Re: TD-46-1 > > 6.4 Clarification > > > of statistic > > > > reset capability > > > > > > > > > > > > I think > > > > * we should be explicit that the > > 1st Modify > > > inherently supports > > > > "Statistic read" > > > > operation, in addition to the > > "disable operation", > > > > > > > > and if this is true > > > > * an additional AuditValue prior > > to the first Modify > > > is thus not > > > > required. > > > > > > > > The assumption is that a dedicated > > Statistics > > > Descriptor setting in > > > > the 1st > > > > Modify allows "read and/or > > disable" in one step. > > > > My second assumption is, that the > > 1st Modify may be > > > replace by > > > > AuditValue to get > > > > adequate "read and/or disable" > > operations in one > > > step. > > > > > > > > If my understanding is correct, > > then I'd like to > > > propose to > > > > a) replace "to disable" by " to > > read and/or to > > > disable", and > > > > b) replace "the MGC may send a > > Modify ..." by "the > > > MGC may send a > > > > Modify or > > > > AuditValue ..." > > > > > > > > Albrecht > > > > > > > > > > > > > > > > > > > > > > > > Quoting Kevin Boyle > > <kboyle(a)nortel.com>: > > > > > > > > > I like the points raised by your > > suggested text. > > > How about this: > > > > > > > > > > For terminations not in the NULL > > Context, the MGC > > > may send a > > > Modify > > > > > Command with a Statistics > > Descriptor to disable > > > one or more > > > statistics > > > > > followed by a second Modify > > Command including a > > > Statistics > > > > Descriptor to > > > > > re-enable those statistics. As > > explained above, > > > this has the > > > effect of > > > > > resetting the included > > statistics. By bundling > > > the two commands > > > > > together into the same action or > > transaction, the > > > MGC can minimize > > > the > > > > > time during which statistics are > > not collected by > > > the MG. > > > > > > > > > > If this looks OK, I will alter > > the IG and upload > > > it as 46a. > > > > > > > > > > Kevin > > > > > > > > > > -----Original Message----- > > > > > From: > > albrecht.schwarz(a)ties.itu.ch > > > > > > [mailto:albrecht.schwarz@ties.itu.ch] > > > > > > > > > > Sent: Friday, December 02, 2005 > > 4:24 AM > > > > > To: Boyle, Kevin > > [NCRTP:3Z40:EXCH] > > > > > Cc: > > albrecht.schwarz(a)ties.itu.ch; > > > linyangbo(a)huawei.com; > > > > > > > arturo.martin-de-nicolas(a)ericsson.com; > > > geoff.hunt(a)bt.com; > > > > > cdahm(a)cisco.com > > > > > Subject: Attach; Re: TD-46-1 6.4 > > Clarification of > > > statistic reset > > > > > capability > > > > > > > > > > Not sure whether attachment was > > delivered. > > > > > Again ... > > > > > > > > > > > > > > > Quoting > > albrecht.schwarz(a)ties.itu.int: > > > > > > > > > > > Kevin, > > > > > > > > > > > > pls find attached comments to > > > > > > "6.4 Clarification of > > statistic reset > > > capability". > > > > > > > > > > > > Like to offer following change > > proposals: > > > > > > - "prior to Subtract" (of > > course it's > > > semantically correct) > > > > > > - add AuditValue, > > > > > > - add one or two Notes in > > order to incate > > > Statistic Descriptor > > > > details > > > > > > > > > > > (this is important usage > > information IMHO) > > > > > > > > > > > > Albrecht > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- End forwarded message -----

1 0

Fwd:Tree structure view of available meeting documents
by OKUBO Sakae 06 Dec '05

06 Dec '05

*** This looks a great improvement -- Sakae OKUBO *** >Subject: Tree structure view of available meeting documents >Date: Tue, 6 Dec 2005 18:17:23 +0100 >Thread-Topic: Tree structure view of available meeting documents >Thread-Index: AcX6h9Xig12CLb9CSr648izhtHDt6wAAMVpw >From: <simao.campos(a)itu.int> >To: <t05sg16mgt(a)ties.itu.int>, <tsg6mgt(a)ties.itu.int> >Sender: owner-t05sg16mgt(a)itu.int >Reply-To: <simao.campos(a)itu.int> >X-Greylist: Sender IP whitelisted, not delayed by >milter-greylist-2.0.2 (mail4.itu.ch [156.106.192.20]); Tue, 06 Dec >2005 18:18:04 +0100 (MET) >X-Biglobe-VirusCheck: Wed, 07 Dec 2005 02:18:10 +0900 > >Dear colleagues, > >you may find this way of checking meeting documents more convenient >than before. Please share it with experts in your Qs. Specific >feedback/problems should be provided directly to TSB EDH >(<mailto:tsbedh@itu.int>tsbedh(a)itu.int). > >Best regards, >Sim黍 > > >From: owner-tsagwp3(a)itu.int [mailto:owner-tsagwp3@itu.int] On Behalf >Of Al.Dayao(a)itu.int >Sent: 06 December 2005 18:10 >To: tsagwp3, ITU (MLIST) >Cc: TSBEDH, ITU >Subject: TSAG-D30 Proposal: Provide tree structure of list of >meeting documents > >Dear TSAG WP3 Participants, > >Following the proposal of Republic of Korea for enhancements in the >electronic working environment in ITU-T meetings, a new web page has >been created based on the information provided in TSAG Delayed >Contribution 30 ( ><http://www.itu.int/md/meetingdoc.asp?type=mitems&lang=e&parent=T05-TSAG-051…>http://www.itu.int/md/meetingdoc.asp?type=mitems&lang=e&parent=T05-TSAG-051… ). > >The new page lists all the meeting documents available in DMS and in >the Informal FTP areas (IFAs) of all the Study Groups using a >directory tree menu structure. It allows the users to view all the >Study Groups' documents without display limit and provides quick >navigation across the different Study Group documents without having >to open other pages. > >A link to the new page has been included in the TSAG as well as in >all the Study Groups main pages under the item "View Documents in >Directory Tree Mode". > >The new page is available here: ><http://www.itu.int/ITU-T/meetingdocs/index.asp>http://www.itu.int/ITU-T/meetingdocs/index.asp > >Kind regards, >Al Dayao >TSB EDH Coordinator

1 0

Fwd:Tree structure view of available meeting documents
by OKUBO Sakae 06 Dec '05

06 Dec '05

*** This looks a great improvement -- Sakae OKUBO *** >Subject: Tree structure view of available meeting documents >Date: Tue, 6 Dec 2005 18:17:23 +0100 >Thread-Topic: Tree structure view of available meeting documents >Thread-Index: AcX6h9Xig12CLb9CSr648izhtHDt6wAAMVpw >From: <simao.campos(a)itu.int> >To: <t05sg16mgt(a)ties.itu.int>, <tsg6mgt(a)ties.itu.int> >Sender: owner-t05sg16mgt(a)itu.int >Reply-To: <simao.campos(a)itu.int> >X-Greylist: Sender IP whitelisted, not delayed by >milter-greylist-2.0.2 (mail4.itu.ch [156.106.192.20]); Tue, 06 Dec >2005 18:18:04 +0100 (MET) >X-Biglobe-VirusCheck: Wed, 07 Dec 2005 02:18:10 +0900 > >Dear colleagues, > >you may find this way of checking meeting documents more convenient >than before. Please share it with experts in your Qs. Specific >feedback/problems should be provided directly to TSB EDH >(<mailto:tsbedh@itu.int>tsbedh(a)itu.int). > >Best regards, >Sim黍 > > >From: owner-tsagwp3(a)itu.int [mailto:owner-tsagwp3@itu.int] On Behalf >Of Al.Dayao(a)itu.int >Sent: 06 December 2005 18:10 >To: tsagwp3, ITU (MLIST) >Cc: TSBEDH, ITU >Subject: TSAG-D30 Proposal: Provide tree structure of list of >meeting documents > >Dear TSAG WP3 Participants, > >Following the proposal of Republic of Korea for enhancements in the >electronic working environment in ITU-T meetings, a new web page has >been created based on the information provided in TSAG Delayed >Contribution 30 ( ><http://www.itu.int/md/meetingdoc.asp?type=mitems&lang=e&parent=T05-TSAG-051…>http://www.itu.int/md/meetingdoc.asp?type=mitems&lang=e&parent=T05-TSAG-051… ). > >The new page lists all the meeting documents available in DMS and in >the Informal FTP areas (IFAs) of all the Study Groups using a >directory tree menu structure. It allows the users to view all the >Study Groups' documents without display limit and provides quick >navigation across the different Study Group documents without having >to open other pages. > >A link to the new page has been included in the TSAG as well as in >all the Study Groups main pages under the item "View Documents in >Directory Tree Mode". > >The new page is available here: ><http://www.itu.int/ITU-T/meetingdocs/index.asp>http://www.itu.int/ITU-T/meetingdocs/index.asp > >Kind regards, >Al Dayao >TSB EDH Coordinator

1 0

Re: Summary of the last week Rapporteur meeting
by OKUBO Sakae 05 Dec '05

05 Dec '05

Dear experts, At 7:22 AM -0500 05/12/05, OKUBO Sakae wrote: >[...]Q.1 documents will be advised separately. Mr. Patrick Luthi has announced the following: At 3:00 PM +0100 05/12/05, Patrick Luthi wrote: >The Rapporteur meeting of Q.1/16 has concluded. This was a busy >meeting with 24 input contributions (+ several docs. generated at >the meeting) and I am happy to report that we made some good >progress in 2 main areas: H.241 and H.324M. > >The meeting report can be found here: >http://ftp3.itu.int/av-arch/lbc-site/0511_Geneva/q1e33.doc > >The report will remain posted for a couple of weeks with change >marks on, so experts can see the changes and additions that were >made during the closing session. > >The final list of documents is available here: >http://ftp3.itu.ch/av-arch/lbc-site/0511_Geneva/q1e00r2.doc -- Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering Waseda University ****************************************************************** Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan H.323 videoconferencing: arranged by advice ******************************************************************

1 0

Q1/16 meeting has concluded: report and documents
by Patrick Luthi 05 Dec '05

05 Dec '05

Dear experts, The Rapporteur meeting of Q.1/16 has concluded. This was a busy meeting with 24 input contributions (+ several docs. generated at the meeting) and I am happy to report that we made some good progress in 2 main areas: H.241 and H.324M. The meeting report can be found here: http://ftp3.itu.int/av-arch/lbc-site/0511_Geneva/q1e33.doc The report will remain posted for a couple of weeks with change marks on, so experts can see the changes and additions that were made during the closing session. The final list of documents is available here: http://ftp3.itu.ch/av-arch/lbc-site/0511_Geneva/q1e00r2.doc Best regards, Patrick Luthi Rapporteur for Q.1/16

1 0

Summary of the last week Rapporteur meeting
by OKUBO Sakae 05 Dec '05

05 Dec '05

Dear experts, The following are the reports and liaison statements for Questions 2, 3, 4, 5, 21, 22, 24 and 25. Q.1 documents will be advised separately. -------------------------------------------------------- Topic Report Liaison statements -------------------------------------------------------- Question 2 TD-11a TD-56, TD-57 Question 3 TD-12a TD-39a, TD-40, TD-41b, TD-49a Question 4 TD-13a Question 5 TD-14a Question 21 TD-15 TD-53 Question 22 TD-16a Question 24 TD-17 Question 25 TD-18a TD-28a, TD-29, TD-30 General TD-55a -------------------------------------------------------- They are available at: http://ftp3.itu.int/av-arch/avc-site/2005-2008/0511_Gen/ or ftp://ftp3.itu.int/avc-site/2005-2008/0511_Gen/ user: avguest, password:Avguest -- Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering Waseda University ****************************************************************** Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan H.323 videoconferencing: arranged by advice ******************************************************************

1 0

Fwd: Sentence for Annex A/H.324
by Patrick Luthi 01 Dec '05

01 Dec '05

Dear experts, Here is the proposed sentence from the H.241 editor to consider to include in A.1/H.324 tomorrow morning: "It is recommended that, when possible, multiple H.245 messages should be sent in each single SRP or LAPM frame in order to reduce the number of round-trip message exchanges and frame header overhead." I suggest we discuss in Q.1 whether or not we want to leave out the 3 bold words. --Dave See you tomorrow morning at 9.00! Patrick Luthi Rapporteur for Q.1/16

1 0

Incoming liaison from IMTC
by Patrick Luthi 29 Nov '05

29 Nov '05

Dear experts, We have just received a liaison statement from the IMTC 3G-324M AG titled "LS Response to call setup time improvement methods for H.324". It will be document Q1-E24 and I have updated the agenda to consider it at this Q.1 meeting. Best regards, Patrick Luthi Rapporteur for Q.1

1 0