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 <> 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? <> 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. <> 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? <> 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