Subject: [AVT] Meeting in San Francisco

From: Colin Perkins <[email-masked]>
Date: Mon, 10 Feb 2003 09:42:34 -0500

The AVT working group is scheduled for two slots at the 56th IETF meeting
in San Francisco. On the tentative agenda, these are from 9:00 to 11:30am
on Tuesday 18th March, and 1:00 to 3:00pm on Wednesday 19th March. These
dates are subject to change - DO NOT USE THEM TO PLAN TRAVEL.

Those wanting agenda time at the meeting should contact the working group
chairs by 3rd March. Submitting a draft does not automatically provide
agenda time. 

You are reminded that the cut-off date for -00 Internet Draft submissions
is Monday, 24th February at 9:00am EST (GMT -05:00). Unless you have prior
approval from the chairs, -00 submissions should have filenames with the
format draft-yourname-avt-...-00.txt. Be advised that updates to -00 drafts
received after 24th February will not be accepted. 

All other Internet-Draft submissions must be made by Monday, 3rd March at
9:00am EST.

Drafts which are submitted late and do not make the cutoff date will not be
discussed at the meeting.

-- 
Colin Perkins
http://csperkins.org/
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: "LIM, Young-Kwon" <[email-masked]>
Date: Fri, 14 Feb 2003 13:15:10 +0900

Hi Colin and all,

Could you inform me about the current status of mpeg4-simple payload format in IETF? I remeber that there was a revision for IESG last call a few months ago? Do you expect that there will be a call very soon? Are there any remaining issues need another revision?

Sincerely,
Young.

---

From: Colin Perkins <[email-masked]>
Date: Fri, 21 Feb 2003 10:24:22 -0500

A reminder that the submission deadline for -00 internet-drafts is 9:00am
EST (GMT -05:00) on Monday.

Colin

---

From: Colin Perkins <[email-masked]>
Date: Mon, 24 Feb 2003 11:01:00 -0500

Folks,

The submission deadline for -00 drafts has now passed. Other drafts are due
one week from today. If you have submitted a draft, and need agenda time to
discuss it, you should contact the working group chairs. 

We currently have agenda requests for the following:

  RTP Extended Reports (RTP XR) 			   (Friedman/Clark)
  Framing RTP over Connection-Oriented Transport 	   (Lazzaro)
  The MIDI Wire Protocol Packetization (MWPP) 		   (Lazzaro)
  RTP Payload Format for iLBC Speech 			   (Duric) 
  RTP payload format for a 64 kbit/s voice band data call  (Kreuter)
  RTP Payload Format for the Speex Codec 		   (Herlien)
  
Colin

---

From: "Jim Fleming" <[email-masked]>
Date: Mon, 24 Feb 2003 10:10:17 -0600

Working code appears to be more useful than meetings of the I* society...
http://lists.digium.com/pipermail/asterisk-users/2003-February/007532.html

Jim Fleming
http://IPv8.vrx.net

---

From: Greg Herlein <[email-masked]>
Date: Mon, 24 Feb 2003 08:55:17 -0800 (PST)

> http://lists.digium.com/pipermail/asterisk-users/2003-February/007532.html

Well, I might as well introduce myself on this list by
disagreeing.  :)  

Your link discusses Asterisk's non-standard implementation of the
use of Speex in RTP.  It may be working code for asterisk, but it
can't talk to anything else.  In fact, it may work for Asterisk,
but since it does not do dyunamic payload types, it can't talk to
much of anything else.

Currently, Speex is trying to finalize a draft profile for use in
RTP.  Currently, there is interoperability between gnomemeeting
and ohphone, for example, but only because both use the OpenH323
implementation of speex.  Linphone can talk to other linphone
apps, but I don't know of any other SIP-based apps that have
implemented libspeex.  We do have a draft that we just submitted
that should make interoperability possible.

Getting to where we are has been a lot of hours spent emailing
between the primary authors of the above apps to get everyone to
agree.  I'd rather not repeat that when the next VoIP app comes
along and wants to play.  I'd rather say "go read the RFC."

Now, if like Asterisk, they chose to not even follow the basic
rules, that't their issue.

The objective of these meetings is to get specs to a point where
there is hope for interoperable implementations.  Working code is
easy - any fool programmer can do that.  Getting that code to
interoperate with other implementations is much harder.

Greg

---

From: "Jim Fleming" <[email-masked]>
Date: Mon, 24 Feb 2003 11:03:19 -0600

----- Original Message -----
From: "Greg Herlein" <[email-masked]>
> along and wants to play.  I'd rather say "go read the RFC."

Was NAT developed that way ?

https://www1.ietf.org/mail-archive/working-groups/ipr-wg/current/msg00613.html
From: Brian E Carpenter <[email-masked]>
This is exactly why we evolved the current IETF policy, and why it works
(and has not stopped the open source community from flourishing in
a world that runs on IETF protocols).
========

A few facts....

1. The 160-bit Internet Protocol header, is basically a Uni* O/S data structure.
2. The Uni* O/S existed long before the IETF, the ISOC and the I* society. (small s...aka the Big Lie Society)
3. Open Source has been the basis for Uni* O/S development since the 1970's.
4. IBM was never an advocate of that movement or a major contributor.
5. As for protocols, some of the major ones that the average netizen views as "the Net", were not invented, developed, etc. by the
IETF, which is described as an activity of the ISOC.

==== Quotes to consider =====
http://www.spectrum.ieee.org/select/1098/int.html
NATs are a no-no
HEATH: I was going to say that IEEE Spectrum should make it very clear that this group's consensus would appear to be: let's
discourage NATs--I mean the manufacture of them at all--because there is a real need for IPv6.

HUITEMA: It's more than that. There is a real need for security and you can't have security with NATs.

CERF: NAT is a guaranteed spoofing box in effect.
====

http://IPv8.no-ip.com
http://www.go-mono.com/
http://www.knoppix.com
http://www.netfilter.org
http://www.digium.com
http://www.asterisk.org
http://www.openss7.org
http://www.zapatatelephony.org
http://www.new.net
http://IPv8.vrx.net

Jim Fleming
[email-masked] Consultant
http://www.Unir.NET
http://www.Unir.com
http://www.Uni%ae.com
http://www.Uni®.com

---

From: "Michael A. Ramalho" <[email-masked]>
Date: Mon, 24 Feb 2003 12:42:36 -0500

>   RTP Payload Format for the Speex Codec                   (Herlien)

Colin/Steve,

I plan on revving the following drafts to -01:

draft-ramalho-rgl-desc-00.txt and
draft-ramalho-rgl-rtpformat-00.txt

The second (RGL payload format) is a major
re-write/proposal (based primarily on Steve's
feedback).

The first (RGL description) has trivial changes from
the "00" version that were made to more easily
accommodate the new proposed RTP payload
format(s).

I plan to meet the "non-00" deadline for both.

Michael Ramalho

---

From: Colin Perkins <[email-masked]>
Date: Wed, 26 Feb 2003 15:48:20 -0500

>dates are subject to change - DO NOT USE THEM TO PLAN TRAVEL.

Note that the latest version of the agenda has AVT scheduled on Wednesday,
19th March at 13:00-15:00 and Thursday, 20th March at 09:00-11:30.

Colin