RTP Splicing Status Update draft-ietf-avtext-splicing-for-rtp-11 Jinwei Xia.

Slides:



Advertisements
Similar presentations
Re-INVITE Handling draft-camarillo-sipping-reinvite-00.txt
Advertisements

Content Splicing for RTP Sessions draft-xia-avtext-splicing-for-rtp-00 IETF#80, Mar 2011, Prague Jinwei
Note Well Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made.
Copyright © 2003 Colin Perkins SDP Specification Update Colin Perkins
Session Announcement Protocol Colin Perkins University College London.
IPv6 Mobility David Bush. Correspondent Node Operation DEF: Correspondent node is any node that is trying to communicate with a mobile node. This node.
Long-term Archive Service Requirements draft-ietf-ltans-reqs-00.txt.
Slide #1IETF 77 – Roll WG – March 2010 ROLL RPL IETF 77 status draft-ietf-roll-rpl Tim Winter Pascal Thubert Design Team.
Ch. 28 Q and A IS 333 Spring Q1 Q: What is network latency? 1.Changes in delay and duration of the changes 2.time required to transfer data across.
1 SIPREC Requirements IETF #80 Authors: K. Rehor, A. Hutton, L. Portman, R. Jain, H. Lam.
Request History – Solution Mary Barnes SIP WG Meeting IETF-57 draft-ietf-sip-history-info-00.txt.
1 Chapter06 Mobile IP. 2 Outline What is the problem at the routing layer when Internet hosts move?! Can the problem be solved? What is the standard solution?
SIP working group status Keith Drage, Dean Willis.
March 7, 2005MOBIKE WG, IETF 621 Mobility Protocol Options for IKEv2 (MOPO-IKE) Pasi Eronen.
WG RAQMON Internet-Drafts RMON MIB WG Meeting Washington, Nov. 11, 2004.
Concerns about designating the MAG as a Default Router James Kempf NETLMM Interim Sept. 27, 2006.
1 IPFIX Protocol Specifications IPFIX IETF-59 March 3, 2004 Benoit Claise Mark Fullmer Reinaldo Penno Paul Calato Stewart Bryant Ganesh Sadasivan.
IETF54 Charter Issues Dealt with since IETF53 PANA WG Meeting Basavaraj Patil.
DIME WG IETF 82 Dime WG Agenda & Status THURSDAY, November 17, 2011 Jouni Korhonen & Lionel Morand.
MPTCP – MULTIPATH TCP Interim meeting #3 20 th October 2011 audio Yoshifumi Nishida Philip Eardley.
T-MPLS Update (abridged) IETF70 December 2007 Stewart Bryant
XCON WG IETF-73 Meeting Instant Messaging Sessions with a Centralized Conferencing (XCON) System draft-boulton-xcon-session-chat-02 Authors: Chris Boulton.
DCCP, TFRC & Open Problems in Congestion Control for Media Applications Tom Phelan 13-Feb-2007 ICCRG.
1 Virtual Router Redundancy Protocol (VRRP) San Francisco IETF VRRP Working Group March 2003 San Francisco IETF Mukesh Gupta / Nokia Chair.
SIPREC draft-ietf-siprec-req-00 Requirements for Media Recording using SIP Draft authors: K. Rehor, A. Hutton, L. Portman, R. Jain, H. Lum IETF 78 Ken.
Node Information Queries July 2002 Yokohama IETF Bob Hinden / Nokia.
SIPREC draft-ietf-siprec-req-05 Requirements for Media Recording using SIP Draft authors: K. Rehor, A. Hutton, L. Portman, R. Jain, H. Lum IETF 79.1 Interim.
SIP working group IETF#70 Essential corrections Keith Drage.
Guidelines for Cryptographic Algorithm Agility Russ Housley IETF 89 - SAAG Session.
CONEX BoF. Welcome to CONEX! Chairs: –Leslie Daigle –Philip Eardley Scribe Note well.
Audio/Video Transport Core Maintenance Working Group Magnus Westerlund Roni Even Jabber room:
CSE5803 Advanced Internet Protocols and Applications (14) Introduction Developed in recent years, for low cost phone calls (long distance in particular).
Page 1 IETF Speermint Working Group Speermint Requirements/Guidelines for SIP session peering draft-ietf-speermint-requirements-02 IETF 69 - Monday July.
SonOf3039 Status Russ Housley Security Area Director.
Magnus Westerlund 1 The RTSP Core specification draft-ietf-mmusic-rfc2326bis-06.txt Magnus Westerlund Aravind Narasimhan Rob Lanphier Anup Rao Henning.
IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: Security Problems related to Transition Date Submitted: January.
Open issues from SIP list Jonathan Rosenberg dynamicsoft.
Slide title In CAPITALS 50 pt Slide subtitle 32 pt RTSP draft-ietf-mmusic-rfc2396bis-10 Magnus Westerlund Co-auhtors: Henning Schulzrinne, Rob Lanphier,
Requirements and Selection Process for RADIUS Crypto-Agility December 5, 2007 David B. Nelson IETF 70 Vancouver, BC.
1 Header Compression over IPsec (HCoIPsec) Emre Ertekin, Christos Christou, Rohan Jasani {
NEMO Basic Support update IETF 61. Status IANA assignments done Very close to AUTH48 call Some issues raised recently We need to figure out if we want.
Indication of Terminated Dialog draft-holmberg-sipping txt Christer Holmberg NomadicLab Ericsson.
BSR Spec Status BSR Spec authors 03/06. Status ID refreshed (now rev-07) Resolved remaining issues we had on our list Updated to reflect WG
Uni Innsbruck Informatik th IETF, PMTUD WG: Path MTU Discovery Using Options draft-welzl-pmtud-options-01.txt Michael Welzl
RTP Usage for CLUE draft-lennox-clue-rtp-usage-02 Clue WG, IETF 83, 27 March 2012 Jonathan Lennox Allyn Romanow
OSPF WG Security Extensions for OSPFv2 when using Manual Keying Manav Bhatia, Alcatel-Lucent Sam Hartman, Huawei Dacheng Zhang, Huawei IETF 80, Prague.
RTP Functionalities for RTCWEB A combined view from the authors of draft-cbran-rtcweb-media-00 draft-cbran-rtcweb-media-00 draft-perkins-rtcweb-rtp-usage-02.
Netconf Schema Query Mark Scott IETF 70 Vancouver December 2007
IETF 52 nd Meeting December 2001draft-charlton-deaf-req-00.txt User Requirements for SIP in support of deaf, hard of hearing and speech- impaired individuals.
K. Salah1 Security Protocols in the Internet IPSec.
PMIPv6 multicast handover optimization by the Subscription Information Acquisition through the LMA (SIAL) Luis M. Contreras Telefónica I+D Carlos J. Bernardos.
EAP WG EAP Key Management Framework Draft-ietf-eap-keying-05.txt Bernard Aboba Microsoft IETF 62, Minneapolis, MN.
SDP Security Descriptions for Media Streams draft-ietf-mmusic-sdescriptions-02.txt November 14, 2003 Flemming Andreasen Mark Baugher.
CLUE Framework IETF 88 – Nov 8, 2013 Mark Duckworth draft-ietf-clue-framework-12 draft-groves-clue-multi-content-00 draft-duckworth-clue-switching-example-01.
Codec Control for RTCWEB
Mobile IP.
Managed Objects for Packet Sampling
Request History Capability – Requirements & Solution
IP Router-Alert Considerations and usage
IETF 78 Ken Rehor on behalf of the team
Note Well Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made.
In-Band Authentication Extension for Protocol Independent Multicast (PIM) draft-bhatia-zhang-pim-auth-extension-00 Manav Bhatia
Les Ginsberg Stefano Previdi Peter Psenak Martin Pilka
IKEv2 Mobility and Multihoming Protocol (MOBIKE)
CONEX BoF.
ECN Experimentation draft-black-ecn-experimentation
Jul 12, /12/10 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: Frame signaling options for Security.
PW Control Word Stitching
BPSec: AD Review Comments and Responses
Guidelines for using the Multiplexing Features of RTP to Support Multiple Media Streams draft-ietf-avtcore-multiplex-guidelines-06 Magnus.
Presentation transcript:

RTP Splicing Status Update draft-ietf-avtext-splicing-for-rtp-11 Jinwei Xia

Status Documents second IESG telechat on the 11 th of October IESG raised some remaining issues Two draft updates have been submitted since then (version 10 and 11) to resolve issues This solved all but two issues. IETF 85 - AVTEXTdraft-ietf-avtext-splicing-for-rtp-112

Stewart Bryant Discuss on RTP Payload security mechanism text. The text indicated that this was not compatible with splicing point indication based on RTP payload content – Misunderstood at first to refer to security contexts NEW Text proposal: – Some RTP deployments uses RTP payload security mechanisms (e.g., ISMACryp [ISMACryp]). If any payload internal security mechanisms are used, only the RTP sender and the RTP receiver establishes that security context, in which case, any middlebox (e.g., splicer) between the RTP sender and the RTP receiver will not get such keying material. This may impact the splicers's possibility to perform splicing if it is dependent on RTP payload level hints for finding the splice in and out points. However, other potential solutions exist to specify or mark where the splicing points exist in the media streams. When using RTP payload security mechanisms SRTP or other security mechanism at RTP or lower layers can be used to provide integrity and source authentication between the splicer and the RTP receiver. IETF 85 - AVTEXTdraft-ietf-avtext-splicing-for-rtp-113

Pete Resnick’s Issue One REQ-7: There at least needs to be a forward reference to section 4.5 in this section. That said, I am still bothered by this section. The first sentence is written in the passive voice, so I can't tell what it's saying: Is it saying that splicing should not be easily detected *by the RTP receiving implementation* (in which case section 4.5 is really all that this is talking about), or is it saying that splicing should not be easily detected *by the RTP stream end-user* (in which case it's talking about section 4.3, which I think is bogus)? The second half of REQ-7 talks about both, but then goes on to say that this memo is only concerned with the RTP layer. Please rewrite this section to make it clear that you are only talking about the protocol, not the user experience. – Clarified to be RTP level only – Wording was a bit unclear, new text prepared IETF 85 - AVTEXTdraft-ietf-avtext-splicing-for-rtp-114

Issue One Proposed Text REQ-7: – The RTP receiver should not be able to detect any splicing points in the RTP stream produced by the splicer on RTP protocol level. For the advertisement insertion use case, it is important to make it difficult for the RTP receiver to detect where an advertisement insertion is starting or ending from the RTP packets, and thus avoiding the RTP receiver from filtering out the advertisement content. This memo only focuses on making the splicing undetectable at the RTP layer. The corresponding processing is depicted in section 4.5. IETF 85 - AVTEXTdraft-ietf-avtext-splicing-for-rtp-115

Pete Resnick’s Issue Two Section 4.3: Similar to the above, this is really all user experience, not protocol clipping. I think this section should simply be dropped. Section 4.5: "User Invisibility" is not the requirement in 4.5; it is "Receiving implementation invisibility.“ – First of all it has been clarified that it is not about implementation invisibility – Secondly I have proposed rewording of the text to use other terminology and focus on possible implementation issues. IETF 85 - AVTEXTdraft-ietf-avtext-splicing-for-rtp-116

Issue Two Proposed Text 4.3. Considerations for Handling Media Substitution at the RTP Layer This section provides informative guidelines on how to handle media substitution at both the RTP layer to minimize media impact. Dealing with the media substitution well at the RTP layer is necessary for quality implementations. To perfectly erase any media impact needs more considerations at the higher layers, how the media substitution is erased at the higher layers are outside of the scope of this memo. IETF 85 - AVTEXTdraft-ietf-avtext-splicing-for-rtp-117

Issue Two Proposed Text If the time duration for any substitutive content mismatches, i.e. shorter or longer, than the duration of the main content to be replaced, then media degradations may occur at the splicing point and thus impact the user's experience. If the substitutive content has shorter duration from the main content, then there could be a gap in the output RTP stream. The RTP sequence number will be contiguous across this gap, but there will be an unexpected jump in the RTP timestamp. Such a gap would cause the receiver to have nothing to play. This may be unavoidable, unless the mixer can adjusts the splice in or splice out point to compensate. This assumes the splicing mixer can send more of the main RTP stream in place of the shorter substitutive stream, or vary the length of the substitutive content. It is the responsibility of the higher layer protocols and the media providers to ensure that the substitutive content is of very similar duration as the main content to be replaced. IETF 85 - AVTEXTdraft-ietf-avtext-splicing-for-rtp-118

Issue Two Proposed Text If the substitute content have a duration longer than the reserved gap duration, there will be an overlap between the substitutive RTP stream and the main RTP stream at the splicing out point. A straightforward approach is that the mixer performs an ungraceful action, terminating the splicing and switching back to main RTP stream even if this may cause media stuttering on receiver. Alternatively, the mixer may transcode the substitutive content to play at a faster rate than normal, to adjust it to the length of the gap in the main content, and generate a new RTP stream for the transcoded content. This is a complex operation, and very specific to the content and media codec used. Additional approaches exists, these type of issues should be taken into account in both mixer implementors and media generators to enable smooth substitutions. IETF 85 - AVTEXTdraft-ietf-avtext-splicing-for-rtp-119

Pete Resnick’s Issue Three Section 4.5 does not address user experience invisibility and should be re-titled. – Resolved by v11 text IETF 85 - AVTEXTdraft-ietf-avtext-splicing-for-rtp-1110

Next Steps Awaiting confirmation from ADs on new text resolving issues New draft will be submitted when above completed 1 Week WG last call on changes If all Ok, then AD approves publication IETF 85 - AVTEXTdraft-ietf-avtext-splicing-for-rtp-1111