From petithug@acm.org Sun May 1 12:14:04 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7217CE06A0 for ; Sun, 1 May 2011 12:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.065 X-Spam-Level: X-Spam-Status: No, score=-101.065 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98CTaDRAf0kC for ; Sun, 1 May 2011 12:14:03 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by ietfa.amsl.com (Postfix) with ESMTP id C06A8E0674 for ; Sun, 1 May 2011 12:14:00 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 51A36DBCC044; Sun, 1 May 2011 19:13:59 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id A573E6C984C6 for ; Sun, 1 May 2011 19:13:58 +0000 (UTC) Message-ID: <4DBDB0F5.8060001@acm.org> Date: Sun, 01 May 2011 12:13:57 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110402 Iceowl/1.0b2 Icedove/3.1.9 MIME-Version: 1.0 To: "avtext@ietf.org" X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [avtext] draft-petithuguenin-avtext-multiple-clock-rates-01 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2011 19:14:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I just published a new version of the draft, which now use the formulas provided by Magnus: http://tools.ietf.org/html/draft-petithuguenin-avtext-multiple-clock-rates-01 As discussed in the meeting in Prague, I am now proposing this draft to be adopted as the WG document for the "Submit Support for multiple clock rates in an RTP session for Proposed Standard" milestone. Changelog: o Clarified the goals for this documents o Removed the non-monotonic method (replaced by Magnus formula). o Moved the "RTP Sender and RTP Receiver section inside a new "Recommendations" section. o Inserted the new Sender formula inside the Recommendation section. o Inserted the new jitter formula in the RTP Receiver section. o Emptied the Analysis sections. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk29sPQACgkQ9RoMZyVa61fRZwCfSg8+VjUJgJrQ/Vqdz59SwICu cSYAn2R52s1ssTNeR4lhZd9hOCN0nC7c =hExm -----END PGP SIGNATURE----- From abegen@cisco.com Sun May 1 12:46:04 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F793E06B8 for ; Sun, 1 May 2011 12:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.591 X-Spam-Level: X-Spam-Status: No, score=-10.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIO9SaLtHWV7 for ; Sun, 1 May 2011 12:46:03 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 63E35E0674 for ; Sun, 1 May 2011 12:46:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=6237; q=dns/txt; s=iport; t=1304279163; x=1305488763; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=gzmvQMw3B3hv66jmb5vxt227VFTz43YL9/DlYuZ1TfQ=; b=YaIPLuFRIi8HZ7Dljgh6sxxD0DJFP3fFjMyv2NvRPRS+x/zOruexDmfw 4LE6m0ZBMrlc52KPB7tkRCXEDK7YmRR6YRSky6AWkvwSw6PdSZULS6GhR 0D/S5Gr9A5XpVAz1LnFa6mqjjXrC2HecpQm16+RLPcmqqn9Xq870YvbvU s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIBAKK3vU2rRDoH/2dsb2JhbACYFo4Gd4hxnUabLoMFgnsEhg6NDYog X-IronPort-AV: E=Sophos;i="4.64,299,1301875200"; d="scan'208";a="348226439" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-2.cisco.com with ESMTP; 01 May 2011 19:46:03 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p41Jk32u026806; Sun, 1 May 2011 19:46:03 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 1 May 2011 12:46:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Sun, 1 May 2011 12:45:43 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540EEAAB8D@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-begen-avtext-rams-scenarios-00 : comments Thread-Index: Acv+rFXn1hPrCpaDTOyQVQL/SJRGtABlhkRA References: From: "Ali C. Begen (abegen)" To: "Van Caenegem, Tom (Tom)" , X-OriginalArrivalTime: 01 May 2011 19:46:03.0133 (UTC) FILETIME=[674F1AD0:01CC0838] Subject: Re: [avtext] draft-begen-avtext-rams-scenarios-00 : comments X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2011 19:46:04 -0000 Hi Tom, Thanks for the review.=20 > -----Original Message----- > From: Van Caenegem, Tom (Tom) = [mailto:tom.van_caenegem@alcatel-lucent.com] > Sent: Tuesday, April 19, 2011 12:11 PM > To: avtext@ietf.org > Cc: Ali C. Begen (abegen) > Subject: draft-begen-avtext-rams-scenarios-00 : comments >=20 > Hi Ali, >=20 > I read through the draft draft-begen-avtext-rams-scenarios-00. >=20 > -One general comment I have is that you mention multiple times "RAMS = session", while "RAMS session" is not defined in the > RAMS draft. Maybe it would be good to clarify this. I am actually looking for a better term here. Any suggestions? Or yes, = we will need to define it. =20 > E.g. in the Intro section, you say: > "In > scenarios where multiple RAMS sessions will be simultaneously run = by > an RTP receiver, they need to be coordinated." > I suggest to say: >=20 > "In > scenarios where multiple RAMS sessions, each initiated with an = individual RAMS-R message to a different feedback target > FT-ap, > will be simultaneously run by an RTP receiver, they need to be = coordinated by the RTP receiver." >=20 >=20 > -because the draft focuses on co-ordinated RAMS sessions/scenarios, = maybe add this in the title of the draft? Good idea. =20 > -I do not identify easily what are the guidelines this draft proposes = (as mentioned in the intro/abstract). Is this about which > multiplexing scenario is best in terms of combination with RAMS, in = terms of flexibility ?.. Perhaps just stick to describing > different scenarios, without mentioning guidelines? Maybe, it was supposed to be more on the guidelines side. Any = suggestions to improve the doc in that direction? =20 > These are more detailed comments: >=20 > Section introduction > "However, the specification has mostly focused > on the simplest case, which is when the RTP receiver acquires only > one multicast stream at a time, to explain the protocol details." >=20 > I would rephrase this as follows: >=20 > The specification does not discuss scenarios where an RTP receiver = makes use of RAMS to rapidly acquire multiple and > associated multicast streams in parallel, or where different RTP = sessions are part of the same SSM. E.g. the example section > 8.3 in the specification addresses only the simple case of an RTP = receiver rapidly acquiring only one multicast stream based > on an SDP which describes a single SSM composed of a single RTP = stream." OK, some rewording is in order here. =20 > section 4.3 : see my comments for section 6.3.. I do not understand = scenario 3 >=20 > section 4.4: >=20 > "and the > retransmission and RAMS operations will not be able to be applied > based on the payload type" > DELETE: "retransmission" (..because retransmission is based on RTP = SN.. no need to distinguish among PT?) OK. =20 > section 5: > "However, since this is not an easy requirement to satisfy, > RAMS specification forbids to have more than one RTP session to be > associated with a specific feedback target" >=20 > ADD: ..with a specific FB target on a specific port. Better said "with a specific FTAp" =20 =20 >=20 > section 6.1 >=20 > "This is the preferred deployment model for FEC. Having FEC in a > different multicast group provides flexibility for not only the RTP > receivers that are not FEC capable but also the ones that are FEC > capable but are not willing to receive FEC during the rapid > acquisition." >=20 > SUGGEST to DELETE: > This is the preferred deployment model for FEC. This is not much subjective AFAICT. Any strong reason why we should = delete it? This is also what we "recommend" in FEC Framework. =20 > REPHRASE : Having FEC in a > different multicast group provides two flexibility points: RTP > receivers that are not FEC capable can receive the primary video = stream without FEC, and RTP receivers that are FEC > capable can decide to not receive FEC during the rapid > acquisition (but still join the FEC stream after RAMS for the = primary video stream has finished). OK.=20 =20 > "In this case, the RTP receiver can request a Max > Receive Bitrate of 22 Mbps in the RAMS Request message" >=20 > ADD: ..in the RAMS request message for the prmary video stream. Good idea.=20 =20 > section 6.2: >=20 > "The > only difference from scenario #1 is that here the join time is the > same for both the primary video and FEC streams". >=20 > REPHRASE: .. is that here the join time is default the same for the = primary video and FEC stream. >=20 > (editor note: also in scenario 1 the join time can be the same) I see you point. I will make this clearer.=20 =20 > section 6.3 >=20 > "This is similar to scenario #2. However, since we cannot explicitly > specify the bitrates for the primary and FEC streams, the RTP > receiver can request to rapidly acquire both streams in parallel. = In > this case, two separate RAMS Request messages have to be sent by = the > RTP receiver to the feedback target." >=20 >=20 > ..I am a bit confused here. Fact is that, following the RAMS = specification, normally a single RAMS-R message is sent. If we Right, a single RAMS-R asking for all SSRCs would work. When you = indicate the max receive bitrate, individual streams will be accelerated = relatively. If that is what one wants, it is fine. > know the SSRCs of each stream, an RTP receiver can just request the = primary video stream. However, a single RAMS-R does > not allow to specify e.g. "max receive bit rate" per stream.. but I do = not think this is desired anyhow, as it will be the source > of the two sub streams that determine the relative bursting of the two = streams. So, looks like some revision is needed here.=20 > If we do not know the SSRC values, we cannot request separately the = SSRC streams using a single RAMS-R. > ..but why do we need to send two separate RAMS-R messages... and how = will you do that when there is only a single FT-ap? Yeah, something is not worded accurately here. I will try to make this = clearer. Thanks. -acbegen=20 From emil@sip-communicator.org Wed May 4 05:37:44 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07B4AE0773 for ; Wed, 4 May 2011 05:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id no53So59oGGo for ; Wed, 4 May 2011 05:37:42 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 56CC7E0762 for ; Wed, 4 May 2011 05:37:39 -0700 (PDT) Received: by bwz13 with SMTP id 13so1074031bwz.31 for ; Wed, 04 May 2011 05:37:38 -0700 (PDT) Received: by 10.204.228.130 with SMTP id je2mr999800bkb.166.1304512658062; Wed, 04 May 2011 05:37:38 -0700 (PDT) Received: from porcinet.local ([78.90.181.123]) by mx.google.com with ESMTPS id q24sm701076bks.21.2011.05.04.05.37.36 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 May 2011 05:37:37 -0700 (PDT) Message-ID: <4DC1488E.2000301@jitsi.org> Date: Wed, 04 May 2011 15:37:34 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; bg; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "avtext@ietf.org" Subject: Re: [avtext] Comments on draft-ietf-avtext-mixer-to-client-audio-level X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 12:37:44 -0000 Hey Keith, all, We are about to submit a new version and have addressed most of the comments raised by you and others on this list. We just wanted to clarify a couple of things before submitting: =D0=9D=D0=B0 28.03.11 13:29, DRAGE, Keith (Keith) =D0=BD=D0=B0=D0=BF=D0=B8= =D1=81=D0=B0: > Again a brief scan and identified some comments: >=20 > 1) Section 3: >=20 > This document describes an RTP header extension that allows mixers > to indicate the audio-level of every conference participant (CSRC) > in addition to simply indicating their on/off status. This new > header extension is based on the "General Mechanism for RTP Header=20 > Extensions" [RFC5285]. >=20 > RFC 5285 is a normative reference, and therefore the use of the term > "is based" is inappropriate. Need to be much more precise about how > RFC 5285 is followed (although some of that is covered by later > references. Does the following work? This document describes an RTP header extension that allows mixers to indicate the audio-level of every conference participant (CSRC) in addition to simply indicating their on/off status. This new header extension uses "General Mechanism for RTP Header Extensions" described in [RFC5285]. > 2) Section 4: >=20 > The 4-bit len field is the number minus one of data bytes (i.e. > audio level values) transported in this header extension element > following the one-byte header. Therefore, the value zero in this > field indicates that one byte of data follows. A value of 15 is not=20 > allowed by this specification and it MUST NOT be used as the RTP=20 > header can carry a maximum of 15 CSRC IDs. The maximum value > allowed is therefore 14 indicating a following sequence of 15 audio > level values. >=20 > I suspect that any RFC 2119 language here actually belongs in a > procedural section, but I was also unclear what the real conformance > requirement was here.=20 I am not sure I understand this comment. > Surely the main conformance requirement is to > carry 15 or less audio levels. This results in a maximum encoding of > 14. Yes this is what we had in mind and what the text currently says. Is there a problem with it? Could you maybe suggest a better wording? > 3) Section 6: >=20 > Conferencing clients that support audio level indicators and have no=20 > mixing capabilities SHOULD always include the direction parameter in=20 > the "extmap" attribute setting it to "recvonly". Conference focus=20 > entities with mixing capabilities MAY omit the direction or set it > to "sendrecv" in SDP offers. Such entities SHOULD set it to > "sendonly" in SDP answers to offers with a "recvonly" parameter and > to "sendrecv" when answering other "sendrecv" offers. >=20 > Is such a requirement in scope of this document? I suspect it ends up > updating an existing MMUSIC RFC. We don't really change or override anything in here and it's mostly a clarification. The thinking is that if a conferencing client does not have conferencing capabilities, then they won't be sending the header extension and would only be able to receive and process those coming from the mixer. This translates to SHOULD always include the direction parameter in the "extmap" attribute setting it to "recvonly" would it help if we simply removed the 2119 language and otherwise kept the text as it is? > 4) Section 6: >=20 > An example SDP offer/answer exchange between two conference focus=20 > entities with mixing capabilities negotiating an audio stream with=20 > bidirectional flwo of audio level information. >=20 > Typo "flow" Fixed. > 5) Section 7: >=20 > 2. Furthermore, the fact that audio level values would not be=20 > protected even in an SRTP session may be of concern in some cases=20 > where the activity of a particular participant in a conference is=20 > confidential. >=20 > Change "may" to "can" or "might" to avoid RFC 2119 style sentences. Changed. > 6) Section 8: >=20 > Add a note to RFC editor saying replace RFC XXXX by the number of > this RFC. Added. > 7) Section 12.2 >=20 > RFC 3920, RFC 3551 appear to not be used as references. Removed. > 8) General: >=20 > I suspect the editors could do with putting the two drafts side by > side and aligning the text from one to the other in the areas where > they are both trying to say the same thing. This is not a call for a > single document - I think they are distinct in that respect, but > there are similarities in the requirements and we should only say > similar things in the same way. OK. > Finally I notice that the summary of changes since the previous > version has been restricted to the last version. Could I ask that this > material is reinstated, and we will delete it at the publication > stage. In pursuance of this, please add a note to the RFC editor to > delete this material during final editing. Done. Whatever changelogs existed are back into the document. We also removed the level renderer and added an overload parameter to the AudioLevelCalculator as suggested by Peter Musgrave. Cheers, Emil >=20 >=20 > Regards >=20 > Keith _______________________________________________ avtext mailing > list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext >=20 --=20 Emil Ivov, Ph.D. 67000 Strasbourg, Project Lead France Jitsi emcho@jitsi.org PHONE: +33.1.77.62.43.30 http://jitsi.org FAX: +33.1.77.62.47.31 From emil@sip-communicator.org Wed May 4 06:20:59 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C409E0795 for ; Wed, 4 May 2011 06:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lh0YITmE+U2C for ; Wed, 4 May 2011 06:20:58 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0A7E0748 for ; Wed, 4 May 2011 06:20:57 -0700 (PDT) Received: by fxm15 with SMTP id 15so925963fxm.31 for ; Wed, 04 May 2011 06:20:57 -0700 (PDT) Received: by 10.223.17.68 with SMTP id r4mr1273380faa.62.1304515257153; Wed, 04 May 2011 06:20:57 -0700 (PDT) Received: from porcinet.local ([78.90.181.123]) by mx.google.com with ESMTPS id j11sm391394faa.44.2011.05.04.06.20.55 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 May 2011 06:20:56 -0700 (PDT) Message-ID: <4DC152B6.6080200@jitsi.org> Date: Wed, 04 May 2011 16:20:54 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; bg; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <4DC1488E.2000301@jitsi.org> In-Reply-To: <4DC1488E.2000301@jitsi.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "avtext@ietf.org" Subject: Re: [avtext] Comments on draft-ietf-avtext-mixer-to-client-audio-level X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 13:20:59 -0000 Adding to my previous post: =D0=9D=D0=B0 04.05.11 15:37, Emil Ivov =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0= : >> Conferencing clients that support audio level indicators and have no=20 >> mixing capabilities SHOULD always include the direction parameter in=20 >> the "extmap" attribute setting it to "recvonly". Conference focus=20 >> entities with mixing capabilities MAY omit the direction or set it >> to "sendrecv" in SDP offers. Such entities SHOULD set it to >> "sendonly" in SDP answers to offers with a "recvonly" parameter and >> to "sendrecv" when answering other "sendrecv" offers. >> >> Is such a requirement in scope of this document? I suspect it ends up >> updating an existing MMUSIC RFC. >=20 > We don't really change or override anything in here and it's mostly > a clarification. The thinking is that if a conferencing client does not= > have conferencing capabilities, then they won't be sending the header > extension and would only be able to receive and process those coming > from the mixer. This translates to >=20 > SHOULD always include the direction parameter in the "extmap" > attribute setting it to "recvonly" >=20 > would it help if we simply removed the 2119 language and otherwise kept= > the text as it is? Like this for example: Conferencing clients that support audio level indicators and have no mixing capabilities would not be able to content for this audio level extension and would hence have to always include the direction parameter in the "extmap" attribute with a value of "recvonly". Conference focus entities with mixing capabilities can omit the direction or set it to "sendrecv" in SDP offers. Such entities would need to set it to "sendonly" in SDP answers to offers with a "recvonly" parameter and to "sendrecv" when answering other "sendrecv" offers. Emil From keith.drage@alcatel-lucent.com Wed May 4 10:11:08 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8DFE07C9 for ; Wed, 4 May 2011 10:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.738 X-Spam-Level: X-Spam-Status: No, score=-102.738 tagged_above=-999 required=5 tests=[AWL=-2.939, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jriQO3k1TZv2 for ; Wed, 4 May 2011 10:11:07 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id EB93EE0684 for ; Wed, 4 May 2011 10:11:06 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p44HB4Yu028570 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 4 May 2011 19:11:05 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 4 May 2011 19:11:04 +0200 From: "DRAGE, Keith (Keith)" To: Emil Ivov Date: Wed, 4 May 2011 19:11:03 +0200 Thread-Topic: [avtext] Comments on draft-ietf-avtext-mixer-to-client-audio-level Thread-Index: AcwKWBj43GL6mECMRCiLHQu6zvde7QABRVXA Message-ID: References: <4DC1488E.2000301@jitsi.org> In-Reply-To: <4DC1488E.2000301@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Cc: "avtext@ietf.org" Subject: Re: [avtext] Comments on draft-ietf-avtext-mixer-to-client-audio-level X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 17:11:08 -0000 See below. I've removed the fixed comments. Keith > -----Original Message----- > From: Emil Ivov [mailto:emcho@jitsi.org] > Sent: 04 May 2011 13:38 > To: DRAGE, Keith (Keith) > Cc: avtext@ietf.org > Subject: Re: [avtext] Comments on draft-ietf-avtext-mixer-to-client-audio= - > level >=20 > Hey Keith, all, >=20 > We are about to submit a new version and have addressed most of the > comments raised by you and others on this list. We just wanted to > clarify a couple of things before submitting: >=20 > =EE=C1 28.03.11 13:29, DRAGE, Keith (Keith) =CE=C1=D0=C9=D3=C1: > > Again a brief scan and identified some comments: > > > > 1) Section 3: > > > > This document describes an RTP header extension that allows mixers > > to indicate the audio-level of every conference participant (CSRC) > > in addition to simply indicating their on/off status. This new > > header extension is based on the "General Mechanism for RTP Header > > Extensions" [RFC5285]. > > > > RFC 5285 is a normative reference, and therefore the use of the term > > "is based" is inappropriate. Need to be much more precise about how > > RFC 5285 is followed (although some of that is covered by later > > references. >=20 > Does the following work? >=20 > This document describes an RTP header extension that allows mixers to > indicate the audio-level of every conference participant (CSRC) in > addition to simply indicating their on/off status. This new header > extension uses "General Mechanism for RTP Header Extensions" > described in [RFC5285]. >=20 That works. >=20 > > 2) Section 4: > > > > The 4-bit len field is the number minus one of data bytes (i.e. > > audio level values) transported in this header extension element > > following the one-byte header. Therefore, the value zero in this > > field indicates that one byte of data follows. A value of 15 is not > > allowed by this specification and it MUST NOT be used as the RTP > > header can carry a maximum of 15 CSRC IDs. The maximum value > > allowed is therefore 14 indicating a following sequence of 15 audio > > level values. > > > > I suspect that any RFC 2119 language here actually belongs in a > > procedural section, but I was also unclear what the real conformance > > requirement was here. >=20 > I am not sure I understand this comment. >=20 As written, I found it very different to think of a test for the requiremen= t based only on the MUST. > > Surely the main conformance requirement is to > > carry 15 or less audio levels. This results in a maximum encoding of > > 14. >=20 > Yes this is what we had in mind and what the text currently says. Is > there a problem with it? Could you maybe suggest a better wording? >=20 Without investigating deeper I was unclear what the limitation is here. Is = the value 15 possible but reserved elsewhere for extension or what. If the coding already doesn't allow the value 15, but only the values 0 thr= ough 14, then I would assume we just need an informative statement pointing= out the consequences or the normative requirement. In the value 15 or more is allowed, then I would suggest just writing a sta= tement that says "Implementations MUST NOT include more than 15 audio level= values." >=20 > > 3) Section 6: > > > > Conferencing clients that support audio level indicators and have no > > mixing capabilities SHOULD always include the direction parameter in > > the "extmap" attribute setting it to "recvonly". Conference focus > > entities with mixing capabilities MAY omit the direction or set it > > to "sendrecv" in SDP offers. Such entities SHOULD set it to > > "sendonly" in SDP answers to offers with a "recvonly" parameter and > > to "sendrecv" when answering other "sendrecv" offers. > > > > Is such a requirement in scope of this document? I suspect it ends up > > updating an existing MMUSIC RFC. >=20 > We don't really change or override anything in here and it's mostly > a clarification. The thinking is that if a conferencing client does not > have conferencing capabilities, then they won't be sending the header > extension and would only be able to receive and process those coming > from the mixer. This translates to >=20 > SHOULD always include the direction parameter in the "extmap" > attribute setting it to "recvonly" >=20 > would it help if we simply removed the 2119 language and otherwise kept > the text as it is? >=20 Yes. From keith.drage@alcatel-lucent.com Wed May 4 10:12:24 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4FB5E06E0 for ; Wed, 4 May 2011 10:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.636 X-Spam-Level: X-Spam-Status: No, score=-102.636 tagged_above=-999 required=5 tests=[AWL=-2.837, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id icUzJGhnO+vj for ; Wed, 4 May 2011 10:12:24 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 19CD9E0684 for ; Wed, 4 May 2011 10:12:23 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p44HCM6r028709 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 4 May 2011 19:12:22 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 4 May 2011 19:12:22 +0200 From: "DRAGE, Keith (Keith)" To: Emil Ivov Date: Wed, 4 May 2011 19:12:21 +0200 Thread-Topic: [avtext] Comments on draft-ietf-avtext-mixer-to-client-audio-level Thread-Index: AcwKXhtzi6f2dzOUTsG6SPU0+85gHwAIE28g Message-ID: References: <4DC1488E.2000301@jitsi.org> <4DC152B6.6080200@jitsi.org> In-Reply-To: <4DC152B6.6080200@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Cc: "avtext@ietf.org" Subject: Re: [avtext] Comments on draft-ietf-avtext-mixer-to-client-audio-level X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2011 17:12:24 -0000 Fine by me Keith > -----Original Message----- > From: Emil Ivov [mailto:emcho@jitsi.org] > Sent: 04 May 2011 14:21 > To: DRAGE, Keith (Keith) > Cc: avtext@ietf.org > Subject: Re: [avtext] Comments on draft-ietf-avtext-mixer-to-client-audio= - > level >=20 > Adding to my previous post: >=20 > =EE=C1 04.05.11 15:37, Emil Ivov =CE=C1=D0=C9=D3=C1: > >> Conferencing clients that support audio level indicators and have no > >> mixing capabilities SHOULD always include the direction parameter in > >> the "extmap" attribute setting it to "recvonly". Conference focus > >> entities with mixing capabilities MAY omit the direction or set it > >> to "sendrecv" in SDP offers. Such entities SHOULD set it to > >> "sendonly" in SDP answers to offers with a "recvonly" parameter and > >> to "sendrecv" when answering other "sendrecv" offers. > >> > >> Is such a requirement in scope of this document? I suspect it ends up > >> updating an existing MMUSIC RFC. > > > > We don't really change or override anything in here and it's mostly > > a clarification. The thinking is that if a conferencing client does not > > have conferencing capabilities, then they won't be sending the header > > extension and would only be able to receive and process those coming > > from the mixer. This translates to > > > > SHOULD always include the direction parameter in the "extmap" > > attribute setting it to "recvonly" > > > > would it help if we simply removed the 2119 language and otherwise kept > > the text as it is? >=20 > Like this for example: >=20 > Conferencing clients that support audio level indicators and > have no mixing capabilities would not be able to content for > this audio level extension and would hence have to always > include the direction parameter in the "extmap" attribute > with a value of "recvonly". Conference focus entities with > mixing capabilities can omit the direction or set it to > "sendrecv" in SDP offers. Such entities would need to > set it to "sendonly" in SDP answers to offers with a > "recvonly" parameter and to "sendrecv" when answering other > "sendrecv" offers. >=20 > Emil From emil@sip-communicator.org Thu May 5 02:52:44 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0FC1E06E2 for ; Thu, 5 May 2011 02:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=-1.225, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4Daxy-uYXpt for ; Thu, 5 May 2011 02:52:44 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 22520E06DB for ; Thu, 5 May 2011 02:52:43 -0700 (PDT) Received: by fxm15 with SMTP id 15so1630336fxm.31 for ; Thu, 05 May 2011 02:52:42 -0700 (PDT) Received: by 10.223.52.7 with SMTP id f7mr370475fag.16.1304589162447; Thu, 05 May 2011 02:52:42 -0700 (PDT) Received: from porcinet.local ([78.90.181.123]) by mx.google.com with ESMTPS id c22sm688846fat.38.2011.05.05.02.52.40 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 05 May 2011 02:52:40 -0700 (PDT) Message-ID: <4DC27367.5000401@jitsi.org> Date: Thu, 05 May 2011 12:52:39 +0300 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; bg; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <4DC1488E.2000301@jitsi.org> In-Reply-To: Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Cc: "avtext@ietf.org" Subject: Re: [avtext] Comments on draft-ietf-avtext-mixer-to-client-audio-level X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 09:52:45 -0000 Hey Keith, (inline) =EE=C1 04.05.11 20:11, DRAGE, Keith (Keith) =CE=C1=D0=C9=D3=C1: >>> 2) Section 4: >>>=20 >>> The 4-bit len field is the number minus one of data bytes (i.e.=20 >>> audio level values) transported in this header extension element=20 >>> following the one-byte header. Therefore, the value zero in >>> this field indicates that one byte of data follows. A value of >>> 15 is not allowed by this specification and it MUST NOT be used >>> as the RTP header can carry a maximum of 15 CSRC IDs. The >>> maximum value allowed is therefore 14 indicating a following >>> sequence of 15 audio level values. >>>=20 >>> I suspect that any RFC 2119 language here actually belongs in a=20 >>> procedural section, but I was also unclear what the real >>> conformance requirement was here. >>=20 >> I am not sure I understand this comment. >>=20 > As written, I found it very different to think of a test for the > requirement based only on the MUST. >=20 >=20 >>> Surely the main conformance requirement is to carry 15 or less >>> audio levels. This results in a maximum encoding of 14. >>=20 >> Yes this is what we had in mind and what the text currently says. >> Is there a problem with it? Could you maybe suggest a better >> wording? >>=20 > Without investigating deeper I was unclear what the limitation is > here. Is the value 15 possible but reserved elsewhere for extension > or what. >=20 > If the coding already doesn't allow the value 15, but only the values > 0 through 14, then I would assume we just need an informative > statement pointing out the consequences or the normative > requirement. >=20 > In the value 15 or more is allowed, then I would suggest just writing > a statement that says "Implementations MUST NOT include more than 15 > audio level values." OK I see. So how about this: The 4-bit len field is the number minus one of data bytes (i.e. audio level values) transported in this header extension element following the one-byte header. Therefore, the value zero in this field indicates that one byte of data follows. RFC 3550 [RFC3550] only allows RTP packets to carry a maximum of 15 CSRC IDs. Given that audio levels directly refer to CSRC IDs, implementations MUST NOT include more than 15 audio level values. The maximum value allowed in the len field is therefore 14. Emil From keith.drage@alcatel-lucent.com Thu May 5 02:54:10 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3DADE06E2 for ; Thu, 5 May 2011 02:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.548 X-Spam-Level: X-Spam-Status: No, score=-104.548 tagged_above=-999 required=5 tests=[AWL=-0.749, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhD1AvoADyJe for ; Thu, 5 May 2011 02:54:10 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id DC769E06C5 for ; Thu, 5 May 2011 02:54:09 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p459rlR6025546 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 5 May 2011 11:54:05 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Thu, 5 May 2011 11:53:43 +0200 From: "DRAGE, Keith (Keith)" To: Emil Ivov Date: Thu, 5 May 2011 11:53:42 +0200 Thread-Topic: [avtext] Comments on draft-ietf-avtext-mixer-to-client-audio-level Thread-Index: AcwLCjF/zdpeJ9ppTo+34hpajNKBBQAABr1w Message-ID: References: <4DC1488E.2000301@jitsi.org> <4DC27367.5000401@jitsi.org> In-Reply-To: <4DC27367.5000401@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: "avtext@ietf.org" Subject: Re: [avtext] Comments on draft-ietf-avtext-mixer-to-client-audio-level X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 09:54:10 -0000 Fine by me. Keith > -----Original Message----- > From: Emil Ivov [mailto:emcho@jitsi.org] > Sent: 05 May 2011 10:53 > To: DRAGE, Keith (Keith) > Cc: avtext@ietf.org > Subject: Re: [avtext] Comments on draft-ietf-avtext-mixer-to-client-audio= - > level >=20 > Hey Keith, >=20 > (inline) >=20 > =EE=C1 04.05.11 20:11, DRAGE, Keith (Keith) =CE=C1=D0=C9=D3=C1: > >>> 2) Section 4: > >>> > >>> The 4-bit len field is the number minus one of data bytes (i.e. > >>> audio level values) transported in this header extension element > >>> following the one-byte header. Therefore, the value zero in > >>> this field indicates that one byte of data follows. A value of > >>> 15 is not allowed by this specification and it MUST NOT be used > >>> as the RTP header can carry a maximum of 15 CSRC IDs. The > >>> maximum value allowed is therefore 14 indicating a following > >>> sequence of 15 audio level values. > >>> > >>> I suspect that any RFC 2119 language here actually belongs in a > >>> procedural section, but I was also unclear what the real > >>> conformance requirement was here. > >> > >> I am not sure I understand this comment. > >> > > As written, I found it very different to think of a test for the > > requirement based only on the MUST. > > > > > >>> Surely the main conformance requirement is to carry 15 or less > >>> audio levels. This results in a maximum encoding of 14. > >> > >> Yes this is what we had in mind and what the text currently says. > >> Is there a problem with it? Could you maybe suggest a better > >> wording? > >> > > Without investigating deeper I was unclear what the limitation is > > here. Is the value 15 possible but reserved elsewhere for extension > > or what. > > > > If the coding already doesn't allow the value 15, but only the values > > 0 through 14, then I would assume we just need an informative > > statement pointing out the consequences or the normative > > requirement. > > > > In the value 15 or more is allowed, then I would suggest just writing > > a statement that says "Implementations MUST NOT include more than 15 > > audio level values." >=20 > OK I see. So how about this: >=20 > The 4-bit len field is the number minus one of data bytes (i.e. audio > level values) transported in this header extension element following > the one-byte header. Therefore, the value zero in this field > indicates that one byte of data follows. RFC 3550 [RFC3550] only > allows RTP packets to carry a maximum of 15 CSRC IDs. Given that > audio levels directly refer to CSRC IDs, implementations MUST NOT > include more than 15 audio level values. The maximum value allowed > in the len field is therefore 14. >=20 > Emil From magnus.westerlund@ericsson.com Fri May 6 07:18:12 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB0AE0761 for ; Fri, 6 May 2011 07:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.551 X-Spam-Level: X-Spam-Status: No, score=-106.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbZx5RSAr6dm for ; Fri, 6 May 2011 07:18:11 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 5E610E06D4 for ; Fri, 6 May 2011 07:18:10 -0700 (PDT) X-AuditID: c1b4fb3d-b7bd5ae000002ba3-87-4dc4032176c0 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id BA.F0.11171.12304CD4; Fri, 6 May 2011 16:18:09 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Fri, 6 May 2011 16:18:08 +0200 Message-ID: <4DC40320.1050407@ericsson.com> Date: Fri, 6 May 2011 16:18:08 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Jinwei Xia References: <3F01CB95-4099-4B04-99D5-6B2D8551E12E@orandom.net> <00c401cbf292$edace870$c906b950$%roni@huawei.com> <5C7BD80F-9AAC-4145-BD06-E722C9B691C6@csperkins.org> <015701cbf302$3abc3c50$b034b4f0$%roni@huawei.com> <4D9F297A.7020309@ericsson.com> <4DA2E990.60109@ericsson.com> <464A7AD502134A5697C7D18ADF337E0F@jinwei> In-Reply-To: <464A7AD502134A5697C7D18ADF337E0F@jinwei> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "avtext@ietf.org" Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 14:18:12 -0000 On 2011-04-13 16:49, Jinwei Xia wrote: >> Can we conclude that: >> >> Translator: >> pros: allow primary source know the situation of full path. >> cons: more considertaion for media adaptation; changing RTP SN and/or >> TS, and that RTCP. >> >> Mixer: >> pros: straight forward approach for media adaptation. >> cons: primary source only know the situation between itself and mixer; >> changing RTP SN, TS, SSRC and CSRC, and that RTCP. >> >> Is there any missing pros & cons of translator and mixer on splicing? Sorry for dropping out of the discussion. I think that the document needs to have a little bit of discussion of the two main approaches and the pro and con list wit a little more detail than the above. That as I think it is important it is clear under what premises and reasoning the path was selected. Then I think we should form a consensus on which approach we think is the more suitable to describe in all its gory details. But if minimal detectability is gone, then it might be that translator becomes more palatable for me. I am still not certain how one can avoid continues offset rewriting of rtp sequence number, timestamp etc unless one uses multiple SSRC in either a mixer or a translator usage. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From xiajinwei@huawei.com Mon May 9 01:22:08 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FFE5E07AC for ; Mon, 9 May 2011 01:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.01 X-Spam-Level: X-Spam-Status: No, score=-4.01 tagged_above=-999 required=5 tests=[AWL=1.989, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xz+BTN-Px0Ms for ; Mon, 9 May 2011 01:22:07 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 58D87E079B for ; Mon, 9 May 2011 01:22:07 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKX0041X5V6D5@szxga03-in.huawei.com> for avtext@ietf.org; Mon, 09 May 2011 16:21:06 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKX00AZT5V62P@szxga03-in.huawei.com> for avtext@ietf.org; Mon, 09 May 2011 16:21:06 +0800 (CST) Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 09 May 2011 16:21:05 +0800 Received: from x65217 (10.138.41.84) by smtpscn.huawei.com (10.82.67.32) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 09 May 2011 16:21:05 +0800 Date: Mon, 09 May 2011 16:21:05 +0800 From: Xiajinwei In-reply-to: <4DC40320.1050407@ericsson.com> X-Originating-IP: [10.138.41.84] To: 'Magnus Westerlund' Message-id: <017201cc0e22$0aec3170$54298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Thread-index: AcwL+HzFkXaL7srQS723KdoOuYhpKgB7oiAg Cc: avtext@ietf.org Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 08:22:08 -0000 Magnus,=20 Thank you for picking up the discussion. Let's categorize RTP splicing = to detectability and non-detectability.=20 In non-detectable case, The RTP header parameters must remain consistent regardless of the media content the RTP conveys. We can analyse the pron&cons of two approaches as following four aspects: RTP: translator should rewrite the SN and TS when the amount of substitutived packets is not equal to amount of main packets replaced. Translator must execute transcoding if the media type are different = between the two streams; Mixer should initiate its own SN and TS for the new = media stream, or transcoding, additionally mixer should change the CSRC for = loop detection. But the CSRC difference can allow downstream client to be = able to detect the switch. RTCP: translator should rewrite RTCP traffic passing through it to = reflect the real characteristics of each other; Mixer divides RTCP flow between source and user into two separate RTCP loops, hence media source has no = idea about the situation on user. Compared to translator, mixer is a more straight forward approach on RTCP.=20 Security: If encryption is employed, the media translator and mixer = need to be able to decrypt and re-encrypt the media stream. The difference is translator use one cryptographic key per user, mixer use key per domain. There is not strong requirement to hide translator or mixer from = receiver, but just there is one potential security issue: mixer exposes its = address to receivers and may get attacks from vicious receivers. Overhead: neither translaotr nor mixer can avoid the overhead while no splicing occur. When security mechanisms are used, there is more = overhead on translator since it needs to prepare multiple different keying material = for different receiver. In non-detectable case, I personally incline to translator since = translator can totally eliminate the difference between the two stream and erase = the potential security issue. In detectable case, the thing becomes simpler. translator is suitable to handle detectable splicing. When splicing ends, translator resumes main stream and rewrites the sequence number one higher than the last packet = sent to receiver in the main stream. There is a little overhead on translator = to rewrite RTP SN. If media sender support SSRC multiplexing, the thing = becomes simplest, the splicer can be a normal "switch node" which swith between multiple streams with different SSRCs to realize zero overhead. The appropriate solution is decided on whether the headend uses SSRC multiplexing mechanism.=20 BR Jinwei > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 > Sent: Friday, May 06, 2011 10:18 PM > To: Jinwei Xia > Cc: DRAGE, Keith (Keith); avtext@ietf.org > Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80 >=20 > On 2011-04-13 16:49, Jinwei Xia wrote: >=20 > >> Can we conclude that: > >> > >> Translator: > >> pros: allow primary source know the situation of full path. > >> cons: more considertaion for media adaptation; changing RTP SN=20 > >> and/or TS, and that RTCP. > >> > >> Mixer: > >> pros: straight forward approach for media adaptation. > >> cons: primary source only know the situation between=20 > itself and=20 > >> mixer; changing RTP SN, TS, SSRC and CSRC, and that RTCP. > >> > >> Is there any missing pros & cons of translator and mixer=20 > on splicing? >=20 > Sorry for dropping out of the discussion. >=20 > I think that the document needs to have a little bit of=20 > discussion of the two main approaches and the pro and con=20 > list wit a little more detail than the above. That as I think=20 > it is important it is clear under what premises and reasoning=20 > the path was selected. >=20 > Then I think we should form a consensus on which approach we=20 > think is the more suitable to describe in all its gory details. >=20 > But if minimal detectability is gone, then it might be that=20 > translator becomes more palatable for me. >=20 > I am still not certain how one can avoid continues offset=20 > rewriting of rtp sequence number, timestamp etc unless one=20 > uses multiple SSRC in either a mixer or a translator usage. >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 From internet-drafts@ietf.org Mon May 9 03:05:51 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49ED5E07E8; Mon, 9 May 2011 03:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VON9v5oKhbRZ; Mon, 9 May 2011 03:05:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5FB4E06D3; Mon, 9 May 2011 03:05:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.53 Message-ID: <20110509100550.21303.33389.idtracker@ietfa.amsl.com> Date: Mon, 09 May 2011 03:05:50 -0700 Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-mixer-to-client-audio-level-02.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 10:05:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Extensions Work= ing Group of the IETF. Title : A Real-Time Transport Protocol (RTP) Header Extension fo= r Mixer-to- Client Audio Level Indication Author(s) : Emil Ivov Enrico Marocco Jonathan Lennox Filename : draft-ietf-avtext-mixer-to-client-audio-level-02.txt Pages : 15 Date : 2011-05-09 This document describes a mechanism for RTP-level mixers in audio conferences to deliver information about the audio level of individual participants. Such audio level indicators are transported in the same RTP packets as the audio data they pertain to. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtext-mixer-to-client-audio= -level-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtext-mixer-to-client-audio-= level-02.txt From emil@sip-communicator.org Mon May 9 03:15:23 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45630E06E0 for ; Mon, 9 May 2011 03:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id heUEkAKzedO5 for ; Mon, 9 May 2011 03:15:21 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 96919E0651 for ; Mon, 9 May 2011 03:15:21 -0700 (PDT) Received: by wyb29 with SMTP id 29so4379966wyb.31 for ; Mon, 09 May 2011 03:15:20 -0700 (PDT) Received: by 10.216.202.147 with SMTP id d19mr6886724weo.23.1304936120197; Mon, 09 May 2011 03:15:20 -0700 (PDT) Received: from porcinet.local (shm67-5-88-165-90-188.fbx.proxad.net [88.165.90.188]) by mx.google.com with ESMTPS id d54sm2931467wej.10.2011.05.09.03.15.18 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 May 2011 03:15:19 -0700 (PDT) Message-ID: <4DC7BEB5.6010002@jitsi.org> Date: Mon, 09 May 2011 12:15:17 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; bg; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: AVTEXT References: <20110509100550.21303.33389.idtracker@ietfa.amsl.com> In-Reply-To: <20110509100550.21303.33389.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [avtext] mixer-to-client audio levels ready (Was: I-D Action: draft-ietf-avtext-mixer-to-client-audio-level-02.txt) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 10:15:23 -0000 Hey all, The authors are confident that all open issues and mailing list comments have now been addressed and that this document is now ready to move forwa= rd. We will be submitting the client-to-mixer draft in the following days. Cheers, Emil =D0=9D=D0=B0 09.05.11 12:05, internet-drafts@ietf.org =D0=BD=D0=B0=D0=BF=D0= =B8=D1=81=D0=B0: > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. This draft is a work item of the Audio/Video Transport Extension= s Working Group of the IETF. >=20 > Title : A Real-Time Transport Protocol (RTP) Header Extensio= n for Mixer-to- Client Audio Level Indication > Author(s) : Emil Ivov > Enrico Marocco > Jonathan Lennox > Filename : draft-ietf-avtext-mixer-to-client-audio-level-02.txt= > Pages : 15 > Date : 2011-05-09 >=20 > This document describes a mechanism for RTP-level mixers in audio > conferences to deliver information about the audio level of > individual participants. Such audio level indicators are transporte= d > in the same RTP packets as the audio data they pertain to. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-avtext-mixer-to-client-a= udio-level-02.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtext-mixer-to-client-au= dio-level-02.txt > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext >=20 --=20 Emil Ivov, Ph.D. 67000 Strasbourg, Project Lead France Jitsi emcho@jitsi.org PHONE: +33.1.77.62.43.30 http://jitsi.org FAX: +33.1.77.62.47.31 From magnus.westerlund@ericsson.com Thu May 12 02:19:04 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 554F0E0744 for ; Thu, 12 May 2011 02:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.115 X-Spam-Level: X-Spam-Status: No, score=-106.115 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2JVjBYizMYF for ; Thu, 12 May 2011 02:19:03 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 23862E06A0 for ; Thu, 12 May 2011 02:18:59 -0700 (PDT) X-AuditID: c1b4fb39-b7cc5ae000006f6d-a0-4dcba602d91e Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 33.23.28525.206ABCD4; Thu, 12 May 2011 11:18:58 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Thu, 12 May 2011 11:18:56 +0200 Message-ID: <4DCBA5FF.8040307@ericsson.com> Date: Thu, 12 May 2011 11:18:55 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Xiajinwei References: <017201cc0e22$0aec3170$54298a0a@china.huawei.com> In-Reply-To: <017201cc0e22$0aec3170$54298a0a@china.huawei.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "avtext@ietf.org" Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 09:19:04 -0000 On 2011-05-09 10:21, Xiajinwei wrote: > > Magnus, > > Thank you for picking up the discussion. Let's categorize RTP splicing to > detectability and non-detectability. > > In non-detectable case, The RTP header parameters must remain consistent > regardless of the media content the RTP conveys. We can analyse the > pron&cons of two approaches as following four aspects: First of all non-detectable is still detectable just by looking at the media stream. For example a non-detectable splicing operation with a video stream using H.264 will still be detectable just because that streams encoded by different encoders will have different parameter sets. Only if you do full media transcoding in the splicer can you avoid this. This is both complex and reduces quality thus I hope this is not expected. > > RTP: translator should rewrite the SN and TS when the amount of > substitutived packets is not equal to amount of main packets replaced. > Translator must execute transcoding if the media type are different between > the two streams; Mixer should initiate its own SN and TS for the new media > stream, or transcoding, additionally mixer should change the CSRC for loop > detection. But the CSRC difference can allow downstream client to be able to > detect the switch. Hmmm, I am not certain I agree with this description or usage of the models. Lets start with the picture Source1 ---> Splicer ----> receiver source2 -------^ In a translator case source1 view of the session is that it sees RTCP feedback from the receiver, at least when its content is forwarded. When it splices in source 2, then it creates a consistent continuation of source1 stream by setting SN and TS, while the splicer provide feedback on delivery to source 1 while it splices instead of the receiver. When it goes back to source1 it still will need to change SN and TS to maintain previous consistency. In a mixer case the splicer will use its own SSRC always and just select which of the source it uses for the media in the stream. Which means that the mixer owns the SN and TS space it forwards the media using. Also feedback will always be separated for the leg to the mixer and the leg between the mixer and the receiver. If the sources needs to react to downstream events additional RTCP extensions are needed. In the mixer case the mixer can select to use CSRC and forward the corresponding SDES items or not. > > RTCP: translator should rewrite RTCP traffic passing through it to reflect > the real characteristics of each other; Mixer divides RTCP flow between > source and user into two separate RTCP loops, hence media source has no idea > about the situation on user. Compared to translator, mixer is a more > straight forward approach on RTCP. Yes, except that if response to other leg is needed, then codec control messages or similar are needed. > > Security: If encryption is employed, the media translator and mixer need to > be able to decrypt and re-encrypt the media stream. The difference is > translator use one cryptographic key per user, mixer use key per domain. > There is not strong requirement to hide translator or mixer from receiver, > but just there is one potential security issue: mixer exposes its address to > receivers and may get attacks from vicious receivers. I don't understand why you come to the conclusion about why translators and mixers uses different keys. That is up to the implementation. And if we are talking about IPTV we are anyway talking about payload internal encryption which neither the boxes will touch unless one has decided to to media transcoding which seems expensive for this. > > Overhead: neither translaotr nor mixer can avoid the overhead while no > splicing occur. When security mechanisms are used, there is more overhead on > translator since it needs to prepare multiple different keying material for > different receiver. I don't see the need for having different security overhead between translator and mixer. > > > In non-detectable case, I personally incline to translator since translator > can totally eliminate the difference between the two stream and erase the > potential security issue. I think both can realize the non-detectable case. > > > In detectable case, the thing becomes simpler. translator is suitable to > handle detectable splicing. When splicing ends, translator resumes main > stream and rewrites the sequence number one higher than the last packet sent > to receiver in the main stream. There is a little overhead on translator to > rewrite RTP SN. What about the TS? I think that may become inconsistent and thus needs rewriting also. If media sender support SSRC multiplexing, the thing becomes > simplest, the splicer can be a normal "switch node" which swith between > multiple streams with different SSRCs to realize zero overhead. The > appropriate solution is decided on whether the headend uses SSRC > multiplexing mechanism. I think the question is not if the sender supports SSRC multiplexing, but if the receivers do. Sending two different RTP streams and hoping that they are nicely inserted in the gap is possible but not necessarily trivial. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From stewe@stewe.org Thu May 12 07:54:33 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73782E0759 for ; Thu, 12 May 2011 07:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.402 X-Spam-Level: X-Spam-Status: No, score=-0.402 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, DATE_IN_FUTURE_06_12=1.897, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNKbPGr2sDnc for ; Thu, 12 May 2011 07:54:29 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id 18B98E072F for ; Thu, 12 May 2011 07:54:28 -0700 (PDT) Received: from [192.168.13.185] (unverified [94.90.92.250]) by stewe.org (SurgeMail 3.9e) with ESMTP id 553-1743317 for multiple; Thu, 12 May 2011 16:54:27 +0200 User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Thu, 12 May 2011 16:54:17 -0700 From: Stephan Wenger To: Magnus Westerlund , Xiajinwei Message-ID: Thread-Topic: [avtext] Splicing: Confirmation of decisions at IETF#80 In-Reply-To: <4DCBA5FF.8040307@ericsson.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Originating-IP: 94.90.92.250 X-Authenticated-User: stewe@stewe.org Cc: "avtext@ietf.org" Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 14:54:33 -0000 Hi Magnus, Inline... On 5.12.2011 02:18 , "Magnus Westerlund" wrote: >On 2011-05-09 10:21, Xiajinwei wrote: >>=20 >> Magnus,=20 >>=20 >> Thank you for picking up the discussion. Let's categorize RTP splicing >>to >> detectability and non-detectability. >>=20 >> In non-detectable case, The RTP header parameters must remain consistent >> regardless of the media content the RTP conveys. We can analyse the >> pron&cons of two approaches as following four aspects: > >First of all non-detectable is still detectable just by looking at the >media stream. For example a non-detectable splicing operation with a >video stream using H.264 will still be detectable just because that >streams encoded by different encoders will have different parameter >sets. Only if you do full media transcoding in the splicer can you avoid >this. This is both complex and reduces quality thus I hope this is not >expected. I don't think your example is a good one. In H.264 (as well as in most other video compression standards) there are certain points in the bitstream which break bitstream prediction. The data (after decoding) between those points is called a sequence. A decoder cannot, without relying on heuristic means, determine whether a bitstream composed of more than one sequence was produced by one or more than one encoder. It's equally possible that two decoders use the same parameter sets. It's not even unlikely that they do, especially if you are using a "standard" set of tools and image formats, probably mandated by a profiling organization such as 3GPP. At the risk of being proven wrong in an exotic use case, I would even argue that, with most media codecs, it is very hard or even impossible, to identify properly implemented splicing without side information of some kind. I believe I agree with the rest of Magnus' comments below (without having thought about them in much detail). Stephan > >>=20 >> RTP: translator should rewrite the SN and TS when the amount of >> substitutived packets is not equal to amount of main packets replaced. >> Translator must execute transcoding if the media type are different >>between >> the two streams; Mixer should initiate its own SN and TS for the new >>media >> stream, or transcoding, additionally mixer should change the CSRC for >>loop >> detection. But the CSRC difference can allow downstream client to be >>able to >> detect the switch. > >Hmmm, I am not certain I agree with this description or usage of the >models. =20 > >Lets start with the picture > >Source1 ---> Splicer ----> receiver >source2 -------^ > >In a translator case source1 view of the session is that it sees RTCP >feedback from the receiver, at least when its content is forwarded. When >it splices in source 2, then it creates a consistent continuation of >source1 stream by setting SN and TS, while the splicer provide feedback >on delivery to source 1 while it splices instead of the receiver. When >it goes back to source1 it still will need to change SN and TS to >maintain previous consistency. > >In a mixer case the splicer will use its own SSRC always and just select >which of the source it uses for the media in the stream. Which means >that the mixer owns the SN and TS space it forwards the media using. >Also feedback will always be separated for the leg to the mixer and the >leg between the mixer and the receiver. If the sources needs to react to >downstream events additional RTCP extensions are needed. >In the mixer case the mixer can select to use CSRC and forward the >corresponding SDES items or not. > > > >>=20 >> RTCP: translator should rewrite RTCP traffic passing through it to >>reflect >> the real characteristics of each other; Mixer divides RTCP flow between >> source and user into two separate RTCP loops, hence media source has no >>idea >> about the situation on user. Compared to translator, mixer is a more >> straight forward approach on RTCP. > >Yes, except that if response to other leg is needed, then codec control >messages or similar are needed. > >>=20 >> Security: If encryption is employed, the media translator and mixer >>need to >> be able to decrypt and re-encrypt the media stream. The difference is >> translator use one cryptographic key per user, mixer use key per domain. >> There is not strong requirement to hide translator or mixer from >>receiver, >> but just there is one potential security issue: mixer exposes its >>address to >> receivers and may get attacks from vicious receivers. > >I don't understand why you come to the conclusion about why translators >and mixers uses different keys. That is up to the implementation. > >And if we are talking about IPTV we are anyway talking about payload >internal encryption which neither the boxes will touch unless one has >decided to to media transcoding which seems expensive for this. > >>=20 >> Overhead: neither translaotr nor mixer can avoid the overhead while no >> splicing occur. When security mechanisms are used, there is more >>overhead on >> translator since it needs to prepare multiple different keying material >>for >> different receiver. > >I don't see the need for having different security overhead between >translator and mixer. > >>=20 >>=20 >> In non-detectable case, I personally incline to translator since >>translator >> can totally eliminate the difference between the two stream and erase >>the >> potential security issue. > >I think both can realize the non-detectable case. > >>=20 >>=20 >> In detectable case, the thing becomes simpler. translator is suitable to >> handle detectable splicing. When splicing ends, translator resumes main >> stream and rewrites the sequence number one higher than the last packet >>sent >> to receiver in the main stream. There is a little overhead on >>translator to >> rewrite RTP SN.=20 > >What about the TS? I think that may become inconsistent and thus needs >rewriting also. > >If media sender support SSRC multiplexing, the thing becomes >> simplest, the splicer can be a normal "switch node" which swith between >> multiple streams with different SSRCs to realize zero overhead. The >> appropriate solution is decided on whether the headend uses SSRC >> multiplexing mechanism. > >I think the question is not if the sender supports SSRC multiplexing, >but if the receivers do. Sending two different RTP streams and hoping >that they are nicely inserted in the gap is possible but not necessarily >trivial. > >Cheers > >Magnus Westerlund > >---------------------------------------------------------------------- >Multimedia Technologies, Ericsson Research EAB/TVM >---------------------------------------------------------------------- >Ericsson AB | Phone +46 10 7148287 >F=E4r=F6gatan 6 | Mobile +46 73 0949079 >SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >---------------------------------------------------------------------- > >_______________________________________________ >avtext mailing list >avtext@ietf.org >https://www.ietf.org/mailman/listinfo/avtext From xiajinwei@huawei.com Thu May 12 20:54:54 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D684E068D for ; Thu, 12 May 2011 20:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4iqnsfjad-i for ; Thu, 12 May 2011 20:54:53 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id EAF01E0681 for ; Thu, 12 May 2011 20:54:52 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LL40078786MK1@szxga04-in.huawei.com> for avtext@ietf.org; Fri, 13 May 2011 11:54:22 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LL400JXL86L1A@szxga04-in.huawei.com> for avtext@ietf.org; Fri, 13 May 2011 11:54:22 +0800 (CST) Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 13 May 2011 11:54:15 +0800 Received: from x65217 (10.138.41.84) by szxeml403-hub.china.huawei.com (10.82.67.35) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 13 May 2011 11:54:21 +0800 Date: Fri, 13 May 2011 11:54:21 +0800 From: Xiajinwei In-reply-to: <4DCBA5FF.8040307@ericsson.com> X-Originating-IP: [10.138.41.84] To: 'Magnus Westerlund' Message-id: <002401cc1121$71c2b340$54298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Thread-index: AcwQhcUTwqZbi8hoRUCHWyZBc5YaVQAC8syw Cc: avtext@ietf.org Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 03:54:54 -0000 Magnus, > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 > Sent: Thursday, May 12, 2011 5:19 PM > To: Xiajinwei > Cc: 'DRAGE, Keith (Keith)'; avtext@ietf.org > Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80 >=20 > On 2011-05-09 10:21, Xiajinwei wrote: > >=20 > > Magnus, > >=20 > > Thank you for picking up the discussion. Let's categorize RTP=20 > > splicing to detectability and non-detectability. > >=20 > > In non-detectable case, The RTP header parameters must remain=20 > > consistent regardless of the media content the RTP conveys. We can=20 > > analyse the pron&cons of two approaches as following four aspects: >=20 > First of all non-detectable is still detectable just by=20 > looking at the media stream. For example a non-detectable=20 > splicing operation with a video stream using H.264 will still=20 > be detectable just because that streams encoded by different=20 > encoders will have different parameter sets. Only if you do=20 > full media transcoding in the splicer can you avoid this.=20 > This is both complex and reduces quality thus I hope this is=20 > not expected. >=20 I agree minimum-detectable is more appropriate. In draft-xia-avtext-splicing-for-rtp-00, I mentioned the RTP header = parameters MUST remain consistent except that meida type SHOULD be same since transcoding is prohibitively expensive and complex, so it is = RECOMMENDED to use same media type in insertion stream as that in main stream. If an operator want to realize complete non-detectable on client, he must take = the tranacoding cost in account.=20 Moreover, Splicer SHOULD also realize minimum-detectable in application layer, for example, reusing existing PIDs after a splicing described in [SMPTE-321M]. How this is done is an implementation detail and not = discussed in this draft. So how about above change?=20 > >=20 > > RTP: translator should rewrite the SN and TS when the amount of=20 > > substitutived packets is not equal to amount of main=20 > packets replaced. > > Translator must execute transcoding if the media type are different=20 > > between the two streams; Mixer should initiate its own SN=20 > and TS for=20 > > the new media stream, or transcoding, additionally mixer=20 > should change=20 > > the CSRC for loop detection. But the CSRC difference can allow=20 > > downstream client to be able to detect the switch. >=20 > Hmmm, I am not certain I agree with this description or usage=20 > of the models. >=20 > Lets start with the picture >=20 > Source1 ---> Splicer ----> receiver > source2 -------^ >=20 > In a translator case source1 view of the session is that it=20 > sees RTCP feedback from the receiver, at least when its=20 > content is forwarded. When it splices in source 2, then it=20 > creates a consistent continuation of > source1 stream by setting SN and TS, while the splicer=20 > provide feedback on delivery to source 1 while it splices=20 > instead of the receiver. When it goes back to source1 it=20 > still will need to change SN and TS to maintain previous consistency. >=20 > In a mixer case the splicer will use its own SSRC always and=20 > just select which of the source it uses for the media in the=20 > stream. Which means that the mixer owns the SN and TS space=20 > it forwards the media using. > Also feedback will always be separated for the leg to the=20 > mixer and the leg between the mixer and the receiver. If the=20 > sources needs to react to downstream events additional RTCP=20 > extensions are needed. > In the mixer case the mixer can select to use CSRC and=20 > forward the corresponding SDES items or not. >=20 >=20 Your description is more detailed, also including RTCP processing. = Compared to translator, mixer change the CSRC field in RTP header during = splicing. >=20 > >=20 > > RTCP: translator should rewrite RTCP traffic passing through it to=20 > > reflect the real characteristics of each other; Mixer divides RTCP=20 > > flow between source and user into two separate RTCP loops,=20 > hence media=20 > > source has no idea about the situation on user. Compared to=20 > > translator, mixer is a more straight forward approach on RTCP. >=20 > Yes, except that if response to other leg is needed, then=20 > codec control messages or similar are needed. >=20 True. RFC5104 can repair it. > >=20 > > Security: If encryption is employed, the media translator=20 > and mixer=20 > > need to be able to decrypt and re-encrypt the media stream. The=20 > > difference is translator use one cryptographic key per=20 > user, mixer use key per domain. > > There is not strong requirement to hide translator or mixer from=20 > > receiver, but just there is one potential security issue: mixer=20 > > exposes its address to receivers and may get attacks from=20 > vicious receivers. >=20 > I don't understand why you come to the conclusion about why=20 > translators and mixers uses different keys. That is up to the=20 > implementation. >=20 > And if we are talking about IPTV we are anyway talking about=20 > payload internal encryption which neither the boxes will=20 > touch unless one has decided to to media transcoding which=20 > seems expensive for this. an translator change the payload of RTP during splicing with SSRC = intact, should it use different keys for different segments?=20 >=20 > >=20 > > Overhead: neither translaotr nor mixer can avoid the=20 > overhead while no=20 > > splicing occur. When security mechanisms are used, there is more=20 > > overhead on translator since it needs to prepare multiple different=20 > > keying material for different receiver. >=20 > I don't see the need for having different security overhead=20 > between translator and mixer. >=20 > >=20 > >=20 > > In non-detectable case, I personally incline to translator since=20 > > translator can totally eliminate the difference between the=20 > two stream=20 > > and erase the potential security issue. >=20 > I think both can realize the non-detectable case. >=20 Yes, both can do that. The problem is which one is better. What's your prefer in the two candidates or otherwise? > >=20 > >=20 > > In detectable case, the thing becomes simpler. translator=20 > is suitable=20 > > to handle detectable splicing. When splicing ends,=20 > translator resumes=20 > > main stream and rewrites the sequence number one higher=20 > than the last=20 > > packet sent to receiver in the main stream. There is a=20 > little overhead=20 > > on translator to rewrite RTP SN. >=20 > What about the TS? I think that may become inconsistent and=20 > thus needs rewriting also. Sorry for missing it again, the TS is higher than the last inserted = packet to maintain consistency. >=20 > If media sender support SSRC multiplexing, the thing becomes > > simplest, the splicer can be a normal "switch node" which swith=20 > > between multiple streams with different SSRCs to realize zero=20 > > overhead. The appropriate solution is decided on whether=20 > the headend=20 > > uses SSRC multiplexing mechanism. >=20 > I think the question is not if the sender supports SSRC=20 > multiplexing, but if the receivers do. Sending two different=20 > RTP streams and hoping that they are nicely inserted in the=20 > gap is possible but not necessarily trivial. Yes, this is inner implementation to fill up the gap. Using SSRC multiplexing may be the most straight forward approach for detectable = case. Thank you Jinwei >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 From magnus.westerlund@ericsson.com Fri May 13 01:19:00 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8DCE0738 for ; Fri, 13 May 2011 01:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.147 X-Spam-Level: X-Spam-Status: No, score=-106.147 tagged_above=-999 required=5 tests=[AWL=-0.147, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWMjYfb99yZy for ; Fri, 13 May 2011 01:18:59 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 89C41E06FB for ; Fri, 13 May 2011 01:18:59 -0700 (PDT) X-AuditID: c1b4fb39-b7cc5ae000006f6d-9f-4dcce43fc0ef Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 2C.FE.28525.F34ECCD4; Fri, 13 May 2011 09:56:47 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Fri, 13 May 2011 09:56:40 +0200 Message-ID: <4DCCE438.1040301@ericsson.com> Date: Fri, 13 May 2011 09:56:40 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Stephan Wenger References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "avtext@ietf.org" Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2011 08:19:00 -0000 On 2011-05-13 01:54, Stephan Wenger wrote: > Hi Magnus, > > Inline... > > On 5.12.2011 02:18 , "Magnus Westerlund" > wrote: > >> On 2011-05-09 10:21, Xiajinwei wrote: >>> >>> Magnus, >>> >>> Thank you for picking up the discussion. Let's categorize RTP splicing >>> to >>> detectability and non-detectability. >>> >>> In non-detectable case, The RTP header parameters must remain consistent >>> regardless of the media content the RTP conveys. We can analyse the >>> pron&cons of two approaches as following four aspects: >> >> First of all non-detectable is still detectable just by looking at the >> media stream. For example a non-detectable splicing operation with a >> video stream using H.264 will still be detectable just because that >> streams encoded by different encoders will have different parameter >> sets. Only if you do full media transcoding in the splicer can you avoid >> this. This is both complex and reduces quality thus I hope this is not >> expected. > > > I don't think your example is a good one. In H.264 (as well as in most > other video compression standards) there are certain points in the > bitstream which break bitstream prediction. The data (after decoding) > between those points is called a sequence. A decoder cannot, without > relying on heuristic means, determine whether a bitstream composed of more > than one sequence was produced by one or more than one encoder. > > It's equally possible that two decoders use the same parameter sets. It's > not even unlikely that they do, especially if you are using a "standard" > set of tools and image formats, probably mandated by a profiling > organization such as 3GPP. > > At the risk of being proven wrong in an exotic use case, I would even > argue that, with most media codecs, it is very hard or even impossible, to > identify properly implemented splicing without side information of some > kind. I agree that it is not certain that you can detect, but in certain case you will be able to detect, at least using heuristics. Yes, if you ensure a certain level of harmonization between the encoding I agree you can make it difficult to detect. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From csp@csperkins.org Mon May 16 03:47:21 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 148C3E071F for ; Mon, 16 May 2011 03:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.911 X-Spam-Level: X-Spam-Status: No, score=-102.911 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7gXWi0nUm5Bn for ; Mon, 16 May 2011 03:47:20 -0700 (PDT) Received: from anchor-msapost-3.mail.demon.net (anchor-msapost-3.mail.demon.net [195.173.77.166]) by ietfa.amsl.com (Postfix) with ESMTP id DECEEE066A for ; Mon, 16 May 2011 03:47:19 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by anchor-post-3.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1QLvKZ-0002pt-mY; Mon, 16 May 2011 10:47:19 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <4DCBA5FF.8040307@ericsson.com> Date: Mon, 16 May 2011 11:47:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0EA52F7A-E495-40F3-8DA3-F92474406469@csperkins.org> References: <017201cc0e22$0aec3170$54298a0a@china.huawei.com> <4DCBA5FF.8040307@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1084) Cc: "avtext@ietf.org" Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 10:47:21 -0000 On 12 May 2011, at 10:18, Magnus Westerlund wrote: > On 2011-05-09 10:21, Xiajinwei wrote: >>=20 >> Magnus,=20 >>=20 >> Thank you for picking up the discussion. Let's categorize RTP = splicing to >> detectability and non-detectability.=20 >>=20 >> In non-detectable case, The RTP header parameters must remain = consistent >> regardless of the media content the RTP conveys. We can analyse the >> pron&cons of two approaches as following four aspects: >=20 > First of all non-detectable is still detectable just by looking at the > media stream. For example a non-detectable splicing operation with a > video stream using H.264 will still be detectable just because that > streams encoded by different encoders will have different parameter > sets. Only if you do full media transcoding in the splicer can you = avoid > this. This is both complex and reduces quality thus I hope this is not > expected. >=20 >>=20 >> RTP: translator should rewrite the SN and TS when the amount of >> substitutived packets is not equal to amount of main packets = replaced. >> Translator must execute transcoding if the media type are different = between >> the two streams; Mixer should initiate its own SN and TS for the new = media >> stream, or transcoding, additionally mixer should change the CSRC for = loop >> detection. But the CSRC difference can allow downstream client to be = able to >> detect the switch. >=20 > Hmmm, I am not certain I agree with this description or usage of the > models. >=20 > Lets start with the picture >=20 > Source1 ---> Splicer ----> receiver > source2 -------^ >=20 > In a translator case source1 view of the session is that it sees RTCP > feedback from the receiver, at least when its content is forwarded. = When > it splices in source 2, then it creates a consistent continuation of > source1 stream by setting SN and TS, while the splicer provide = feedback > on delivery to source 1 while it splices instead of the receiver. When > it goes back to source1 it still will need to change SN and TS to > maintain previous consistency. >=20 > In a mixer case the splicer will use its own SSRC always and just = select > which of the source it uses for the media in the stream. Which means > that the mixer owns the SN and TS space it forwards the media using. > Also feedback will always be separated for the leg to the mixer and = the > leg between the mixer and the receiver. If the sources needs to react = to > downstream events additional RTCP extensions are needed. > In the mixer case the mixer can select to use CSRC and forward the > corresponding SDES items or not. >=20 >=20 >=20 >>=20 >> RTCP: translator should rewrite RTCP traffic passing through it to = reflect >> the real characteristics of each other; Mixer divides RTCP flow = between >> source and user into two separate RTCP loops, hence media source has = no idea >> about the situation on user. Compared to translator, mixer is a more >> straight forward approach on RTCP.=20 >=20 > Yes, except that if response to other leg is needed, then codec = control > messages or similar are needed. >=20 >>=20 >> Security: If encryption is employed, the media translator and mixer = need to >> be able to decrypt and re-encrypt the media stream. The difference is >> translator use one cryptographic key per user, mixer use key per = domain. >> There is not strong requirement to hide translator or mixer from = receiver, >> but just there is one potential security issue: mixer exposes its = address to >> receivers and may get attacks from vicious receivers. >=20 > I don't understand why you come to the conclusion about why = translators > and mixers uses different keys. That is up to the implementation. >=20 > And if we are talking about IPTV we are anyway talking about payload > internal encryption which neither the boxes will touch unless one has > decided to to media transcoding which seems expensive for this. >=20 >>=20 >> Overhead: neither translaotr nor mixer can avoid the overhead while = no >> splicing occur. When security mechanisms are used, there is more = overhead on >> translator since it needs to prepare multiple different keying = material for >> different receiver. >=20 > I don't see the need for having different security overhead between > translator and mixer. >=20 >>=20 >>=20 >> In non-detectable case, I personally incline to translator since = translator >> can totally eliminate the difference between the two stream and erase = the >> potential security issue. >=20 > I think both can realize the non-detectable case. >=20 >>=20 >>=20 >> In detectable case, the thing becomes simpler. translator is suitable = to >> handle detectable splicing. When splicing ends, translator resumes = main >> stream and rewrites the sequence number one higher than the last = packet sent >> to receiver in the main stream. There is a little overhead on = translator to >> rewrite RTP SN.=20 >=20 > What about the TS? I think that may become inconsistent and thus needs > rewriting also. I'd think it reasonable to require that the inserted content MUST be the = same duration as the original content. Otherwise, not only will you need = to rewrite the timestamps after the splicing has ended, you'll either = have a gap or extra data to be buffered somewhere. You'll only have to = rewrite timestamps during the splicing, to normalise the random offset. --=20 Colin Perkins http://csperkins.org/ From magnus.westerlund@ericsson.com Mon May 16 04:41:31 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AACAE0743 for ; Mon, 16 May 2011 04:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.404 X-Spam-Level: X-Spam-Status: No, score=-106.404 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qm3b1CE45hdS for ; Mon, 16 May 2011 04:41:30 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id E08A6E069A for ; Mon, 16 May 2011 04:41:29 -0700 (PDT) X-AuditID: c1b4fb39-b7ceaae0000076dc-48-4dd10d687ceb Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 3B.63.30428.86D01DD4; Mon, 16 May 2011 13:41:28 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Mon, 16 May 2011 13:41:28 +0200 Message-ID: <4DD10D68.1090302@ericsson.com> Date: Mon, 16 May 2011 13:41:28 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "avtext@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [avtext] Call for adopting document for mile stone "Support for multiple clock rates in an RTP session for Proposed Standard" X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2011 11:41:31 -0000 WG, AVTEXT has one milestone: Dec 2011 Submit Support for multiple clock rates in an RTP session for Proposed Standard We have one candidate document: https://datatracker.ietf.org/doc/draft-petithuguenin-avtext-multiple-clock-rates/ This is the call to the WG if we want to adopt this document as the basis for meeting that milestone? Please provide comments even if it is just "Yes". If you think there is some aspect of the issue or the solution that hasn't been discussed and you want to ensure is covered, please comment on that. The WG chairs will make a decision on 31st of May based on your comments. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Tue May 17 00:14:36 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04FE1E07E5 for ; Tue, 17 May 2011 00:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.134 X-Spam-Level: X-Spam-Status: No, score=-106.134 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vEe8JEiyV14 for ; Tue, 17 May 2011 00:14:34 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id E4321E07E2 for ; Tue, 17 May 2011 00:14:33 -0700 (PDT) X-AuditID: c1b4fb39-b7ceaae0000076dc-00-4dd2205890c9 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id EA.2A.30428.85022DD4; Tue, 17 May 2011 09:14:32 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Tue, 17 May 2011 09:14:32 +0200 Message-ID: <4DD22058.8030007@ericsson.com> Date: Tue, 17 May 2011 09:14:32 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Xiajinwei References: <002401cc1121$71c2b340$54298a0a@china.huawei.com> In-Reply-To: <002401cc1121$71c2b340$54298a0a@china.huawei.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "avtext@ietf.org" Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2011 07:14:36 -0000 On 2011-05-13 05:54, Xiajinwei wrote: > > Magnus, > >> -----Original Message----- >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >> Sent: Thursday, May 12, 2011 5:19 PM >> To: Xiajinwei >> Cc: 'DRAGE, Keith (Keith)'; avtext@ietf.org >> Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80 >> >> On 2011-05-09 10:21, Xiajinwei wrote: >>> >>> Magnus, >>> >>> Thank you for picking up the discussion. Let's categorize RTP >>> splicing to detectability and non-detectability. >>> >>> In non-detectable case, The RTP header parameters must remain >>> consistent regardless of the media content the RTP conveys. We can >>> analyse the pron&cons of two approaches as following four aspects: >> >> First of all non-detectable is still detectable just by >> looking at the media stream. For example a non-detectable >> splicing operation with a video stream using H.264 will still >> be detectable just because that streams encoded by different >> encoders will have different parameter sets. Only if you do >> full media transcoding in the splicer can you avoid this. >> This is both complex and reduces quality thus I hope this is >> not expected. >> > > I agree minimum-detectable is more appropriate. In > draft-xia-avtext-splicing-for-rtp-00, I mentioned the RTP header parameters > MUST remain consistent except that meida type SHOULD be same since > transcoding is prohibitively expensive and complex, so it is RECOMMENDED to > use same media type in insertion stream as that in main stream. If an > operator want to realize complete non-detectable on client, he must take the > tranacoding cost in account. > > Moreover, Splicer SHOULD also realize minimum-detectable in application > layer, for example, reusing existing PIDs after a splicing described in > [SMPTE-321M]. How this is done is an implementation detail and not discussed > in this draft. > > So how about above change? > I guess PIDs are protocol IDs. I think one needs to have a more detailed discussion on what IDs can be reused and when they can't. >>> >>> RTP: translator should rewrite the SN and TS when the amount of >>> substitutived packets is not equal to amount of main >> packets replaced. >>> Translator must execute transcoding if the media type are different >>> between the two streams; Mixer should initiate its own SN >> and TS for >>> the new media stream, or transcoding, additionally mixer >> should change >>> the CSRC for loop detection. But the CSRC difference can allow >>> downstream client to be able to detect the switch. >> >> Hmmm, I am not certain I agree with this description or usage >> of the models. >> >> Lets start with the picture >> >> Source1 ---> Splicer ----> receiver >> source2 -------^ >> >> In a translator case source1 view of the session is that it >> sees RTCP feedback from the receiver, at least when its >> content is forwarded. When it splices in source 2, then it >> creates a consistent continuation of >> source1 stream by setting SN and TS, while the splicer >> provide feedback on delivery to source 1 while it splices >> instead of the receiver. When it goes back to source1 it >> still will need to change SN and TS to maintain previous consistency. >> >> In a mixer case the splicer will use its own SSRC always and >> just select which of the source it uses for the media in the >> stream. Which means that the mixer owns the SN and TS space >> it forwards the media using. >> Also feedback will always be separated for the leg to the >> mixer and the leg between the mixer and the receiver. If the >> sources needs to react to downstream events additional RTCP >> extensions are needed. >> In the mixer case the mixer can select to use CSRC and >> forward the corresponding SDES items or not. >> >> > > Your description is more detailed, also including RTCP processing. Compared > to translator, mixer change the CSRC field in RTP header during splicing. > It may do that, it is not a strict requirement to use CSRC in mixers. And in a splicer there appears to be benefits of not including the CRSC. >>> >>> Security: If encryption is employed, the media translator >> and mixer >>> need to be able to decrypt and re-encrypt the media stream. The >>> difference is translator use one cryptographic key per >> user, mixer use key per domain. >>> There is not strong requirement to hide translator or mixer from >>> receiver, but just there is one potential security issue: mixer >>> exposes its address to receivers and may get attacks from >> vicious receivers. >> >> I don't understand why you come to the conclusion about why >> translators and mixers uses different keys. That is up to the >> implementation. >> >> And if we are talking about IPTV we are anyway talking about >> payload internal encryption which neither the boxes will >> touch unless one has decided to to media transcoding which >> seems expensive for this. > > an translator change the payload of RTP during splicing with SSRC intact, > should it use different keys for different segments? For the payload internal stuff people are using, it can likely handle such key changes using security payload internal mechanism. The whole point with these payload internal mechanisms is that no entity between the content source and the decoder actually needs to have the key. If one uses regular transport security like SRTP or DTLS, IPsec, etc. then you need to re-process all the packets if you change something in them. Thus different key-context for the different legs makes sense. > >> >>> >>> Overhead: neither translaotr nor mixer can avoid the >> overhead while no >>> splicing occur. When security mechanisms are used, there is more >>> overhead on translator since it needs to prepare multiple different >>> keying material for different receiver. >> >> I don't see the need for having different security overhead >> between translator and mixer. >> >>> >>> >>> In non-detectable case, I personally incline to translator since >>> translator can totally eliminate the difference between the >> two stream >>> and erase the potential security issue. >> >> I think both can realize the non-detectable case. >> > > Yes, both can do that. The problem is which one is better. What's your > prefer in the two candidates or otherwise? I think it comes down to how one wants to organize the splicer and the upstream content sources. To which degree they should aware of the splicer and if requiring changes to them are acceptable, specifically the original content source. If modifying the original content source is out of the picture then I think a translator is the right way to go, although I believe it will require a bit more text to describe all the aspects one needs to think about. If one can modify the original content source, then I think a mixer is more straight forward and thus easier to describe. What the answer is to the modifying question I don't know. Input is desirable. >> >> If media sender support SSRC multiplexing, the thing becomes >>> simplest, the splicer can be a normal "switch node" which swith >>> between multiple streams with different SSRCs to realize zero >>> overhead. The appropriate solution is decided on whether >> the headend >>> uses SSRC multiplexing mechanism. >> >> I think the question is not if the sender supports SSRC >> multiplexing, but if the receivers do. Sending two different >> RTP streams and hoping that they are nicely inserted in the >> gap is possible but not necessarily trivial. > > Yes, this is inner implementation to fill up the gap. Using SSRC > multiplexing may be the most straight forward approach for detectable case. > Yes, but also least likely to ensure glitch free media processing, at least before you have updated your receivers to include a few mechanisms to ensure that they can quickly and correctly create a common timeline. Thus I think SSRC multiplexing is to quite a large degree a red herring in this case. It will not work well in legacy case, and even with updates it is still creating potential issues. Thus I think using a single SSRC and inserting the content into the stream is the most likely to work well. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Tue May 17 00:18:38 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C6DE07E4 for ; Tue, 17 May 2011 00:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.425 X-Spam-Level: X-Spam-Status: No, score=-106.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6dgxOrypRV7 for ; Tue, 17 May 2011 00:18:37 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 59997E067F for ; Tue, 17 May 2011 00:18:37 -0700 (PDT) X-AuditID: c1b4fb39-b7ceaae0000076dc-e7-4dd2214ca393 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id DC.DA.30428.C4122DD4; Tue, 17 May 2011 09:18:36 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Tue, 17 May 2011 09:18:35 +0200 Message-ID: <4DD2214C.1050805@ericsson.com> Date: Tue, 17 May 2011 09:18:36 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Colin Perkins References: <017201cc0e22$0aec3170$54298a0a@china.huawei.com> <4DCBA5FF.8040307@ericsson.com> <0EA52F7A-E495-40F3-8DA3-F92474406469@csperkins.org> In-Reply-To: <0EA52F7A-E495-40F3-8DA3-F92474406469@csperkins.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "avtext@ietf.org" Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2011 07:18:38 -0000 On 2011-05-16 12:47, Colin Perkins wrote: >>> >>> In detectable case, the thing becomes simpler. translator is suitable to >>> handle detectable splicing. When splicing ends, translator resumes main >>> stream and rewrites the sequence number one higher than the last packet sent >>> to receiver in the main stream. There is a little overhead on translator to >>> rewrite RTP SN. >> >> What about the TS? I think that may become inconsistent and thus needs >> rewriting also. > > I'd think it reasonable to require that the inserted content MUST be > the same duration as the original content. Otherwise, not only will > you need to rewrite the timestamps after the splicing has ended, > you'll either have a gap or extra data to be buffered somewhere. > You'll only have to rewrite timestamps during the splicing, to > normalise the random offset. > I agree that you need to have content to insert that is very close to the space you are replacing. The question is what happens when things are off with a video frame or less, or an audio frame or less. One thing to worry about here is what happens if the frame rate varies between the content, then you may have a small diff to take care of. Yes, letting that be a bit extra delay between content in the point of switching is back is likely fine, but it needs to be discussed in the document. I might have made the impression that this issue is bigger than it really is. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From xiajinwei@huawei.com Tue May 17 02:55:14 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCB09E06A8 for ; Tue, 17 May 2011 02:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[AWL=-1.700, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3qCMc5EzUhY for ; Tue, 17 May 2011 02:55:13 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id EE960E0679 for ; Tue, 17 May 2011 02:55:12 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLC00LU93JUEO@szxga05-in.huawei.com> for avtext@ietf.org; Tue, 17 May 2011 17:55:07 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLC005YU3JUN6@szxga05-in.huawei.com> for avtext@ietf.org; Tue, 17 May 2011 17:55:06 +0800 (CST) Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 17 May 2011 17:55:04 +0800 Received: from x65217 (10.138.41.84) by smtpscn.huawei.com (10.82.67.32) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 17 May 2011 17:55:05 +0800 Date: Tue, 17 May 2011 17:55:05 +0800 From: Jinwei Xia In-reply-to: <4DD2214C.1050805@ericsson.com> X-Originating-IP: [10.138.41.84] To: 'Magnus Westerlund' , 'Colin Perkins' Message-id: <00a301cc1478$7f95da60$54298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-index: AcwUYywIdcJp7rSRSz+lR9Nvpilz+QABrqZg Cc: avtext@ietf.org Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2011 09:55:14 -0000 Magnus, Inline~~ > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 > Sent: Tuesday, May 17, 2011 3:19 PM > To: Colin Perkins > Cc: Xiajinwei; avtext@ietf.org > Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80 >=20 > On 2011-05-16 12:47, Colin Perkins wrote: >=20 > >>> > >>> In detectable case, the thing becomes simpler. translator is=20 > >>> suitable to handle detectable splicing. When splicing ends,=20 > >>> translator resumes main stream and rewrites the sequence=20 > number one=20 > >>> higher than the last packet sent to receiver in the main stream.=20 > >>> There is a little overhead on translator to rewrite RTP SN. > >> > >> What about the TS? I think that may become inconsistent and thus=20 > >> needs rewriting also. > >=20 > > I'd think it reasonable to require that the inserted=20 > content MUST be=20 > > the same duration as the original content. Otherwise, not only will=20 > > you need to rewrite the timestamps after the splicing has ended,=20 > > you'll either have a gap or extra data to be buffered somewhere. > > You'll only have to rewrite timestamps during the splicing, to=20 > > normalise the random offset. > >=20 >=20 > I agree that you need to have content to insert that is very=20 > close to the space you are replacing. The question is what=20 > happens when things are off with a video frame or less, or an=20 > audio frame or less. >=20 Your concern make senses, one of splicing requirements is Splicer SHOULD = NOT cause perceptible media clipping at the splicing joint. Media source = must schedule the splicing point which usually is the boundary of two independently decodable frames. When audio and video are not = interleaved, each audio frame is usually decodable for common audio codecs. For = video, some predicted frames need to depent on other frames, so the splicing = point is usually at the Group of Pictures (GoP) boundary instead. > One thing to worry about here is what happens if the frame=20 > rate varies between the content, then you may have a small=20 > diff to take care of. > Yes, letting that be a bit extra delay between content in the=20 > point of switching is back is likely fine, but it needs to be=20 > discussed in the document. Media encoding bitrates of the two contents may be different but the difference should be minor, since both of them should match the user's = media comsuption rate to ensure that the user's buffer remains at a stable = level over time. If the encoding bitrate of insertion content is drastically higher or lower than that of main content when splicing begins, user = might rapidly flood or drain its buffer, and eventually result in a buffer overflow or underflow. So the insertion content is recommended to be = encoded at an appropriate bitrate to match main content's. If the insertion = content comes from another media source, the source may have knowledge about the media encoding bitrate of main content in advance. How does it know that = is out of scope in this draft. I will add above content in next version. Thank you again! Jinwei >=20 > I might have made the impression that this issue is bigger=20 > than it really is. >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 From xiajinwei@huawei.com Mon May 23 00:04:26 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7114DE0759 for ; Mon, 23 May 2011 00:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.397 X-Spam-Level: X-Spam-Status: No, score=-2.397 tagged_above=-999 required=5 tests=[AWL=-1.902, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oi0ZVAiZr-a5 for ; Mon, 23 May 2011 00:04:25 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 70F9EE0720 for ; Mon, 23 May 2011 00:04:25 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLM000QFZK2R1@szxga05-in.huawei.com> for avtext@ietf.org; Mon, 23 May 2011 15:02:26 +0800 (CST) Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLM00KSQZK0NA@szxga05-in.huawei.com> for avtext@ietf.org; Mon, 23 May 2011 15:02:26 +0800 (CST) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 23 May 2011 15:02:21 +0800 Received: from x65217 (10.138.41.84) by smtpscn.huawei.com (10.82.67.31) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 23 May 2011 15:02:06 +0800 Date: Mon, 23 May 2011 15:02:05 +0800 From: Jinwei Xia In-reply-to: <4DD22058.8030007@ericsson.com> X-Originating-IP: [10.138.41.84] To: 'Magnus Westerlund' Message-id: <004b01cc1917$531aa8a0$54298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Thread-index: AcwUYjqiyatlKjeeSzOiTfkAMGItXQAF09OQ Cc: avtext@ietf.org Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 07:04:26 -0000 Hi Magnus=EF=BC=8C Sorry for my late response. > > I agree minimum-detectable is more appropriate. In=20 > > draft-xia-avtext-splicing-for-rtp-00, I mentioned the RTP header=20 > > parameters MUST remain consistent except that meida type SHOULD be=20 > > same since transcoding is prohibitively expensive and=20 > complex, so it =20 > > is RECOMMENDED to use same media type in insertion stream=20 > as that in=20 > > main stream. If an operator want to realize complete=20 > non-detectable on=20 > > client, he must take the tranacoding cost in account. > >=20 > > Moreover, Splicer SHOULD also realize minimum-detectable in=20 > > application layer, for example, reusing existing PIDs after=20 > a splicing=20 > > described in [SMPTE-321M]. How this is done is an implementation=20 > > detail and not discussed in this draft. > >=20 > > So how about above change?=20 > >=20 >=20 >=20 > I guess PIDs are protocol IDs. I think one needs to have a=20 > more detailed discussion on what IDs can be reused and when=20 > they can't. >=20 No, PID is packet identifier, a 13-bit ID to to identify elementary = stream of a program in MPEG2 transport stream.For each program, there is = one unique Program Map Table (PMT), each program includes multiple = streams (video, audio and metadata), each stream has its unique packet = identifier (PID).=20 Since splicing changes the contents of a transport stream, and the PIDs = (i.e., new PIDs in insertion stream), then the changes must be reflected = in valid PMT packets. Splicer are responsible for sending any changes to the PMT required to accommodate changes in the = number of PIDs after a splicing. However, in order to prevent commercial killing devices from taking = advantage of changes in PMT, systems with splicing are encouraged to = avoid changes to the PMT by reusing existing video and audio PIDs (i.e., = PIDs in original stream) after a splicing. > > an translator change the payload of RTP during splicing with SSRC=20 > > intact, should it use different keys for different segments? >=20 > For the payload internal stuff people are using, it can=20 > likely handle such key changes using security payload=20 > internal mechanism. The whole point with these payload=20 > internal mechanisms is that no entity between the content=20 > source and the decoder actually needs to have the key. >=20 > If one uses regular transport security like SRTP or DTLS, IPsec, etc. > then you need to re-process all the packets if you change=20 > something in them. Thus different key-context for the=20 > different legs makes sense. Right, we should narrow the security scope into transport security since = the we are discussing splicing in media transport area. The security = considerations will give the SRTP based security contexts in future = version. > >>> > >>> In non-detectable case, I personally incline to translator since=20 > >>> translator can totally eliminate the difference between the > >> two stream > >>> and erase the potential security issue. > >> > >> I think both can realize the non-detectable case. > >> > >=20 > > Yes, both can do that. The problem is which one is better.=20 > What's your=20 > > prefer in the two candidates or otherwise? >=20 > I think it comes down to how one wants to organize the=20 > splicer and the upstream content sources. To which degree=20 > they should aware of the splicer and if requiring changes to=20 > them are acceptable, specifically the original content source. >=20 > If modifying the original content source is out of the=20 > picture then I think a translator is the right way to go,=20 > although I believe it will require a bit more text to=20 > describe all the aspects one needs to think about. >=20 > If one can modify the original content source, then I think a=20 > mixer is more straight forward and thus easier to describe. >=20 > What the answer is to the modifying question I don't know.=20 > Input is desirable. >=20 I think this is a key point, but feeling a little confusion about above = analysis. Based on our previous discussion, whether translator or mixer = can act as splicer needs to take two aspects into account when = minimum-detectable requirement is supported. One aspect is bitrate = adaption to handle varying network condition, another is overhead on = splicer while splicing is not active. But neither seems to be related to = original content source changing requirement, do you mean the original = content source should reserve some gap in the content using some sort of = RTP empty packets during the gap time, or otherwise? Another confusing point is the mixer definition in RFC3550: "An = intermediate system that receives RTP packets from one or more sources, = possibly changes the data format, combines the packets in some manner = and then forwards a new RTP packet." I am not sure whether combine = implies a full mix, but a splicer does not combine packets in some = manner, it merely decides which of two streams to forward. > > Yes, this is inner implementation to fill up the gap. Using SSRC=20 > > multiplexing may be the most straight forward approach for=20 > detectable case. > >=20 >=20 > Yes, but also least likely to ensure glitch free media=20 > processing, at least before you have updated your receivers=20 > to include a few mechanisms to ensure that they can quickly=20 > and correctly create a common timeline. >=20 > Thus I think SSRC multiplexing is to quite a large degree a=20 > red herring in this case. It will not work well in legacy=20 > case, and even with updates it is still creating potential=20 > issues. Thus I think using a single SSRC and inserting the=20 > content into the stream is the most likely to work well. Agree, let's simplify the case and focus on a single SSRC. Thank you Jinwei >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 >=20 From xiajinwei@huawei.com Mon May 23 01:26:37 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48518E0769 for ; Mon, 23 May 2011 01:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.763 X-Spam-Level: X-Spam-Status: No, score=-1.763 tagged_above=-999 required=5 tests=[AWL=-1.268, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZke2sLijVAK for ; Mon, 23 May 2011 01:26:36 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 6FAD6E0766 for ; Mon, 23 May 2011 01:26:36 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLN00JJQ3GBW3@szxga05-in.huawei.com> for avtext@ietf.org; Mon, 23 May 2011 16:26:35 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLN0010I3G9QA@szxga05-in.huawei.com> for avtext@ietf.org; Mon, 23 May 2011 16:26:35 +0800 (CST) Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 23 May 2011 16:26:18 +0800 Received: from x65217 (10.138.41.84) by smtpscn.huawei.com (10.82.67.32) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 23 May 2011 16:26:08 +0800 Date: Mon, 23 May 2011 16:26:06 +0800 From: Jinwei Xia In-reply-to: X-Originating-IP: [10.138.41.84] To: 'Jinwei Xia' , 'Magnus Westerlund' , 'Colin Perkins' Message-id: <004d01cc1923$0fc9e0a0$54298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcwUYywIdcJp7rSRSz+lR9Nvpilz+QABrqZgAStnNbA= Cc: avtext@ietf.org Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 08:26:37 -0000 As an complement to my previous feedback. > > > > I agree that you need to have content to insert that is > very close to > > the space you are replacing. The question is what happens > when things > > are off with a video frame or less, or an audio frame or less. > > > > Your concern make senses, one of splicing requirements is > Splicer SHOULD NOT cause perceptible media clipping at the > splicing joint. Media source must schedule the splicing > point which usually is the boundary of two independently > decodable frames. When audio and video are not interleaved, > each audio frame is usually decodable for common audio > codecs. For video, some predicted frames need to depent on > other frames, so the splicing point is usually at the Group > of Pictures (GoP) boundary instead. > Meanwhile, the insertion media source or splicer must schedule that the duration of insertion content properly matches the gap time, i.e., starting with an independently decodable frame and ending with another one. Moreover, to reduce the playout latency, splicer may fill some specific information (e.g., preamble information for rapid demultiplexing and decoding insertion content) up the user's buffer with serval seconds earlier before the presentation time of the insertion content. Jinwei From csp@csperkins.org Mon May 23 03:54:05 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7844E078A for ; Mon, 23 May 2011 03:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.33 X-Spam-Level: X-Spam-Status: No, score=-103.33 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNVaS59Anw6C for ; Mon, 23 May 2011 03:54:04 -0700 (PDT) Received: from anchor-msapost-1.mail.demon.net (anchor-msapost-1.mail.demon.net [195.173.77.164]) by ietfa.amsl.com (Postfix) with ESMTP id 9F619E0786 for ; Mon, 23 May 2011 03:54:04 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by anchor-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1QOSlu-00001L-hw; Mon, 23 May 2011 10:54:02 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Colin Perkins In-Reply-To: <4DD2214C.1050805@ericsson.com> Date: Mon, 23 May 2011 11:54:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <42CE2B69-91AB-408C-9F0B-A94DC49C9F42@csperkins.org> References: <017201cc0e22$0aec3170$54298a0a@china.huawei.com> <4DCBA5FF.8040307@ericsson.com> <0EA52F7A-E495-40F3-8DA3-F92474406469@csperkins.org> <4DD2214C.1050805@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1084) Cc: "avtext@ietf.org" Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 10:54:05 -0000 On 17 May 2011, at 08:18, Magnus Westerlund wrote: > On 2011-05-16 12:47, Colin Perkins wrote: >>>> In detectable case, the thing becomes simpler. translator is = suitable to handle detectable splicing. When splicing ends, translator = resumes main stream and rewrites the sequence number one higher than the = last packet sent to receiver in the main stream. There is a little = overhead on translator to rewrite RTP SN.=20 >>>=20 >>> What about the TS? I think that may become inconsistent and thus = needs rewriting also. >>=20 >> I'd think it reasonable to require that the inserted content MUST be = the same duration as the original content. Otherwise, not only will you = need to rewrite the timestamps after the splicing has ended, you'll = either have a gap or extra data to be buffered somewhere. You'll only = have to rewrite timestamps during the splicing, to normalise the random = offset. >=20 > I agree that you need to have content to insert that is very close to = the space you are replacing. The question is what happens when things = are off with a video frame or less, or an audio frame or less. >=20 > One thing to worry about here is what happens if the frame rate varies = between the content, then you may have a small diff to take care of. = Yes, letting that be a bit extra delay between content in the point of = switching is back is likely fine, but it needs to be discussed in the = document. Okay, this makes sense. I guess providing the inserted content is not = longer than the gap, there's no real problem, and the draft just needs = to mention the issue. If the inserted content might be longer, then = things get a little more complex. > I might have made the impression that this issue is bigger than it = really is. >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext --=20 Colin Perkins http://csperkins.org/ From csp@csperkins.org Mon May 23 03:58:13 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58384E079B for ; Mon, 23 May 2011 03:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.384 X-Spam-Level: X-Spam-Status: No, score=-103.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQFX-GN8qlk8 for ; Mon, 23 May 2011 03:58:12 -0700 (PDT) Received: from anchor-msapost-1.mail.demon.net (anchor-msapost-1.mail.demon.net [195.173.77.164]) by ietfa.amsl.com (Postfix) with ESMTP id 5D901E0791 for ; Mon, 23 May 2011 03:58:12 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by anchor-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1QOSpv-0001rW-iT; Mon, 23 May 2011 10:58:11 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <004d01cc1923$0fc9e0a0$54298a0a@china.huawei.com> Date: Mon, 23 May 2011 11:58:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5CB5E60D-E191-4FD4-925F-0D2ABE98CE6D@csperkins.org> References: <004d01cc1923$0fc9e0a0$54298a0a@china.huawei.com> To: Jinwei Xia X-Mailer: Apple Mail (2.1084) Cc: avtext@ietf.org Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 10:58:13 -0000 On 23 May 2011, at 09:26, Jinwei Xia wrote: > As an complement to my previous feedback. >=20 >>> I agree that you need to have content to insert that is very close = to the space you are replacing. The question is what happens when things = are off with a video frame or less, or an audio frame or less. >>=20 >> Your concern make senses, one of splicing requirements is Splicer = SHOULD NOT cause perceptible media clipping at the splicing joint. = Media source must schedule the splicing point which usually is the = boundary of two independently decodable frames. When audio and video are = not interleaved, each audio frame is usually decodable for common audio = codecs. For video, some predicted frames need to depent on other frames, = so the splicing point is usually at the Group of Pictures (GoP) boundary = instead. >=20 > Meanwhile, the insertion media source or splicer must schedule that = the duration of insertion content properly matches the gap time, i.e., = starting with an independently decodable frame and ending with another = one. >=20 > Moreover, to reduce the playout latency, splicer may fill some = specific information (e.g., preamble information for rapid = demultiplexing and decoding insertion content) up the user's buffer with = serval seconds earlier before the presentation time of the insertion = content. That will need careful specification, since the requirements for = rewriting the RTP headers in this case are tricky. --=20 Colin Perkins http://csperkins.org/ From csp@csperkins.org Mon May 23 04:03:43 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 032F1E0785 for ; Mon, 23 May 2011 04:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.419 X-Spam-Level: X-Spam-Status: No, score=-103.419 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0WVNKvZx+tU for ; Mon, 23 May 2011 04:03:41 -0700 (PDT) Received: from lon1-msapost-1.mail.demon.net (lon1-msapost-1.mail.demon.net [195.173.77.180]) by ietfa.amsl.com (Postfix) with ESMTP id 9F0DBE06AF for ; Mon, 23 May 2011 04:03:41 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by lon1-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1QOSvE-0005ic-YO; Mon, 23 May 2011 11:03:40 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Colin Perkins In-Reply-To: <004b01cc1917$531aa8a0$54298a0a@china.huawei.com> Date: Mon, 23 May 2011 12:03:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9379B9D5-63AD-4226-803B-7CF49628FC44@csperkins.org> References: <004b01cc1917$531aa8a0$54298a0a@china.huawei.com> To: Jinwei Xia X-Mailer: Apple Mail (2.1084) Cc: avtext@ietf.org Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 11:03:43 -0000 On 23 May 2011, at 08:02, Jinwei Xia wrote: > Hi Magnus=EF=BC=8C >=20 > Sorry for my late response. >=20 >>> I agree minimum-detectable is more appropriate. In = draft-xia-avtext-splicing-for-rtp-00, I mentioned the RTP header = parameters MUST remain consistent except that meida type SHOULD be same = since transcoding is prohibitively expensive and complex, so it is = RECOMMENDED to use same media type in insertion stream as that in main = stream. If an operator want to realize complete non-detectable on = client, he must take the tranacoding cost in account. >>>=20 >>> Moreover, Splicer SHOULD also realize minimum-detectable in = application layer, for example, reusing existing PIDs after a splicing = described in [SMPTE-321M]. How this is done is an implementation detail = and not discussed in this draft. >>>=20 >>> So how about above change?=20 >>=20 >> I guess PIDs are protocol IDs. I think one needs to have a more = detailed discussion on what IDs can be reused and when they can't. >=20 > No, PID is packet identifier, a 13-bit ID to to identify elementary = stream of a program in MPEG2 transport stream.For each program, there is = one unique Program Map Table (PMT), each program includes multiple = streams (video, audio and metadata), each stream has its unique packet = identifier (PID).=20 >=20 > Since splicing changes the contents of a transport stream, and the = PIDs (i.e., new PIDs in insertion stream), then the changes must be = reflected in valid PMT packets. Splicer are responsible for sending any = changes to the PMT required to accommodate changes in the number of PIDs = after a splicing. >=20 > However, in order to prevent commercial killing devices from taking = advantage of changes in PMT, systems with splicing are encouraged to = avoid changes to the PMT by reusing existing video and audio PIDs (i.e., = PIDs in original stream) after a splicing. This sounds like something that should be specified by MPEG, not by = IETF. Is there an MPEG document that this draft can reference to discuss = how MPEG-specific payload data is manipulated? >>> an translator change the payload of RTP during splicing with SSRC = intact, should it use different keys for different segments? >>=20 >> For the payload internal stuff people are using, it can likely handle = such key changes using security payload internal mechanism. The whole = point with these payload internal mechanisms is that no entity between = the content source and the decoder actually needs to have the key. >>=20 >> If one uses regular transport security like SRTP or DTLS, IPsec, etc. = then you need to re-process all the packets if you change something in = them. Thus different key-context for the different legs makes sense. >=20 > Right, we should narrow the security scope into transport security = since the we are discussing splicing in media transport area. The = security considerations will give the SRTP based security contexts in = future version. People are using payload internal security, so it needs to be mentioned = in the draft, but (as this the PID stuff), it should probably be by = reference to some other document. >>>>> In non-detectable case, I personally incline to translator since = translator can totally eliminate the difference between the two stream = and erase the potential security issue. >>>>=20 >>>> I think both can realize the non-detectable case. >>>>=20 >>>=20 >>> Yes, both can do that. The problem is which one is better. What's = your prefer in the two candidates or otherwise? >>=20 >> I think it comes down to how one wants to organize the=20 >> splicer and the upstream content sources. To which degree=20 >> they should aware of the splicer and if requiring changes to=20 >> them are acceptable, specifically the original content source. >>=20 >> If modifying the original content source is out of the=20 >> picture then I think a translator is the right way to go,=20 >> although I believe it will require a bit more text to=20 >> describe all the aspects one needs to think about. >>=20 >> If one can modify the original content source, then I think a=20 >> mixer is more straight forward and thus easier to describe. >>=20 >> What the answer is to the modifying question I don't know.=20 >> Input is desirable. >>=20 >=20 > I think this is a key point, but feeling a little confusion about = above analysis. Based on our previous discussion, whether translator or = mixer can act as splicer needs to take two aspects into account when = minimum-detectable requirement is supported. One aspect is bitrate = adaption to handle varying network condition, another is overhead on = splicer while splicing is not active. But neither seems to be related to = original content source changing requirement, do you mean the original = content source should reserve some gap in the content using some sort of = RTP empty packets during the gap time, or otherwise? >=20 > Another confusing point is the mixer definition in RFC3550: "An = intermediate system that receives RTP packets from one or more sources, = possibly changes the data format, combines the packets in some manner = and then forwards a new RTP packet." I am not sure whether combine = implies a full mix, but a splicer does not combine packets in some = manner, it merely decides which of two streams to forward. >=20 >>> Yes, this is inner implementation to fill up the gap. Using SSRC = multiplexing may be the most straight forward approach for detectable = case. >>=20 >> Yes, but also least likely to ensure glitch free media processing, at = least before you have updated your receivers to include a few mechanisms = to ensure that they can quickly and correctly create a common timeline. >>=20 >> Thus I think SSRC multiplexing is to quite a large degree a red = herring in this case. It will not work well in legacy case, and even = with updates it is still creating potential issues. Thus I think using a = single SSRC and inserting the content into the stream is the most likely = to work well. >=20 > Agree, let's simplify the case and focus on a single SSRC. I think the draft would be much clearer if it focussed on either = non-detectable (e.g., using a translator) or detectable splicing, and = didn't try to discuss both. --=20 Colin Perkins http://csperkins.org/ From xiajinwei@huawei.com Mon May 23 20:25:57 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56B93E0688 for ; Mon, 23 May 2011 20:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.498 X-Spam-Level: X-Spam-Status: No, score=-4.498 tagged_above=-999 required=5 tests=[AWL=2.101, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FidJFpyo1kiV for ; Mon, 23 May 2011 20:25:56 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 43B25E06AA for ; Mon, 23 May 2011 20:25:56 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLO002HEK7638@szxga04-in.huawei.com> for avtext@ietf.org; Tue, 24 May 2011 11:25:54 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LLO00G8HK72NX@szxga04-in.huawei.com> for avtext@ietf.org; Tue, 24 May 2011 11:25:53 +0800 (CST) Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 24 May 2011 11:25:45 +0800 Received: from x65217 (10.138.41.84) by smtpscn.huawei.com (10.82.67.31) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 24 May 2011 11:25:38 +0800 Date: Tue, 24 May 2011 11:25:38 +0800 From: Jinwei Xia In-reply-to: <9379B9D5-63AD-4226-803B-7CF49628FC44@csperkins.org> X-Originating-IP: [10.138.41.84] To: 'Colin Perkins' Message-id: <004801cc19c2$40c824b0$54298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcwZOSAkqDbOf6UnR7ml0f7nbwVp7QAeUTsg Cc: avtext@ietf.org Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 03:25:57 -0000 Hi Colin, > >> > >> I guess PIDs are protocol IDs. I think one needs to have a > more detailed discussion on what IDs can be reused and when > they can't. > > > > No, PID is packet identifier, a 13-bit ID to to identify > elementary stream of a program in MPEG2 transport stream.For > each program, there is one unique Program Map Table (PMT), > each program includes multiple streams (video, audio and > metadata), each stream has its unique packet identifier (PID). > > > > Since splicing changes the contents of a transport stream, > and the PIDs (i.e., new PIDs in insertion stream), then the > changes must be reflected in valid PMT packets. Splicer are > responsible for sending any changes to the PMT required to > accommodate changes in the number of PIDs after a splicing. > > > > However, in order to prevent commercial killing devices > from taking advantage of changes in PMT, systems with > splicing are encouraged to avoid changes to the PMT by > reusing existing video and audio PIDs (i.e., PIDs in original > stream) after a splicing. > > This sounds like something that should be specified by MPEG, > not by IETF. Is there an MPEG document that this draft can > reference to discuss how MPEG-specific payload data is manipulated? Right, above description is about MPEG splicing, I just interprets how non-detectable splicing is done in application layer herein, but would not include above description in draft. There are several MPEG-splicing references in SCTE and SMPTE STDs. > > >>> an translator change the payload of RTP during splicing > with SSRC intact, should it use different keys for different segments? > >> > >> For the payload internal stuff people are using, it can > likely handle such key changes using security payload > internal mechanism. The whole point with these payload > internal mechanisms is that no entity between the content > source and the decoder actually needs to have the key. > >> > >> If one uses regular transport security like SRTP or DTLS, > IPsec, etc. then you need to re-process all the packets if > you change something in them. Thus different key-context for > the different legs makes sense. > > > > Right, we should narrow the security scope into transport > security since the we are discussing splicing in media > transport area. The security considerations will give the > SRTP based security contexts in future version. > > People are using payload internal security, so it needs to be > mentioned in the draft, but (as this the PID stuff), it > should probably be by reference to some other document. > Accept > >> Thus I think SSRC multiplexing is to quite a large degree > a red herring in this case. It will not work well in legacy > case, and even with updates it is still creating potential > issues. Thus I think using a single SSRC and inserting the > content into the stream is the most likely to work well. > > > > Agree, let's simplify the case and focus on a single SSRC. > > > I think the draft would be much clearer if it focussed on > either non-detectable (e.g., using a translator) or > detectable splicing, and didn't try to discuss both. > Both cases can be discussed in the maillist with wide scope, but if there should be only one solution in a single draft, I prefer to address minimum-detectable case. Thank you. Jinwei > -- > Colin Perkins > http://csperkins.org/ > > > From internet-drafts@ietf.org Thu May 26 09:37:01 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63390E0764; Thu, 26 May 2011 09:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAioZAXiYStt; Thu, 26 May 2011 09:37:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E48E3E06D6; Thu, 26 May 2011 09:37:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110526163700.21794.69442.idtracker@ietfa.amsl.com> Date: Thu, 26 May 2011 09:37:00 -0700 Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-multicast-acq-rtcp-xr-05.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 16:37:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Extensions Work= ing Group of the IETF. Title : Multicast Acquisition Report Block Type for RTP Control = Protocol (RTCP) Extended Reports (XRs) Author(s) : Ali Begen Eric Friedrich Filename : draft-ietf-avtext-multicast-acq-rtcp-xr-05.txt Pages : 22 Date : 2011-05-26 In most RTP-based multicast applications, the RTP source sends inter- related data. Due to this interdependency, randomly joining RTP receivers usually cannot start consuming the multicast data right after they join the session. Thus, they often experience a random acquisition delay. An RTP receiver can use one or more different approaches to achieve rapid acquisition. Yet, due to various factors, performance of the rapid acquisition methods usually varies. Furthermore, in some cases the RTP receiver can do a simple multicast join (in other cases it is compelled to do so). For quality reporting, monitoring and diagnostics purposes, it is important to collect detailed information from the RTP receivers about their acquisition and presentation experiences. This document addresses this issue by defining a new report block type, called Multicast Acquisition (MA) Report Block, within the framework of RTP Control Protocol (RTCP) Extended Reports (XR) (RFC 3611). This document also defines the necessary signaling of the new MA report block type in the Session Description Protocol (SDP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtext-multicast-acq-rtcp-xr= -05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtext-multicast-acq-rtcp-xr-= 05.txt From csp@csperkins.org Sun May 29 04:40:22 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9B3E0719 for ; Sun, 29 May 2011 04:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.219 X-Spam-Level: X-Spam-Status: No, score=-103.219 tagged_above=-999 required=5 tests=[AWL=0.380, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqFwxJe5o-25 for ; Sun, 29 May 2011 04:40:20 -0700 (PDT) Received: from anchor-msapost-2.mail.demon.net (anchor-msapost-2.mail.demon.net [195.173.77.165]) by ietfa.amsl.com (Postfix) with ESMTP id AA7B1E071F for ; Sun, 29 May 2011 04:40:20 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.21]) by anchor-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1QQeKA-0004A8-jm; Sun, 29 May 2011 11:38:26 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <4DD10D68.1090302@ericsson.com> Date: Sun, 29 May 2011 12:38:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <46E4318B-57EE-4F88-9A87-E65103442735@csperkins.org> References: <4DD10D68.1090302@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1084) Cc: "avtext@ietf.org" Subject: Re: [avtext] Call for adopting document for mile stone "Support for multiple clock rates in an RTP session for Proposed Standard" X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2011 11:40:22 -0000 On 16 May 2011, at 12:41, Magnus Westerlund wrote: > AVTEXT has one milestone: >=20 > Dec 2011 Submit Support for multiple clock rates in an RTP session > for Proposed Standard >=20 > We have one candidate document: >=20 > = https://datatracker.ietf.org/doc/draft-petithuguenin-avtext-multiple-clock= -rates/ >=20 > This is the call to the WG if we want to adopt this document as the > basis for meeting that milestone? Please provide comments even if it = is > just "Yes". I've read this, and think that it's useful, and should be adopted.=20 --=20 Colin Perkins http://csperkins.org/ From internet-drafts@ietf.org Sun May 29 07:45:27 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3F1E0743; Sun, 29 May 2011 07:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UIV3YU6v6dDP; Sun, 29 May 2011 07:45:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5CC4E0662; Sun, 29 May 2011 07:45:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110529144526.620.45673.idtracker@ietfa.amsl.com> Date: Sun, 29 May 2011 07:45:26 -0700 Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-multicast-acq-rtcp-xr-06.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2011 14:45:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Extensions Work= ing Group of the IETF. Title : Multicast Acquisition Report Block Type for RTP Control = Protocol (RTCP) Extended Reports (XRs) Author(s) : Ali Begen Eric Friedrich Filename : draft-ietf-avtext-multicast-acq-rtcp-xr-06.txt Pages : 21 Date : 2011-05-29 In most RTP-based multicast applications, the RTP source sends inter- related data. Due to this interdependency, randomly joining RTP receivers usually cannot start consuming the multicast data right after they join the session. Thus, they often experience a random acquisition delay. An RTP receiver can use one or more different approaches to achieve rapid acquisition. Yet, due to various factors, performance of the rapid acquisition methods usually varies. Furthermore, in some cases the RTP receiver can do a simple multicast join (in other cases it is compelled to do so). For quality reporting, monitoring and diagnostics purposes, it is important to collect detailed information from the RTP receivers about their acquisition and presentation experiences. This document addresses this issue by defining a new report block type, called Multicast Acquisition (MA) Report Block, within the framework of RTP Control Protocol (RTCP) Extended Reports (XR) (RFC 3611). This document also defines the necessary signaling of the new MA report block type in the Session Description Protocol (SDP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtext-multicast-acq-rtcp-xr= -06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtext-multicast-acq-rtcp-xr-= 06.txt From magnus.westerlund@ericsson.com Tue May 31 01:23:56 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4745DE07EF for ; Tue, 31 May 2011 01:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.259 X-Spam-Level: X-Spam-Status: No, score=-106.259 tagged_above=-999 required=5 tests=[AWL=0.340, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MtSDdsFPP0X6 for ; Tue, 31 May 2011 01:23:55 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id A0A02E064A for ; Tue, 31 May 2011 01:23:53 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-d2-4de4a5978b60 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id D0.3B.20773.795A4ED4; Tue, 31 May 2011 10:23:52 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Tue, 31 May 2011 10:23:47 +0200 Message-ID: <4DE4A593.7080502@ericsson.com> Date: Tue, 31 May 2011 10:23:47 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: avtext@ietf.org References: <4DD10D68.1090302@ericsson.com> In-Reply-To: <4DD10D68.1090302@ericsson.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [avtext] Call for adopting document for mile stone "Support for multiple clock rates in an RTP session for Proposed Standard" X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 08:23:56 -0000 As Individual I would like to support this adoption. Magnus On 2011-05-16 13:41, Magnus Westerlund wrote: > WG, > > AVTEXT has one milestone: > > Dec 2011 Submit Support for multiple clock rates in an RTP session > for Proposed Standard > > We have one candidate document: > > https://datatracker.ietf.org/doc/draft-petithuguenin-avtext-multiple-clock-rates/ > > This is the call to the WG if we want to adopt this document as the > basis for meeting that milestone? Please provide comments even if it is > just "Yes". > > If you think there is some aspect of the issue or the solution that > hasn't been discussed and you want to ensure is covered, please comment > on that. > > The WG chairs will make a decision on 31st of May based on your comments. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From musgravepj@gmail.com Tue May 31 04:03:01 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3028AE070A for ; Tue, 31 May 2011 04:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.379 X-Spam-Level: X-Spam-Status: No, score=-3.379 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1B+xxvfuqXvJ for ; Tue, 31 May 2011 04:03:00 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 22896E06DC for ; Tue, 31 May 2011 04:02:59 -0700 (PDT) Received: by fxm15 with SMTP id 15so3360783fxm.31 for ; Tue, 31 May 2011 04:02:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=KYL5h3gQS0GpVSIGB2GwQZJJrjXgzTl/VQ1EtbUcgGs=; b=bzo9Q4aHnqgOvSEfPJfK6SGM7iTikroOYaH6wGSSFYGMuaJPDPoWiRWA3ZHA1OmoM2 MAZlv6jY4DpfY2D+9XNaVHtYfMOSdQA9mdRNH4ipJQdPQXUrz3kRssucWmnzyWbjY1Rj sowTEpnOXijhPDixqHukJg2cE2cZRj4fCVRbk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=aV2xGANwXr/q49+B+npw6zYbuDuRKM1LklHpSDuimuDS6X6BgiDRevXbSc5gYS/1W4 NrOU/4d4suuPvC692287z0zOtKlYzCwGRGz7hXa1M8qAEjins0+IBGHwJKgeZThwC/tY 5wN84dIlTSVJk0IHAue11R77H5sOI3M1JaH+w= MIME-Version: 1.0 Received: by 10.223.71.204 with SMTP id i12mr2614610faj.65.1306839779252; Tue, 31 May 2011 04:02:59 -0700 (PDT) Received: by 10.223.109.212 with HTTP; Tue, 31 May 2011 04:02:59 -0700 (PDT) In-Reply-To: <4DE4A593.7080502@ericsson.com> References: <4DD10D68.1090302@ericsson.com> <4DE4A593.7080502@ericsson.com> Date: Tue, 31 May 2011 07:02:59 -0400 Message-ID: From: Peter Musgrave To: avtext@ietf.org Content-Type: multipart/alternative; boundary=20cf3054a8c1d21bbe04a49058f4 Subject: Re: [avtext] Call for adopting document for mile stone "Support for multiple clock rates in an RTP session for Proposed Standard" X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 11:03:01 -0000 --20cf3054a8c1d21bbe04a49058f4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1 Peter Musgrave On Tue, May 31, 2011 at 4:23 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > As Individual I would like to support this adoption. > > Magnus > > On 2011-05-16 13:41, Magnus Westerlund wrote: > > WG, > > > > AVTEXT has one milestone: > > > > Dec 2011 Submit Support for multiple clock rates in an RTP session > > for Proposed Standard > > > > We have one candidate document: > > > > > https://datatracker.ietf.org/doc/draft-petithuguenin-avtext-multiple-cloc= k-rates/ > > > > This is the call to the WG if we want to adopt this document as the > > basis for meeting that milestone? Please provide comments even if it is > > just "Yes". > > > > If you think there is some aspect of the issue or the solution that > > hasn't been discussed and you want to ensure is covered, please comment > > on that. > > > > The WG chairs will make a decision on 31st of May based on your comment= s. > > > > Cheers > > > > Magnus Westerlund > > > > ---------------------------------------------------------------------- > > Multimedia Technologies, Ericsson Research EAB/TVM > > ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 10 7148287 > > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > > ---------------------------------------------------------------------- > > > > _______________________________________________ > > avtext mailing list > > avtext@ietf.org > > https://www.ietf.org/mailman/listinfo/avtext > > > > > -- > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext > --20cf3054a8c1d21bbe04a49058f4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1=A0

Peter Musgrave

O= n Tue, May 31, 2011 at 4:23 AM, Magnus Westerlund <magnus.westerlund@ericsson.c= om> wrote:
As Individual I would like to support this = adoption.

Magnus

On 2011-05-16 13:41, Magnus Westerlund wrote:
> WG,
>
> AVTEXT has one milestone:
>
> Dec 2011 Submit Support for multiple clock rates in an RTP session
> =A0 =A0 =A0 =A0 =A0for Proposed Standard
>
> We have one candidate document:
>
> https://datatracker.ietf.org/doc/= draft-petithuguenin-avtext-multiple-clock-rates/
>
> This is the call to the WG if we want to adopt this document as the > basis for meeting that milestone? Please provide comments even if it i= s
> just "Yes".
>
> If you think there is some aspect of the issue or the solution t= hat
> hasn't been discussed and you want to ensure is covered, please co= mment
> on that.
>
> The WG chairs will make a decision on 31st of May based on your commen= ts.
>
> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------=
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------=
> Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287
> F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------=
>
> _______________________________________________
> avtext mailing list
> avtext@ietf.org
> https://www.ietf.org/mailman/listinfo/avtext
>


--

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287
F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

_______________________________________________
avtext mailing list
avtext@ietf.org
= https://www.ietf.org/mailman/listinfo/avtext

--20cf3054a8c1d21bbe04a49058f4-- From abegen@cisco.com Tue May 31 07:42:09 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 074F8E06A0 for ; Tue, 31 May 2011 07:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.572 X-Spam-Level: X-Spam-Status: No, score=-10.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rSeJvh4CMWl for ; Tue, 31 May 2011 07:42:04 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id CC248E068E for ; Tue, 31 May 2011 07:42:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=2631; q=dns/txt; s=iport; t=1306852924; x=1308062524; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=mhuM+IkE1bzGllgFEXLbcwPjQz+3eik94Vyeoso2jAE=; b=dUgVGaa0QV25KlLG01vq55dTM3kgJW8CueBO8iUjTgit6SmhQwfsTNIx u00+gGyrxqRgGI+Pv07fC+Cb+QjgfLF7J5XxKPzUWpab8+55RTiG9l0DE pQMmVS+AiG3Zv26w0NqkFz9d2LcwNunU1iQByj0IgbMN4vLH3ZGx8Jmv9 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYBAMH85E2rRDoH/2dsb2JhbABTl0uOUneoSp1TAoYcBIZkjjKKcw X-IronPort-AV: E=Sophos;i="4.65,297,1304294400"; d="scan'208";a="367322400" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-2.cisco.com with ESMTP; 31 May 2011 14:42:01 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4VEg1aA004034; Tue, 31 May 2011 14:42:01 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 31 May 2011 07:42:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Tue, 31 May 2011 07:41:59 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540F20DB8B@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4DE4A593.7080502@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [avtext] Call for adopting document for mile stone "Support for multiple clock rates in an RTP session for Proposed Standard" Thread-Index: AcwfbBrWNGXeTZGfRHqSecGTZ+likwANLucA References: <4DD10D68.1090302@ericsson.com> <4DE4A593.7080502@ericsson.com> From: "Ali C. Begen (abegen)" To: "Magnus Westerlund" , X-OriginalArrivalTime: 31 May 2011 14:42:01.0234 (UTC) FILETIME=[E6AEB720:01CC1FA0] Subject: Re: [avtext] Call for adopting document for mile stone "Support for multiple clock rates in an RTP session for Proposed Standard" X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 14:42:09 -0000 I will repeat my earlier support here again for adopting this. -acbegen > -----Original Message----- > From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On = Behalf Of Magnus Westerlund > Sent: Tuesday, May 31, 2011 4:24 AM > To: avtext@ietf.org > Subject: Re: [avtext] Call for adopting document for mile stone = "Support for multiple clock rates in an RTP session for > Proposed Standard" >=20 > As Individual I would like to support this adoption. >=20 > Magnus >=20 > On 2011-05-16 13:41, Magnus Westerlund wrote: > > WG, > > > > AVTEXT has one milestone: > > > > Dec 2011 Submit Support for multiple clock rates in an RTP session > > for Proposed Standard > > > > We have one candidate document: > > > > = https://datatracker.ietf.org/doc/draft-petithuguenin-avtext-multiple-cloc= k-rates/ > > > > This is the call to the WG if we want to adopt this document as the > > basis for meeting that milestone? Please provide comments even if it = is > > just "Yes". > > > > If you think there is some aspect of the issue or the solution that > > hasn't been discussed and you want to ensure is covered, please = comment > > on that. > > > > The WG chairs will make a decision on 31st of May based on your = comments. > > > > Cheers > > > > Magnus Westerlund > > > > = ---------------------------------------------------------------------- > > Multimedia Technologies, Ericsson Research EAB/TVM > > = ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 10 7148287 > > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > > = ---------------------------------------------------------------------- > > > > _______________________________________________ > > avtext mailing list > > avtext@ietf.org > > https://www.ietf.org/mailman/listinfo/avtext > > >=20 >=20 > -- >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From ray.vanbrandenburg@tno.nl Tue May 31 07:53:51 2011 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF15EE070E for ; Tue, 31 May 2011 07:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJGiBlGXMKZc for ; Tue, 31 May 2011 07:53:47 -0700 (PDT) Received: from mailouta.tno.nl (mailouta.tno.nl [134.221.1.16]) by ietfa.amsl.com (Postfix) with ESMTP id 6ABFAE078F for ; Tue, 31 May 2011 07:53:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.65,297,1304287200"; d="scan'208";a="52535957" Received: from unknown (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1a.tno.nl with ESMTP; 31 May 2011 16:53:45 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.44]) by EXC-CASHUB03.tsn.tno.nl ([134.221.225.222]) with mapi id 14.01.0270.001; Tue, 31 May 2011 16:53:45 +0200 From: "Brandenburg, R. (Ray) van" To: "avtext@ietf.org" Thread-Topic: [avtext] Call for adopting document for mile stone "Support for multiple clock rates in an RTP session for Proposed Standard" Thread-Index: AQHMH6KJwaYZPd3iXECF6sQ9Aw6t1g== Date: Tue, 31 May 2011 14:53:44 +0000 Message-ID: References: <4DD10D68.1090302@ericsson.com> <4DE4A593.7080502@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540F20DB8B@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540F20DB8B@xmb-sjc-215.amer.cisco.com> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.191] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [avtext] Call for adopting document for mile stone "Support for multiple clock rates in an RTP session for Proposed Standard" X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 14:53:52 -0000 I support this document and am willing to review future versions.=20 Ray van Brandenburg > -----Original Message----- > From: avtext-bounces@ietf.org [mailto:avtext-bounces@ietf.org] On=20 > Behalf Of Magnus Westerlund > Sent: Tuesday, May 31, 2011 4:24 AM > To: avtext@ietf.org > Subject: Re: [avtext] Call for adopting document for mile stone=20 > "Support for multiple clock rates in an RTP session for Proposed Standard" >=20 > As Individual I would like to support this adoption. >=20 > Magnus >=20 > On 2011-05-16 13:41, Magnus Westerlund wrote: > > WG, > > > > AVTEXT has one milestone: > > > > Dec 2011 Submit Support for multiple clock rates in an RTP session > > for Proposed Standard > > > > We have one candidate document: > > > > https://datatracker.ietf.org/doc/draft-petithuguenin-avtext-multiple > > -clock-rates/ > > > > This is the call to the WG if we want to adopt this document as the=20 > > basis for meeting that milestone? Please provide comments even if it=20 > > is just "Yes". > > > > If you think there is some aspect of the issue or the solution that=20 > > hasn't been discussed and you want to ensure is covered, please=20 > > comment on that. > > > > The WG chairs will make a decision on 31st of May based on your comment= s. > > > > Cheers > > > > Magnus Westerlund > > > > -------------------------------------------------------------------- > > -- Multimedia Technologies, Ericsson Research EAB/TVM > > ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 10 7148287 > > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > > -------------------------------------------------------------------- > > -- > > > > _______________________________________________ > > avtext mailing list > > avtext@ietf.org > > https://www.ietf.org/mailman/listinfo/avtext > > >=20 >=20 > -- >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext _______________________________________________ avtext mailing list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer