- sg16-avd - lists.packetizer.com

unsubscribe
by morgan.potter＠BT.COM 21 Jun '05

21 Jun '05

1 0

unsubscribe
by Lars Briseid 21 Jun '05

21 Jun '05

1 0

unsubscribe
by Paul Jr.,Grant G. 21 Jun '05

21 Jun '05

1 0

unsubscribe
by pango 21 Jun '05

21 Jun '05

1 0

unsubscribe
by ludovic.de-graaf＠transport.alstom.com 21 Jun '05

21 Jun '05

1 0

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 ************************************************************… [View More]

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-… [View More]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 [View Less]

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-… [View More]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 [View Less]

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 … [View More]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 [View Less]

1 0