[AVT] AVT notes

[Tom Taylor <[e-mail]>]

Here are my notes for this afternoon's AVT session. If people could fill in the 
blanks or make corrections to the list or directly to me, these can be turned 
into minutes.

Tom Taylor

Session 1
Palos Verdes
1300-1500 Wednesday March 24
Roni Even and Keith Drage chairing

Note Well notice presented.

1. Chairs' introduction
=======================
Roni presenting, charts

a. Agenda bashing

No comments.

b. Document status

Comments requested for ecn-for-rtp.

Re EKT: list question, how to use DTLS-SRTP with multicast. Should that be in scope?

No further comments.

2. Restructuring
================
Robert Sparks, chart (part of Chairs' pres)

List comments:
Comments on list don't question core maintenance.
For continuity, payload specs should be WG rather than experts' group.
No comments on XR.
Specific charters for applications like RAMS. Use DISPATCH.

Roni: sees no reason to split AVT core and payload types.
       Participants in XR no longer appear at AVT.
       Fourth item: specifically for RAMS, DISPATCH for other stuff.

Stephan: no need for maintenance -- isn't happening.
       Payload formats the major work of the last few years -- will be permanent,
       should be WG. Amounts to renaming of AVT.
       No support for XR group because of lack of support.
       Payload-independent work can be dealt with anywhere.
       Anything that requires intimate knowledge of payload structure into payload.
       That includes RAMS. Summing up: don't bother changing anything.

Gonzalo: reminiscent of the SIPPING discussion. But that didn't work -- DISPATCH 
has increased energy levels and pace of output.

Roni: RTP payload analogous to SIPCORE.

Cullen: AVT much the largest workload in RAI. How can we split that up?

Stephan: if split, watch the scheduling.

Bill ver Steeg: must be able to call in experts when discussing obscure payload 
types.

Keith: focus on the skills you need to assemble.

Ingmar: 10-15 people are the major contributors on the list.

Stephan: disagrees with Keith. Real problem is that payload contributors are 
drop-in, do their work, disappear. Need continuity, need to retain old hands.

Robert: what would cause the experts to disappear?

Stephan: people interested in the protocol (such as Stephan himself) not 
interested in picky payload issues.

Jabber: (mised)

3. RAMS Draft
==========
Ali Begen, charts.

Noted IPR declarations, objection on the list. No alternative proposals for 
solution. Asked Chair for guidance.
Keith asked if anyone else objected. Sense of the room is that we proceed with 
the work as it is. This will be confirmed on the list.

After presentation:

Roni: reporting on Magnus's comments -- appear to be editorial.
Ali: one more version, then WGLC. Agreed, need to move port mapping along.

Colin P: agreed there are no issues, agree with Magnus that it is not great to 
use RTCP for RTP session management.

4. RTCP Port for SSM Sessions
=============================
Ali Begen, charts

Issue raised by Magnus, SSM (RFC 5760) requires multicast RTCP port to be 
derived from RTP port on m= line. Proposes new attribute to specify RTCP port.

Question: make attribute mandatory for RAMS? Update RFC 5760?
Tom van Caenagem -- make more general -- unicast too.
Magnus: make it applicable for multicast, not specifically SSM.

Chair: room seems to accept need for work. Need to negotiate milestone with ADs.

Robert: still concerned that generalization creates new signalling protocol for 
initiating and controlling sessions, wants to make sure we don't duplicate 
existing capability. (Comment was really about the port mapping draft, next 
agenda item).

5. Port Mapping
===============
Ali Begen, charts

Breakout session yesterday. Cullen Jennings took notes, will send them out to list.

Magnus: note that this is specialized, other cases (unicast retransmission) 
don't need to be covered but should be mentioned.

Tom van Caenagem: can't see what is missing from the RAMS draft.
Keith: document packaging issue.

Consensus: use RTP/RTCP multiplexing.

6. Port Mapping -- Alternative Solution
=======================================
Tom v. Caenagem, charts

Specialized, makes certain assumptions.

Cullen notes that the NATs that are unfavourable to the operation of this 
solution are unfortunately the most common type.

Summation: go with the Begin draft, WGLC when it settles down. Also a 
documentation packaging issue.

7. MPEG2TS Preamble
===================
Tom v Caenagem presenting both drafts. Charts.

Jonathan Lennox: can receiver distinguish between packets subject to preamble 
and others? Roni: yes, provision for that in MPEG-2.

Bill: is syntax of Xia output valid for any decoder? (Ali) Can it be handled by 
third-party set top boxes. Cisco interoperates with nine vendors. Frank Xia: 
answer is yes.

Cullen speaking for Colin Perkins: does the draft always produce a valid MPEG-2 
TS or does it depend on the details of the preamble? Roni: agreed that 
post-processing needed within some boxes, but compliant to reference model.

Bill: are bits on the wire recognizable as valid MPEG-2 TS packets?

Stephan: probably no one complies totally. Quite likely that standard itself is 
ambiguous with respect to compliance. Practical test is what the analyzers and 
chips on the market do? Since both proposals claim interoperability in their own 
environments that is probably all you can ask.

Frank: can demonstrate bit stream compliance.

Eric (Jabber): is PCR found in the preamble.

Roni: discussion not to the point. Point is packaging discussion.

Stephan: way forward: wrong to have group decide now. Could live with both, or 
have shoot-out (interop test. Don't try to decide here and now.

Keith: is the sense of the room that we work for one document, or that we go 
with both solutions or neither.

Roni: need data.

Stephan: strongly supports deferring decision. Likely to have two solutions in 
reality even though IETF chose one. Put the question off.

Keith: continue in next session.