February 2003 - sg16-avd - lists.packetizer.com

Re: Use of RTCP statistics for estimating QoS of VoIP
by frank.derks＠PHILIPS.COM 16 Apr '03

16 Apr '03

Alan, I have just had a look at the final version sof H.460.9 and I could not find any text that explains the real value of the QoS information that can be transported (not including future extensions of course). This is a real pity, because I do agree that many implementors will not be well informed enough to determine the value of the information from the standard RTCP packets. Regards, Frank Alan Clark <alan(a)TELCHEMY.COM> Sent by: Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)echo.jf.INTEL.COM> 2002-11-08 18:29 Please respond to alan To: ITU-SG16(a)echo.jf.INTEL.COM cc: (bcc: Frank Derks/HVS/BE/PHILIPS) Subject: Re: Use of RTCP statistics for estimating QoS of VoIP Classification: Frank I did suggest (via Mike Buckley) that the following be added to H.460.9 however don't know if it was actually included. " It should be noted that RTCP reports were not originally intended to provide accurate QoS metrics but for informative exchanges between endpoints to support possible dynamic configuration. According to RFC1889 (a) received packet count may include duplicate packets and hence it is possible to report negative packet loss (b) reported mean packet-to-packet delay variation (jitter) is averaged over the last 16 received packets and hence provides information only on the 160-480mS period immediately preceding transmission of the RTCP report." I do agree with you that potential implementors may well feel uncomfortable that the Recommendation in its initial form contains information that has little or no value. I am even more concerned that less well informed implementors may accept what is in the Recommendation as being "sufficient" and hence attempt to manage VoIP services with metrics that can be quite misleading. Regards Alan -----Original Message----- From: frank.derks(a)philips.com [mailto:frank.derks@philips.com] Sent: Friday, November 08, 2002 2:46 AM To: alan(a)TELCHEMY.COM Cc: ITU-SG16(a)echo.jf.INTEL.COM Subject: Re: Use of RTCP statistics for estimating QoS of VoIP Alan, I certainly agree that, if the main body of the Recommendation covers metrics that are of little practical use of the recipient of these metrics, the Recommendation can be misleading. Only with the proper background information will the reader be able to distinguish the real value in the particular metrics. I feel somewhat uncomfortable when the main body of a Recommendation provides me with something that is of little value, but which can be extended to include more useful information. A possible way "out of this", is to include some text that clearly explains the situation and that reflects the concerns that were raised and agreed upon. Regards, Frank Bob I appreciate that a mechanism was provided to permit extension of H.460.9 and that it was agreed to incorporate the RTCP Extensions, once standardized. This does make a lot of sense and would definitely accomodate the new metrics when available. The reason behind my email yesterday was that we often find that equipment manufacturers, service providers and network managers don't understand this area as well as those who are actively conducting R&D in this area, and hence in this case they may assume that RFC1889 metrics are "good" for monitoring VoIP QoS since they are contained in H.460.9. This is already a continual re-education process with the metrics in RFC1889 .. their inclusion in H.460.9 will make the task even more difficult. People within the industry have great respect for the ITU, understand that there is an extensive process of technical discussion and review that is part of the process of developing ITU standards, and hence place considerable faith in the technical content of ITU Recommendations. In this specific case H.460.9 contains metrics which are known to be inadequate for the purpose of measuring VoIP QoS and hence there is a risk of deployment of an incorrect or inappropriate element due to its incorporation in an ITU Recommendation. I am not trying to be "difficult" but tried to input essentially the same viewpoints prior to the SG16 meeting and am genuinely concerned over the outcome. Regards Alan Clark -----Original Message----- From: Mailing list for parties associated with ITU-T Study Group 16 [mailto:ITU-SG16@echo.jf.INTEL.COM]On Behalf Of Robert R. Gilman Sent: Wednesday, November 06, 2002 8:13 PM To: ITU-SG16(a)echo.jf.INTEL.COM Subject: Re: Use of RTCP statistics for estimating QoS of VoIP Alan- Mike Buckley brought up the same questions you raise at the last SG16 meeting. I don't believe anyone objects to your arguments, and, in fact, the resulting work, H.460.9, was modified to permit extension to other measures and the exclusion of the current, IETF-standardized, measures. Once the IETF draft you reference becomes a standard, it will be easy to refer to the resulting RFC and to incorporate the resulting measures as appropriate. In the meantime, you have the option to use the existing measures and, through the definition of non-standard elements, any other measures you wish to implement on a permanent or trial basis. It seemed better to set the framework now, so that implementation and use can begin, and to do so in such a way that future improvements may be incorporated quickly and easily. Does this make sense? -Bob ---------------------------------------------------- Bob Gilman rrg(a)avaya.com +1 303 538 3868 Alan Clark wrote: > > Paul > > I am responding to the recent SG16 email that encouraged direct input from > those not participating directly in the work of the Study Group. > > One particular recent issue relates to the recent addition of QoS reporting > based on RTCP statistics. We have spent the last three years analyzing and > modeling the effects of IP network impairments on VoIP and would like to > share our experience on this issue. > > RTCP statistics were intended to provide a "rough" real time feedback > between endpoints to give some sense of network quality and facilitate > potential adaptation. IP network impairments are transient in nature and > the "averaged" metrics that RFC1889 produces are as a result very > misleading. The addition of QoS reporting based on RFC1889 metrics is, in > our opinion, a backward step as it infers that these statistics are useful > for VoIP quality estimation whereas they are in fact almost meaningless. > > (i) Packet Loss - counts > RFC1889 counts of loss are not compensated for duplicate packets, hence it > is possible to have incorrect and even negative (!!) loss counts. > > (ii) Packet Loss- distribution > Voice quality is very sensitive to the distribution of packet loss - if 2% > loss occurs but the losses are spread out evenly then with PLC quality would > be affected only marginally, if 1% loss occurs but losses occur during short > intervals (typically the case) then quality can be affected quite > significantly. > RFC1889 does not consider the distribution of lost packets and hence packet > loss numbers can only grossly be equated to call quality (i.e. loss rate of > 20% is bad but you couldn't say for sure if 2% was bad or not) > > (iii) Jitter - metric > The average packet-to-packet delay variation used in RFC1889 does not > properly reflect the effects of congestion related delay changes. For > example > (a) if congesion occurs and a queue starts to fill then delay increases > however the packet-to-packet delay change may be small however the increase > in delay may cause the jitter buffer to resynchronize at some stage. > (b) LAN congestion can cause short term spikes in delay, and hence may lead > to packet discards. The average packet-to-packet delay variation will not > reflect this due to the smoothing effect of the averaging algorithm. > > (iv) Jitter - reporting interval > As jitter is reported as a running average with a scaling factor of 16, an > RTCP report only describes the jitter level during the 200mS or so prior to > the report being generated and says nothing about the jitter level during > the much larger period between reports. > > We have spoken to, and worked with, people in the industry that have been > looking at this issue in detail and have found general agreement with the > comments above. Unfortunately, there are also a fair number of people that > blindly accept that something must be "ok" because it is "in a standard" .. > this obviously raised the concern that incorporating these metrics into the > H series of standards further proliferates this viewpoint. > > Within the IETF AVT group this issue was discussed almost a year ago, and > the group agreed to develop a set of metrics that were more accurate and > appropriate for VoIP QoS reporting purposes. These include measures of > packet loss, packets discarded due to jitter, length and density of bursts > and gaps (of combined loss and discard), delay, call quality metrics... > This is contained in the following:- > > draft-ietf-avt-rtcp-report-extns-01.txt > > I would very much appreciate understanding the technical rationale behind > incorporating RFC1889 based metrics into VoIP QoS reports, given the > comments above. > > Regards > > Alan Clark > Telchemy > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)lists.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

6 10

Reminder of Q.H/16 Accessibility Rapporteur Meeting. Cutoff date Feb. 26!!
by Gunnar Hellström 25 Feb '03

25 Feb '03

To Experts of ITU-T SG16 Question H: Accessibility to Multimedia Systems and services Cc Mr. P-A. Probst, Chairman of SG16 <probst-pa(a)bluewin.ch> Mr. M. Matsumoto, WP 1/16 Chairman <matsumoto(a)giti.waseda.ac.jp> Mr. S. Campos-Neto, ITU TSB <simao.campos(a)itu.int> >From G Hellstrom Rapporteur for Q.H/16 <gunnar.hellstrom(a)omnitor.se> ------------------------------------------------------------------- Subject: Reminder of Joint Rapporteur Meeting in Streatley, Berkshire, UK Date: March 18-19 2003 ------------------------------------------------------------------- Dear experts of ITU-T Question H/16. A Rapporteur meeting for ITU-T Q.H/16 Experts will be held in Streatley, Berkshire, UK on March 18-19. The meeting is co-located with a meeting of Q.11/16 in order to get an opportunity to discuss joint matters in the Text over IP area. The cutoff date for booking in the selected hotel, and announcement of your intention to participate is February 26, 18.00 GMT. Details of the meeting can be found in the attached document. Best regards ------------------------------------------- Gunnar Hellström Omnitor AB Renathvägen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom(a)Omnitor.se -------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Text over IP existing standards- requirements - use cases - solutions
by Gunnar Hellström 21 Feb '03

21 Feb '03

Dear all, The discussion about solutions for text over IP is moving on. One goal for Q.H/16 is to have a requirement spec agreed from the rapporteurs meeting March 18-19 in UK. I have collected some material belonging to this work in www.totalconversation.org - An overview presentation over standards and solutions made for the ATIS seminar on Jan.13. - A small discussion presentation around the proposed requirement spec, a proposed division in use cases and one brief solution. - A draft requirement spec, intended to go as a contribution to the Q.H meeting. Please review the draft requirement spec, and comment directly to me or as contributions to the Q.H meeting. Please also remember to sign up for the announced Q.H/16 rapporteurs meeting not later than Feb. 26. I have noticed that it is good to have a list of already approved standards at hand when discussiong this topic. So: Already approved from standards groups of importance in the TVoIP discussion: -------------------------------------------------------------------------- - ITU-T F.700 Multimedia framework. Appendix 3, Defines media, among them Conversational text in two quality levels T1 and T2. T1 alows 1% errors. T2 allows 0.2 % error rate. - ITU-T F.703 Multimedia Conversation Service Description. Defines among other services Text Telephony and Total Conversation, and gives basic characteristics and requirements. This should be the starting point for the current work. - ITU-T V.18, an automoding text telephony standard including Baudot TTY. When it is specified "V.18 or any of its legacy submodes", it can be interpreted "Baudot TTY" in USA if you want. - ITU-T T.140, a presentation level text conversation protocol based on Unicode. Used in all multimedia environments to add a simple text dialogue to it. The natural choice for any effort to make TTY-like text conversations in other networks. - ITU-T H.323 Annex G Text Conversation and Text SET. Both the text telephone for H.323 VoIP networks, and the text component to add to H.323 Multimedia environment. - IETF RFC 2793, RTP Packetization for T.140. A description of how to pack T.140 text in packets for transmission with the RTP protocol, commonly used for media transmission in both H.323 and SIP multimedia and VoIP. Includes a standardised method for repeating information in sequential packets for increasing reliability. Includes also the MIME registration so that text/t140 can be started in a SIP textphone or multimedia phone. - ITU-T H.248.2 Text and Fax and call discrimination packages for the H.248 gateway protocol. Makes use of V.18, and other standards for discrimination between voice fax and and text telephony on PSTN lines, and has methods for establishing and transmitting text over the IP network with T.140 and RFC 2793. The application of V.18 principles in H.248.2 allows configuration to only support one or a few text telephone types ( e.g. Baudot and native V.18 ) H.248 is one of the dominating gateway architectures for VoIP. - 3GPP 26.235, 22.226, 23.226 reuses T.140 with RFC2793 in SIP connections with text in 3G wireless environments and gatewayes with H.248.2 to TTY and other textphones. - 3GPP 26.226 CTM describes a robust method to transport T.140 text over a voice channel, with possible conversion in both ends to other forms of text telephony, e.g. V.18 or Baudot TTY. Used in GSM wireless networks. These standards form a good base when now defining the application in ToIP. Regards Gunnar ------------------------------------------- Gunnar Hellström Omnitor AB Renathvägen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom(a)Omnitor.se -------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Presence in LDAP
by Anatoli Levine 19 Feb '03

19 Feb '03

FYI -----Original Message----- From: Tyler Miller Johnson [mailto:trjohns1@email.unc.edu] Sent: Wednesday, February 19, 2003 11:37 AM To: h323forum Subject: [h323forum] Presence in LDAP Dear H323Forum User, I have been following the recent discussions about presence and instant messaging in H.323. I am the editor of a proposed new series of recommendations from ITU-T Study Group 16 on directory services architectures for multimedia conferencing. The architecture has been under review in SG16 for sometime, and we are hoping for ratification in May of this year if all goes well. The architecture is LDAP based and provides a way for users to be listed in directories in a standardized way, allowing searching of enterprise directories, and even searching of directory portals which can find users across the Internet. The architecture also supports the management of users through LDAP, rather than through closed databases associated with gatekeepers or SIP proxies. Early on it became evident that we could easily support presence through this architecture through the addition of a simple attribute. However, we chose not to add that because there already seemed to be confusion in the presence space with competing protocols. We did not want to cloud the issue. In some ways, the LDAP approach to presence is perhaps more scalable as it addresses security and large scale federation (i.e. inter-institutional) dynamics more directly. My question is, should SG16 re-visit this issue in regards to LDAP, or leave it out as it currently stands? Regards, Tyler Johnson Editor, H.LDAP --- You are currently subscribed to h323forum as: alevine(a)radvision.com To unsubscribe send a blank email to leave-h323forum-27275U(a)mail.imtc.org ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Re: Recommendations from the FS-VDSL Focus Group
by OKUBO Sakae 16 Feb '03

16 Feb '03

*** Forwarded to WP2/16 members. I have failed to take this up *** *** at the San Jose meeting - Sakae OKUBO (WP2/16 chairman) *** At 10:51 +0000 03/02/12, John Magill wrote: >Gentlemen, > >During your Rapporteur meetings this week, I would be grateful if >you would remind the WP2 delegates present of the new SG16 work on >Recommendations for Full Service VDSL. These are: >H.fsv-arch - Full Service VDSL - service architecture and CPE >H.fsv-oamp - Full Service VDSL - Operations, Administration, >Maintenance and Provisioning. >It is intended that these Recommendations will be proposed for >Consent at the May 2003 meeting of SG16, and they will be discussed >at the Focus Group meeting and potential Rapporteur meetings >(subject to interest) in Toronto 4-6 March. > >The latest drafts are available at the ftp site: >ftp://ftp3.itu.int/fsvdsl/ >For information on how to get access to the ftp site and subscribe >to the email reflector, see: >http://www.itu.int/ITU-T/studygroups/com16/fs-vdsl/edh-info.html > >The Associate Rapporteurs for this work are: >Associate Rapporteur for architecture Recommendation (Q.B) - Stephane >Py <stephane.py(a)rd.francetelecom.com> >Associate Rapporteur for OAM&P Recommendation (Q.C) - Peter Adams ><p.f.adams(a)btopenworld.com> > >Comments or questions on the drafts should be sent to the Associate >Rapporteurs, or to the reflector <fsvdsl-fg(a)itu.int>. > >I am also happy to take comments and general questions. > >Thanks for your help. I hope you are having a productive meeting. > >Best regards > >John > > > >----------------------------------------------------- >John Magill >Tel: +44 1666 510105 >Fax: +44 8700 527645 >Email: johnmagill(a)probecom.co.uk >----------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Outcome of the San Jose meeting
by OKUBO Sakae 15 Feb '03

15 Feb '03

Dear SG16 experts, The meeting reports of the just finished Q.D,F,G,2-5/16 meeting in San Jose are found at the following place: http://standard.pictel.com/ftp/avc-site/0302_San/TD-11.zip Q.F http://standard.pictel.com/ftp/avc-site/0302_San/TD-12a.zip Q.G http://standard.pictel.com/ftp/avc-site/0302_San/TD-13c.zip Q.2 http://standard.pictel.com/ftp/avc-site/0302_San/TD-14b.zip Q.3 http://standard.pictel.com/ftp/avc-site/0302_San/TD-15a.zip Q.4 -- Best regards, OKUBO Sakae e-mail: okubo(a)giti.waseda.ac.jp ******************************************************************* YRP Office Global Information and Telecommunication Institute (GITI) 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 GITI Headquarter 29-7 Waseda University Bldg. Tel: +81 3 5286 3831 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo Fax: +81 3 5286 3832 169-0051 Japan ******************************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

New ITU-T templates for documents
by OKUBO Sakae 13 Feb '03

13 Feb '03

---< Message from ITU-TSB >--- Dear all, As it was kindly pointed out to us, although you were informed about the existance of new templates (http://www.itu.int/ITU-T/studygroups/templates) there was no follow-up about their use. You may notice that the "Author's template" is just a plain table requesting to input certain information and later the text of the document. All documents (white, delayed, TDs) will be based on this same template. When they reach the TSB, a macro is applied in order to "transform" it into the appropriate type of document (only after this the ITU logo, headers, etc of the final published document will appear). This was implemented in order to avoid any changes that the document might have suffered when the TSB template was used. Please note that the aforementioned macro is *internal* to the TSB, they are not available to you, as many delegates expressed strong reservations against documents that have embedded macros. In a nutsheel, what is required of the authors is that you fill in (or fill out :-) the simple Winword table as provided in the template, and we will take care of the rest. Please, do not change its format (no more, no less rows or columns!). If you have any questions please feel free to contact me. Best regards Ms. Leslie Jones, Assistant ITU-T Study Group 16 International Telecommunication Union Place des Nations 1211 Geneva 20 Switzerland Tel: +41 22 730 5808 Fax: +41 22 730 5853 e-mail: leslie.jones(a)itu.int Study Group 16 e-mail: tsbsg16(a)itu.int ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Re: H323 for Instant Message and Presence information suppo rt?
by Ahmar Ghaffar 13 Feb '03

13 Feb '03

Markku, I gave some thought to this idea and i discussed this with Paul too a couple of months ago. My opinion is that Instant Messaging would be a bit too shall we say "heavy" on the H.323 protocol. Besides i think the scope of IM and SMS is quite different. Of course you can incorporate IM in H.323 but the question is, is this service really needed in H.323? What do you think? . The reason i took up SMS was that this service is already quite popular (also MMS now) and other signalling protocols are supporting somewhat similar services. If H.323 is to survive then it has to have a similar service. Another reason was that many vendors are supporting SMS in their own proprietary ways, so i thought why not define a standard which everybody can use. So in my opinion IM is not really so important from H.323 perspective. However i would give some serious thought to Presence Notification. Because this would be a really useful service. Maybe i can take this up when we are done with the SMS spec. :-) Regards Ahmar ----- Original Message ----- From: "Markku Korpi" <korpim(a)cosini.com> To: "Ahmar Ghaffar" <ghaffar(a)snom.de> Sent: Thursday, February 13, 2003 1:35 PM Subject: FW: H323 for Instant Message and Presence information suppo rt? > Ahmar, > > this email appeared on the ITU-T SG16 reflector just a couple of minutes > ago, after I sent out the previous email. > IM is diferent than SMS, of course, but what would it mean if we would > defiem IM over H.323 and use it also for SMS? > Could it be used for interworking with SMS, too? > > Markku > > -----Original Message----- > From: Mailing list for parties associated with ITU-T Study Group 16 > [mailto:ITU-SG16@echo.jf.INTEL.COM]On Behalf Of Anatoli Levine > Sent: Tuesday, February 11, 2003 8:50 AM > To: ITU-SG16(a)echo.jf.INTEL.COM > Subject: FW: [HvS] H323 for Instant Message and Presence information > suppo rt? > > > Interesting question - anyone wants to take a stub at it? > > Thanks, > Anatoli > > -----Original Message----- > From: Xiaotao Wu [mailto:xiaotaow@hotmail.com] > Sent: Tuesday, February 11, 2003 11:41 AM > To: Hvs(a)packetizer.com > Subject: [HvS] H323 for Instant Message and Presence information > support? > > > In the article "H.323 versus SIP: A Comparison", seems a very important > aspect of Internet Telephony prodcut (NOTE: not Telephony product) is missed > > -- how easily to integrate the H323 or SIP products with the other Internet > services? > > Is there any effort in H323 on supporting Instant Message and presence > information -- an important and convinient service over the Internet? > Or we have to say that any H323 terminal has to have a separate messenger > with it for IM and presence information, and any H323 proxy has to have a > separate presence agent with it. For SIP, with the effort in SIMPLE working > group, this can be easily solved, and it's easy to add a presence agent to a > > SIP proxy server. > > Thanks! > > _________________________________________________________________ > The new MSN 8: smart spam protection and 2 months FREE* > http://join.msn.com/?page=features/junkmail > > > _______________________________________________ > H.323-versus-SIP mailing list (hvs(a)packetizer.com) > http://host4.imagelinkusa.net/mailman/listinfo/hvs_packetizer.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)lists.intel.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

New ITU-T templates for documents
by Campos, Simao 13 Feb '03

13 Feb '03

Dear all, As it was kindly pointed out to us, although you were informed about the existance of new templates (http://www.itu.int/ITU-T/studygroups/templates) there was no follow-up about their use. You may notice that the "Author's template" is just a plain table requesting to input certain information and later the text of the document. All documents (white, delayed, TDs) will be based on this same template. When they reach the TSB, a macro is applied in order to "transform" it into the appropriate type of document (only after this the ITU logo, headers, etc of the final published document will appear). This was implemented in order to avoid any changes that the document might have suffered when the TSB template was used. Please note that the aforementioned macro is *internal* to the TSB, they are not available to you, as many delegates expressed strong reservations against documents that have embedded macros. In a nutsheel, what is required of the authors is that you fill in (or fill out :-) the simple Winword table as provided in the template, and we will take care of the rest. Please, do not change its format (no more, no less rows or columns!). If you have any questions please feel free to contact me. Best regards Ms. Leslie Jones, Assistant ITU-T Study Group 16 International Telecommunication Union Place des Nations 1211 Geneva 20 Switzerland Tel: +41 22 730 5808 Fax: +41 22 730 5853 e-mail: leslie.jones(a)itu.int Study Group 16 e-mail: tsbsg16(a)itu.int ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Notice of Q.H/16 Accessibility Rapporteur Meeting
by Gunnar Hellström 12 Feb '03

12 Feb '03

To Experts of ITU-T SG16 Question H: Accessibility to Multimedia Systems and services Cc Mr. P-A. Probst, Chairman of SG16 <probst-pa(a)bluewin.ch> Mr. M. Matsumoto, WP 1/16 Chairman <matsumoto(a)giti.waseda.ac.jp> Mr. S. Campos-Neto, ITU TSB <simao.campos(a)itu.int> >From G Hellstrom Rapporteur for Q.H/16 <gunnar.hellstrom(a)omnitor.se> ------------------------------------------------------------------- Subject: Notice of Joint Rapporteur Meeting in Streatley, Berkshire, UK Date: March 18-19 2003 ------------------------------------------------------------------- Dear experts of ITU-T Question H/16. A Rapporteur meeting for ITU-T Q.H/16 Experts will be held in Streatley, Berkshire, UK on March 18-19. The meeting is co-located with a meeting of Q.11/16 in order to get an opportunity to discuss joint matters in the Text over IP area. Details of the meeting can be found in the attached document. Best regards ------------------------------------------- Gunnar Hellström Omnitor AB Renathvägen 2 SE 121 37 Johanneshov SWEDEN +46 8 556 002 03 Mob: +46 708 204 288 www.omnitor.se Gunnar.Hellstrom(a)Omnitor.se -------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

FW: [HvS] H323 for Instant Message and Presence information suppo rt?
by Anatoli Levine 11 Feb '03

11 Feb '03

Interesting question - anyone wants to take a stub at it? Thanks, Anatoli -----Original Message----- From: Xiaotao Wu [mailto:xiaotaow@hotmail.com] Sent: Tuesday, February 11, 2003 11:41 AM To: Hvs(a)packetizer.com Subject: [HvS] H323 for Instant Message and Presence information support? In the article "H.323 versus SIP: A Comparison", seems a very important aspect of Internet Telephony prodcut (NOTE: not Telephony product) is missed -- how easily to integrate the H323 or SIP products with the other Internet services? Is there any effort in H323 on supporting Instant Message and presence information -- an important and convinient service over the Internet? Or we have to say that any H323 terminal has to have a separate messenger with it for IM and presence information, and any H323 proxy has to have a separate presence agent with it. For SIP, with the effort in SIMPLE working group, this can be easily solved, and it's easy to add a presence agent to a SIP proxy server. Thanks! _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail _______________________________________________ H.323-versus-SIP mailing list (hvs(a)packetizer.com) http://host4.imagelinkusa.net/mailman/listinfo/hvs_packetizer.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Re: Tunneling ISDN - semi-permanent scenario
by Peter Price 10 Feb '03

10 Feb '03

Frank, I've added the subject line that I forgot on the original posting. thanks for your reply but I still don't see how it all works. I'm either missing something fundamental or there really is a need for this to be covered in H.323. > I assume that you are referring to 9.3.2/ECMA-333 and 11.2/ECMA-333. > In 9.3.2/ECMA-333, it is stated that the Uq-channel number is used > as the session identifier and not the other way around, but this is > a only a trivial matter. You have the correct references, but I think a minor mis-interpretation. 9.3.2/ECMA-333 says the pair of logical channels shall be established and then it says that the session numnber shall be used as the Uq-channel number. In other words the session number is determined before the Uq-channel number. This means that when a QSIG SETUP is received by a gateway that is going to tunnel using the semi-permanent scenario an exchange of H.323 messages must occur to establish the RTP streams and hence the session number before it is possible to forward the QSIG SETUP with the correct Uq-channel number through the H323 tunnel. The gateway that received the SETUP can only establish the RTP stream in one direction. The RTP stream in the other direction must be initiated by the destination gateway. If that destination gateway is the H.323 slave how does it ensure that it achieves the same session number for the return channel (consider the possibility of multiple QSIG calls arriving at the gateway simultaneously). 11.2/ECMA-333 Note 2 is a reminder that each gateway/PINX must open its own tx channel. The only way I can think of to ensure both RTP streams have matching session numbers is for the original OLC to be initiated from the slave so that the master can assign the session number and immediately open a return channel with the same session number. So now the question becomes - what if the QSIG SETUP is originally received at the master gateway. What message does it send to the remote gateway? Hence my original questions. Or alternatively - what am I missing? Regards Peter > -----Original Message----- > From: frank.derks(a)philips.com [mailto:frank.derks@philips.com] > Sent: 10 February 2003 18:10 > To: Peter Price > Cc: ITU-SG16(a)echo.jf.INTEL.COM > Subject: Re: > > > Peter, > > I assume that you are referring to 9.3.2/ECMA-333 and 11.2/ECMA-333. > In 9.3.2/ECMA-333, it is stated that the Uq-channel number is used > as the session identifier and not the other way around, but this is > a only a trivial matter. > > Your concern seems to be the fact that the "H.245 slave" can > establish a QSIG call and therefore tunnel a QSIG SETUP message, but > it is not in control over the H.245 session identifier: H.245 states > that the session identifier can only be created by the master. > > When the slave opens its logical channel towards the master it will > specify a session identifier with the value 0. In the > OpenLogicalChannelAck message, the master will provide the session > identifier that is to be used for this session. If the master > overruled the Uq-channel number, it will return this number as the > session identifier. If the master accepted the Uq-channel number > that was proposed by the slave, it will return this number as the > session identifier. > > So, unless I don't quite understood you concerns, I do not see any > real problems. > > > Regards, > > Frank > > ----------------------------------------------------- > Frank Derks |Tel +31 35 6893238 | > APPlications |Fax +31 35 6891290 | > Philips Business Communications|P.O. Box 32 | > |1200 JD Hilversum | > |The Netherlands | > ----------------------------------------------------| > E-mail: mailto:frank.derks@philips.com | > WWW: http://www.sopho.philips.com | > ----------------------------------------------------- > > > > > > > > > > Peter Price <PeterP(a)VEGASTREAM.COM> > Sent by: > Mailing list for parties associated with ITU-T Study Group 16 > <ITU-SG16(a)echo.jf.INTEL.COM> > 2003-02-06 11:53 > Please respond to Peter Price > > > To: ITU-SG16(a)echo.jf.INTEL.COM > cc: (bcc: Frank Derks/HVS/BE/PHILIPS) > Subject: > Classification: > > > > All, > > ECMA 333 defines the mapping functions for tunneling QSIG over H.323 > networks. > It describes two scenarios, on-demand and semi-permanent. > In on-demand each new ISDN call is tunneled through a > separate H.323 call. > In semi-permanent multiple ISDN calls can be tunneled through > a single > H323 > call. > > 10.2.4/H323 V4 describes the mechanism for tunneling ISDN > protocols within > H323 calls. > However, this only ssems to cover the on-demand scenario. It does not > include any procedures for the establisment of the additional > RTP streams > that will be required to support multiple calls. > > Obviously the existing logical channel procedures can be used > to actually > open the channels - thats not the problem. > > ECMA 333 states that the Channel ID IE in the tunneled messages should > contain the H.323 session id of the logical channel to be > used for the > audio > stream. This isn't a problem for on-demand, there is only one voice > channel > and it uses the well-known session id 1. > > However there are multiple active channels whenn using > semi-permanent and > the problem is that the session ID is allocated by the H.323 > master - what > happens if you want to originate a call from the H.323 slave > - what do you > put in the tunneled ISDN SETUP message? > > Is this actually covered anywhere or does it need something in H.323? > Is there any work in progress within the standards community > to cover this > issue? > Any other commnents? > > Thanks > > > Peter Price > Principal Software Engineer > Vegastream, a division of Pace Micro Technology plc > > Enabling Digital. > Our Vision is to be the biggest supplier worldwide of digital gateway > technology. > > Tel: +44 1344 784914 > Fax: +44 1344 784901 > Berkshire Court, Western Road, Bracknell, Berkshire. RG12 1RE > www.pace.co.uk > www.vegastream.co.uk > > This E-mail and any attachments hereto are strictly confidential and > intended solely for the addressee. If you are not the > intended addressee > please notify the sender by return and delete the message. > You must not > disclose, forward or copy this E-mail or attachments to any > third party > without the prior consent of the sender. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)lists.intel.com > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

None
by frank.derks＠PHILIPS.COM 10 Feb '03

10 Feb '03

Peter, I assume that you are referring to 9.3.2/ECMA-333 and 11.2/ECMA-333. In 9.3.2/ECMA-333, it is stated that the Uq-channel number is used as the session identifier and not the other way around, but this is a only a trivial matter. Your concern seems to be the fact that the "H.245 slave" can establish a QSIG call and therefore tunnel a QSIG SETUP message, but it is not in control over the H.245 session identifier: H.245 states that the session identifier can only be created by the master. When the slave opens its logical channel towards the master it will specify a session identifier with the value 0. In the OpenLogicalChannelAck message, the master will provide the session identifier that is to be used for this session. If the master overruled the Uq-channel number, it will return this number as the session identifier. If the master accepted the Uq-channel number that was proposed by the slave, it will return this number as the session identifier. So, unless I don't quite understood you concerns, I do not see any real problems. Regards, Frank ----------------------------------------------------- Frank Derks |Tel +31 35 6893238 | APPlications |Fax +31 35 6891290 | Philips Business Communications|P.O. Box 32 | |1200 JD Hilversum | |The Netherlands | ----------------------------------------------------| E-mail: mailto:frank.derks@philips.com | WWW: http://www.sopho.philips.com | ----------------------------------------------------- Peter Price <PeterP(a)VEGASTREAM.COM> Sent by: Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)echo.jf.INTEL.COM> 2003-02-06 11:53 Please respond to Peter Price To: ITU-SG16(a)echo.jf.INTEL.COM cc: (bcc: Frank Derks/HVS/BE/PHILIPS) Subject: Classification: All, ECMA 333 defines the mapping functions for tunneling QSIG over H.323 networks. It describes two scenarios, on-demand and semi-permanent. In on-demand each new ISDN call is tunneled through a separate H.323 call. In semi-permanent multiple ISDN calls can be tunneled through a single H323 call. 10.2.4/H323 V4 describes the mechanism for tunneling ISDN protocols within H323 calls. However, this only ssems to cover the on-demand scenario. It does not include any procedures for the establisment of the additional RTP streams that will be required to support multiple calls. Obviously the existing logical channel procedures can be used to actually open the channels - thats not the problem. ECMA 333 states that the Channel ID IE in the tunneled messages should contain the H.323 session id of the logical channel to be used for the audio stream. This isn't a problem for on-demand, there is only one voice channel and it uses the well-known session id 1. However there are multiple active channels whenn using semi-permanent and the problem is that the session ID is allocated by the H.323 master - what happens if you want to originate a call from the H.323 slave - what do you put in the tunneled ISDN SETUP message? Is this actually covered anywhere or does it need something in H.323? Is there any work in progress within the standards community to cover this issue? Any other commnents? Thanks Peter Price Principal Software Engineer Vegastream, a division of Pace Micro Technology plc Enabling Digital. Our Vision is to be the biggest supplier worldwide of digital gateway technology. Tel: +44 1344 784914 Fax: +44 1344 784901 Berkshire Court, Western Road, Bracknell, Berkshire. RG12 1RE www.pace.co.uk www.vegastream.co.uk This E-mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message. You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Re: Errors in TD-02
by OKUBO Sakae 10 Feb '03

10 Feb '03

Dear Paul, Thank you for your advice. An updated version is issued as: http://standard.pictel.com/ftp/avc-site/0302_San/TD-02a.xls At 23:50 -0500 03/02/09, Paul E. Jones wrote: >Mr. Okubo, > >In TD-02, I noted a few errors: > >AVD-2268 is marked as being to "I, 2", but the document is actually >to "I, 3". Even so, I have put this on the Q.2 agenda, it seems >relevant, considering the H.460.4 work (referenced in that liaison). > >AVD-2299 should be addressed only to Q.2. > >AVD-2308 should be to 2 and 3. > >AVD-2318 is addressed to "3, I". I think you are saying "G, I." >AVD-2321 and AVD-2322 are reversed. I will assume that the >documents will remain the same and that the TD-02 will be updated to >reflect the real document titles. Yes, I have swapped the titles in TD-02a. -- Best regards, OKUBO Sakae e-mail: okubo(a)giti.waseda.ac.jp ******************************************************************* YRP Office Global Information and Telecommunication Institute (GITI) 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 GITI Headquarter 29-7 Waseda University Bldg. Tel: +81 3 5286 3831 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo Fax: +81 3 5286 3832 169-0051 Japan ******************************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

San Jose meeting information
by OKUBO Sakae 08 Feb '03

08 Feb '03

Dear San Jose meeting participants, This is information from the meeting host. >From: "Paul E. Jones" <paulej(a)packetizer.com> >To: "Sakae Okubo" <okubo(a)giti.waseda.ac.jp> >Subject: Updated attendee list >Date: Wed, 5 Feb 2003 23:52:51 -0500 > >Mr. Okubo, > >We have an additional attendee registered, for a total of 29 now. I >would expect that not all Cisco folks will be present at all times. >The room holds about 40 people, so I would expect that we should >have plenty of work space. > >I have requested a projector for the laptop and microphones for the >rapporteurs and floor stand or mobile microphones.. whatever they >have available. > >I did not make arrangement for catering, but there is a cafeteria in >that building, so getting stacks and drinks is easy to do. > >We will have power at each seat and Ethernet connections at each >seat. My understanding is that hubs will be placed throughout the >room. Cisco employees can access the wireless network, but no >wireless access is available for non-Cisco employees. Further, >Cisco policy does not allow non-Cisco IT managed wireless devices to >be installed by employees, so I can't install an access point myself. > >I actually get there late Monday night, so I can only hope things >are in good order when I arrive. I will follow-up with the folks in >SJ to make sure things are going OK. > >[...] > >Paul -- Best regards, OKUBO Sakae e-mail: okubo(a)giti.waseda.ac.jp ******************************************************************* YRP Office Global Information and Telecommunication Institute (GITI) 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 GITI Headquarter 29-7 Waseda University Bldg. Tel: +81 3 5286 3831 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo Fax: +81 3 5286 3832 169-0051 Japan ******************************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

None
by Peter Price 06 Feb '03

06 Feb '03

All, ECMA 333 defines the mapping functions for tunneling QSIG over H.323 networks. It describes two scenarios, on-demand and semi-permanent. In on-demand each new ISDN call is tunneled through a separate H.323 call. In semi-permanent multiple ISDN calls can be tunneled through a single H323 call. 10.2.4/H323 V4 describes the mechanism for tunneling ISDN protocols within H323 calls. However, this only ssems to cover the on-demand scenario. It does not include any procedures for the establisment of the additional RTP streams that will be required to support multiple calls. Obviously the existing logical channel procedures can be used to actually open the channels - thats not the problem. ECMA 333 states that the Channel ID IE in the tunneled messages should contain the H.323 session id of the logical channel to be used for the audio stream. This isn't a problem for on-demand, there is only one voice channel and it uses the well-known session id 1. However there are multiple active channels whenn using semi-permanent and the problem is that the session ID is allocated by the H.323 master - what happens if you want to originate a call from the H.323 slave - what do you put in the tunneled ISDN SETUP message? Is this actually covered anywhere or does it need something in H.323? Is there any work in progress within the standards community to cover this issue? Any other commnents? Thanks Peter Price Principal Software Engineer Vegastream, a division of Pace Micro Technology plc Enabling Digital. Our Vision is to be the biggest supplier worldwide of digital gateway technology. Tel: +44 1344 784914 Fax: +44 1344 784901 Berkshire Court, Western Road, Bracknell, Berkshire. RG12 1RE www.pace.co.uk www.vegastream.co.uk This E-mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message. You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

San Jose meeting documents
by OKUBO Sakae 05 Feb '03

05 Feb '03

Dear SG16 experts, This reflector itu-sg16(a)lists.intel.com has resumed its operation thanks to the Intel efforts. Please note that the San Jose meeting documents are available at: http://standard.pictel.com/ftp/avc-site/0302_San/ where the current list of documents is contained as: http://standard.pictel.com/ftp/avc-site/0302_San/TD-02.xls If you are using a ftp tool, URL is ftp://standard.pictel.com/avc-site/0302_San/ -- Best regards, OKUBO Sakae e-mail: okubo(a)giti.waseda.ac.jp ******************************************************************* YRP Office Global Information and Telecommunication Institute (GITI) 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 GITI Headquarter 29-7 Waseda University Bldg. Tel: +81 3 5286 3831 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo Fax: +81 3 5286 3832 169-0051 Japan ******************************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Re: document in incoming
by Euchner Martin ICN M SR 3 04 Feb '03

04 Feb '03

I've uploaded the following contributions to the Incoming directory AVD-2284 Editor H.235 Draft H.235 VERSION 3 AVD-2285 Siemens AG H.235 Annex G: H.323-SIP Security Interworking considerations With kind regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Rapporteur Q.G/SG16 | Martin Euchner Phone: +49 89 722 55790 | Siemens AG.....................Fax : +49 89 722 62366 | ICN M SR 3 mailto:Martin.Euchner@siemens.com | mailto:martin.euchner@ties.itu.int | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/cs27/topics/security/ | D-81359 Muenchen Internet: http://www.siemens.de/ | __________________ | Germany ----------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

testing - please disregard
by OKUBO Sakae 01 Feb '03

01 Feb '03

This is a test message to check if the reflector is working - Sakae OKUBO ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0