Subject: [avtext] Proceedings from AVTEXT session in Quebec

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sat, 27 Aug 2011 00:11:32 +0200

(As WG cochair)

Somewhat late here follows the proceedings text for AVTEXT in Quebec. They are also at:

https://datatracker.ietf.org/meeting/81/materials.html 

My thanks to the note takers Bill ver Steeg, Brian Rosen, and Stephen Botzko.

Any comments to the list.

Regards

Keith

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

Audio/Video Transport Extensions (avtext) working group
=================================================

WEDNESDAY, July 27, 2011
1510-1610  Afternoon Session II
205 ABC

Chaired by Keith Drage and Magnus Westerlund
Notes taken by Bill ver Steeg, Brian Rosen, and Stephen Botzko
Jabber scribe was Jonathan Lennox

Agenda Bash and Status
-----------------------------
Led by WG chairs
[Slides avtext-0]
Datatracker, current status, document status from slides
The chairs identified that we need reviewers for draft-ietf-avtext-rams-scenarios-00. Roni and Bill VerSteeg volunteer

Presentation of issues of PAYLOAD working group
------------------------------------------------------------
Led by Roni Even
[Slides avtext-4, avtext-5]

Send comments to payload list, not avtext list. Proceedings will appear as part of AVTEXT session.

Magnus owns the "how to write a payload" document
Glen: What are we doing about G718? comments about adding stuff from ITU and other stuff
Roni: need to ask ITU-T about updates, Roni will send questions to ITU-T
Ali: exchanged a few emails with current authors, one has left the company, questions to ITU pending
Volunteers requested to edit docs on XRBlock/monitoring
Glen Zorn - volunteers to edit documents for XR blocks or other documents

G711.0
Michael Ramhalo presenting
Need more information on G711.0 compression segments, and need to decide if it should be part of the payload specification.
author maintains that SDP signalling might not be required.
need the two use cases described (presently unspecified magic).
Roni: need to have a way to negotiate the behavior
Michael: in band and out of band
Magnus: Need to have a payload type that says G711.0. Between the compressor and decompressor, that's it.
Michael: PCMU and PCMA have distinct payloads
Roni: Depends on behaviour in the end or in the middle. Payload type is awareness. May have other ways to do signalling unaware cases.
Michael: current location in unspecified
Jonathan: need to distinct PTs for .0 and .1 - the SDP generator needs to know the payload type in an unambiguous manner. If we need two payload types, no problem.  PT=Q is okay. May need an "antipayload" type signal from endpoints (payload types I promise not to use).
Hadriel: Endpoints are not going to say what they are not going to use in the future.  Middlebox transcoding already can be done (like 729-711-729) - this is just normal SDP, with G711 as the codec, this is the same as this case, there is nothing to talk about.
Michael: This is lossless.  That makes it different.
Hadriel Kaplan: any piece of work on SDP messing around doesn't belong in a payload type draft.
Michael: Will take this to the list, and include mmusic guys in the discussion.

Actions: more discussion on the list (PAYLOAD list)
Open question on whether to split out the compression segment from the payload draft.

Audio Levels
---------------
Led by Emil Ivov / Jonathan Lennox
draft-ietf-avtext-client-to-mixer-audio-level-03
draft-ietf-avtext-mixer-to-client-audio-level-03
[slides avtext-1]

Discussing VAD support, signal in V, add a bit, redefine V.
Bill: Are bits so expensive we can't afford another?
Jonathan: some complications involved, it's not just a bit.  
Steve: Advantage of signaling is middle boxes can mess with it
Magnus: signal the support / lack of support of V bit so that middleboxes can do the right thing.
Stefan: Is there value in sending levels when there is no voice?  if not, send a recognized pattern
Jonathan: sometimes a "no voice" indicator is useful for deciding what to play in the absence of voice. Yes, sometimes sending background is good
Stefan: could use state tracking and more complication
Cullen: make a choice
Bill: Send it in the SDP, then do the best you can - VAD set to 1 if you can't tell

Chairs: who objects to signaling in SDP
<<no hands>>

Action: - put in signaling to indicate VAD support (or lack of) in SDP.  MMUSIC will need to review.

Drafts will shortly move to publication request (when new version issued and after short review of new SDP by MMUSIC).

Splicing
---------
led by Jinwei Xia
draft-xia-avtext-splicing-for-rtp-00
[slides avtext-2]

Chairs: Anyone object to using mixer approach for user detectable case?
<<no hands>>
Chairs: Who objects to mixer soln for non-user detectable case
Colin: We talked about open mixer and translator on the list, I prefer the translator, but mixer/translator is OK as long as the requirements have commonality.
<<no hands>>
Conclusion: Majority of WG prefers the RTP mixer approach for user-detectable case.
Recommendation: use RTP mixer for all cases for simplicity.
Consensus confirmed in room (no objections): Mixer to be specified in both user detectable case and non-detectable case as well.
Confirmation on the mailing list will be solicited.

IEEE 1588/802.1AS Synchronisation for RTP Streams
---------------------------------------------------------------
Aidan Williams was ill and not able to be present in Quebec, and not able to address this draft.
draft-williams-avtext-avbsync-01
[slides avtext-3]

  - is this in scope
  - what are the issues with working on this
  - interest to the list

Chairs:  Is work in scope, what are the issues, is there any interest?
Colin: is this like existing methods?
Magnus: More like NTP providing a base clock. We also already have the RTCP packet registered at IEEE.
Colin: Not completely unreasonable? Would be interested to see in more details.
Chairs: Do we make this a WG item, or have some f2f in Taipei before we ask that?
<<not much response>>

Does this need face-to-face time, or should this be on the list?
Action - try to close on the list.

Not discussed
----------------
The following documents were not separately discussed although comments are always welcome on the mailing list. 

draft-ietf-avtext-multiple-clock-rates-01
draft-ietf-avtext-rams-scenarios-00

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