- sg16-avd - lists.packetizer.com

Comments on H.248.1 Editing Meeting Week 5
by Yangbo Lin 21 Jun '05

21 Jun '05

Please refer to the attached document for my comments to the H.248.1 Editing Meeting Week 5. Thank you!

1 0

Re: New draft F.avod
by OKUBO Sakae 21 Jun '05

21 Jun '05

Dera Ms. Nie, At 11:01 +0800 05/06/21, Niexiuying wrote: >Attached is new draft of F.avod modified based on your comments. This has been placed at the avc-site for the review of interested parties: <http://ftp3.itu.int/av-arch/avc-site/2005-2008/0507_Gen/Working_Docs/FAVO Dv2_050621.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

H.248.1 V3 Week 5 - RE: Statistics:nt/os, nt/or;
by Albrecht.Schwarz＠alcatel.de 21 Jun '05

21 Jun '05

For information only: I've mentioned in our "Week 5" comments that ALCATEL will submitt a contribution to next SG16 on "H.248.1 Annex E.11 Network Package - Recommendations for Statistics Usage". An initial proposal (file Alcatelx1 T05-SG16-050726-D H.248.1v3 nt Package_Ed01.doc , Alcatelx1 T05-SG16-050726-D H.248.1v3 nt Package_Ed01.pdf) is ready and uploaded in /av-arch/avc-site/Incoming. Prof. Okuba, could you please move the files in directory http://ftp3.itu.int/av-arch/avc-site/2005-2008/0507_Gen/Working_Docs/ Thoughts, comments? Regards Albrecht PS Walter, I did cover your mentioned relation in clause "E.11.5.3.2.2.1". But I didn't consider the correlation of statistics from different Terminations of the same Context so far in the proposal. Perhaps I'll add a subsection on that item ("which is questionable in general for statistics without any time information, like start/end time, or time stamps per probe etc; ... and I'm not aware of the existence of such kind of H.248 statistics so far ..") "Binz, Walter" <Walter.Binz@key To: Albrecht SCHWARZ/DE/ALCATEL@ALCATEL, <megaco(a)ietf.org> mile.com> cc: Sent by: Subject: RE: Statistics:nt/os, nt/or; Re: [Megaco] Call Flow Example in megaco-bounces@i H.248.1Corrigendum1 (03/2004) etf.org 23.05.2005 15:37 Albrecht et al., my understanding is that nt/or & nt/os for a 64kbps physical termination (such as in the H.248.1 call flow example) should be about 8 times nt/dur (8 PCM samples per ms), independent of the chosen RTP/AVP (I assume that codec and silence suppression functions are part of the ephemeral termination). Therefore in the H.248.1 Call Flow Example below, nt/or for the ephemeral termination should be about 10 times lower than nt/os for the physical termination (and NOT the same), as a G.723.1 codec was used for the call. I would appreciate if some guidance text can be added to the nt package. Regards, Walter >-----Original Message----- >From: megaco-bounces(a)ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of >Albrecht.Schwarz(a)alcatel.de >Sent: Friday, May 20, 2005 9:12 AM >To: megaco(a)ietf.org >Subject: Statistics:nt/os, nt/or; Re: [Megaco] Call Flow Example in >H.248.1Corrigendum1 (03/2004) > > >Hello Alberto et al., > >I think the question was not the *unit* of the time-based statistic nt/dur >versus the unit-less statistics nt/or & nt/os. >Looking from a high-level perspective on the traffic volume related >statistics nt/or & nt/os on circuit- and packet-side on the H.248 Context >(MG) in this example, it looks like that the conservation law is invalid >("traffic volume increase from C2P direction, whereas the volume is >constant in the opposite direction P2C":-) >Of course, whether the conservation law is applicable at all depends on >codec type, silence suppression mode, RTP FEC mode, and other >configurations. > >The crucial point is rather, which protocol layers have to be considered >for these volume-based statistics? This basic question becomes more open >due to the "generic scope" of these statistics: they are defined for ALL >type of H.248 Terminations (physical T.: ALN, TDM; ephemeral T.: RTP, UDP, >IP, AAL2, AAL1, ATM, etc etc). > >This issue was frequently discussed in the past, also in last SG16 meeting. > >Just the note therefore that I'm currently working on a contribution on >that subject for next SG16. >The intent aren't any technical changes to the nt Package, I rather do see >a need to provide some guidance on statistics usage. Such recommendations >may be covered in the procedural section (clause § E.11.5 >"Procedures"/H.248.1). > >regards >Albrecht > > > > > > Christian Groves > <christian.groves@er To: Puglisi Alberto ><Alberto.Puglisi(a)italtel.it> > icsson.com> cc: >megaco@ietf..org > Sent by: Subject: Re: [Megaco] >Call Flow Example in H.248.1 Corrigendum1 (03/2004) > megaco-bounces@ietf. > org > > > 12.05.2005 05:47 > > > > > >Hello Puglisi, > >I'm not sure if I understand your question correctly. nt/dur shouldn't have >the >same value as nt/os, nt/or because Duration is in Milliseconds and Octets >Sent >and Received are in numbers of Octets. > >Regards, Christian > >Puglisi Alberto wrote: > >> 22) The MGC now sends both MGs a Subtract to take down the call. Only >> the subtracts to MG2 are shown here. Each termination has its own set of >> statistics that it gathers. An MGC may not need to request both to be >> returned. A5555 is a physical termination, and A5556 is an RTP >> termination. >> >>>From MGC to MG2: >> >> MEGACO/1 2 [123.123.123.4]:55555 >> Transaction = 50009 { >> Context = 5000 { >> Subtract = A5555 {Audit{Statistics}}, >> Subtract = A5556 {Audit{Statistics}} >> } >> } >> >>>From MG2 to MGC: >> >> MEGACO/1 2 [125.125.125.111]:55555 >> Reply = 50009 { >> Context = 5000 { >> Subtract = A5555 { >> Statistics { >> nt/os=45123, ; Octets Sent >> nt/or=45123, ; Octets Received >> nt/dur=40000 ; in milliseconds >> } >> }, >> Subtract = A5556 { >> Statistics { >> rtp/ps=1245, ; packets sent >> nt/os=62345, ; octets sent >> rtp/pr=780, ; packets received >> nt/or=45123, ; octets received >> rtp/pl=10, ; % packets lost >> rtp/jit=27, >> rtp/delay=48, ; average latency >> nt/dur=38000 ; in millisec >> } >> } >> } >> } >> >> I understand that nt/os, nt/or, and nt/dur should have the same values, >> am I correct ? >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Megaco mailing list >> Megaco(a)ietf.org >> https://www1.ietf.org/mailman/listinfo/megaco > >_______________________________________________ >Megaco mailing list >Megaco(a)ietf.org >https://www1.ietf.org/mailman/listinfo/megaco > > > > > >_______________________________________________ >Megaco mailing list >Megaco(a)ietf.org >https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco(a)ietf.org https://www1.ietf.org/mailman/listinfo/megaco

1 0

[Megaco] H.248.1 V3 Week 5 - RE: Statistics:nt/os, nt/or;
by Albrecht.Schwarz＠alcatel.de 21 Jun '05

21 Jun '05

For information only: I've mentioned in our "Week 5" comments that ALCATEL will submitt a contribution to next SG16 on "H.248.1 Annex E.11 Network Package - Recommendations for Statistics Usage". An initial proposal (file Alcatelx1 T05-SG16-050726-D H.248.1v3 nt Package_Ed01.doc , Alcatelx1 T05-SG16-050726-D H.248.1v3 nt Package_Ed01.pdf) is ready and uploaded in /av-arch/avc-site/Incoming. Prof. Okuba, could you please move the files in directory http://ftp3.itu.int/av-arch/avc-site/2005-2008/0507_Gen/Working_Docs/ Thoughts, comments? Regards Albrecht PS Walter, I did cover your mentioned relation in clause "E.11.5.3.2.2.1". But I didn't consider the correlation of statistics from different Terminations of the same Context so far in the proposal. Perhaps I'll add a subsection on that item ("which is questionable in general for statistics without any time information, like start/end time, or time stamps per probe etc; ... and I'm not aware of the existence of such kind of H.248 statistics so far ..") "Binz, Walter" <Walter.Binz@key To: Albrecht SCHWARZ/DE/ALCATEL@ALCATEL, <megaco(a)ietf.org> mile.com> cc: Sent by: Subject: RE: Statistics:nt/os, nt/or; Re: [Megaco] Call Flow Example in megaco-bounces@i H.248.1Corrigendum1 (03/2004) etf.org 23.05.2005 15:37 Albrecht et al., my understanding is that nt/or & nt/os for a 64kbps physical termination (such as in the H.248.1 call flow example) should be about 8 times nt/dur (8 PCM samples per ms), independent of the chosen RTP/AVP (I assume that codec and silence suppression functions are part of the ephemeral termination). Therefore in the H.248.1 Call Flow Example below, nt/or for the ephemeral termination should be about 10 times lower than nt/os for the physical termination (and NOT the same), as a G.723.1 codec was used for the call. I would appreciate if some guidance text can be added to the nt package. Regards, Walter >-----Original Message----- >From: megaco-bounces(a)ietf.org [mailto:megaco-bounces@ietf.org] On Behalf Of >Albrecht.Schwarz(a)alcatel.de >Sent: Friday, May 20, 2005 9:12 AM >To: megaco(a)ietf.org >Subject: Statistics:nt/os, nt/or; Re: [Megaco] Call Flow Example in >H.248.1Corrigendum1 (03/2004) > > >Hello Alberto et al., > >I think the question was not the *unit* of the time-based statistic nt/dur >versus the unit-less statistics nt/or & nt/os. >Looking from a high-level perspective on the traffic volume related >statistics nt/or & nt/os on circuit- and packet-side on the H.248 Context >(MG) in this example, it looks like that the conservation law is invalid >("traffic volume increase from C2P direction, whereas the volume is >constant in the opposite direction P2C":-) >Of course, whether the conservation law is applicable at all depends on >codec type, silence suppression mode, RTP FEC mode, and other >configurations. > >The crucial point is rather, which protocol layers have to be considered >for these volume-based statistics? This basic question becomes more open >due to the "generic scope" of these statistics: they are defined for ALL >type of H.248 Terminations (physical T.: ALN, TDM; ephemeral T.: RTP, UDP, >IP, AAL2, AAL1, ATM, etc etc). > >This issue was frequently discussed in the past, also in last SG16 meeting. > >Just the note therefore that I'm currently working on a contribution on >that subject for next SG16. >The intent aren't any technical changes to the nt Package, I rather do see >a need to provide some guidance on statistics usage. Such recommendations >may be covered in the procedural section (clause § E.11.5 >"Procedures"/H.248.1). > >regards >Albrecht > > > > > > Christian Groves > <christian.groves@er To: Puglisi Alberto ><Alberto.Puglisi(a)italtel.it> > icsson.com> cc: >megaco@ietf..org > Sent by: Subject: Re: [Megaco] >Call Flow Example in H.248.1 Corrigendum1 (03/2004) > megaco-bounces@ietf. > org > > > 12.05.2005 05:47 > > > > > >Hello Puglisi, > >I'm not sure if I understand your question correctly. nt/dur shouldn't have >the >same value as nt/os, nt/or because Duration is in Milliseconds and Octets >Sent >and Received are in numbers of Octets. > >Regards, Christian > >Puglisi Alberto wrote: > >> 22) The MGC now sends both MGs a Subtract to take down the call. Only >> the subtracts to MG2 are shown here. Each termination has its own set of >> statistics that it gathers. An MGC may not need to request both to be >> returned. A5555 is a physical termination, and A5556 is an RTP >> termination. >> >>>From MGC to MG2: >> >> MEGACO/1 2 [123.123.123.4]:55555 >> Transaction = 50009 { >> Context = 5000 { >> Subtract = A5555 {Audit{Statistics}}, >> Subtract = A5556 {Audit{Statistics}} >> } >> } >> >>>From MG2 to MGC: >> >> MEGACO/1 2 [125.125.125.111]:55555 >> Reply = 50009 { >> Context = 5000 { >> Subtract = A5555 { >> Statistics { >> nt/os=45123, ; Octets Sent >> nt/or=45123, ; Octets Received >> nt/dur=40000 ; in milliseconds >> } >> }, >> Subtract = A5556 { >> Statistics { >> rtp/ps=1245, ; packets sent >> nt/os=62345, ; octets sent >> rtp/pr=780, ; packets received >> nt/or=45123, ; octets received >> rtp/pl=10, ; % packets lost >> rtp/jit=27, >> rtp/delay=48, ; average latency >> nt/dur=38000 ; in millisec >> } >> } >> } >> } >> >> I understand that nt/os, nt/or, and nt/dur should have the same values, >> am I correct ? >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Megaco mailing list >> Megaco(a)ietf.org >> https://www1.ietf.org/mailman/listinfo/megaco > >_______________________________________________ >Megaco mailing list >Megaco(a)ietf.org >https://www1.ietf.org/mailman/listinfo/megaco > > > > > >_______________________________________________ >Megaco mailing list >Megaco(a)ietf.org >https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco(a)ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ Megaco mailing list Megaco(a)ietf.org https://www1.ietf.org/mailman/listinfo/megaco

1 0

[SUSPECT ATTACHMENT] 8. H.248.1: Value of Statistics at a Termination Level; Re: H.248.1 Editing
by Albrecht.Schwarz＠alcatel.de 21 Jun '05

21 Jun '05

Hi Christian et al., I concur with Christian's proposals. I know I'm behind week 4, but when looking at the nt statistics, I'm again not sure whether the additions for item 8 are sufficient. Current proposal: "The value of a Statistic at a Termination level is the sum of the values as if it had been placed on all the streams in the termination." Discussion: The statistic on Termination level is superior concerning the Stream level statistics. Thus, there needs to be a "superior function" for the Termination statistic. Crucial: such a function is "statistic type" dependent. "sum" is an example for a "superior function", "average" another one (e.g., applicable for some time-based statistics like "delay" or "delay variation"). Generally there are two possibilities here: (1) Statistic was initially defined for "Streams", afterwards a meaningful "superior statistic" for "Terminations" is demanded. or (2) Statistic was initially defined for "Terminations", afterwards an adaption for "Streams" is demanded. The 2nd case seems to be straighforward, the first case is our issue here. New proposal: "The value of a Statistic at a Termination level is the result of a meaningful superior function (like for instance sum or average)of the values as if it had been placed on all the streams in the termination. Such a superior function is dependent of the particular statistic type." Comments? Regards Albrecht Christian Groves <christian.groves@ER To: SG16 <itu-sg16(a)external.cisco.com> ICSSON.COM> cc: Kevin Boyle <kboyle(a)nortel.com> Subject: [SUSPECT ATTACHMENT] H.248.1 Editing Meeting Week 4 comments 17.06.2005 06:05 Hello Kevin, all, Please find attached my comments for week 4 of the editing meeting. Rather than a marked up document its in the form of an IG update. I have attempted to capture items that have been discussed on the Megaco list or have been mentioned in Tispan. I'm not sure whether all the items fall into the realm of editorial only but none of the items add new functionality. I intend on presenting this DC (with any new raised issues) to the July meeting. Of interest to the Week 4 ABNF are items 1,2 and 3. Comments? Regards, Christian ------------------------------------------------------------------------- CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY ------------------------------------------------------------------------- WARNING: This message has an attachment that could contain executable code. Please review the attachment carefully to ensure you do not inadvertently execute embedded programs that could contain viruses. We suggest you review the following URL to stay up-to-date with current virus threats: http://wwwin.cisco.com/support/library/mcafee/virus_info.shtml Please be aware many viruses attempt to look like legitimate email or notifications from anti-virus systems. We will clearly mark a seperation between our notifications and the original email as follows: "CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY" For further reference information about viruses and email antivirus efforts within Cisco, please visit: http://wwwin.cisco.com/it/ems/services/antiviral If your concern isn't addressed by the information in this notification or the above web page, you may open a support request: http://wwwin.cisco.com/support/ Select "Messaging", "Email-Related", "Mail Routing" Please include in the text of your case the following information: * Full headers of the message. Documentation on displaying the full headers is available at this URL: http://wwwin.cisco.com/support/library/faqs/solution002471.html * This unique quarantine identifier: j5H45lQ3023840 If the matter is urgent, you may follow up by calling one of the below referenced numbers. Please make every effort to provide the above requested information via the support web tool prior to calling as it will greatly aid the resolution of your issue. Americas: 1 408 526 8888 Asiapac +61 2 8446 8888 EMEA +31 20 485 4888 Japan +81 3 5549 6888 US (Toll Free) 1| 800| 888| 8187| (ext.68888) Thank you for your cooperation, Enterprise Messaging Services Cisco Systems, Inc (See attached file: DC-xxx_H_248_1v3_Corrections_Clarifications.zip) ------------------------------------------------------------------------- CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY ------------------------------------------------------------------------- WARNING: This message has an attachment that could contain executable code. Please review the attachment carefully to ensure you do not inadvertently execute embedded programs that could contain viruses. We suggest you review the following URL to stay up-to-date with current virus threats: http://wwwin.cisco.com/support/library/mcafee/virus_info.shtml Please be aware many viruses attempt to look like legitimate email or notifications from anti-virus systems. We will clearly mark a seperation between our notifications and the original email as follows: "CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY" For further reference information about viruses and email antivirus efforts within Cisco, please visit: http://wwwin.cisco.com/it/ems/services/antiviral If your concern isn't addressed by the information in this notification or the above web page, you may open a support request: http://wwwin.cisco.com/support/ Select "Messaging", "Email-Related", "Mail Routing" Please include in the text of your case the following information: * Full headers of the message. Documentation on displaying the full headers is available at this URL: http://wwwin.cisco.com/support/library/faqs/solution002471.html * This unique quarantine identifier: j5L69U92027213 If the matter is urgent, you may follow up by calling one of the below referenced numbers. Please make every effort to provide the above requested information via the support web tool prior to calling as it will greatly aid the resolution of your issue. Americas: 1 408 526 8888 Asiapac +61 2 8446 8888 EMEA +31 20 485 4888 Japan +81 3 5549 6888 US (Toll Free) 1| 800| 888| 8187| (ext.68888) Thank you for your cooperation, Enterprise Messaging Services Cisco Systems, Inc

1 0

Re: Comments on Draft F-series documents
by OKUBO Sakae 20 Jun '05

20 Jun '05

Dear Ms. Sun and all, At 11:16 +0800 05/06/20, sunmingjun wrote: >attached is the second draft F.MMCIP, thank you. This has been placed at the avc-site for your review: <http://ftp3.itu.int/av-arch/avc-site/2005-2008/0507_Gen/Working_Docs/FMMC IP_050620.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

[SUSPECT ATTACHMENT] H.248.1 Editing Comments Week 5
by Christian Groves 20 Jun '05

20 Jun '05

Hello Kevin, all, Please find attached my week 5 comments marked up in the attached document. I have used Albrecht's comments as a base. I also have an additional IG comment on the ABNF (week 4). Comments? Regards, Christian ------------------------------------------------------------------------- CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY ------------------------------------------------------------------------- WARNING: This message has an attachment that could contain executable code. Please review the attachment carefully to ensure you do not inadvertently execute embedded programs that could contain viruses. We suggest you review the following URL to stay up-to-date with current virus threats: http://wwwin.cisco.com/support/library/mcafee/virus_info.shtml Please be aware many viruses attempt to look like legitimate email or notifications from anti-virus systems. We will clearly mark a seperation between our notifications and the original email as follows: "CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY" For further reference information about viruses and email antivirus efforts within Cisco, please visit: http://wwwin.cisco.com/it/ems/services/antiviral If your concern isn't addressed by the information in this notification or the above web page, you may open a support request: http://wwwin.cisco.com/support/ Select "Messaging", "Email-Related", "Mail Routing" Please include in the text of your case the following information: * Full headers of the message. Documentation on displaying the full headers is available at this URL: http://wwwin.cisco.com/support/library/faqs/solution002471.html * This unique quarantine identifier: j5K8KgDg015974 If the matter is urgent, you may follow up by calling one of the below referenced numbers. Please make every effort to provide the above requested information via the support web tool prior to calling as it will greatly aid the resolution of your issue. Americas: 1 408 526 8888 Asiapac +61 2 8446 8888 EMEA +31 20 485 4888 Japan +81 3 5549 6888 US (Toll Free) 1| 800| 888| 8187| (ext.68888) Thank you for your cooperation, Enterprise Messaging Services Cisco Systems, Inc

1 0

Re: The question about extension of an H.248 package.
by Christian Groves 19 Jun '05

19 Jun '05

Hello Sasha, Please see my response below. Regards, Christian Sasha Ruditsky wrote: > Hi Christian > > Thanks, again. > > It looks like I will have some more question about H.248.19. > > Meanwhile. > > In H.248.19 defines vwp/wxp and vwp/wyp as being from 0 to 10000. > > The description text states: > This property is set by the MC to represent the horizontal "X" position > of the bottom left hand corner of a window. > 0 represents the left hand side of a screen, > 10000 the right hand side of a screen. > > So it makes the size of the screen equal to 10001 units. > > In the same time vwp/wh and vwp/wl are also defined to be 0 to 10000. > > I think it means that it is impossible to create window which fills the > entire screen. > (Screen is 10001 units and the biggest window is only 10000). [CHG] Given a display 10000 by 10000 pixels the way I saw the property working was that 0,0 represented the bottom left hand corner of the display/window. A window position 0,0 size 1,1 would draw a pixel 1,1 starting at this point. A window placed at 10000,10000 couldn't actually have a positive size as it would exceed the display. > > Do I misunderstand the description text? > Shouldn't the vwp/wxp and vwp/wyp be defined in range from 0 to 9999? > Or probably the range is OK, however the 10000 is outside of screen? [CHG] So technically 10000 is outside the meaningful range for displaying anything. > > What do you think? > ==================================================================== > > Another small editorial issue is that in H.248.19 on Figure 8 the text > references the vwpcvsp/ovs, where I believe it should be cvsp/ovs. [CHG] Is the editorial issue in Figure 8 itself? It should be cvsp/ovs but I can't see where the error occurs. > > > > Thanks, > Sasha > > > > > -----Original Message----- > From: Christian Groves [mailto:christian.groves@ericsson.com] > Sent: Thursday, June 16, 2005 8:55 PM > To: Sasha Ruditsky > Cc: itu-sg16(a)external.cisco.com > Subject: Re: The question about extension of an H.248 package. > > Hello Sasha, > > In thus case the text encoding would use H.248.15 Gateway control > protocol: SDP > H.248 package attribute. > > Regards, Christian > > Sasha Ruditsky wrote: > > >>Hi Christian >> >>Thanks. >> >>One more question. >>In H.248.19 most of the properties inside packages are specified to be > > >>"Defined in: Local/Remote". >>>From what I know about H.248 -- local/remote descriptors contain SDP >>messages. >> >>How do the H.248.19 properties coexist with SDP? >>Is it only possible in binary encoding mode? >> >>Thanks, >>Sasha >> >>-----Original Message----- >>From: Christian Groves [mailto:christian.groves@ERICSSON.COM] >>Sent: Thursday, June 16, 2005 12:35 AM >>To: Sasha Ruditsky >>Cc: itu-sg16(a)external.cisco.com >>Subject: Re: The question about extension of an H.248 package. >> >>Hello Sasha, >> >>There is no hard rule of what to propose. It really depends on the >>type of information you want added. >> >>I think the only time the package extension should be used is if the >>added properties/signals/events provide a set of functions of their >>own right. e.g. >>would it makes sense that these properties could be a package by >>themselves but need another package to operate. For example: The tone >>gen package. The DTMF was added as a extension package as DTMF >>generation is its own subset functionality but is related to the >>generation of tones. >> >>Regards, Christian >> >>Sasha Ruditsky wrote: >> >> >> >>>Hi >>> >>>I'm working on a proposal for July meeting to add some new properties >>>to one of the H.248.19 packages. >>>>From H.248 document it appears that there are defined (at least) two >>>ways of doing this. >>> >>>* Creating a new version of an existing package >>>* Creating a new package that extends the existing one. >>> >>> >>>Can somebody please comment on the factors helping to determine which >>>of these two mechanisms should be uses? >>> >>>Thanks, >>>Sasha >>>. >>> >> >> > >

1 0

Working documents
by OKUBO Sakae 18 Jun '05

18 Jun '05

Dear SG16 experts, Your review is requested. At 15:47 +0800 05/06/13, Niexiuying wrote: >I appreciate that Mr. OKUBO Sakae have given us the comments to >draft F.dl and F.avod. I modified the draft F.dl and F.avod based on >his comments. Attached is the new version of draft F.dl. The reply >to Mr. OKUBO Sakaea's comments is as follows: You comments to the >reversion of F.dl and comments to the reply are solicited. I will >send the new version of Draft F.avod soon. This updated draft F.dl has been placed at the avc-site: <http://ftp3.itu.int/av-arch/avc-site/2005-2008/0507_Gen/Working_Docs/Fdl_ 050613.zip> At 07:02 -0400 05/06/13, Giles Chamberlin wrote: >Attached document is based on AVD-2718 from the Biel meeting. >Modifications are to take into account the comments from the meeting >and to improve clarity. In particular I hope I’ve succeeded in not >breaking fast connect. > >As you’ll see form the markup, there’s more to do, but hopefully >that’s mostly editorial. This draft has been placed at the avc-site: <http://ftp3.itu.int/av-arch/avc-site/2005-2008/0507_Gen/Working_Docs/h460 .fantas_v1.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: The question about extension of an H.248 package.
by Sasha Ruditsky 17 Jun '05

17 Jun '05

Hi Christian Thanks, again. It looks like I will have some more question about H.248.19. Meanwhile. In H.248.19 defines vwp/wxp and vwp/wyp as being from 0 to 10000. The description text states: This property is set by the MC to represent the horizontal "X" position of the bottom left hand corner of a window. 0 represents the left hand side of a screen, 10000 the right hand side of a screen. So it makes the size of the screen equal to 10001 units. In the same time vwp/wh and vwp/wl are also defined to be 0 to 10000. I think it means that it is impossible to create window which fills the entire screen. (Screen is 10001 units and the biggest window is only 10000). Do I misunderstand the description text? Shouldn't the vwp/wxp and vwp/wyp be defined in range from 0 to 9999? Or probably the range is OK, however the 10000 is outside of screen? What do you think? ==================================================================== Another small editorial issue is that in H.248.19 on Figure 8 the text references the vwpcvsp/ovs, where I believe it should be cvsp/ovs. Thanks, Sasha -----Original Message----- From: Christian Groves [mailto:christian.groves@ericsson.com] Sent: Thursday, June 16, 2005 8:55 PM To: Sasha Ruditsky Cc: itu-sg16(a)external.cisco.com Subject: Re: The question about extension of an H.248 package. Hello Sasha, In thus case the text encoding would use H.248.15 Gateway control protocol: SDP H.248 package attribute. Regards, Christian Sasha Ruditsky wrote: > Hi Christian > > Thanks. > > One more question. > In H.248.19 most of the properties inside packages are specified to be > "Defined in: Local/Remote". >>From what I know about H.248 -- local/remote descriptors contain SDP > messages. > > How do the H.248.19 properties coexist with SDP? > Is it only possible in binary encoding mode? > > Thanks, > Sasha > > -----Original Message----- > From: Christian Groves [mailto:christian.groves@ERICSSON.COM] > Sent: Thursday, June 16, 2005 12:35 AM > To: Sasha Ruditsky > Cc: itu-sg16(a)external.cisco.com > Subject: Re: The question about extension of an H.248 package. > > Hello Sasha, > > There is no hard rule of what to propose. It really depends on the > type of information you want added. > > I think the only time the package extension should be used is if the > added properties/signals/events provide a set of functions of their > own right. e.g. > would it makes sense that these properties could be a package by > themselves but need another package to operate. For example: The tone > gen package. The DTMF was added as a extension package as DTMF > generation is its own subset functionality but is related to the > generation of tones. > > Regards, Christian > > Sasha Ruditsky wrote: > > >>Hi >> >>I'm working on a proposal for July meeting to add some new properties >>to one of the H.248.19 packages. >>>From H.248 document it appears that there are defined (at least) two >>ways of doing this. >> >>* Creating a new version of an existing package >>* Creating a new package that extends the existing one. >> >> >>Can somebody please comment on the factors helping to determine which >>of these two mechanisms should be uses? >> >>Thanks, >>Sasha >>. >> > >

1 0

[SUSPECT ATTACHMENT] H.248.1 Editing Meeting Week 4 comments
by Christian Groves 17 Jun '05

17 Jun '05

Hello Kevin, all, Please find attached my comments for week 4 of the editing meeting. Rather than a marked up document its in the form of an IG update. I have attempted to capture items that have been discussed on the Megaco list or have been mentioned in Tispan. I'm not sure whether all the items fall into the realm of editorial only but none of the items add new functionality. I intend on presenting this DC (with any new raised issues) to the July meeting. Of interest to the Week 4 ABNF are items 1,2 and 3. Comments? Regards, Christian ------------------------------------------------------------------------- CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY ------------------------------------------------------------------------- WARNING: This message has an attachment that could contain executable code. Please review the attachment carefully to ensure you do not inadvertently execute embedded programs that could contain viruses. We suggest you review the following URL to stay up-to-date with current virus threats: http://wwwin.cisco.com/support/library/mcafee/virus_info.shtml Please be aware many viruses attempt to look like legitimate email or notifications from anti-virus systems. We will clearly mark a seperation between our notifications and the original email as follows: "CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY" For further reference information about viruses and email antivirus efforts within Cisco, please visit: http://wwwin.cisco.com/it/ems/services/antiviral If your concern isn't addressed by the information in this notification or the above web page, you may open a support request: http://wwwin.cisco.com/support/ Select "Messaging", "Email-Related", "Mail Routing" Please include in the text of your case the following information: * Full headers of the message. Documentation on displaying the full headers is available at this URL: http://wwwin.cisco.com/support/library/faqs/solution002471.html * This unique quarantine identifier: j5H45lQ3023840 If the matter is urgent, you may follow up by calling one of the below referenced numbers. Please make every effort to provide the above requested information via the support web tool prior to calling as it will greatly aid the resolution of your issue. Americas: 1 408 526 8888 Asiapac +61 2 8446 8888 EMEA +31 20 485 4888 Japan +81 3 5549 6888 US (Toll Free) 1| 800| 888| 8187| (ext.68888) Thank you for your cooperation, Enterprise Messaging Services Cisco Systems, Inc

1 0

Re: The question about extension of an H.248 package.
by Christian Groves 16 Jun '05

16 Jun '05

Hello Sasha, In thus case the text encoding would use H.248.15 Gateway control protocol: SDP H.248 package attribute. Regards, Christian Sasha Ruditsky wrote: > Hi Christian > > Thanks. > > One more question. > In H.248.19 most of the properties inside packages are specified to be > "Defined in: Local/Remote". >>From what I know about H.248 -- local/remote descriptors contain SDP > messages. > > How do the H.248.19 properties coexist with SDP? > Is it only possible in binary encoding mode? > > Thanks, > Sasha > > -----Original Message----- > From: Christian Groves [mailto:christian.groves@ERICSSON.COM] > Sent: Thursday, June 16, 2005 12:35 AM > To: Sasha Ruditsky > Cc: itu-sg16(a)external.cisco.com > Subject: Re: The question about extension of an H.248 package. > > Hello Sasha, > > There is no hard rule of what to propose. It really depends on the type > of information you want added. > > I think the only time the package extension should be used is if the > added properties/signals/events provide a set of functions of their own > right. e.g. > would it makes sense that these properties could be a package by > themselves but need another package to operate. For example: The tone > gen package. The DTMF was added as a extension package as DTMF > generation is its own subset functionality but is related to the > generation of tones. > > Regards, Christian > > Sasha Ruditsky wrote: > > >>Hi >> >>I'm working on a proposal for July meeting to add some new properties >>to one of the H.248.19 packages. >>>From H.248 document it appears that there are defined (at least) two >>ways of doing this. >> >>* Creating a new version of an existing package >>* Creating a new package that extends the existing one. >> >> >>Can somebody please comment on the factors helping to determine which >>of these two mechanisms should be uses? >> >>Thanks, >>Sasha >>. >> > >

1 0

RE: The question about extension of an H.248 package.
by Sasha Ruditsky 16 Jun '05

16 Jun '05

Hi Christian Thanks. One more question. In H.248.19 most of the properties inside packages are specified to be "Defined in: Local/Remote". >From what I know about H.248 -- local/remote descriptors contain SDP messages. How do the H.248.19 properties coexist with SDP? Is it only possible in binary encoding mode? Thanks, Sasha -----Original Message----- From: Christian Groves [mailto:christian.groves@ERICSSON.COM] Sent: Thursday, June 16, 2005 12:35 AM To: Sasha Ruditsky Cc: itu-sg16(a)external.cisco.com Subject: Re: The question about extension of an H.248 package. Hello Sasha, There is no hard rule of what to propose. It really depends on the type of information you want added. I think the only time the package extension should be used is if the added properties/signals/events provide a set of functions of their own right. e.g. would it makes sense that these properties could be a package by themselves but need another package to operate. For example: The tone gen package. The DTMF was added as a extension package as DTMF generation is its own subset functionality but is related to the generation of tones. Regards, Christian Sasha Ruditsky wrote: > Hi > > I'm working on a proposal for July meeting to add some new properties > to one of the H.248.19 packages. >>From H.248 document it appears that there are defined (at least) two > ways of doing this. > > * Creating a new version of an existing package > * Creating a new package that extends the existing one. > > > Can somebody please comment on the factors helping to determine which > of these two mechanisms should be uses? > > Thanks, > Sasha > . >

1 0

Re: The question about extension of an H.248 package.
by Christian Groves 16 Jun '05

16 Jun '05

Hello Sasha, There is no hard rule of what to propose. It really depends on the type of information you want added. I think the only time the package extension should be used is if the added properties/signals/events provide a set of functions of their own right. e.g. would it makes sense that these properties could be a package by themselves but need another package to operate. For example: The tone gen package. The DTMF was added as a extension package as DTMF generation is its own subset functionality but is related to the generation of tones. Regards, Christian Sasha Ruditsky wrote: > Hi > > I'm working on a proposal for July meeting to add some new properties to > one of the H.248.19 packages. >>From H.248 document it appears that there are defined (at least) two > ways of doing this. > > * Creating a new version of an existing package > * Creating a new package that extends the existing one. > > > Can somebody please comment on the factors helping to determine which of > these two mechanisms should be uses? > > Thanks, > Sasha > . >

1 0

The question about extension of an H.248 package.
by Sasha Ruditsky 15 Jun '05

15 Jun '05

Hi I'm working on a proposal for July meeting to add some new properties to one of the H.248.19 packages. >From H.248 document it appears that there are defined (at least) two ways of doing this. * Creating a new version of an existing package * Creating a new package that extends the existing one. Can somebody please comment on the factors helping to determine which of these two mechanisms should be uses? Thanks, Sasha

1 0

RE: Update r1; Re: H.248.1 V3 Editorial Comments: Week 5
by Kevin Boyle 15 Jun '05

15 Jun '05

This is week 4. Let's not get ahead of ourselves, especially since I am still catching up from the Great Capitalization Change that took me literally days of effort to work through. All should note: my email address changed some time ago to kboyle(a)nortel.com. Use of the nortelnetworks.com address will start being rejected in the next day or so. Kevin -----Original Message----- From: Christian Groves [mailto:christian.groves@ERICSSON.COM] Sent: Wednesday, June 15, 2005 2:55 AM To: Albrecht.Schwarz(a)alcatel.de Cc: itu-sg16(a)external.cisco.com; kboyle(a)nortelnetworks.com Subject: Re: Update r1; Re: H.248.1 V3 Editorial Comments: Week 5 Hello Albrecht, all, I agree with Albrechts suggestions. With regards to the Generic Package I think its is a typo that change be changed as extension rules say this must be a versioning of the package. With regards to your comments ABS7 "Wording of sentence? Makes this sense?" I think the sentence should read "Allowed terminations type combinations in a context". With regards to your comments ABS8 " Note: an ALCATEL contribution to next SG16 is planned proposing "§ 5.8.7 Notify" inclusion". I'm happy to accept this as Notify is a command and should be listed. Regards, Christian PS: Kevin: Did I miss week 4 ABNF sections? I'll send some comments on week 4 in the next couple of days. Albrecht.Schwarz(a)alcatel.de wrote: > I found two further typos in Appendix II. > -> Revision "...r1" file in Incoming directory again. > > Regards > Albrecht > > > > > > Albrecht > > SCHWARZ/DE/ALCAT To: SG16 > <itu-sg16(a)external.cisco.com> > EL@ALCATEL cc: > jan.lindquist(a)ERICSSON.COM > Subject: H.248.1 V3 > Editorial Comments: Week 5 > 13.06.2005 18:25 > > > > > > > > > FYI, > > I've uploaded comments from ALCATEL side to "Week 5" in the "Incoming" > directory: > > http://ftp3.itu.int/av-arch/avc-site/Incoming/TD7%20Week%205%20Comment > s% > 20ASchwarz.doc > > > Major (technical) update is Generic Package Version 2 (instead V1) due > to inclusion of "onIteration" capability in my opinion. > > Also just the note that Alcatel contributions for next SG16 are in > planning with regard to: > 1) § E.11.5 "recommendations on statistics usage), and > 2) App. II (new § 5.8.6 Notify) > > Regards > Albrecht > > > > >

1 0

Re: Update r1; Re: H.248.1 V3 Editorial Comments: Week 5
by Christian Groves 15 Jun '05

15 Jun '05

Hello Albrecht, all, I agree with Albrechts suggestions. With regards to the Generic Package I think its is a typo that change be changed as extension rules say this must be a versioning of the package. With regards to your comments ABS7 "Wording of sentence? Makes this sense?" I think the sentence should read "Allowed terminations type combinations in a context". With regards to your comments ABS8 " Note: an ALCATEL contribution to next SG16 is planned proposing “§ 5.8.7 Notify” inclusion". I'm happy to accept this as Notify is a command and should be listed. Regards, Christian PS: Kevin: Did I miss week 4 ABNF sections? I'll send some comments on week 4 in the next couple of days. Albrecht.Schwarz(a)alcatel.de wrote: > I found two further typos in Appendix II. > -> Revision "...r1" file in Incoming directory again. > > Regards > Albrecht > > > > > > Albrecht > > SCHWARZ/DE/ALCAT To: SG16 > <itu-sg16(a)external.cisco.com> > EL@ALCATEL cc: > jan.lindquist(a)ERICSSON.COM > Subject: H.248.1 V3 > Editorial Comments: Week 5 > 13.06.2005 18:25 > > > > > > > > > FYI, > > I've uploaded comments from ALCATEL side to "Week 5" in the "Incoming" > directory: > > http://ftp3.itu.int/av-arch/avc-site/Incoming/TD7%20Week%205%20Comments% > 20ASchwarz.doc > > > Major (technical) update is Generic Package Version 2 (instead V1) due > to > inclusion of "onIteration" capability in my opinion. > > Also just the note that Alcatel contributions for next SG16 are in > planning > with regard to: > 1) § E.11.5 "recommendations on statistics usage), and > 2) App. II (new § 5.8.6 Notify) > > Regards > Albrecht > > > > >

1 0

Update r1; Re: H.248.1 V3 Editorial Comments: Week 5
by Albrecht.Schwarz＠alcatel.de 14 Jun '05

14 Jun '05

I found two further typos in Appendix II. -> Revision "...r1" file in Incoming directory again. Regards Albrecht Albrecht SCHWARZ/DE/ALCAT To: SG16 <itu-sg16(a)external.cisco.com> EL@ALCATEL cc: jan.lindquist(a)ERICSSON.COM Subject: H.248.1 V3 Editorial Comments: Week 5 13.06.2005 18:25 FYI, I've uploaded comments from ALCATEL side to "Week 5" in the "Incoming" directory: http://ftp3.itu.int/av-arch/avc-site/Incoming/TD7%20Week%205%20Comments%20 ASchwarz.doc Major (technical) update is Generic Package Version 2 (instead V1) due to inclusion of "onIteration" capability in my opinion. Also just the note that Alcatel contributions for next SG16 are in planning with regard to: 1) § E.11.5 "recommendations on statistics usage), and 2) App. II (new § 5.8.6 Notify) Regards Albrecht

1 0

H.248.1 V3 Editorial Comments: Week 5
by Albrecht.Schwarz＠alcatel.de 13 Jun '05

13 Jun '05

FYI, I've uploaded comments from ALCATEL side to "Week 5" in the "Incoming" directory: http://ftp3.itu.int/av-arch/avc-site/Incoming/TD7%20Week%205%20Comments%20 ASchwarz.doc Major (technical) update is Generic Package Version 2 (instead V1) due to inclusion of "onIteration" capability in my opinion. Also just the note that Alcatel contributions for next SG16 are in planning with regard to: 1) § E.11.5 "recommendations on statistics usage), and 2) App. II (new § 5.8.6 Notify) Regards Albrecht

1 0

Draft H.460.fantas
by Giles Chamberlin 13 Jun '05

13 Jun '05

Attached document is based on AVD-2718 from the Biel meeting. Modifications are to take into account the comments from the meeting and to improve clarity. In particular I hope I've succeeded in not breaking fast connect. As you'll see form the markup, there's more to do, but hopefully that's mostly editorial. Giles Chamberlin

1 0

Re: (????-??????????)Comments on Draft F-series documents
by Niexiuying 13 Jun '05

13 Jun '05

Dear Mr. OKUBO Sakae and all: I appreciate that Mr. OKUBO Sakae have given us the comments to draft F.dl and F.avod. I modified the draft F.dl and F.avod based on his comments. Attached is the new version of draft F.dl. The reply to Mr. OKUBO Sakaea's comments is as follows: You comments to the reversion of F.dl and comments to the reply are solicited. I will send the new version of Draft F.avod soon. Thank all of you for your comments in advance. Best Regard. Nie xiuying F.DL ^^^^ 1/ Table of Contents Why ex Section 8 Requirements has been dropped in this draft? It should be an essential part as shown in the title and scope. Add Ex Section 8 requirments to new document, delete 8.2 and 8.3 of last version. In my opinion, 8.2 and 8.3 have similar means to ex section 8. 2/ Section 1 I cannot understand the meaning of "responsive application solution" and the intention of including the "when applicable ITU-T Recommendations are not yet available" part. The latter looks contradictory if this documents is intended as an ITU-T Recommendation. I derived this setence from ITU- T REc. F.701. I think it refers to special application requirments and technical architecture and framwork. I delete the sentence from the new version document if it does not define anything. 3/ Section 2 We need to check if we can include IEEE standards as part of the normative references. I have checkITU-T releted document about it. the answer to it is "yes". 4/ Section 3, Distance Learning I do not understand what "sometimes connectedness" means. It means "through telecommunication networks"., because using post ( or mail) to send learning material is also a kind of "distance learning". 5/ Section 6, last paragraph The same comment as 1/. 6/ Section 7.1.1, Case 2, Stage 1 It is implied that DLSP provides instant messaging. Videophone and telephone look separate from DLSP. Is that the intention? It only refers to that individual instruct can also be achieved using videophone or telephone. It may or may not within DLSP. For this draft scope, I delete them from this document to limite distance learning to multimedia services. 7/ Section 7.3, 1st paragraph I would suggest to itemize listed applications as bullets. I modify the document based on this suggestion. 8/ Section 7.3, 2nd paragraph "conferences" and "files distribution applications" look too generic for this document addressing distance learning service. I delete them. 9/ Section 8.2 I would suggest to itemize listed applications under the sentence: The following are desirable adjuncts to the distance learning application: I delte this section, because I add ex section 8 requirments to this document. F.avod ^^^^^^ 1/ Section 5, 2nd paragraph I wonder if the scope of this document is limited to the use of "current carriers networks." I believe it should also take into account other type of networks like corporate, private ones. Chang it to telecommunications networks to include other networks. 2/ Section 6.1, 2nd paragraph This description doe not match Figure 1. "Control and management system" is a part of the "service provider" there. Change the description to " .. is made of content providers, service providers and end users " 3/ Section 6.1, after Figure 1, 2nd bullet, 2nd sentence It is hard to capture the structure of this sentence. Please rephrase it. 4/ Section 6.1 "value-added services" is too generic. We need some examples in the context of avod. Give some examples . such as audivisual on demand service prsented, gaming, per-order audiovisual on demand services. 5/ Section 7.1, 1st paragraph, 3rd sentence I cannot understand what "integrating centralized or distributed methods" means. Delete them form document. It refers to CDN based method and peer to peer delivery method. 6/ Section 7.2, 1st paragraph, 4th sentence starting with "Some current affairs, ..." This sentence is incomplete. delete this sentence. 7/ Section 7.3, Stage 5, 2nd last sentence It is not clear to me how "due to he has passed the authentication before" related to other part of the sentence. delete " after he passes authentication". 8/ Section 8.3, 3rd sentence This sentence is incomplete. change "." to ","to make two sentences into one sentence. 9/ Section 8.6, after the three bullets What is "start time"? Response time to the request of an audiovisual content? yes, it is. 10/ Section 9, 2) Add some more descriptions, "control" is necessary in any type of avod applications as far as "on demand" is involved. Change " control" to " monitoring". 11/ Section 11.2, 1st sentence It looks we are comparing the two different categories; provider (SP stands for Service Provider) and system (videoconference system). It is not a surprise if they are quite different in functions.　 Delete the first paragraph.　 _____ ========= _____

1 0

Re: Comments on Draft F-series documents
by sunmingjun 13 Jun '05

13 Jun '05

Dear Mr. Okubo and all, I have no problem to the editioral of F.MMCIP, following orange texts are the reply to the questions. Comments from Mr.Okubo are appreciated, and other comments and suggestions are solicited. Best£¬ Mingjun Sun sunmingjun(a)catr.com.cn China Academy of Telecommunication Technology +86-10-62302430-2413 2005-06-13 ----- Original Message ----- From: "OKUBO Sakae" <okubo(a)MXZ.MESH.NE.JP> To: <itu-sg16(a)external.cisco.com> Sent: Thursday, June 09, 2005 4:21 PM Subject: Comments on Draft F-series documents > > F.MMCIP > ^^^^^^^ > > 1/ Section 2.6 > > As we have "multimedia conference service" in Section 2.9, I would > suggest the following: > > A type of multimedia conference service that utilizes networks for > control and media transfer. > > 2/ Section 2.7, last sentence > > As we may also use ALM (Application Layer Multicast) in the future, > use of network transport multicast may not be an only solution. "may" > instead of "should" would be more appropriate. > > 3/ Section 5, 2nd paragraph > > "If there are two or more terminals, ..." I wonder if the number be > "three or more" instead of "two ore more". The multimedia information > control and exchange is needed also for the case where only two > terminals are involved? > The multimedia information control and exchange isn¡¯t needed in fact, but in some cases, the multimedia information control and exchange still works. For example, three terminals in a five-endpoints conference leaves, but the conference still continues, the multimedia information control and exchange still is needed though only the two terminals in this conference. > 4/ Section 5, 3 bullets > > It looks multiple viewpoints are involved to get these three types of > terminal: hardware/software, full/part time use, movable/fixed. > Please sort them out. > following is the propositional modification text : There are two types of terminal: ¨C Hard terminal, which includes two sub-type of terminals: dedicated studios equipped for multimedia conferences, named special conference terminal; equipment only part-time used for teleconferencing, can be moved from here to there, named Portable Terminal ¨C Soft terminal, running on Computer > 5/ Section 6.1, 2nd sentence > > We need clarification here. > > Since the "Voice/Video/Data Switch & Process function" is in the > IP-based Network area, the multimedia path between the switch&process > function and the right most User is understood to be IP. Does this > mean that PSTN Access terminal is using IP over PSTN? It looks more > realistic to me that the switch&process function has PSTN interface > and the voice is ordinary analog one. > since the function of "Voice/Video/Data Switch & Process function" is mainly about media processing, so my suggestion to this problem is another ¡°gateway function¡± is added for the PSTN and IP transition, also for the mobile. > 6/ Section 6.3 > > I would suggest to unify the function listing style as verb first. >

1 0

Comments on Draft F-series documents
by OKUBO Sakae 09 Jun '05

09 Jun '05

Dear editors and all, Very belatedly, please find after the signature my comments to the following four documents posted in April: F.VTIP Service description and requirements for videotelephony over IP services (Editor: Mr Zhang Qing) <http://ftp3.itu.int/av-arch/avc-site/2005-2008/0507_Gen/Working_Docs/FVTI P_050414.zip> F.MMCIP Service description and requirements for multimedia conferencing over IP services (Editor: Ms Sun Mingjun) <http://ftp3.itu.int/av-arch/avc-site/2005-2008/0507_Gen/Working_Docs/FMMC IPv1.1_050410.zip> F.DL Service description and requirements for distance learning services (Editor: Ms Nie Xiuying) <http://ftp3.itu.int/av-arch/avc-site/2005-2008/0507_Gen/Working_Docs/Fdlr ev1_050410clear.zip> F.AVoD Service description and requirements for audiovisual on demand services (Editor: Ms Nie Xiuying) <http://ftp3.itu.int/av-arch/avc-site/2005-2008/0507_Gen/Working_Docs/FAVO Drev1_050414.zip> They are mostly editorial to make the documents more understandable. Your review about the substance is requested so that we can decide in July if these documents be processed as draft Recommendations. 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 ****************************************************************** Comments common to the four documents ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 1/ I would suggest to include an introductory text to the service scenario section indicating its purposes, something like: This section describes typical service scenarios to illustrate the ... service and to derive its technical requirements. 2/ Please make sure that the "requirements" section reflects all of what the service scenarios indicate. 3/ "stage" vs "step" Since the terms "stage 1", "stage 2" and "stage 3" have particular meanings defined in I.130, please use "step" for our current documents. 4/ Use of capital letters It looks the use of capital letters are not consistent. The ITU guideline is in Appendix I to A.15: Unnecessary use of capitalized words should be avoided. 5/ Editorial observations I have placed marked up documents with my observations at the following place: http://ftp3.itu.int/av-arch/avc-site/2005-2008/0507_Gen/Working_Docs/FVTIP _050414_SO.zip http://ftp3.itu.int/av-arch/avc-site/2005-2008/0507_Gen/Working_Docs/FMMCI P_050410_SO.zip http://ftp3.itu.int/av-arch/avc-site/2005-2008/0507_Gen/Working_Docs/Fdl_0 50410_SO.zip http://ftp3.itu.int/av-arch/avc-site/2005-2008/0507_Gen/Working_Docs/FAVOD _050414_SO.zip Please note that the text in {} is not a modification itself but shows my comment or question F.VTIP ^^^^^^ 1/ Section 4, 3rd paragraph It may hint that videotelephony service = conventional telephony service. The use of videotelephony services ... ==> The way to place a call of videotelephony services is just the same as that of conventional telephony services ... 2/ Section 4, 2nd bullet Audio and video mixing devices may be operated by the "network" or by the "user." It would be more appropriate to delete "network" from "network devices." 3/ Section 5.2 "unmanned baby-sitting for unattended kids" should be "unmanned baby-sitting for kids"? Kids with baby-sitting are attended, I think, 4/ Section 5.3 It is not clear to me how the service profiles will be utilized in this document or other places. Please add some more positive statements of the intention. Just "for references" looks weak. 5/ Section 6.1.3, 1st paragraph Can we replace "800 customer service" with a generic naming? I think "800" is the number in the US, it is called "free dial" service in Japan and the number starts with 0120. 6/ Section 7.1, Basic requirements, 3rd bullet I wonder if "when necessary" adds particular meaning compared to the sentence without those two words. 7/ Section 7.6.1, 2nd sentence "terminal-based echo-cancellation" means acoustic echo-cancellation? Its parallel term would be "network-based" echo-cancellation. Here we are addressing echo due to the feedback from the loud-speaker to the microphone, not the one due to the 4-wire to 2-wire conversion in the network. My point is that network-based echo-cancellation may in principle deal with both network echo and acoustic echo while the terminal-based echo-canllelation deals with only acoustic echo. 8/ Section 7.6.4 1st sentence I am afraid "whenever there are motions in the human facial regions, e.g., lips or eyes" is not always true. Probably you are referring to the case where frame dropping is employed when a large amount of data is generated due to large motions. I would suggest to describe the case more precisely or delete the quoted text. F.MMCIP ^^^^^^^ 1/ Section 2.6 As we have "multimedia conference service" in Section 2.9, I would suggest the following: A type of multimedia conference service that utilizes networks for control and media transfer. 2/ Section 2.7, last sentence As we may also use ALM (Application Layer Multicast) in the future, use of network transport multicast may not be an only solution. "may" instead of "should" would be more appropriate. 3/ Section 5, 2nd paragraph "If there are two or more terminals, ..." I wonder if the number be "three or more" instead of "two ore more". The multimedia information control and exchange is needed also for the case where only two terminals are involved? 4/ Section 5, 3 bullets It looks multiple viewpoints are involved to get these three types of terminal: hardware/software, full/part time use, movable/fixed. Please sort them out. 5/ Section 6.1, 2nd sentence We need clarification here. Since the "Voice/Video/Data Switch & Process function" is in the IP-based Network area, the multimedia path between the switch&process function and the right most User is understood to be IP. Does this mean that PSTN Access terminal is using IP over PSTN? It looks more realistic to me that the switch&process function has PSTN interface and the voice is ordinary analog one. 6/ Section 6.3 I would suggest to unify the function listing style as verb first. F.DL ^^^^ 1/ Table of Contents Why ex Section 8 Requirements has been dropped in this draft? It should be an essential part as shown in the title and scope. 2/ Section 1 I cannot understand the meaning of "responsive application solution" and the intention of including the "when applicable ITU-T Recommendations are not yet available" part. The latter looks contradictory if this documents is intended as an ITU-T Recommendation. 3/ Section 2 We need to check if we can include IEEE standards as part of the normative references. 4/ Section 3, Distance Learning I do not understand what "sometimes connectedness" means. 5/ Section 6, last paragraph The same comment as 1/. 6/ Section 7.1.1, Case 2, Stage 1 It is implied that DLSP provides instant messaging. Videophone and telephone look separate from DLSP. Is that the intention? 7/ Section 7.3, 1st paragraph I would suggest to itemize listed applications as bullets. 8/ Section 7.3, 2nd paragraph "conferences" and "files distribution applications" look too generic for this document addressing distance learning service. 9/ Section 8.2 I would suggest to itemize listed applications under the sentence: The following are desirable adjuncts to the distance learning application: F.avod ^^^^^^ 1/ Section 5, 2nd paragraph I wonder if the scope of this document is limited to the use of "current carriers networks." I believe it should also take into account other type of networks like corporate, private ones. 2/ Section 6.1, 2nd paragraph This description doe not match Figure 1. "Control and management system" is a part of the "service provider" there. 3/ Section 6.1, after Figure 1, 2nd bullet, 2nd sentence It is hard to capture the structure of this sentence. Please rephrase it. 4/ Section 6.1 "value-added services" is too generic. We need some examples in the context of avod. 5/ Section 7.1, 1st paragraph, 3rd sentence I cannot understand what "integrating centralized or distributed methods" means. 6/ Section 7.2, 1st paragraph, 4th sentence starting with "Some current affairs, ..." This sentence is incomplete. 7/ Section 7.3, Stage 5, 2nd last sentence It is not clear to me how "due to he has passed the authentication before" related to other part of the sentence. 8/ Section 8.3, 3rd sentence This sentence is incomplete. 9/ Section 8.6, after the three bullets What is "start time"? Response time to the request of an audiovisual content? 10/ Section 9, 2) Add some more descriptions, "control" is necessary in any type of avod applications as far as "on demand" is involved. 11/ Section 11.2, 1st sentence It looks we are comparing the two different categories; provider (SP stands for Service Provider) and system (videoconference system). It is not a surprise if they are quite different in functions. ==========

1 0

FW: An important step for interoperability and functionality of text communication: RFC 4103 replaces RFC 2793.
by simao.campos＠itu.int 07 Jun '05

07 Jun '05

FYI -----Original Message----- From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] Sent: 07 June 2005 11:13 To: Text Telephone Forum; STF267 Cc: Björn Troili; eConf Support; Frank Shearar; Andreas Piirimets(Omnitor); Andreas Richter; Kristian Kristiansson; Johan Malmgren; Bill Pechey; Judy Harkins; Paul Jones(Packetizer); Marcelo Tapia; George Skorkowski; Bo Bergner; Robert Hecht; Andrea Saks; Guido Gybels (E-mail); Arnoud van Wijk; Gregg Vanderheiden; TR-30. 1; Campos, Simao; Tom Taylor; Henry Sinnreich; Christian Groves; Pekka. V. Heikkinen; Claes Tjäder Subject: An important step for interoperability and functionality of text communication: RFC 4103 replaces RFC 2793. An IETF document describing real time text transmission in IP networks is approved and published. The work with revision of the real time text transport specification RFC 2793 in IETF is completed. During the work, we have called it rfc2793bis. The result is now published as a standards track RFC: RFC 4103 RTP Payload for Text Conversation By that, RFC 2793 is made obsolete. RFC 4103 is backwards compatible with its predecessor, so the move will be smooth. There are two new parameters to handle. All references to RFC 2793 in other standards can now be read as RFC 4103, and should eventually be replaced in the texts by RFC 4103. This is valid for example for the following documents referring to RFC 2793. ITU-T H.323 Annex G Text converation and Text SET ITU-T H.248.2 Text, Fax and call discrimination packages ITU-T Draft requirements for text over IP ITU-T Draft V.151 Procedures for the end-to-end connection of analogue PSTN text telephones over an IP network utilizing text relay. ETSI TS 126 235 IP Multimedia default codecs ETSI TS 123 226 Global Text Telephony Stage 2 ETSI Draft EG 202 320 Duplex Universal Speech and Text 3GPP TS 26.235 IP Multimedia default codecs 3GPP TS 23.226 Global Text Telephony Stage 2 draft-ietf-sipping-toip Text over IP requirements draft-sinnreich-sipdev-req SIP telephony device requirements draft-ietf-avt-rfc2833bis RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals draft-ietf-avt-rfc2833bisdata Definition of Events For Modem, FAX, and Text Telephony Signals The main improvements are: -------------------------- -SDP examples clearly showing how a real time text channel can be negotiated and opened in a SIP session. -Clear packet layout examples showing various cases with and without redundancy. -Clearer and stronger recommendations to use the default two levels of redundant transmission to keep the risk for character loss very low. -Clearer and stronger recommendations to use 300 ms buffering between transmissions in order to keep the risk for character loss very low and to keep bandwidth usage for text very low. -More explicit recommendations on how to apply security considerations. -More explicit descriptions of the procedures for recovery from packet loss. -More explicit descriptions of the procedures for protection from congestion. By these improvements, I am sure that this RFC will contribute well to good interoperability and high functionality of real time conversation applications including the imnportant text medium as a popular feature improving communications for all. I and Paul Jones stand as authors, but many more have made this improvement possible by putting efforts into the work. Thanks to all! Another related document has also been published. It is RFC 4102 Registration of the text/red MIME Sub-Type. Here is a copy of the IETF announcements: -------------------------------------------------------------------------- ---------------- - A new Request for Comments is now available in online RFC libraries. RFC 4103 Title: RTP Payload for Text Conversation Author(s): G. Hellstrom, P. Jones Status: Standards Track Date: June 2005 Mailbox: gunnar.hellstrom(a)omnitor.se, paulej(a)packetizer.com Pages: 20 Characters: 44246 Obsoletes: 2793 I-D Tag: draft-ietf-avt-rfc2793bis-09.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4103.txt This memo obsoletes RFC 2793; it describes how to carry real-time text conversation session contents in RTP packets. Text conversation session contents are specified in ITU-T Recommendation T.140. One payload format is described for transmitting text on a separate RTP session dedicated for the transmission of text. This RTP payload description recommends a method to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss. This document is a product of the Audio/Video Transport Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. ------------------------------------------------------------------------- A new Request for Comments is now available in online RFC libraries. RFC 4102 Title: Registration of the text/red MIME Sub-Type Author(s): P. Jones Status: Standards Track Date: June 2005 Mailbox: paulej(a)packetizer.com Pages: 6 Characters: 11337 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-avt-text-red-05.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4102.txt This document defines the text/red MIME sub-type. "Red" is short for redundant. The actual RTP packetization for this MIME type is specified in RFC 2198. This document is a product of the Audio/Video Transport Working Group of the IETF. This is now a Proposed Standard Protocol. ---------------------End of copy--------------------- 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 --------------------------------------------

1 0

Editing Comment from Week 1 and Week2
by Christian Groves 07 Jun '05

07 Jun '05

Hello all, The following 2 sections talk about package extension. 6.2.3 Packages For improved interoperability and backward compatibility, an MG MAY publish all Packages supported by its Terminations, including base Packages from which extended Packages are derived. An exception to this is in cases where the base packages are expressly "Designed to be extended only". 12.1.1 Designed to be extended only (Optional): Yes This indicates that the package has been expressly designed to be extended by others, not to be directly referenced. For example, the package may not have any function on its own or be nonsensical on its own. The MG SHOULD NOT publish this PackageID when reporting packages. I think there could be a chance that some people misread section 6.2.3 in that "Designed to be extended only" packages MAY be published. I believe this is not the intention as clarified in section 12.1.1. Therefore I would propose that 6.2.3 states: 6.2.3 Packages .. For improved interoperability and backward compatibility, an MG MAY publish all Packages supported by its Terminations, including base Packages from which extended Packages are derived. An exception to this is in cases where the base packages are expressly "Designed to be extended only"<<<, these packages shall not be published.>>> Regards, Christian

1 0