IETF 59 AVT minutes

Hi,

Attached are the final AVT minutes after addressing the comments 
received during the comments period.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund <at> ericsson.com

Audio/Video Transport Working Group Minutes

Reported by Magnus Westerlund and Colin Perkins

   The AVT working group had two sessions during the 59th IETF meeting, 
   the first on Tuesday morning, and the second on Wednesday afternoon. 
   During these sessions the WG discussed RTP payload formats for 
   different media codecs, RTCP Extensions for SSM, header compression 
   requirements for MPLS, a NOOP RTP payload format with RTCP request 
   hint, and a new RTP profile for congestion control with TFRC. 

Introduction and Status Update

   The meeting began with a status update from the chairs. Two RFCs 

Call for Papers: BASENETS '04

Apologies if you receive multiple copies of this call!

----------------------------------------------------------------------

                         CALL FOR PAPERS

      ********************************************************    
      *                                                      *
      *  1st Workshop on Broadband Advanced Sensor Networks  *
      *           (co-located with BroadNets 04)             *
      *             San Jose, CA, October 2004               *
      *                                                      *
      *                    BASENETS 04                       *
      *                                                      *
      ********************************************************
      *                                                      *
      *             http://www.basenets.org                  *
      *                                                      *
      ********************************************************

SCOPE

The emergence and adoption of broadband wireless access standards,
such as 802.16, 802.16a and 802.11a/g, offers exciting new
possibilities for high-bandwidth data communication over the "last
mile". A significant use of such high bandwidth may lie in the use of
a variety of multimodal sensors for monitoring and control of diverse
geographic areas. Such sensors may be used for remote video/audio
surveillance and active monitoring of telemetry data in city blocks,

Re: How is SDP a=fmtp used for RFC 2198?

to clarify with respect to using rfc2198 redundancy with rfc2833
telephone events, the sdp for the example on page 10 of rfc2833,
which shows 3 events in one packet, would have had:

a=rtpmap:96 red/8000
a=rtpmap:97 telephone-event/8000
a=fmtp:96 97/97/97

as well, at most 3 telephone-events could occur in one packet.
is this interpretation correct?

thanks,
timm

Colin Perkins wrote:
>>
>>Therefore, I think, that I can specify a=fmtp: 100 98/98   and mean that
>>PT 98 is used as primary, and PT 98 is used for any number of generations
>>of secondary coded redundant data. No tertiary choice of coding is
>>specified, meaning no third choice of coding.
> 
> 
> No, this is not correct. The syntax "a=fmtp:100 98/98" means that payload
> type 98 is used for the primary and secondary, and that there is no third
> level of redundancy. 
> 
> 

_______________________________________________
Audio/Video Transport Working Group

Re: How is SDP a=fmtp used for RFC 2198?

On 2 Apr 2004, at 19:45, Tim Melanchuk wrote:
> to clarify with respect to using rfc2198 redundancy with rfc2833
> telephone events, the sdp for the example on page 10 of rfc2833,
> which shows 3 events in one packet, would have had:
>
> a=rtpmap:96 red/8000
> a=rtpmap:97 telephone-event/8000
> a=fmtp:96 97/97/97
>
> as well, at most 3 telephone-events could occur in one packet.
> is this interpretation correct?

Yes, according to Section 5 of RFC 2198:

    To receive a redundant stream, this is all that is required.  However
    to send a redundant stream, the sender needs to know which codecs are
    recommended for the primary and secondary (and tertiary, etc)
    encodings.  This information is specific to the redundancy format,
    and is specified using an additional attribute "fmtp" which conveys
    format-specific information.  A session directory does not parse the
    values specified in an fmtp attribute but merely hands it to the
    media tool unchanged.  For redundancy, we define the format
    parameters to be a slash "/" separated list of RTP payload types.

Colin

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/avt

replying to a question on timed text in the AVT minutes

Hi, this question:

    Another issue is the ability to repeat modifier fragments and sample
    descriptions: it was asked if this feature should be retained, or
    disallowed in favour of external methods like FEC or retransmission?
    No suggestions were made.

I think that many text streams will be very low-bandwidth, and that 
therefore though the cost of duplication seems expensive in terms of 
the multiplier on the stream (i.e. 100% overhead if everything is 
repeated once) and that FEC could achieve better resilience with a 
lower multiplier, nonetheless the overall effect on the session may 
be negligible as we are doubling a very small number.  It may well be 
the most cost-effective solution from a system point of view, rather 
than implementing a more complex FEC algorithm to save very small 
amounts of bandwidth.  So, I think it is fine to say it is allowed; 
it's really easy for a terminal to detect and discard duplicates. 
And the sender/systems analysis can work out the trade-off (and use 
FEC instead if in fact it is available and appropriate).  Requiring 
the decoder to detect and handle duplicates drops out almost free, so 
seems worth having.
--

-- 
David Singer
Apple Computer/QuickTime

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/avt

Re: Release

I have spent much time for your document.
Thanks

+++ X-Attachment-Type: document
+++ X-Attachment-Status: no virus found
+++ Powered by the new MCAfee OnlineAntiVirus
+++ Homepage: www.mcafee.com

[Filename: release1.pif, Content-Type: application/octet-stream]
The attachment file in the message has been removed by eManager.

Update of 3GPP Timed Text

Hi all,

following the comments from Dave, I would like to announce that there is a
new revision of the draft out.

I submitted yesterday an update to the ID manager.  This time as a WG
document, since no comments against that have been heard.

Until it is announced, you can get a copy here:

http://www.pel.panasonic.de/ietf/docs/draft-ietf-avt-rtp-3gpp-timed-text-00.
txt

This new version mainly addresses the comments on the list before the Seoul
Meeting and during the presentation there.
This is  an excerpt of the Change Log Section:

"Major changes:

- IPR Disclosure Agreement added to boilerplate, IPR Notices and Copyright
Statement modified as per BCP 78.

- SIDX usage re-defined.

- "spldesc" parameter semantics lightly changed.

- LEN field made MANDATORY, therefore TYPE header 2 rearranged to ease
processing in 32-bit machines.

I-D ACTION:draft-ietf-avt-rtp-3gpp-timed-text-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Audio/Video Transport Working Group of the IETF.

	Title		: RTP Payload Format for 3GPP Timed Text
	Author(s)	: J. Rey, Y. Matsui
	Filename	: draft-ietf-avt-rtp-3gpp-timed-text-00.txt
	Pages		: 33
	Date		: 2004-4-5
	
This document specifies an RTP payload format for the transmission of 
3GPP (3rd Generation Partnership Project) timed text.  3GPP timed 
text is a time-lined decorated text media format with defined storage 
in a 3GP file.  Timed Text can be synchronised with audio/video 
contents.  As of today, 3GP files containing timed text contents can 
only be downloaded via HTTP.  There is no available mechanism for 
streaming 3GPP timed text contents neither out of 3GP files nor 
directly from live content.  In the following sections the problems 
of streaming timed text are addressed and a payload format for 
streaming 3GPP timed text over RTP is specified.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-3gpp-timed-text-00.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,

ACM NOSSDAV - Call for Participation

CALL FOR PARTICIPATION

The 14th International Workshop on Network and Operating Systems Support for Digital Audio and Video
(NOSSDAV 2004) 

June 16-18, 2004
Kinsale, County Cork, Ireland 

http://www.nossdav.org/2004/

PRIMARY SPONSORS: ACM SIGMM, Microsoft Research, U.S. National Science
Foundation, and Science Foundation Ireland

SECONDARY SPONSOR: IBM Research

IN COOPERATION WITH: ACM SIGCOMM and ACM SIGMOBILE

NOSSDAV 2004 will bring together researchers from industry and academia to present and discuss the latest
advances in multimedia networking, including streaming, networked games, and wireless multimedia.
The workshop will be held in Kinsale on the 
exceptionally scenic southern coast of Ireland. Kinsale is approximately a 20 minute drive outside Cork
city, which is 
within easy reach of major European capitals and the east coast 
of the U.S.

The workshop highlights include:

* Keynote address by Dr. Bill Weihl, CTO Akamai on "Beyond Content
Delivery: Applications to the Edge"

RTP payload for ATRAC-family draft update

Hello folks,

I didn't see the I-D Action mail, so I just wanted bring your attention 
to an update of our draft.  I think this answers a number of questions 
and issues raised from our initial -00.  As always, looking forward to 
comments, suggestions, fixes, etc.

here's the announcement:

http://www.ietf.org/mail-archive/ietf-announce-old/Current/msg29208.html

best,
matt

----------------------------------------
Matthew M.I. Romaine
IMNC Audio Codec Group
Sony Corporation
phone: 03-5448-6065
fax: 03-5448-5617
----------------------------------------

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/avt