From lars.eggert@nokia.com Tue Feb 1 12:01:45 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 528BB3A6EE9 for ; Tue, 1 Feb 2011 12:01:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.727 X-Spam-Level: X-Spam-Status: No, score=-103.727 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BioE786W7Way for ; Tue, 1 Feb 2011 12:01:43 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by core3.amsl.com (Postfix) with ESMTP id 985403A6E78 for ; Tue, 1 Feb 2011 12:01:43 -0800 (PST) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-da01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p11K4xPj022732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 1 Feb 2011 22:05:00 +0200 From: Lars Eggert X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.5 at fit.nokia.com Content-Type: multipart/signed; boundary=Apple-Mail-10-455916495; protocol="application/pkcs7-signature"; micalg=sha1 Date: Tue, 1 Feb 2011 22:04:56 +0200 References: <20706_1296566878_4D480A5E_20706_7634_1_94C682931C08B048B7A8645303FDC9F33C4376DCDC@PUEXCB1B.nanterre.francetelecom.fr> To: avt@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Tue, 01 Feb 2011 22:04:56 +0200 (EET) X-Nokia-AV: Clean X-Mailman-Approved-At: Wed, 02 Feb 2011 09:59:55 -0800 Subject: [AVTCORE] Fwd: [pcp] Reservation of Pair of Ports with PCP (I-D.pcp-rtp-rtcp-00) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 20:01:45 -0000 --Apple-Mail-10-455916495 Content-Type: multipart/mixed; boundary=Apple-Mail-9-455916461 --Apple-Mail-9-455916461 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I'm fairly sure AVT folks will want to give this a close read. Begin forwarded message: > From: "mohamed.boucadair@orange-ftgroup.com" = > Date: February 1, 2011 15:27:57 GMT+02:00 > To: "pcp@ietf.org" > Subject: [pcp] Reservation of Pair of Ports with PCP = (I-D.pcp-rtp-rtcp-00) >=20 > Dear all, >=20 > We edited a document to describe why a feature to allow reserving a = pair of port is needed.=20 >=20 > Comments and suggestions are welcome. >=20 > Cheers, > Med >=20 > -----Message d'origine----- > De : i-d-announce-bounces@ietf.org = [mailto:i-d-announce-bounces@ietf.org] De la part de = Internet-Drafts@ietf.org > Envoy=E9 : mardi 1 f=E9vrier 2011 14:00 > =C0 : i-d-announce@ietf.org > Objet : I-D Action:draft-boucadair-pcp-rtp-rtcp-00.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title : Reservation of Pair of Ports with PCP > Author(s) : M. Boucadair, S. Sivakumar > Filename : draft-boucadair-pcp-rtp-rtcp-00.txt > Pages : 14 > Date : 2011-02-01 >=20 > This document defines a new PCP Option to reserve a pair of ports in > a PCP-controlled device. This new PCP Option eases the traversal of > NAT for RTP/RTCP flows. >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-boucadair-pcp-rtp-rtcp-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 > ********************************* > This message and any attachments (the "message") are confidential and = intended solely for the addressees.=20 > Any unauthorised use or dissemination is prohibited. > Messages are susceptible to alteration.=20 > France Telecom Group shall not be liable for the message if altered, = changed or falsified. > If you are not the intended addressee of this message, please cancel = it immediately and inform the sender. > ******************************** >=20 --Apple-Mail-9-455916461 Content-Disposition: attachment; filename=draft-boucadair-pcp-rtp-rtcp-00.url Content-Type: message/external-body; name="draft-boucadair-pcp-rtp-rtcp-00.url" Content-Transfer-Encoding: 7bit [InternetShortcut]
URL=ftp: //ftp.ietf.org/internet-drafts/draft-boucadair-pcp-rtp-rtcp-00.txt
--Apple-Mail-9-455916461 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp --Apple-Mail-9-455916461-- --Apple-Mail-10-455916495 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEGxdPUZzCwUJ8KBiJwH+bYgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMDEwMTUwMDAwMDBaFw0x MTEwMTUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9r aWEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwolKEyOz/NQZJJlw0x9XBS9W wCmabdY1fXpbWSdcaJiEWhQpRzSIC/pgIwCgaUW9g3JsWioXCawyjUVeg8xR42sR690f4z+OPAUm 3jokZxsuRaGX6fuPkPQomYAGz7htUHws/8FZIU+4dciETQf4vF5ptitJ+QZCVRCTLqisj6mG/kG4 65Op3G5/YZF9F/a390LdhuRP6vdY2Y+dqm8LDa0zmENPpoE98u1pIZGqCcnskN/nNBtEPd+a4lNh ZSGnPuL4XCUSJYR9NB7FAYBvi5N7LSWHR3fspwa5EgpXynJcsLzaLA0iGfjFOBYFxul/07edmyw4 FIXuCIkaMDUfEwIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQAlSTzUKqa3ZouKWFQfIJ+4l/KsztPnY4Onwzt8lqAmeiFPqOmf kLTXbXDKtC6caFadNtyHpnsmQFFKXwhe5Z9/AaVSwryu6F9992DzYLp3j8PE0DSU0wmpUXUtp+rz TFqJRkzB8RCBoq/TPBmkMPr68qB0TkU3dbYiVIvscOt1MRkdHiwG4wKQLyCf8XRRWqmMY6lbun7g kiEWiris5StGKRvE5+e1SrcdnoZxIKQFF7Etr+4ftClrsDQWX9nRCEjYcmz4y/deq+HU8ylBaKZE 0ZJmcnYlAaD50OYWi0ckGDnKYyeMUEtCZJSV0otm2LqyIUAu9WPv/GNHt2ntjnUaMIIG7jCCBdag AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO 4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy +kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/ wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDIwMTIwMDQ1NlowIwYJKoZIhvcNAQkE MRYEFN7vANM9t29R92ZrYOjDTbFiMWlZMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGxdPUZzCwUJ8KBiJwH+ bYgwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMA0GCSqGSIb3DQEBAQUABIIB AJ8Eo+7N+5oznUlSClY26sSmNdhMhCvJhdIXO7cd5paeAVFM53jXBPs15sryqXeaP23uyF67sJa/ Z8U6N1FwQC3OSfFFBrf0UjVw1Ao4l3bYUU9hlYh2Fu+8lK36Ko6/3puDRLSCd7i6OzKDoUpoDLNS mI9Vn7uk56rsvvXJnwCa7JvKWFXlko5of6bFJEkgcwbU3cAVhfHVhl9OdEfrGjBayt+kgPNTvCN6 hOSf2yyHcSa8bwIPMBdrRIC4AVBYtBEQgvKECisnl0rQ7RJ7JqYGHhnNtSt6ZlHPc3UONaKT9avL h/+bd55YmPkIrOUsxO5P0xuaGuNotKp/ucV3xtQAAAAAAAA= --Apple-Mail-10-455916495-- From csp@csperkins.org Wed Feb 2 10:00:09 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8D4E3A6DB4 for ; Wed, 2 Feb 2011 10:00:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.243 X-Spam-Level: X-Spam-Status: No, score=-103.243 tagged_above=-999 required=5 tests=[AWL=0.356, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFDq+7h3ZOQt for ; Wed, 2 Feb 2011 10:00:08 -0800 (PST) Received: from lon1-msapost-3.mail.demon.net (lon1-msapost-3.mail.demon.net [195.173.77.182]) by core3.amsl.com (Postfix) with ESMTP id DD7D03A6DB1 for ; Wed, 2 Feb 2011 10:00:07 -0800 (PST) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by lon1-post-3.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1Pkh39-0000Ly-eZ; Wed, 02 Feb 2011 18:03:27 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <4D42CEB8.1090806@ericsson.com> Date: Wed, 2 Feb 2011 18:03:26 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D42CEB8.1090806@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1082) Cc: IETF AVT WG Subject: Re: [AVTCORE] [AVT] WG adoption to meet milestone for indication of retransmission supression X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 18:00:10 -0000 On 28 Jan 2011, at 14:12, Magnus Westerlund wrote: > WG, >=20 > This is a call for adopting "RTCP Extension for Feedback Suppression > Indication" as the starting point for meeting our milestone. The draft > is available here: > = https://datatracker.ietf.org/doc/draft-wu-avt-retransmission-supression-rt= p/ >=20 > The milestone: > May 2011 Submit RTCP indication for retransmission suppression as > Proposed Standard >=20 > Please provide any inut by Friday the 11th of February. Yes, this draft is heading in the right direction, and should be = adopted. --=20 Colin Perkins http://csperkins.org/ From csp@csperkins.org Wed Feb 2 10:30:17 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04CDA3A6DD3 for ; Wed, 2 Feb 2011 10:30:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.27 X-Spam-Level: X-Spam-Status: No, score=-103.27 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5ZeEYVNYV6E for ; Wed, 2 Feb 2011 10:30:15 -0800 (PST) Received: from anchor-msapost-2.mail.demon.net (anchor-msapost-2.mail.demon.net [195.173.77.165]) by core3.amsl.com (Postfix) with ESMTP id C0F903A6DBB for ; Wed, 2 Feb 2011 10:30:15 -0800 (PST) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by anchor-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1PkhWJ-0006IE-l4; Wed, 02 Feb 2011 18:33:35 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: Date: Wed, 2 Feb 2011 18:33:33 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <5D51ED4A-D95A-4DE6-A87F-A80330B60FE2@csperkins.org> References: <1F2FD678-D0A8-43A2-AB58-85401BD781F4@tno.nl> To: "Brandenburg, R. (Ray) van" X-Mailer: Apple Mail (2.1082) Cc: "avt@ietf.org" Subject: Re: [AVTCORE] [AVT] New version of RTCP for IDMS X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 18:30:17 -0000 Ray, On 20 Jan 2011, at 08:43, Brandenburg, R. (Ray) van wrote: >=20 > Hi, >=20 > On 19 Jan 2011, at 23:27, Colin Perkins wrote: >=20 > ... >=20 >>> The main reason we went with an RTCP-XR report block was that we = believed it would be less controversial to add an XR block type than a = completely new RTCP packet type. In RFC5968 (which I believe you = authored) it says that the only valid reason to create a new RTCP packet = type is if the required functionality would not be appropriate as part = of one of the current packet types (such as XR-). In the description of = the XR- packet type in the same document it says the XR blocks are = appropriate for "for transporting new metrics regarding media = transmission or reception quality". So I think we should have a = discussion about whether the IDMS block fits this description.=20 >=20 >> As I said, I think using RTCP XR is appropriate for receivers to = provide feedback to the sender on receipt and presentation times for RTP = packets.=20 >=20 >> I don't think an RTCP XR block is appropriate to, as your draft = phrases it, "indicate synchronization settings instructions to a = receiver". That seems to be providing guidance on when to playout the = media, rather than conveying a metric on how well media playout is = doing. This message from MSAS to SC would be better expressed as a new = RTCP packet type, I think. >=20 > I agree that this sentence is somewhat misleading and leads one to = believe that this IDMS message is some sort of control/command protocol. = That is not our goal. The message is used to inform receivers of how = media playout is doing on their slowest peer receiver. They can then use = this information to possibly synchronize their own playout to this peer, = although this is not required. In practice, a receiver would probably = only synchronize when the playout difference crosses some threshold = (e.g. for Social TV >150ms), to not cause unnecessary stutters for the = user. Sure, I understand. However, I still disagree that this is appropriate = for RTCP XR, because it's not a report on how a particular receiver sees = the session, but instead a summary of the overall state, and a playout = hint. This seems much better suited to be a new RTCP packet type. --=20 Colin Perkins http://csperkins.org/ From peter.musgrave@magorcorp.com Wed Feb 2 10:39:34 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B807A3A6B7F for ; Wed, 2 Feb 2011 10:39:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RBPkWKWJx4rF for ; Wed, 2 Feb 2011 10:39:34 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id AF0813A6B6E for ; Wed, 2 Feb 2011 10:39:33 -0800 (PST) Received: by wwa36 with SMTP id 36so289902wwa.13 for ; Wed, 02 Feb 2011 10:42:53 -0800 (PST) Received: by 10.216.185.199 with SMTP id u49mr9914885wem.45.1296672173287; Wed, 02 Feb 2011 10:42:53 -0800 (PST) Received: from [10.114.119.215] ([62.50.234.185]) by mx.google.com with ESMTPS id r38sm12289457weq.47.2011.02.02.10.42.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 02 Feb 2011 10:42:52 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-33-537383083 From: Peter Musgrave In-Reply-To: <5D51ED4A-D95A-4DE6-A87F-A80330B60FE2@csperkins.org> Date: Wed, 2 Feb 2011 18:42:42 +0000 Message-Id: <5BEA1E7A-DAD2-4A3E-B135-441EAA75BC88@magorcorp.com> References: <1F2FD678-D0A8-43A2-AB58-85401BD781F4@tno.nl> <5D51ED4A-D95A-4DE6-A87F-A80330B60FE2@csperkins.org> To: Colin Perkins X-Mailer: Apple Mail (2.1082) Cc: "avt@ietf.org" Subject: Re: [AVTCORE] [AVT] New version of RTCP for IDMS X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 18:39:34 -0000 --Apple-Mail-33-537383083 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I think this is a valid point.=20 Should this be an APP packet then? =46rom 3550:=20 "After testing and if wider use is justified, it is RECOMMENDED that each APP packet be redefined without the subtype and name fields and registered with IANA using an RTCP packet type. " Or should the draft indicate a new packet type? Peter Musgrave On 2011-02-02, at 6:33 PM, Colin Perkins wrote: > Sure, I understand. However, I still disagree that this is appropriate = for RTCP XR, because it's not a report on how a particular receiver sees = the session, but instead a summary of the overall state, and a playout = hint. This seems much better suited to be a new RTCP packet type. --Apple-Mail-33-537383083 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = think this is a valid point. 

Should this be an = APP packet then?

=46rom = 3550: 
"After testing and = if wider use is justified, it is RECOMMENDED that
   each APP packet =
be redefined without the subtype and name fields =
and
   registered with IANA using an RTCP packet =
type.
"

Or should the draft = indicate a new packet type?

Peter = Musgrave

On 2011-02-02, at 6:33 PM, Colin = Perkins wrote:

Sure, I = understand. However, I still disagree that this is appropriate for RTCP = XR, because it's not a report on how a particular receiver sees the = session, but instead a summary of the overall state, and a playout hint. = This seems much better suited to be a new RTCP packet = type.

= --Apple-Mail-33-537383083-- From magnus.westerlund@ericsson.com Thu Feb 3 01:49:39 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 696623A68D2 for ; Thu, 3 Feb 2011 01:49:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.491 X-Spam-Level: X-Spam-Status: No, score=-106.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WeXEwBt55s7 for ; Thu, 3 Feb 2011 01:49:38 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 5A5BD3A68A0 for ; Thu, 3 Feb 2011 01:49:38 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-9b-4d4a7afb6d0b Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 29.E9.13987.BFA7A4D4; Thu, 3 Feb 2011 10:52:59 +0100 (CET) Received: from [147.214.183.170] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.2.234.1; Thu, 3 Feb 2011 10:52:59 +0100 Message-ID: <4D4A7AFB.6090705@ericsson.com> Date: Thu, 3 Feb 2011 10:52:59 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: avt@ietf.org References: <1F2FD678-D0A8-43A2-AB58-85401BD781F4@tno.nl> <5D51ED4A-D95A-4DE6-A87F-A80330B60FE2@csperkins.org> <5BEA1E7A-DAD2-4A3E-B135-441EAA75BC88@magorcorp.com> In-Reply-To: <5BEA1E7A-DAD2-4A3E-B135-441EAA75BC88@magorcorp.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: [AVTCORE] [AVT] New version of RTCP for IDMS X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 09:49:39 -0000 Peter Musgrave skrev 2011-02-02 19:42: > I think this is a valid point. > > Should this be an APP packet then? > > From 3550: > "After testing and if wider use is justified, it is RECOMMENDED that > > each APP packet be redefined without the subtype and name fields and > > registered with IANA using an RTCP packet type. Well, if one is doing a AVT defined solution for this, then we can clearly go for a new RTCP packet type directly. We don't need to test it before. That is already happening with the current spec, isn't it? 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 wwwrun@core3.amsl.com Thu Feb 3 09:32:18 2011 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 0D9BA3A6A3A; Thu, 3 Feb 2011 09:32:17 -0800 (PST) To: stewe@cs.tu-berlin.de From: IETF Secretariat Message-Id: <20110203173218.0D9BA3A6A3A@core3.amsl.com> Date: Thu, 3 Feb 2011 09:32:18 -0800 (PST) Cc: keith.drage@alcatel-lucent.com, housley@vigilsec.com, gonzalo.camarillo@ericsson.com, avt@ietf.org, ipr-announce@ietf.org Subject: [AVTCORE] IPR Disclosure: QUALCOMM Incorporated's Statement about IPR related to RFC 3984 (5) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 17:32:18 -0000 Dear Stephan Wenger: An IPR disclosure that pertains to your RFC entitled "RTP payload Format for H.264 Video" (RFC3984) was submitted to the IETF Secretariat on 2011-01-19 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1473/). The title of the IPR disclosure is "QUALCOMM Incorporated's Statement about IPR related to RFC 3984 (5)." The IETF Secretariat From Even.roni@huawei.com Fri Feb 4 01:23:46 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3C003A68B0 for ; Fri, 4 Feb 2011 01:23:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.75 X-Spam-Level: X-Spam-Status: No, score=-103.75 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huDXRZvzLwWg for ; Fri, 4 Feb 2011 01:23:46 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id A9A3B3A68AD for ; Fri, 4 Feb 2011 01:23:45 -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 <0LG30047M68P2U@szxga04-in.huawei.com> for avt@ietf.org; Fri, 04 Feb 2011 17:26:49 +0800 (CST) Received: from 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 <0LG300IJR68P2X@szxga04-in.huawei.com> for avt@ietf.org; Fri, 04 Feb 2011 17:26:49 +0800 (CST) Received: from windows8d787f9 (bzq-79-176-2-186.red.bezeqint.net [79.176.2.186]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LG300I1T67TBJ@szxml01-in.huawei.com> for avt@ietf.org; Fri, 04 Feb 2011 17:26:49 +0800 (CST) Date: Fri, 04 Feb 2011 11:22:19 +0200 From: Roni Even To: 'IETF AVTCore WG' Message-id: <01fc01cbc44d$194ddc10$4be99430$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_BR1wpor2txAuW3vNuTqlww)" Content-language: en-us Thread-index: AcvBSxwYV8dNxSwsSpWizxH3SP09VQ== x-cr-hashedpuzzle: AXUs A8Hy Bh7U BvaR B9TW DpTK ELRZ FLwH FNXp F1wb HL1w IYAF Id8l Ip/9 JP3u JZVd; 1; YQB2AHQAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {7CDAC789-BB31-44B8-8A11-65A0AA1A6CE2}; ZQB2AGUAbgAuAHIAbwBuAGkAQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Mon, 31 Jan 2011 13:31:04 GMT; UwBoAG8AcgB0ACAAVwBHAEwAQwAgAG8AbgAgAFAAbwByAHQAIABNAGEAcABwAGkAbgBnACAAQgBlAHQAdwBlAGUAbgAgAFUAbgBpAGMAYQBzAHQAIABhAG4AZAAgAE0AdQBsAHQAaQBjAGEAcwB0ACAAUgBUAFAAIABTAGUAcwBzAGkAbwBuAHMA x-cr-puzzleid: {7CDAC789-BB31-44B8-8A11-65A0AA1A6CE2} Subject: [AVTCORE] Short WGLC on Port Mapping Between Unicast and Multicast RTP Sessions -reminder X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 09:23:46 -0000 This is a multi-part message in MIME format. --Boundary_(ID_BR1wpor2txAuW3vNuTqlww) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, I would like to start a one week working group last call on http://tools.ietf.org/html/draft-ietf-avtcore-ports-for-ucast-mcast-rtp-00 . This draft finished a WGLC in the AVT WG before the restructure and the new 00 revision reflects that changes that were done based on email discussion. Please review the draft and send any comment to the AVTCore mailing list (avt@ietf.org) till the end of Monday February 7th 2011. Thanks Roni Even AVTCore co chair --Boundary_(ID_BR1wpor2txAuW3vNuTqlww) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi,

I would like to = start a one week working group last call on http://tools.ietf.org/html/draft-ietf-avtcore-ports-for-ucast-= mcast-rtp-00 .

This draft = finished a WGLC in the AVT WG before the restructure and the new 00 = revision reflects that changes that were done based on email = discussion.

 

Please review the draft and send any comment to the = AVTCore mailing list (avt@ietf.org) = till the end of Monday February 7th 2011.

Thanks

Roni = Even

AVTCore co chair =

= --Boundary_(ID_BR1wpor2txAuW3vNuTqlww)-- From ray.vanbrandenburg@tno.nl Mon Feb 7 05:45:57 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0330D3A6A73 for ; Mon, 7 Feb 2011 05:45:57 -0800 (PST) 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zn7x0oXN5jSt for ; Mon, 7 Feb 2011 05:45:56 -0800 (PST) Received: from mailoutb.tno.nl (mailoutb.tno.nl [134.221.1.17]) by core3.amsl.com (Postfix) with ESMTP id A73AD3A6936 for ; Mon, 7 Feb 2011 05:45:55 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.60,438,1291590000"; d="scan'208";a="11382580" Received: from unknown (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1b.tno.nl with ESMTP; 07 Feb 2011 14:45:58 +0100 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.220]) by EXC-CASHUB03.tsn.tno.nl ([134.221.225.222]) with mapi id 14.01.0270.001; Mon, 7 Feb 2011 14:45:58 +0100 From: "Brandenburg, R. (Ray) van" To: 'Magnus Westerlund' , "avt@ietf.org" , 'Colin Perkins' , 'Peter Musgrave' Thread-Topic: [AVTCORE] [AVT] New version of RTCP for IDMS Thread-Index: Acu0BjkkNJ4VJH75TgKyYQ88CLubgwC5facAAAmZdiAAQ0HigAAXJdAQAqDG+4AAAFHPAAAfypGAANNK8OA= Date: Mon, 7 Feb 2011 13:45:57 +0000 Message-ID: References: <1F2FD678-D0A8-43A2-AB58-85401BD781F4@tno.nl> <5D51ED4A-D95A-4DE6-A87F-A80330B60FE2@csperkins.org> <5BEA1E7A-DAD2-4A3E-B135-441EAA75BC88@magorcorp.com> <4D4A7AFB.6090705@ericsson.com> In-Reply-To: <4D4A7AFB.6090705@ericsson.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: [AVTCORE] [AVT] New version of RTCP for IDMS X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 13:45:57 -0000 Hi Colin/Peter/Magnus and all, Thanks for your input. After giving it much thought I now agree that it wou= ld be best to define a new packet type for the sender->receiver message.=20 I therefore propose the following:=20 - The receiver->sender message remains a XR block message as currently defi= ned by the I-D. This would allow it to be compatible with the ETSI TISPAN v= ersion, and would prevent unnecessary duplication.=20 - The sender->receiver message becomes a new RTCP packet type. - We include a section on compatibility with the TISPAN solution indicating= that receivers MUST use the XR block for providing the sender with input w= hile senders SHOULD use the new RTCP packet type for sender->receiver but M= AY use the TISPAN defined sender->receiver XR block (which will not be defi= ned in the I-D but remain in the ETSI spec). This should include an explana= tion on that the TISPAN sender->receiver XR block MUST only be used for pur= poses of compatibility with the TISPAN solution, but MUST NOT be used if al= l senders and receivers involved support the new RTCP packet type. In this = way, backward compatibility is ensured, while not limiting improvements mad= e within IETF. - A new SDP parameter is defined for the new sender->receiver RTCP packet t= ype. This would mean that there are two SDP parameters for the server->clie= nt message in the IANA registry; one for the ETSI solution and one for the = IETF solution. This would also mean: if all elements in the SDP negotiation= support the IETF solution, they SHOULD use the new RTCP packet type.=20 Would this solution be acceptable to you?=20 Regards, Ray van Brandenburg -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Magnu= s Westerlund Sent: donderdag 3 februari 2011 10:53 To: avt@ietf.org Subject: Re: [AVTCORE] [AVT] New version of RTCP for IDMS Peter Musgrave skrev 2011-02-02 19:42: > I think this is a valid point.=20 >=20 > Should this be an APP packet then? >=20 > From 3550:=20 > "After testing and if wider use is justified, it is RECOMMENDED that >=20 > each APP packet be redefined without the subtype and name fields=20 > and >=20 > registered with IANA using an RTCP packet type. Well, if one is doing a AVT defined solution for this, then we can clearly = go for a new RTCP packet type directly. We don't need to test it before. Th= at is already happening with the current spec, isn't it? 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 ---------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/disclaimer/email.html From peter.musgrave@magorcorp.com Mon Feb 7 10:57:09 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20FB03A6E82 for ; Mon, 7 Feb 2011 10:57:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X23PiLggO-Ot for ; Mon, 7 Feb 2011 10:57:07 -0800 (PST) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id 0A3783A6E7C for ; Mon, 7 Feb 2011 10:57:06 -0800 (PST) Received: by yie19 with SMTP id 19so2121772yie.31 for ; Mon, 07 Feb 2011 10:57:11 -0800 (PST) Received: by 10.151.9.3 with SMTP id m3mr15591218ybi.32.1297105029359; Mon, 07 Feb 2011 10:57:09 -0800 (PST) Received: from petermac.magor.local ([72.1.217.106]) by mx.google.com with ESMTPS id r24sm205659yba.6.2011.02.07.10.56.57 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 Feb 2011 10:57:00 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Peter Musgrave In-Reply-To: Date: Mon, 7 Feb 2011 13:56:56 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9318662B-EFA4-4CE3-B395-00C9718CF6C0@magorcorp.com> References: <1F2FD678-D0A8-43A2-AB58-85401BD781F4@tno.nl> <5D51ED4A-D95A-4DE6-A87F-A80330B60FE2@csperkins.org> <5BEA1E7A-DAD2-4A3E-B135-441EAA75BC88@magorcorp.com> <4D4A7AFB.6090705@ericsson.com> To: "Brandenburg, R. (Ray) van" X-Mailer: Apple Mail (2.1082) Cc: 'Magnus Westerlund' , "avt@ietf.org" , 'Colin Perkins' Subject: Re: [AVTCORE] [AVT] New version of RTCP for IDMS X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 18:57:09 -0000 I am ok with this - but I have no expertise on the TISPAN implications - = I defer to others on that issue... Cheers, Peter Musgrave On 2011-02-07, at 8:45 AM, Brandenburg, R. (Ray) van wrote: > Hi Colin/Peter/Magnus and all, >=20 > Thanks for your input. After giving it much thought I now agree that = it would be best to define a new packet type for the sender->receiver = message.=20 >=20 > I therefore propose the following:=20 >=20 > - The receiver->sender message remains a XR block message as currently = defined by the I-D. This would allow it to be compatible with the ETSI = TISPAN version, and would prevent unnecessary duplication.=20 >=20 > - The sender->receiver message becomes a new RTCP packet type. >=20 > - We include a section on compatibility with the TISPAN solution = indicating that receivers MUST use the XR block for providing the sender = with input while senders SHOULD use the new RTCP packet type for = sender->receiver but MAY use the TISPAN defined sender->receiver XR = block (which will not be defined in the I-D but remain in the ETSI = spec). This should include an explanation on that the TISPAN = sender->receiver XR block MUST only be used for purposes of = compatibility with the TISPAN solution, but MUST NOT be used if all = senders and receivers involved support the new RTCP packet type. In this = way, backward compatibility is ensured, while not limiting improvements = made within IETF. >=20 > - A new SDP parameter is defined for the new sender->receiver RTCP = packet type. This would mean that there are two SDP parameters for the = server->client message in the IANA registry; one for the ETSI solution = and one for the IETF solution. This would also mean: if all elements in = the SDP negotiation support the IETF solution, they SHOULD use the new = RTCP packet type.=20 >=20 > Would this solution be acceptable to you?=20 >=20 > Regards, >=20 > Ray van Brandenburg >=20 >=20 >=20 > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Magnus Westerlund > Sent: donderdag 3 februari 2011 10:53 > To: avt@ietf.org > Subject: Re: [AVTCORE] [AVT] New version of RTCP for IDMS >=20 > Peter Musgrave skrev 2011-02-02 19:42: >> I think this is a valid point.=20 >>=20 >> Should this be an APP packet then? >>=20 >> =46rom 3550:=20 >> "After testing and if wider use is justified, it is RECOMMENDED that >>=20 >> each APP packet be redefined without the subtype and name fields=20 >> and >>=20 >> registered with IANA using an RTCP packet type. >=20 > Well, if one is doing a AVT defined solution for this, then we can = clearly go for a new RTCP packet type directly. We don't need to test it = before. That is already happening with the current spec, isn't it? >=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 > ---------------------------------------------------------------------- > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > This e-mail and its contents are subject to the DISCLAIMER at = http://www.tno.nl/disclaimer/email.html >=20 From Even.roni@huawei.com Mon Feb 7 15:20:56 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44F9F3A6FCB for ; Mon, 7 Feb 2011 15:20:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.494 X-Spam-Level: X-Spam-Status: No, score=-100.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bd0o3hgF90qO for ; Mon, 7 Feb 2011 15:20:55 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id B2BF83A6FCA for ; Mon, 7 Feb 2011 15:20:54 -0800 (PST) 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 <0LG900B0ISUPBJ@szxga05-in.huawei.com> for avt@ietf.org; Tue, 08 Feb 2011 07:20:49 +0800 (CST) Received: from 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 <0LG900BFRSUPPS@szxga05-in.huawei.com> for avt@ietf.org; Tue, 08 Feb 2011 07:20:49 +0800 (CST) Received: from windows8d787f9 (bzq-109-66-14-129.red.bezeqint.net [109.66.14.129]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LG90006SSUKKJ@szxml02-in.huawei.com> for avt@ietf.org; Tue, 08 Feb 2011 07:20:49 +0800 (CST) Date: Tue, 08 Feb 2011 01:16:40 +0200 From: Roni Even In-reply-to: To: 'IETF AVTCore WG' Message-id: <00ee01cbc71d$1669e9d0$433dbd70$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_7y/CmGuvzTPQY7NS17PkSQ)" Content-language: en-us Thread-index: AcvBSxwYV8dNxSwsSpWizxH3SP09VQF0a+Qw References: Subject: Re: [AVTCORE] Short WGLC on Port Mapping Between Unicast and Multicast RTP Sessions X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 23:20:56 -0000 This is a multi-part message in MIME format. --Boundary_(ID_7y/CmGuvzTPQY7NS17PkSQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, This concludes the WGLC, there were no new comments and Magnus said that this version addresses his concerns I will send the document to publication Thanks Roni Even AVTCore co-chair From: Roni Even [mailto:even.roni@huawei.com] Sent: Monday, January 31, 2011 3:31 PM To: 'IETF AVTCore WG' Subject: Short WGLC on Port Mapping Between Unicast and Multicast RTP Sessions Hi, I would like to start a one week working group last call on http://tools.ietf.org/html/draft-ietf-avtcore-ports-for-ucast-mcast-rtp-00 . This draft finished a WGLC in the AVT WG before the restructure and the new 00 revision reflects that changes that were done based on email discussion. Please review the draft and send any comment to the AVTCore mailing list (avt@ietf.org) till the end of Monday February 7th 2011. Thanks Roni Even AVTCore co chair --Boundary_(ID_7y/CmGuvzTPQY7NS17PkSQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi,

This concludes the WGLC, = there were no new comments and Magnus said that this version addresses = his concerns I will send the document to = publication

Thanks

Roni = Even

AVTCore co-chair

 

From:= = Roni Even [mailto:even.roni@huawei.com]
Sent: Monday, January = 31, 2011 3:31 PM
To: 'IETF AVTCore WG'
Subject: = Short WGLC on Port Mapping Between Unicast and Multicast RTP = Sessions

 

Hi,

I would like to = start a one week working group last call on http://tools.ietf.org/html/draft-ietf-avtcore-ports-for-ucast-= mcast-rtp-00 .

This draft = finished a WGLC in the AVT WG before the restructure and the new 00 = revision reflects that changes that were done based on email = discussion.

 

Please review the draft and send any comment to the = AVTCore mailing list (avt@ietf.org) = till the end of Monday February 7th 2011.

Thanks

Roni = Even

AVTCore co chair =

= --Boundary_(ID_7y/CmGuvzTPQY7NS17PkSQ)-- From yekui.wang@huawei.com Mon Feb 7 16:16:10 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D3763A6FE3 for ; Mon, 7 Feb 2011 16:16:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vw1-zRZ8WU22 for ; Mon, 7 Feb 2011 16:16:05 -0800 (PST) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 71C4D3A6FD3 for ; Mon, 7 Feb 2011 16:16:05 -0800 (PST) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LG900IQJVEX98@usaga04-in.huawei.com> for avt@ietf.org; Mon, 07 Feb 2011 18:16:10 -0600 (CST) Received: from dfweml201-edg.china.huawei.com ([172.18.9.107]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LG900M3XVEWLL@usaga04-in.huawei.com> for avt@ietf.org; Mon, 07 Feb 2011 18:16:09 -0600 (CST) Received: from DFWEML401-HUB.china.huawei.com (10.193.5.101) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 07 Feb 2011 16:16:06 -0800 Received: from DFWEML501-MBX.china.huawei.com ([fe80::c52a:9e19:87eb:4531]) by DFWEML401-HUB.china.huawei.com ([fe80::f07f:889f:78ef:8df3%13]) with mapi id 14.01.0270.001; Mon, 07 Feb 2011 16:15:56 -0800 Date: Tue, 08 Feb 2011 00:15:54 +0000 From: Wangyekui In-reply-to: <01fc01cbc44d$194ddc10$4be99430$%roni@huawei.com> X-Originating-IP: [10.193.125.214] To: "avt@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_BCdRc5Lo/agmcRZSQ0IVKA)" Content-language: en-US Accept-Language: en-US Thread-topic: Comments on draft-singh-avt-mprtp-01 Thread-index: AQHLxyVZZMgSXOBsZ0qnpWiKHXAj3w== X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AtBM DZHW DdYU Dv/q HdfY Jkb5 JkxW JxtZ Le/v M34/ N1/R PBPa PGZ3 Sm+R S94D VsIL; 2; YQB2AHQAQABpAGUAdABmAC4AbwByAGcAOwB2AGEAcgB1AG4AQABjAG8AbQBuAGUAdAAuAHQAawBrAC4AZgBpAA==; Sosha1_v1; 7; {F3B089DC-D753-47F0-A113-C858EDAA4D0E}; eQBlAGsAdQBpAC4AdwBhAG4AZwBAAGgAdQBhAHcAZQBpAC4AYwBvAG0A; Tue, 08 Feb 2011 00:15:45 GMT; QwBvAG0AbQBlAG4AdABzACAAbwBuACAAZAByAGEAZgB0AC0AcwBpAG4AZwBoAC0AYQB2AHQALQBtAHAAcgB0AHAALQAwADEA x-cr-puzzleid: {F3B089DC-D753-47F0-A113-C858EDAA4D0E} References: <01fc01cbc44d$194ddc10$4be99430$%roni@huawei.com> Cc: "varun@comnet.tkk.fi" Subject: [AVTCORE] Comments on draft-singh-avt-mprtp-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 00:16:10 -0000 --Boundary_(ID_BCdRc5Lo/agmcRZSQ0IVKA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Varun, all, I have some comments on draft-singh-avt-mprtp-01, for discussion. - First of all, I think this draft initiated a very useful work. For example, today, many mobile operators have deployed dual-plane IP bearer networks, wherein a multipath version of RTP can be used for real-time communications such as voice- and video-over-IP services. BTW, you may want to mention this in the introduction section. - The draft specifies the negotiation of multiple paths is through upgrading from a single-path session and using in-band signaling (i.e. RTP header extension) for indication of additional paths. Would it be better to negotiate the use of one or more of the available paths out-of-band (i.e. using SDP)? One problem with in-band negotiation is that, if the initial path happens to be broken, then even the session setup would fail. Another problem is that in-band information may get lost (and when it happens the negotiation would fail). - In some cases, it may be useful to use multiple paths concurrently, for improved throughput. In some other cases, it may be more desirable to use only a subset of available paths at any time instance. For example, in mobile networks using dual-plane IP bearer, typically the better-performing path is used, while the other path is kept there for fast fallback when the path being used has problem. Therefore, it would be desirable if signaling of such a capability/preference is possible. - Finally, it would be useful if it is possible to indicate more path specific information when advertising paths (or "interfaces" as used in the draft), e.g., which of the two planes in a network using dual-plane IP bearer. It might be sufficient if there is a hook specified to enable backwards compatible extensions when the potential multipath RTP standard is used in the future by application system standards. BR, YK --Boundary_(ID_BCdRc5Lo/agmcRZSQ0IVKA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi Varun, all,

 

I have some comments on draft-singh-avt-mprtp-01, for discussion.

 

-          First of all, I think this draft initiated a very useful wor= k. For example, today, many mobile operators have deployed dual-plane IP be= arer networks, wherein a multipath version of RTP can be used for real-time communications such as voice- and= video-over-IP services. BTW, you may want to mention this in the introduct= ion section.

=  

-          The draft specifies the negotiation of multiple paths is thr= ough upgrading from a single-path session and using in-band signaling (i.e.= RTP header extension) for indication of additional paths. Would it be better to negotiate the use of one or mor= e of the available paths out-of-band (i.e. using SDP)? One problem with in-= band negotiation is that, if the initial path happens to be broken, then ev= en the session setup would fail. Another problem is that in-band information may get lost (and when it happ= ens the negotiation would fail).

 

-          In some cases, it may be useful to use multiple paths concur= rently, for improved throughput. In some other cases, it may be more desira= ble to use only a subset of available paths at any time instance. For example, in mobile networks using dual-pla= ne IP bearer, typically the better-performing path is used, while the other= path is kept there for fast fallback when the path being used has problem.= Therefore, it would be desirable if signaling of such a capability/preference is possible.

 

-          Finally, it would be useful if it is possible to indicate mo= re path specific information when advertising paths (or “interfaces&#= 8221; as used in the draft), e.g., which of the two planes in a network using dual-plane IP bearer. It might be suffic= ient if there is a hook specified to enable backwards compatible extensions= when the potential multipath RTP standard is used in the future by applica= tion system standards.

 

BR, YK

 

--Boundary_(ID_BCdRc5Lo/agmcRZSQ0IVKA)-- From Even.roni@huawei.com Tue Feb 8 00:20:37 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A3BE3A7003; Tue, 8 Feb 2011 00:20:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.194 X-Spam-Level: X-Spam-Status: No, score=-102.194 tagged_above=-999 required=5 tests=[AWL=1.700, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDAVYEtX1Bjt; Tue, 8 Feb 2011 00:20:26 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 076AD3A6CB7; Tue, 8 Feb 2011 00:20:26 -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 <0LGA00GB4HTWG1@szxga04-in.huawei.com>; Tue, 08 Feb 2011 16:20:21 +0800 (CST) Received: from 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 <0LGA00FZ5HTWSW@szxga04-in.huawei.com>; Tue, 08 Feb 2011 16:20:20 +0800 (CST) Received: from windows8d787f9 (bzq-109-66-14-129.red.bezeqint.net [109.66.14.129]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LGA00CDOHTN38@szxml01-in.huawei.com>; Tue, 08 Feb 2011 16:20:20 +0800 (CST) Date: Tue, 08 Feb 2011 10:16:07 +0200 From: Roni Even To: 'Robert Sparks' , iesg-secretary@ietf.org Message-id: <011601cbc768$73dc3a50$5b94aef0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_MCuP+dGUJ7XLZo/6IfTEGQ)" Content-language: en-us Thread-index: AcvHaG3Mzoq83BbbTamaaMgN+TUBGQ== Cc: 'Magnus Westerlund' , draft-ietf-avtcore-ports-for-ucast-mcast-rtp.all@tools.ietf.org, 'IETF AVTCore WG' Subject: [AVTCORE] request to publish draft-ietf-avtcore-ports-for-ucast-mcast-rtp-00 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 08:20:37 -0000 This is a multi-part message in MIME format. --Boundary_(ID_MCuP+dGUJ7XLZo/6IfTEGQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Robert, I'd like to request that draft-ietf-avtcore-ports-for-ucast-mcast-rtp-00, Port Mapping Between Unicast and Multicast RTP Sessions, be published as Standard Track RFC. I've reviewed the draft in detail, and the AVT / AVTCore working groups were given the opportunity to comment. The draft is required for RAMS, and doesn't conflict with other work in AVTCore. Accordingly, please consider it for publication. Thanks, Roni Even (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? The document shepherd is Roni Even. I have reviewed the document, and believe it is ready for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document is the result of an effort done by key WG members in order to address a problem encountered in RAMS (Rapid Acquisition for RTP) which was recognized as a general problem that requires a solution. The current approach reflects that consensus in the WG. It went through two Working Group last calls and people had enough time to review it. The document shepherd feels comfortable with the review it got. Note that the document started at AVT and was at -11 revision before it was moved to the new AVTCore WG. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No concerns (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No Concerns (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The document has strong consensus for key members of the AVT/AVTCore WGs. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits?(See the Checklist and idnits ).Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? The idnits tool reports a comment which is not correct about the latest version of draft-ietf-avt-rapid-acquisition-for-rtp which is 17 and not 16. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. References are split. There is a normative reference to draft-ietf-avt-rtp-cnames which is in the RFC Editor queue. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The IANA consideration section exists and is inline with the body of the document. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? No such sections (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. "This document presents a port mapping solution that allows RTP receivers to choose their own ports for an auxiliary unicast session in RTP applications using both unicast and multicast services. The solution provides protection against denial-of-service or packet amplification attacks that could be used to cause one or more RTP packets to be sent to a victim client." Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? There was a discussion if to use a token or cookie for the solution. The initial solution was based on a cookie but after a technical discussion in IETF78 and mailing list call for consensus the token based solution was selected. There was a consensus to use this approach. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? The document shepherd is not aware of current implementations but the vendors of RAMS solution will support --Boundary_(ID_MCuP+dGUJ7XLZo/6IfTEGQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Robert,

I'd like to request that draft-ietf-avtcore-ports-for-ucast-mcast-rtp-00, Port Mapping Between Unicast and Multicast RTP Sessions, be published as Standard Track RFC.

I've reviewed the draft in detail , and th roups were given the opportunity to comment. The draft is required for RAMS, and doesn't conflict with other work in AVTCore. Accordingly, please consider it for publication.

 

Thanks,

Roni Even

 

 

(1.a) Who is the Document Shepherd for this document? Has the

     ; & herd personally reviewed this version of the

        document and, in particular, does he or she believe this

        version is ready for forwarding to the IESG for publication?

 

The document shepherd is Roni Even. I have reviewed the document, and believe it is ready for publication.

 

  (1.b) Has the document had adequate review both from key WG members

        and from key non-WG members? Does the Docume nt Sheph p class=Preformatted>        any concerns about the depth or breadth of the reviews that

        have been performed? 

 

The document is the result of an effort done by key WG members in order to address a problem encountered in RAMS (Rapid Acquisition for RTP) which was recognized as a general problem that requires a solution. The current approach reflects that consensus in the WG. It went through two Working Group last calls and people had enough time to review it. The document shepherd feels comfortable with the review it got.

Note that the document started at AVT and was at -11 revision before it was moved to the new AVTCore WG.

 

  (1.c) Does the Document She pherd ha ment

        needs more review from a particular or broader perspective,

        e.g., security, operational complexity, someone familiar with

        AAA, internationalization or XML?

 

No concerns

 

 

  (1.d) Does the Document Shepherd have any specific concerns or

        issues with this document that the Responsible Area Director

        and/or the IESG should be aware of? For example, perhaps he

        has concerns whether there really is a need for it. In any

        event, if the WG has discussed those issues and has indicated

        that it still wishes to advance the document, detail those

        concerns here. Has an IPR disclosure related to this document

        been filed? If so, please include a reference to the

        disclosure and summarize the WG discussion and conclusion on

 

No Concerns

 

(1.e) How solid is the WG consensus behind this document? Does it

        represent the strong concurrence of a few individuals, with

        others being silent, or does the WG as a whole understand and

        agree with it?

 

The document has strong consensus for key members of the AVT/AVTCore WGs.

 

  (1.f) Has anyone threatened an appeal or otherwise indicated ext reme         discontent? If so, please summarise the areas of conflict in

        separate email messages to the Responsible Area Director. (It

        should be in a separate email because this questionnaire is

        entered into the ID Tracker.)

 

No

  (1.g) Has the Document Shepherd personally verified that the

document satisfies all ID nits?(See the Checklist and idnits).Boilerplate checks ar e not en be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews?

 

The idnits tool reports a comment which is not correct about the latest version of draft-ietf-avt-rapid-acquisition-for-rtp which is 17 and not 16.

 

  (1.h) Has the document split its references into normative and

        informative? Are there normative references to documents that

        are not ready for advancement or are otherwise in an unclear

    &n bsp;&nbs uch normative references exist, what is the

        strategy for their completion? Are there normative references

        that are downward references, as described in [RFC3967]? If

        so, list these downward references to support the Area

        Director in the Last Call procedure for them [RFC3967].

  

 

References are split. There is a normative reference to draft-ietf-avt-rtp-cnames which is in the RFC Editor queue.

  ;< (1.i) Has the Document Shepherd verified that the document IANA

        consideration section exists and is consistent with the body

        of the document? If the document specifies protocol

        extensions, are reservations requested in appropriate IANA

        registries? Are the IANA registries clearly identified? If

        the document creates a new registry, does it define the

        proposed initial contents of the registry and an allocation

     &n bsp;&nbs ure registrations? Does it suggest a

        reasonable name for the new registry? See [RFC5226]. If the

        document describes an Expert Review process has Shepherd

        conferred with the Responsible Area Director so that the IESG

        can appoint the needed Expert during the IESG Evaluation?

 

 

The IANA consideration section exists and is inline with the body of the document.

 

  (1.j) Has the Document Shepherd verified t hat sect p>

        document that are written in a formal language, such as XML

        code, BNF rules, MIB definitions, etc., validate correctly in

        an automated checker?

 

No such sections

 

  (1.k) The IESG approval announcement includes a Document

        Announcement Write-Up. Please provide such a Document

        Announcement Write-Up? Recent examples can be found in the

        &q uot;Acti r approved documents. The approval

        announcement contains the following sections:

     

Technical Summary

        Relevant content can frequently be found in the abstract

        and/or introduction of the document. If not, this may be

        an indication that there are deficiencies in the abstract

        or introduction.

     

“This document presents a port mapping solution that allows RTP    receivers to choose their own ports for an auxiliary unicast session

   in RTP applications using both unicast and multicast services.  The

   solution provides protection against denial-of-service or packet

   amplification attacks that could be used to cause one or more RTP

   packets to be sent to a victim client.”

 

Working Group Summary

        Was there anything in WG process that is worth noting? For

        example, was there controversy about particular points or

     &nb sp;  ns where the consensus was particularly

        rough?

     

There was a discussion if to use a token or cookie for the solution. The initial solution was based on a cookie but after a technical discussion in IETF78 and mailing list call for consensus the token based solution was selected. There was a consensus to use this approach.

 

 

 

Document Quality

        Are there existing implementations of the protocol? Have a

        significant number of vendors indicated their plan to

        merit special mention as having done a thorough review,

        e.g., one that resulted in important changes or a

        conclusion that the document had no substantive issues? If

        there was a MIB Doctor, Media Type or other expert review,

        what was its course (briefly)? In the case of a Media Type

        review, on what date was the request posted?

The document shepherd is not aware of current implementations but the vendors of RAMS solution will support

--Boundary_(ID_MCuP+dGUJ7XLZo/6IfTEGQ)-- From thomas.belling@nsn.com Tue Feb 8 06:03:54 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 752343A7120 for ; Tue, 8 Feb 2011 06:03:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01AU5zMLV1Xr for ; Tue, 8 Feb 2011 06:03:50 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 44A4A3A68C0 for ; Tue, 8 Feb 2011 06:03:50 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p18E3tvh011095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Feb 2011 15:03:55 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p18E3pjE022282; Tue, 8 Feb 2011 15:03:55 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Feb 2011 15:03:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBC799.057738A8" Date: Tue, 8 Feb 2011 15:03:53 +0100 Message-ID: <744A66DF31B5B34EA8B08BBD8187A7220351B576@DEMUEXC014.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-avtcore-ecn-for-rtp-00.txt: Are ECN summary reports collaborative or unillateral Thread-Index: AcvHmPmeh1FdgtDWTtSz6kuDRVkO8Q== From: "Belling, Thomas (NSN - DE/Munich)" To: "ext Magnus Westerlund" , "IETF AVT WG" X-OriginalArrivalTime: 08 Feb 2011 14:03:55.0221 (UTC) FILETIME=[05D8D050:01CBC799] Subject: [AVTCORE] draft-ietf-avtcore-ecn-for-rtp-00.txt: Are ECN summary reports collaborative or unillateral X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 14:03:54 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBC799.057738A8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Magnus, RFC 3611 states: Each "rtcp-xr" parameter belongs to one of two categories. The first category, the unilateral parameters, are for report blocks that simply report on the RTP stream and related metrics. The second category, collaborative parameters, are for XR blocks that involve actions by more than one party in order to carry out their functions SDP offer-answer procedures also differ between those categories. To which category does the "ecn-sum" report belong? I assume unilateral. Is that correct? In any case please add a clarifying statement in the next version of = your draft (as I did in my earlier proposal) Thomas ---------------------------------- Dr. Thomas Belling=20 3GPP Standardisation=20 COO RTP IE 3GPP Converged Core=20 MchM 34/417 Nokia Siemens Networks GmbH & Co. KG. =20 Sankt-Martin-Str. 76 D-81541 M=FCnchen Germany Tel +49 89 5159 35207=20 Mobil +49 172 2974678=20 Fax +49 89 636 49158 Email Thomas.Belling@nsn.com=20 ------_=_NextPart_001_01CBC799.057738A8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft-ietf-avtcore-ecn-for-rtp-00.txt: Are ECN summary reports = collaborative or unillateral

Dear = Magnus,

RFC 3611 = states:

   Each "rtcp-xr" parameter belongs = to one of two categories.  The first

   = category, the unilateral parameters, are = for report blocks that

   = simply report on the RTP stream and related metrics.  The = second

   = category, collaborative parameters, are for XR blocks that = involve

   = actions by more than one party in order to carry out their = functions

SDP offer-answer procedures also differ between those = categories.

To which = category does the “ecn-sum” report = belong?

I assume = unilateral. Is that correct?

In any case = please add a clarifying statement in the next version of your draft (as I did in my earlier = proposal)

Thomas

----------------------------------
Dr. Thomas Belling
3GPP Standardisation
COO RTP IE 3GPP Converged Core
MchM 34/417
Nokia Siemens Networks=A0=A0GmbH & Co. = KG.=A0=A0=A0=A0=A0=A0=A0=A0
Sankt-Martin-Str. 76
D-81541 M=FCnchen Germany
Tel=A0=A0=A0=A0=A0=A0 +49 89 5159 = 35207
Mobil=A0=A0 +49 172 2974678
Fax=A0=A0=A0=A0 +49 89 636 49158
Email=A0=A0 Thomas.Belling@nsn.com

------_=_NextPart_001_01CBC799.057738A8-- From csp@csperkins.org Wed Feb 9 10:21:04 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB7BC3A69E7 for ; Wed, 9 Feb 2011 10:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcZwmUufnQU6 for ; Wed, 9 Feb 2011 10:21:03 -0800 (PST) Received: from lon1-msapost-1.mail.demon.net (lon1-msapost-1.mail.demon.net [195.173.77.180]) by core3.amsl.com (Postfix) with ESMTP id 76FAA3A69EB for ; Wed, 9 Feb 2011 10:21:03 -0800 (PST) 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 1PnEfA-0002DV-ZC; Wed, 09 Feb 2011 18:21:12 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Colin Perkins In-Reply-To: Date: Wed, 9 Feb 2011 18:21:12 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1F2FD678-D0A8-43A2-AB58-85401BD781F4@tno.nl> <5D51ED4A-D95A-4DE6-A87F-A80330B60FE2@csperkins.org> <5BEA1E7A-DAD2-4A3E-B135-441EAA75BC88@magorcorp.com> <4D4A7AFB.6090705@ericsson.com> To: "Brandenburg, R. (Ray) van" X-Mailer: Apple Mail (2.1082) Cc: 'Magnus Westerlund' , "avt@ietf.org" Subject: Re: [AVTCORE] [AVT] New version of RTCP for IDMS X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 18:21:05 -0000 Sounds good to me. Colin On 7 Feb 2011, at 13:45, Brandenburg, R. (Ray) van wrote: > Hi Colin/Peter/Magnus and all, >=20 > Thanks for your input. After giving it much thought I now agree that = it would be best to define a new packet type for the sender->receiver = message.=20 >=20 > I therefore propose the following:=20 >=20 > - The receiver->sender message remains a XR block message as currently = defined by the I-D. This would allow it to be compatible with the ETSI = TISPAN version, and would prevent unnecessary duplication.=20 >=20 > - The sender->receiver message becomes a new RTCP packet type. >=20 > - We include a section on compatibility with the TISPAN solution = indicating that receivers MUST use the XR block for providing the sender = with input while senders SHOULD use the new RTCP packet type for = sender->receiver but MAY use the TISPAN defined sender->receiver XR = block (which will not be defined in the I-D but remain in the ETSI = spec). This should include an explanation on that the TISPAN = sender->receiver XR block MUST only be used for purposes of = compatibility with the TISPAN solution, but MUST NOT be used if all = senders and receivers involved support the new RTCP packet type. In this = way, backward compatibility is ensured, while not limiting improvements = made within IETF. >=20 > - A new SDP parameter is defined for the new sender->receiver RTCP = packet type. This would mean that there are two SDP parameters for the = server->client message in the IANA registry; one for the ETSI solution = and one for the IETF solution. This would also mean: if all elements in = the SDP negotiation support the IETF solution, they SHOULD use the new = RTCP packet type.=20 >=20 > Would this solution be acceptable to you?=20 >=20 > Regards, >=20 > Ray van Brandenburg >=20 >=20 >=20 > -----Original Message----- > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Magnus Westerlund > Sent: donderdag 3 februari 2011 10:53 > To: avt@ietf.org > Subject: Re: [AVTCORE] [AVT] New version of RTCP for IDMS >=20 > Peter Musgrave skrev 2011-02-02 19:42: >> I think this is a valid point.=20 >>=20 >> Should this be an APP packet then? >>=20 >> =46rom 3550:=20 >> "After testing and if wider use is justified, it is RECOMMENDED that >>=20 >> each APP packet be redefined without the subtype and name fields=20 >> and >>=20 >> registered with IANA using an RTCP packet type. >=20 > Well, if one is doing a AVT defined solution for this, then we can = clearly go for a new RTCP packet type directly. We don't need to test it = before. That is already happening with the current spec, isn't it? >=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 > ---------------------------------------------------------------------- > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > This e-mail and its contents are subject to the DISCLAIMER at = http://www.tno.nl/disclaimer/email.html >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt --=20 Colin Perkins http://csperkins.org/ From dean.willis@softarmor.com Thu Feb 10 15:47:14 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5336C3A6B00 for ; Thu, 10 Feb 2011 15:47:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EaxvpCWt+xZx for ; Thu, 10 Feb 2011 15:47:13 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 6E35C3A6ADC for ; Thu, 10 Feb 2011 15:47:13 -0800 (PST) Received: by ywk9 with SMTP id 9so933643ywk.31 for ; Thu, 10 Feb 2011 15:47:26 -0800 (PST) Received: by 10.100.95.2 with SMTP id s2mr10407334anb.57.1297381646629; Thu, 10 Feb 2011 15:47:26 -0800 (PST) Received: from [192.168.2.104] (cpe-66-25-28-30.tx.res.rr.com [66.25.28.30]) by mx.google.com with ESMTPS id c7sm136501ana.37.2011.02.10.15.47.25 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 10 Feb 2011 15:47:25 -0800 (PST) From: Dean Willis Content-Type: text/plain; charset=us-ascii Message-Id: <0EE596AE-156F-4665-B296-4A76FCFF8484@softarmor.com> Date: Thu, 10 Feb 2011 17:47:24 -0600 To: avt@ietf.org Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [AVTCORE] Offtopic: Looking for old Volcaltec iWave stuff X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 23:47:14 -0000 Sorry to interrupt with a non-sequitur, but I'm looking for instances of = Vocaltec Internet Wave software and content. It used to be free to = download, but disappeared a few years back. If you have it in a personal archive, please holler at me privately. -- Dean= From vsingh.ietf@gmail.com Fri Feb 11 06:16:33 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 550693A6ADE for ; Fri, 11 Feb 2011 06:16:33 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jfg3CfKeUkyn for ; Fri, 11 Feb 2011 06:16:32 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 42BC73A6A5D for ; Fri, 11 Feb 2011 06:16:32 -0800 (PST) Received: by fxm9 with SMTP id 9so3173151fxm.31 for ; Fri, 11 Feb 2011 06:16:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=43D3xzf2uYHDtPTdM7NR3/o/+l2+yFFgGyTkBBC56Tk=; b=UkNzuv/PCf8hmeT62uaDGL7Z28wFUtJrMy93W0p0JwI5oDolZRkc1ukthhGNuahm+1 lXrkp45b3dHEExXQx/vtLTk3xQC55w9dB0iFoD0UhFQ9ncBudGBYPwL4aCfgM+DTFD9q TMOuW91fcYVOBjS4bzUsPt5NHibk91nr/NpYY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=wXfMX8Bz5+dsuPmTtWNmxe74m8wTBlzBO9l5abds8N+XHyL6C1GnfDWvTnfHm/5+JX +Mb6tuXFjBqGWFW9K1m32uUmVzt4SPl01daYs7ZeUR4ht6wpsZmkcAkQ6jlO/OGR4AAJ V03O5qfpOMSXCUlY3qsOue1Pmyz9v2BRCj6hc= Received: by 10.223.102.77 with SMTP id f13mr557161fao.113.1297433794418; Fri, 11 Feb 2011 06:16:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.49.87 with HTTP; Fri, 11 Feb 2011 06:16:14 -0800 (PST) In-Reply-To: References: <01fc01cbc44d$194ddc10$4be99430$%roni@huawei.com> From: varun singh Date: Fri, 11 Feb 2011 16:16:14 +0200 Message-ID: To: Wangyekui Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "varun@comnet.tkk.fi" , "avt@ietf.org" Subject: Re: [AVTCORE] Comments on draft-singh-avt-mprtp-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 14:16:33 -0000 Hi Ye-kui, comments inline On Tue, Feb 8, 2011 at 02:15, Wangyekui wrote: > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 First of all, I think this draft initiated a= very useful work. For example, today, many mobile operators have deployed = dual-plane IP bearer networks, wherein a multipath version of RTP can be us= ed for real-time communications such as voice- and video-over-IP services. = BTW, you may want to mention this in the introduction section. Can you elaborate on what is a dual-plane IP bearer. > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 The draft specifies the negotiation of multi= ple paths is through upgrading from a single-path session and using in-band= signaling (i.e. RTP header extension) for indication of additional paths. = Would it be better to negotiate the use of one or more of the available pat= hs out-of-band (i.e. using SDP)? One problem with in-band negotiation is th= at, if the initial path happens to be broken, then even the session setup w= ould fail. Another problem is that in-band information may get lost (and wh= en it happens the negotiation would fail). If the initial path is broken then it would also fail for the case of single path RTP. In the spec we allow for ICE and SDP. SDP is too slow to always negotiate. > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 In some cases, it may be useful to use multi= ple paths concurrently, for improved throughput. In some other cases, it ma= y be more desirable to use only a subset of available paths at any time ins= tance. For example, in mobile networks using dual-plane IP bearer, typicall= y the better-performing path is used, while the other path is kept there fo= r fast fallback when the path being used has problem. Therefore, it would b= e desirable if signaling of such a capability/preference is possible. > This is a good point and the draft aims to have basic mechanisms first. Profiles to be added later, may be to the same document or as a different draft. We'll add this inside as an editor's note. > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Finally, it would be useful if it is possibl= e to indicate more path specific information when advertising paths (or =93= interfaces=94 as used in the draft), e.g., which of the two planes in a net= work using dual-plane IP bearer. It might be sufficient if there is a hook = specified to enable backwards compatible extensions when the potential mult= ipath RTP standard is used in the future by application system standards. We need to stay independent of network architecture or infrastructure. However, can you elaborate on the extension that can signal a path's characteristic? Regards, Varun From thomas.belling@nsn.com Fri Feb 11 11:39:20 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDCB83A6A2F for ; Fri, 11 Feb 2011 11:39:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5JvZYmsFFie for ; Fri, 11 Feb 2011 11:39:17 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 324C73A6A2D for ; Fri, 11 Feb 2011 11:39:16 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p1BJdUeU029719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 Feb 2011 20:39:30 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p1BJdRKT006168; Fri, 11 Feb 2011 20:39:30 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Feb 2011 20:38:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBCA23.375875E8" Date: Fri, 11 Feb 2011 20:38:09 +0100 Message-ID: <744A66DF31B5B34EA8B08BBD8187A72203597EAD@DEMUEXC014.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-avtcore-ecn-for-rtp-00.txt: What to do if "ecn-fb" has not been negotiated via rtcp.fb attribute? Thread-Index: AcvKIyjyHuuKGEEsQbCzEE/SR/rGVA== From: "Belling, Thomas (NSN - DE/Munich)" To: "IETF AVT WG" , "ext Magnus Westerlund" X-OriginalArrivalTime: 11 Feb 2011 19:38:11.0025 (UTC) FILETIME=[3746E410:01CBCA23] Subject: [AVTCORE] draft-ietf-avtcore-ecn-for-rtp-00.txt: What to do if "ecn-fb" has not been negotiated via rtcp.fb attribute? X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 19:39:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBCA23.375875E8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Magnus, You omitted one more clarification I suggested for the "rtcp-fb" attribute negotiation procedures: I suggested a recommendation for the case that "rtcp-fb" attribute negotiation procedures concluded that "ecn-fb" is not allowed to use application specific feedback when ECT marked packets are received. Did you intentionally omit this (why?) or was it simply take away with proposed text you considered redundant? Thomas ---------------------------------- Dr. Thomas Belling=20 3GPP Standardisation=20 Nokia Siemens Networks =20 ------_=_NextPart_001_01CBCA23.375875E8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-ietf-avtcore-ecn-for-rtp-00.txt: What to do if = "ecn-fb" has not been negotiated via rtcp.fb = attribute?

Dear = Magnus,

You omitted one more clarification I suggested for the “rtcp-fb” attribute negotiation = procedures:

I suggested a = recommendation for the case = that “rtcp-fb” = attribute negotiation procedures concluded = that “ecn-fb” is not = allowed to use application specific = feedback when ECT marked packets are = received.

Did you = intentionally omit = this (why?) or was = it simply take away with proposed text you considered redundant?

Thomas

----------------------------------
Dr. Thomas Belling
3GPP Standardisation
Nokia Siemens Networks  

------_=_NextPart_001_01CBCA23.375875E8-- From wwwrun@rfc-editor.org Fri Feb 11 16:04:10 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E7FD3A6A24; Fri, 11 Feb 2011 16:04:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.025 X-Spam-Level: X-Spam-Status: No, score=-102.025 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ym+N8-KYQ08H; Fri, 11 Feb 2011 16:04:09 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 583F93A6A89; Fri, 11 Feb 2011 16:04:09 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id A72C3E074F; Fri, 11 Feb 2011 16:04:25 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110212000425.A72C3E074F@rfc-editor.org> Date: Fri, 11 Feb 2011 16:04:25 -0800 (PST) Cc: avt@ietf.org, rfc-editor@rfc-editor.org Subject: [AVTCORE] RFC 6128 on RTP Control Protocol (RTCP) Port for Source-Specific Multicast (SSM) Sessions X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Feb 2011 00:04:10 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6128 Title: RTP Control Protocol (RTCP) Port for Source-Specific Multicast (SSM) Sessions Author: A. Begen Status: Standards Track Stream: IETF Date: February 2011 Mailbox: abegen@cisco.com Pages: 6 Characters: 11544 Updates: RFC5760 I-D Tag: draft-ietf-avt-rtcp-port-for-ssm-04.txt URL: http://www.rfc-editor.org/rfc/rfc6128.txt The Session Description Protocol (SDP) has an attribute that allows RTP applications to specify an address and a port associated with the RTP Control Protocol (RTCP) traffic. In RTP-based source-specific multicast (SSM) sessions, the same attribute is used to designate the address and the RTCP port of the Feedback Target in the SDP description. However, the RTCP port associated with the SSM session itself cannot be specified by the same attribute to avoid ambiguity, and thus, is required to be derived from the "m=" line of the media description. Deriving the RTCP port from the "m=" line imposes an unnecessary restriction. This document removes this restriction by introducing a new SDP attribute. [STANDARDS-TRACK] This document is a product of the Audio/Video Transport Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From stewe@stewe.org Sun Feb 13 10:40:59 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6956F3A6A1C; Sun, 13 Feb 2011 10:40:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.133 X-Spam-Level: X-Spam-Status: No, score=-0.133 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nz0VYpBVapwi; Sun, 13 Feb 2011 10:40:58 -0800 (PST) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id DE1BE3A6A00; Sun, 13 Feb 2011 10:40:57 -0800 (PST) Received: from [192.168.1.106] (unverified [24.5.132.232]) by stewe.org (SurgeMail 3.9e) with ESMTP id 4221-1743317 for multiple; Sun, 13 Feb 2011 19:41:17 +0100 User-Agent: Microsoft-MacOutlook/14.2.0.101115 Date: Sun, 13 Feb 2011 10:41:10 +0100 From: Stephan Wenger To: IETF AVT WG , , Message-ID: Thread-Topic: Incoming liaison from MPEG Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3380438477_1401406" X-Originating-IP: 24.5.132.232 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (24.5.132.232) was found in the spamhaus database. http://www.spamhaus.net Subject: [AVTCORE] Incoming liaison from MPEG X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2011 18:40:59 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3380438477_1401406 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi all, We have received a liaison statement from MPEG. They inform us of their progress at their last meeting in Korea. Their streaming over HTTP technology (known as DASH) is now in Draft International Standard (DIS) state, and support for DASH has also been included in a Draft Amendment to their MPEG-4 file format specification. With respect to the latter, the AVT folks may find the informal description of RTP's synchronization mechanisms in Annex H particularly interesting. I glanced over it and found it consistent with RTP and its common use, but perhaps someone else wants to check as well? No actions are required by the IETF, but they welcome comments and participation. The statement should be available in the official IETF tracker (https://datatracker.ietf.org/liaison/) shortly; until then, you can email me for a copy. Regards, Stephan --B_3380438477_1401406 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Hi all,
We have re= ceived a liaison statement from MPEG.  They inform us of their progress= at their last meeting in Korea.  Their streaming over HTTP technology = (known as DASH) is now in Draft International Standard (DIS) state, and supp= ort for DASH has also been included in a Draft Amendment to their MPEG-4 fil= e format specification.  With respect to the latter, the AVT folks may = find the informal description of RTP's synchronization mechanisms in Annex H= particularly interesting.  I glanced over it and found it consistent w= ith RTP and its common use, but perhaps someone else wants to check as well?=
No actions are required by the IETF, but they welcome comments an= d participation.
The statement should be available in the official= IETF tracker (https://datatr= acker.ietf.org/liaison/) shortly; until then, you can email me for a cop= y.
Regards,
Stephan
  
<= /html> --B_3380438477_1401406-- From keith.drage@alcatel-lucent.com Mon Feb 14 05:38:50 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 207F63A6D37 for ; Mon, 14 Feb 2011 05:38:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.199 X-Spam-Level: X-Spam-Status: No, score=-105.199 tagged_above=-999 required=5 tests=[AWL=1.050, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qECwUM-7ZaWM for ; Mon, 14 Feb 2011 05:38:44 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id C73503A6CD5 for ; Mon, 14 Feb 2011 05:38:42 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p1EDcOGs027816 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 14 Feb 2011 14:39:04 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Mon, 14 Feb 2011 14:38:50 +0100 From: "DRAGE, Keith (Keith)" To: IETF AVT WG Date: Mon, 14 Feb 2011 14:38:49 +0100 Thread-Topic: WG Action: Audio/Video Transport Extensions (AVTEXT) Thread-Index: Acu85zpEuiQ7t/V2QcOYKt2VrT2r8gPZJdqQ Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Subject: [AVTCORE] FW: WG Action: Audio/Video Transport Extensions (AVTEXT) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 13:38:50 -0000 (As AVTEXT WG chair) I note that we only have 69 members so far on the AVTEXT WG mailing list - = subscription details below (and also on the WG charter page on the IETF web= site). While 69 is a goodly number to start a working group, I was expecting there= to be a few more of you out there. The chairs of AVTEXT are about to make = some more working group consensus calls which will only be done on the AVTE= XT mailing list. In case you have forgotten that you need to register for the new AVTEXT mai= ling list (and indeed PAYLOAD and XRBLOCK as well) then I'm sending this re= minder to the AVT list.=20 For those who wish to continue only in AVTCORE, you need do nothing as the = old AVT list is the mailing list for the new AVTCORE. Regards Keith > -----Original Message----- > From: IESG Secretary [mailto:iesg-secretary@ietf.org]=20 > Sent: 25 January 2011 23:23 > To: IETF Announcement list > Cc: DRAGE, Keith (Keith); magnus.westerlund@ericsson.com;=20 > avtext@ietf.org > Subject: WG Action: Audio/Video Transport Extensions (AVTEXT)=20 >=20 > A new IETF working group has been formed in the Real-time=20 > Applications and Infrastructure Area. For additional=20 > information, please contact the Area Directors or the WG Chairs. >=20 > Audio/Video Transport Extensions (AVTEXT) > --------------------------------------------------- > Current Status: Active Working Group >=20 > Chairs: > * Keith Drage > * Magnus Westerlund >=20 > Real-time Applications and Infrastructure Area Director(s): > * Gonzalo Camarillo > * Robert Sparks >=20 > Real-time Applications and Infrastructure Area Advisor: > * Gonzalo Camarillo >=20 > Mailing Lists: > General Discussion: avtext@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/avtext > Archive: http://www.ietf.org/mail-archive/web/avtext/index.html >=20 > Description of Working Group: >=20 > The Full-Standard Real-time Transport Protocol, RTP [RFC=20 > 3550], along with its associated profiles and payload formats=20 > provides for real- time transmission of audio and video over=20 > unicast and multicast transports. RTP is widely implemented,=20 > and deployed for a wide range of applications, ranging from=20 > telephony to television over IP. As new applications have=20 > emerged, the need for guidelines for the use of the RTP/RTCP=20 > protocols and extensions specific to those applications has=20 > been identified. >=20 > The AVTEXT working group is charted to develop=20 > application-specific guidelines for the use of RTP/RTCP=20 > protocols with the AVP, SAVP, AVPF, and SAVPF profiles, and=20 > extensions to those protocols that are driven by=20 > application-specific needs. Proposals for extensions with=20 > general applicability to many different RTP/RTCP usages=20 > should be taken to the AVTCORE working group. >=20 > The AVTEXT working group is constrained to use the protocol=20 > extension mechanisms defined in the core protocols (such as=20 > RTP Header extensions [RFC5285], AVPF Feedback Messages=20 > [RFC4585], and SDES Items [RFC3550]). If new ways to extend=20 > the core protocols are needed, they will be developed in the=20 > AVTCORE working group. >=20 > In addition to the milestones called out below, the AVTEXT=20 > working group's initial tasks will include completing any new=20 > work identified during IESG evaluation for the Rapid=20 > Acquisition of Multicast RTP Sessions. >=20 > Goals and Milestones: >=20 > Jun 2011 Submit Considerations for RAMS Scenarios for=20 > Informational Oct 2011 Submit RTP Header extension for mixer=20 > to client audio level=20 > indication as Proposed Standard Oct 2011 Submit=20 > RTP Header extension for client to mixer audio level=20 > indication as proposed standard Dec 2011 Submit=20 > Support for multiple clock rates in an RTP session for=20 > Proposed Standard > Dec 2011 Submit SRTP Store-and-Forward Use Cases and=20 > Requirements for=20 > Informational > Dec 2011 Submit Use of the Secure Real-time Transport=20 > Protocol (SRTP)=20 > in Store-and-Forward Applications for Proposed Standard > = From Internet-Drafts@ietf.org Mon Feb 14 21:45:07 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5373B3A6E45; Mon, 14 Feb 2011 21:45:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBQ5kbql8dcw; Mon, 14 Feb 2011 21:45:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EB6E3A6E3E; Mon, 14 Feb 2011 21:45:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110215054502.26622.8752.idtracker@localhost> Date: Mon, 14 Feb 2011 21:45:02 -0800 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action:draft-ietf-avtcore-feedback-supression-rtp-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 05:45:07 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF. Title : RTCP Extension for Feedback Suppression Indication Author(s) : W. Wu, et al. Filename : draft-ietf-avtcore-feedback-supression-rtp-00.txt Pages : 17 Date : 2011-02-14 In a large RTP session using the RTCP feedback mechanism defined in RFC 4585, a media source or middlebox may experience transient overload if some event causes a large number of receivers to send feedback at once. This feedback implosion can be mitigated if the device suffering from overload can send a third party loss report message to the receivers to inhibit further feedback. This memo defines RTCP extensions for third party loss report, to suppress NACK and FIR feedback requests. It also defines associated SDP signalling. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtcore-feedback-supression-rtp-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-avtcore-feedback-supression-rtp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-14214156.I-D@ietf.org> --NextPart-- From magnus.westerlund@ericsson.com Tue Feb 15 01:06:08 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C1963A6B5B for ; Tue, 15 Feb 2011 01:06:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNOEHPSkMJjV for ; Tue, 15 Feb 2011 01:06:07 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 1A91C3A6E49 for ; Tue, 15 Feb 2011 01:06:06 -0800 (PST) X-AuditID: c1b4fb39-b7cfbae000005c8e-60-4d5a421785f3 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id DA.DE.23694.7124A5D4; Tue, 15 Feb 2011 10:06:31 +0100 (CET) Received: from [147.214.183.8] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.2.234.1; Tue, 15 Feb 2011 10:06:29 +0100 Message-ID: <4D5A4215.3010102@ericsson.com> Date: Tue, 15 Feb 2011 10:06:29 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Belling, Thomas (NSN - DE/Munich)" References: <744A66DF31B5B34EA8B08BBD8187A7220351B576@DEMUEXC014.nsn-intra.net> In-Reply-To: <744A66DF31B5B34EA8B08BBD8187A7220351B576@DEMUEXC014.nsn-intra.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: IETF AVT WG Subject: Re: [AVTCORE] draft-ietf-avtcore-ecn-for-rtp-00.txt: Are ECN summary reports collaborative or unillateral X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 09:06:08 -0000 Belling, Thomas (NSN - DE/Munich) skrev 2011-02-08 15:03: > Dear Magnus, > > RFC 3611 states: > > Each "rtcp-xr" parameter belongs to one of two categories. The first > > category, the unilateral parameters, are for report blocks that > > simply report on the RTP stream and related metrics. The second > > category, collaborative parameters, are for XR blocks that involve > > actions by more than one party in order to carry out their functions > > SDP offer-answer procedures also differ between those categories. > > To which category does the“ecn-sum”report belong? > > I assume unilateral. Is that correct? Yes, the report block is unilateral. > > In any case please add a clarifying statement in the next version ofyour > draft (as I did in my earlier proposal) Will do. Thanks 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 Feb 15 01:07:17 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 585193A6C7E for ; Tue, 15 Feb 2011 01:07:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78opJg9gYYts for ; Tue, 15 Feb 2011 01:07:16 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 48AA83A6B5B for ; Tue, 15 Feb 2011 01:07:16 -0800 (PST) X-AuditID: c1b4fb39-b7cfbae000005c8e-ad-4d5a425c66da Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id EB.1F.23694.C524A5D4; Tue, 15 Feb 2011 10:07:40 +0100 (CET) Received: from [147.214.183.8] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.2.234.1; Tue, 15 Feb 2011 10:07:40 +0100 Message-ID: <4D5A425C.2000503@ericsson.com> Date: Tue, 15 Feb 2011 10:07:40 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Brandenburg, R. (Ray) van" References: <1F2FD678-D0A8-43A2-AB58-85401BD781F4@tno.nl> <5D51ED4A-D95A-4DE6-A87F-A80330B60FE2@csperkins.org> <5BEA1E7A-DAD2-4A3E-B135-441EAA75BC88@magorcorp.com> <4D4A7AFB.6090705@ericsson.com> 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: "avt@ietf.org" , 'Colin Perkins' Subject: Re: [AVTCORE] [AVT] New version of RTCP for IDMS X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 09:07:17 -0000 Brandenburg, R. (Ray) van skrev 2011-02-07 14:45: > Hi Colin/Peter/Magnus and all, > > Thanks for your input. After giving it much thought I now agree that it would be best to define a new packet type for the sender->receiver message. > > I therefore propose the following: > > - The receiver->sender message remains a XR block message as currently defined by the I-D. This would allow it to be compatible with the ETSI TISPAN version, and would prevent unnecessary duplication. > > - The sender->receiver message becomes a new RTCP packet type. > > - We include a section on compatibility with the TISPAN solution indicating that receivers MUST use the XR block for providing the sender with input while senders SHOULD use the new RTCP packet type for sender->receiver but MAY use the TISPAN defined sender->receiver XR block (which will not be defined in the I-D but remain in the ETSI spec). This should include an explanation on that the TISPAN sender->receiver XR block MUST only be used for purposes of compatibility with the TISPAN solution, but MUST NOT be used if all senders and receivers involved support the new RTCP packet type. In this way, backward compatibility is ensured, while not limiting improvements made within IETF. > > - A new SDP parameter is defined for the new sender->receiver RTCP packet type. This would mean that there are two SDP parameters for the server->client message in the IANA registry; one for the ETSI solution and one for the IETF solution. This would also mean: if all elements in the SDP negotiation support the IETF solution, they SHOULD use the new RTCP packet type. > > Would this solution be acceptable to you? Yes, this sounds very reasonable. Thanks 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 Feb 15 01:15:43 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBD523A6B5B for ; Tue, 15 Feb 2011 01:15:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLK-gpbvTs1K for ; Tue, 15 Feb 2011 01:15:43 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id BCA873A6B57 for ; Tue, 15 Feb 2011 01:15:42 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-4e-4d5a4456a24c Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 40.FE.13987.6544A5D4; Tue, 15 Feb 2011 10:16:07 +0100 (CET) Received: from [147.214.183.8] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.2.234.1; Tue, 15 Feb 2011 10:16:06 +0100 Message-ID: <4D5A4456.8070000@ericsson.com> Date: Tue, 15 Feb 2011 10:16:06 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Belling, Thomas (NSN - DE/Munich)" References: <744A66DF31B5B34EA8B08BBD8187A72203597EAD@DEMUEXC014.nsn-intra.net> In-Reply-To: <744A66DF31B5B34EA8B08BBD8187A72203597EAD@DEMUEXC014.nsn-intra.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: IETF AVT WG Subject: Re: [AVTCORE] draft-ietf-avtcore-ecn-for-rtp-00.txt: What to do if "ecn-fb" has not been negotiated via rtcp.fb attribute? X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 09:15:43 -0000 Belling, Thomas (NSN - DE/Munich) skrev 2011-02-11 20:38: > Dear Magnus, > > You omitted one more clarification I suggested for the“rtcp-fb”attribute > negotiation procedures: > > I suggested a recommendationfor the case > that“rtcp-fb”attributenegotiation procedures concludedthat“ecn-fb”is not > allowedto use application specific feedbackwhen ECT marked packets are > received. > > Did you intentionallyomitthis(why?)or was it simply take away > withproposedtextyou considered redundant? > Thomas, I don't understand which case you are discussing. Can you please clarify which part of the avtcore-ecn-for-rtp-00 you are refering to and what your suggested change in relation to this would be? 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 thomas.belling@nsn.com Tue Feb 15 04:50:46 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BC883A6CD7 for ; Tue, 15 Feb 2011 04:50:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAF7Getw+C8F for ; Tue, 15 Feb 2011 04:50:45 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 7AD3D3A6CCE for ; Tue, 15 Feb 2011 04:50:43 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p1FCp15f009075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 15 Feb 2011 13:51:01 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p1FCotmn030467; Tue, 15 Feb 2011 13:51:01 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Feb 2011 13:50:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Feb 2011 13:50:53 +0100 Message-ID: <744A66DF31B5B34EA8B08BBD8187A722035E48E5@DEMUEXC014.nsn-intra.net> In-Reply-To: <4D5A4456.8070000@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-avtcore-ecn-for-rtp-00.txt: What to do if "ecn-fb" has not been negotiated via rtcp.fb attribute? Thread-Index: AcvM8PwxElSEyeobQdecCg3XiDYO7gABKHGA References: <744A66DF31B5B34EA8B08BBD8187A72203597EAD@DEMUEXC014.nsn-intra.net> <4D5A4456.8070000@ericsson.com> From: "Belling, Thomas (NSN - DE/Munich)" To: "ext Magnus Westerlund" X-OriginalArrivalTime: 15 Feb 2011 12:50:55.0090 (UTC) FILETIME=[FBFA1D20:01CBCD0E] Cc: IETF AVT WG Subject: Re: [AVTCORE] draft-ietf-avtcore-ecn-for-rtp-00.txt: What to do if "ecn-fb" has not been negotiated via rtcp.fb attribute? X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 12:50:46 -0000 Dear Magnus, a possible text proposal is below (between >>> <<<): 6.2. RTCP Feedback SDP Parameter A new "nack" feedback parameter "ecn" is defined to indicate the usage of the RTCP ECN feedback packet format (Section 5.1). The ABNF [RFC5234] definition of the SDP parameter extension is: rtcp-fb-nack-param =3D rtcp-fb-nack-param /=3D ecn-fb-par ecn-fb-par =3D SP "ecn" The offer/answer rules for this SDP feedback parameters are specified in AVPF [RFC4585]. >>> If ECN has been negotiated according to clause 6.1, but no "a=3Drtcp-fb" = attribute with value "ecn" is contained in the answer, an RTP receiver = that receives a packet with an ECN-CE mark SHOULD use application = specific feedback. <<< Thomas -----Original Message----- From: ext Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 Sent: Tuesday, February 15, 2011 10:16 AM To: Belling, Thomas (NSN - DE/Munich) Cc: IETF AVT WG Subject: Re: draft-ietf-avtcore-ecn-for-rtp-00.txt: What to do if = "ecn-fb" has not been negotiated via rtcp.fb attribute? Belling, Thomas (NSN - DE/Munich) skrev 2011-02-11 20:38: > Dear Magnus, >=20 > You omitted one more clarification I suggested for=20 > the"rtcp-fb"attribute negotiation procedures: >=20 > I suggested a recommendationfor the case=20 > that"rtcp-fb"attributenegotiation procedures concludedthat"ecn-fb"is=20 > not allowedto use application specific feedbackwhen ECT marked packets = > are received. >=20 > Did you intentionallyomitthis(why?)or was it simply take away=20 > withproposedtextyou considered redundant? >=20 Thomas, I don't understand which case you are discussing. Can you please clarify = which part of the avtcore-ecn-for-rtp-00 you are refering to and what = your suggested change in relation to this would be? 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 ---------------------------------------------------------------------- From carlberg@g11.org.uk Tue Feb 15 05:27:13 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 104993A6CBD for ; Tue, 15 Feb 2011 05:27:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5CCwe27LOXKZ for ; Tue, 15 Feb 2011 05:27:12 -0800 (PST) Received: from portland.eukhosting.net (portland.eukhosting.net [92.48.97.5]) by core3.amsl.com (Postfix) with ESMTP id 3FAC73A6956 for ; Tue, 15 Feb 2011 05:27:11 -0800 (PST) Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:52043 helo=[192.168.0.20]) by portland.eukhosting.net with esmtpa (Exim 4.69) (envelope-from ) id 1PpKwA-0004E6-8d; Tue, 15 Feb 2011 13:27:26 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: ken carlberg In-Reply-To: <744A66DF31B5B34EA8B08BBD8187A722035E48E5@DEMUEXC014.nsn-intra.net> Date: Tue, 15 Feb 2011 08:27:32 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <92AF6A87-D0C7-4F74-B9EF-C61B66BC9854@g11.org.uk> References: <744A66DF31B5B34EA8B08BBD8187A72203597EAD@DEMUEXC014.nsn-intra.net> <4D5A4456.8070000@ericsson.com> <744A66DF31B5B34EA8B08BBD8187A722035E48E5@DEMUEXC014.nsn-intra.net> To: "Belling, Thomas (NSN - DE/Munich)" X-Mailer: Apple Mail (2.1082) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk X-Source: X-Source-Args: X-Source-Dir: Cc: ext Magnus Westerlund , IETF AVT WG Subject: Re: [AVTCORE] draft-ietf-avtcore-ecn-for-rtp-00.txt: What to do if "ecn-fb" has not been negotiated via rtcp.fb attribute? X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 13:27:13 -0000 Thomas, > a possible text proposal is below (between >>> <<<): >=20 > 6.2. RTCP Feedback SDP Parameter >=20 > A new "nack" feedback parameter "ecn" is defined to indicate the > usage of the RTCP ECN feedback packet format (Section 5.1). The = ABNF > [RFC5234] definition of the SDP parameter extension is: >=20 > rtcp-fb-nack-param =3D > rtcp-fb-nack-param /=3D ecn-fb-par > ecn-fb-par =3D SP "ecn" >=20 > The offer/answer rules for this SDP feedback parameters are = specified > in AVPF [RFC4585]. >>>>=20 > If ECN has been negotiated according to clause 6.1, but no "a=3Drtcp-fb"= attribute with value "ecn" is contained in the answer, an RTP receiver = that receives a packet with an ECN-CE mark SHOULD use application = specific feedback. > <<< the above seems incomplete, and still a little complex because of what = appears to be several variations of attributes. what are you suggesting = are the courses of action if "ecn" (as you describe above) *is* = contained in the answer? -ken= From thomas.belling@nsn.com Tue Feb 15 05:37:07 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBFB23A6D28 for ; Tue, 15 Feb 2011 05:37:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWi4R59BMx85 for ; Tue, 15 Feb 2011 05:37:07 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id AD04B3A6D0A for ; Tue, 15 Feb 2011 05:37:06 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p1FDbNGC021511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 15 Feb 2011 14:37:23 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p1FDbJPQ026841; Tue, 15 Feb 2011 14:37:22 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Feb 2011 14:37:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Feb 2011 14:37:18 +0100 Message-ID: <744A66DF31B5B34EA8B08BBD8187A722035E499F@DEMUEXC014.nsn-intra.net> In-Reply-To: <92AF6A87-D0C7-4F74-B9EF-C61B66BC9854@g11.org.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVTCORE] draft-ietf-avtcore-ecn-for-rtp-00.txt: What to do if "ecn-fb" has not been negotiated via rtcp.fb attribute? Thread-Index: AcvNFB9XHnao9cjzTSuXsdawGCTINwAAB/Qw References: <744A66DF31B5B34EA8B08BBD8187A72203597EAD@DEMUEXC014.nsn-intra.net> <4D5A4456.8070000@ericsson.com> <744A66DF31B5B34EA8B08BBD8187A722035E48E5@DEMUEXC014.nsn-intra.net> <92AF6A87-D0C7-4F74-B9EF-C61B66BC9854@g11.org.uk> From: "Belling, Thomas (NSN - DE/Munich)" To: "ext ken carlberg" X-OriginalArrivalTime: 15 Feb 2011 13:37:19.0840 (UTC) FILETIME=[77D13E00:01CBCD15] Cc: ext Magnus Westerlund , IETF AVT WG Subject: Re: [AVTCORE] draft-ietf-avtcore-ecn-for-rtp-00.txt: What to do if "ecn-fb" has not been negotiated via rtcp.fb attribute? X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 13:37:08 -0000 Dear Ken, I made a proposal having more wording on the negotiation procedure earlier, but Magnus had concerns that much is redundant compared to RFC 4585 procedures. Those indeed cover this case and say that ECN-FB may then be used. Also, in other places in the draft there is more wording on using ECN FB already. I believe that the text I propose goes a bit beyond RFC 4585, because while it is clear that other application specific feedback can be used if negotiated, it is unclear that it should be used in response to ECT-marked packages. Further, not all application specific feedback is negotiated using RFC 4585. Thomas -----Original Message----- From: ext ken carlberg [mailto:carlberg@g11.org.uk]=20 Sent: Tuesday, February 15, 2011 2:28 PM To: Belling, Thomas (NSN - DE/Munich) Cc: ext Magnus Westerlund; IETF AVT WG Subject: Re: [AVTCORE] draft-ietf-avtcore-ecn-for-rtp-00.txt: What to do if "ecn-fb" has not been negotiated via rtcp.fb attribute? Thomas, > a possible text proposal is below (between >>> <<<): >=20 > 6.2. RTCP Feedback SDP Parameter >=20 > A new "nack" feedback parameter "ecn" is defined to indicate the > usage of the RTCP ECN feedback packet format (Section 5.1). The ABNF > [RFC5234] definition of the SDP parameter extension is: >=20 > rtcp-fb-nack-param =3D > rtcp-fb-nack-param /=3D ecn-fb-par > ecn-fb-par =3D SP "ecn" >=20 > The offer/answer rules for this SDP feedback parameters are specified > in AVPF [RFC4585]. >>>>=20 > If ECN has been negotiated according to clause 6.1, but no = "a=3Drtcp-fb" attribute with value "ecn" is contained in the answer, an RTP receiver that receives a packet with an ECN-CE mark SHOULD use application specific feedback. > <<< the above seems incomplete, and still a little complex because of what appears to be several variations of attributes. what are you suggesting are the courses of action if "ecn" (as you describe above) *is* contained in the answer? -ken From Even.roni@huawei.com Tue Feb 15 12:50:35 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8D993A6D71 for ; Tue, 15 Feb 2011 12:50:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.494 X-Spam-Level: X-Spam-Status: No, score=-104.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yYWKaMg7GfA for ; Tue, 15 Feb 2011 12:50:32 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id BF06D3A6DCF for ; Tue, 15 Feb 2011 12:50:31 -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 <0LGO00D5CF8N7M@szxga04-in.huawei.com> for avt@ietf.org; Wed, 16 Feb 2011 04:50:47 +0800 (CST) Received: from 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 <0LGO003I2F8NMT@szxga04-in.huawei.com> for avt@ietf.org; Wed, 16 Feb 2011 04:50:47 +0800 (CST) Received: from windows8d787f9 (bzq-79-178-9-34.red.bezeqint.net [79.178.9.34]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LGO004R9F8E1V@szxml12-in.huawei.com> for avt@ietf.org; Wed, 16 Feb 2011 04:50:47 +0800 (CST) Date: Tue, 15 Feb 2011 22:46:07 +0200 From: Roni Even To: 'IETF AVTCore WG' Message-id: <036a01cbcd51$649ee0d0$2ddca270$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_P66+T3SRvcFzB8/xMsQ6WQ)" Content-language: en-us Thread-index: AcvNUVxzSUTYwOoaTq+THjS9VhM77g== Subject: [AVTCORE] comments on draft-ietf-avtcore-ecn-for-rtp-00 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 20:50:36 -0000 This is a multi-part message in MIME format. --Boundary_(ID_P66+T3SRvcFzB8/xMsQ6WQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, 1. In section 6.1 there are these two sentences: "If the participant lack the functionality they SHALL refuse the media streams using multicast." and " Participants MUST NOT join such a session unless they have the capability to receive ECN-marked UDP packets," I am not sure how that works for participants who do not understand the ecn-capable-rtp attribute. I think that they will ignore the attribute and join the session and will not use ECN. 2. In section 6.1 "Thus, the use of the Extended RTP Profile for RTCP-Based Feedback(RTP/AVPF) [RFC4585] or other profile that inherits AVPF's signalling rules, MUST be signalled unless timely feedback is not required in case it is RECOMMENDED to be used. " I am not sire what is meant by the last part of the sentence "in case .". 3. In the example is section 12.1 with ICE I did not see "a=ice-options: rtp+ecn" in the offer, is this required? 4. Some typos in 6.1 " unless all senders are required to attempt to use ECN for there outgoing sessions" should be "their" and in 7.4 "ECT marked packets unless their is duplication in the network" should be "there" Roni Even _____ --Boundary_(ID_P66+T3SRvcFzB8/xMsQ6WQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

1.       In section 6.1 there are these two sentences: "If the participant lack the functionality they SHALL refuse the media streams using multicast." and " Participants MUST NOT join such a session unless they have the capability to receive ECN-marked UDP packets," I am not sure h ow that o do not understand the ecn-capable-rtp attribute. I think that they will ignore the attribute and join the session and will not use ECN.

2.       In section 6.1 "Thus, the use of the Extended RTP Profile for RTCP-Based Feedback(RTP/AVPF) [RFC4585] or other profile that inherits AVPF's signalling rules, MUST be signalled unless timely feedback is not required in case it is RECOMMENDED to be used. " I am not sir e what i of the sentence "in case …".

3.       In the example is section 12.1 with ICE I did not see "a=ice-options: rtp+ecn" in the offer, is this required?

4. nbsp;  Some typos in 6.1 " unless all senders are required to attempt to  use ECN for there outgoing sessions" should be "their" and in 7.4 "ECT marked packets unless their is duplication in the network" should be  "there"

 

 

 

Roni Even

 

 

 

 

 

 

 

--Boundary_(ID_P66+T3SRvcFzB8/xMsQ6WQ)-- From magnus.westerlund@ericsson.com Fri Feb 18 01:17:31 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A63963A6F00 for ; Fri, 18 Feb 2011 01:17:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.239 X-Spam-Level: X-Spam-Status: No, score=-106.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jg2O4P-6Bh84 for ; Fri, 18 Feb 2011 01:17:30 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 5A0D93A6E0C for ; Fri, 18 Feb 2011 01:17:30 -0800 (PST) X-AuditID: c1b4fb3d-b7c78ae000005844-8b-4d5e394aa9cc Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 8C.DA.22596.A493E5D4; Fri, 18 Feb 2011 10:18:03 +0100 (CET) Received: from [147.214.183.8] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.2.234.1; Fri, 18 Feb 2011 10:18:01 +0100 Message-ID: <4D5E3949.30804@ericsson.com> Date: Fri, 18 Feb 2011 10:18:01 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Belling, Thomas (NSN - DE/Munich)" References: <744A66DF31B5B34EA8B08BBD8187A72203597EAD@DEMUEXC014.nsn-intra.net> <4D5A4456.8070000@ericsson.com> <744A66DF31B5B34EA8B08BBD8187A722035E48E5@DEMUEXC014.nsn-intra.net> <92AF6A87-D0C7-4F74-B9EF-C61B66BC9854@g11.org.uk> <744A66DF31B5B34EA8B08BBD8187A722035E499F@DEMUEXC014.nsn-intra.net> In-Reply-To: <744A66DF31B5B34EA8B08BBD8187A722035E499F@DEMUEXC014.nsn-intra.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: IETF AVT WG Subject: Re: [AVTCORE] draft-ietf-avtcore-ecn-for-rtp-00.txt: What to do if "ecn-fb" has not been negotiated via rtcp.fb attribute? X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 09:17:31 -0000 Hi Thomas, The semantics of what your propose doesn't make sense. The "rtcp-fb" parameter is intended to signal feedback parameters that are intended or requested to be used. What you are proposing is to use this SDP parameter to indicate that you are not using an RTCP FB format but something else. The logical choice here is to use positive explicit signaling of the alternative feedback that one uses and not indicate the ECN FB format. cheers Magnus Belling, Thomas (NSN - DE/Munich) skrev 2011-02-15 14:37: > Dear Ken, > > I made a proposal having more wording on the negotiation procedure > earlier, but Magnus had concerns that much is redundant compared to RFC > 4585 procedures. Those indeed cover this case and say that ECN-FB may > then be used. > Also, in other places in the draft there is more wording on using ECN FB > already. > > I believe that the text I propose goes a bit beyond RFC 4585, because > while it is clear that other application specific feedback can be used > if negotiated, it is unclear that it should be used in response to > ECT-marked packages. Further, not all application specific feedback is > negotiated using RFC 4585. > > Thomas > > -----Original Message----- > From: ext ken carlberg [mailto:carlberg@g11.org.uk] > Sent: Tuesday, February 15, 2011 2:28 PM > To: Belling, Thomas (NSN - DE/Munich) > Cc: ext Magnus Westerlund; IETF AVT WG > Subject: Re: [AVTCORE] draft-ietf-avtcore-ecn-for-rtp-00.txt: What to do > if "ecn-fb" has not been negotiated via rtcp.fb attribute? > > Thomas, > >> a possible text proposal is below (between >>> <<<): >> >> 6.2. RTCP Feedback SDP Parameter >> >> A new "nack" feedback parameter "ecn" is defined to indicate the >> usage of the RTCP ECN feedback packet format (Section 5.1). The > ABNF >> [RFC5234] definition of the SDP parameter extension is: >> >> rtcp-fb-nack-param = >> rtcp-fb-nack-param /= ecn-fb-par >> ecn-fb-par = SP "ecn" >> >> The offer/answer rules for this SDP feedback parameters are > specified >> in AVPF [RFC4585]. >>>>> >> If ECN has been negotiated according to clause 6.1, but no "a=rtcp-fb" > attribute with value "ecn" is contained in the answer, an RTP receiver > that receives a packet with an ECN-CE mark SHOULD use application > specific feedback. >> <<< > > the above seems incomplete, and still a little complex because of what > appears to be several variations of attributes. what are you suggesting > are the courses of action if "ecn" (as you describe above) *is* > contained in the answer? > > -ken > -- 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 thomas.belling@nsn.com Fri Feb 18 01:29:36 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19A723A6EB2 for ; Fri, 18 Feb 2011 01:29:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.074 X-Spam-Level: X-Spam-Status: No, score=-6.074 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiwE-fhzl4Pq for ; Fri, 18 Feb 2011 01:29:32 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 43DAF3A6E81 for ; Fri, 18 Feb 2011 01:29:32 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p1I9TwOK010017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 18 Feb 2011 10:29:58 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p1I9TsDu006390; Fri, 18 Feb 2011 10:29:58 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.111]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 18 Feb 2011 10:29:56 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 18 Feb 2011 10:29:55 +0100 Message-ID: <744A66DF31B5B34EA8B08BBD8187A72203664A86@DEMUEXC014.nsn-intra.net> In-Reply-To: <4D5E3949.30804@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVTCORE] draft-ietf-avtcore-ecn-for-rtp-00.txt: What to do if "ecn-fb" has not been negotiated via rtcp.fb attribute? Thread-Index: AcvPTMGCLKCiFZ+cTeallsf3QiFcrQAAGArQ References: <744A66DF31B5B34EA8B08BBD8187A72203597EAD@DEMUEXC014.nsn-intra.net> <4D5A4456.8070000@ericsson.com> <744A66DF31B5B34EA8B08BBD8187A722035E48E5@DEMUEXC014.nsn-intra.net> <92AF6A87-D0C7-4F74-B9EF-C61B66BC9854@g11.org.uk> <744A66DF31B5B34EA8B08BBD8187A722035E499F@DEMUEXC014.nsn-intra.net> <4D5E3949.30804@ericsson.com> From: "Belling, Thomas (NSN - DE/Munich)" To: "ext Magnus Westerlund" X-OriginalArrivalTime: 18 Feb 2011 09:29:56.0810 (UTC) FILETIME=[67EBDAA0:01CBCF4E] Cc: IETF AVT WG Subject: Re: [AVTCORE] draft-ietf-avtcore-ecn-for-rtp-00.txt: What to do if "ecn-fb" has not been negotiated via rtcp.fb attribute? X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 09:29:36 -0000 Hi Magnus, suppose that support of TMMBR is indicated in the "rtcp-fb" attribute = (in a positive way, as you suggest), but support is "ECN FB" is not = indicated. It is then clear from rtcp-fb negotiation rules that TMMBR can be used, = but no ECN FB. What is unclear is a host supporting ECN would use TMMBR when receiving = ECT-marked packets. I intended to recommend that with the proposed wording. And I believe = such a recommendation could be in scope of the ECN draft (not being = explicit about TMMBR, but speaking about application specific feedback = in general. Thomas -----Original Message----- From: ext Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 Sent: Friday, February 18, 2011 10:18 AM To: Belling, Thomas (NSN - DE/Munich) Cc: ext ken carlberg; IETF AVT WG Subject: Re: [AVTCORE] draft-ietf-avtcore-ecn-for-rtp-00.txt: What to do = if "ecn-fb" has not been negotiated via rtcp.fb attribute? Hi Thomas, The semantics of what your propose doesn't make sense. The "rtcp-fb" parameter is intended to signal feedback parameters that are intended or = requested to be used. What you are proposing is to use this SDP = parameter to indicate that you are not using an RTCP FB format but = something else. The logical choice here is to use positive explicit = signaling of the alternative feedback that one uses and not indicate the = ECN FB format. cheers Magnus Belling, Thomas (NSN - DE/Munich) skrev 2011-02-15 14:37: > Dear Ken, >=20 > I made a proposal having more wording on the negotiation procedure=20 > earlier, but Magnus had concerns that much is redundant compared to=20 > RFC > 4585 procedures. Those indeed cover this case and say that ECN-FB may=20 > then be used. > Also, in other places in the draft there is more wording on using ECN=20 > FB already. >=20 > I believe that the text I propose goes a bit beyond RFC 4585, because=20 > while it is clear that other application specific feedback can be used = > if negotiated, it is unclear that it should be used in response to=20 > ECT-marked packages. Further, not all application specific feedback is = > negotiated using RFC 4585. >=20 > Thomas >=20 > -----Original Message----- > From: ext ken carlberg [mailto:carlberg@g11.org.uk] > Sent: Tuesday, February 15, 2011 2:28 PM > To: Belling, Thomas (NSN - DE/Munich) > Cc: ext Magnus Westerlund; IETF AVT WG > Subject: Re: [AVTCORE] draft-ietf-avtcore-ecn-for-rtp-00.txt: What to=20 > do if "ecn-fb" has not been negotiated via rtcp.fb attribute? >=20 > Thomas, >=20 >> a possible text proposal is below (between >>> <<<): >> >> 6.2. RTCP Feedback SDP Parameter >> >> A new "nack" feedback parameter "ecn" is defined to indicate the >> usage of the RTCP ECN feedback packet format (Section 5.1). The > ABNF >> [RFC5234] definition of the SDP parameter extension is: >> >> rtcp-fb-nack-param =3D >> rtcp-fb-nack-param /=3D ecn-fb-par >> ecn-fb-par =3D SP "ecn" >> >> The offer/answer rules for this SDP feedback parameters are > specified >> in AVPF [RFC4585]. >>>>> >> If ECN has been negotiated according to clause 6.1, but no = "a=3Drtcp-fb" > attribute with value "ecn" is contained in the answer, an RTP receiver = > that receives a packet with an ECN-CE mark SHOULD use application=20 > specific feedback. >> <<< >=20 > the above seems incomplete, and still a little complex because of what = > appears to be several variations of attributes. what are you=20 > suggesting are the courses of action if "ecn" (as you describe above)=20 > *is* contained in the answer? >=20 > -ken >=20 --=20 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 ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Fri Feb 18 01:30:33 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E18233A6D48 for ; Fri, 18 Feb 2011 01:30:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.199 X-Spam-Level: X-Spam-Status: No, score=-106.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XhvixpOhZdS3 for ; Fri, 18 Feb 2011 01:30:32 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id BC2AB3A6EB2 for ; Fri, 18 Feb 2011 01:30:31 -0800 (PST) X-AuditID: c1b4fb39-b7b76ae00000276e-18-4d5e3c5800d3 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 91.6C.10094.85C3E5D4; Fri, 18 Feb 2011 10:31:04 +0100 (CET) Received: from [147.214.183.8] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.2.234.1; Fri, 18 Feb 2011 10:30:56 +0100 Message-ID: <4D5E3C50.8060508@ericsson.com> Date: Fri, 18 Feb 2011 10:30:56 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Roni Even References: <036a01cbcd51$649ee0d0$2ddca270$%roni@huawei.com> In-Reply-To: <036a01cbcd51$649ee0d0$2ddca270$%roni@huawei.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: 'IETF AVTCore WG' Subject: Re: [AVTCORE] comments on draft-ietf-avtcore-ecn-for-rtp-00 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 09:30:34 -0000 Thanks, for the review Roni. Roni Even skrev 2011-02-15 21:46: > Hi, > > 1. In section 6.1 there are these two sentences: "If the > participant lack the functionality they SHALL refuse the media streams > using multicast." and " Participants MUST NOT join such a session unless > they have the capability to receive ECN-marked UDP packets," I am not > sure h ow that o do not understand the ecn-capable-rtp attribute. I > think that they will ignore the attribute and join the session and will > not use ECN. Lets look at each statement separtely: If an RTP session using multicast is negotiated using offer/answer all participants intending to send RTP packets SHALL support setting of ECN packet, and all participants receiving SHALL have the capability to read ECN values on incoming packets. If the participant lack the functionality they SHALL refuse the media streams using multicast. This clearly can be improved. But as it is offer/answer we should make it clear that the other part in a session requiring multicast and ECN shall ensure that the joining participant is capable. Thus using SIP methods for terminating the dialog and the other participants attempt to take part in the session. Does this make more sense? When SDP is used in a declarative manner, for example in a multicast session using the Session Announcement Protocol (SAP, [RFC2974]), negotiation of session description parameters is not possible. The "a=ecn-capable-rtp" attribute MAY be added to the session description to indicate that the sender will use ECN in the RTP session. The attribute MUST include a single method of initiation. Participants MUST NOT join such a session unless they have the capability to receive ECN-marked UDP packets, implement the method of initiation, and can generate RTCP ECN feedback (note that having the capability to use ECN doesn't necessarily imply that the underlying network path between sender and receiver supports ECN). The mode parameter MAY be included also in declarative usage, to indicate the minimal capability is required by the consumer of the SDP. So for example in a SSM session the participants configured with a particular SDP will all be in a media receive only mode, thus mode=readonly will work as the capability of reporting on the ECN markings in the received is what is required. However, using "mode=readonly" also in ASM sessions is reasonable, unless all senders are required to attempt to use ECN for there outgoing sessions, in which case the mode needs to be set to "setread". So this is declartive and multicast. I agree that it is a difficult case to ensure that no implementations doesn't join. However, for declarative multicast sessions, you frankly need to understand the session you are joining in. I know that our specs could be clearer on this, but if you join a multicast session and don't understand all the parameters you will be in trouble. Thus, it is possible that some applications implement detection of attributes, but not the corresponding functionalities simply to ensure that they do not join the session unnecessary. Thus, I think the statement is necessary, but I agree not 100% ensuring that this will not happen. I can clarify this. > > 2. In section 6.1 "Thus, the use of the Extended RTP Profile for > RTCP-Based Feedback(RTP/AVPF) [RFC4585] or other profile that inherits > AVPF's signalling rules, MUST be signalled unless timely feedback is not > required in case it is RECOMMENDED to be used." I am not sir e what i of > the sentence "in case …". This sentence should be broken into two. IT tries to say even if not stricitly required, is is still recommended to use AVPF. Will reformulate. > > 3. In the example is section 12.1 with ICE I did not see > "a=ice-options: rtp+ecn" in the offer, is this required? That should be included, forgotten in the example. It should be incldued, but is in fact not strictly needed due to the ICE based initiation method negotation in the ecn-capable-rtp SDP attribute. > > 4.nbsp; Some typos in 6.1 " unless all senders are required to attempt > to use ECN for there outgoing sessions" should be "their" and in 7.4 > "ECT marked packets unless their is duplication in the network" should > be "there" Thanks, will fix. 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 Even.roni@huawei.com Fri Feb 18 05:01:59 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12CA33A6F58 for ; Fri, 18 Feb 2011 05:01:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.95 X-Spam-Level: X-Spam-Status: No, score=-101.95 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FRT_OFFER2=2.545, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CK10O7SoaChj for ; Fri, 18 Feb 2011 05:01:58 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 31D3C3A6EF8 for ; Fri, 18 Feb 2011 05:01:58 -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 <0LGT000Z6DILH6@szxga04-in.huawei.com> for avt@ietf.org; Fri, 18 Feb 2011 21:01:33 +0800 (CST) Received: from 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 <0LGT00CY6DILF7@szxga04-in.huawei.com> for avt@ietf.org; Fri, 18 Feb 2011 21:01:33 +0800 (CST) Received: from windows8d787f9 ([109.64.1.114]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LGT00KYIDHZDT@szxml12-in.huawei.com>; Fri, 18 Feb 2011 21:01:33 +0800 (CST) Date: Fri, 18 Feb 2011 14:56:35 +0200 From: Roni Even In-reply-to: <4D5E3C50.8060508@ericsson.com> To: 'Magnus Westerlund' Message-id: <002a01cbcf6b$53dcca20$fb965e60$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcvPTp0Vk5q0BO3GRAGUPdVZPTrMAQAHAswQ References: <036a01cbcd51$649ee0d0$2ddca270$%roni@huawei.com> <4D5E3C50.8060508@ericsson.com> Cc: 'IETF AVTCore WG' Subject: Re: [AVTCORE] comments on draft-ietf-avtcore-ecn-for-rtp-00 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 13:01:59 -0000 Hi Magnus, Inline > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Friday, February 18, 2011 11:31 AM > To: Roni Even > Cc: 'IETF AVTCore WG' > Subject: Re: [AVTCORE] comments on draft-ietf-avtcore-ecn-for-rtp-00 > > Thanks, for the review Roni. > > Roni Even skrev 2011-02-15 21:46: > > Hi, > > > > 1. In section 6.1 there are these two sentences: "If the > > participant lack the functionality they SHALL refuse the media > streams > > using multicast." and " Participants MUST NOT join such a session > unless > > they have the capability to receive ECN-marked UDP packets," I am not > > sure h ow that o do not understand the ecn-capable-rtp attribute. I > > think that they will ignore the attribute and join the session and > will > > not use ECN. > > Lets look at each statement separtely: > > If an RTP session using multicast is negotiated using offer/answer > all participants intending to send RTP packets SHALL support setting > of ECN packet, and all participants receiving SHALL have the > capability to read ECN values on incoming packets. If the > participant lack the functionality they SHALL refuse the media > streams using multicast. > > This clearly can be improved. But as it is offer/answer we should make > it clear that the other part in a session requiring multicast and ECN > shall ensure that the joining participant is capable. Thus using SIP > methods for terminating the dialog and the other participants attempt > to > take part in the session. Does this make more sense? My concern in offer answer is that a legacy system that will receive an offer with ecn attribute may accept the stream and remove the attribute in the answer without violating offer/answer. I think that it will be up to the offrer to terminate the session when noticing the lack of the ecn attribute in the answer. Regards Roni Even From carlberg@g11.org.uk Sun Feb 20 04:58:34 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F0B33A6F5F for ; Sun, 20 Feb 2011 04:58:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQ3dKKvDBJ+D for ; Sun, 20 Feb 2011 04:58:33 -0800 (PST) Received: from portland.eukhosting.net (portland.eukhosting.net [92.48.97.5]) by core3.amsl.com (Postfix) with ESMTP id E6D613A6F32 for ; Sun, 20 Feb 2011 04:58:32 -0800 (PST) Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:51098 helo=[192.168.0.20]) by portland.eukhosting.net with esmtpa (Exim 4.69) (envelope-from ) id 1Pr8sO-0002qE-Vc; Sun, 20 Feb 2011 12:59:01 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: ken carlberg In-Reply-To: <744A66DF31B5B34EA8B08BBD8187A72203664A86@DEMUEXC014.nsn-intra.net> Date: Sun, 20 Feb 2011 07:58:57 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <744A66DF31B5B34EA8B08BBD8187A72203597EAD@DEMUEXC014.nsn-intra.net> <4D5A4456.8070000@ericsson.com> <744A66DF31B5B34EA8B08BBD8187A722035E48E5@DEMUEXC014.nsn-intra.net> <92AF6A87-D0C7-4F74-B9EF-C61B66BC9854@g11.org.uk> <744A66DF31B5B34EA8B08BBD8187A722035E499F@DEMUEXC014.nsn-intra.net> <4D5E3949.30804@ericsson.com> <744A66DF31B5B34EA8B08BBD8187A72203664A86@DEMUEXC014.nsn-intra.net> To: "Belling, Thomas (NSN - DE/Munich)" X-Mailer: Apple Mail (2.1082) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk X-Source: X-Source-Args: X-Source-Dir: Cc: ext Magnus Westerlund , IETF AVT WG Subject: Re: [AVTCORE] draft-ietf-avtcore-ecn-for-rtp-00.txt: What to do if "ecn-fb" has not been negotiated via rtcp.fb attribute? X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2011 12:58:34 -0000 Thomas, the objective of the draft is to negotiate support of ECN, and then to = convey the presence/reception of CE marked IP packets quickly to the = source. and the fundamental aspect of the latter is that there is a = consistency in the response. hence, if the draft becomes an RFC, then = those that claim conformance know exactly what to expect and when to = expect it in terms of a response to upstream congestion. The more open ended approach that you are advocating of either ECN = reports or some other application-specific feedback does away with that = consistency. Magnus raised the point that such an approach leads to = non-interoperability. In the unicast, its probably not an issue, but = its not clear to me how you reconcile the multicast case. Outside of = that, its the uniformity of the response that is my bigger concern. = With application-specific responses, you cannot guarantee that the = feedback of CE marked packets will exhibit the same characteristics or = information. An analogy would be like having different rules for TCP = Tahoe and Reno in conveying CE back to the sender (e.g., one sends back = ECN-echo in the first Ack, the other sets a different flag and sends it = on the N'th Ack, or on the next upstream data packet). If its that critical for you to have a more open-ended application = specific approach in providing feedback to CE marked IP packets, then I = think it would be better to produce a separate draft articulating this = design. cheers, -ken On Feb 18, 2011, at 4:29 AM, Belling, Thomas (NSN - DE/Munich) wrote: > Hi Magnus, >=20 > suppose that support of TMMBR is indicated in the "rtcp-fb" attribute = (in a positive way, as you suggest), but support is "ECN FB" is not = indicated. >=20 > It is then clear from rtcp-fb negotiation rules that TMMBR can be = used, but no ECN FB. >=20 > What is unclear is a host supporting ECN would use TMMBR when = receiving ECT-marked packets. >=20 > I intended to recommend that with the proposed wording. And I believe = such a recommendation could be in scope of the ECN draft (not being = explicit about TMMBR, but speaking about application specific feedback = in general. >=20 > Thomas >=20 >=20 > -----Original Message----- > From: ext Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 > Sent: Friday, February 18, 2011 10:18 AM > To: Belling, Thomas (NSN - DE/Munich) > Cc: ext ken carlberg; IETF AVT WG > Subject: Re: [AVTCORE] draft-ietf-avtcore-ecn-for-rtp-00.txt: What to = do if "ecn-fb" has not been negotiated via rtcp.fb attribute? >=20 > Hi Thomas, >=20 > The semantics of what your propose doesn't make sense. The "rtcp-fb" > parameter is intended to signal feedback parameters that are intended = or requested to be used. What you are proposing is to use this SDP = parameter to indicate that you are not using an RTCP FB format but = something else. The logical choice here is to use positive explicit = signaling of the alternative feedback that one uses and not indicate the = ECN FB format. >=20 > cheers >=20 > Magnus >=20 > Belling, Thomas (NSN - DE/Munich) skrev 2011-02-15 14:37: >> Dear Ken, >>=20 >> I made a proposal having more wording on the negotiation procedure=20 >> earlier, but Magnus had concerns that much is redundant compared to=20= >> RFC >> 4585 procedures. Those indeed cover this case and say that ECN-FB may=20= >> then be used. >> Also, in other places in the draft there is more wording on using ECN=20= >> FB already. >>=20 >> I believe that the text I propose goes a bit beyond RFC 4585, because=20= >> while it is clear that other application specific feedback can be = used=20 >> if negotiated, it is unclear that it should be used in response to=20 >> ECT-marked packages. Further, not all application specific feedback = is=20 >> negotiated using RFC 4585. >>=20 >> Thomas >>=20 >> -----Original Message----- >> From: ext ken carlberg [mailto:carlberg@g11.org.uk] >> Sent: Tuesday, February 15, 2011 2:28 PM >> To: Belling, Thomas (NSN - DE/Munich) >> Cc: ext Magnus Westerlund; IETF AVT WG >> Subject: Re: [AVTCORE] draft-ietf-avtcore-ecn-for-rtp-00.txt: What to=20= >> do if "ecn-fb" has not been negotiated via rtcp.fb attribute? >>=20 >> Thomas, >>=20 >>> a possible text proposal is below (between >>> <<<): >>>=20 >>> 6.2. RTCP Feedback SDP Parameter >>>=20 >>> A new "nack" feedback parameter "ecn" is defined to indicate the >>> usage of the RTCP ECN feedback packet format (Section 5.1). The >> ABNF >>> [RFC5234] definition of the SDP parameter extension is: >>>=20 >>> rtcp-fb-nack-param =3D >>> rtcp-fb-nack-param /=3D ecn-fb-par >>> ecn-fb-par =3D SP "ecn" >>>=20 >>> The offer/answer rules for this SDP feedback parameters are >> specified >>> in AVPF [RFC4585]. >>>>>>=20 >>> If ECN has been negotiated according to clause 6.1, but no = "a=3Drtcp-fb" >> attribute with value "ecn" is contained in the answer, an RTP = receiver=20 >> that receives a packet with an ECN-CE mark SHOULD use application=20 >> specific feedback. >>> <<< >>=20 >> the above seems incomplete, and still a little complex because of = what=20 >> appears to be several variations of attributes. what are you=20 >> suggesting are the courses of action if "ecn" (as you describe above)=20= >> *is* contained in the answer? >>=20 >> -ken >>=20 >=20 >=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 > ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Mon Feb 21 02:28:34 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FECB3A6E99 for ; Mon, 21 Feb 2011 02:28:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.198 X-Spam-Level: X-Spam-Status: No, score=-105.198 tagged_above=-999 required=5 tests=[AWL=-1.144, BAYES_00=-2.599, FRT_OFFER2=2.545, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQgFkk0xTY66 for ; Mon, 21 Feb 2011 02:28:33 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 3AECA3A6E93 for ; Mon, 21 Feb 2011 02:28:32 -0800 (PST) X-AuditID: c1b4fb3d-b7c78ae000005844-97-4d623e792298 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 06.86.22596.97E326D4; Mon, 21 Feb 2011 11:29:13 +0100 (CET) Received: from [147.214.183.8] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.2.234.1; Mon, 21 Feb 2011 11:29:12 +0100 Message-ID: <4D623E79.1000504@ericsson.com> Date: Mon, 21 Feb 2011 11:29:13 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Roni Even References: <036a01cbcd51$649ee0d0$2ddca270$%roni@huawei.com> <4D5E3C50.8060508@ericsson.com> <002a01cbcf6b$53dcca20$fb965e60$%roni@huawei.com> In-Reply-To: <002a01cbcf6b$53dcca20$fb965e60$%roni@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: 'IETF AVTCore WG' Subject: Re: [AVTCORE] comments on draft-ietf-avtcore-ecn-for-rtp-00 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 10:28:34 -0000 Roni Even skrev 2011-02-18 13:56: > Hi Magnus, > > Inline > >> -----Original Message----- >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >> Sent: Friday, February 18, 2011 11:31 AM >> To: Roni Even >> Cc: 'IETF AVTCore WG' >> Subject: Re: [AVTCORE] comments on draft-ietf-avtcore-ecn-for-rtp-00 >> >> Thanks, for the review Roni. >> >> Roni Even skrev 2011-02-15 21:46: >>> Hi, >>> >>> 1. In section 6.1 there are these two sentences: "If the >>> participant lack the functionality they SHALL refuse the media >> streams >>> using multicast." and " Participants MUST NOT join such a session >> unless >>> they have the capability to receive ECN-marked UDP packets," I am not >>> sure h ow that o do not understand the ecn-capable-rtp attribute. I >>> think that they will ignore the attribute and join the session and >> will >>> not use ECN. >> >> Lets look at each statement separtely: >> >> If an RTP session using multicast is negotiated using offer/answer >> all participants intending to send RTP packets SHALL support setting >> of ECN packet, and all participants receiving SHALL have the >> capability to read ECN values on incoming packets. If the >> participant lack the functionality they SHALL refuse the media >> streams using multicast. >> >> This clearly can be improved. But as it is offer/answer we should make >> it clear that the other part in a session requiring multicast and ECN >> shall ensure that the joining participant is capable. Thus using SIP >> methods for terminating the dialog and the other participants attempt >> to >> take part in the session. Does this make more sense? > > My concern in offer answer is that a legacy system that will receive an > offer with ecn attribute may accept the stream and remove the attribute in > the answer without violating offer/answer. I think that it will be up to the > offrer to terminate the session when noticing the lack of the ecn attribute > in the answer. > Yes, that is rightly a concern. I will attempt to clarify the need for the capable end-point to notice that and then either accept that ECN will fail, or terminate the dialog with that participant. 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 Mon Feb 21 02:36:20 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B09B53A707B for ; Mon, 21 Feb 2011 02:36:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.027 X-Spam-Level: X-Spam-Status: No, score=-106.027 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIxxTPm30dmK for ; Mon, 21 Feb 2011 02:36:19 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 88B413A7079 for ; Mon, 21 Feb 2011 02:36:19 -0800 (PST) X-AuditID: c1b4fb3d-b7c78ae000005844-38-4d62404ca235 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 99.08.22596.C40426D4; Mon, 21 Feb 2011 11:37:00 +0100 (CET) Received: from [147.214.183.8] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.2.234.1; Mon, 21 Feb 2011 11:36:59 +0100 Message-ID: <4D62404C.5080807@ericsson.com> Date: Mon, 21 Feb 2011 11:37:00 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Belling, Thomas (NSN - DE/Munich)" References: <744A66DF31B5B34EA8B08BBD8187A72203597EAD@DEMUEXC014.nsn-intra.net> <4D5A4456.8070000@ericsson.com> <744A66DF31B5B34EA8B08BBD8187A722035E48E5@DEMUEXC014.nsn-intra.net> <92AF6A87-D0C7-4F74-B9EF-C61B66BC9854@g11.org.uk> <744A66DF31B5B34EA8B08BBD8187A722035E499F@DEMUEXC014.nsn-intra.net> <4D5E3949.30804@ericsson.com> <744A66DF31B5B34EA8B08BBD8187A72203664A86@DEMUEXC014.nsn-intra.net> In-Reply-To: <744A66DF31B5B34EA8B08BBD8187A72203664A86@DEMUEXC014.nsn-intra.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: IETF AVT WG Subject: Re: [AVTCORE] draft-ietf-avtcore-ecn-for-rtp-00.txt: What to do if "ecn-fb" has not been negotiated via rtcp.fb attribute? X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 10:36:20 -0000 Belling, Thomas (NSN - DE/Munich) skrev 2011-02-18 10:29: > Hi Magnus, > > suppose that support of TMMBR is indicated in the "rtcp-fb" attribute (in a positive way, as you suggest), but support is "ECN FB" is not indicated. > > It is then clear from rtcp-fb negotiation rules that TMMBR can be used, but no ECN FB. Yes, I think so. And if it isn't clear then it is more a problem with RFC 4585 than this specification. > > What is unclear is a host supporting ECN would use TMMBR when receiving ECT-marked packets. Well, that is because we aren't defining the 3GPP TS 26.114 solution in our specifications. This draft currently do require for interoperability that you do support the ECN feedback format and the XR summary format as well as the RTP/RTCP based initiation method. If 3GPP selects to be non compliant to this and ignores the desire for interoperability, I think it is primarily the 3GPP's issue to ensure that their signalling ensures that TS 26.114 compliant terminals will negotiate this correctly. > > I intended to recommend that with the proposed wording. And I believe such a recommendation could be in scope of the ECN draft (not being explicit about TMMBR, but speaking about application specific feedback in general. I don't think it is that appropriate. What I think we can clarify further is the need for mechanisms using additional signalling or specific congestion control algorithms the need to define thier own signalling to ensure compatibility between enabled end-points. 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 swc@iis.sinica.edu.tw Mon Feb 21 04:52:32 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6C173A6EE9 for ; Mon, 21 Feb 2011 04:52:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.264 X-Spam-Level: X-Spam-Status: No, score=-1.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_TW=1.335] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNVZ0uXmw4Rx for ; Mon, 21 Feb 2011 04:52:30 -0800 (PST) Received: from iismx.iis.sinica.edu.tw (iismx.iis.sinica.edu.tw [140.109.20.49]) by core3.amsl.com (Postfix) with ESMTP id A35F23A6C85 for ; Mon, 21 Feb 2011 04:52:30 -0800 (PST) Received: from mail.iis.sinica.edu.tw (mail [192.168.0.50]) by iismx.iis.sinica.edu.tw (8.14.3/8.14.3) with ESMTP id p1LCr5rk086945 for ; Mon, 21 Feb 2011 20:53:06 +0800 (CST) (envelope-from swc@iis.sinica.edu.tw) Received: from [127.0.0.1] (swc.iis.sinica.edu.tw [140.109.20.151]) (authenticated bits=0) by mail.iis.sinica.edu.tw (8.13.8/8.13.8) with ESMTP id p1LCr52w002286 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Mon, 21 Feb 2011 20:53:05 +0800 (CST) (envelope-from swc@iis.sinica.edu.tw) Message-ID: <4D62602A.2050909@iis.sinica.edu.tw> Date: Mon, 21 Feb 2011 20:52:58 +0800 From: "Sheng-Wei (Kuan-Ta) Chen" Organization: Academia Sinica User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-TW; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: avt@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (iismx.iis.sinica.edu.tw [192.168.0.49]); Mon, 21 Feb 2011 20:53:06 +0800 (CST) X-Scanned-By: MIMEDefang 2.67 on 192.168.0.49 Subject: [AVTCORE] Call for Papers: NOSSDAV 2011 -- Deadline Extended to March 3rd X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: swc@iis.sinica.edu.tw List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 12:52:32 -0000 [Apologies if you receive this more than once] +++++++++++++++++++++ [ NOSSDAV 2011 Call for Papers ] +++++++++++++++++++++++ The 21th International Workshop on Network and Operating Systems Support for Digital Audio and Video June 2-3, 2011 Vancouver, British Columbia, Canada http://nss.cs.ubc.ca/nossdav2011/ NOSSDAV 2011 is the 21th anniversary of SIGMM's leading workshop on network and operating systems support for digital audio and video. The workshop, hosted at the University of British Columbia (UBC), will continue to focus on emerging research topics, controversial ideas, and future research directions in the area of multimedia systems research. As in previous years, we will maintain the focused single-track format a setting that stimulates lively discussions among the senior and junior participants. NOSSDAV encourages experimental research based on real systems and real data sets. Public availability of the source code and data sets discussed in papers presented at NOSSDAV is highly encouraged. For NOSSDAV 2011, we will accept papers on broad ranges of topics related to the transmission and presentation of digital audio/video objects. We are particularly interested in soliciting articles that discuss system-level support for distributed social media, as well as papers that focus on enabling multimedia applications in distributed cloud. Other topics of interest include (but are not restricted to): * OS, middleware and network support * Overlay networks * Media streaming, distribution and storage support * Web 2.0 systems and social networks * Media sensor and ad hoc networks / embedded systems * Multicore architecture support * Wireless and mobile multimedia systems / network processor support * Networked GPUs, graphics and virtual environments * Networked games / real-time immersive systems * Multimedia communications and system security * Grid/Cloud computing support Please contact the workshop co-chairs to check if your topic is within the scope of NOSSDAV. Papers will be judged on their relevance, technical content and correctness, and the clarity of presentation of the research. Papers should not be under review at another venue nor previously published elsewhere. Submissions should be at most SIX pages, using standard ACM proceedings style. We expect these submissions to be the kernel of what will eventually lead to full-length papers at high-quality conferences or journals. Important Dates Paper Submission Deadline: 3 Mar 2011 (extended) Decision Notification: 24 Mar 2011 Camera Ready Due: 7 Apr 2011 For more information, please visit the workshop website at http://nss.cs.ubc.ca/nossdav2011/ From Even.roni@huawei.com Mon Feb 21 06:02:01 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADA6B3A6F00; Mon, 21 Feb 2011 06:02:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.245 X-Spam-Level: X-Spam-Status: No, score=-102.245 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKwkV0CQjw2Y; Mon, 21 Feb 2011 06:02:00 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 0D3EF3A6EA1; Mon, 21 Feb 2011 06:02:00 -0800 (PST) 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 <0LGZ002RI0C3PY@szxga03-in.huawei.com>; Mon, 21 Feb 2011 22:02:28 +0800 (CST) Received: from 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 <0LGZ004FP0C3UK@szxga03-in.huawei.com>; Mon, 21 Feb 2011 22:02:27 +0800 (CST) Received: from windows8d787f9 (bzq-79-178-22-235.red.bezeqint.net [79.178.22.235]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LGZ0015P0ADVK@szxml12-in.huawei.com>; Mon, 21 Feb 2011 22:02:27 +0800 (CST) Date: Mon, 21 Feb 2011 15:56:41 +0200 From: Roni Even In-reply-to: <509DA52866E38F47878413CF102D751F7099C5CB50@poseidon.nexus-ag.com> To: 'Sambasiva Rao Manchili' , payload@ietf.org, 'IETF AVTCore WG' Message-id: <015601cbd1cf$507b89a0$f1729ce0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-us Content-transfer-encoding: quoted-printable Thread-index: AQHL0FeK//SQUrZ5dEaOQI5XewDSTpQJWCmQgACht4CAABCtEIABvk5QgAAwv/A= References: <509DA52866E38F47878413CF102D751F7099C582BD@poseidon.nexus-ag.com> <009201cbd07c$d6198570$824c9050$%roni@huawei.com> <509DA52866E38F47878413CF102D751F7099C582C0@poseidon.nexus-ag.com> <00b901cbd0d6$78b22270$6a166750$%roni@huawei.com> <509DA52866E38F47878413CF102D751F7099C5CB50@poseidon.nexus-ag.com> Cc: 'Antonio Gambin' , =?iso-8859-1?Q?'Ralf_K=FChl'?= , 'Markus Locher' Subject: Re: [AVTCORE] [payload] RTP Timestamping in Control messages of IuCS interface. X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 14:02:01 -0000 Hi, I am not sure if you read RFC4867 (http://tools.ietf.org/html/rfc4867) = which is the RTP payload specification for AMR Roni Even > -----Original Message----- > From: Sambasiva Rao Manchili > [mailto:sambasiva.manchili@nexustelecom.com] > Sent: Monday, February 21, 2011 1:05 PM > To: Roni Even; payload@ietf.org; avtcore@ietf.org > Cc: Antonio Gambin; Ralf K=FChl; Markus Locher > Subject: RE: [payload] RTP Timestamping in Control messages of IuCS > interface. >=20 > Hi Roni, > Sorry for late reply. > Since these are control messages of Upper layer(IuUP Protocol) all the > messages from upper layer should be treated same at RTP layer. This as > per Layered prorotocl architecture princples. >=20 > To my knowledge RTP layer has no table of contents which > differentiates it as Speech or control frame of upper layer. > All messages either Control message or Speech message of Upper layer = of > RTP belonging to a paricular subscriber will be sent with same RTP > Session number (Sync Source Identifier) >=20 > The payload type of RTP may be able to do this, but specification also > tells in Section 5 of RFC 3550 that > "An RTP source MAY change the payload type during a session, but this > field SHOULD NOT be used for multiplexing separate media streams" >=20 > Here the Payload type we use on IuCS interface for all type of = messages > is 96. >=20 > Thank you, > Samba. >=20 > -----Original Message----- > From: Roni Even [mailto:Even.roni@huawei.com] > Sent: Sunday, 20. February, 2011 09:16 > To: Sambasiva Rao Manchili; payload@ietf.org; avtcore@ietf.org > Cc: Antonio Gambin; Ralf K=FChl; Markus Locher > Subject: RE: [payload] RTP Timestamping in Control messages of IuCS > interface. >=20 > Hi, > These mailing lists are the right ones for RTP issues. > As for your question, the timestamp is the sample timestamp so if = there > is no speech in the packet than the time stamp will not progress. > For example consider a case where you have an RTP packet with control > and speech data followed by a packet with only control and a packet > with speech and control. > If you will advance the timestamp for the control only packet what = will > you do with the next one who has the next sampled speech frame. >=20 > With my limited knowledge of AMR payload, the RTP layer has the table > of content which need to know if there is a speech or control frame in > the packet, am I wrong? >=20 > Roni >=20 > > -----Original Message----- > > From: Sambasiva Rao Manchili > > [mailto:sambasiva.manchili@nexustelecom.com] > > Sent: Sunday, February 20, 2011 9:51 AM > > To: Roni Even; payload@ietf.org; avtcore@ietf.org > > Cc: Antonio Gambin; Ralf K=FChl; Markus Locher > > Subject: RE: [payload] RTP Timestamping in Control messages of IuCS > > interface. > > > > Hi Roni, > > Thank you very much for the writing to me over the weekend. > > Yes, the RTP timestamp corresponds to the sampling. In this case it > > is > > 16 samples per milli second for speech. > > It is uncertain for us about the timestmamp of these two consecutive > > control messages which are exchanged before real speech transmit on > > channel. These are first messages exchanged over RTP. > > These both control messages are to be acked before real speech > > transmits. Currently we discard one control message as both have = same > > timestamp and speech will not be transmitted as one control message > is > > discarded. > > > > When we capture on wireshark we see difference of 2.5 ms in = wireshark > > timestamp between these two control packets but RTP header timestamp > > remains same but sequence number increases. > > If I understood you right as long as there exists no real speech > > encoded in the packet then such packets can carry same timestamps. > > But then the question comes is it responsibility of RTP to see the > > content of bytes belonging to upper layer and decide if this has > > speech or normal control message and then evaluate timestamp of RTP > header ? > > > > Can you please lead me to group who are experts in AMR Iu UP Control > > messages (If I had not put the right group in my mailing list)? > > Thank you, > > Samba. > > > > ________________________________________ > > From: Roni Even [Even.roni@huawei.com] > > Sent: Saturday, February 19, 2011 10:34 PM > > To: Sambasiva Rao Manchili; payload@ietf.org; avtcore@ietf.org > > Cc: Antonio Gambin; Ralf K=FChl; Markus Locher > > Subject: RE: [payload] RTP Timestamping in Control messages of IuCS > > interface. > > > > Hi, > > I am not that familiar with the AMR control message but the general > > definition for time stamp is the RTP timestamp corresponds to the > > sampling instant of the first sample encoded for the first frame- > block > > in the packet. > > So if there is no speech information in the second packet it should > > have the same timestamp as the previous one. > > > > Roni Even > > > > > -----Original Message----- > > > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] = On > > > Behalf Of Sambasiva Rao Manchili > > > Sent: Saturday, February 19, 2011 7:08 PM > > > To: tsvwg@ietf.org; payload@ietf.org; avtcore@ietf.org; > > codec@ietf.org > > > Cc: Antonio Gambin; Ralf K=FChl; Markus Locher > > > Subject: [payload] RTP Timestamping in Control messages of IuCS > > > interface. > > > > > > Hallo, > > > > > > Can some one in IETF list, please help me to clarify the point > w.r.t > > > the Time stamping in RTP header for Audio Stream AMR 5.9. > > > I hope I am addressing to right group. > > > > > > Our implementation of RTP is not accepting the two control = messages > > > belonging to the UPP(User plane protocol above RTP) if the two > > > consecutive control packets arrived has same time stamp with > > different > > > sequence numbers. > > > The two control messages are UPP_INIT_ACK and Rate Control Message > > > which belongs to UPP layer on IuCS user plane stack. > > > Our implementation expects the time stamp of second packet to be > > 320ms > > > greater than the time stamp arrived in 1st Control message of RTP > > > header. > > > > > > Our counter part RTP stack says their implementation is right and > > > can have the same time stamp in the RTP header of these control > messages. > > > > > > RFC 3350 tells about equal timestamps for Video stream belonging > to > > > same frame, but does not specifically tell about the control > > > messages of its upper layer. > > > We have read the RFC 3550 , section 5.1 does NOT prevent RTP > packets > > > from having equal timestamps but rather explicitly allows for it: > > > > > > Several consecutive RTP packets will have equal timestamps = if > > > they are (logically) generated at once, e.g., belong to the > > same > > > video frame. Consecutive RTP packets MAY contain timestamps > > that > > > are not monotonic if the data is not transmitted in the = order > > it > > > was sampled, as in the case of MPEG interpolated video > frames. > > > (The sequence numbers of the packets as transmitted will > still > > be > > > monotonic.) > > > > > > May I kindly ask the RTP experts in Audio Stream area(or specific > to > > > IuCS ) can please clarify me. > > > > > > Thank you very much for your time. > > > > > > Best Regads, > > > Samba. > > > > > > This email and any attachment may contain confidential information > > > which is intended for use only by the addressee(s) named above. If > > you > > > received this email by mistake, please notify the sender > > > immediately, and delete the email from your system. You are > > > prohibited from > > copying, > > > disseminating or otherwise using the email or any attachment. > > > > > > _______________________________________________ > > > payload mailing list > > > payload@ietf.org > > > https://www.ietf.org/mailman/listinfo/payload > > > > > > > > This email and any attachment may contain confidential information > > which is intended for use only by the addressee(s) named above. If > you > > received this email by mistake, please notify the sender = immediately, > > and delete the email from your system. You are prohibited from > > copying, disseminating or otherwise using the email or any > attachment. >=20 >=20 >=20 >=20 > This email and any attachment may contain confidential information > which is intended for use only by the addressee(s) named above. If you > received this email by mistake, please notify the sender immediately, > and delete the email from your system. You are prohibited from = copying, > disseminating or otherwise using the email or any attachment. From xavier.marjou@gmail.com Mon Feb 21 07:32:04 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DB6C3A712F for ; Mon, 21 Feb 2011 07:32:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTrAgxJBoPWE for ; Mon, 21 Feb 2011 07:32:03 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 068833A7115 for ; Mon, 21 Feb 2011 07:32:02 -0800 (PST) Received: by vxa40 with SMTP id 40so357776vxa.31 for ; Mon, 21 Feb 2011 07:32:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=VEZyOGKqPlj+Uzrjles1Y+uGBFv+5lkxBng5ZPQfFhw=; b=uExpHiwLt7q7DpO4WORHbhk+m9nyJ5BO1+Kj47ektZ/BlO/DLLoJ++ApPCUm3EcVZq pirIaXISp6euHH7MYDRo0iABMUigrUamqftSnz7KdnjDtwLAZgnG2OwHCHx9XynZSA7G dSxCK8rYJ8j+EtxnQ/GIoUMcXHHHGgHEvmCqQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=D0gFieb/OmofZXzm7XXNXEomAmk5cDw1WRVSu8rFcDKrrfFq3QWrCmiO5E3/Ov3IUn K0vV1+/uDxHiqGQm6zrAQuxRZNvg/7fBCJjHkpyAEuxPweh6ZIz3wW7RHF51J72VyflG KZyZRBgPV3XSNVbe931Fv0SpfL5rx+T0UyDLA= MIME-Version: 1.0 Received: by 10.52.167.42 with SMTP id zl10mr2056848vdb.299.1298302360801; Mon, 21 Feb 2011 07:32:40 -0800 (PST) Received: by 10.220.20.20 with HTTP; Mon, 21 Feb 2011 07:32:40 -0800 (PST) Date: Mon, 21 Feb 2011 16:32:40 +0100 Message-ID: From: Xavier Marjou To: IETF AVT WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [AVTCORE] draft-ietf-avt-app-rtp-keepalive and RTCP X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 15:32:04 -0000 Hi, This mail deals with the rtp-keepalive draft: http://tools.ietf.org/id/draft-ietf-avt-app-rtp-keepalive-09.txt This 09 version still has one issue with regards to the IESG feedback, which is that "RTCP can not be left out of this draft". An explicit section about RTCP is thus needed. Magnus proposed some text for that. The resulting section would be the proposal below. Please give feedback if you think some details must be changed. Here is a link of what could be the complete draft when RTCP is added (ie: RTCP appears in tittle, abstract, introduction...) http://tinyurl.com/5ss2zyz You can use the menu "File"->"Download as"->"TXT" to use it with he http://tools.ietf.org/rfcdiff tool if you want. If I haven't heard anything to the contrary by March 3rd, I will submit -10 containing this text. Cheers, Xavier 8. RTCP Flow Keepalive RTCP packets are sent periodically and can thus normally maintain the NAT mappings open as long as they are sent frequently enough. There are two conditions for that. First RTCP needs to be used bi- directionally and in a symmetric fashion, as described in [RFC4961]. Secondly, RTCP needs to be sent frequently enough. However, there are certain configurations that can break this latter assumption. There are two factors that need to be considered to ensure that RTCP is sent frequently enough. First the RTCP bandwidth needs to be sufficiently large so that transmission will occur more frequently than the longest acceptable packet transmission interval (Tr). The worst case RTCP interval (Twc) can be calculated using this formula by inserting the max value of the following parameters: o Maximum RTCP packet size (avg_rtcp_size_max) o Maximum number of participants (members_max) o RTCP receiver bandwidth (rtcp_bw) The RTCP bandwidth value to use here is for a worst case, which will be the receiver proportion when all members are not senders except one. This can be approximated to be all members. Thus for sessions where RR and RS values are used, then rtcp_bw shall be set to RR. For sessions where the [RFC3550] defines proportions of 1/4 for sender and 3/4 for receivers are used, then rtcp_bw will be 5% of 3/4 of the AS value in bits per second. Twc = 1.5 / 1.21828 * members_max * rtcp_bw / avg_rtcp_size_max * 8 The second factor is the minimum RTCP interval Tmin defined in [RFC3550]. Its base value is 5 seconds, but it might also be scaled to 360 divided by the session bandwidth in kbps. The Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF) [RFC4585] also allows for the setting of a trr- int parameter which is a minimal RTCP interval for regular RTCP packets. It is also used as the Tmin value in the regular Td calculation. An analysis of the algorithm gives that the longest possible regular RTCP interval possible are: RTCP_int_max = trr-int * 1.5 + Td * 1.5 / 1.21828 And as long as the there is sufficient bandwidth according to criteria 1, then this can be simplified by setting Td = trr-int giving RTCP_int_max = trr-int * (1.5 + 1.5 / 1.21828) = 2.73123 * trr-int Thus the requirements on the RTCP parameters are the following for functioning keepalive: 1. Ensure that sufficient RTCP bandwidth is provided by calculating Twc and ensure that this is less than or equal to Tr. 2. If AVP or SAVP is used the Tmin value can't be greater that Tr divided by 1.5 / (e-3/2). 3. If AVPF or SAVPF is to be used trr-min must not be set to a greater value than Tr / 3. From rjsparks@nostrum.com Mon Feb 21 13:07:40 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDF783A7132 for ; Mon, 21 Feb 2011 13:07:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0QvXxvseVPq for ; Mon, 21 Feb 2011 13:07:39 -0800 (PST) Received: from nostrum.com (shaman.nostrum.com [72.232.179.90]) by core3.amsl.com (Postfix) with ESMTP id 778FC3A70F9 for ; Mon, 21 Feb 2011 13:07:39 -0800 (PST) Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p1LL6sl0006054 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 21 Feb 2011 15:07:03 -0600 (CST) (envelope-from rjsparks@nostrum.com) From: Robert Sparks Content-Type: multipart/alternative; boundary=Apple-Mail-70-40148848 Date: Mon, 21 Feb 2011 15:06:52 -0600 References: <50196776-A554-45C7-9E40-E44008E99D0E@nostrum.com> To: IETF AVTCORE WG Message-Id: <410D19DE-D1DF-4340-9503-1FD071F99ACC@nostrum.com> Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [AVTCORE] AD review: draft-ietf-ports-for-ucast-mcast-rtp-00 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 21:07:40 -0000 --Apple-Mail-70-40148848 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Summary: Ready, but with minor concerns. I've requested IETF LC - please treat these as IETF LC comments 1) Section 3.2: "That is, clients MUST NOT implement this specification with only a specific use case in mind" is not testable. I suggest either removing the sentence or replacing it with something that is more of an observation of the consequences of improperly implementing the MUST in the preceeding sentence 2) Consider replacing "guaranteed to be temporally and globally unique" in section 4.1 with "extremely unlikely to collide with other clients sharing the same IP address", pointing again to 4086 for implementation guidance. 3) In section 4.3.1, "might also need to be authenticated" could be more assertive. Are you trying to primarily influence implementers or application designers here? 4) In the final paragraph of Section 5, "and implementations might need to handle this eventually" is not that useful. Please consider deleting the phrase, or providing a concrete recommendation. 5) The end of Section 6 could be read to say that receiving a token verification failure message is part of the normal path for discovering that a session description change has occurred. Was the intent here to note that a _very_ recent change may have occurred and that an implementation should take care to avoid scheduling retries when that happens? If so, could this be rewritten to look less like it is encouraging implementations to rely on Token Verification Failures to notice that a session description has changed? Finally, it would help if this short description of retries could point to where the limit on the number of retries is defined. 6) (Nit) Section 7.1.1 "The 'portmapping-req' attribute SHALL be used as a media-level attribute" is slightly off target. It says that the attribute SHALL be used. The intent, I think, is that if it is used, it is used only at the media-level. I suggest adding the word "only" at "SHALL only be used". 7) To avoid confusion, consider saying "sub-registry of the Real-Time Transport Protocol (RTP) Parameters registr for the sub-message type"... 8) The way Section 3.2's item 5 is currently written, [I-D.ietf-avt-app-rtp-keepalive] looks like it should be a normative reference. If you intend for implementers to follow the guidance in that draft, please move the reference to normative and strengthen the text. If that's not the intent, adjust the text to make it clear that you are referring people to that draft for more information about the problem. --Apple-Mail-70-40148848 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Summary: Ready, but with minor = concerns.
     =    I've requested IETF LC - please treat these = as 
     =    IETF LC comments

1) = Section 3.2: "That is, clients MUST NOT implement this
specification with only a specific use case = in mind" is not
testable. I = suggest either removing the sentence or replacing it
with something that is more of an observation = of the consequences
of = improperly implementing the MUST in the preceeding = sentence

2) Consider replacing "guaranteed to be = temporally and globally
unique" = in section 4.1 with "extremely unlikely to collide with
other clients sharing the same IP address", = pointing again to
4086 for = implementation guidance.

3) In section 4.3.1, "might also need to be = authenticated" could
be more = assertive. Are you trying to primarily influence
implementers or application designers = here? 

4) In the final paragraph of Section 5, "and = implementations
might need to = handle this eventually" is not that useful. Please
consider deleting the phrase, or providing a = concrete
recommendation.

5) = The end of Section 6 could be read to say that receiving = a
token verification failure = message is part of the normal path for
discovering that a session description change = has occurred. Was
the intent = here to note that a _very_ recent change may have
occurred and that an implementation should = take care to avoid
scheduling = retries when that happens? If so, could this be
rewritten to look less like it is encouraging = implementations to
rely on = Token Verification Failures to notice that a session
description has changed?  Finally, it = would help if this short
description of retries could point to where = the limit on the
number of = retries is defined.

6) (Nit) Section 7.1.1 "The 'portmapping-req' = attribute SHALL be
used as a = media-level attribute" is slightly off target. It says
that the attribute SHALL be used. The intent, = I think, is that
if it is = used, it is used only at the media-level. I suggest 
adding the word "only" at "SHALL only be = used".

7) To avoid confusion, consider saying = "sub-registry of the
Real-Time = Transport Protocol (RTP) Parameters registr for the
sub-message type"...

8) = The way Section 3.2's item 5 is currently written,
[I-D.ietf-avt-app-rtp-keepalive] looks like = it should be a
normative = reference. If you intend for implementers to follow the
guidance in that draft, please move the = reference to normative
and = strengthen the text. If that's not the intent, adjust the
text to make it clear that you are referring = people to that draft
for more = information about the problem. 


= --Apple-Mail-70-40148848-- From sunseawq@huawei.com Tue Feb 22 00:57:23 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A6583A676A for ; Tue, 22 Feb 2011 00:57:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.283 X-Spam-Level: X-Spam-Status: No, score=-3.283 tagged_above=-999 required=5 tests=[AWL=1.212, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKHe9MUabN21 for ; Tue, 22 Feb 2011 00:57:22 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id A03933A6405 for ; Tue, 22 Feb 2011 00:57:21 -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 <0LH000DZNGW5XS@szxga04-in.huawei.com> for avt@ietf.org; Tue, 22 Feb 2011 16:57:41 +0800 (CST) Received: from 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 <0LH0001BFGW5RK@szxga04-in.huawei.com> for avt@ietf.org; Tue, 22 Feb 2011 16:57:41 +0800 (CST) Received: from w53375 ([10.138.41.48]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LH0008DDGW5CL@szxml04-in.huawei.com> for avt@ietf.org; Tue, 22 Feb 2011 16:57:41 +0800 (CST) Date: Tue, 22 Feb 2011 16:57:39 +0800 From: Qin Wu To: avt@ietf.org Message-id: <054301cbd26e$8eef15e0$30298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20110215054502.26622.8752.idtracker@localhost> Subject: Re: [AVTCORE] I-D Action:draft-ietf-avtcore-feedback-supression-rtp-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 08:57:23 -0000 Hi, Ali: Thank for your comments to this draft. Summarized what we discussed on the list during the last meeting, I believe two issues are waiting for being addressed. Issue 1: How FEC is taken into account in this draft? Currently this version does not touch this issue. But I agree both retransmission and FEC can be used to recover packet loss and will address this in the 01 version. Issue 2: It is not clear that how Distribution source in the SSM case react to different reports? I think each distribution source may send its own Third Party Loss report to downstream receivers respectively. if the upstream Third Party Loss Report reports the different event, the downstream distribution sources forward Third Party Loss Report received from upstream to all the RTP receivers, over the multicast channel. If the same event is reported from upstream distribution source, the downstream distribution source may suppress creating and sending its own report to the relevant RTP receivers. In response to these two pending comments, I propose to do the following changes to draft-ietf-avtcore-feedback-suppression-rtp. Section 3 OLD TEXT: " These intermediate nodes need to take into account such factors as the tolerable application delay, the network dynamics, and the media type. When the packet loss is detected upstream of the intermediary and additional latency is tolerable, the intermediate node may itself send a feedback message asking for the suspected lost packet or ask for the correct decoder refresh point. Because it has already provided the necessary feedback toward the source, the intermediate node can be reasonably certain that it will help the situation by sending a Third Party Loss Report message to all the relevant receivers, thereby indicating to the receivers that they should not transmit feedback messages for a period of time. " NEW TEXT: " These intermediate nodes need to take into account such factors as the tolerable application delay, packet loss recovery techniques, the network dynamics, and the media type. When the packet loss is detected upstream of the intermediary and additional latency is tolerable, loss-repair methods such as Forward Error Correction and retransmission may be used to recover the missing packets. Therefore the intermediate node can be reasonably certain that it will help the situation by sending a Third Party Loss Report message to all the relevant receivers, thereby indicating to the receivers that they should not transmit feedback messages for a period of time. " Section 6.1 OLD TEXT: " Another possibility is when there may be multiple distribution sources placed between the media source and the receivers, the upstream distribution source may inform downstream distribution sources of the detected packet loss using Third Party Loss Report messages. In response, the downstream distribution sources forward Third Party Loss Report received from upstream to all the RTP receivers, over the multicast channel. " NEW TEXT: " Another possibility is when there may be multiple distribution sources placed between the media source and the receivers, each distribution source may send its own Third Party Loss report to downstream receivers respectively. And also the upstream distribution source may inform downstream distribution sources in the path of the detected packet loss using Third Party Loss Report messages. In response, if the upstream Third Party Loss Report reports the different event, the downstream distribution sources forward Third Party Loss Report received from upstream to all the RTP receivers, over the multicast channel. If the same event is reported from upstream distribution source, the downstream distribution source may suppress creating and sending its own report to the relevant RTP receivers. " am I addressing your concerns? Regards! -Qin ----- Original Message ----- From: To: Cc: Sent: Tuesday, February 15, 2011 1:45 PM Subject: I-D Action:draft-ietf-avtcore-feedback-supression-rtp-00.txt >A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF. > > > Title : RTCP Extension for Feedback Suppression Indication > Author(s) : W. Wu, et al. > Filename : draft-ietf-avtcore-feedback-supression-rtp-00.txt > Pages : 17 > Date : 2011-02-14 > > In a large RTP session using the RTCP feedback mechanism defined in > RFC 4585, a media source or middlebox may experience transient > overload if some event causes a large number of receivers to send > feedback at once. This feedback implosion can be mitigated if the > device suffering from overload can send a third party loss report > message to the receivers to inhibit further feedback. This memo > defines RTCP extensions for third party loss report, to suppress NACK > and FIR feedback requests. It also defines associated SDP > signalling. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-avtcore-feedback-supression-rtp-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------------------- > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From iesg-secretary@ietf.org Tue Feb 22 06:34:36 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 457E33A68C5; Tue, 22 Feb 2011 06:34:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4pLMy3drZ-Rb; Tue, 22 Feb 2011 06:34:35 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75F043A68C0; Tue, 22 Feb 2011 06:34:35 -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.12 Message-ID: <20110222143435.12566.11395.idtracker@localhost> Date: Tue, 22 Feb 2011 06:34:35 -0800 Cc: avt@ietf.org Subject: [AVTCORE] Last Call: (Port Mapping Between Unicast and Multicast RTP Sessions) to Proposed Standard X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 14:34:36 -0000 The IESG has received a request from the Audio/Video Transport Core Maintenance WG (avtcore) to consider the following document: - 'Port Mapping Between Unicast and Multicast RTP Sessions' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-03-08. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-avtcore-ports-for-ucast-mcast-rtp/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-avtcore-ports-for-ucast-mcast-rtp/ No IPR declarations have been submitted directly on this I-D. From thomas.belling@nsn.com Tue Feb 22 18:07:21 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E71E3A67DF for ; Tue, 22 Feb 2011 18:07:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.059 X-Spam-Level: X-Spam-Status: No, score=-6.059 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-ryG93eUutr for ; Tue, 22 Feb 2011 18:07:20 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 609FF3A6989 for ; Tue, 22 Feb 2011 18:07:20 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p1N27xeH024093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Feb 2011 03:07:59 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p1N27vWZ005040; Wed, 23 Feb 2011 03:07:59 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.111]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 Feb 2011 03:07:25 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 23 Feb 2011 03:07:13 +0100 Message-ID: <744A66DF31B5B34EA8B08BBD8187A722036E8D17@DEMUEXC014.nsn-intra.net> In-Reply-To: <4D62404C.5080807@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVTCORE] draft-ietf-avtcore-ecn-for-rtp-00.txt: What to do if "ecn-fb" has not been negotiated via rtcp.fb attribute? Thread-Index: AcvRs0bZbl1hw3yxScyf6a3fcv0mSwBSAgxw References: <744A66DF31B5B34EA8B08BBD8187A72203597EAD@DEMUEXC014.nsn-intra.net> <4D5A4456.8070000@ericsson.com> <744A66DF31B5B34EA8B08BBD8187A722035E48E5@DEMUEXC014.nsn-intra.net> <92AF6A87-D0C7-4F74-B9EF-C61B66BC9854@g11.org.uk> <744A66DF31B5B34EA8B08BBD8187A722035E499F@DEMUEXC014.nsn-intra.net> <4D5E3949.30804@ericsson.com> <744A66DF31B5B34EA8B08BBD8187A72203664A86@DEMUEXC014.nsn-intra.net> <4D62404C.5080807@ericsson.com> From: "Belling, Thomas (NSN - DE/Munich)" To: "ext Magnus Westerlund" X-OriginalArrivalTime: 23 Feb 2011 02:07:25.0683 (UTC) FILETIME=[6A482430:01CBD2FE] Cc: IETF AVT WG Subject: Re: [AVTCORE] draft-ietf-avtcore-ecn-for-rtp-00.txt: What to do if "ecn-fb" has not been negotiated via rtcp.fb attribute? X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 02:07:21 -0000 Hi Magnus, please note that the agreed procedures in TS 26.114 currently do not = assume the behaviour discussed in this thread from peers, as we deemed = it safer not to take any such assumptions. Although the question poped up when we were preparing the procedures. So you believe such a recommendation is not appropriate? Thomas -----Original Message----- From: ext Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 Sent: Monday, February 21, 2011 11:37 AM To: Belling, Thomas (NSN - DE/Munich) Cc: ext ken carlberg; IETF AVT WG Subject: Re: [AVTCORE] draft-ietf-avtcore-ecn-for-rtp-00.txt: What to do = if "ecn-fb" has not been negotiated via rtcp.fb attribute? Belling, Thomas (NSN - DE/Munich) skrev 2011-02-18 10:29: > Hi Magnus, >=20 > suppose that support of TMMBR is indicated in the "rtcp-fb" attribute = (in a positive way, as you suggest), but support is "ECN FB" is not = indicated. >=20 > It is then clear from rtcp-fb negotiation rules that TMMBR can be = used, but no ECN FB. Yes, I think so. And if it isn't clear then it is more a problem with = RFC 4585 than this specification. >=20 > What is unclear is a host supporting ECN would use TMMBR when = receiving ECT-marked packets. Well, that is because we aren't defining the 3GPP TS 26.114 solution in = our specifications. This draft currently do require for interoperability = that you do support the ECN feedback format and the XR summary format as = well as the RTP/RTCP based initiation method. If 3GPP selects to be non compliant to this and ignores the desire for = interoperability, I think it is primarily the 3GPP's issue to ensure = that their signalling ensures that TS 26.114 compliant terminals will = negotiate this correctly. >=20 > I intended to recommend that with the proposed wording. And I believe = such a recommendation could be in scope of the ECN draft (not being = explicit about TMMBR, but speaking about application specific feedback = in general. I don't think it is that appropriate. What I think we can clarify = further is the need for mechanisms using additional signalling or = specific congestion control algorithms the need to define thier own = signalling to ensure compatibility between enabled end-points. 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 ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Wed Feb 23 00:11:39 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 584543A6830 for ; Wed, 23 Feb 2011 00:11:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.093 X-Spam-Level: X-Spam-Status: No, score=-106.093 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p5MCVtl+J4p1 for ; Wed, 23 Feb 2011 00:11:38 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id B92CA3A6826 for ; Wed, 23 Feb 2011 00:11:37 -0800 (PST) X-AuditID: c1b4fb3d-b7c78ae000005844-78-4d64c166b31d Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 74.97.22596.661C46D4; Wed, 23 Feb 2011 09:12:22 +0100 (CET) Received: from [147.214.183.8] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.2.234.1; Wed, 23 Feb 2011 09:12:22 +0100 Message-ID: <4D64C166.2020902@ericsson.com> Date: Wed, 23 Feb 2011 09:12:22 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Belling, Thomas (NSN - DE/Munich)" References: <744A66DF31B5B34EA8B08BBD8187A72203597EAD@DEMUEXC014.nsn-intra.net> <4D5A4456.8070000@ericsson.com> <744A66DF31B5B34EA8B08BBD8187A722035E48E5@DEMUEXC014.nsn-intra.net> <92AF6A87-D0C7-4F74-B9EF-C61B66BC9854@g11.org.uk> <744A66DF31B5B34EA8B08BBD8187A722035E499F@DEMUEXC014.nsn-intra.net> <4D5E3949.30804@ericsson.com> <744A66DF31B5B34EA8B08BBD8187A72203664A86@DEMUEXC014.nsn-intra.net> <4D62404C.5080807@ericsson.com> <744A66DF31B5B34EA8B08BBD8187A722036E8D17@DEMUEXC014.nsn-intra.net> In-Reply-To: <744A66DF31B5B34EA8B08BBD8187A722036E8D17@DEMUEXC014.nsn-intra.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: IETF AVT WG Subject: Re: [AVTCORE] draft-ietf-avtcore-ecn-for-rtp-00.txt: What to do if "ecn-fb" has not been negotiated via rtcp.fb attribute? X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 08:11:39 -0000 Belling, Thomas (NSN - DE/Munich) skrev 2011-02-23 03:07: > Hi Magnus, > > please note that the agreed procedures in TS 26.114 currently do not assume the behaviour discussed in this thread from peers, as we deemed it safer not to take any such assumptions. > > Although the question poped up when we were preparing the procedures. > > So you believe such a recommendation is not appropriate? I think there can be an informative pointer to that in advanced use case beyond what is defined in here, it is important to watch the RTCP-FB attribute for what messages really should be used in a session. 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 abegen@cisco.com Wed Feb 23 15:50:25 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1757A3A69A5 for ; Wed, 23 Feb 2011 15:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.528 X-Spam-Level: X-Spam-Status: No, score=-10.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qVdBUJM-lJTy for ; Wed, 23 Feb 2011 15:50:24 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id EE5B93A698E for ; Wed, 23 Feb 2011 15:50:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=3890; q=dns/txt; s=iport; t=1298505072; x=1299714672; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=/JKqTaFiVwtWhgsEJdzUpy1XFLEIu35N3f6vkH6p8J8=; b=AZ+F7UYzKrw2NsHOgfiV2/UT8s06Abh0IcudImu0YQ5jEPAOSg3R/+dB a8Gx/t5jggr9/GJm8SxKRcQ3rkacgvFGOE0KyARFBpE1aYhdJM4gEFgSP l3l5RS9g8lfuSfO4kFTMrHffZSA/1ChmBJvMGElBmLm1Lv6uKGsU8EQDY 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUBAKssZU2rR7Hu/2dsb2JhbACXUo5Nc6BDm2CFXgSFDYpK X-IronPort-AV: E=Sophos;i="4.62,214,1297036800"; d="scan'208";a="664117578" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 23 Feb 2011 23:51:12 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p1NNpCI5023862; Wed, 23 Feb 2011 23:51:12 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); Wed, 23 Feb 2011 15:51:12 -0800 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: Wed, 23 Feb 2011 15:51:08 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540E614655@xmb-sjc-215.amer.cisco.com> In-Reply-To: <50196776-A554-45C7-9E40-E44008E99D0E@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review: draft-ietf-ports-for-ucast-mcast-rtp-00 Thread-Index: AcvSCPiXViKPeeyMTsmyJ40rdIoJhgBqd+Vg References: <50196776-A554-45C7-9E40-E44008E99D0E@nostrum.com> From: "Ali C. Begen (abegen)" To: "Robert Sparks" , X-OriginalArrivalTime: 23 Feb 2011 23:51:12.0133 (UTC) FILETIME=[8CE12350:01CBD3B4] Cc: draft-ietf-avtcore-ports-for-ucast-mcast-rtp@tools.ietf.org Subject: Re: [AVTCORE] AD review: draft-ietf-ports-for-ucast-mcast-rtp-00 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 23:50:25 -0000 Hi Robert, > -----Original Message----- > From: Robert Sparks [mailto:rjsparks@nostrum.com] > Sent: Monday, February 21, 2011 12:48 PM > To: avtcore@ietf.org > Cc: avtcore-chairs@tools.ietf.org; = draft-ietf-avtcore-ports-for-ucast-mcast-rtp@tools.ietf.org > Subject: AD review: draft-ietf-ports-for-ucast-mcast-rtp-00 >=20 > Summary: Ready, but with minor concerns. > I've requested IETF LC - please treat these as > IETF LC comments >=20 > 1) Section 3.2: "That is, clients MUST NOT implement this > specification with only a specific use case in mind" is not > testable. I suggest either removing the sentence or replacing it > with something that is more of an observation of the consequences > of improperly implementing the MUST in the preceeding sentence I am fine with removing this sentence, since the earlier sentence tells = what I wanna say. =20 > 2) Consider replacing "guaranteed to be temporally and globally > unique" in section 4.1 with "extremely unlikely to collide with > other clients sharing the same IP address", pointing again to > 4086 for implementation guidance. Good suggestion. =20 > 3) In section 4.3.1, "might also need to be authenticated" could > be more assertive. Are you trying to primarily influence > implementers or application designers here? Implementers. As being more assertive, I am not sure how we could do = that since we don=92t wanna be more assertive. =20 > 4) In the final paragraph of Section 5, "and implementations > might need to handle this eventually" is not that useful. Please > consider deleting the phrase, or providing a concrete > recommendation. Deleting is fine with me: Finally, be aware that NTP timestamps will wrap around in year 2036. Refer to Section 6 of [RFC5905] for further details =20 > 5) The end of Section 6 could be read to say that receiving a > token verification failure message is part of the normal path for > discovering that a session description change has occurred. Was I don=92t think the implementations should try the token approach to = confirm whether SDP was updated or not. That was not the intention of = this text. > the intent here to note that a _very_ recent change may have > occurred and that an implementation should take care to avoid > scheduling retries when that happens? If so, could this be > rewritten to look less like it is encouraging implementations to > rely on Token Verification Failures to notice that a session > description has changed? Finally, it would help if this short I hope it does not encourage doing that. I will think how to reword = this. > description of retries could point to where the limit on the > number of retries is defined. We did not define a max limit since if the client needs it, it will keep = trying I guess. =20 > 6) (Nit) Section 7.1.1 "The 'portmapping-req' attribute SHALL be > used as a media-level attribute" is slightly off target. It says > that the attribute SHALL be used. The intent, I think, is that > if it is used, it is used only at the media-level. I suggest > adding the word "only" at "SHALL only be used". Good catch. =20 > 7) To avoid confusion, consider saying "sub-registry of the > Real-Time Transport Protocol (RTP) Parameters registr for the > sub-message type"... OK. =20 > 8) The way Section 3.2's item 5 is currently written, > [I-D.ietf-avt-app-rtp-keepalive] looks like it should be a > normative reference. If you intend for implementers to follow the > guidance in that draft, please move the reference to normative > and strengthen the text. If that's not the intent, adjust the > text to make it clear that you are referring people to that draft > for more information about the problem. OK, we did not intend to make it normative. I will check the text. Thanks. -acbegen From yekui.wang@huawei.com Thu Feb 24 09:51:42 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77F923A67B8 for ; Thu, 24 Feb 2011 09:51:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gw2CBw1-hH9g for ; Thu, 24 Feb 2011 09:51:40 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id EE7843A677E for ; Thu, 24 Feb 2011 09:51:39 -0800 (PST) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LH400E3LUZHEZ@usaga02-in.huawei.com> for avt@ietf.org; Thu, 24 Feb 2011 09:52:29 -0800 (PST) Received: from dfweml201-edg.china.huawei.com ([172.18.9.107]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LH400MEGUZH18@usaga02-in.huawei.com> for avt@ietf.org; Thu, 24 Feb 2011 09:52:29 -0800 (PST) Received: from DFWEML401-HUB.china.huawei.com (10.193.5.101) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 24 Feb 2011 09:52:23 -0800 Received: from DFWEML501-MBX.china.huawei.com ([fe80::c52a:9e19:87eb:4531]) by DFWEML401-HUB.china.huawei.com ([fe80::f07f:889f:78ef:8df3%13]) with mapi id 14.01.0270.001; Thu, 24 Feb 2011 09:52:29 -0800 Date: Thu, 24 Feb 2011 17:52:28 +0000 From: Ye-Kui Wang In-reply-to: X-Originating-IP: [10.193.125.214] To: varun singh Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US Thread-topic: [AVTCORE] Comments on draft-singh-avt-mprtp-01 Thread-index: AQHLxyVZZMgSXOBsZ0qnpWiKHXAj35P85EwAgBQSL+A= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <01fc01cbc44d$194ddc10$4be99430$%roni@huawei.com> Cc: "varun@comnet.tkk.fi" , "avt@ietf.org" Subject: Re: [AVTCORE] Comments on draft-singh-avt-mprtp-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 17:51:42 -0000 Hi Varun, Thanks for your reply. See inline below.=20 BR, YK -----Original Message----- From: varun singh [mailto:vsingh.ietf@gmail.com]=20 Sent: Friday, February 11, 2011 9:16 AM To: Wangyekui Cc: avt@ietf.org; varun@comnet.tkk.fi Subject: Re: [AVTCORE] Comments on draft-singh-avt-mprtp-01 Hi Ye-kui, comments inline On Tue, Feb 8, 2011 at 02:15, Wangyekui wrote: > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 First of all, I think this draft initiated a= very useful work. For example, today, many mobile operators have deployed = dual-plane IP bearer networks, wherein a multipath version of RTP can be us= ed for real-time communications such as voice- and video-over-IP services. = BTW, you may want to mention this in the introduction section. Can you elaborate on what is a dual-plane IP bearer. YK: This is basically an IP bearer network with two planes, between which t= here can be communications. When there is problem is one plane, services wo= uld be all switched to the other plane. Mobile operators deploy such networ= ks for robust service provisioning. In the multi-path context, two planes p= rovide at least two paths for data transfer. > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 The draft specifies the negotiation of multi= ple paths is through upgrading from a single-path session and using in-band= signaling (i.e. RTP header extension) for indication of additional paths. = Would it be better to negotiate the use of one or more of the available pat= hs out-of-band (i.e. using SDP)? One problem with in-band negotiation is th= at, if the initial path happens to be broken, then even the session setup w= ould fail. Another problem is that in-band information may get lost (and wh= en it happens the negotiation would fail). If the initial path is broken then it would also fail for the case of single path RTP.=20 YK: Right, that's the point. If initially multiple possible paths are offer= ed, then the other side may check and choose the best one or at least a wor= king one. In the spec we allow for ICE and SDP. SDP is too slow to always negotiate. YK: What do you mean by "allow for SDP"? Allow for offering multiple paths = using SDP? > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 In some cases, it may be useful to use multi= ple paths concurrently, for improved throughput. In some other cases, it ma= y be more desirable to use only a subset of available paths at any time ins= tance. For example, in mobile networks using dual-plane IP bearer, typicall= y the better-performing path is used, while the other path is kept there fo= r fast fallback when the path being used has problem. Therefore, it would b= e desirable if signaling of such a capability/preference is possible. > This is a good point and the draft aims to have basic mechanisms first. Profiles to be added later, may be to the same document or as a different draft. We'll add this inside as an editor's note. YK: Good. > -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Finally, it would be useful if it is possibl= e to indicate more path specific information when advertising paths (or "in= terfaces" as used in the draft), e.g., which of the two planes in a network= using dual-plane IP bearer. It might be sufficient if there is a hook spec= ified to enable backwards compatible extensions when the potential multipat= h RTP standard is used in the future by application system standards. We need to stay independent of network architecture or infrastructure. YK: Agreed. However, can you elaborate on the extension that can signal a path's characteristic? YK: Actually I found that the "mprtp-optional-parameter" in the current dra= ft is already sufficient for this. We just need to keep in mind that in the= final spec there should be such an openly specified parameter.=20 From Even.roni@huawei.com Thu Feb 24 15:18:49 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79E713A680C; Thu, 24 Feb 2011 15:18:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.209 X-Spam-Level: X-Spam-Status: No, score=-103.209 tagged_above=-999 required=5 tests=[AWL=1.285, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bxDyprOd8Uyk; Thu, 24 Feb 2011 15:18:48 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 546123A6808; Thu, 24 Feb 2011 15:18:48 -0800 (PST) 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 <0LH5001ZBA4GA7@szxga03-in.huawei.com>; Fri, 25 Feb 2011 07:19:28 +0800 (CST) Received: from 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 <0LH5009GVA4GL4@szxga03-in.huawei.com>; Fri, 25 Feb 2011 07:19:28 +0800 (CST) Received: from windows8d787f9 (bzq-79-178-14-23.red.bezeqint.net [79.178.14.23]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LH50046VA453C@szxml11-in.huawei.com>; Fri, 25 Feb 2011 07:19:28 +0800 (CST) Date: Fri, 25 Feb 2011 01:19:25 +0200 From: Roni Even To: 'IETF AVTCore WG' Message-id: <004d01cbd479$4e307140$ea9153c0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_+tffHAXqK6M1PNbt/YaUvw)" Content-language: en-us Thread-index: AcvUeUbQYcW+WCcvRUa1Q6RXKYvdgw== Cc: 'Magnus Westerlund' , payload@ietf.org, xrblock@ietf.org Subject: [AVTCORE] Requests for agenda time in Prague IETF80 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 23:18:49 -0000 This is a multi-part message in MIME format. --Boundary_(ID_+tffHAXqK6M1PNbt/YaUvw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, This will be the first meeting after the restructuring of AVT. We will have one time slot for AVTCore and we will use this timeslot also to present the status of the new payload and xrblock working groups. If you wish to have agenda time at the upcoming meeting in Prague , please send an agenda request to the chairs. We are trying to prepare the agenda early and not wait for the last minute. We will use the time for presentations giving priority based on the AVTCore milestones and open issues. The draft agenda shows that AVTCore will meet on Monday 13:00 -15:00 in Roma room. Note that this is not the final agenda. Thanks Magnus Westerlund and Roni Even AVTCore Chairs. Ali Begen and Roni Even Payload Chairs Peter Musgrave and Roni Even XRblock Chairs. --Boundary_(ID_+tffHAXqK6M1PNbt/YaUvw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

This will be the first meeting after the restructuring of AVT. We will have one time slot for AVTCore and we will use this timeslot also to present the status of the new payload and xrblock working groups.

 

If you wish to have agenda time at the upcoming meeting in Prague , please send an agenda request to the chairs. We are trying to prepare the agenda early and no t wait f /o:p>

 

 

We will use the time for presentations giving priority based on the AVTCore milestones and open issues.

 

 

The draft agenda shows that AVTCore will meet on Monday 13:00 -15:00 i n Roma r t the final agenda.

 

Thanks
Magnus Westerlund and Roni Even AVTCore Chairs.
 
Ali Begen and Roni Even Payload Chairs
 
Peter Musgrave and Roni Even XRblock Chairs.

 

--Boundary_(ID_+tffHAXqK6M1PNbt/YaUvw)-- From vsingh.ietf@gmail.com Fri Feb 25 01:07:47 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03E583A6928 for ; Fri, 25 Feb 2011 01:07:47 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8SeMETpdT-Q for ; Fri, 25 Feb 2011 01:07:45 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 874B33A68FE for ; Fri, 25 Feb 2011 01:07:45 -0800 (PST) Received: by fxm15 with SMTP id 15so1468435fxm.31 for ; Fri, 25 Feb 2011 01:08:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:from:date:message-id:subject:to :content-type; bh=jifoXF0vpzEFQYjF4pPL94gjuwhiu9d4U0X1GmJwXtA=; b=Ao4PzOiano2STpZWsT0OCKiA1bjrtIBrmU0iwzrEuwi7cZOw78rAN8M6/wM+1cInc9 NVUHK/NxRLYUdaWcm5N3hkKodu6ANKVrtKWxl6ExzyYjPVRpuHDQnwNd0+YD69sgiipe Kr8n3h0K18qvQ76vzqPjoM9PJenfrhI0gZleI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=kiXju3ABgta/57Pk8dXMlFkHS5EJ05a5IifEj0/KxWXWRrqrqgDDu3JIk5jhp5F0o1 G2snQAH09NqONXR9u4E/BW5zU4iF6NIMsOn/yaxNGxlr187t3ZI1Obo1Y4BHt4PXD4SS m8WemPJ5YPG8UeR7iubzeoyZdGE5lBqhi31Us= Received: by 10.223.83.203 with SMTP id g11mr2282123fal.137.1298624895186; Fri, 25 Feb 2011 01:08:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.49.87 with HTTP; Fri, 25 Feb 2011 01:07:55 -0800 (PST) From: varun singh Date: Fri, 25 Feb 2011 11:07:55 +0200 Message-ID: To: avt@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [AVTCORE] Fwd: New Version Notification for draft-singh-avt-mprtp-02 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 09:07:47 -0000 Hi, We have submitted a new version of MPRTP. Sections 7 and 8 have undergone some significant change. The detailed diff can be seen here: http://tools.ietf.org/rfcdiff?url2=draft-singh-avt-mprtp-02.txt Filename: draft-singh-avt-mprtp Revision: 02 Title: Multipath RTP (MPRTP) Creation_date: 2011-02-24 WG ID: Independent Submission Number_of_pages: 25 Abstract: The Real-time Transport Protocol (RTP) is used to deliver real-time content and, along with the RTP Control Protocol (RTCP), forms the control channel between the sender and receiver. However, RTP and RTCP assume a single delivery path between the sender and receiver and make decisions based on the measured characteristics of this single path. Increasingly, endpoints are becoming multi-homed, which means that they are connected via multiple Internet paths. Network utilization can be improved when endpoints use multiple parallel paths for communication. The resulting increase in reliability and throughput can also enhance the user experience. This document extends the Real-time Transport Protocol (RTP) so that a single session can take advantage of the availability of multiple paths between two endpoints. The IETF Secretariat. Varun Singh http://www.netlab.tkk.fi/~varun From magnus.westerlund@ericsson.com Fri Feb 25 05:04:12 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0EFA3A69AF for ; Fri, 25 Feb 2011 05:04:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.386 X-Spam-Level: X-Spam-Status: No, score=-106.386 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2k7L4XagX50A for ; Fri, 25 Feb 2011 05:04:12 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id DB2DB3A69AE for ; Fri, 25 Feb 2011 05:04:11 -0800 (PST) X-AuditID: c1b4fb39-b7b76ae00000276e-97-4d67a8fec713 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id E5.41.10094.EF8A76D4; Fri, 25 Feb 2011 14:05:03 +0100 (CET) Received: from [147.214.183.8] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.2.234.1; Fri, 25 Feb 2011 14:05:02 +0100 Message-ID: <4D67A8FE.3050806@ericsson.com> Date: Fri, 25 Feb 2011 14:05:02 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: avt@ietf.org, sunseawq@huawei.com References: <005101cb9edd$0e2a5f10$2a7f1d30$%roni@huawei.com> In-Reply-To: <005101cb9edd$0e2a5f10$2a7f1d30$%roni@huawei.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [AVTCORE] Editor for WG version of Monitoring Architecture X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 13:04:12 -0000 AVTCore and Qin Wu Once more thanks to all the people that volunteered for the role as editor of the WG i-d for the RTP monitoring architecture. We have picked Qin Wu as editor. Sorry for the late decision. I do hope that you will be able to submit a new version before the deadline. Regards 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 rjsparks@nostrum.com Fri Feb 25 09:02:39 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDADA3A6781 for ; Fri, 25 Feb 2011 09:02:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzfse1P6Mn9X for ; Fri, 25 Feb 2011 09:02:39 -0800 (PST) Received: from nostrum.com (shaman.nostrum.com [72.232.179.90]) by core3.amsl.com (Postfix) with ESMTP id 28C283A6407 for ; Fri, 25 Feb 2011 09:02:39 -0800 (PST) Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p1PH2F4G047753 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 25 Feb 2011 11:02:15 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-10-371071812 From: Robert Sparks In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540E614655@xmb-sjc-215.amer.cisco.com> Date: Fri, 25 Feb 2011 11:02:15 -0600 Message-Id: References: <50196776-A554-45C7-9E40-E44008E99D0E@nostrum.com> <04CAD96D4C5A3D48B1919248A8FE0D540E614655@xmb-sjc-215.amer.cisco.com> To: "Ali C. Begen (abegen)" X-Mailer: Apple Mail (2.1082) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: avt@ietf.org, draft-ietf-avtcore-ports-for-ucast-mcast-rtp@tools.ietf.org Subject: Re: [AVTCORE] AD review: draft-ietf-ports-for-ucast-mcast-rtp-00 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 17:02:40 -0000 --Apple-Mail-10-371071812 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 (trimming to one topic) On Feb 23, 2011, at 5:51 PM, Ali C. Begen (abegen) wrote: >=20 >>=20 >=20 >> 3) In section 4.3.1, "might also need to be authenticated" could >> be more assertive. Are you trying to primarily influence >> implementers or application designers here? >=20 > Implementers. As being more assertive, I am not sure how we could do = that since we don=92t wanna be more assertive. Are you trying to not be assertive about implementing or about using? If = you're just trying to avoid forcing people to _use_ the mechanism, but want to make sure a particular deployment can decide = to use the mechanism without forklifting its install base, you could say something like "Implementations MUST = support authenticating such RTCP messages by=20 using a Token". RjS --Apple-Mail-10-371071812 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252



3) In section 4.3.1, "might also need to be authenticated" = could
be more assertive. Are = you trying to primarily influence
implementers or application designers = here?

Implementers. As being more assertive, I am = not sure how we could do that since we don=92t wanna be more = assertive.

Are you trying to not be = assertive about implementing or about using? If you're just trying to = avoid forcing people to _use_
the mechanism, but want to make = sure a particular deployment can decide to use the mechanism without = forklifting its
install base, you could say something = like  "Implementations MUST support authenticating such RTCP = messages by 
using a = Token".

RjS


= --Apple-Mail-10-371071812-- From abegen@cisco.com Fri Feb 25 09:06:47 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBE4B3A679F for ; Fri, 25 Feb 2011 09:06:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.532 X-Spam-Level: X-Spam-Status: No, score=-10.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJgqjrsXysnR for ; Fri, 25 Feb 2011 09:06:46 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id D35323A67A5 for ; Fri, 25 Feb 2011 09:06:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=1364; q=dns/txt; s=iport; t=1298653659; x=1299863259; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=XqSQQ0FyLIZ4cvKEdS09xqYCyKEg0Cnwhx6hmknL1yI=; b=iJcxOSlotWuNwGCj0CicKeG4pFNB+8oCzlTXFYC5kKYMHvY7bjuDJy4Y 0NsTaTt5KM3KCXrRjpPfDxhN7I6fJ6svcW0Kt9xCDvJoWGMxFq51+5O1u AWYrEV7uzw4e+3sBa1GEI07JBHyxV1kwIydkTsZS2bl5HxhjbPt8HIeiG 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcBAL9wZ02rR7Ht/2dsb2JhbACXa45RdKE2m2qFYASFEIpR X-IronPort-AV: E=Sophos;i="4.62,226,1297036800"; d="scan'208";a="315226874" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 25 Feb 2011 17:07:39 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1PH7dxr023632; Fri, 25 Feb 2011 17:07:39 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); Fri, 25 Feb 2011 09:07:39 -0800 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: Fri, 25 Feb 2011 09:07:41 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540E6BF2A8@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review: draft-ietf-ports-for-ucast-mcast-rtp-00 Thread-Index: AcvVDceVMnQ7hsFMQZ+brhkerz2mqAAAKY+A References: <50196776-A554-45C7-9E40-E44008E99D0E@nostrum.com> <04CAD96D4C5A3D48B1919248A8FE0D540E614655@xmb-sjc-215.amer.cisco.com> From: "Ali C. Begen (abegen)" To: "Robert Sparks" X-OriginalArrivalTime: 25 Feb 2011 17:07:39.0567 (UTC) FILETIME=[81E443F0:01CBD50E] Cc: avt@ietf.org, draft-ietf-avtcore-ports-for-ucast-mcast-rtp@tools.ietf.org Subject: Re: [AVTCORE] AD review: draft-ietf-ports-for-ucast-mcast-rtp-00 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 17:06:47 -0000 > -----Original Message----- > From: Robert Sparks [mailto:rjsparks@nostrum.com] > Sent: Friday, February 25, 2011 9:02 AM > To: Ali C. Begen (abegen) > Cc: avt@ietf.org; = draft-ietf-avtcore-ports-for-ucast-mcast-rtp@tools.ietf.org > Subject: Re: AD review: draft-ietf-ports-for-ucast-mcast-rtp-00 >=20 > (trimming to one topic) >=20 > On Feb 23, 2011, at 5:51 PM, Ali C. Begen (abegen) wrote: >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > 3) In section 4.3.1, "might also need to be authenticated" could >=20 >=20 > be more assertive. Are you trying to primarily influence >=20 >=20 > implementers or application designers here? >=20 >=20 >=20 > Implementers. As being more assertive, I am not sure how we could do = that since we don=92t wanna be more assertive. >=20 >=20 >=20 > Are you trying to not be assertive about implementing or about using? = If you're just trying to avoid forcing people to _use_ > the mechanism, but want to make sure a particular deployment can = decide to use the mechanism without forklifting its > install base, you could say something like "Implementations MUST = support authenticating such RTCP messages by > using a Token". Ok, thanks. This addresses my concern. I will hold on to the changes = till we get the other LC comments. -acbegen =20 > RjS >=20 >=20 From vsingh.ietf@gmail.com Fri Feb 25 13:43:37 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0265B3A6A48 for ; Fri, 25 Feb 2011 13:43:37 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yePEXPFgk5JI for ; Fri, 25 Feb 2011 13:43:35 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 93D453A6A44 for ; Fri, 25 Feb 2011 13:43:35 -0800 (PST) Received: by fxm15 with SMTP id 15so2171886fxm.31 for ; Fri, 25 Feb 2011 13:44:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type:content-transfer-encoding; bh=xulgp/K06NPH8ecPCHpLx1DEIaAkTqx069mmso/M+EQ=; b=p29g1FCmI4juRhyi/MoBM3aRDGn5Werp6FSXNRaHr3Go/OklmfGPW+0l880CNxP6B/ JrgcfPYuI/ueTuuD6NhksJMbGoRBbXTMh2RQrnabJ39RRamDy+9uY92ipqzmszVockQ3 hmtCqMtVZwc6T1+KdYCdmBy0Omy/iu8ama+rc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=aBu2Zg6X/94ZqYRXyIwF38R+7xjKzM8gaOQq6IozUOR6X5vP41r3Dc//ZtWTuwYR1c 2vuunuuOg3Eys4tfEtv+DuY0dOeLbua+41dxX/tAK1rUMEEUeR4W9M7pLzJK4HlrbqpD iNj8884xQzzVLTrcXE2XHqXev/1Sj5ehbNGa8= Received: by 10.223.97.2 with SMTP id j2mr3346441fan.23.1298670268203; Fri, 25 Feb 2011 13:44:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.49.87 with HTTP; Fri, 25 Feb 2011 13:44:08 -0800 (PST) In-Reply-To: References: From: varun singh Date: Fri, 25 Feb 2011 23:44:08 +0200 Message-ID: To: avt@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [AVTCORE] New Version Notification for draft-singh-avt-mprtp-02 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 21:43:37 -0000 Hi, The earlier draft is resubmitted under avtcore and is available at: http://tools.ietf.org/html/draft-singh-avtcore-mprtp-00 Cheers, Varun On Fri, Feb 25, 2011 at 11:07, varun singh wrote: > Hi, > > We have submitted a new version of MPRTP. Sections 7 and 8 have > undergone some significant change. =A0The detailed diff can be seen > here: http://tools.ietf.org/rfcdiff?url2=3Ddraft-singh-avt-mprtp-02.txt > > > Filename: =A0 =A0 =A0 =A0draft-singh-avt-mprtp > Revision: =A0 =A0 =A0 =A002 > Title: =A0 =A0 =A0 =A0 =A0 Multipath RTP (MPRTP) > Creation_date: =A0 2011-02-24 > WG ID: =A0 =A0 =A0 =A0 =A0 Independent Submission > Number_of_pages: 25 > > Abstract: > The Real-time Transport Protocol (RTP) is used to deliver real-time > content and, along with the RTP Control Protocol (RTCP), forms the > control channel between the sender and receiver. =A0However, RTP and > RTCP assume a single delivery path between the sender and receiver > and make decisions based on the measured characteristics of this > single path. =A0Increasingly, endpoints are becoming multi-homed, which > means that they are connected via multiple Internet paths. =A0Network > utilization can be improved when endpoints use multiple parallel > paths for communication. =A0The resulting increase in reliability and > throughput can also enhance the user experience. =A0This document > extends the Real-time Transport Protocol (RTP) so that a single > session can take advantage of the availability of multiple paths > between two endpoints. > > > > The IETF Secretariat. > > > Varun Singh > http://www.netlab.tkk.fi/~varun > From sunseawq@huawei.com Fri Feb 25 17:38:18 2011 Return-Path: X-Original-To: avt@core3.amsl.com Delivered-To: avt@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C42C43A681B for ; Fri, 25 Feb 2011 17:38:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APUfne8Rq3uq for ; Fri, 25 Feb 2011 17:38:18 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id A44DA3A659A for ; Fri, 25 Feb 2011 17:38:17 -0800 (PST) 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 <0LH7001XGB909Y@szxga03-in.huawei.com> for avt@ietf.org; Sat, 26 Feb 2011 09:39:00 +0800 (CST) Received: from 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 <0LH7008Q3B90I1@szxga03-in.huawei.com> for avt@ietf.org; Sat, 26 Feb 2011 09:39:00 +0800 (CST) Received: from w53375 ([10.138.41.48]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LH700B4PB90WZ@szxml06-in.huawei.com> for avt@ietf.org; Sat, 26 Feb 2011 09:39:00 +0800 (CST) Date: Sat, 26 Feb 2011 09:38:59 +0800 From: Qin Wu To: Magnus Westerlund , avt@ietf.org Message-id: <024b01cbd555$f10e6520$30298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal References: <005101cb9edd$0e2a5f10$2a7f1d30$%roni@huawei.com> <4D67A8FE.3050806@ericsson.com> Subject: Re: [AVTCORE] Editor for WG version of Monitoring Architecture X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 01:38:19 -0000 SGksDQpUaGFua3MuIEkgYW0gZ2xhZCB0byBoZWxwIG1vdmUgdGhpcyB3b3JrIGZvcndhcmQuDQpU aGUgbmV3IHZlcnNpb24gd2lsbCBiZSByZWFkeSBzb29uIHRvIG1lZXQgdGhlIGRlYWRsaW5lLg0K DQpSZWdhcmRzIQ0KLVFpbg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJN YWdudXMgV2VzdGVybHVuZCIgPG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbT4NClRvOiA8 YXZ0QGlldGYub3JnPjsgPHN1bnNlYXdxQGh1YXdlaS5jb20+DQpTZW50OiBGcmlkYXksIEZlYnJ1 YXJ5IDI1LCAyMDExIDk6MDUgUE0NClN1YmplY3Q6IEVkaXRvciBmb3IgV0cgdmVyc2lvbiBvZiBN b25pdG9yaW5nIEFyY2hpdGVjdHVyZQ0KDQoNCj4gQVZUQ29yZSBhbmQgUWluIFd1DQo+IA0KPiBP bmNlIG1vcmUgdGhhbmtzIHRvIGFsbCB0aGUgcGVvcGxlIHRoYXQgdm9sdW50ZWVyZWQgZm9yIHRo ZSByb2xlIGFzDQo+IGVkaXRvciBvZiB0aGUgV0cgaS1kIGZvciB0aGUgUlRQIG1vbml0b3Jpbmcg YXJjaGl0ZWN0dXJlLg0KPiANCj4gV2UgaGF2ZSBwaWNrZWQgUWluIFd1IGFzIGVkaXRvci4gU29y cnkgZm9yIHRoZSBsYXRlIGRlY2lzaW9uLiBJIGRvIGhvcGUNCj4gdGhhdCB5b3Ugd2lsbCBiZSBh YmxlIHRvIHN1Ym1pdCBhIG5ldyB2ZXJzaW9uIGJlZm9yZSB0aGUgZGVhZGxpbmUuDQo+IA0KPiBS ZWdhcmRzDQo+IA0KPiBNYWdudXMgV2VzdGVybHVuZA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBN dWx0aW1lZGlhIFRlY2hub2xvZ2llcywgRXJpY3Nzb24gUmVzZWFyY2ggRUFCL1RWTQ0KPiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+IEVyaWNzc29uIEFCICAgICAgICAgICAgICAgIHwgUGhvbmUgICs0NiAxMCA3 MTQ4Mjg3DQo+IEbkcvZnYXRhbiA2ICAgICAgICAgICAgICAgIHwgTW9iaWxlICs0NiA3MyAwOTQ5 MDc5DQo+IFNFLTE2NCA4MCBTdG9ja2hvbG0sIFN3ZWRlbnwgbWFpbHRvOiBtYWdudXMud2VzdGVy bHVuZEBlcmljc3Nvbi5jb20NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ==