AVTEXT ====== Thursday 17:30 - 18:30 Chairs: Keith Drage Magnus Westerlund Agenda bash and status check ---------------------------- Slides: http://www.ietf.org/proceedings/84/slides/slides-84-avtext-0.ppt Status RFC 6659 (Deploying RAMS) has been published. splicing http://www.ietf.org/id/draft-ietf-avtext-splicing-for-rtp-08.txt - Significant comments from IESG review - Will require additional review - Document will undergo another WGLC before resubmission to IESG - Keith Drage is currently performing a readability review duplicating RTP streams http://www.ietf.org/id/draft-ietf-avtext-rtp-duplication-00.txt Chairs Support for Multiple Clock Rates in an RTP Session -------------------------------------------------- http://www.ietf.org/id/draft-ietf-avtext-multiple-clock-rates-05.txt Glenn Zorn Slides: http://www.ietf.org/proceedings/84/slides/slides-84-avtext-3.ppt - Editor (Glen Zorn) requesting additional group review commentary so it can be taken to WGLC - Right now only Magnus has provided comments - Jonathan Lennox volunteered to review Document went through WGLC, no response on comments (apart from editor). Needs more reviews and discussion on the list RTP Media Stream Pause and Resume --------------------------------- http://www.ietf.org/id/draft-westerlund-avtext-rtp-stream-pause-02.txt Bo Burman Slides: http://www.ietf.org/proceedings/84/slides/slides-84-avtext-1.ppt IPR disclosure has been made on draft Author requests WG review of proposed solution with intent to be considered for WG adoption Author presented draft and motivation for draft Roni: Why do you need sender to indicate that it stopped sending? Bo: Can be used by explicit indication as an ACK Roni: Wouldn't you receive this also from SR Bo: The pause indication can be send for longer period of time (instead of just once with SR) Magnus: In addition, can be faster than SR, you get an immediate response, where SR could take some time. Roni: If the pause packet is part of the same compound packet, it does not matter Mo Zanaty: Can also be used for intermediate nodes, such as mixers Mo: What is difference from TMMBR/TMMBN, not clear from draft? -> Explained in later slides Ali: From where do you resume? Magnus: This is not used for trick play, aimed at live sources. All data between pause and resume is 'lost' Ali: What is the relevance to multicast? Bo: Should work reasonably well Bo presents rationale for sending pause request through RTCP instead of SDP Roni: What is the assumption on the SIP bandwidth constraints? Bo: Unconstrained Mo: Scalability of servers is important aspect in case of SIP, I support RTCP approach Hadriel Kaplan: If you pause a stream, middle boxes who no longer receive RTCP may stop stream Bo: Old-boxes may indeed be problematic Charles Eckel: You need keep-alive anyway to keep ports open Magnus: In some cases you only pause some streams, so there is still data flowing Ray: What is impact on scheduled RTCP traffic (SR/RR/XR)? Bo: No impact (keeps flowing) Keith mentioned that case of media stream in low power state was not considered Justin: How does this compare to CLUE work on selecting which streams should be sent (and which parameters)? Jonathan: There is a related draft, particularly dealing with the parameters. So I think there is at least some overlap, but not contradictory Justin: Question is whether you want to do this on the media plane or on the signalling plane Keith: Question is whether you want to do this on the media plane _as well_ Stephen: CLUE doesn't include any pausing functionality Jonathan: Stopping a stream is similar to pausing it Roni: Another alternative here would be the CLUE signalling message Roni: You mentioned earlier that your proposal works reasonably for multicast, wouldn't it be better to just describe pause functionality in terms of TMMBR (in that draft) instead of creating new functionality for something that is already possible. Roni reports that we already have a solution in the signaling plane Jonathan Lennox states that CLUE framework doesn't fully cover this solution Roni Even mentions that this solution is not working well with Multicast whereas CCM TMMBR does Mo: We are just discussing encoding here, the semantics between this proposal and TMMBR are similar. Magnus: We might not agree now on updating TMMBR versus doing it like this, but we can at least agree that we want to do something for pause/resume Mo: I agree with Magnus that we want to do something, since there is currently no standardized method Roni: I think we already agree that we want to solve it, we just need to agree on how Magnus: So those who want to go for the TMMBR approach, need to write a draft on that Roni agreed to this Keith Drage as Chair: How many people that RTCP is appropriate for this mechanism? Rough consensus that RTCP is appropriate ** Keith (as chair) indicates working group has interest in having a media plane solution but a competing draft is in order Keith (as Chair): OK, so we will defer this discussion until we have more (alternative) proposals. RTCP SDES Item SRCNAME to Label Individual Sources -------------------------------------------------- http://www.ietf.org/id/draft-westerlund-avtext-rtcp-sdes-srcname-01.txt Bo Burman Slides: http://www.ietf.org/proceedings/84/slides/slides-84-avtext-2.ppt There was no time for the final presentation. Keith (as Chair): We will put a notice on the list regarding the fact that we didn't have time for the SRCNAME proposal today, requesting comments