- sg16-avd - lists.packetizer.com

Packet Video 2000 - Call for Papers
by pv2000 07 Jul '99

07 Jul '99

===================================================================== PRELIMINARY CALL FOR PAPERS ====================================================================== PACKET VIDEO 2000 The 10th International Packet Video Workshop Date: 1-2 May 2000 Venue: Forte Village Resort, Cagliari, Italy Web site: http://www.diee.unica.it/pv2000/ Organization: Francesco G.B. De Natale and Daniele D. Giusto, University of Cagliari Technical sponsors: EURASIP, IEEE Signal Processing Society (IMDSP and MMSP Technical Committees) ====================================================================== The tenth edition of the International Packet Video Workshop (PV 2000) will be held at the Forte Village Resort, Cagliari, Italy. The workshop is devoted to present technological advancements and innovations in video communications over packet networks, in particular, the Internet. Packet Video Workshops have been unique in providing a common ground for people from video coding and networking fields. Presentations on theory and practice, standards activities, and business and consumer applicatons are encouraged. We cordially invite you to take part in this workshop by submitting your work and look forward to seeing you in Sardinia in May 2000 for what will be a most rewarding and exciting experience! ====================================================================== TECHNICAL PROGRAM Chairs: Leonardo Chiariglione, CSELT, Turin Maurizio Decina, Cefriel and Polytechnic of Milan The technical program of Packet Video 2000 will consist of invited talks, submitted paper presentations, poster sessions and demos Topics of interest include, but are not limited to: Video processing and transmission Video streaming over the Internet Network adaptive video coding and transport Packetized video for home LANs Packetized video for wireless/mobile systems Layered coding for error resilience and heterogeneous networks Packet loss resilient coding and transport Terminal and server architectures for Internet TV Efficient transcoding for heterogeneous networks Congestion control Error concealment Pre and post-processing for picture quality enhancement Statistical multiplexing for greater network and terminal utilization Traffic shaping for efficient network and terminal utilization Interstream synchronization for multiple video presentations Performance modeling and evaluation Picture quality evaluation Rate control for VBR video International Standards: MPEG-4, MPEG-7, H.263, RTP, RTSP, SIP, SDP Multicasting, MBONE applications Implementations and commercial applications ====================================================================== Best Paper Award The author of the best paper will receive a $250 prize and a diploma suitable for framing. ====================================================================== Please submit an electronic manuscript written in HTML, not exceeding 7 Mbytes and 10 printed pages. We will produce a CD-ROM containing all the accepted papers. Electronic components accompanying your submission are strongly encouraged. Submit your work in ONE of the following forms: 1) a set of HTML files organized in a single directory OR 2) as a URL (you must have the rights to all the material there, and guarantee stability of the files until the conference). to: pv2000(a)diee.unica.it Detailed instructions for authors and help with manuscript preparation with HTML can be found on the conference web page. Deadlines: paper submission: December 15, 1999, notification of acceptance: February 29, 2000 final paper delivery: March 31, 2000 ====================================================================== Publication and local arrangements Luigi Atzori Dept. of Electrical and Electronic Engineering University of Cagliari Piazza d'Armi, 19 09123 Cagliari, Italy gigi(a)diee.unica.it

1 0

Re: Moving on
by Roy, Radhika R, ALCOO 07 Jul '99

07 Jul '99

Hi Chris: We have been delighted to see the contributions that you made during your participation in H.323. However, I am sad to see that you are leaving the H.323 arena. With a hope to have a bright career in your new opportunity, Radhika > -----Original Message----- > From: Chris Purvis [SMTP:Chris.Purvis@MADGE.COM] > Sent: Wednesday, July 07, 1999 6:03 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Moving on > > All, > > I will be leaving Madge Networks at the end of the week, and with it (at > least for the moment) the H.323 arena - so don't be surprised that I'll no > longer be posting to these lists! > Although I've enjoyed working with you all, a new opportunity beckons... > > Regards, > Chris > -- > Until Friday 9th July 1999: > Dr Chris Purvis - Senior Development Engineer, WAVE CC Software > Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. > ENGLAND > Phone: +44 1753 661 359 email: cpurvis(a)madge.com > > From Monday 12th July 1999: > Dr Chris Purvis - Development Manager > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road, > Winkfield Row, Berkshire RG42 6LY. ENGLAND > Phone: +44 1344 899 007 email: Chris.Purvis(a)isdn-comms.co.uk

1 0

Docuement download
by Edgar Martinez [1] 07 Jul '99

07 Jul '99

2 1

Use of GIT instead of B-HLI in H.310 and H.323 Annex C
by Sakae OKUBO 03 Jul '99

03 Jul '99

Dear Mr. Hedayat, Dear Mr. Audet, FA> I'd support this as well: some additional text regarding backward FA> compatibility (use of GIT instead of B-HLI) is required. Along the FA> lines of what was done for H.310 which went throught the same FA> change. What happened to H.310 as I recollect are as follows: 1. H.310 Version 1 (approved in November 1996) Use of GIT was included in the Q.2931 SETUP message table for the H.245 resource/correlation number to associate the logical channel and ATM VC. But GIT was noted as "under development". 2. H.310 V1 Implementors Guide approved in March 1997 As part of detailing and clarifying the use of DSS2 call signalling, it was specified that H.310 correlation ID (H.245 resourceID in the H222LogicalChannelParameters) shall be coded according to Q.2941.1 (GIT) in the Q.2931 SETUP message. At the same time, it was also specified that "Optionally, the H.310 correlationID may also be sent in the Broadband High Layer IE (B-HLI) as follows. ... In the case where either of the terminals do not support the GIT information element, the B-HLI information element shall be used to convey the H.310 correlationID." Appendix II for extended use of Q.2931 Release 1 describes how to use B-HLI for the H.310 Correlation ID with the note "These accommodations are provisional, the Generic Identifier Transport Information Element should be used to convey the H.310 correlation ID when the relevant Q.2931 specifications have been implemented." 3. H.310 Version 2, determined in February 1998 At this meeting, SG16 received a liaison statement from SG11 advising that the use of B-HLI for the purpose of conveying the H.310 Correlation ID was inappropriate. Hence in the process of integrating the H.310 V1 Impelmentors Guide into draft H.310 V2, the option of B-HLI use was totally deleted. Instead, according to the SG11 suggestion, the following one line sentence was added: "Optionally, the H.310 correlationID may also be sent in the user-to-user information IE." However, there is no description of how to use the user-to-user information IE for this purpose. 4. H.310 Version 2, decided in September 1998 Compared to Version 1, the following were added: - H.310 V1 IG except for the above mentioned optional B-HLI use for H.310 Correlation ID - Correction approved in February 1998 for the H.320/H.321 stack for the RAST-5 terminal - Procedures for the interworking procedures between RAST-1 and RAST-5 terminals which were developed in the experts group work. I hope this information may be of some use for considering the text for H.323 Annex C regarding the use of GIT instead of B-HLI, though the situations appears to be not completely the same between H.310 and H.323 Annex C. KH> If the additional text is approved in Berlin will it KH> be possible to add it to H.323 V3? We should respect the guideline that officially the Rapporteur meeting cannot re-address the matters in the White Contribution for decision (in the spirit of determination based on maturity). However, the rule allows that based on written contributions SG16 meeting in September may modify the draft Recommendation submitted as White Contribution. Once the consensus is obtained at the Berlin meeting, a delayed contribution should be submitted by Administration(s) or ITU-T Sector member organization(s). Best regards, Sakae OKUBO (Mr.) *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0

Re: H.323v3 for decision in September
by Pete Cordell 02 Jul '99

02 Jul '99

Paul, The reason for proposing the extensibility framework changes is to make future additions to H.323 easier. Indeed, V4 extensions could be implemented as annexes which exploit the extensibility framework. They would then have a standardisation cycle of their own, and each new implementation of a version is not loaded with baggage that is potentially not of interest to it. Therefore post-poning them to V4 is highly un-desirable. People have made contribution plans based on the previous dead-lines. Quickly dropping a half-baked version of H.323 that then forces as to wait another 2 years for any revisions makes little sense. Pete ============================================= Pete Cordell pete(a)tech-know-ware.com ============================================= -----Original Message----- From: Paul E. Jones <paul.jones(a)TIES.ITU.INT> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> Date: 29 June 1999 16:52 Subject: Re: H.323v3 for decision in September >Pete, > >I would venture to say that, given the nature of this work, it would not be >included in H.323v3. However, it could certainly be included in H.323v4, >which, as I noted below, will be determined in February. > >There are actually a number of new features people want to add to H.323, >which is one reason for adjusting the schedule. By deciding v3 in >September, we can focus our attention on v4, which will give us the time to >enrich H.323 in a reasonable timeframe. It would be nearly impossible to >properly add all of the new features to v3 between now and February. > >Would you be willing to bring that document as a contribution toward v4? > >Paul > >----- Original Message ----- >From: Pete Cordell <pete(a)TECH-KNOW-WARE.COM> >To: <ITU-SG16(a)MAILBAG.INTEL.COM> >Sent: Tuesday, June 29, 1999 4:01 AM >Subject: Re: H.323v3 for decision in September > > >> One issue I was discussing with my BT colleagues was installing an open >> framework for extensibility and feature negotiation into H.323v3. The >> motivation for this was to enable transport of SS7, but also other >protocols >> such as DPNSS, (is CAS a digital one?) and so on. If we were to go ahead >I >> guess we would have presented something in Berlin. >> >> Given that September is fast approaching waiting for such a scheme to >> transport things like SS7 does not seem too onerous. >> >> Unfortunately my colleagues are out this week, but I will attach the >latest >> text so that people can have early sight of it. >> >> Regards, >> >> Pete >> >> ============================================= >> Pete Cordell >> pete(a)tech-know-ware.com >> ============================================= >> >> -----Original Message----- >> From: Paul E. Jones <paul.jones(a)TIES.ITU.INT> >> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> >> Date: 29 June 1999 01:25 >> Subject: H.323v3 for decision in September >> >> >> >Folks, >> > >> >We may attempt to decide H.323v3 in September and determine version 4 in >> >February. Mr. Skran has asked that I post the current draft so that >people >> >can review the document. This document must be delivered to the ITU by >30 >> >June 1999. (Please note that Annex C/H.323 is also a candidate for >> decision >> >in Septemer.) >> > >> >This document contains only minor editorial changes to the document that >> was >> >determined in Santiago. Nonetheless, I encourage you to review the >> document >> >for any errors or omissions. >> > >> >The change marks indicate all changes that have been made since version >2. >> > >> >Please direct any comments on the document to me. >> > >> >The document can be found here: >> > >> >ftp://standards.pictel.com/avc-site/Incoming/H.323v3-990628.doc >> > >> >Best Regards, >> >Paul E. Jones >> >DataBeam Corporation >> > >> >

2 1

Q.16-17/16 Rapporteur meeting
by Sakae OKUBO 02 Jul '99

02 Jul '99

Dear Q.12-14/16 experts, Attached please find the notice of the subject meeting held in Geneva during 25-27 August 1999. Best regards, Sakae OKUBO (Mr.) *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** Subject: Convocation of the Rapporteur's meeting on Q16 and 17/16 Date: Thu, 1 Jul 1999 15:18:37 +0200 Importance: high X-Priority: 1 MIME-Version: 1.0 Dear Colleagues, As agreed at Santiago a Rapporteur meeting regarding Qs 16 and 17/16 will take place in Geneva at the ITU premises from 25 to 27 August 1999 (inclusive), with the following agenda: 1. Opening 2. Approval of the agenda 3. Discussion/proposals a) for the project "MEDIA COM 2004" b) possible information to TSAG c) communication with other SGs 4. Preparation of the meeting of IP experts of SG 13 (Geneva, 30 August - 10 September 1999) 5. GII projects under the responsibility of SG 16 7. Miscellaneous 8. Future work 9. Closing The meeting will open at 09.30 hours on the first day. Detailed information concerning the meeting rooms will be displayed on screens at the entrances to ITU headquarters. The results of this meeting will also serve as preparation for the review of Questions for the next study period. This activity will very likely take place in a meeting organized on 30 September (afternoon session), 1 October and 2 October (if needed), with the participation of the management of SG 16 and the Rapporteurs. Contributions to the August meeting should reach TSB as soon as possible and will be posted in Q16/16 and Q17/16 informal ftp area. A copy of contributions should be sent to the Rapporteur Mr. M. Matsumoto at e-mail: matumoto(a)tom.comm.waseda.ac.jp Would you be so kind as to confirm your participation to the August meeting of Q16 and 17/16 by return e-mail, and in any case prior to 15 August 1999. Yours faithfully Fabio Bigi TSB Senior Counsellor

1 0

Re: PDU & ASN parser
by Pete Cordell 01 Jul '99

01 Jul '99

Dear All, I support the principle that only one H.225 call signalling message should be sent per TPKT. Firstly I believe it was agreed between early implementers that this is the way they would work. Secondly, even though it is possible to send multiple PER messages per TPKT there are other reasons why this is not totally desirable. In our case of working on a high volume GK, we only need to process a fraction of H.245 messages. If there is only one message per TPKT we can easily work out what the message is by looking at the first few bytes. However, if there are multiple messages per packet we have no choice but to decode each and every message. In most cases this represents a totally unnecessary processing overhead and is therefore best avoided. Pete ============================================= Pete Cordell pete(a)tech-know-ware.com ============================================= -----Original Message----- From: Paul Long <Plong(a)SMITHMICRO.COM> To: 'h323implementors(a)imtc.org' <h323implementors(a)imtc.org> Cc: ITU-SG16(a)mailbag.cps.intel.com <ITU-SG16(a)mailbag.cps.intel.com> Date: 30 June 1999 17:53 Subject: RE: PDU & ASN parser >Guntram, > >I raised this issue over a year ago. In addition, H.225.0 does not address >this issue regarding RAS (it does regarding call signaling), so I suppose one >could pack multiple RAS messages per unreliable-transport PDU. As you say, it >doesn't make sense to pack messages, and I don't think anyone does it. We >should probably add something like the following to section 6.1 of the next >revision of H.225.0. > >"When messages are sent on the H.225.0 RAS channel, only one whole message >shall be sent within the boundaries defined by the transport; there shall be >no fragmentation of H.225.0 RAS messages across transport PDUs." > >We should also insert the indicated text, below, into existing text in the >same section. > >"When messages are sent on the reliable H.245 control channel, >>>exactly one >message should be sent but<<< more than one message may be sent within the >boundaries defined by the reliable transport PDU as long as whole messages are >sent;" > >Paul Long >Smith Micro Software, Inc. > > -----Original Message----- > From: Guntram Diehl [SMTP:gdiehl@innovaphone.com] > Sent: Wednesday, June 30, 1999 4:14 AM > To: 'Bancroft Scott'; 'Srikanth Nayani' > Cc: 'h323implementors(a)imtc.org' > Subject: RE: PDU & ASN parser > > Yes this can be done, but does any implementation actually do it? Why > would anyone want to do this, it just saves 4 bytes tpkt header per > additional H.245 message and it does not change the fragmentation of >the > whole thing by IP. > > Or is there another reason why this was specified in the standard this > way? > > Guntram > > -----Original Message----- > From: Bancroft Scott [mailto:baos@OSS.COM] > Sent: Wednesday, June 30, 1999 3:54 AM > To: Srikanth Nayani > Cc: h323implementors(a)imtc.org > Subject: Re: PDU & ASN parser > > > On Tue, 29 Jun 1999, Srikanth Nayani wrote: > > > In the H.225 document chapter 6 mentions that multiple messages >can be > > sent over the reliable H.245 control channel within the boundaries >of the > > reliable transport channel . Does that mean that two H.245 PDUs >encoded > > using PER and whose total encoded length is within the boundary of >the > > H.245 TCP channel can be merely concatenated and sent as a single >payload > > of the H.245 TCP channel. > > If so how does a ASN.1 decoder know that there are two >messages in the > > payload and the offset at which the second message starts. > > An PER decoder does not know that there are two messages in the >payload. > It does know where the first message ends, so the location of the next > message can be derived from this knowledge. > > >------------------------------------------------------------------------ > -- > Bancroft Scott Toll Free > :1-888-OSS-ASN1 > Open Systems Solutions, Inc. > International:1-609-987-9073 > baos(a)oss.com Tech Support > :1-732-249-5107 > http://www.oss.com Fax > :1-732-249-4636 > > >------------------------------------------------------------------------ > - > for list subscription instructions, > send email to h323implementors-request(a)imtc.org with text "info" > > >------------------------------------------------------------------------- > for list subscription instructions, > send email to h323implementors-request(a)imtc.org with text "info" >------------------------------------------------------------------------- >for list subscription instructions, >send email to h323implementors-request(a)imtc.org with text "info" > >

1 0

Re: New T.35
by Paul Long 30 Jun '99

30 Jun '99

Paul, Could we run into problems with some country actually using the extension field? (I think the US always defines it to be zero.) I don't see any other alternative, though. Paul Long Smith Micro Software, Inc. -----Original Message----- From: Paul E. Jones [SMTP:paul.jones@TIES.ITU.INT] Sent: Monday, June 28, 1999 9:31 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: New T.35 Folks, As many of you know, the latest T.35 document supports more than 254 country codes. In the newest document, T.35 says that one or two octets may be used to indicate the country code. If the first octet contains 1111 1111, the second octet will contain the country code. Unfortunately, the syntax in H.245 does not utilize extension markers, so there is no place to hold second octet for the country code. Therefore, I would like to propose that, both for H.225.0 and H.245, we change the comments in the ASN.1 from: t35CountryCode INTEGER(0..255), -- country, as per T.35 t35Extension INTEGER(0..255), -- assigned nationally manufacturerCode INTEGER(0..65535), -- assigned nationally to the following t35CountryCode INTEGER(0..255), -- country, as per T.35 Annex A t35Extension INTEGER(0..255), -- assigned nationally, unless the -- t35CountryCode is 1111 1111, in -- which case this field shall -- contain the country code found -- in T.35 Annex B manufacturerCode INTEGER(0..65535), -- assigned nationally This may be a perversion of the t35Extension field, but we have a limited number of options if we wish to support the usage of two octets for a country code in H.245. What are your opinions? Best Regards, Paul

5 5

Re: MGCP reference (was Re: Megaco/H.gcp conference call)
by Tom-PT Taylor 30 Jun '99

30 Jun '99

It's for real. Honestly speaking, there is much wariness on the IETF side, but so long as the outcome continues to be sensible the agreement is holding. > -----Original Message----- > From: Chip Sharp [SMTP:chsharp@cisco.com] > Sent: Wednesday, June 30, 1999 1:40 PM > To: Taylor, Tom-PT [CAR:5V00-I:EXCH]; ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: MGCP reference (was Re: Megaco/H.gcp conference call) > > At 09:53 AM 6/30/99 -0400, Tom-PT Taylor wrote: > >Here's a brief history, from my point of view -- others are free to add > >their viewpoints. > > > ...snip... > > > >May 1998: formal Megaco/H.GCP cooperative arrangement announced. > ...snip... > I believe the arrangement announced in Santiago has not actually been > formalized or confirmed. At least that was the impression I got from > Scott's mail. Of course, just because there is no formal arrangement > doesn't mean megaco and Q.14 aren't working toward common protocol. > > Since you brought it up though, :-), what is the status of the > arrangement? > > Chip > > -------------------------------------------------- > Chip Sharp Consulting Engineering > Cisco Systems Telco Bio-region > Reality - Love it or Leave it. > --------------------------------------------------

1 0

Re: PDU & ASN parser
by Sherlock, Stuart 30 Jun '99

30 Jun '99

Would someone please unsubscribe me. Thanks Stuart Sherlock -----Original Message----- From: Paul Long [mailto:Plong@SMITHMICRO.COM] Sent: Wednesday, June 30, 1999 9:28 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: PDU & ASN parser Guntram, I raised this issue over a year ago. In addition, H.225.0 does not address this issue regarding RAS (it does regarding call signaling), so I suppose one could pack multiple RAS messages per unreliable-transport PDU. As you say, it doesn't make sense to pack messages, and I don't think anyone does it. We should probably add something like the following to section 6.1 of the next revision of H.225.0. "When messages are sent on the H.225.0 RAS channel, only one whole message shall be sent within the boundaries defined by the transport; there shall be no fragmentation of H.225.0 RAS messages across transport PDUs." We should also insert the indicated text, below, into existing text in the same section. "When messages are sent on the reliable H.245 control channel, >>>exactly one message should be sent but<<< more than one message may be sent within the boundaries defined by the reliable transport PDU as long as whole messages are sent;" Paul Long Smith Micro Software, Inc. -----Original Message----- From: Guntram Diehl [SMTP:gdiehl@innovaphone.com] Sent: Wednesday, June 30, 1999 4:14 AM To: 'Bancroft Scott'; 'Srikanth Nayani' Cc: 'h323implementors(a)imtc.org' Subject: RE: PDU & ASN parser Yes this can be done, but does any implementation actually do it? Why would anyone want to do this, it just saves 4 bytes tpkt header per additional H.245 message and it does not change the fragmentation of the whole thing by IP. Or is there another reason why this was specified in the standard this way? Guntram -----Original Message----- From: Bancroft Scott [mailto:baos@OSS.COM] Sent: Wednesday, June 30, 1999 3:54 AM To: Srikanth Nayani Cc: h323implementors(a)imtc.org Subject: Re: PDU & ASN parser On Tue, 29 Jun 1999, Srikanth Nayani wrote: > In the H.225 document chapter 6 mentions that multiple messages can be > sent over the reliable H.245 control channel within the boundaries of the > reliable transport channel . Does that mean that two H.245 PDUs encoded > using PER and whose total encoded length is within the boundary of the > H.245 TCP channel can be merely concatenated and sent as a single payload > of the H.245 TCP channel. > If so how does a ASN.1 decoder know that there are two messages in the > payload and the offset at which the second message starts. An PER decoder does not know that there are two messages in the payload. It does know where the first message ends, so the location of the next message can be derived from this knowledge. ------------------------------------------------------------------------ -- Bancroft Scott Toll Free :1-888-OSS-ASN1 Open Systems Solutions, Inc. International:1-609-987-9073 baos(a)oss.com Tech Support :1-732-249-5107 http://www.oss.com Fax :1-732-249-4636 ------------------------------------------------------------------------ - for list subscription instructions, send email to h323implementors-request(a)imtc.org with text "info" ------------------------------------------------------------------------- for list subscription instructions, send email to h323implementors-request(a)imtc.org with text "info"

2 1