- sg16-avd - lists.packetizer.com

Re: unsubscribe
by Kamalakanta Palei 22 Jun '05

22 Jun '05

Vehbi Sheholli <Vehbi.Sheholli(a)PTKONLINE.COM> wrote: -----Original Message----- From: FCG Wang JuLin [mailto:JuLin.Wang@alcatel-sbell.com.cn] Sent: Wednesday, June 22, 2005 3:04 AM To: itu-sg16(a)external.cisco.com Subject: unsubscribe __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Re: unsubscribe
by Kamalakanta Palei 22 Jun '05

22 Jun '05

Vehbi Sheholli <Vehbi.Sheholli(a)PTKONLINE.COM> wrote: -----Original Message----- From: FCG Wang JuLin [mailto:JuLin.Wang@alcatel-sbell.com.cn] Sent: Wednesday, June 22, 2005 3:04 AM To: itu-sg16(a)external.cisco.com Subject: unsubscribe __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

unsubscribe
by Vehbi Sheholli 22 Jun '05

22 Jun '05

-----Original Message----- From: FCG Wang JuLin [mailto:JuLin.Wang@alcatel-sbell.com.cn] Sent: Wednesday, June 22, 2005 3:04 AM To: itu-sg16(a)external.cisco.com Subject: unsubscribe

1 0

Re: 8. H.248.1: Value of Statistics at a Termination Level; Re: H.248 .1
by Albrecht.Schwarz＠alcatel.de 22 Jun '05

22 Jun '05

Proposal is OK from my side. Regards/Albrecht Christian Groves <christian.groves@er To: Albrecht SCHWARZ/DE/ALCATEL@ALCATEL icsson.com> cc: SG16 <itu-sg16(a)external.cisco.com>, Kevin Boyle <kboyle(a)nortel.com> Subject: Re: 8. H.248.1: Value of Statistics at a Termination Level; Re: 22.06.2005 09:19 H.248 .1 Editing Meeting Week 4 comments Hello Albrecht, You have a good point about that the "superior function" could be something other than the "sum" it could in fact be the "average" and mostly dependent on statistic type. I think your proposal still leaves it open what to do with a termination level statistic. I would like to see at least a default behaviour like "sum", I also think that we should say that this may be modified by an individual statistic definition. That way if someone doesn't add text (eg. all the existing statistics) then a certain behaviour can be assumed. Would the following text be agreeable: "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. Unless specified otherwise in the package that defines a particular statistic, the default behaviour is a sum of the values." Regards, Christian Albrecht.Schwarz(a)alcatel.de wrote: > 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) > >

1 0

Re: 8. H.248.1: Value of Statistics at a Termination Level; Re: H.248
by Christian Groves 22 Jun '05

22 Jun '05

Hello Albrecht, You have a good point about that the "superior function" could be something other than the "sum" it could in fact be the "average" and mostly dependent on statistic type. I think your proposal still leaves it open what to do with a termination level statistic. I would like to see at least a default behaviour like "sum", I also think that we should say that this may be modified by an individual statistic definition. That way if someone doesn't add text (eg. all the existing statistics) then a certain behaviour can be assumed. Would the following text be agreeable: "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. Unless specified otherwise in the package that defines a particular statistic, the default behaviour is a sum of the values." Regards, Christian Albrecht.Schwarz(a)alcatel.de wrote: > 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) > >

1 0

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

22 Jun '05

Hello Sasha, It looks like the editorial version was fixed by the TSB during publishing. The published version uses cvsp. Regards, Christian Sasha Ruditsky wrote: > Hi Christian > > Thanks, > I understand now the definition of vwp/wxp and vwp/wyp. > > Regarding to the editorial problem. > In the version, which I have (which is TD33(PLEN) from Geneva Jan 2004 > meeting) in the figure 8 the text says: > > Property Group 1 > vwp/vid=1,vwp/wseq=1,vwp/wxp=2500,vwp/wyp=0, > vwp/wh=7500,vwp/wl=5000,vwpcvsp/ovs=2 > Property Group 2 > vwp/vid=2,vwp/wseq=2,vwp/wxp=5000,vwp/wyp=2500, > vwp/wh=7500,vwp/wl=5000,vwpcvsp/ovs=1 > > > Regards, > Sasha > > -----Original Message----- > From: Christian Groves [mailto:christian.groves@ERICSSON.COM] > Sent: Sunday, June 19, 2005 10:21 PM > To: Sasha Ruditsky > Cc: itu-sg16(a)external.cisco.com > Subject: Re: The question about extension of an H.248 package. > > 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

unsubscribe
by FCG Wang JuLin 21 Jun '05

21 Jun '05

1 0

H.248.1 V3 Week 5 Comments
by Picha, Marianne (Marianne) 21 Jun '05

21 Jun '05

Attached are my comments - through section F.4.1.1 Marianne <<TD7 Week 5 Comments mpicha.doc>>

1 0

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

21 Jun '05

Hi Christian Thanks, I understand now the definition of vwp/wxp and vwp/wyp. Regarding to the editorial problem. In the version, which I have (which is TD33(PLEN) from Geneva Jan 2004 meeting) in the figure 8 the text says: Property Group 1 vwp/vid=1,vwp/wseq=1,vwp/wxp=2500,vwp/wyp=0, vwp/wh=7500,vwp/wl=5000,vwpcvsp/ovs=2 Property Group 2 vwp/vid=2,vwp/wseq=2,vwp/wxp=5000,vwp/wyp=2500, vwp/wh=7500,vwp/wl=5000,vwpcvsp/ovs=1 Regards, Sasha -----Original Message----- From: Christian Groves [mailto:christian.groves@ERICSSON.COM] Sent: Sunday, June 19, 2005 10:21 PM To: Sasha Ruditsky Cc: itu-sg16(a)external.cisco.com Subject: Re: The question about extension of an H.248 package. 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

unsubscribe
by Christine Pepin 21 Jun '05

21 Jun '05

1 0