From iesg-secretary@ietf.org Mon Nov 7 15:21:19 2011 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D53D711E80B9; Mon, 7 Nov 2011 15:21:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWv2JTDT4t6k; Mon, 7 Nov 2011 15:21:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 339E411E80BD; Mon, 7 Nov 2011 15:21:19 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.63 Message-ID: <20111107232119.9401.88121.idtracker@ietfa.amsl.com> Date: Mon, 07 Nov 2011 15:21:19 -0800 Cc: payload chair , payload mailing list , RFC Editor Subject: [payload] Protocol Action: 'RTP Payload Format for DV (IEC 61834) Video' to Proposed Standard (draft-ietf-payload-rfc3189bis-03.txt) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 23:21:20 -0000 The IESG has approved the following document: - 'RTP Payload Format for DV (IEC 61834) Video' (draft-ietf-payload-rfc3189bis-03.txt) as a Proposed Standard This document is the product of the Audio/Video Transport Payloads Working Group. The IESG contact persons are Robert Sparks and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-payload-rfc3189bis/ Technical Summary This document specifies the packetization scheme for encapsulating the compressed digital video data streams commonly known as "DV" into a payload format for the Real-Time Transport Protocol (RTP). This document obsoletes RFC 3189. Working Group Summary This is a product of the PAYLOAD working group. It is an update to an existing payload type. There was no controversy during its development. It only received detail by a few (but sufficient set of) working group members. Document Quality This is an update to an existing payload type reflecting advances in related standards work. The document contains an interoperability with Previous Implementations section. The request for media type review was posted on July 11, 2011. DV is used in The Society of Motion Picture and Television Engineers (SMPTE) standards. From internet-drafts@ietf.org Tue Nov 15 03:19:15 2011 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7DEA21F8FA5; Tue, 15 Nov 2011 03:19:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PEFHDyfKh784; Tue, 15 Nov 2011 03:19:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD4221F8F9D; Tue, 15 Nov 2011 03:19:15 -0800 (PST) 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.63 Message-ID: <20111115111915.17351.81081.idtracker@ietfa.amsl.com> Date: Tue, 15 Nov 2011 03:19:15 -0800 Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-g718-01.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 11:19:15 -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 Payloads Workin= g Group of the IETF. Title : RTP Payload Format for G.718 Speech/Audio Author(s) : Glen Zorn Ye-Kui Wang Ari Lakaniemi Filename : draft-ietf-payload-rtp-g718-01.txt Pages : 27 Date : 2011-11-15 This document specifies the Real-Time Transport Protocol (RTP) payload format for the Embedded Variable Bit-Rate (EV-VBR) speech/ audio codec, specified in ITU-T G.718. A media type registration for this RTP payload format is also included. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-payload-rtp-g718-01.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-payload-rtp-g718-01.txt From internet-drafts@ietf.org Thu Nov 17 00:06:59 2011 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEE9211E8151; Thu, 17 Nov 2011 00:06:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Knlj8WfL3NpR; Thu, 17 Nov 2011 00:06:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2DB11E80E3; Thu, 17 Nov 2011 00:06:58 -0800 (PST) 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.64 Message-ID: <20111117080658.5626.80081.idtracker@ietfa.amsl.com> Date: Thu, 17 Nov 2011 00:06:58 -0800 Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-vp8-02.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 08:06:59 -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 Payloads Workin= g Group of the IETF. Title : RTP Payload Format for VP8 Video Author(s) : Patrik Westin Henrik F Lundin Michael Glover Justin Uberti Frank Galligan Filename : draft-ietf-payload-vp8-02.txt Pages : 27 Date : 2011-11-17 This memo describes an RTP payload format for the VP8 video codec. The payload format has wide applicability, as it supports applications from low bit-rate peer-to-peer usage, to high bit-rate video conferences. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-payload-vp8-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-payload-vp8-02.txt From HKaplan@acmepacket.com Mon Nov 21 09:59:59 2011 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0D6A21F8B18; Mon, 21 Nov 2011 09:59:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+dFJMloF-vH; Mon, 21 Nov 2011 09:59:59 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 038F421F8AAA; Mon, 21 Nov 2011 09:59:58 -0800 (PST) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 21 Nov 2011 12:59:55 -0500 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Mon, 21 Nov 2011 12:59:55 -0500 From: Hadriel Kaplan To: "mmusic (E-mail)" Thread-Topic: [MMUSIC] Comments on draft-ietf-mmusic-media-loopback-16 Thread-Index: AQHMqHdfBqooEIMwnkm5vxPqfuyS4w== Date: Mon, 21 Nov 2011 17:59:55 +0000 Message-ID: <4E297805-F75E-4728-855B-A0F78BE86D9B@acmepacket.com> References: <4EA13A85.2060506@ericsson.com> In-Reply-To: <4EA13A85.2060506@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5F4082E497E5B84AB72325A719DD93B7@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "payload@ietf.org" Subject: Re: [payload] [MMUSIC] Comments on draft-ietf-mmusic-media-loopback-16 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 17:59:59 -0000 Howdy, Magnus sent back a big list of comments against media-loopback for the WGLC= . I plan to propose changes to address some of his points in separate emails,= notably for the technical ones. The following points copied below I consider editorial in nature and wish t= o resolve directly as the editor. Does anyone object to this? On Oct 21, 2011, at 5:25 AM, Magnus Westerlund wrote: > 5. Abstract: "maintaining voice/real-time Text/video quality, > reliability, and overall performance." The "voice/real-time" > construction appears to indicate that voice isn't real-time. I guess > something like: maintaining real-time voice/Text/video quality, > reliability, and overall performance. would be easier and clearer. >=20 > 6. Section 3. > No reference to SDP offer answer. And the "Offering entity" is called > agent in SDP O/A terminology. >=20 > 7. Section 3: > "it MAY do so as defined in section 5.4.1 of > this specification." >=20 > Considering what is written in 5.4.1 I think that section can be moved > to section 3. >=20 > 8. Section 4: > An answering entity that is not compliant to this specification and > which receives an offer with the "loopback" media attributes MAY > ignore the attribute and treat the incoming offer as a normal > request. >=20 > I would suggest reformulate this. I expect this text to say what is > expected to happen when the answering agent doesn't know what this > attribute is. Which is ignore the attribute, attempt to establish the > session without loopback and send back the answer without the attribute. >=20 > I would suggest to clarify that the offering agent should consider > terminating the establishment at this point as loopback was not > available, unless it might actual "ring" if this is an end-point at a use= r. >=20 ... > 10. What is really the purpose of the sections 3 and 4. They seem to be > teasers for a very small part of the issue that is covered in detail in > section 5. Why not move the appropriate text in to the relevant subsectio= ns? >=20 ... >=20 > 12. Section 5.3: > I think one could clarify that the loopback source needs to include the > encapsulation or direct loopback payload formats when suggesting pckt > type loopback. >=20 > ... > 14. Section 5.1: > loopback-type =3D loopback-choice [1*SP loopback-choice] > loopback-choice =3D loopback-type-pkt / loopback-type-media > loopback-type-pkt =3D "rtp-pkt-loopback" > loopback-type-media =3D "rtp-media-loopback" >=20 > The ABNF appears broken as it doesn't define the whole attribute. I > would suggest to add a line: >=20 > loopback-attr =3D "a=3Dloopback:" loopback-type >=20 > 15. Section 5.2 is missing ABNF. > I think it should make clear the attributes definition completely. >=20 > 16. Section 5 > Two new media attributes are defined: one indicates the type of > loopback and the other indicates the mode of the loopback. >=20 > I would claim that this spec defines 3 attributes. >=20 > 17. Section 5.4: >=20 > The loopback-mode attributes (loopbackThe > port number and the address in the answer (m=3D line) indicate where > the answerer would like to receive the media stream. >=20 > Strange sentence! >=20 ... > 21. Section 6. > "An answering entity that is compliant to this specification and > accepting a media with the loopback type rtp-media-loopback MUST > transmit all received media back to the sender. " >=20 > I think this MUST, MUST have an exception for that the path from the > mirror to the source actually can support the bit-rate required. >=20 ... > 36. Section 10.1 > Either of the o=3D lines are in error. Because they can't be the same whe= n > it comes to the ID and version fields. >=20 ... -hadriel From HKaplan@acmepacket.com Mon Nov 21 10:57:56 2011 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8316211E80E7; Mon, 21 Nov 2011 10:57:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.488 X-Spam-Level: X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gAqxTUeACsMI; Mon, 21 Nov 2011 10:57:56 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id F2B4511E80E5; Mon, 21 Nov 2011 10:57:55 -0800 (PST) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 21 Nov 2011 13:57:54 -0500 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Mon, 21 Nov 2011 13:57:54 -0500 From: Hadriel Kaplan To: "mmusic (E-mail)" , "payload@ietf.org" Thread-Topic: Issue #4 from Magnus on draft-ietf-mmusic-media-loopback-16 Thread-Index: AQHMqH95nHVY2W5eEU6uQXRGDD1AsA== Date: Mon, 21 Nov 2011 18:57:53 +0000 Message-ID: References: <4EA13A85.2060506@ericsson.com> In-Reply-To: <4EA13A85.2060506@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1847384CF048EF4EA80807AE67A67EBC@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: [payload] Issue #4 from Magnus on draft-ietf-mmusic-media-loopback-16 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 18:57:56 -0000 On Oct 21, 2011, at 5:25 AM, Magnus Westerlund wrote: > 4. Title: I think the title is indicating that this is only an SDP > solution, but it clearly contains the considerations needed for the > RTP/RTCP part also. I think it should reflect that it is a solution for > RTP transported media loopback including SDP signalling. I propose the following title: "A Media Loopback Mechanism for Real-time Transport Protocol (RTP)" Does anyone object? -hadriel From HKaplan@acmepacket.com Mon Nov 21 11:06:35 2011 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C15CF1F0C7E; Mon, 21 Nov 2011 11:06:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1DUiwrJAC7O; Mon, 21 Nov 2011 11:06:34 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 754201F0C79; Mon, 21 Nov 2011 11:05:57 -0800 (PST) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 21 Nov 2011 14:05:56 -0500 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Mon, 21 Nov 2011 14:05:56 -0500 From: Hadriel Kaplan To: "mmusic (E-mail)" , "payload@ietf.org" Thread-Topic: Issue #11 from Magnus on draft-ietf-mmusic-media-loopback-16 Thread-Index: AQHMqICYahoClbm3JkeqXgL1uiWwxw== Date: Mon, 21 Nov 2011 19:05:56 +0000 Message-ID: References: <4EA13A85.2060506@ericsson.com> In-Reply-To: <4EA13A85.2060506@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: draft-ietf-mmusic-media-loopback Subject: [payload] Issue #11 from Magnus on draft-ietf-mmusic-media-loopback-16 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 19:06:35 -0000 With regards to issue #11 on the media-loopback draft, the consensus on the= mailing list so far appears to be ok with the following text: "Since media loopback requires bidirectional RTP, its normal direction mode= is "sendrecv"; the "sendrecv" direction attribute MAY be encoded in SDP or= not, as per section 5.1 of [RFC3264], since it is implied by default. If e= ither the loopback source or mirror wish to disable loopback use during a s= ession, the direction attribute "inactive" MUST be used as per [RFC3264]. = The direction mode attributes "recvonly" and "sendonly" are incompatible wi= th the loopback mechanism and MUST NOT be indicated when generating an SDP = Offer or Answer." Does anyone object to the above text? -hadriel On Oct 21, 2011, at 5:25 AM, Magnus Westerlund wrote: > 11. Section 5.3 > " Note: A loopback offer in a given media description MUST NOT > contain the standard mode attributes sendonly, recvonly, sendrecv, > or inactive. The loopback-mode attributes (loopback-source and > loopback-mirror) replace the standard attributes." >=20 > This appears to be a strange MUST NOT which I think might encounter > issues. Considering that SIP proxies that looks into this SDP requires > the direction attribute to be present and adds it, what happens now. > And why isn't sendrecv and inactive possible values? sendrecv appears to > be requried for loopback to work, and inactive would put media transport > in an established session on hold. Isn't that reasonable? From HKaplan@acmepacket.com Tue Nov 22 00:11:33 2011 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFA0211E8083; Tue, 22 Nov 2011 00:11:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHuo3BmPBor9; Tue, 22 Nov 2011 00:11:32 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 60D1A21F8557; Tue, 22 Nov 2011 00:11:28 -0800 (PST) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 22 Nov 2011 03:11:24 -0500 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Tue, 22 Nov 2011 03:11:24 -0500 From: Hadriel Kaplan To: "Miguel A. Garcia" Thread-Topic: [MMUSIC] Issue #4 from Magnus on draft-ietf-mmusic-media-loopback-16 Thread-Index: AQHMqO5T57XIgns6CUqTjH7PUFazsg== Date: Tue, 22 Nov 2011 08:11:24 +0000 Message-ID: <5960030E-C594-4751-84CB-46E30275232C@acmepacket.com> References: <4EA13A85.2060506@ericsson.com> <4ECB4487.9000801@ericsson.com> In-Reply-To: <4ECB4487.9000801@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <98ED0D38328506468E4FAB6780579EA0@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" , "mmusic \(E-mail\)" , "payload@ietf.org" Subject: Re: [payload] [MMUSIC] Issue #4 from Magnus on draft-ietf-mmusic-media-loopback-16 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 08:11:33 -0000 Hi Miguel, I knew you had also posted comments but I was planning to address Magnus' f= irst and then your's, but I see now there is some overlap. With regard to title, would this be ok: "A Media Loopback Mechanism for Real-time Transport Protocol (RTP) and Exte= nsion for SDP" -hadriel On Nov 22, 2011, at 1:43 AM, Miguel A. Garcia wrote: > Hi: >=20 > In my comments posted in this mail: > http://www.ietf.org/mail-archive/web/mmusic/current/msg08958.html >=20 > I suggested to rename the draft to: "An extension to SDP and RTP for medi= a loopback". >=20 > While I don't care much of the exact words, I think the terms "SDP", "RTP= " and "media loopback" need all be in the title of the document. Your propo= sal misses "SDP", so, if you add it, I will agree. >=20 > BR, >=20 > Miguel >=20 > On 21/11/2011 19:57, Hadriel Kaplan wrote: >>=20 >>=20 >>=20 >> On Oct 21, 2011, at 5:25 AM, Magnus Westerlund wrote: >>=20 >>> 4. Title: I think the title is indicating that this is only an SDP >>> solution, but it clearly contains the considerations needed for the >>> RTP/RTCP part also. I think it should reflect that it is a solution for >>> RTP transported media loopback including SDP signalling. >>=20 >> I propose the following title: >> "A Media Loopback Mechanism for Real-time Transport Protocol (RTP)" >>=20 >> Does anyone object? >>=20 >> -hadriel >>=20 >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >>=20 >=20 > --=20 > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain From HKaplan@acmepacket.com Tue Nov 22 00:25:40 2011 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7E4B21F8B74; Tue, 22 Nov 2011 00:25:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MI4WqgC2uuzn; Tue, 22 Nov 2011 00:25:40 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id B0A6D21F8B73; Tue, 22 Nov 2011 00:25:39 -0800 (PST) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 22 Nov 2011 03:25:38 -0500 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Tue, 22 Nov 2011 03:25:38 -0500 From: Hadriel Kaplan To: "mmusic (E-mail)" , "payload@ietf.org" Thread-Topic: [MMUSIC] Comments to draft-ietf-mmusic-media-loopback-16 Thread-Index: AQHMqPBPLmwVIdu6wEilEi4+tI/ZTQ== Date: Tue, 22 Nov 2011 08:25:37 +0000 Message-ID: References: <4E9B41B6.9070506@ericsson.com> In-Reply-To: <4E9B41B6.9070506@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="us-ascii" Content-ID: <84B500DA7A4DDB4C8D240F057B73DC21@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "Miguel A. Garcia" , "" Subject: Re: [payload] [MMUSIC] Comments to draft-ietf-mmusic-media-loopback-16 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 08:25:40 -0000 Howdy, Miguel sent back a list of comments against media-loopback for the WGLC. I plan to propose changes to address some of his points in separate emails,= for the technical comments. The following points copied below I consider editorial in nature and wish t= o resolve directly as the editor.=20 Does anyone object to this course of action? On Oct 16, 2011, at 4:42 PM, Miguel A. Garcia wrote: > - Terminology. I don't find any justification for this draft to depend on= RFC 3261 and for making references to SIP INVITEs and alike. Instead, the = draft should be based on the SDP offer/answer model (RFC 3264). As part of = this, I will add a paragraph in Section 2 saying that ... "The following te= rms are borrowed from RFC 3264: offer, offerer, answer, answerer". I will r= ename section 3 to "SDP offerer behavior", Section 4 to "SDP answerer behav= ior". An in general, I will not talk of the "offering entity" (section 3), = but the "offerer", or the "answering entity" (section 4), but the "answerer= ". >=20 > - I will add a new paragraph at the end of Section 3 indicating where the= "loopback" attribute is defined. >=20 > - Section 4, the last paragraph is not correct, because it puts a normati= ve requirement (MAY) for answerers that are not compliant with this specifi= cation. So, if an answerer is not compliant with this specification, how ca= n it comply with the normative MAY? >=20 > I suggest to replace the "MAY" with "is expected". >=20 > - I would rename Section 5 to "New SDP attributes" >=20 > - I would start Section 5.1 with a sentence that says: "This specificatio= n defines a new 'loopback' attribute which indicates the type of loopback t= hat the entity is able to do". >=20 ... > - The last two paragraphs in Section 5.1 describe the packet loopback and= the media loopback. However, in Section 1.1, there are three modes defined= . I would like to have a matching between the two values and the three mode= s. For example, you could add a sentence indicating in each of these two va= lues "this value is used when the loopback is of type xxx (see Section 1.X)= ." >=20 >=20 ... > - Section 5.3, after the example. There is a note that contains a normati= ve statement (MUST NOT). In principle, notes should be informative by natur= e, so just remove the word "Note:" from the beginning of the paragraph. >=20 > - Section 5.3, the paragraph after the Note refers to the "m=3D line" whe= n the draft says "The port number and the address in the offer (m=3D line).= .." However, the address in SDP goes in the c=3D line, therefore, whenever = you refer to port number and address, you should refer to the "m/c=3D lines= ". >=20 >=20 ... > - Examples at the end of Section 5.3 It would be nice to elaborate these = examples, describing what they are showing. Also, at this point in the draf= t, the "encaprtp" and "rtploopback" tokens have not been introduced, so it = would be nice to point to the sections where it will later be defined. >=20 > - Section 5.4, first paragraph, first sentence, replace "a loopback answe= r" with "an SDP answer". Later in this same paragraph replace "offerere" wi= th "offerer". >=20 > - There is some missing words in the second sentence of the first paragra= ph in Section 5.4. The sentence is incomplete. >=20 > - Section 5.4, second paragraph, write "attributes" in plural in the firs= t sentence. >=20 > - Section 5.5, first and second sentences, read: >=20 > The answer to a loopback-source MUST be loopback-mirror. The > answer to a loopback-mirror MUST be loopback-source. >=20 > First, the sentences should be expressed in terms of "SDP offer" and "SDP= answer" "containing a loopback-source" or "loopback-mirror". For example: >=20 > An offer containing a "loopback-source" attribute must be answered wit= h an SDP answer containing a "loopback-mirror attribute in the same media d= escription. An offer containing... >=20 > But, having said that... I wonder whether the above sentence makes sense = in this section. This section is titled "Offerer processing of the answer".= Therefore, I expect to find there what the offerer should do when it recei= ves an SDP answer, not what the answerer should do to process the offer and= generate the answer. So, move these two sentences to the Section 5.4. >=20 > - The third and fourth sentences in Section 5.5 read: >=20 > The > loopback-mode line MUST contain at least one codec the answerer is > willing to send or receive depending on whether it is the loopback- > source or the loopback-mirror. In addition, the "m=3D" line MUST > contain at least one codec that the answerer is willing to send or > receive depending on whether it is the loopback-mirror or the > loopback-source. >=20 > Well, it seems that these sentencse also describe how the answerer genera= tes the answer, so it should be moved to Section 5.4. >=20 > - Second paragraph in Section 5.5. Replace "target UA" with "answerer". B= ut most important, this paragraph needs to say what happens if the offer re= ceives an answer that does not include the loopback-mirror/loopback-source = attribute. I believe it should say that a session is still established, but= loopback packets are not expected. It is up to the offerer to close down t= he session by regular means (high level protocol such as a SIP BYE or sendi= ng a new offer with the port number set to zero). >=20 > - Section 5.6, I wonder way the "may" in the first sentence is not a MAY. >=20 > - Section 5.6, replace the reference to SIP. You just need the reference = to Section 8 of RFC 3264. >=20 ... > - Section 10. All the examples, replace "client", "server" and "INVITE re= quest", and "response" with: >=20 > An [offerer|answerer] sends an SDP [offer|answer] which looks like: >=20 > - Section 10. In all the examples, replace "s=3DExample" with "s=3D" (sou= rce, RFC 3264). And you can omit the i=3D and e=3D lines as well, they do n= ot really add anything, nor they are mandated. >=20 > - Section 10.3. Re-title this section to "SDP answer rejecting loopback m= edia". >=20 > - The note at the end of Section 10.3 reads: >=20 > NOTE: Loopback request may be rejected by either not including the > loopback mode attribute (for backward compatibility) or setting the > media port number to zero, or both, in the response. >=20 > First, I don't like this note here, because it may induce to double speci= fication, specially since you have Section 5.4 that describes how to reject= a loopback request. >=20 > And actually, here you have double incongruent specification. Section 5.4= .1 only offers one mechanism for rejecting a session: setting the port to z= ero like in regular SDP. Nothing is written about rejecting a session by no= t including the loopback mode attribute. >=20 > Not including a loopback mode attribute in the answer is not a rejection,= it is merely a session with no support for the loopback feature, but the s= ession is established. >=20 > I recommend to delete this note. >=20 > - Section 11. I disagree with the dependency on RFC 3261. Please remove. = Also, I am surprised of not seen any dependency of the security considerati= ons of RTP/RTCP. >=20 -hadriel From miguel.a.garcia@ericsson.com Mon Nov 21 22:43:25 2011 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53ED811E816A; Mon, 21 Nov 2011 22:43:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.384 X-Spam-Level: X-Spam-Status: No, score=-6.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAPppBtEU60T; Mon, 21 Nov 2011 22:43:24 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 2F40511E8165; Mon, 21 Nov 2011 22:43:24 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-92-4ecb4488d26b Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 22.02.09514.8844BCE4; Tue, 22 Nov 2011 07:43:20 +0100 (CET) Received: from [159.107.24.191] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Tue, 22 Nov 2011 07:43:20 +0100 Message-ID: <4ECB4487.9000801@ericsson.com> Date: Tue, 22 Nov 2011 07:43:19 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Hadriel Kaplan References: <4EA13A85.2060506@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Tue, 22 Nov 2011 00:53:09 -0800 Cc: "" , "mmusic \(E-mail\)" , "payload@ietf.org" Subject: Re: [payload] [MMUSIC] Issue #4 from Magnus on draft-ietf-mmusic-media-loopback-16 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 06:43:25 -0000 Hi: In my comments posted in this mail: http://www.ietf.org/mail-archive/web/mmusic/current/msg08958.html I suggested to rename the draft to: "An extension to SDP and RTP for media loopback". While I don't care much of the exact words, I think the terms "SDP", "RTP" and "media loopback" need all be in the title of the document. Your proposal misses "SDP", so, if you add it, I will agree. BR, Miguel On 21/11/2011 19:57, Hadriel Kaplan wrote: > > > > On Oct 21, 2011, at 5:25 AM, Magnus Westerlund wrote: > >> 4. Title: I think the title is indicating that this is only an SDP >> solution, but it clearly contains the considerations needed for the >> RTP/RTCP part also. I think it should reflect that it is a solution for >> RTP transported media loopback including SDP signalling. > > I propose the following title: > "A Media Loopback Mechanism for Real-time Transport Protocol (RTP)" > > Does anyone object? > > -hadriel > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From nathan@robotics.net Mon Nov 21 11:26:57 2011 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ACCD1F0C8B; Mon, 21 Nov 2011 11:26:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JuXGW47ymbGa; Mon, 21 Nov 2011 11:26:56 -0800 (PST) Received: from bart.robotics.net (bart.robotics.net [75.148.206.242]) by ietfa.amsl.com (Postfix) with ESMTP id B42C01F0C5A; Mon, 21 Nov 2011 11:26:56 -0800 (PST) Received: from [10.13.0.114] (75-148-206-241-Houston.hfc.comcastbusiness.net [75.148.206.241]) by bart.robotics.net (Postfix) with ESMTPA id 0BBDD22020E; Mon, 21 Nov 2011 13:26:39 -0600 (CST) References: <4EA13A85.2060506@ericsson.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (9A405) From: Nathan Stratton Date: Mon, 21 Nov 2011 13:26:37 -0600 To: Hadriel Kaplan X-Mailman-Approved-At: Tue, 22 Nov 2011 00:53:09 -0800 Cc: draft-ietf-mmusic-media-loopback , "mmusic \(E-mail\)" , "payload@ietf.org" Subject: Re: [payload] Issue #11 from Magnus on draft-ietf-mmusic-media-loopback-16 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 19:26:57 -0000 Looks good. Sent from my iPhone On Nov 21, 2011, at 1:05 PM, Hadriel Kaplan wrote: >=20 > With regards to issue #11 on the media-loopback draft, the consensus on th= e mailing list so far appears to be ok with the following text: >=20 > "Since media loopback requires bidirectional RTP, its normal direction mod= e is "sendrecv"; the "sendrecv" direction attribute MAY be encoded in SDP or= not, as per section 5.1 of [RFC3264], since it is implied by default. If ei= ther the loopback source or mirror wish to disable loopback use during a ses= sion, the direction attribute "inactive" MUST be used as per [RFC3264]. The= direction mode attributes "recvonly" and "sendonly" are incompatible with t= he loopback mechanism and MUST NOT be indicated when generating an SDP Offer= or Answer." >=20 > Does anyone object to the above text? >=20 > -hadriel >=20 >=20 > On Oct 21, 2011, at 5:25 AM, Magnus Westerlund wrote: >=20 >> 11. Section 5.3 >> " Note: A loopback offer in a given media description MUST NOT >> contain the standard mode attributes sendonly, recvonly, sendrecv, >> or inactive. The loopback-mode attributes (loopback-source and >> loopback-mirror) replace the standard attributes." >>=20 >> This appears to be a strange MUST NOT which I think might encounter >> issues. Considering that SIP proxies that looks into this SDP requires >> the direction attribute to be present and adds it, what happens now. >> And why isn't sendrecv and inactive possible values? sendrecv appears to >> be requried for loopback to work, and inactive would put media transport >> in an established session on hold. Isn't that reasonable? From miguel.a.garcia@ericsson.com Tue Nov 22 00:12:27 2011 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C85D11E8164; Tue, 22 Nov 2011 00:12:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.394 X-Spam-Level: X-Spam-Status: No, score=-6.394 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcpUXhEYyADP; Tue, 22 Nov 2011 00:12:26 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id D675C21F858D; Tue, 22 Nov 2011 00:12:25 -0800 (PST) X-AuditID: c1b4fb3d-b7c26ae0000035b9-4c-4ecb5961b667 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 48.FA.13753.1695BCE4; Tue, 22 Nov 2011 09:12:17 +0100 (CET) Received: from [159.107.24.191] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Tue, 22 Nov 2011 09:12:17 +0100 Message-ID: <4ECB5960.4090305@ericsson.com> Date: Tue, 22 Nov 2011 09:12:16 +0100 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Hadriel Kaplan References: <4EA13A85.2060506@ericsson.com> <4ECB4487.9000801@ericsson.com> <5960030E-C594-4751-84CB-46E30275232C@acmepacket.com> In-Reply-To: <5960030E-C594-4751-84CB-46E30275232C@acmepacket.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Tue, 22 Nov 2011 00:53:09 -0800 Cc: "" , "mmusic \(E-mail\)" , "payload@ietf.org" Subject: Re: [payload] [MMUSIC] Issue #4 from Magnus on draft-ietf-mmusic-media-loopback-16 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 08:12:27 -0000 Works for me. /Miguel On 22/11/2011 9:11, Hadriel Kaplan wrote: > > Hi Miguel, > I knew you had also posted comments but I was planning to address Magnus' first and then your's, but I see now there is some overlap. > > With regard to title, would this be ok: > > "A Media Loopback Mechanism for Real-time Transport Protocol (RTP) and Extension for SDP" > > -hadriel > > > On Nov 22, 2011, at 1:43 AM, Miguel A. Garcia wrote: > >> Hi: >> >> In my comments posted in this mail: >> http://www.ietf.org/mail-archive/web/mmusic/current/msg08958.html >> >> I suggested to rename the draft to: "An extension to SDP and RTP for media loopback". >> >> While I don't care much of the exact words, I think the terms "SDP", "RTP" and "media loopback" need all be in the title of the document. Your proposal misses "SDP", so, if you add it, I will agree. >> >> BR, >> >> Miguel >> >> On 21/11/2011 19:57, Hadriel Kaplan wrote: >>> >>> >>> >>> On Oct 21, 2011, at 5:25 AM, Magnus Westerlund wrote: >>> >>>> 4. Title: I think the title is indicating that this is only an SDP >>>> solution, but it clearly contains the considerations needed for the >>>> RTP/RTCP part also. I think it should reflect that it is a solution for >>>> RTP transported media loopback including SDP signalling. >>> >>> I propose the following title: >>> "A Media Loopback Mechanism for Real-time Transport Protocol (RTP)" >>> >>> Does anyone object? >>> >>> -hadriel >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >> >> -- >> Miguel A. Garcia >> +34-91-339-3608 >> Ericsson Spain > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From stockhammer@nomor.de Fri Nov 25 03:44:44 2011 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC5921F8B8D; Fri, 25 Nov 2011 03:44:44 -0800 (PST) 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=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2gmy74H6uxi; Fri, 25 Nov 2011 03:44:44 -0800 (PST) Received: from mo-p00-ob6.rzone.de (mo-p00-ob6.rzone.de [IPv6:2a01:238:20a:202:53f0::1]) by ietfa.amsl.com (Postfix) with ESMTP id AA1A821F8B89; Fri, 25 Nov 2011 03:44:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1322221479; l=1773; s=domk; d=nomor.de; h=To:References:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From: Content-Type:Mime-Version:Subject:X-RZG-CLASS-ID:X-RZG-AUTH; bh=7Xf2nCge+dhreIZlN3dIXKFPssw=; b=plhuv6DyOR6fMwZRN5WlJ8vE9Eb1Hry0joOxrc3y+JnAKHTpFb9RAhcTmy17Nh1d/TP VDNSqrpXd/+9sTJhYWUeKvAIvSs6klVSiDCKldegAett52T3tW7NTwGrXPihJfjvpbN3l C1EI99A64mSTjJVk6YPsaD3EVkcoF9e9gRk= X-RZG-AUTH: :P3gLdkugevKirJkjH/RoTtk5THWq6nlFgKpnuMPeiu13+UwGfuMVAY1fXI1g9SU= X-RZG-CLASS-ID: mo00 Received: from [192.168.0.170] ([93.104.202.244]) by smtp.strato.de (jimi mo7) (RZmta 26.10 AUTH) with ESMTPA id 605d49nAPAWXgC ; Fri, 25 Nov 2011 12:44:34 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Thomas Stockhammer In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D541013EC57@xmb-sjc-215.amer.cisco.com> Date: Fri, 25 Nov 2011 12:44:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <02A6EFD6-843A-4191-A8FE-CE36D4CDBB07@nomor.de> References: <04CAD96D4C5A3D48B1919248A8FE0D541013EC57@xmb-sjc-215.amer.cisco.com> To: Ali C. Begen (abegen) X-Mailer: Apple Mail (2.1251.1) Cc: gjshep@gmail.com, payload@ietf.org, fecframe@ietf.org Subject: Re: [payload] [Fecframe] LC draft-ietf-fecframe-rtp-raptor-05.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 11:44:45 -0000 Ali, thanks for the comments. All of the comments will be addressed in an = updated revision to be published shortly. Thomas > Minor comments: > - The framework draft was published as RFC 6363, the citation should = be updated. > - 2119 keywords should not be used in the intro section. Just make = them small letters. > - Provide some example apps in the registration section (Applications = that use this media type: is empty) > - Controller should be PAYLOAD WG not AVT.=20 > - I-D.ietf-fecframe-sdp-elements is also RFC 6364 now. >=20 > -acbegen >=20 >> -----Original Message----- >> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On = Behalf Of Greg Shepherd >> Sent: Monday, October 10, 2011 4:03 PM >> To: fecframe@ietf.org; payload@ietf.org >> Subject: [payload] LC draft-ietf-fecframe-rtp-raptor-05.txt >>=20 >> Please read, review, comment - a comment of support is also helpful - >> ASAP. This WG is very close to being finished and this is one of the >> few last bits. >>=20 >> http://www.ietf.org/id/draft-ietf-fecframe-rtp-raptor-05.txt >>=20 >> Thanks!, >> Greg >> _______________________________________________ >> payload mailing list >> payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe --- Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89 = 978980 02 || cell +491725702667 || http://www.nomor-research.com Nomor Research GmbH - Sitz der Gesellschaft: M=FCnchen - = Registergericht: M=FCnchen, HRB 165856 =96 Umsatzsteuer-ID: DE238047637 = - Gesch=E4ftsf=FChrer: Dr. Thomas Stockhammer, Dr. Ingo Viering. From bill.wu@huawei.com Tue Nov 29 22:54:31 2011 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9044111E808B; Tue, 29 Nov 2011 22:54:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.321 X-Spam-Level: X-Spam-Status: No, score=-6.321 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E55yRlHgpdw5; Tue, 29 Nov 2011 22:54:30 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id C001F11E8083; Tue, 29 Nov 2011 22:54:30 -0800 (PST) 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 <0LVG00CTEOIEYB@szxga04-in.huawei.com>; Wed, 30 Nov 2011 14:54:14 +0800 (CST) Received: from szxrg01-dlp.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 <0LVG0071NOIAQD@szxga04-in.huawei.com>; Wed, 30 Nov 2011 14:54:14 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFK97032; Wed, 30 Nov 2011 14:54:08 +0800 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 30 Nov 2011 14:54:04 +0800 Received: from w53375q (10.138.41.130) by szxeml401-hub.china.huawei.com (10.82.67.31) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 30 Nov 2011 14:53:59 +0800 Date: Wed, 30 Nov 2011 14:53:58 +0800 From: Qin Wu X-Originating-IP: [10.138.41.130] To: Colin Perkins Message-id: <45036E627AD24168BF9679E16ADB994E@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected References: <5F7BCCF5541B7444830A2288ABBEBC962161842965@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> <84156BF2-5F35-451C-8366-15DF54EA0988@csperkins.org> Cc: xrblock@ietf.org, payload@ietf.org, Alan Clark , "Schwarz, Albrecht \(Albrecht\)" Subject: Re: [payload] [xrblock] QoE draft submitted X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 06:54:31 -0000 Hi, ----- Original Message ----- From: "Colin Perkins" To: "Qin Wu" Cc: "Alan Clark" ; "Schwarz, Albrecht (Albrecht)" ; Sent: Tuesday, November 29, 2011 1:08 AM Subject: Re: [xrblock] QoE draft submitted On 16 Nov 2011, at 03:16, Qin Wu wrote: ... > So for the more precise granularity of MOS, e.g., narrowband, wideband, ultra wideband, why not just use signaling or out band mechanism to indicate that? ... How much of this can be inferred from the RTP payload type being used in the session, without additional signalling? [Qin]: AFAIK, a. the narrowband, wideband and ultrawideband only apply to audio applications or audio codecs. b. audio codecs tend evolving from narrowband to wideband, or from wideband to ultra wideband. c. most audio codec only support one mode, e.g., G.729 only supports narrowband, G.729.1 only supports wideband and G.729.1 SWB ony support ultra wideband. AMR-NB support narrowband, AMR-WB support wideband and AMR-WB+ support ultra wideband. but this doesn't mean that one RTP payload for audio application is not possible to support both narrowband and wideband, e.g., EVRC-NW, EV-VBR. In EVRC-NW, Encoding capability identification in the payload header is used to indicate if wideband or narrowband is used. In EV-VBR, Layer identificiation value in the payload format can be used to indicate if narrowband or wideband is used. So to my understanding, in most cases, payload type can be used to indicate if narrowband or wideband is used in the audio applications. However in very few other cases, you may need additional information in the payload format to faciliate your identification. For all the video applications, we don't need such feature. -- Colin Perkins http://csperkins.org/ From iss@ieee.org Wed Nov 30 07:18:57 2011 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57AE621F8B48; Wed, 30 Nov 2011 07:18:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.399 X-Spam-Level: X-Spam-Status: No, score=-101.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3hIP4Mun1wg; Wed, 30 Nov 2011 07:18:56 -0800 (PST) Received: from nesono.com (nesono.com [85.214.71.234]) by ietfa.amsl.com (Postfix) with ESMTP id 9299421F87D6; Wed, 30 Nov 2011 07:18:53 -0800 (PST) Received: from faui7rob7.informatik.uni-erlangen.de (faui7rob7.informatik.uni-erlangen.de [131.188.37.137]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: iss@nesono.com) by nesono.com (Postfix) with ESMTPSA id 065102B8008; Wed, 30 Nov 2011 16:18:27 +0100 (CET) From: Jochen Issing Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Nov 2011 16:18:26 +0100 Message-Id: <63CCC37C-D80A-46B9-83CB-DB78989F6018@ieee.org> To: payload@ietf.org, mmusic@ietf.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: [payload] RFC3640 (AAC) and SIP offer/answer issues X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 15:18:57 -0000 Dear experts, I need to double-apologize before posting our findings: 1) for cross-posting, as I do not know, where this issue has its exact = home, which is hopefully not a response killer. 2) for the long mail, even though I tried to keep it short. Now, here's the actual request: We are referring to RFC3640 SDP fields only, as this is most often the = stumbling block. Let's use the following example: m=3Daudio 49170 RTP/AVP 96 a=3Drtpmap:96 mpeg4-generic/48000/2 a=3Dfmtp:96 streamtype=3D5; profile-level-id=3D15; mode=3DAAC-hbr; = config=3D1190; sizeLength=3D13; indexLength=3D3; indexDeltaLength=3D3; = constantDuration=3D1024 The fields of interest are in the fmtp line: 'profile-level-id' and = 'config'. In contrast to other codecs, e.g. G.XXX, AAC integrates many different = types of sub codecs, which are identified using the Audio Object Type = (AOT). The AOT and some additional (codec internal) information is = stored in the Audio Specific Config (ASC), which is conveyed in the = 'config' field. The 'profile-level-id' points to a profile with a certain level. The = profile comprises a set of one or more AOTs and the level restricts the = stream to a maximum sample rate and/or number channels. The = profile-level-ids, as specified in ISO 14496-3, are partly hierarchical = and most often ambiguous. Suppose the classic SIP use case that two clients want to exchange their = codec capabilities. The first client specifies some payload types in the SDP part of SIP = INVITE which can differ in their profile-level-id and/or config. For instance, client bob supports AAC-LC, HE-AAC and HE-AACv2. To signal = these codecs/AOTs he could either indicate all formats with the same = profile-level-id (e.g., 48), which includes all these AOTs or he could = specify profile-level-ids, that are most 'narrow' to the actual = specified AOT or he could even mix this principle. On the other hand, the ASC might use implicit signaling, explicit = backwards-compatible, or explicit non-backwards-compatible. Bobs main problem would be to determine, whether the profile-level-id = was chosen to really identify the necessary (and applied) AAC AOTs or if = he could rely on the ASC or if the profile-level-id was just brawling = about the encoders feature. To clean up this mess of opportunities, we would like to specify a = non-ambiguous way to utilize the profile-level-id and config fields = appropriately and provide a guide on how to accomplish clean and easier = signalization and thus improve interoperability. But first of all we would like to make sure, that you agree to this = problem statement or do we miss something here? Comments are as always highly appreciated. Best Regards, --=20 jochen