=====================================================================
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 …
[View More]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
[View Less]
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 …
[View More]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
[View Less]
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 …
[View More]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
***********************************************************
[View Less]
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
…
[View More]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
>> >
>>
>
[View Less]
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
******************************…
[View More]*****************************
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
[View Less]
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 …
[View More]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"
>
>
[View Less]
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 …
[View More]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
[View Less]
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:
> …
[View More]>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.
> --------------------------------------------------
[View Less]
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 …
[View More]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"
[View Less]