From fluffy@cisco.com  Fri May  1 05:39:19 2009
Return-Path: <fluffy@cisco.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F6E528C50D; Fri,  1 May 2009 05:39:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.593
X-Spam-Level: 
X-Spam-Status: No, score=-106.593 tagged_above=-999 required=5 tests=[AWL=0.006, 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 gmlkDiF9kniT; Fri,  1 May 2009 05:39:18 -0700 (PDT)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 5D3A328CD42; Fri,  1 May 2009 05:21:54 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.40,277,1238976000"; d="scan'208";a="160950704"
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 01 May 2009 12:23:18 +0000
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n41CNI9u014662;  Fri, 1 May 2009 05:23:18 -0700
Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n41CNHml020189; Fri, 1 May 2009 12:23:17 GMT
From: Cullen Jennings <fluffy@cisco.com>
To: "Elwell, John" <john.elwell@siemens-enterprise.com>
In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001D4B064@GBNTHT12009MSX.gb002.siemens.net>
Impp: xmpp:cullenfluffyjennings@jabber.org
References: <49F864E8.20005@alcatel-lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D001D4B064@GBNTHT12009MSX.gb002.siemens.net>
Message-Id: <217DAD6D-52BF-4E85-8BD3-6024C570B5D5@cisco.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Fri, 1 May 2009 06:23:16 -0600
X-Mailer: Apple Mail (2.930.3)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=263; t=1241180598; x=1242044598; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20<fluffy@cisco.com> |Subject:=20Re=3A=20[dispatch]=20[Sipping]=20SIP-CLF=3A=20R esults=20on=20ASCII=20vs.=20binary=20representation |Sender:=20; bh=XSjDlbWIOima53lP/CuYgFw8tzwFc+10x9hH7Z6f7eo=; b=OJcgP/aiFXIXrl1MNpZrqsgRP3U3DWiNPUr2ALLcJcqB0okhR0GE7xOE+Y YMmeO+q2U2S9dYMt9iq510up0E1YdfvyXPK7whVGRivAVsH4hFEPoC9/S0Cc 1JP+Kw48xG;
Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); 
Cc: dispatch@ietf.org
Subject: Re: [dispatch] [Sipping] SIP-CLF: Results on ASCII vs. binary representation
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 May 2009 12:39:19 -0000

On Apr 29, 2009, at 1:34 PM, Elwell, John wrote:

> p.s. which list - DISPATCH or SIP-OPS?

Folks, please use DISPATCH for this for now.

Thanks,
Cullen <in my RAI AD role>

ANd in gneraly, please, don't cross post whole threads if at all  
posible.


From dean.willis@softarmor.com  Fri May  1 06:27:49 2009
Return-Path: <dean.willis@softarmor.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 564323A67FF for <dispatch@core3.amsl.com>; Fri,  1 May 2009 06:27:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.555
X-Spam-Level: 
X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044,  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 4JGfFNSl+aCe for <dispatch@core3.amsl.com>; Fri,  1 May 2009 06:27:48 -0700 (PDT)
Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 471393A691C for <dispatch@ietf.org>; Fri,  1 May 2009 06:27:48 -0700 (PDT)
Received: from [192.168.2.103] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n41DT867032160 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 1 May 2009 08:29:09 -0500
Message-Id: <8CF72A4C-BAFE-445A-A308-864CEA26FEAA@softarmor.com>
From: Dean Willis <dean.willis@softarmor.com>
To: Cullen Jennings <fluffy@cisco.com>
In-Reply-To: <217DAD6D-52BF-4E85-8BD3-6024C570B5D5@cisco.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Fri, 1 May 2009 08:29:03 -0500
References: <49F864E8.20005@alcatel-lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D001D4B064@GBNTHT12009MSX.gb002.siemens.net> <217DAD6D-52BF-4E85-8BD3-6024C570B5D5@cisco.com>
X-Mailer: Apple Mail (2.930.3)
Cc: dispatch@ietf.org
Subject: Re: [dispatch] [Sipping] SIP-CLF: Results on ASCII vs. binary representation
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 May 2009 13:27:49 -0000

On May 1, 2009, at 7:23 AM, Cullen Jennings wrote:

>
> On Apr 29, 2009, at 1:34 PM, Elwell, John wrote:
>
>> p.s. which list - DISPATCH or SIP-OPS?
>
> Folks, please use DISPATCH for this for now.
>
> Thanks,
> Cullen <in my RAI AD role>
>

This isn't SIPPING.

Why are we having a technical conversation about defining a log format  
on the DISPATCH list?

Shouldn't the conversation here be about where to do the work and  
whether or not a new working group is needed to do that work?

It seems to me that a technical conversation belongs either on a WG  
list or perhaps on the sip-ops list.

--
Dean



From eburger@standardstrack.com  Fri May  1 06:48:38 2009
Return-Path: <eburger@standardstrack.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBB2128C1A3 for <dispatch@core3.amsl.com>; Fri,  1 May 2009 06:48:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.385
X-Spam-Level: 
X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[AWL=0.214,  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 7m+pPjW7Aefn for <dispatch@core3.amsl.com>; Fri,  1 May 2009 06:48:37 -0700 (PDT)
Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id DBCAC28C1C1 for <dispatch@ietf.org>; Fri,  1 May 2009 06:46:52 -0700 (PDT)
Received: from c-75-68-112-157.hsd1.nh.comcast.net ([75.68.112.157] helo=[192.168.45.103]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from <eburger@standardstrack.com>) id 1Lzt64-00033O-1w for dispatch@ietf.org; Fri, 01 May 2009 06:48:12 -0700
Message-Id: <AF689C4E-9D79-4C82-87D5-7623D7A08007@standardstrack.com>
From: Eric Burger <eburger@standardstrack.com>
To: dispatch@ietf.org
Content-Type: multipart/signed; boundary=Apple-Mail-272-885488235; micalg=sha1; protocol="application/pkcs7-signature"
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Fri, 1 May 2009 09:48:13 -0400
X-Mailer: Apple Mail (2.930.3)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Subject: [dispatch] SIP-CLF: text versus binary
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 May 2009 13:48:38 -0000

--Apple-Mail-272-885488235
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

I would humbly offer that the number of iterations it took for Theo  
(super awesome coder), Adam (truly awesome coder), and Vijay (above  
average coder) to get a half decent binary implementation of a CLF  
writer and reader highlights the argument for a text-based LOG file.   
Imagine what an average coder would do.

Binary file formats are not easy. SIP-CLF is trivial and it is not easy.


Questions for people to consider:

Why isn't SIP in a binary format? It would be much easier to generate  
and parse the message, and the message would be smaller.

Why is H.248 a text protocol in the wild, even though the binary  
format had tons of intellectual effort poured into it?

Why are SNMP MIBs a black art, years after their introduction?
--Apple-Mail-272-885488235
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGPTCCBjkw
ggUhoAMCAQICEC+VK1RLWxrF8KJZDR9k8p8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVT
MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS
VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQD
Ey1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwODEz
MDAwMDAwWhcNMDkwODEzMjM1OTU5WjCB4TE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsg
LSBQRVJTT05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9m
IHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMg
Q29tb2RvIExpbWl0ZWQxFDASBgNVBAMTC0VyaWMgQnVyZ2VyMSkwJwYJKoZIhvcNAQkBFhplYnVy
Z2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMTF
RRoA4LgOACMFph0aomRC/UpqoA5C/d6DUTOvTMrYSEqkjwnU4zxDtBcHlcB4AxKAov00MYsUvEU4
loz7BHjfDjv76AIkcwu33VYQbzGmarVnyaXsVb6f/cyRL3fPT0VOVO2tQAEEgwg//CX0jN8Kn2jH
uXD/HEvko7cmpL3Pwevf3+DwB61v7ca79PpEZfn/WhaqRKA4uVNPj/JbieeaLo2v/0RJzrEElZK0
pHCqxiD3mQ8ossPkA9fUCSxLlbdMcPU3be5x8vt8Q8mYTXF5Z3d9RZmYrmNkvTQtdzVpfYWr/hgV
Xqm9tByOOAR+hoN3FKbubR/OrAHL9yDAd4sCAwEAAaOCAhwwggIYMB8GA1UdIwQYMBaAFImCZ33E
nSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRDWgutb7b8R/L7G3Y3D+molAA3VzAOBgNVHQ8BAf8E
BAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJ
YIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEW
HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6
Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRF
bWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVu
dEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYq
aHR0cDovL2NydC5jb21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhho
dHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJQYDVR0RBB4wHIEaZWJ1cmdlckBzdGFuZGFyZHN0cmFj
ay5jb20wDQYJKoZIhvcNAQEFBQADggEBAGeBR7NPCvrY3GQoIi49JOuciatY2r4st905Jw1etp6J
umFFWlaCBl11tFSclk/3S45B+lUv3SEvG4CEjUByPScprVmCqHR+y8BAQaB/CV+N1y14x3MbhJ+Z
8XDGKeUXuuyGd9w0l3/t/QPid6TRXQjQFrLPFs1IALuNpNiFMHEF/xFbMG1Z2vznR/gSPlePekoZ
TqcExIDBNZTBebpZqwAXzPpedNNOclbMLFLWDMOAozVRpkfjI0eiFsk8SF1Ho1Gb9Bx8DeG4peE2
KRVOR9FFnZZgBpFjXYRcglsMOSKCY8HgE+NGvbbqbrMoBV/BlYyxRXwfti71RL9Zs2Cq1eQxggP8
MIID+AIBATCBwzCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh
a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v
d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp
Y2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkNH2TynzAJBgUrDgMCGgUAoIICDTAYBgkqhkiG
9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA1MDExMzQ4MTNaMCMGCSqGSIb3
DQEJBDEWBBRsq9/FTBMpeWMxH7rjRM2QzRN/tzCB1AYJKwYBBAGCNxAEMYHGMIHDMIGuMQswCQYD
VQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVU
aGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2
MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhAv
lStUS1saxfCiWQ0fZPKfMIHWBgsqhkiG9w0BCRACCzGBxqCBwzCBrjELMAkGA1UEBhMCVVMxCzAJ
BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT
VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU
Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkN
H2TynzANBgkqhkiG9w0BAQEFAASCAQANmsVo02TCBjMO1EsUYDaAsJiuBgi/Ql8jgiwmRBrIGX0Y
HgNilMafy1ImA7efo+13FR7Wwo2Um7E7ByRHP1UvoS3RyPv7kmWHVRkt4Zc7CmPHvWzByKqpzWXZ
dlaoKGXW+/i4UNObqVzJ0TzfnVc0jrdrW5UY5iyPsSt55dShsFbMzvWQ6nuHm6L7H58eCiHm36o8
7MsWeuwTV5Pqh95/TuSLTUcpYT10c/K3z2gnQjORmNiEhiASJocc55K13/i+5Fm7gfRoedAyiX7D
schb+C1x9Noso5R2rngmUsXETbUOmXgmIx4JcywtYUGQsKyZiEphrVSU4U96cwo05A2mAAAAAAAA

--Apple-Mail-272-885488235--

From simon.perreault@viagenie.ca  Fri May  1 06:59:20 2009
Return-Path: <simon.perreault@viagenie.ca>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85EC428C198 for <dispatch@core3.amsl.com>; Fri,  1 May 2009 06:59:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.289
X-Spam-Level: 
X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.311,  BAYES_00=-2.599, NO_RELAYS=-0.001]
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 RrHGjMmar+gJ for <dispatch@core3.amsl.com>; Fri,  1 May 2009 06:59:19 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 7769628C18B for <dispatch@ietf.org>; Fri,  1 May 2009 06:59:19 -0700 (PDT)
Received: by jazz.viagenie.ca (Postfix, from userid 8) id DF1BB29E159F; Fri,  1 May 2009 10:00:42 -0400 (EDT)
Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTP id CE91E29E1598; Fri,  1 May 2009 10:00:42 -0400 (EDT)
Message-ID: <49FB008A.1090006@viagenie.ca>
Date: Fri, 01 May 2009 10:00:42 -0400
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Thunderbird 2.0.0.21 (X11/20090320)
MIME-Version: 1.0
To: Eric Burger <eburger@standardstrack.com>
References: <AF689C4E-9D79-4C82-87D5-7623D7A08007@standardstrack.com>
In-Reply-To: <AF689C4E-9D79-4C82-87D5-7623D7A08007@standardstrack.com>
X-Enigmail-Version: 0.95.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: dispatch@ietf.org
Subject: Re: [dispatch] SIP-CLF: text versus binary
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 May 2009 13:59:20 -0000

Eric Burger wrote, on 01/05/09 09:48 AM:
> Why isn't SIP in a binary format? It would be much easier to generate
> and parse the message, and the message would be smaller.
> 
> Why is H.248 a text protocol in the wild, even though the binary format
> had tons of intellectual effort poured into it?
> 
> Why are SNMP MIBs a black art, years after their introduction?

This is exactly what I meant by "speed is not an issue".

- File size is similar.
- Output speed is similar.
- Input speed is inconclusive (I guess it would tend toward similar with more
effort.)

The real issue is: ease of use, flexibility, "greppability", etc. This all
points toward the text format.

By the way, there is a wide body of knowledge with HTTP log formats, which are
not standardized but very many people use the Apache format. This means there is
code, tools, libraries, etc. that can be reused. This is a solved problem.
Experience has shown that text log formats work.

Simon (forgotten coder)
-- 
STUN/TURN server    --> http://numb.viagenie.ca
Interplanetary news --> http://reeves.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org

From BPenfield@acmepacket.com  Fri May  1 07:10:49 2009
Return-Path: <BPenfield@acmepacket.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 934F328C193 for <dispatch@core3.amsl.com>; Fri,  1 May 2009 07:10:49 -0700 (PDT)
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.000,  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 x696WeJoFX9J for <dispatch@core3.amsl.com>; Fri,  1 May 2009 07:10:48 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 8E72228C187 for <dispatch@ietf.org>; Fri,  1 May 2009 07:10:48 -0700 (PDT)
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Fri, 1 May 2009 10:12:11 -0400
Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 1 May 2009 10:12:11 -0400
From: Bob Penfield <BPenfield@acmepacket.com>
To: Eric Burger <eburger@standardstrack.com>, "dispatch@ietf.org" <dispatch@ietf.org>
Date: Fri, 1 May 2009 10:12:09 -0400
Thread-Topic: [dispatch] SIP-CLF: text versus binary
Thread-Index: AcnKY8Jb1Axkcq82Sbu73TewfM/jtAAAtRdA
Message-ID: <E6C2E8958BA59A4FB960963D475F7AC319161DE50E@mail>
References: <AF689C4E-9D79-4C82-87D5-7623D7A08007@standardstrack.com>
In-Reply-To: <AF689C4E-9D79-4C82-87D5-7623D7A08007@standardstrack.com>
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
Subject: Re: [dispatch] SIP-CLF: text versus binary
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 May 2009 14:10:49 -0000

We could eliminate the implementation issues by including the code in the R=
FC.

I personally prefer the binary format.

Cheers,
(-:bob=20

-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal=
f Of Eric Burger
Sent: Friday, May 01, 2009 9:48 AM
To: dispatch@ietf.org
Subject: [dispatch] SIP-CLF: text versus binary

I would humbly offer that the number of iterations it took for Theo =20
(super awesome coder), Adam (truly awesome coder), and Vijay (above =20
average coder) to get a half decent binary implementation of a CLF =20
writer and reader highlights the argument for a text-based LOG file.  =20
Imagine what an average coder would do.

Binary file formats are not easy. SIP-CLF is trivial and it is not easy.


Questions for people to consider:

Why isn't SIP in a binary format? It would be much easier to generate =20
and parse the message, and the message would be smaller.

Why is H.248 a text protocol in the wild, even though the binary =20
format had tons of intellectual effort poured into it?

Why are SNMP MIBs a black art, years after their introduction?=

From pkyzivat@cisco.com  Fri May  1 07:58:25 2009
Return-Path: <pkyzivat@cisco.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29DDD3A7232 for <dispatch@core3.amsl.com>; Fri,  1 May 2009 07:58:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.115
X-Spam-Level: 
X-Spam-Status: No, score=-6.115 tagged_above=-999 required=5 tests=[AWL=0.484,  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 H5mcbtCvRf19 for <dispatch@core3.amsl.com>; Fri,  1 May 2009 07:58:24 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 093F53A706A for <dispatch@ietf.org>; Fri,  1 May 2009 07:57:42 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.40,278,1238976000"; d="scan'208";a="179598000"
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 01 May 2009 14:59:05 +0000
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n41Ex5wf022365;  Fri, 1 May 2009 07:59:05 -0700
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n41Ex4iW000227; Fri, 1 May 2009 14:59:05 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Fri, 1 May 2009 10:58:59 -0400
Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Fri, 1 May 2009 10:58:59 -0400
Message-ID: <49FB0E2C.8040907@cisco.com>
Date: Fri, 01 May 2009 10:58:52 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Eric Burger <eburger@standardstrack.com>
References: <AF689C4E-9D79-4C82-87D5-7623D7A08007@standardstrack.com>
In-Reply-To: <AF689C4E-9D79-4C82-87D5-7623D7A08007@standardstrack.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 01 May 2009 14:58:59.0038 (UTC) FILETIME=[5B6547E0:01C9CA6D]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2306; t=1241189945; x=1242053945; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20<pkyzivat@cisco.com> |Subject:=20Re=3A=20[dispatch]=20SIP-CLF=3A=20text=20versus =20binary |Sender:=20; bh=egiyKFDewtE3ogZ2ZZ0ax8/xexjebju+fAEVGbCxhX8=; b=vOaHCahc2Wdv5P0VrYNt+zQwNJUAwKZVriVVmFi75GiN+cfRwaZBjA14NS 56RkeRKku7qulRPdFB5sSbsQDPqgmxU2oGYFD5OU/o3yMDs4YTyWaiIgFCcj Xr/9+/GhS2;
Authentication-Results: sj-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); 
Cc: dispatch@ietf.org
Subject: Re: [dispatch] SIP-CLF: text versus binary
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 May 2009 14:58:25 -0000

Eric,

I have pondered the questions you raise for many years, and I still 
don't know. I *think* it is mostly a matter of easing the learning curve 
to get started on something. Once you have worked on it for awhile, you 
have a set of tools, and whether the underlying representation is text 
or binary is the least of concerns. But for those first few weeks before 
you have figured out what tools you need and obtained or built them, a 
text rep is very helpful.

An interesting case study is print formats. A *long* time ago Xerox had 
a binary print representation, called InterPress. It was proprietary and 
not very approachable. Some people left Xerox, formed Adobe, and 
produced a text print format (PostScript), which for some reason was 
vastly more popular. Does it matter that postscript is text rather than 
binary? Probably not in practice, but somehow it did matter. (Or course 
now ps has been pretty much subsumed into pdf, which I think is a binary 
format.)

So, for reasons I still don't fully fathom, I agree with you that its 
probably important to have a text rep as the primary one, even if it is 
suboptimal, and if there is also a binary format people probably won't 
implement it.

	Thanks,
	Paul

Eric Burger wrote:
> I would humbly offer that the number of iterations it took for Theo 
> (super awesome coder), Adam (truly awesome coder), and Vijay (above 
> average coder) to get a half decent binary implementation of a CLF 
> writer and reader highlights the argument for a text-based LOG file.  
> Imagine what an average coder would do.
> 
> Binary file formats are not easy. SIP-CLF is trivial and it is not easy.
> 
> 
> Questions for people to consider:
> 
> Why isn't SIP in a binary format? It would be much easier to generate 
> and parse the message, and the message would be smaller.
> 
> Why is H.248 a text protocol in the wild, even though the binary format 
> had tons of intellectual effort poured into it?
> 
> Why are SNMP MIBs a black art, years after their introduction?
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

From adam@nostrum.com  Fri May  1 08:22:01 2009
Return-Path: <adam@nostrum.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8E863A708B for <dispatch@core3.amsl.com>; Fri,  1 May 2009 08:22:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.562
X-Spam-Level: 
X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038,  BAYES_00=-2.599, SPF_PASS=-0.001]
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 Ee7pcLuv1jwp for <dispatch@core3.amsl.com>; Fri,  1 May 2009 08:21:59 -0700 (PDT)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 2F2C33A6FA9 for <dispatch@ietf.org>; Fri,  1 May 2009 08:21:58 -0700 (PDT)
Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n41FNK50023379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 May 2009 10:23:21 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <49FB13E8.2070108@nostrum.com>
Date: Fri, 01 May 2009 10:23:20 -0500
From: Adam Roach <adam@nostrum.com>
User-Agent: Postbox 1.0b11 (Macintosh/2009041623)
MIME-Version: 1.0
To: Eric Burger <eburger@standardstrack.com>
References: <AF689C4E-9D79-4C82-87D5-7623D7A08007@standardstrack.com>
In-Reply-To: <AF689C4E-9D79-4C82-87D5-7623D7A08007@standardstrack.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism)
Cc: dispatch@ietf.org
Subject: Re: [dispatch] SIP-CLF: text versus binary
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 May 2009 15:22:01 -0000

Eric Burger wrote:
> I would humbly offer that the number of iterations it took for Theo
> (super awesome coder), Adam (truly awesome coder), and Vijay (above
> average coder) to get a half decent binary implementation of a CLF
> writer and reader highlights the argument for a text-based LOG file.

Vijay's initial implementation was pretty much spot-on, with one easily 
fixed exception. Improvements past that point were pretty much 
incremental, minor, and inconsequential in the grand order of things 
(except for Theo's last change, which is really just Theo working some 
deep voodoo magic that would apply equally to text and binary).

In either case, the speed of processing one versus the other stands at 
5x to 10x by any reasonable metric.

> Imagine what an average coder would do.

Any coder sufficiently competent to get a SIP parser even halfway right 
should be able to code this in their sleep.


Bob Penfield wrote:
 > We could eliminate the implementation issues by including the code in 
 > the RFC.

I like that idea. I'll adapt my perl script to a library and add it as 
an appendix to the next version of the binary CLF document (presuming 
there's any reason to produce a "next version").

/a

From scott.lawrence@nortel.com  Fri May  1 12:13:15 2009
Return-Path: <scott.lawrence@nortel.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9099228C25A for <dispatch@core3.amsl.com>; Fri,  1 May 2009 12:13:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.803
X-Spam-Level: 
X-Spam-Status: No, score=-5.803 tagged_above=-999 required=5 tests=[AWL=0.796,  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 fNLNQSWX0piR for <dispatch@core3.amsl.com>; Fri,  1 May 2009 12:13:14 -0700 (PDT)
Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 713B43A727A for <dispatch@ietf.org>; Fri,  1 May 2009 12:12:36 -0700 (PDT)
Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n41JDu711657 for <dispatch@ietf.org>; Fri, 1 May 2009 19:13:56 GMT
Received: from [127.0.0.1] ([47.17.25.99]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 1 May 2009 15:13:41 -0400
From: "Scott Lawrence" <scott.lawrence@nortel.com>
To: "Vijay K. Gurbani" <vkg@alcatel-lucent.com>
In-Reply-To: <49F8CA90.3000508@alcatel-lucent.com>
References: <49F864E8.20005@alcatel-lucent.com> <167dfb9b0904290847u322161d5h3da18771344436ec@mail.gmail.com> <49F8988C.9050900@alcatel-lucent.com> <167dfb9b0904291203m4e74ab39s5f83cfa1be9799a0@mail.gmail.com> <49F8B827.3060501@alcatel-lucent.com> <E6C2E8958BA59A4FB960963D475F7AC31915E3E5B1@mail> <49F8CA90.3000508@alcatel-lucent.com>
Content-Type: text/plain
Organization: Nortel Networks
Date: Fri, 01 May 2009 15:13:40 -0400
Message-Id: <1241205220.3646.42.camel@scott>
Mime-Version: 1.0
X-Mailer: Evolution 2.24.5 (2.24.5-1.fc10) 
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 01 May 2009 19:13:41.0447 (UTC) FILETIME=[F06BD570:01C9CA90]
Cc: "dispatch@ietf.org" <dispatch@ietf.org>
Subject: Re: [dispatch] SIP-CLF: Results on ASCII vs. binary representation
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 May 2009 19:13:15 -0000

> Hadriel Kaplan wrote:
> > Depends on how you plan to disambiguate legal characters in the
> > fields from the field separators...

On Wed, 2009-04-29 at 16:45 -0500, Vijay K. Gurbani wrote:

> Right; this is a nagging problem at the back of my head ever
> since Dale pointed it out.  The least impacting way to deal
> with this, I believe, will be not to save display-name type
> of constructs but only addr-spec for URIs.  The generic-param
> construct is another potential problem.  Spaces in it need
> to be escaped or generic-param could be simply unallowed. 

> > But anyway, I think the real question that needs to be answered
> > *first* is "what is the purpose of the CLF?"  What is it going to
> > help admins do?  Is it for troubleshooting, or for registration audit
> > logging, or for IDS systems, etc?
> 
>  From the list above, at least for troubleshooting, logging, and
> IDS systems.  What I do not envision CLF being used for is
> debugging (distinct from troubleshooting) and CDR.

If you're going to include troubleshooting in the list of purposes, then
removing anything from the name-addr fields, or any generic-param is
going to be problematic.  I know you couldn't debug some configurations
on my system if you'd stripped some of the proprietary parameters we
use.



From tom.taylor@rogers.com  Fri May  1 12:13:57 2009
Return-Path: <tom.taylor@rogers.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 274A33A6B1E for <dispatch@core3.amsl.com>; Fri,  1 May 2009 12:13:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level: 
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[AWL=-0.607, BAYES_20=-0.74]
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 Hy3xl4WHW-uF for <dispatch@core3.amsl.com>; Fri,  1 May 2009 12:13:56 -0700 (PDT)
Received: from smtp125.rog.mail.re2.yahoo.com (smtp125.rog.mail.re2.yahoo.com [206.190.53.30]) by core3.amsl.com (Postfix) with SMTP id E77BA3A691D for <dispatch@ietf.org>; Fri,  1 May 2009 12:13:55 -0700 (PDT)
Received: (qmail 53917 invoked from network); 1 May 2009 19:15:19 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=s+faBvk31rUxZqh9/NGSgoBIE5/0Dz7vMRxmG/vmY6sPfYPnaxz1tQAoi+0cxTwygmQYDa2AgGjRZVwX1/m+Irf83Ikuu61C7JKO+omwAMHr/tR70VXYdY6MPWC1tpzv6cbStD9BYhk2lRdbWE8dODDLqin9FQoDOQ7Tjp6y62g= ; 
Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@72.140.46.24 with plain) by smtp125.rog.mail.re2.yahoo.com with SMTP; 1 May 2009 19:15:19 -0000
X-YMail-OSG: kS5JklUVM1nOmhJIqpCZHROo5Jv0n_2nMzyyeLWNvUoeuAn8y9pG9jScXh_eq8mbFA--
X-Yahoo-Newman-Property: ymail-3
Message-ID: <49FB4A4B.1060007@rogers.com>
Date: Fri, 01 May 2009 15:15:23 -0400
From: Tom Taylor <tom.taylor@rogers.com>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Eric Burger <eburger@standardstrack.com>
References: <AF689C4E-9D79-4C82-87D5-7623D7A08007@standardstrack.com>
In-Reply-To: <AF689C4E-9D79-4C82-87D5-7623D7A08007@standardstrack.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: dispatch@ietf.org
Subject: Re: [dispatch] SIP-CLF: text versus binary
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 May 2009 19:13:57 -0000

Just for fun, I'll remind you all that we tried to decide the H.248 text vs. 
binary question by the flip of a coin. The coin came up "text" while the H.248 
rapporteur sat there with his jaw touching the floor, but then Pete Cordell came 
up with the idea of text-encoded ASN.1 and that kept the issue alive. It turned 
out the real reason the binary wouldn't die was that some people wanted to carry 
it in ISUP (BICC, actually).

Tom Taylor

Eric Burger wrote:
...
> 
> Why is H.248 a text protocol in the wild, even though the binary format 
> had tons of intellectual effort poured into it?
> 


From vkg@alcatel-lucent.com  Fri May  1 12:58:47 2009
Return-Path: <vkg@alcatel-lucent.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D0963A6D5E for <dispatch@core3.amsl.com>; Fri,  1 May 2009 12:58:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.527
X-Spam-Level: 
X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072,  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 nQwZFlcmTf2e for <dispatch@core3.amsl.com>; Fri,  1 May 2009 12:58:46 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 495E13A6C51 for <dispatch@ietf.org>; Fri,  1 May 2009 12:58:46 -0700 (PDT)
Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id n41K03kX029329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 May 2009 15:00:03 -0500 (CDT)
Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id n41K01wA021228; Fri, 1 May 2009 15:00:02 -0500 (CDT)
Message-ID: <49FB54C1.30206@alcatel-lucent.com>
Date: Fri, 01 May 2009 15:00:01 -0500
From: "Vijay K. Gurbani" <vkg@alcatel-lucent.com>
Organization: Bell Labs Security Technology Research Group
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "dispatch@ietf.org" <dispatch@ietf.org>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020305000106060501080703"
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
Subject: [dispatch] Next steps on SIP-CLF
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 May 2009 19:58:47 -0000

This is a cryptographically signed message in MIME format.

--------------ms020305000106060501080703
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Given that there is enough interest in the topic of SIP-CLF
and enough passionate people to support both sides of the
argument on binary vs. ASCII, we might as well start thinking
of a place to get the work done.

Following dispatch's role, maybe we should think how to form
a place to get this work done, i.e., forming a BoF or EG or
directing the work to an existing WG.  To that extent, if
anyone wants to help put a concrete proposal together for
SIP CLF work, I will be more than happy to work with them to
define problem statement and proposal for new work.  We could
do that part in dispatch, I believe.

Regarding dealing with the technical aspects of the work, we
could start a new IETF mailing list so that the technical
discussions happen on that list and the process discussions
can continue on dispatch.

ADs: please advise if this is appropriate.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/

--------------ms020305000106060501080703
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJaTCC
Aw8wggJ4oAMCAQICEBxfFIlb7CTCWch269C0f2gwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDIxMTE1MDAwMFoX
DTEwMDIxMTE1MDAwMFowZDEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEaMBgG
CSqGSIb3DQEJARYLdmtnQGFjbS5vcmcxJTAjBgkqhkiG9w0BCQEWFnZrZ0BhbGNhdGVsLWx1
Y2VudC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCf/d52MpS/tDZTVOfu
GpXkWqPJKMnb6C47jwMh7ijnRqRIi/Zvr3OqUar4/s5dYokPpWCzFlVaiYt58o3/kimzy1Cd
DatGfoC3wgJUQkw2LHTnxNVn8HxZh4MrVgmtv1D1K/L++0Zt54pjgve3Rfr95opITylqcAzQ
j4HeiF2ZBUiqr7suHsSFvI5lg+odvhwQgCnET8PHxbxjjyX2tvWYP/vU9W0Lf9E/ZbY6zVIk
+HcNm2lESUEcSuV82BVDgWH7QiExzsGKjEkMmmYE0KliJNxcSL8NQxzbBtoZs9itgi0nqd3w
oEbIjouPZlptIVWYsnOTgxOAavhHEqjdXYQrAgMBAAGjQDA+MC4GA1UdEQQnMCWBC3ZrZ0Bh
Y20ub3JngRZ2a2dAYWxjYXRlbC1sdWNlbnQuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcN
AQEFBQADgYEAxKKod4FEhIbMwZQJcKagYk2TeYHVMmZBtNG3ld6pUuh0BmSfgVrgU0c5TZ+v
FhvmQ+sfmvrVRKbN6p2HMmDG82VAecylQplvhwAql6UgRV1+uFW+IttYjmcuT8wzlWF3PPJZ
IWGjytwUUrAjmjZ+W2OzOIoF5hADbXQ36wLUNQwwggMPMIICeKADAgECAhAcXxSJW+wkwlnI
duvQtH9oMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUg
Q29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h
aWwgSXNzdWluZyBDQTAeFw0wOTAyMTExNTAwMDBaFw0xMDAyMTExNTAwMDBaMGQxHzAdBgNV
BAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxGjAYBgkqhkiG9w0BCQEWC3ZrZ0BhY20ub3Jn
MSUwIwYJKoZIhvcNAQkBFhZ2a2dAYWxjYXRlbC1sdWNlbnQuY29tMIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAn/3edjKUv7Q2U1Tn7hqV5FqjySjJ2+guO48DIe4o50akSIv2
b69zqlGq+P7OXWKJD6VgsxZVWomLefKN/5Ips8tQnQ2rRn6At8ICVEJMNix058TVZ/B8WYeD
K1YJrb9Q9Svy/vtGbeeKY4L3t0X6/eaKSE8panAM0I+B3ohdmQVIqq+7Lh7EhbyOZYPqHb4c
EIApxE/Dx8W8Y48l9rb1mD/71PVtC3/RP2W2Os1SJPh3DZtpRElBHErlfNgVQ4Fh+0IhMc7B
ioxJDJpmBNCpYiTcXEi/DUMc2wbaGbPYrYItJ6nd8KBGyI6Lj2ZabSFVmLJzk4MTgGr4RxKo
3V2EKwIDAQABo0AwPjAuBgNVHREEJzAlgQt2a2dAYWNtLm9yZ4EWdmtnQGFsY2F0ZWwtbHVj
ZW50LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAMSiqHeBRISGzMGUCXCm
oGJNk3mB1TJmQbTRt5XeqVLodAZkn4Fa4FNHOU2frxYb5kPrH5r61USmzeqdhzJgxvNlQHnM
pUKZb4cAKpelIEVdfrhVviLbWI5nLk/MM5VhdzzyWSFho8rcFFKwI5o2fltjsziKBeYQA210
N+sC1DUMMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkEx
FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFU
aGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZp
c2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcN
AQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEz
MDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n
IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n
IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/
ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2
JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wID
AQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDov
L2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQD
AgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG
9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAg
k3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghO
rvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEBMHYwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAcXxSJW+wkwlnIduvQtH9o
MAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF
MQ8XDTA5MDUwMTIwMDAwMVowIwYJKoZIhvcNAQkEMRYEFLN4tVhbmdpHub50G7w78wOZSAwO
MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3
DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJ
BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD
VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQHF8UiVvsJMJZyHbr
0LR/aDCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3
dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl
ZW1haWwgSXNzdWluZyBDQQIQHF8UiVvsJMJZyHbr0LR/aDANBgkqhkiG9w0BAQEFAASCAQCe
7xdaQghLSucFNyd+C6avubHByhUxRRL66IAmHFoH7idOSBSALhWGqEwdL4ob7UN43o3fCCGk
cfwaOLSsmfHuzeUppm1323kJCo6N4ajnYnrq39KnRAHbdtSdMrB1Rkm2wK36vJRMyNwKHpzU
HRkBGD8acwtwbpqgEpWfx3HNFnNx/o3Y2iQjSoQ4t5+FPg3EJT+9L13PlUB8OLbsejuH1a8P
TcLcDE7gCw688labzmQrC4Oy8/ERBnpzMfGl8lY/E79z/x27fmH+B15mXOyyMVSj85FjUPa6
ewUX/DFajdYsTYPhCvAdb18X1N3Vq8e3ZvAleLpFBaiUoveDh3lKAAAAAAAA
--------------ms020305000106060501080703--

From fluffy@cisco.com  Fri May  1 13:14:37 2009
Return-Path: <fluffy@cisco.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A6243A6C26 for <dispatch@core3.amsl.com>; Fri,  1 May 2009 13:14:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.593
X-Spam-Level: 
X-Spam-Status: No, score=-106.593 tagged_above=-999 required=5 tests=[AWL=0.006, 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 4+Wyy0idqnGW for <dispatch@core3.amsl.com>; Fri,  1 May 2009 13:14:36 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 8BD943A6B7A for <dispatch@ietf.org>; Fri,  1 May 2009 13:14:36 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.40,280,1238976000"; d="scan'208";a="179754362"
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 01 May 2009 20:15:59 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n41KFxrP001132;  Fri, 1 May 2009 13:15:59 -0700
Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n41KFwqN002865; Fri, 1 May 2009 20:15:58 GMT
From: Cullen Jennings <fluffy@cisco.com>
To: "Vijay K. Gurbani" <vkg@alcatel-lucent.com>
In-Reply-To: <49FB54C1.30206@alcatel-lucent.com>
Impp: xmpp:cullenfluffyjennings@jabber.org
References: <49FB54C1.30206@alcatel-lucent.com>
Message-Id: <91F97501-F0C9-45DC-A48F-38F0EE362FF0@cisco.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Fri, 1 May 2009 14:15:57 -0600
X-Mailer: Apple Mail (2.930.3)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1205; t=1241208959; x=1242072959; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20<fluffy@cisco.com> |Subject:=20Re=3A=20Next=20steps=20on=20SIP-CLF |Sender:=20; bh=dPWA8VTcuCBQrZqymguYZrDg9h21T5hmXc0YRuHsEp8=; b=ZVdSIBrQXu+1AH/CklpgLVXDzIkuxrtiZgbqR/lLGxnnBaql+NA5y6Zz6z /K0Lf1Hn6cxd66e31gjPvD1MIguk8GDtioiSY3LU2bVV0VbxIUhMGTRjTl18 jMihsQcxQg;
Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); 
Cc: "dispatch@ietf.org" <dispatch@ietf.org>
Subject: Re: [dispatch] Next steps on SIP-CLF
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 May 2009 20:14:37 -0000

On May 1, 2009, at 2:00 PM, Vijay K. Gurbani wrote:

> Given that there is enough interest in the topic of SIP-CLF
> and enough passionate people to support both sides of the
> argument on binary vs. ASCII, we might as well start thinking
> of a place to get the work done.
>
> Following dispatch's role, maybe we should think how to form
> a place to get this work done, i.e., forming a BoF or EG or
> directing the work to an existing WG.  To that extent, if
> anyone wants to help put a concrete proposal together for
> SIP CLF work, I will be more than happy to work with them to
> define problem statement and proposal for new work.  We could
> do that part in dispatch, I believe.

Sound great - I'd be happy to see this happening.


>
>
> Regarding dealing with the technical aspects of the work, we
> could start a new IETF mailing list so that the technical
> discussions happen on that list and the process discussions
> can continue on dispatch.

Sounds like a reasonable plan. I'm not sure we want to do this for all  
things but I think it sounds like a good experiment to try for this  
one. I'll work with you to get the list set up.

Cullen <in my AD role>


From vkg@alcatel-lucent.com  Fri May  1 13:25:01 2009
Return-Path: <vkg@alcatel-lucent.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23D1F3A6CD3 for <dispatch@core3.amsl.com>; Fri,  1 May 2009 13:25:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.528
X-Spam-Level: 
X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071,  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 2HhjHiVaic-F for <dispatch@core3.amsl.com>; Fri,  1 May 2009 13:25:00 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 229503A6C51 for <dispatch@ietf.org>; Fri,  1 May 2009 13:24:59 -0700 (PDT)
Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id n41KQMEE014193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 May 2009 15:26:22 -0500 (CDT)
Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id n41KQMA3012749; Fri, 1 May 2009 15:26:22 -0500 (CDT)
Message-ID: <49FB5AEE.10109@alcatel-lucent.com>
Date: Fri, 01 May 2009 15:26:22 -0500
From: "Vijay K. Gurbani" <vkg@alcatel-lucent.com>
Organization: Bell Labs Security Technology Research Group
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Adam Roach <adam@nostrum.com>
References: <AF689C4E-9D79-4C82-87D5-7623D7A08007@standardstrack.com> <49FB13E8.2070108@nostrum.com>
In-Reply-To: <49FB13E8.2070108@nostrum.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
Cc: dispatch@ietf.org
Subject: Re: [dispatch] SIP-CLF: text versus binary
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 May 2009 20:25:01 -0000

Adam Roach wrote:
 > Vijay's initial implementation was pretty much spot-on, with one
 > easily fixed exception.

Adam: Thanks, and once again, I take the blame for not paying
enough attention to the binary CLF write function (but that is
the whole reason why I published the source as well -- just in
case I did not account for something egregious.)

 > In either case, the speed of processing one versus the other stands at
 > 5x to 10x by any reasonable metric.

To be sure, you are saying that a perl script finding a certain
record in an ASCII CLF file is about 5x to 10x times slower
than a C program or perl script finding the same record in a
binary CLF file.  If so, yes, that is so.  The writes are
about even, with binary writes taking up a bit less time.

There are other technical discussions that I will like to
continue with you on the merits and demerits of ASCII vs.
binary, but will wait for a short while until we decide to
see how the SIP CLF work progresses in dispatch (hopefully we
can conduct those on a separate technical discussion list.)

Ciao,

- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/

From gonzalo.camarillo@ericsson.com  Fri May  1 14:23:33 2009
Return-Path: <gonzalo.camarillo@ericsson.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EC0528C241 for <dispatch@core3.amsl.com>; Fri,  1 May 2009 14:23:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.394
X-Spam-Level: 
X-Spam-Status: No, score=-5.394 tagged_above=-999 required=5 tests=[AWL=0.855,  BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 zdlnxeeuYflx for <dispatch@core3.amsl.com>; Fri,  1 May 2009 14:23:32 -0700 (PDT)
Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 79A3228C250 for <dispatch@ietf.org>; Fri,  1 May 2009 14:23:32 -0700 (PDT)
X-AuditID: c1b4fb3e-b7b7aae000004a86-76-49fb68a617bc
Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 58.D7.19078.6A86BF94; Fri,  1 May 2009 23:24:55 +0200 (CEST)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Fri, 1 May 2009 23:24:54 +0200
Received: from [131.160.126.150] ([131.160.126.150]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Fri, 1 May 2009 23:24:54 +0200
Message-ID: <49FB68A6.1040103@ericsson.com>
Date: Sat, 02 May 2009 00:24:54 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Cullen Jennings <fluffy@cisco.com>
References: <49FB54C1.30206@alcatel-lucent.com> <91F97501-F0C9-45DC-A48F-38F0EE362FF0@cisco.com>
In-Reply-To: <91F97501-F0C9-45DC-A48F-38F0EE362FF0@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 01 May 2009 21:24:54.0448 (UTC) FILETIME=[45187300:01C9CAA3]
X-Brightmail-Tracker: AAAAAA==
Cc: "dispatch@ietf.org" <dispatch@ietf.org>
Subject: Re: [dispatch] Next steps on SIP-CLF
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 May 2009 21:23:33 -0000

Hi,

> Sounds like a reasonable plan. I'm not sure we want to do this for all 
> things but I think it sounds like a good experiment to try for this one. 

yes, setting up a dedicated mailing list for discussing technical issues 
is a good option for relatively big work items. For smaller ones, we may 
want to use a generic mailing list for technical discussions on 
different smaller topics. This would avoid the overhead of creating and 
following too many mailing lists.

In any case, we would like to limit discussions in the DISPTACH list to 
discussions on whether or not we should work on a particular issue. 
High-level technical discussions that may help clarify whether or not it 
is appropriate to adopt some work are relevant but more detailed 
technical discussions fall outside our charter.

Cheers,

Gonzalo

From hsinnrei@adobe.com  Fri May  1 13:05:16 2009
Return-Path: <hsinnrei@adobe.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D49943A6D5E for <dispatch@core3.amsl.com>; Fri,  1 May 2009 13:05:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.064
X-Spam-Level: 
X-Spam-Status: No, score=-6.064 tagged_above=-999 required=5 tests=[AWL=0.534,  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 iXbyjahPPE2g for <dispatch@core3.amsl.com>; Fri,  1 May 2009 13:05:15 -0700 (PDT)
Received: from exprod6og105.obsmtp.com (exprod6og105.obsmtp.com [64.18.1.189]) by core3.amsl.com (Postfix) with ESMTP id BFD0E3A6D74 for <dispatch@ietf.org>; Fri,  1 May 2009 13:05:15 -0700 (PDT)
Received: from source ([192.150.11.134]) by exprod6ob105.postini.com ([64.18.5.12]) with SMTP ID DSNKSftWSEhrILKHbgKcQrRjuRA0RDgQEQ4O@postini.com; Fri, 01 May 2009 13:06:40 PDT
Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n41K0geM004202; Fri, 1 May 2009 13:00:42 -0700 (PDT)
Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n41K6Wiq013338; Fri, 1 May 2009 13:06:32 -0700 (PDT)
Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nahub01.corp.adobe.com ([10.8.189.97]) with mapi; Fri, 1 May 2009 13:06:32 -0700
From: Henry Sinnreich <hsinnrei@adobe.com>
To: "Vijay K. Gurbani" <vkg@alcatel-lucent.com>, "dispatch@ietf.org" <dispatch@ietf.org>
Date: Fri, 1 May 2009 13:06:30 -0700
Thread-Topic: [dispatch] Next steps on SIP-CLF
Thread-Index: AcnKl3F+C3g0dF+XSQazpnEE1OavRgAAN+L3
Message-ID: <C620C076.37F5%hsinnrei@adobe.com>
In-Reply-To: <49FB54C1.30206@alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_C620C07637F5hsinnreiadobecom_"
MIME-Version: 1.0
X-Mailman-Approved-At: Sun, 03 May 2009 05:36:16 -0700
Subject: Re: [dispatch] Next steps on SIP-CLF
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 May 2009 20:05:16 -0000

--_000_C620C07637F5hsinnreiadobecom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

This and several other projects seem to be the perfect fit for a Wiki.

Henry


On 5/1/09 3:00 PM, "Vijay K. Gurbani" <vkg@alcatel-lucent.com> wrote:

Given that there is enough interest in the topic of SIP-CLF
and enough passionate people to support both sides of the
argument on binary vs. ASCII, we might as well start thinking
of a place to get the work done.

Following dispatch's role, maybe we should think how to form
a place to get this work done, i.e., forming a BoF or EG or
directing the work to an existing WG.  To that extent, if
anyone wants to help put a concrete proposal together for
SIP CLF work, I will be more than happy to work with them to
define problem statement and proposal for new work.  We could
do that part in dispatch, I believe.

Regarding dealing with the technical aspects of the work, we
could start a new IETF mailing list so that the technical
discussions happen on that list and the process discussions
can continue on dispatch.

ADs: please advise if this is appropriate.

Thanks,

- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/


--_000_C620C07637F5hsinnreiadobecom_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [dispatch] Next steps on SIP-CLF</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:=
18pt'>This and several other projects seem to be the perfect fit for a Wiki=
.<BR>
<BR>
Henry<BR>
<BR>
<BR>
On 5/1/09 3:00 PM, &quot;Vijay K. Gurbani&quot; &lt;<a href=3D"vkg@alcatel-=
lucent.com">vkg@alcatel-lucent.com</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:18pt'>Given that there is enough interest in the =
topic of SIP-CLF<BR>
and enough passionate people to support both sides of the<BR>
argument on binary vs. ASCII, we might as well start thinking<BR>
of a place to get the work done.<BR>
<BR>
Following dispatch's role, maybe we should think how to form<BR>
a place to get this work done, i.e., forming a BoF or EG or<BR>
directing the work to an existing WG. &nbsp;To that extent, if<BR>
anyone wants to help put a concrete proposal together for<BR>
SIP CLF work, I will be more than happy to work with them to<BR>
define problem statement and proposal for new work. &nbsp;We could<BR>
do that part in dispatch, I believe.<BR>
<BR>
Regarding dealing with the technical aspects of the work, we<BR>
could start a new IETF mailing list so that the technical<BR>
discussions happen on that list and the process discussions<BR>
can continue on dispatch.<BR>
<BR>
ADs: please advise if this is appropriate.<BR>
<BR>
Thanks,<BR>
<BR>
- vijay<BR>
--<BR>
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent<BR>
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)<BR>
Email: <a href=3D"vkg@{alcatel-lucent.com">vkg@{alcatel-lucent.com</a>,bell=
-labs.com,acm.org}<BR>
Web: &nbsp;&nbsp;<a href=3D"http://ect.bell-labs.com/who/vkg/">http://ect.b=
ell-labs.com/who/vkg/</a><BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--_000_C620C07637F5hsinnreiadobecom_--

From TIMOTHY.L.MORAN@saic.com  Fri May  1 15:39:43 2009
Return-Path: <TIMOTHY.L.MORAN@saic.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C750528C154 for <dispatch@core3.amsl.com>; Fri,  1 May 2009 15:39:43 -0700 (PDT)
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, HTML_MESSAGE=0.001]
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 5iWyrZH7mNYT for <dispatch@core3.amsl.com>; Fri,  1 May 2009 15:39:40 -0700 (PDT)
Received: from mclmx.mail.saic.com (mclmx.mail.saic.com [149.8.64.10]) by core3.amsl.com (Postfix) with ESMTP id 00CD128C16E for <dispatch@ietf.org>; Fri,  1 May 2009 15:39:39 -0700 (PDT)
Received: from 0015-ITS-SMS01 ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com with ESMTP id BT-MMP-1166294 for dispatch@ietf.org; Fri, 1 May 2009 18:40:57 -0400
X-AuditID: 9508402e-a9d79ba000006f8f-91-49fb7a792464
Received: from 0015-its-exbh03.us.saic.com (unknown [149.8.64.21]) by 0015-ITS-SMS01 (Symantec Mail Security) with ESMTP id 6FC05C48119 for <dispatch@ietf.org>; Fri,  1 May 2009 18:40:57 -0400 (EDT)
Received: from 0015-ITS-EXBH01.us.saic.com ([10.43.229.18]) by 0015-its-exbh03.us.saic.com with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 1 May 2009 18:40:57 -0400
Received: from 0256-its-exmp02.us.saic.com ([10.40.16.18]) by 0015-ITS-EXBH01.us.saic.com with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 1 May 2009 18:40:57 -0400
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_01C9CAAD.E4ABBA58"
Date: Fri, 1 May 2009 18:40:59 -0400
Message-Id: <DF6DD917A6E6D34C9619D66816FF0C4F01345439@0256-its-exmp02.us.saic.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SIP Overload Control Design: Loop Control
thread-index: AcnKreXWhYloWrNQQYyw8M+5d8AQ5w==
From: "Moran, Timothy L." <TIMOTHY.L.MORAN@saic.com>
To: <dispatch@ietf.org>
X-OriginalArrivalTime: 01 May 2009 22:40:57.0236 (UTC) FILETIME=[E4BAA540:01C9CAAD]
X-Brightmail-Tracker: AAAAAA==
X-Mailman-Approved-At: Sun, 03 May 2009 05:36:16 -0700
Subject: [dispatch] SIP Overload Control Design: Loop Control
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 May 2009 22:39:43 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9CAAD.E4ABBA58
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Volker,

=20

A comment on the control loop paragraph in section 2 of the design
considerations for OLC:

"A control loop spanning multiple hops can be used if the sending entity
has full knowledge about the SIP servers on the path of a SIP message."
=20
I read this as the sending entity is required to have full knowledge of
the entire path.  I offer that that may not be the case.  It may be
possible to only require knowledge of one level downstream.  This sounds
pretty much like your example except that the example limits the case to
"one" downstream server.  Referring back to the requirements case of two
load balancing servers and the upstream server "PA", server PA can
declare overload upstream by knowing that servers P1 and P2 are
overloaded. =20
=20
Perhaps what I am trying to say is that an upstream server in a managed
network would declare overload (upstream) based on knowledge that all
next-hop servers are overloaded. =20
=20
Br,
Tim M.

=20

=20

=20


------_=_NextPart_001_01C9CAAD.E4ABBA58
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
h3
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:.5in;
	text-indent:-.5in;
	page-break-after:avoid;
	mso-list:l1 level3 lfo2;
	font-size:13.0pt;
	font-family:Arial;}
h4
	{margin-top:12.0pt;
	margin-right:0in;
	margin-bottom:3.0pt;
	margin-left:.6in;
	text-indent:-.6in;
	page-break-after:avoid;
	font-size:14.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
pre
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
p.Appendix1, li.Appendix1, div.Appendix1
	{margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	text-indent:-.25in;
	mso-list:l0 level1 lfo1;
	font-size:16.0pt;
	font-family:Arial;
	font-weight:bold;}
p.Hedaing5, li.Hedaing5, div.Hedaing5
	{margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:24.6pt;
	margin-bottom:.0001pt;
	text-indent:-.3in;
	mso-list:l2 level1 lfo3;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle19
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:339550940;
	mso-list-template-ids:-1954087436;}
@list l0:level1
	{mso-level-number-format:alpha-upper;
	mso-level-style-link:"Appendix 1";
	mso-level-text:"Appendix %1\.";
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level2
	{mso-level-text:"%1%2\.";
	mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level3
	{mso-level-tab-stop:1.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level4
	{mso-level-tab-stop:2.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level5
	{mso-level-tab-stop:2.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level6
	{mso-level-tab-stop:3.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level7
	{mso-level-tab-stop:3.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level8
	{mso-level-tab-stop:4.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level9
	{mso-level-tab-stop:4.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l1
	{mso-list-id:681247952;
	mso-list-template-ids:1992067650;}
@list l1:level1
	{mso-level-start-at:3;
	mso-level-text:%1;
	mso-level-tab-stop:.3in;
	mso-level-number-position:left;
	margin-left:.3in;
	text-indent:-.3in;}
@list l1:level2
	{mso-level-start-at:5;
	mso-level-text:"%1\.%2";
	mso-level-tab-stop:.4in;
	mso-level-number-position:left;
	margin-left:.4in;
	text-indent:-.4in;}
@list l1:level3
	{mso-level-start-at:3;
	mso-level-style-link:"Heading 3";
	mso-level-text:"%1\.%2\.%3";
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	margin-left:.5in;
	text-indent:-.5in;}
@list l1:level4
	{mso-level-text:"%1\.%2\.%3\.%4";
	mso-level-tab-stop:.6in;
	mso-level-number-position:left;
	margin-left:.6in;
	text-indent:-.6in;}
@list l1:level5
	{mso-level-text:"%1\.%2\.%3\.%4\.%5";
	mso-level-tab-stop:.7in;
	mso-level-number-position:left;
	margin-left:.7in;
	text-indent:-.7in;}
@list l1:level6
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6";
	mso-level-tab-stop:.8in;
	mso-level-number-position:left;
	margin-left:.8in;
	text-indent:-.8in;}
@list l1:level7
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7";
	mso-level-tab-stop:.9in;
	mso-level-number-position:left;
	margin-left:.9in;
	text-indent:-.9in;}
@list l1:level8
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8";
	mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	margin-left:1.0in;
	text-indent:-1.0in;}
@list l1:level9
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9";
	mso-level-tab-stop:1.1in;
	mso-level-number-position:left;
	margin-left:1.1in;
	text-indent:-1.1in;}
@list l2
	{mso-list-id:2131509665;
	mso-list-template-ids:-209792696;}
@list l2:level1
	{mso-level-style-link:"Hedaing 5";
	mso-level-text:%1;
	mso-level-tab-stop:24.6pt;
	mso-level-number-position:left;
	margin-left:24.6pt;
	text-indent:-.3in;}
@list l2:level2
	{mso-level-text:"%1\.%2";
	mso-level-tab-stop:31.8pt;
	mso-level-number-position:left;
	margin-left:31.8pt;
	text-indent:-.4in;}
@list l2:level3
	{mso-level-text:"%1\.%2\.%3";
	mso-level-tab-stop:39.0pt;
	mso-level-number-position:left;
	margin-left:39.0pt;
	text-indent:-.5in;}
@list l2:level4
	{mso-level-text:"%1\.%2\.%3\.%4";
	mso-level-tab-stop:65.7pt;
	mso-level-number-position:left;
	margin-left:65.7pt;
	text-indent:-.6in;}
@list l2:level5
	{mso-level-text:"%1\.%2\.%3\.%4\.%5";
	mso-level-tab-stop:53.4pt;
	mso-level-number-position:left;
	margin-left:53.4pt;
	text-indent:-.7in;}
@list l2:level6
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6";
	mso-level-tab-stop:60.6pt;
	mso-level-number-position:left;
	margin-left:60.6pt;
	text-indent:-.8in;}
@list l2:level7
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7";
	mso-level-tab-stop:67.8pt;
	mso-level-number-position:left;
	margin-left:67.8pt;
	text-indent:-.9in;}
@list l2:level8
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8";
	mso-level-tab-stop:75.0pt;
	mso-level-number-position:left;
	margin-left:75.0pt;
	text-indent:-1.0in;}
@list l2:level9
	{mso-level-text:"%1\.%2\.%3\.%4\.%5\.%6\.%7\.%8\.%9";
	mso-level-tab-stop:82.2pt;
	mso-level-number-position:left;
	margin-left:82.2pt;
	text-indent:-1.1in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoAutoSig><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>Volker,<o:p></o:p></span></font></p>

<p class=3DMsoAutoSig><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoAutoSig><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'>A comment on the control loop paragraph in section 2 of the =
design
considerations for OLC:<o:p></o:p></span></font></p>

<pre><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>&#8220;</span>A control loop spanning =
multiple hops can be used if the sending entity has full knowledge about =
the SIP servers on the path of a SIP =
message.&#8221;<o:p></o:p></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre><fon=
t
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>I read =
this as the sending entity is required to have full knowledge of the =
entire path.&nbsp; I offer that that may not be the case.&nbsp; It may =
be possible to only require knowledge of one <u>level</u> =
downstream.&nbsp; This sounds pretty much like your example except that =
the example limits the case to &#8220;one&#8221; downstream =
server.&nbsp; Referring back to the requirements case of two load =
balancing servers and the upstream server &#8220;PA&#8221;, server PA =
can declare overload upstream by knowing that servers P1 <u>and</u> P2 =
are overloaded.&nbsp; <o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre><fon=
t
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>Perhaps =
what I am trying to say is that an upstream server in a managed network =
would declare overload (upstream) based on knowledge that all next-hop =
servers are overloaded.&nbsp; <o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></pre><pre><fon=
t
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>Br,<o:p></o:p></span></font></pre><pre><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt'>Tim =
M.<o:p></o:p></span></font></pre>

<p class=3DMsoAutoSig><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoAutoSig><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C9CAAD.E4ABBA58--

From scott.lawrence@nortel.com  Sun May  3 12:35:35 2009
Return-Path: <scott.lawrence@nortel.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 657473A6A22; Sun,  3 May 2009 12:35:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.936
X-Spam-Level: 
X-Spam-Status: No, score=-5.936 tagged_above=-999 required=5 tests=[AWL=0.663,  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 7eVs8rUv+ceH; Sun,  3 May 2009 12:35:34 -0700 (PDT)
Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 06EF03A681C; Sun,  3 May 2009 12:35:24 -0700 (PDT)
Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n43JZpe04304; Sun, 3 May 2009 19:35:52 GMT
Received: from [127.0.0.1] ([47.17.25.99]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 3 May 2009 15:36:42 -0400
From: "Scott Lawrence" <scott.lawrence@nortel.com>
To: RAI DISPATCH <dispatch@ietf.org>
Content-Type: text/plain
Organization: Nortel Networks
Date: Sun, 03 May 2009 15:36:40 -0400
Message-Id: <1241379400.3528.50.camel@scott>
Mime-Version: 1.0
X-Mailer: Evolution 2.24.5 (2.24.5-1.fc10) 
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 03 May 2009 19:36:42.0453 (UTC) FILETIME=[7C642050:01C9CC26]
Cc: SIP Operations <sip-ops@ietf.org>
Subject: [dispatch] draft-lawrence-sip-3rd-party-authorization-00
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: RAI DISPATCH <dispatch@ietf.org>
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 03 May 2009 19:35:35 -0000

draft-lawrence-sip-3rd-party-authorization-00.txt has been submitted by
Scott Lawrence and posted to the IETF repository.

Filename:	 draft-lawrence-sip-3rd-party-authorization
Revision:	 00
Title:		 Third Party Authorization in the Session Initiation Protocol
Creation_date:	 2009-05-03
WG ID:		 Independent Submission
Number_of_pages: 15

Abstract:
        This draft describes some circumstances that are common in SIP
        deployments which lack a rigorous authorization model, and points out
        some ways in which this has resulted in poor security
        characteristics.
        
        The purpose of this document is to stimulate discussion of the
        identified problem and proposed requirements for any solution.

In this draft, I lay out a case for why SIP would benefit from an
authorization model that allows for one party to send a request to a
second party who must decide whether or not to allow the request, but
have a third party provide an explicit authorization in the request.
The goal is to allow separation of the evaluation of a request with
respect to a security policy from other parts of responding to the
request.

I _do_not_ include any discussion in this draft of _how_ the
requirements it lists could or should be met.  While I'm very interested
in that discussion, I think it's important to first discover whether or
not there is agreement in the SIP community that there really is a
problem and what part or parts of that problem need to be solved; this
draft is focused on that discussion.




From Christian.Groves@nteczone.com  Sun May  3 17:22:16 2009
Return-Path: <Christian.Groves@nteczone.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3619F3A6FDE for <dispatch@core3.amsl.com>; Sun,  3 May 2009 17:22:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.59
X-Spam-Level: 
X-Spam-Status: No, score=-1.59 tagged_above=-999 required=5 tests=[AWL=-1.585,  BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1, RELAY_IS_203=0.994]
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 iz3Ta3yqwNxZ for <dispatch@core3.amsl.com>; Sun,  3 May 2009 17:22:09 -0700 (PDT)
Received: from ipmail05.adl2.internode.on.net (ipmail05.adl2.internode.on.net [203.16.214.145]) by core3.amsl.com (Postfix) with ESMTP id 420623A6AF6 for <dispatch@ietf.org>; Sun,  3 May 2009 17:22:00 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Au8CAH/S/Ul20Olq/2dsb2JhbAAIyzeDfQU
X-IronPort-AV: E=Sophos;i="4.40,288,1238941800"; d="scan'208";a="373495998"
Received: from ppp118-208-233-106.lns10.mel6.internode.on.net (HELO [127.0.0.1]) ([118.208.233.106]) by ipmail05.adl2.internode.on.net with ESMTP; 04 May 2009 09:53:12 +0930
Message-ID: <49FE3565.9090508@nteczone.com>
Date: Mon, 04 May 2009 10:23:01 +1000
From: Christian Groves <Christian.Groves@nteczone.com>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Tom Taylor <tom.taylor@rogers.com>
References: <AF689C4E-9D79-4C82-87D5-7623D7A08007@standardstrack.com> <49FB4A4B.1060007@rogers.com>
In-Reply-To: <49FB4A4B.1060007@rogers.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: dispatch@ietf.org
Subject: Re: [dispatch] SIP-CLF: text versus binary
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 May 2009 00:22:16 -0000

The reason was not to carry it in ISUP or the BICC protocol (I'm not 
aware of any spec doing this). Companies wanted to use it in gateways 
where ISUP, BICC and H.323 were the call control protocols. All these 
were binary. That's why ITU-T and 3GPP adopted binary for those 
applications. However as H.248/Megaco evolved many applications were 
more closely tied to the work of the IETF and the usage has tended to be 
toward text implementations. Both the text and binary had tons of 
intellectual effort poured into them.
The text version is certainly easier for humans to read but slightly 
more problematic because a human must understand the grammar.
In terms of the technical performance like the tests here have shown the 
results are very dependent who has done the encoding.

My advice would be to pick one (if you use the coin method make sure it 
doesn't roll under a chair :-) ) and then document an optimised encode / 
decode code as part of the spec to try to minimise performance variability.

Good luck,
 Christian

PS: And no I wasn't rapporteur at the time.

Tom Taylor wrote:
> Just for fun, I'll remind you all that we tried to decide the H.248 
> text vs. binary question by the flip of a coin. The coin came up 
> "text" while the H.248 rapporteur sat there with his jaw touching the 
> floor, but then Pete Cordell came up with the idea of text-encoded 
> ASN.1 and that kept the issue alive. It turned out the real reason the 
> binary wouldn't die was that some people wanted to carry it in ISUP 
> (BICC, actually).
>
> Tom Taylor
>
> Eric Burger wrote:
> ...
>>
>> Why is H.248 a text protocol in the wild, even though the binary 
>> format had tons of intellectual effort poured into it?
>>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>

From vkg@alcatel-lucent.com  Mon May  4 13:21:19 2009
Return-Path: <vkg@alcatel-lucent.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1B1928C1C1 for <dispatch@core3.amsl.com>; Mon,  4 May 2009 13:21:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.514
X-Spam-Level: 
X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085,  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 wPiGoSBA1Mhu for <dispatch@core3.amsl.com>; Mon,  4 May 2009 13:21:18 -0700 (PDT)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id F09F728C26E for <dispatch@ietf.org>; Mon,  4 May 2009 13:20:42 -0700 (PDT)
Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id n44KM8Q1029645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <dispatch@ietf.org>; Mon, 4 May 2009 15:22:08 -0500 (CDT)
Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id n44KM8qE012395 for <dispatch@ietf.org>; Mon, 4 May 2009 15:22:08 -0500 (CDT)
Message-ID: <49FF4E70.10609@lucent.com>
Date: Mon, 04 May 2009 15:22:08 -0500
From: "Vijay K. Gurbani" <vkg@alcatel-lucent.com>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "dispatch@ietf.org" <dispatch@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
Subject: [dispatch] SIP-CLF mailing list created
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 May 2009 20:21:19 -0000

Folks: A new non-WG mailing list has been created to hold
discussions for SIP CLF.  We will offload the technical
discussions for SIP CLF from dispatch to the new list.

Adam and I are list administrators for it.  Please subscribe
to the list following instructions for it at the following
URL: https://www.ietf.org/mailman/listinfo/sip-clf.

Please restrict further technical discussions on SIP CLF to
the new list.

Thank you.

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/

From mary.barnes@nortel.com  Fri May  8 10:52:08 2009
Return-Path: <mary.barnes@nortel.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F28B128C265 for <dispatch@core3.amsl.com>; Fri,  8 May 2009 10:52:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.484
X-Spam-Level: 
X-Spam-Status: No, score=-6.484 tagged_above=-999 required=5 tests=[AWL=0.115,  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 wTIhGe75VscL for <dispatch@core3.amsl.com>; Fri,  8 May 2009 10:52:07 -0700 (PDT)
Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 8A49D3A711D for <dispatch@ietf.org>; Fri,  8 May 2009 10:51:34 -0700 (PDT)
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n48Hq1A29011; Fri, 8 May 2009 17:52:01 GMT
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: Fri, 8 May 2009 12:54:07 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF1DE6C5C0@zrc2hxm0.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: IETF-75 plans for DISPATCH 
Thread-Index: AcnNtXrnlTE+ihrURvGZPoNhaaFPuABmOAxgAC3W45A=
From: "Mary Barnes" <mary.barnes@nortel.com>
To: <dispatch@ietf.org>
Cc: rai-ads@tools.ietf.org
Subject: [dispatch] IETF-75 plans for DISPATCH
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 May 2009 17:52:08 -0000

Hi all,

As mentioned previously, we are setting earlier deadlines for discussing
topics in DISPATCH to allow time for constructive discussions prior to
the WG session at IETF-75:=20
http://www.ietf.org/mail-archive/web/dispatch/current/msg00006.html

We are proposing to follow the deadlines for BoFs for IETF-75:
http://www.ietf.org/meetings/75/cutoff-dates.html
since we anticipate that many of the topic discussions will follow a
"mini-BoF" format, based on the DISPATCH charter:
http://www.ietf.org/html.charters/dispatch-charter.html

Thus, the following are the proposed deadlines:

May 25th - Cutoff date to notify the chairs and DISPATCH WG mailing list
of plans to submit a proposal, including the topic of the proposal. This
will help folks with similar topics to work together before the meeting.
If a preliminary charter proposal is available at this point, please
include a pointer to it.

June 8th - Cutoff for charter proposals for topics. A charter proposal
must consist of a minimum of a problem statement and at least one
milestone/deliverable. This deadline will allow time for consideration
of proposals that could potentially be "dispatched" prior to the WG
session.

June 15th - Topics that are to be the focus of IETF-75 are announced.
The idea here is to focus the discussion over the weeks preceding
IETF-75 on these main topics, noting that any updates to the documents
are due 4 weeks later.  This will ensure we have constructive
discussions before the meeting and are actually able to determine
consensus as to where work should be progressed (e.g., separate BoF, a
new WG, an existing WG, individual document, etc.) at IETF-75. Contrary
to the past approach in the SIPPING WG, we anticipate determining
consensus as to the disposition of a work item based on the level of
"commitment" by individuals to actually contribute to the work (e.g.,
conference calls, design team mailing lists, contributing text, etc.)
rather than based on "interest" in doing the work.  Note, that the exact
disposition for a topic may (per the usual process) require follow-up
and confirmation by the ADS and/or IESG (e.g., for a new WG, Bof,
individually sponsored document, etc.) or with another WG to ensure
agreement with the DISPATCH WG consensus for the topic.

Note the intention is not necessarily to preclude folks submitting
documents on other topics, however, it is very unlikely there would be
agenda time allocated to documents/topics submitted after the deadlines.
We can include one or two slides on these topics in the DISPATCH WG
chair charts, as we've done in the past in the SIPPING WG chair charts,
so that the authors can gather other interested parties to contribute to
the work.=20

We appreciate the patience of the WG as we evolve the model for bringing
in new work and welcome feedback.=20

Regards,
Mary and Gonzalo
DISPATCH WG co-chairs=20



From dworley@nortel.com  Mon May 11 15:01:28 2009
Return-Path: <dworley@nortel.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A2DA3A6B47 for <dispatch@core3.amsl.com>; Mon, 11 May 2009 15:01:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.519
X-Spam-Level: 
X-Spam-Status: No, score=-6.519 tagged_above=-999 required=5 tests=[AWL=0.080,  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 mOtB2tBCEovC for <dispatch@core3.amsl.com>; Mon, 11 May 2009 15:01:27 -0700 (PDT)
Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 446343A6BAB for <dispatch@ietf.org>; Mon, 11 May 2009 15:01:27 -0700 (PDT)
Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n4BM2su17253 for <dispatch@ietf.org>; Mon, 11 May 2009 22:02:55 GMT
Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 11 May 2009 18:02:52 -0400
From: "Dale Worley" <dworley@nortel.com>
To: DISPATCH <dispatch@ietf.org>
Content-Type: text/plain
Organization: Nortel Networks
Date: Mon, 11 May 2009 18:02:51 -0400
Message-Id: <1242079371.3757.46.camel@victoria-pingtel-com.us.nortel.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) 
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 11 May 2009 22:02:52.0596 (UTC) FILETIME=[3B1BBF40:01C9D284]
Subject: [dispatch] "profile datasets" and the SIP UA configuration system
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 May 2009 22:01:28 -0000

I'm restarting work on the SIP UA configuration system, also known as
"profile datasets".  I'd like to get feedback:

- Is DISPATCH the correct mailing list for this discussion?  (I assume
so, since the work used to be on SIPPING.)

- The I-Ds that I know of that define profile datasets (or the overall
profile dataset meta-schema) are:

 draft-ietf-sipping-profile-datasets
 draft-ietf-sipping-media-policy-dataset
 draft-ietf-sipping-session-indep-policy

Are there any others?

Dale



From mary.barnes@nortel.com  Mon May 11 17:12:10 2009
Return-Path: <mary.barnes@nortel.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2F0B3A6840 for <dispatch@core3.amsl.com>; Mon, 11 May 2009 17:12:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.478
X-Spam-Level: 
X-Spam-Status: No, score=-6.478 tagged_above=-999 required=5 tests=[AWL=0.121,  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 QH-PwfQ--oM3 for <dispatch@core3.amsl.com>; Mon, 11 May 2009 17:12:09 -0700 (PDT)
Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id F1CC73A6A6F for <dispatch@ietf.org>; Mon, 11 May 2009 17:12:08 -0700 (PDT)
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n4C0Cau11816 for <dispatch@ietf.org>; Tue, 12 May 2009 00:12:36 GMT
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: Mon, 11 May 2009 19:16:16 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF1DEDB2F8@zrc2hxm0.corp.nortel.com>
In-Reply-To: <1242079371.3757.46.camel@victoria-pingtel-com.us.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dispatch] "profile datasets" and the SIP UA configuration system
Thread-Index: AcnShEf3Acntm3vvTsCqeyFqObfGAAAEBYTg
References: <1242079371.3757.46.camel@victoria-pingtel-com.us.nortel.com>
From: "Mary Barnes" <mary.barnes@nortel.com>
To: "Dale Worley" <dworley@nortel.com>, "DISPATCH" <dispatch@ietf.org>
Subject: Re: [dispatch] "profile datasets" and the SIP UA configuration system
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 May 2009 00:12:10 -0000

Hi Dale,

DISPATCH is the right working group for this discussion. There is
already a tentative charter item for figuring out what to do with this
work: http://www.ietf.org/html.charters/dispatch-charter.html

I also think that draft-ietf-sipping-policy-package might fit into the
more general topic - it depends upon the media-policy-dataset. =20

Also, the draft-ietf-sipping-media-policy-dataset replaced the last
document on your list (-session-indep-policy) and the media-policy doc
also covers session specific policies.

There have been several other individual documents in this area in the
past as well - I'll let those folks speak up if they still have an
interest in this work.

Regards,
Mary.=20


-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
Behalf Of Worley, Dale (BL60:9D30)
Sent: Monday, May 11, 2009 5:03 PM
To: DISPATCH
Subject: [dispatch] "profile datasets" and the SIP UA configuration
system

I'm restarting work on the SIP UA configuration system, also known as
"profile datasets".  I'd like to get feedback:

- Is DISPATCH the correct mailing list for this discussion?  (I assume
so, since the work used to be on SIPPING.)

- The I-Ds that I know of that define profile datasets (or the overall
profile dataset meta-schema) are:

 draft-ietf-sipping-profile-datasets
 draft-ietf-sipping-media-policy-dataset
 draft-ietf-sipping-session-indep-policy

Are there any others?

Dale


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

From drage@alcatel-lucent.com  Tue May 12 03:22:54 2009
Return-Path: <drage@alcatel-lucent.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A610E3A67FD for <dispatch@core3.amsl.com>; Tue, 12 May 2009 03:22:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.927
X-Spam-Level: 
X-Spam-Status: No, score=-5.927 tagged_above=-999 required=5 tests=[AWL=0.322,  BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 2BI-9DzgELo8 for <dispatch@core3.amsl.com>; Tue, 12 May 2009 03:22:53 -0700 (PDT)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by core3.amsl.com (Postfix) with ESMTP id 810303A6781 for <dispatch@ietf.org>; Tue, 12 May 2009 03:22:53 -0700 (PDT)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n4CAOMo3001795 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 12 May 2009 12:24:23 +0200
Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Tue, 12 May 2009 12:24:22 +0200
From: "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com>
To: Mary Barnes <mary.barnes@nortel.com>, Dale Worley <dworley@nortel.com>, DISPATCH <dispatch@ietf.org>
Date: Tue, 12 May 2009 12:24:21 +0200
Thread-Topic: [dispatch] "profile datasets" and the SIP UA configuration system
Thread-Index: AcnShEf3Acntm3vvTsCqeyFqObfGAAAEBYTgABXRdxA=
Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D6759ECDEF@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com>
References: <1242079371.3757.46.camel@victoria-pingtel-com.us.nortel.com> <1ECE0EB50388174790F9694F77522CCF1DEDB2F8@zrc2hxm0.corp.nortel.com>
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1DEDB2F8@zrc2hxm0.corp.nortel.com>
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.57 on 155.132.188.80
Subject: Re: [dispatch] "profile datasets" and the SIP UA configuration	system
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 May 2009 10:22:54 -0000

Isn't there a dividing line someone in here between things that are process=
ed through a WG and those that use other processes, e.g. AD sponsored. It e=
xists for event packages and I thought is was going to occur with these as =
well.

I just don't know where the dividing line is.

regards

Keith=20

> -----Original Message-----
> From: dispatch-bounces@ietf.org=20
> [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes
> Sent: Tuesday, May 12, 2009 1:16 AM
> To: Dale Worley; DISPATCH
> Subject: Re: [dispatch] "profile datasets" and the SIP UA=20
> configuration system
>=20
> Hi Dale,
>=20
> DISPATCH is the right working group for this discussion.=20
> There is already a tentative charter item for figuring out=20
> what to do with this
> work: http://www.ietf.org/html.charters/dispatch-charter.html
>=20
> I also think that draft-ietf-sipping-policy-package might fit=20
> into the more general topic - it depends upon the=20
> media-policy-dataset. =20
>=20
> Also, the draft-ietf-sipping-media-policy-dataset replaced=20
> the last document on your list (-session-indep-policy) and=20
> the media-policy doc also covers session specific policies.
>=20
> There have been several other individual documents in this=20
> area in the past as well - I'll let those folks speak up if=20
> they still have an interest in this work.
>=20
> Regards,
> Mary.=20
>=20
>=20
> -----Original Message-----
> From: dispatch-bounces@ietf.org=20
> [mailto:dispatch-bounces@ietf.org] On Behalf Of Worley, Dale=20
> (BL60:9D30)
> Sent: Monday, May 11, 2009 5:03 PM
> To: DISPATCH
> Subject: [dispatch] "profile datasets" and the SIP UA=20
> configuration system
>=20
> I'm restarting work on the SIP UA configuration system, also=20
> known as "profile datasets".  I'd like to get feedback:
>=20
> - Is DISPATCH the correct mailing list for this discussion? =20
> (I assume so, since the work used to be on SIPPING.)
>=20
> - The I-Ds that I know of that define profile datasets (or=20
> the overall profile dataset meta-schema) are:
>=20
>  draft-ietf-sipping-profile-datasets
>  draft-ietf-sipping-media-policy-dataset
>  draft-ietf-sipping-session-indep-policy
>=20
> Are there any others?
>=20
> Dale
>=20
>=20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
> =

From mary.barnes@nortel.com  Tue May 12 06:19:08 2009
Return-Path: <mary.barnes@nortel.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84B1C3A6CDC for <dispatch@core3.amsl.com>; Tue, 12 May 2009 06:19:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.478
X-Spam-Level: 
X-Spam-Status: No, score=-6.478 tagged_above=-999 required=5 tests=[AWL=0.121,  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 sn+GflhpNQDb for <dispatch@core3.amsl.com>; Tue, 12 May 2009 06:19:07 -0700 (PDT)
Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 5DB803A6A8C for <dispatch@ietf.org>; Tue, 12 May 2009 06:19:07 -0700 (PDT)
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n4CDJP826285 for <dispatch@ietf.org>; Tue, 12 May 2009 13:19:25 GMT
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, 12 May 2009 08:23:05 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF1DF1DE76@zrc2hxm0.corp.nortel.com>
In-Reply-To: <28B7C3AA2A7ABA4A841F11217ABE78D6759ECDEF@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dispatch] "profile datasets" and the SIP UA configurationsystem
Thread-Index: AcnShEf3Acntm3vvTsCqeyFqObfGAAAEBYTgABXRdxAABfbCMA==
References: <1242079371.3757.46.camel@victoria-pingtel-com.us.nortel.com> <1ECE0EB50388174790F9694F77522CCF1DEDB2F8@zrc2hxm0.corp.nortel.com> <28B7C3AA2A7ABA4A841F11217ABE78D6759ECDEF@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com>
From: "Mary Barnes" <mary.barnes@nortel.com>
To: "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com>, "Dale Worley" <dworley@nortel.com>, "DISPATCH" <dispatch@ietf.org>
Subject: Re: [dispatch] "profile datasets" and the SIP UA configurationsystem
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 May 2009 13:19:08 -0000

As I understand it, there is supposed to be some flexibility in the
model. However, my understanding was that most things need to at least
first get discussed in DISPATCH so that folks are aware. It's always
possible that someone's event package or new header that they think it
needed for their particular SDO might apply to other SDO's with a modest
tweak, etc. And, of course, other WGs can develop (and charter) event
packages.

My understanding was that this (posting and having some discussion on
DISPATCH mailing list) is the model for event packages per 3427bis -
section 4.1 (second paragraph). There is room in there for AD sponsored,
but my understanding was that initial discussion of the draft in
DISPATCH was still required. Then, it could become AD sponsored and just
require an expert review.=20

Regards,
Mary.=20

-----Original Message-----
From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20
Sent: Tuesday, May 12, 2009 5:24 AM
To: Barnes, Mary (RICH2:AR00); Worley, Dale (BL60:9D30); DISPATCH
Subject: RE: [dispatch] "profile datasets" and the SIP UA
configurationsystem

Isn't there a dividing line someone in here between things that are
processed through a WG and those that use other processes, e.g. AD
sponsored. It exists for event packages and I thought is was going to
occur with these as well.

I just don't know where the dividing line is.

regards

Keith=20

> -----Original Message-----
> From: dispatch-bounces@ietf.org
> [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes
> Sent: Tuesday, May 12, 2009 1:16 AM
> To: Dale Worley; DISPATCH
> Subject: Re: [dispatch] "profile datasets" and the SIP UA=20
> configuration system
>=20
> Hi Dale,
>=20
> DISPATCH is the right working group for this discussion.=20
> There is already a tentative charter item for figuring out what to do=20
> with this
> work: http://www.ietf.org/html.charters/dispatch-charter.html
>=20
> I also think that draft-ietf-sipping-policy-package might fit into the

> more general topic - it depends upon the media-policy-dataset.
>=20
> Also, the draft-ietf-sipping-media-policy-dataset replaced the last=20
> document on your list (-session-indep-policy) and the media-policy doc

> also covers session specific policies.
>=20
> There have been several other individual documents in this area in the

> past as well - I'll let those folks speak up if they still have an=20
> interest in this work.
>=20
> Regards,
> Mary.=20
>=20
>=20
> -----Original Message-----
> From: dispatch-bounces@ietf.org
> [mailto:dispatch-bounces@ietf.org] On Behalf Of Worley, Dale
> (BL60:9D30)
> Sent: Monday, May 11, 2009 5:03 PM
> To: DISPATCH
> Subject: [dispatch] "profile datasets" and the SIP UA configuration=20
> system
>=20
> I'm restarting work on the SIP UA configuration system, also known as=20
> "profile datasets".  I'd like to get feedback:
>=20
> - Is DISPATCH the correct mailing list for this discussion? =20
> (I assume so, since the work used to be on SIPPING.)
>=20
> - The I-Ds that I know of that define profile datasets (or the overall

> profile dataset meta-schema) are:
>=20
>  draft-ietf-sipping-profile-datasets
>  draft-ietf-sipping-media-policy-dataset
>  draft-ietf-sipping-session-indep-policy
>=20
> Are there any others?
>=20
> Dale
>=20
>=20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>=20

From Mike.Szilagyi@inin.com  Tue May 12 07:18:57 2009
Return-Path: <Mike.Szilagyi@inin.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEB7A3A6DA7 for <dispatch@core3.amsl.com>; Tue, 12 May 2009 07:18:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.469
X-Spam-Level: 
X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[AWL=-0.730, BAYES_20=-0.74, HTML_MESSAGE=0.001]
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 pY6H54DYbBDq for <dispatch@core3.amsl.com>; Tue, 12 May 2009 07:18:56 -0700 (PDT)
Received: from inin.com (smtpgw.inin.com [209.43.1.24]) by core3.amsl.com (Postfix) with ESMTP id B35223A6D07 for <dispatch@ietf.org>; Tue, 12 May 2009 07:18:56 -0700 (PDT)
Received: from ININHUB1 [172.16.1.156] by smtpgw.inin.com - Websense Email Security (6.1.1); Tue, 12 May 2009 10:20:27 -0400
Received: from ININMAIL.i3domain.inin.com ([172.16.1.186]) by ininhub1.i3domain.inin.com ([172.16.1.156]) with mapi; Tue, 12 May 2009 10:20:27 -0400
From: "Szilagyi, Mike" <Mike.Szilagyi@inin.com>
To: "dispatch@ietf.org" <dispatch@ietf.org>
Date: Tue, 12 May 2009 10:20:25 -0400
Thread-Topic: Transfer using reINVITE
Thread-Index: AcnTDMs1eQ0iV9OVQeOW5yVQDnpN4g==
Message-ID: <B043FD61A001424599674F50FC89C2D71D92492DF1@ININMAIL.i3domain.inin.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_B043FD61A001424599674F50FC89C2D71D92492DF1ININMAILi3dom_"
MIME-Version: 1.0
X-SEF-7853D99-ADF1-478E-8894-213D316B8FFA: 1
X-SEF-ZeroHour-RefID: fgs=4
X-SEF-Processed: 6_1_1_105__2009_05_12_10_20_27
Subject: [dispatch] Transfer using reINVITE
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 May 2009 14:18:58 -0000

--_000_B043FD61A001424599674F50FC89C2D71D92492DF1ININMAILi3dom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Is anyone familiar with a transfer scenario that uses reINVITEs?  I've run =
into a few RFPs where support for transfer using SIP re-INVITEs is on the q=
uestionnaire.  Could someone reference an RFC or draft that describes this =
scenario, if there is one.

Regards,
Mike

--_000_B043FD61A001424599674F50FC89C2D71D92492DF1ININMAILi3dom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m=
icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://=
schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share=
point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel=
/2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois=
=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://=
schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3=
.org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint=
/dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http=
://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha=
repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"=
 xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://=
schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001=
/XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so=
ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc=
p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/=
/schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche=
mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi=
crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat=
s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf=
ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c=
om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa=
ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web=
partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20=
06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200=
6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli=
deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal=
Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:=
st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal>Is anyone familiar with a transfer scenario that uses
reINVITEs?&nbsp; I&#8217;ve run into a few RFPs where support for transfer =
using SIP
re-INVITEs is on the questionnaire.&nbsp; Could someone reference an RFC or=
 draft
that describes this scenario, if there is one.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Regards,<o:p></o:p></p>

<p class=3DMsoNormal>Mike<o:p></o:p></p>

</div>

</body>

</html>

--_000_B043FD61A001424599674F50FC89C2D71D92492DF1ININMAILi3dom_--


From pkyzivat@cisco.com  Tue May 12 07:41:39 2009
Return-Path: <pkyzivat@cisco.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDDD528C115 for <dispatch@core3.amsl.com>; Tue, 12 May 2009 07:41:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.185
X-Spam-Level: 
X-Spam-Status: No, score=-6.185 tagged_above=-999 required=5 tests=[AWL=0.414,  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 WdTlaC6Q8H2W for <dispatch@core3.amsl.com>; Tue, 12 May 2009 07:41:39 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id D057328C101 for <dispatch@ietf.org>; Tue, 12 May 2009 07:41:37 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.41,182,1241395200"; d="scan'208";a="44003648"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 12 May 2009 14:43:09 +0000
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n4CEh9WO019163;  Tue, 12 May 2009 10:43:09 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n4CEh9DQ025695; Tue, 12 May 2009 14:43:09 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Tue, 12 May 2009 10:43:08 -0400
Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 12 May 2009 10:43:08 -0400
Message-ID: <4A098AFD.20001@cisco.com>
Date: Tue, 12 May 2009 10:43:09 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: "Szilagyi, Mike" <Mike.Szilagyi@inin.com>
References: <B043FD61A001424599674F50FC89C2D71D92492DF1@ININMAIL.i3domain.inin.com>
In-Reply-To: <B043FD61A001424599674F50FC89C2D71D92492DF1@ININMAIL.i3domain.inin.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 12 May 2009 14:43:08.0294 (UTC) FILETIME=[F7408260:01C9D30F]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=784; t=1242139389; x=1243003389; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20<pkyzivat@cisco.com> |Subject:=20Re=3A=20[dispatch]=20Transfer=20using=20reINVIT E |Sender:=20 |To:=20=22Szilagyi,=20Mike=22=20<Mike.Szilagyi@inin.com>; bh=lcXO0tOOCbBYu2kboUsk85qi3P61J8mmreYTzL7O7xc=; b=fOHRsry5gkXUwCJFLwB8kSwfqUtEltz8guW4EgRJVFPu2iO4nIn60QeYOu fXUfglOPsSKbfB1f0nqgHlW/dsv0w0zA/r759ajOi9TIAIPRz2uDY/wpr2Fk egvI6N+xLC;
Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); 
Cc: "dispatch@ietf.org" <dispatch@ietf.org>
Subject: Re: [dispatch] Transfer using reINVITE
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 May 2009 14:41:39 -0000

Transfer can only be accomplished using reinvite if there is an 
intermediary in the call path. I think you must be talking about 3pcc. 
There is an RFC on that but I don't have the number at hand.

	Thanks,
	Paul

Szilagyi, Mike wrote:
> Is anyone familiar with a transfer scenario that uses reINVITEs?  I’ve 
> run into a few RFPs where support for transfer using SIP re-INVITEs is 
> on the questionnaire.  Could someone reference an RFC or draft that 
> describes this scenario, if there is one.
> 
>  
> 
> Regards,
> 
> Mike
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

From ya-ching.tan@nsn.com  Tue May 12 07:46:14 2009
Return-Path: <ya-ching.tan@nsn.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30D7528C132 for <dispatch@core3.amsl.com>; Tue, 12 May 2009 07:46:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.549
X-Spam-Level: 
X-Spam-Status: No, score=-5.549 tagged_above=-999 required=5 tests=[AWL=1.050,  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 8jfuCf9e+HL2 for <dispatch@core3.amsl.com>; Tue, 12 May 2009 07:46:13 -0700 (PDT)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 323503A6DAD for <dispatch@ietf.org>; Tue, 12 May 2009 07:46:13 -0700 (PDT)
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 n4CElUkU025944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 12 May 2009 16:47:30 +0200
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 n4CElUlO017112; Tue, 12 May 2009 16:47:30 +0200
Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 12 May 2009 16:47:30 +0200
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, 12 May 2009 16:47:29 +0200
Message-ID: <601FBEDC0E5A5B4E8AFC11D2CF149AB8DFF13D@DEMUEXC014.nsn-intra.net>
In-Reply-To: <4A098AFD.20001@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dispatch] Transfer using reINVITE
Thread-Index: AcnTD/zPg84Z0fMTTU+hN7VrNSO2LwAAHPhA
References: <B043FD61A001424599674F50FC89C2D71D92492DF1@ININMAIL.i3domain.inin.com> <4A098AFD.20001@cisco.com>
From: "Tan, Ya Ching (NSN - DE/Munich)" <ya-ching.tan@nsn.com>
To: "ext Paul Kyzivat" <pkyzivat@cisco.com>, "Szilagyi, Mike" <Mike.Szilagyi@inin.com>
X-OriginalArrivalTime: 12 May 2009 14:47:30.0196 (UTC) FILETIME=[935B9540:01C9D310]
Cc: dispatch@ietf.org
Subject: Re: [dispatch] Transfer using reINVITE
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 May 2009 14:46:14 -0000

RFC 3725

Regards,
Ya-Ching

-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
Behalf Of ext Paul Kyzivat
Sent: Tuesday, May 12, 2009 4:43 PM
To: Szilagyi, Mike
Cc: dispatch@ietf.org
Subject: Re: [dispatch] Transfer using reINVITE

Transfer can only be accomplished using reinvite if there is an=20
intermediary in the call path. I think you must be talking about 3pcc.=20
There is an RFC on that but I don't have the number at hand.

	Thanks,
	Paul

Szilagyi, Mike wrote:
> Is anyone familiar with a transfer scenario that uses reINVITEs?  I've

> run into a few RFPs where support for transfer using SIP re-INVITEs is

> on the questionnaire.  Could someone reference an RFC or draft that=20
> describes this scenario, if there is one.
>=20
> =20
>=20
> Regards,
>=20
> Mike
>=20
>=20
>
------------------------------------------------------------------------
>=20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

From dworley@nortel.com  Tue May 12 08:04:22 2009
Return-Path: <dworley@nortel.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFEB13A6C90 for <dispatch@core3.amsl.com>; Tue, 12 May 2009 08:04:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.643
X-Spam-Level: 
X-Spam-Status: No, score=-6.643 tagged_above=-999 required=5 tests=[AWL=-0.044, 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 0jvTONRvUato for <dispatch@core3.amsl.com>; Tue, 12 May 2009 08:04:22 -0700 (PDT)
Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id ED77E3A6AFC for <dispatch@ietf.org>; Tue, 12 May 2009 08:04:21 -0700 (PDT)
Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n4CF4p828648; Tue, 12 May 2009 15:04:51 GMT
Received: from [47.141.31.149] ([47.141.31.149]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 12 May 2009 11:05:49 -0400
From: "Dale Worley" <dworley@nortel.com>
To: "Szilagyi, Mike" <Mike.Szilagyi@inin.com>
In-Reply-To: <B043FD61A001424599674F50FC89C2D71D92492DF1@ININMAIL.i3domain.inin.com>
References: <B043FD61A001424599674F50FC89C2D71D92492DF1@ININMAIL.i3domain.inin.com>
Content-Type: text/plain; charset=utf-8
Organization: Nortel Networks
Date: Tue, 12 May 2009 11:05:48 -0400
Message-Id: <1242140748.3614.17.camel@victoria-pingtel-com.us.nortel.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) 
Content-Transfer-Encoding: quoted-printable
X-OriginalArrivalTime: 12 May 2009 15:05:49.0858 (UTC) FILETIME=[22CEB020:01C9D313]
Cc: "dispatch@ietf.org" <dispatch@ietf.org>
Subject: Re: [dispatch] Transfer using reINVITE
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 May 2009 15:04:22 -0000

On Tue, 2009-05-12 at 10:20 -0400, Szilagyi, Mike wrote:
> Is anyone familiar with a transfer scenario that uses reINVITEs?  I=E2=80=
=99ve
> run into a few RFPs where support for transfer using SIP re-INVITEs is
> on the questionnaire.  Could someone reference an RFC or draft that
> describes this scenario, if there is one.

In addition, many UAs, as part of executing a transfer, first put the
caller on hold using re-INVITE.  Though re-INVITE is not intrinsically
part of the transfer, every phone that I have tested as done a re-INVITE
as the first step of a transfer.

Dale




From dworley@nortel.com  Wed May 13 14:43:05 2009
Return-Path: <dworley@nortel.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D7983A6B14 for <dispatch@core3.amsl.com>; Wed, 13 May 2009 14:43:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.512
X-Spam-Level: 
X-Spam-Status: No, score=-6.512 tagged_above=-999 required=5 tests=[AWL=0.087,  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 LNf0mD4jgH8n for <dispatch@core3.amsl.com>; Wed, 13 May 2009 14:43:04 -0700 (PDT)
Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 4A5D43A683B for <dispatch@ietf.org>; Wed, 13 May 2009 14:43:04 -0700 (PDT)
Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n4DLhVE23170 for <dispatch@ietf.org>; Wed, 13 May 2009 21:43:32 GMT
Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 13 May 2009 17:44:30 -0400
From: "Dale Worley" <dworley@nortel.com>
To: "Mary Barnes" <mary.barnes@nortel.com>
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1DEDB2F8@zrc2hxm0.corp.nortel.com>
References: <1242079371.3757.46.camel@victoria-pingtel-com.us.nortel.com> <1ECE0EB50388174790F9694F77522CCF1DEDB2F8@zrc2hxm0.corp.nortel.com>
Content-Type: text/plain
Organization: Nortel Networks
Date: Wed, 13 May 2009 17:44:29 -0400
Message-Id: <1242251069.26396.2.camel@victoria-pingtel-com.us.nortel.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) 
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 13 May 2009 21:44:30.0148 (UTC) FILETIME=[FED30840:01C9D413]
Cc: DISPATCH <dispatch@ietf.org>
Subject: Re: [dispatch] "profile datasets" and the SIP UA configuration	system
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 May 2009 21:43:05 -0000

On Mon, 2009-05-11 at 20:16 -0400, Barnes, Mary (RICH2:AR00) wrote:
> I also think that draft-ietf-sipping-policy-package might fit into the
> more general topic - it depends upon the media-policy-dataset.  

Currently, I don't classify draft-ietf-sipping-policy-package as being
involved in this discussion because it does not depend on the config
schema, it only specifies that the event package carry such XML
documents.  Of course, that distinction breaks down because
policy-package users are interested that the schema carry the
information that they need, but that's more of a semantic
interest/constraint than a syntactic one.

> There have been several other individual documents in this area in the
> past as well - I'll let those folks speak up if they still have an
> interest in this work.

Given the ambiguities involved, it looks like Dispatch is a good place
to get the discussion started.

Dale



From john.elwell@siemens-enterprise.com  Thu May 14 02:04:55 2009
Return-Path: <john.elwell@siemens-enterprise.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD9AA28C19B for <dispatch@core3.amsl.com>; Thu, 14 May 2009 02:04:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.53
X-Spam-Level: 
X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069,  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 jS-f8ZQ+YUP9 for <dispatch@core3.amsl.com>; Thu, 14 May 2009 02:04:54 -0700 (PDT)
Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id B19F028C0D0 for <dispatch@ietf.org>; Thu, 14 May 2009 02:04:54 -0700 (PDT)
Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KJM00L3QMMQGI@siemenscomms.co.uk> for dispatch@ietf.org; Thu, 14 May 2009 10:06:26 +0100 (BST)
Date: Thu, 14 May 2009 10:06:35 +0100
From: "Elwell, John" <john.elwell@siemens-enterprise.com>
In-reply-to: <1242251069.26396.2.camel@victoria-pingtel-com.us.nortel.com>
To: Dale Worley <dworley@nortel.com>, Mary Barnes <mary.barnes@nortel.com>
Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001E6943A@GBNTHT12009MSX.gb002.siemens.net>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: quoted-printable
Thread-Topic: [dispatch] "profile datasets" and the SIP UAconfiguration	system
Thread-Index: AcnUFA5JGfPpzW/kShO8Jk4DW0WKtgAXwT8A
Content-class: urn:content-classes:message
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
References: <1242079371.3757.46.camel@victoria-pingtel-com.us.nortel.com> <1ECE0EB50388174790F9694F77522CCF1DEDB2F8@zrc2hxm0.corp.nortel.com> <1242251069.26396.2.camel@victoria-pingtel-com.us.nortel.com>
Cc: DISPATCH <dispatch@ietf.org>
Subject: Re: [dispatch] "profile datasets" and the SIP UAconfiguration	system
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 May 2009 09:04:55 -0000

A couple of these drafts are being considered in the context of the SIP
Forum UA config work, so I would welcome trying to get this work moving
again through discussions in DISPATCH at IETF75.

John
=20

> -----Original Message-----
> From: dispatch-bounces@ietf.org=20
> [mailto:dispatch-bounces@ietf.org] On Behalf Of Dale Worley
> Sent: 13 May 2009 22:44
> To: Mary Barnes
> Cc: DISPATCH
> Subject: Re: [dispatch] "profile datasets" and the SIP=20
> UAconfiguration system
>=20
> On Mon, 2009-05-11 at 20:16 -0400, Barnes, Mary (RICH2:AR00) wrote:
> > I also think that draft-ietf-sipping-policy-package might=20
> fit into the
> > more general topic - it depends upon the media-policy-dataset. =20
>=20
> Currently, I don't classify draft-ietf-sipping-policy-package as being
> involved in this discussion because it does not depend on the config
> schema, it only specifies that the event package carry such XML
> documents.  Of course, that distinction breaks down because
> policy-package users are interested that the schema carry the
> information that they need, but that's more of a semantic
> interest/constraint than a syntactic one.
>=20
> > There have been several other individual documents in this=20
> area in the
> > past as well - I'll let those folks speak up if they still have an
> > interest in this work.
>=20
> Given the ambiguities involved, it looks like Dispatch is a good place
> to get the discussion started.
>=20
> Dale
>=20
>=20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>=20

From vkg@alcatel-lucent.com  Fri May 15 06:27:10 2009
Return-Path: <vkg@alcatel-lucent.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83B113A6A8E for <dispatch@core3.amsl.com>; Fri, 15 May 2009 06:27:10 -0700 (PDT)
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=[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 dK4L0TFDQV+v for <dispatch@core3.amsl.com>; Fri, 15 May 2009 06:27:09 -0700 (PDT)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 3284D3A6837 for <dispatch@ietf.org>; Fri, 15 May 2009 06:27:08 -0700 (PDT)
Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id n4FDSftb000770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <dispatch@ietf.org>; Fri, 15 May 2009 08:28:41 -0500 (CDT)
Received: from shoonya.ih.lucent.com ([135.112.130.128]) by umail.lucent.com (8.13.8/TPES) with ESMTP id n4FDSeFM011512 for <dispatch@ietf.org>; Fri, 15 May 2009 08:28:41 -0500 (CDT)
Message-ID: <4A0D6E1D.6030007@alcatel-lucent.com>
Date: Fri, 15 May 2009 08:29:01 -0500
From: "Vijay K. Gurbani" <vkg@alcatel-lucent.com>
User-Agent: Thunderbird 2.0.0.19 (X11/20090105)
MIME-Version: 1.0
To: dispatch@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
Subject: [dispatch] SIP-CLF: first draft of proposed work
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 May 2009 13:27:10 -0000

All: Eric and I have come up with a draft of proposed work on
sip-clf, reproduced below.  Please take a look and see if this
is on the right track.

Charter proposal for SIP Common Log File (CLF) format work
==========================================================
Vijay K. Gurbani and Eric Burger

Problem Statement
=================
Well-known web servers such as Apache and web proxies like Squid
support event logging using a common log format.  The logs produced
using these de-facto standard formats are invaluable to system
administrators for trouble-shooting a server and tool writers to
craft tools that mine the log files to produce reports and trends
and to search for a certain SIP message or messages, a transaction
or a related set of transactions.

Furthermore, these log files can also be used to train anomaly
detection systems and feed events into a security event management
system.  The Session Initiation Protocol does not have a common log
format, and as a result, each server supports a distinct log format
that makes it unnecessarily complex to produce tools to do trend
analysis and security detection.

Ad ad-hoc meeting was sponsored by the SIPPING WG during the San
Francisco IETF where the participants expressed interest in undertaking
this work.  Minutes from the ad-hoc are available at:
http://www.ietf.org/mail-archive/web/sipping/current/msg17199.html.
Since then, various discussions on CLF file format and other
assorted discussions have occurred on the SIPPING mailing list,
the sip-ops mailing list and the newly formed sip-clf mailing list.

Milestones and deliverables
===========================

1) A document enunciating the problem statement, motivation,
the possible use cases of a SIP CLF, and the list of mandatory
fields that will allow identifying transactions, grouping
transactions into dialogs, and doing the latter with provisions
for allowing the systems administrator or an automata to
correlate forked branches.  Provisions must be made to
accommodate ad-hoc fields without adversely impacting the
parsing of the mandatory parameters.

A possible starting document for this deliverable is
http://tools.ietf.org/html/draft-gurbani-sipping-clf-01

2) A document that details the byte layout of the SIP CLF
record.

The participants have done preliminary work on writing encoders
and decoders for space-separated ASCII and binary format.  The
runtime complexity to produce the space-separated ASCII and
binary CLF is comparable, however, the binary CLF is appreciably
faster in locating random records from the binary CLF file.
On the other hand, a ASCII CLF format was preferable because
it allowed for a visual interpretation of the mandatory
fields to the benefit of a human user and allowed for
expedited operations on the data using text-based tools.

Based on subsequent deliberations, a text format has been
defined which lends itself well to fast searches while still
allowing the use of visual identification and interpretation
using text-based tools.  This format is documented in:
http://tools.ietf.org/html/draft-roach-sipping-clf-syntax-01
and can serve as a possible starting document for the
details of byte layout.

3) A document that provides reference implementation(s)
for decoding the byte layout of the CLF.

NOTE: It could very well be that three individual documents
are produced to meet the deliverables or a single document is
produced that merges all three aspects.  This can be decided
by the BoF/design team/mini working group.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://ect.bell-labs.com/who/vkg

From dworley@nortel.com  Fri May 15 14:19:17 2009
Return-Path: <dworley@nortel.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 037DF28C147 for <dispatch@core3.amsl.com>; Fri, 15 May 2009 14:19:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.517
X-Spam-Level: 
X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[AWL=0.082,  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 l3hH9RGY2qQZ for <dispatch@core3.amsl.com>; Fri, 15 May 2009 14:19:16 -0700 (PDT)
Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 6BF6028C3D0 for <dispatch@ietf.org>; Fri, 15 May 2009 14:16:05 -0700 (PDT)
Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n4FLHZL07379; Fri, 15 May 2009 21:17:36 GMT
Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 15 May 2009 17:17:35 -0400
From: "Dale Worley" <dworley@nortel.com>
To: "Elwell, John" <john.elwell@siemens-enterprise.com>
In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001E6943A@GBNTHT12009MSX.gb002.siemens.net>
References: <1242079371.3757.46.camel@victoria-pingtel-com.us.nortel.com> <1ECE0EB50388174790F9694F77522CCF1DEDB2F8@zrc2hxm0.corp.nortel.com> <1242251069.26396.2.camel@victoria-pingtel-com.us.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D001E6943A@GBNTHT12009MSX.gb002.siemens.net>
Content-Type: text/plain
Organization: Nortel Networks
Date: Fri, 15 May 2009 17:17:35 -0400
Message-Id: <1242422255.3824.21.camel@victoria-pingtel-com.us.nortel.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) 
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 15 May 2009 21:17:35.0942 (UTC) FILETIME=[91823E60:01C9D5A2]
Cc: DISPATCH <dispatch@ietf.org>
Subject: Re: [dispatch] "profile datasets" and the SIP	UAconfiguration	system
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 May 2009 21:19:17 -0000

On Thu, 2009-05-14 at 10:06 +0100, Elwell, John wrote:
> A couple of these drafts are being considered in the context of the SIP
> Forum UA config work, [...]

Are there any other "profile datasets" that people are now constructing?
It always helps, when defining an abstract schema, to have two or three
concrete uses to hand.

Dale



From ahawrylyshen@ditechnetworks.com  Mon May 18 11:23:15 2009
Return-Path: <ahawrylyshen@ditechnetworks.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C45C3A6A5A for <dispatch@core3.amsl.com>; Mon, 18 May 2009 11:23:15 -0700 (PDT)
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_32=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 dMGi-nbhH4DM for <dispatch@core3.amsl.com>; Mon, 18 May 2009 11:23:08 -0700 (PDT)
Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by core3.amsl.com (Postfix) with ESMTP id 7193D3A6CAF for <dispatch@ietf.org>; Mon, 18 May 2009 11:23:08 -0700 (PDT)
Received: by wf-out-1314.google.com with SMTP id 29so1924492wff.31 for <dispatch@ietf.org>; Mon, 18 May 2009 11:24:42 -0700 (PDT)
Received: by 10.142.234.16 with SMTP id g16mr2091947wfh.107.1242671082645; Mon, 18 May 2009 11:24:42 -0700 (PDT)
Received: from ?172.22.128.136? (remote.ditechcom.com [12.108.187.222]) by mx.google.com with ESMTPS id 28sm9359874wfd.3.2009.05.18.11.24.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 18 May 2009 11:24:42 -0700 (PDT)
Message-Id: <BB945FE3-76FD-4DCB-802F-391667C4F3CD@ditechnetworks.com>
From: Alan Hawrylyshen <ahawrylyshen@ditechnetworks.com>
To: dispatch@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Mon, 18 May 2009 11:24:40 -0700
X-Mailer: Apple Mail (2.935.3)
Subject: [dispatch] Comments on draft-lawrence-sip-3rd-party-authorization-00
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 May 2009 18:23:15 -0000

Scott;

I spend some time over the weekend reading your draft. I think it is a =20=

great start on an important problem. This situation can pop up in many =20=

places where the operations or administrative domain wants to =20
centralize decision making around authorization.

Here are some comments that I made while reading the draft, please let =20=

me know if you want any sort of clarification:


=A72.1 - very clear and concise intro! Too bad everyone doesn't take the
time to lay out the problem and motivation this clearly.

p.5 =A7 2.2 par 10

This hints at a much larger problem in SIP.
Can Bob determine from Alice's subscription requests the (minimum)
degree of disclosure required to satisfy Alice's interests? How can
Bob know the application of the information requested. As you indicate
later in the draft, this remains a significant challenge, although it
is quite likely outside the scope of your draft. The JOIN vs 'line in
use' indications being a great example of the two extremes.

=A72.2.1 - on list disclosure
You said "decreases the security of the list".
I'm fairly certain that you are asserting that broad disclosure
somehow impacts the security of the system as a whole -- I agree with
this. However the sentence as written reads oddly. Can we find another
way to word this?

=A72.2.2 use of IP

I don't think spoofing is the fatal problem here - I think tying L3
and L4 together with an ACL is the fatal move in this approach. You
are essentially throwing DNS in the trash and removing the scalability
and mobility aspects that it brings in order to 'fool yourself' into
thinking that an IP ACL is security in some form. Moreover (and
related) I think that tying your UA to specific IP addresses
complicates the delivery of highly available and reliable services,
once again, bypassing the benefits of DNS.

TLS Peers
"signalling" vs "signaling" your call, I'm not sure which way is
preferred but I get teased for the double-l all the time.

@ the end of =A72.2.2 on the rollout of new features and the adjacency =20=

problem ...
Can you restate this more clearly? I'm understanding that you imply
there is a new feature that requires authorization in a central place
and that the mutual TLS condition only permits authorization by
receipt for a single hop. This part, I understand clearly. What I do
not understand is how a 'new feature' impacts this problem. I see this
as a problem no matter what. In another light, is this any different
that "last hop" authorization? I think I need some concrete example of
the unique aspect of a new feature in the TLS model. I certainly
understand that there can be no intermediary in order to successfully
apply the TLS as authorization paradigm. At least not without signing
the message contents -- something that you discuss further on
(indirectly) in the requirements section.

=A72.3.1
I see you share the concern that I have around minimal disclosure.
Last paragraph on weak auth -- can you expand on this slightly to make
it more clear?

=A72.3.3
s/therefor/therefore/g

=A73
Consider explaining "Enforcing UAS" in the terms section, it might
make the diagrams supremely obvious instead of merely clear.
I presume that these are UAS'es that are tasked with honoring the
authorization indication in requests.

Figure 2
Redirect based generation of authorization indications  could be
problematic, but I see that you explicitly require that auth. inds. be
something that can be copied from one request to another. I feel that
this requirement MAY create some tension with a general security
review and I look forward to exploring how to solve this problem and
the relevant security implications this property may bring.

Figure 4
It seems to met hat the regerred UAC is placing an auth ind into 'ar'.
Did that auth ind originate in the inbound REFER or did it generate it
locally? Is this relevant? I presume that it originates with the REFER
UAC since the point is to indicate to the ultimate target that the
REFER UAC authorized the action. This is unclear in the text and
diagram to me.

R10 - "determine the identity"
This is a strong concept. Did you mean "determine the identity" or
merely "note that this is not the same party" or that "this is a URI
for the party in question". Where on the identity sliding scale does
this requirement fall? (Purely from an identity point of view).

Overall; great draft and in my opinion, this is important work that
impacts many areas. I look forward to seeing this document develop.

Thanks,

Alan Hawrylyshen


From mary.barnes@nortel.com  Wed May 20 11:09:30 2009
Return-Path: <mary.barnes@nortel.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F15BD3A6EA7 for <dispatch@core3.amsl.com>; Wed, 20 May 2009 11:09:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.488
X-Spam-Level: 
X-Spam-Status: No, score=-6.488 tagged_above=-999 required=5 tests=[AWL=0.111,  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 hvena0BBnnit for <dispatch@core3.amsl.com>; Wed, 20 May 2009 11:09:30 -0700 (PDT)
Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id CC84F3A6E10 for <dispatch@ietf.org>; Wed, 20 May 2009 11:09:29 -0700 (PDT)
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n4KIB3D06998; Wed, 20 May 2009 18:11:03 GMT
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: Wed, 20 May 2009 13:13:35 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF1E196A42@zrc2hxm0.corp.nortel.com>
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1DE6C5C0@zrc2hxm0.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Reminder:  [dispatch] IETF-75 plans for DISPATCH
Thread-Index: AcnNtXrnlTE+ihrURvGZPoNhaaFPuABmOAxgAC3W45ACXAEJMA==
References: <1ECE0EB50388174790F9694F77522CCF1DE6C5C0@zrc2hxm0.corp.nortel.com>
From: "Mary Barnes" <mary.barnes@nortel.com>
To: <dispatch@ietf.org>
Cc: rai-ads@tools.ietf.org
Subject: [dispatch] Reminder:   IETF-75 plans for DISPATCH
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 May 2009 18:09:31 -0000

Hi folks,

Just a reminder that initial proposals for topics for IETF-75 timeframe
are due on Monday, May 25th (that's next Monday). So far, we've only
received two requests on the ML:
http://www.ietf.org/mail-archive/web/dispatch/current/msg00052.html (3rd
pty auth)
http://www.ietf.org/mail-archive/web/dispatch/current/msg00066.html
(CLF)

There has been some discussion of profile-datasets and I've had offline
discussions with a couple of other people, but we do need those topic
summaries posted to the ML on or before Monday, May 25.=20

Also, WG feedback on those topics would be extremely useful as that will
help to refine the problem statements.

Regards,
Mary
DISPATCH WG co-chair

-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
Behalf Of Barnes, Mary (RICH2:AR00)
Sent: Friday, May 08, 2009 12:54 PM
To: dispatch@ietf.org
Cc: rai-ads@tools.ietf.org
Subject: [dispatch] IETF-75 plans for DISPATCH

Hi all,

As mentioned previously, we are setting earlier deadlines for discussing
topics in DISPATCH to allow time for constructive discussions prior to
the WG session at IETF-75:=20
http://www.ietf.org/mail-archive/web/dispatch/current/msg00006.html

We are proposing to follow the deadlines for BoFs for IETF-75:
http://www.ietf.org/meetings/75/cutoff-dates.html
since we anticipate that many of the topic discussions will follow a
"mini-BoF" format, based on the DISPATCH charter:
http://www.ietf.org/html.charters/dispatch-charter.html

Thus, the following are the proposed deadlines:

May 25th - Cutoff date to notify the chairs and DISPATCH WG mailing list
of plans to submit a proposal, including the topic of the proposal. This
will help folks with similar topics to work together before the meeting.
If a preliminary charter proposal is available at this point, please
include a pointer to it.

June 8th - Cutoff for charter proposals for topics. A charter proposal
must consist of a minimum of a problem statement and at least one
milestone/deliverable. This deadline will allow time for consideration
of proposals that could potentially be "dispatched" prior to the WG
session.

June 15th - Topics that are to be the focus of IETF-75 are announced.
The idea here is to focus the discussion over the weeks preceding
IETF-75 on these main topics, noting that any updates to the documents
are due 4 weeks later.  This will ensure we have constructive
discussions before the meeting and are actually able to determine
consensus as to where work should be progressed (e.g., separate BoF, a
new WG, an existing WG, individual document, etc.) at IETF-75. Contrary
to the past approach in the SIPPING WG, we anticipate determining
consensus as to the disposition of a work item based on the level of
"commitment" by individuals to actually contribute to the work (e.g.,
conference calls, design team mailing lists, contributing text, etc.)
rather than based on "interest" in doing the work.  Note, that the exact
disposition for a topic may (per the usual process) require follow-up
and confirmation by the ADS and/or IESG (e.g., for a new WG, Bof,
individually sponsored document, etc.) or with another WG to ensure
agreement with the DISPATCH WG consensus for the topic.

Note the intention is not necessarily to preclude folks submitting
documents on other topics, however, it is very unlikely there would be
agenda time allocated to documents/topics submitted after the deadlines.
We can include one or two slides on these topics in the DISPATCH WG
chair charts, as we've done in the past in the SIPPING WG chair charts,
so that the authors can gather other interested parties to contribute to
the work.=20

We appreciate the patience of the WG as we evolve the model for bringing
in new work and welcome feedback.=20

Regards,
Mary and Gonzalo
DISPATCH WG co-chairs=20


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

From scott.lawrence@nortel.com  Wed May 20 15:02:07 2009
Return-Path: <scott.lawrence@nortel.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CE2A3A67A1 for <dispatch@core3.amsl.com>; Wed, 20 May 2009 15:02:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.73
X-Spam-Level: 
X-Spam-Status: No, score=-5.73 tagged_above=-999 required=5 tests=[AWL=0.269,  BAYES_00=-2.599, J_CHICKENPOX_32=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 5yykgYjEwj7N for <dispatch@core3.amsl.com>; Wed, 20 May 2009 15:02:06 -0700 (PDT)
Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 0D45028C0E7 for <dispatch@ietf.org>; Wed, 20 May 2009 15:01:43 -0700 (PDT)
Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n4KM3DD08542; Wed, 20 May 2009 22:03:14 GMT
Received: from [127.0.0.1] ([47.17.25.99]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 20 May 2009 18:03:10 -0400
From: "Scott Lawrence" <scott.lawrence@nortel.com>
To: Alan Hawrylyshen <ahawrylyshen@ditechnetworks.com>
In-Reply-To: <BB945FE3-76FD-4DCB-802F-391667C4F3CD@ditechnetworks.com>
References: <BB945FE3-76FD-4DCB-802F-391667C4F3CD@ditechnetworks.com>
Content-Type: text/plain; charset="UTF-8"
Organization: Nortel Networks
Date: Wed, 20 May 2009 22:03:09 +0000
Message-Id: <1242856989.3432.2530.camel@scott>
Mime-Version: 1.0
X-Mailer: Evolution 2.24.5 (2.24.5-1.fc10) 
Content-Transfer-Encoding: quoted-printable
X-OriginalArrivalTime: 20 May 2009 22:03:10.0769 (UTC) FILETIME=[C3A87A10:01C9D996]
Cc: dispatch@ietf.org
Subject: Re: [dispatch] Comments on draft-lawrence-sip-3rd-party-authorization-00
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 May 2009 22:02:07 -0000

On Mon, 2009-05-18 at 11:24 -0700, Alan Hawrylyshen wrote:
> Scott;
>=20
> I spend some time over the weekend reading your draft. I think it is a =20
> great start on an important problem. This situation can pop up in many =20
> places where the operations or administrative domain wants to =20
> centralize decision making around authorization.
>=20
> Here are some comments that I made while reading the draft, please let =20
> me know if you want any sort of clarification:
>=20
>=20
> =C2=A72.1 - very clear and concise intro! Too bad everyone doesn't take t=
he
> time to lay out the problem and motivation this clearly.

I'll be honest - the ID-nits tool had to remind me to write it :-)
Thank you for the endorsement of its utility to human readers.

> p.5 =C2=A7 2.2 par 10
>=20
> This hints at a much larger problem in SIP.
> Can Bob determine from Alice's subscription requests the (minimum)
> degree of disclosure required to satisfy Alice's interests? How can
> Bob know the application of the information requested. As you indicate
> later in the draft, this remains a significant challenge, although it
> is quite likely outside the scope of your draft. The JOIN vs 'line in
> use' indications being a great example of the two extremes.

Yes - in SIP we spend quite a bit of time and effort creating protocol
mechanisms that can be used in support of multiple end-user
"features" (so much so that we've had to create a whole working group to
describe which is the preferred way to do the features). This is, I
think, mostly a good thing, but it does lead to exactly this ambiguity -
we don't have a way to 'label' a request as being for a particular
purpose.  I had not thought of trying to include solving that 'problem'
with a solution to third party authentication, but it's something worth
noting and perhaps watching for opportunities to address.

> =C2=A72.2.1 - on list disclosure
> You said "decreases the security of the list".
> I'm fairly certain that you are asserting that broad disclosure
> somehow impacts the security of the system as a whole -- I agree with
> this. However the sentence as written reads oddly. Can we find another
> way to word this?

You mean this:

        ... Even if the problem is just one of storing the appropriate
        access control lists, it is not reasonable to replicate the
        lists into all UAs (and perhaps not desirable from a security
        perspective, since this decreases the security of the lists
        themselves).

Yes, that's what I meant: if every phone in the company knows which
identities have the most privilege, then it's probably not hard for an
attacker to pick the identity to go after.  I agree that this could be
made more clear.
       =20

> =C2=A72.2.2 use of IP
>=20
> I don't think spoofing is the fatal problem here - I think tying L3
> and L4 together with an ACL is the fatal move in this approach. You
> are essentially throwing DNS in the trash and removing the scalability
> and mobility aspects that it brings in order to 'fool yourself' into
> thinking that an IP ACL is security in some form. Moreover (and
> related) I think that tying your UA to specific IP addresses
> complicates the delivery of highly available and reliable services,
> once again, bypassing the benefits of DNS.

Agreed.  There are so many things wrong with using IP addresses as
authenticators that I debated whether or not to make this an even
shorter paragraph.  Alas, it is incredibly common in practice.

> TLS Peers
> "signalling" vs "signaling" your call, I'm not sure which way is
> preferred but I get teased for the double-l all the time.

I am always willing to accept spelling advice from anyone - in this, at
least, I know my limits.

> @ the end of =C2=A72.2.2 on the rollout of new features and the adjacency=
 =20
> problem ...
> Can you restate this more clearly? I'm understanding that you imply
> there is a new feature that requires authorization in a central place
> and that the mutual TLS condition only permits authorization by
> receipt for a single hop. This part, I understand clearly. What I do
> not understand is how a 'new feature' impacts this problem. I see this
> as a problem no matter what. In another light, is this any different
> that "last hop" authorization? I think I need some concrete example of
> the unique aspect of a new feature in the TLS model. I certainly
> understand that there can be no intermediary in order to successfully
> apply the TLS as authorization paradigm. At least not without signing
> the message contents -- something that you discuss further on
> (indirectly) in the requirements section.

Suppose I have a wiz-bang new feature.  I figure out how to negotiate
sessions that use it in SIP, and implement it in some spiffy new UAs.
Given a good SIP fabric, the feature works.  But this feature has some
characteristics that mean that I want it to be subject to an
organizational security policy (using it has privacy implications, or it
costs lots of money).  If I don't want to trust the endpoints to
evaluate the policy (for reasons described elsewhere), then I need to
have something else do so.  But the next-hop device those spiffy new UAs
are attached to is my old-reliable edge intermediate; it's hard to get
changes made to that, and it doesn't know anything about my new wiz-bang
feature, so there's no way to get it to do any security policy
evaluation for me on that feature.   If delivery implies authorization,
then all an attacker needs to do is find a way to get the request to the
next-hop old-reliable edge intermediate (probably not hard).

The great thing about proxies or other well-behaved intermediates is
that many new endpoint features work through them with no changes.
Using delivery as an enforcement mechanism breaks that very nice
quality.

> =C2=A72.3.1
> I see you share the concern that I have around minimal disclosure.
> Last paragraph on weak auth -- can you expand on this slightly to make
> it more clear?

Yes, an example or two here would probably help.

> =C2=A72.3.3
> s/therefor/therefore/g
>=20
> =C2=A73
> Consider explaining "Enforcing UAS" in the terms section, it might
> make the diagrams supremely obvious instead of merely clear.
> I presume that these are UAS'es that are tasked with honoring the
> authorization indication in requests.

oops  - that definition may end up being even more hand-wavy than the
others, but it's clearly needed.

> Figure 2
> Redirect based generation of authorization indications  could be
> problematic, but I see that you explicitly require that auth. inds. be
> something that can be copied from one request to another. I feel that
> this requirement MAY create some tension with a general security
> review and I look forward to exploring how to solve this problem and
> the relevant security implications this property may bring.

Yes, I think this one is going to be a challenge, and it may well be
that not all third party authorizations will have the same degree of
'security strength'.  I think that this is acceptable in practice, but I
recognize that others may differ.  I include this as a goal so that it
can get attention because it's a problem I've frequently encountered in
my own product (and for which I have a crude solution), but reasonable
people may differ on this.  I look forward to lively discussions...

> Figure 4
> It seems to met hat the regerred UAC is placing an auth ind into 'ar'.
> Did that auth ind originate in the inbound REFER or did it generate it
> locally? Is this relevant? I presume that it originates with the REFER
> UAC since the point is to indicate to the ultimate target that the
> REFER UAC authorized the action. This is unclear in the text and
> diagram to me.

Yes, my intent was that the REFER 'carries' an authorization that is
incorporated into the request that the referred party creates.

Example - I send you a REFER that instructs you to make a call that I
have the authority to make but that you do not.  By including an
auth-indication in my REFER that you can use in your INVITE, I enable
you to make the call on my authority.

> R10 - "determine the identity"
> This is a strong concept. Did you mean "determine the identity" or
> merely "note that this is not the same party" or that "this is a URI
> for the party in question". Where on the identity sliding scale does
> this requirement fall? (Purely from an identity point of view).

I'm not sure how to answer that.  Informally, I should be able to tell
who provided the authorization as distinct from who originated the
request.  I suspect that this gets us back to 'what is identity really'
again...

> Overall; great draft and in my opinion, this is important work that
> impacts many areas. I look forward to seeing this document develop.

Thanks.



From emil@sip-communicator.org  Thu May 21 15:44:25 2009
Return-Path: <emil@sip-communicator.org>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C65EE3A6AD8 for <dispatch@core3.amsl.com>; Thu, 21 May 2009 15:44:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.229
X-Spam-Level: 
X-Spam-Status: No, score=-1.229 tagged_above=-999 required=5 tests=[AWL=-1.230, BAYES_50=0.001]
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 Kut2hSS+JGeC for <dispatch@core3.amsl.com>; Thu, 21 May 2009 15:44:25 -0700 (PDT)
Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id BCADE3A6E38 for <dispatch@ietf.org>; Thu, 21 May 2009 15:44:24 -0700 (PDT)
Received: by fxm2 with SMTP id 2so1333491fxm.37 for <dispatch@ietf.org>; Thu, 21 May 2009 15:45:56 -0700 (PDT)
Received: by 10.103.161.16 with SMTP id n16mr1630028muo.79.1242945956072; Thu, 21 May 2009 15:45:56 -0700 (PDT)
Received: from porcinet.local (shm67-5-88-165-90-188.fbx.proxad.net [88.165.90.188]) by mx.google.com with ESMTPS id n7sm3056378mue.58.2009.05.21.15.45.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 21 May 2009 15:45:55 -0700 (PDT)
Sender: Emil Ivov <emil@sip-communicator.org>
Message-ID: <4A15D99F.9060100@sip-communicator.org>
Date: Fri, 22 May 2009 00:45:51 +0200
From: Emil Ivov <emcho@sip-communicator.org>
Organization: SIP Communicator
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
MIME-Version: 1.0
To: dispatch@ietf.org, Enrico Marocco <enrico.marocco@telecomitalia.it>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [dispatch] Yet another problem to dispatch
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 May 2009 22:44:25 -0000

Hey folks,

We have been working on client side conference calls  for SIP
Communicator lately and were thinking about implementing participant
sound level indicators. The feature was inspired by Skype's Mac OS X GUI
which you can have a look at over here:

http://sip-communicator.org/skypeconf/skypeconf.png

Since we couldn't find an existing IETF mechanism for a mixer to
dispatch information on sound level to conference participants, Enrico
and I thought that this may be an issue that is worth addressing through
dispatch.

After talking to some of you privately and discussing it among ourselves
we have decided to come up with a document presenting the issue in some
more detail. We are also including short descriptions of what we
consider to be possible approaches for resolving it.

http://www.ietf.org/internet-drafts/draft-ivov-dispatch-slic-ps-00.txt

Comments are most welcome, as well as any show of interest or
indications of what you think would be the right place(s) to work on the
subject.

Thanks,
Emil

From Marek.Dutkiewicz@polycom.com  Thu May 21 15:46:59 2009
Return-Path: <Marek.Dutkiewicz@polycom.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1089E3A6EB4 for <dispatch@core3.amsl.com>; Thu, 21 May 2009 15:46:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.089
X-Spam-Level: 
X-Spam-Status: No, score=-0.089 tagged_above=-999 required=5 tests=[AWL=-2.511, BAYES_50=0.001, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, SARE_GIF_ATTACH=1.42]
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 rMknGR0r4m8K for <dispatch@core3.amsl.com>; Thu, 21 May 2009 15:46:58 -0700 (PDT)
Received: from milpmailbhs.milpitas.polycom.com (milpmailbhs.milpitas.polycom.com [140.242.16.3]) by core3.amsl.com (Postfix) with ESMTP id 3611C3A7014 for <dispatch@ietf.org>; Thu, 21 May 2009 15:46:27 -0700 (PDT)
Received: from vanmail01.vancouver.polycom.com ([172.16.1.119]) by milpmailbhs.milpitas.polycom.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 May 2009 15:48:05 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/related; boundary="----_=_NextPart_001_01C9DA66.34236386"; type="multipart/alternative"
Date: Thu, 21 May 2009 15:48:03 -0700
Message-ID: <4280DB4085C0FC4BAA41AB503C1024D0069FC1BA@vanmail01.vancouver.polycom.com>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: RE: [dispatch] draft-lawrence-sip-3rd-party-authorization-00
Thread-Index: AcnaZjNREhjW++uoT2OEXEwB5W8q5Q==
From: "Dutkiewicz, Marek" <Marek.Dutkiewicz@polycom.com>
To: <dispatch@ietf.org>
X-OriginalArrivalTime: 21 May 2009 22:48:05.0601 (UTC) FILETIME=[3450F510:01C9DA66]
Subject: Re: [dispatch] draft-lawrence-sip-3rd-party-authorization-00
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 May 2009 22:46:59 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9DA66.34236386
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01C9DA66.34236386"


------_=_NextPart_002_01C9DA66.34236386
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

I will lend my voice to the need for a solution to the issue described
in draft-lawrence-sip-3rd-party-authorization-00 posted by Scott
Lawrence.=20

=20

You can add multi-cast paging to the list of scenarios that are ripe for
hacker abuse due to the weak level of authentication/authorization that
is in place. I'm dreading the day when a spam attack on an important
enterprise casts a shadow over VoIP security similar to the situation
encountered by a well known VoIP operator several years ago.

=20

The solutions I am aware of that are 'secure' rely on the call server
(typically a B2BUA implementation) to enforce
authentication/authorization rules. The UAs are configured to
authenticate (using Digest Authentication) that SIP signaling is
originating from the server. This provides a reasonable level of
security.

=20

However increasingly I am seeing people wanting to disaggregate the
control away from a central server model. This makes sense since this is
one of the benefits presented by SIP. However the security implications
could be severe.

=20

I'm not an expert in this area, so not well qualified to recommend a
solution, however one thought is to look at the AAA implementations that
are used in the cellular world to see whether this offers any useful
insight. Perhaps there could be a central authority that the various SIP
elements can turn to whenever they might be concerned about the
authenticity or authority of a particular message.

=20

Regards

Marek

=20

=20

_________________________
Marek Dutkiewicz
Director, VoIP Product Management
Suite 200 3605 Gilmore Way,=20
Burnaby, BC,=20
V5G 4X5
Direct:  604.453.9455
Cell: 604-764-8651

www.polycom.com <http://www.polycom.com/>=20

=20

=20


This communication (including any attachments) may contain privileged or
confidential information of Polycom and is intended for a specific
individual.  If you are not the intended recipient, you should delete
this communication, including any attachments without reading or saving
them in any manner, and you are hereby notified that any disclosure,
copying, or distribution of this communication, or the taking of any
action based on it, is strictly prohibited.

=20

=20


------_=_NextPart_002_01C9DA66.34236386
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.5pt;
	font-family:Consolas;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:Consolas;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"2050" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoPlainText>I will lend my voice to the need for a solution =
to the
issue described in draft-lawrence-sip-3rd-party-authorization-00 posted =
by
Scott Lawrence. <o:p></o:p></p>

<p class=3DMsoPlainText><o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>You can add multi-cast paging to the list of =
scenarios
that are ripe for hacker abuse due to the weak level of
authentication/authorization that is in place. I'm dreading the day when =
a spam
attack on an important enterprise casts a shadow over VoIP security =
similar to the
situation encountered by a well known VoIP operator several years =
ago.<o:p></o:p></p>

<p class=3DMsoPlainText><o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>The solutions I am aware of that are 'secure' =
rely on the
call server (typically a B2BUA implementation) to enforce
authentication/authorization rules. The UAs are configured to =
authenticate
(using Digest Authentication) that SIP signaling is originating from the =
server.
This provides a reasonable level of security.<o:p></o:p></p>

<p class=3DMsoPlainText><o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>However increasingly I am seeing people wanting =
to disaggregate
the control away from a central server model. This makes sense since =
this is
one of the benefits presented by SIP. However the security implications =
could
be severe.<o:p></o:p></p>

<p class=3DMsoPlainText><o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>I'm not an expert in this area, so not well =
qualified to
recommend a solution, however one thought is to look at the AAA =
implementations
that are used in the cellular world to see whether this offers any =
useful
insight. Perhaps there could be a central authority that the various SIP
elements can turn to whenever they might be concerned about the =
authenticity or
authority of a particular message.<o:p></o:p></p>

<p class=3DMsoPlainText><o:p>&nbsp;</o:p></p>

<p class=3DMsoPlainText>Regards<o:p></o:p></p>

<p class=3DMsoPlainText>Marek<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:red'>___=
______________________<br>
</span><b><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:#969696'>Marek Dutkiewicz<br>
</span></b><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:#969696'>Director, VoIP Product Management</span><span =
style=3D'font-size:
12.0pt;font-family:"Times New Roman","serif"'><br>
</span><span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:#969696'>Suite 200 </span><span lang=3DEN-CA =
style=3D'font-size:10.0pt;
font-family:"Arial","sans-serif";color:#969696'>3605 Gilmore Way, <br>
Burnaby, BC, <br>
V5G 4X5</span><span style=3D'font-size:12.0pt;font-family:"Times New =
Roman","serif"'><br>
</span><span lang=3DEN-CA =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:#969696'>Direct:&nbsp; 604.453.9455<br>
Cell: 604-764-8651</span><span =
style=3D'font-size:12.0pt;font-family:"Times New =
Roman","serif"'><o:p></o:p></span></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
lang=3DEN-CA style=3D'font-size:12.0pt;font-family:"Times New =
Roman","serif";
color:#969696'><a href=3D"http://www.polycom.com/" =
title=3D"http://www.polycom.com/"><span
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#969696'=
>www.polycom.com</span></a><o:p></o:p></span></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
style=3D'font-size:12.0pt;font-family:"Times New =
Roman","serif";color:#969696'><img
border=3D0 width=3D166 height=3D47 id=3D"Picture_x0020_1"
src=3D"cid:image001.jpg@01C9DA2B.0CA15B80" =
alt=3D"cid:100561119@05122006-2338"></span><span
style=3D'font-size:8.0pt;font-family:"Arial","sans-serif";color:#969696'>=
<o:p></o:p></span></p>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span
style=3D'font-size:8.0pt;font-family:"Arial","sans-serif";color:#969696'>=
<img
border=3D0 width=3D168 height=3D100 id=3D"Picture_x0020_2"
src=3D"cid:image002.gif@01C9DA2B.0CA15B80" =
alt=3D"cid:100561119@05122006-233F"></span><span
style=3D'font-size:12.0pt;font-family:"Times New =
Roman","serif"'><o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:8.0pt;font-family:"Arial","sans-serif";
color:#969696'><br>
</span><span style=3D'font-size:8.0pt;font-family:"Arial","sans-serif";
color:#969696'>This</span><span =
style=3D'font-size:8.0pt;font-family:"Arial","sans-serif";
color:#969696'> communication (including any attachments) may contain
privileged or confidential information of Polycom and is intended for a
specific individual.&nbsp; If you are not the intended recipient, you =
should
delete this communication,</span><span =
style=3D'font-size:10.0pt;font-family:
"Arial","sans-serif";color:#969696'> </span><span =
style=3D'font-size:8.0pt;
font-family:"Arial","sans-serif";color:#969696'>including</span><span
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#969696'=
>&nbsp;</span><span
style=3D'font-size:8.0pt;font-family:"Arial","sans-serif";color:#969696'>=
any
attachments</span><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:#969696'> </span><span =
style=3D'font-size:8.0pt;font-family:"Arial","sans-serif";
color:#969696'>without reading or saving them in any </span><span
style=3D'font-size:8.0pt;font-family:"Arial","sans-serif";color:#969696'>=
manner,</span><span
style=3D'font-size:8.0pt;font-family:"Arial","sans-serif";color:#969696'>=
 and
you&nbsp;are hereby notified that any disclosure, copying, or =
distribution of
this communication, or the taking of any action based on it, is strictly
prohibited.</span><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p></o:p></=
span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp;<o:p></=
o:p></span></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

</body>

</html>

------_=_NextPart_002_01C9DA66.34236386--

------_=_NextPart_001_01C9DA66.34236386
Content-Type: image/jpeg;
	name="image001.jpg"
Content-Transfer-Encoding: base64
Content-ID: <image001.jpg@01C9DA2B.0CA15B80>
Content-Description: image001.jpg
Content-Location: image001.jpg

/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a
HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy
MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCAAvAKYDASIA
AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA
AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3
ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm
p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA
AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx
BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK
U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3
uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3mW6t
4GCzXEUbEZAdwDj8a8e+KOiWKapBrttKjwTuEu0hkUsG/vD6gfmPeuu+Jnhga5oBvbdM3tkC646v
H/Ev9R9Peub8IeBvC/ijw7HeB7xLpf3c6iYfI474x0PWuHEc1R+yt5o+oyb2GDprHuo9+WSSvv8A
Prunbcw/FHhbwzo3h+C/0/Vbm6uLrb9njLIRg8ksAMjA/U16N4C0qw8NeHY45bq2F7cYluD5q5B7
L17D9c1wXhf4bSX3iLUbTV/MS0sW2FoztMjHlcE9sc/iKi8TeENKh8UWPh3QPPkvJTm4eWQMIwfo
B0GSfwrCnzU37VQ8rHr4v2WLj9QliG/tOVk1a11d3Vkl97se4xyxzIHikV0P8SnIp9U9L0220fTL
fT7RQsMCBV9T6k+5PNeaeLdNg1T43aBptw1wLO60+WSeKK4eMOy7tpO0jpgV6ivbU+CmoqTUHddD
1eivJ/JPgf4s6PpelajeyaXqNpPLe2VxcNMsARSRINxJXOP0NWPDulD4pWEniPxDcXbabPM66fpk
M7RRRxKxUO+0gs5IPXpTJPUKK8gktr34V+OtFgs9Qurnwtrc/wBla1upTIbaY/dKk845H657Grdx
GrftFQWp3G3OkfaTDuOwyhiA+3pu4HNAHqlFcn8Q/C8vijwrcw2MssGqQIZLSWKQodw52Ejs2Mfk
e1cg3igeMvh1omjaegt9X1SYWMka8NZmLBmkA6jaoyP99aAPW6K86124uR4j0b4e+H7qTTYZLZrq
9u4mzMkCnG1GOcMx6t15zVm6+FOhoIbrSpL2z1OCRZUujeyuZCGBIfLHIOCD9aAO8orz7WLy88X+
PrjwhbX09jpWnWyT6lJavslnd/uRBhyq45JHJ6VieMPh+3hHSJvE3gm+vrC+05fPlt2uHliuI15Y
MGJ5xk+/60AeuUV494+u5/HHgjwjPpbvaXur3CqjxyFSmYnZkyDyNy4/AV0vgzxvFdfCldf1BiJt
Nt3jvVb73mRDBB924P8AwKgDvKK8N+HOl6pqus+MtJ1y+uI764htbhnDkmDzcysigngcqDj0r2uy
tvsdjBbGV5fKjCb36tgdTQBPRRRQB4b4q8LW2keOYYbq4mttH1By0csf/LInqOewJH4Gsbxb4XPh
jxDHptveiWOdFdHZgpGTj5sdOe/pXtfjLw4nibw7PZgAXKfvLdj2cdvoen415n4f8C33inRdS1LU
5Jftu3yLPzTzuj4Ofbjb+deVXw9pOMVvqv1R99lmcKVCNavUsoe7Jd2/hl917+he8d+C7fRfB1hd
2swWe0xHO+7Hn7j19yD09vpXPaZ4UsX8E3HibUdSliKsyRRQ4JZhwAc9yf05q7pT6t47v9J8O36u
trpgJujzkhTj5v8AaxhR9SamPga+/wCE2/4RoSTf2KZPt3U7fL6f99fw1EoqcueEdNvmdFKtUw1L
6tiK9ppube/uX2Xm915Ox0nwo8OPaaa+uXYbz7obYAx+7H6/if0HvVDxZBa3/wAdvDdpcyssb6ZM
jGOYxsCd5GGUgg/jXqsUSQxJFEgSNFCqoHAA6Co2tbd5PMa3iaTIO4oCcjpzXqUqapwUUfC4/GTx
mIlXn1/BdEYumeCtD0j7ZJZ2r/aryMxzXU8rzTMpGMb3JOPbpXnvw/8AFNv8P4Z/BPi+T+zpbKZ2
sruYEQ3ELNkEN0zkn88dRXsVQXVla30Yju7aG4QchZYw4H4GtDjPNtVvLX4leLdBtNEJutI0a7F/
e6goIi3qPkiQn7xJ646CqGsazpuj/tDw3mo3sNtbJovltJI2FDl2IUn1xXrkUMVvEsUMaRxrwERQ
APwFNa2t3Ys0ETMepKAk0Ac7Y+PNA1fX7XSNI1CC+nlR5ZDC2RGqgck9OSQMVxPgm302P47eNGt1
gBESGLaR95tpk2+5IGcV6ylvDE26OGND6qoFNSztYnDx20KOM4ZYwCM9aAPMviDFqHhbx5o/j60t
JbvT4YDZalHCu50iJJD49OfzUetdCvxU8GzW0UttrMd1LNgR2tujPO5PQeWBnP1rsuowelVYNNsL
WZpreytoZW+88cSqx+pAoA8v127l+HvxWm8U3dtM3h7W7ZIbueNC32aVQACwHbAH5n0rW8UfEDR9
X8P3Wj+GLuPWNY1GFre3gtAX27xtLueiqoOTmvQnRJEZJFVkYYKsMgiobWwsrHd9ktLe33fe8qIJ
n64FAHmt7pUPhu7+GXh9p42a0uX3sTjLLC2W+hY8fUVg3vh2/tviveeEoIseH9euItXuPRVjJaRR
/vOFB9iK9rktbeZw8sETsONzICfWn7F3h9q7wMBsc49KAPNdAuIY/j54rhWRSZ9Pt2wCPvIFBH1w
a9MqFbS2SXzVt4hJkneEAOT1OamoAKKKKACmO8dvE0jsscaAszE4AHUk0+ggEYIyD2NAGHYv4dsp
7/U7S7s1a6kU3EomUgtjgZzx3OPrWlNqFhbRxzz3dtGko/dyPIoDjrwe9YEOkXtj/Z1ylilw1tJc
77dXVT+8clXBPGQOOvRjVSDQ9Y02Npbe2jeaa2dI1jdP9EYyM4Vd4wVO4A/7tJJLYqU5Td5O7Ool
1bTYZZIpb+2SSMZdWlAKj39Oop1tqVjeDNteQTDBP7uQNwMZ6fUfnWPplhqEOpXxuoZjHcNvyHjM
JPlqM7fvZyD7VBb+H7wRaYm+S1NvpzQSNA6gmQ7Pl5ByPlPPtTJN/wDtOwM6wfbbfzWXeqeYMlcZ
zj0xzT7W8tb6MyWlzFOgOC0ThgD+FctY6Nqdq8kbQTbJLGKH5JY/L3LFtO4H5uvpVnQbS60S7W2u
YzM92IwJtygqEiwQQOwIwO53e1AG+dQs1ujam7gFwBuMRkG4DGc469Oai/tjTPs32n+0LXyN2zzP
OXbu64znrWDFpmr25azjt18lpbhpZ9yETq4YrnPzBgSo9MCqcfh3VbWOE7JppEmgkMkUkayYWFkK
jI2/KT+IPtQB2El7aRDMlzCn7sy/M4HyDq305HNRR6vpstvLcR39s8MWPMkWVSqZ6ZOeKwpNH1Ob
xDFrJCDynjhWB9pYwFcOSwOOrE477RWtolg1lpC208SK/mSMyjBBBkYj9CKALNtqVjef8e15bzdf
9XIG6Yz0+o/Oni9tG24uYTuKhfnHJYZXH1HSuctfD14sOkoXe1NtYyQytA6g7zswOQcj5TVaLwtd
TWkNtdRhFAtsujjcjRxMu4e4YqRQB1U+oWVrF5txdwRR7im55ABuHUc96UX1o1ytst1CZ2XesYcb
ivqB6VytvpOt2wiupreOe72XEbeS6Axs8hYSLv8Al+YYyOoq9Y2OqQ6zb3DQtH5sSfb3LoY5GEeA
VUfMGzx2GBQBv/aYBnM0fD+WfmH3/wC79famve2saTO9zCqwHEpLjEZxn5vTqPzrnpNBvWv5LkSS
bTqiXIhDrsMYVQW6ZzweM1QHhvWVt7wlomk1KMSThcDyphKGHJOG+UkZ/wBgUAdYdV04LCxv7YLO
cRHzVw/bjnnmg6pp4kljN9bh4f8AWqZRlOcc+nJArCm8J+bdpF9ol+yyRTfapMJulZ3RiMY+UHb2
Axiq8+hX1zaaxYy20rw3dwZFV5U8pkMqscAfMDtz1oA65ZEd3RXUshAZQeVzyM0VzOnWus6J9vP2
L+0TJOiwss6ozRKgAZi38Qxg+uM0UAf/2Q==

------_=_NextPart_001_01C9DA66.34236386
Content-Type: image/gif;
	name="image002.gif"
Content-Transfer-Encoding: base64
Content-ID: <image002.gif@01C9DA2B.0CA15B80>
Content-Description: image002.gif
Content-Location: image002.gif

R0lGODlhqABkAOYAAHV1dX19fcTExFlZWcjIyNzc3NTU1M7Oztra2p6enubm5omJiWVlZbKysri4
uMDAwGdnZzw8PLCwsF5eXqampry8vFRUVKysrElJSb6+vqmpqaGhoY2Njba2ttLS0jk5OcvLy3l5
eVBQUJmZmWpqapWVlYCAgN/f32FhYW9vb5KSkkVFRU1NTcbGxnFxccLCwqqqqjo6OlZWVjY2Npqa
mmxsbKSkpGhoaI+Pj05OTj8/P1JSUoSEhGBgYIKCgkJCQpCQkHJycltbW66urkZGRkpKSu0uOPJm
bfedovrHyv7+/jQ0NEFBQf39/dbW1jU1Nfirr/vV18zMzOHh4f7x8uLi4tfX1+9KU/n5+fPz8/X1
9fWQlfHx8e48Rfm5vfFYYO/v7/r6+tnZ2e3t7fSCiOjo6NHR0enp6fv7+/z8/ODg4LW1teTk5M3N
zf3j5PN0evLy8vDw8O7u7rS0tOPj4/f39+Xl5evr6/b29urq6oeHh/j4+PT09Ozs7DMzM////yH5
BAAAAAAALAAAAACoAGQAAAf/gH+Cg4SFhoeIiYqLjI2Oj5CRkpOUlZaXmJmam5ydnp+goaKjpKWm
p6ipqqusra6vsLGys7S1tre4ubq7kxI/C7zBrDh+KErCyJ12ZseGWQ52iAdWydWPWiJ+D5EGfjFl
1uGKWgMfApEFPyxj4u2HcmqISlZZiGfs7vmMSjxPKPX6Ai4a4yHNoDQ//PiJN8gAHYEQ/+TJ5qPZ
Hw07FmAZtOEJEycRA3pQiKEJoTqFUihcE1KYlSANDmHhMMHBogMoAMg5ZMYEgZazFvhhYbFQ0UkA
ismyMmKEmEZ7CjixQrWqFSdqymjduvUMnFNWAHQYpORooQY1RoRJ1ETLIAIu/yrEqhBDYYRzikBY
eLKkr1+/Mz4IHkwYAwoOUlKdQIGiAKJuCiXYYyBiW61sCv0MWItoDJHMoEOLHu2HAYhTxPwAO0Qg
Mw1EDRSSsKUD9I+diFqT3s17BgVTAnREeHHQpCAsAXSgUEDIohoWEYbYYgJ6BZhELXhr363BFJuH
ggQMmHCA0B3jfxQAmBBTEBc2t6hntp6oQ2gmDPLrZwBhv34UOYw2gxmpYIHZBOgVoodCHzCni3wK
0QdbaClAgoUZLojGQIKkYGGBQihwOAgPCs0A34PVXYfIHBQW8kAKDCTAmSFKmCBaG4XIccCJ9hyA
T2dWHGCGGhu9NQEDBgxCx/8BCChJWXeDoEGHAUzG8UgYVSBQQAE/agKhHxIewiJoFQ5SAWgmmCXI
Hh+CxgMhVrDgRwQ2HSLACkMlWcgeDZCAp0IxiMADgYc8UNsTrw2CkiBWLLBDBAo9gUENDeChyAE8
iBDBE4GtwMAGfXgJGhGWIuJAi4MwANoSUySiQWgWzBhCZiIUSUgTQmQWRCEgyLDbEzzwYQgJmf3w
FSFpqFAXaRa0cAgcJiyxGwbtXfIlEwQ4oe2229KA6h9KTBCanodMsaxd0QiSVKTkDnLCDJnNNogD
H4T2gbSgocBFIaraVcWtAWz3gWWDyIFCaERoGtpv1m63W5ngipvZEiAh0gT/ZpkR+od9rhlCAWhQ
/iEGpPFWoAYCCXyWWQhFQZBZBP8OkkBoAKzRwgX9KlSElYI0keHKUsiBBRsNtOnHEolZ8qXDZJIl
sUIUK5KzQnj9EYfKxRxVQ2Y65NEzsZmNUAgdA4BW9R8u+zvIFCQffcGtQIBG7qmZ2WAIHGAXY1Al
SzOtEMThrloxIkGEdraNgKYryB21KQRAQ6C5cMjI8VqU9pwx/6GCm4esK8OxTfSQWQCI3AEhjnz7
LRrgTx89+CF5U01IdplV+wfdCsklSAkTa1zIrHY5iPbLMYexw8s8EsJHAhwI/26kFVQxxfTUT6HA
DZmVoDRoTxTBwvfgf59D/0JNCxL4xK8b0rofPykaoOOEBEySsILkzcKihsSWGcGXwyxIAfWSzSPG
dLQIEIYwMYDX37Y3HzZk4YEQfCAfLvCt80EtfYTAAwZW9RRCcGA++/qDFjaoED0MIgwYY0AipACa
DQyifzETAGjE5gjeqc4PQmBghI51CI5lhnWCS4QVFKiQH4SKEAZ4Qmbwopujlcc9JPQDxAzRBtCo
4IXEE8QDQDMWRyzohj7QIZhUJKYKti5qiBhBaBBUiCaUTSGr+aBCLICGQcAhiihIRBP9cEVBwFCL
oHmbI+SokAa0QQqITKQipXAA/E3iS2EyBAEXaL4zYlAQefhT9g4xszk2If8NvlIIDXtmtCK45RBD
AA3Dhqe2P1QxM6tpxMcy80RRQJKMkjTjqqhhCC1sDTQfcIwhThDAJxRADUr0QzALsS6F+I4QwFNI
0liJOUGcoW10PEQcOBACXv7BDFYkxS0TMUkpOm1VBkhDGNaZBjg8YH1+MEEisKcQGFBQISoshATQ
dAg7NM4PGAAINf0niINlpk636hcLQmig+dwBNhMIQvIemaJErEGXoMmBDCzAURnISTREAAci7lma
nAmSEGMgnx+eoLsoqSQzffRjFgVBUoB2cBCbK1HmbAAaBihuELP0A+nEGMlC0O6H57xhBE6TiDw0
Lpl+0MEZDvGqzHyABlP/QEMWpBA7DDwUi638Ax6M5gcmlGAaAngpiGakBbKuQAUECBIFphaCS7Rt
jImQIWhqQIipOUwEtUxEMzPzuEMoQX4vy0EU7dK+VL2sVYPwQN+gWiLUDcIKKs0MZRnUrkmQdQJ1
REQBKMsBQujPYW/FZSLOFJqWGgILONhsaETA1L5y7auDOADGRsMEhCLxjbsRwdkoERyFMKG2aczM
AKZKCApYAAPQjW50WTCBADTgiI0gB2hkcMpEmIEH73sZCigAECyE9g/7LOEgsMAzLiRABptlgR4Y
cgg8aGACRLTLBCgQQkxMgQIaAM8i2rCBBnSXEGiIAxcWzGAuxIF+kuiD/wPWsAYHeC27CCCAAx5g
BuH94QEWGMA020CBB4S2AAPAQAKiVIAHUDgDThCoIpRwAhevoQNS8DBQRrGHA4lIEIh7QuZ2bA0P
4XNvhpBjBJhLZGGI4aZtYAAJvPmHKeBvDCYgQUvPcNMm36ICH5iBazMYhA/IALKGKMAKfONlXOQ0
loXQqx9GWYgx8bXNtrBDCmqA5kKIIZkseYcLBtBYPLvCDCQ4KSMyEAIK/Pggg3gAA2xn6FMIhSiI
sJUiZmSIpOSz0qg4gQnGLIg6mMACiraTDEhwYT9z4JmgPrRCiJAgng3il5SO9S3GIIQPcMAiCcBA
APYwCBjEAAPC1LUu+P+Q7D+kQT70/YMasKtsZCiBAxEgwYGrrQsFdJYQU9A0IU4wUW67QgvHI5gj
RrYC3JrbFXgYwAyGywgrLIEJTH63K8bQbELIAQb9HoQY+qzvWwhlAmoqOC8cUISYKvzhEI+4xCdO
8Ypb/OIYz7jGN87xjrfjCCAH+Rb+cISRk3zkWwj5EQihcihA4QhR+MPLo/ByldMc5jLHecjf4IU/
RKHlg5j5H7xwBSN8IQmEoMIbjHAFkw8d5DHPedRPPoifQ4HkR0CCz49w9T8g4QpdeIMbXgFyI3Sh
5H8wwsrTvvIjGAEJcCcE0+GeBCQYAel2T8LLi/4FmOfd63dP+xWQ0AX/I7ghCWqn+yDyTgWje6EL
VyAEGd4++Z7/YfJvF8TfBaH2QSBe60Yw+x8+P3ojkOHxa39F5zm/9s67/RCrBzzeAy97zQf+753P
O+kLoXsjjBwKWh/EFb6w9a6f3QhvsD3SWe/5zIfeCF4g/RaMQAWSGyEWsTd6EhDf9rsnYepsX/zt
ab/5v+O++4c3/farr/w/FD74ck+9IKLwdrC3n/mCIL3aw07619Mi+8/nes8nfwFYd+O3fOV3gGn3
fFeHeM+3fLUHBaF3BOyHf+KXBJM3exAYe/pXctCXea8HfPDnCtnXet0He0eXBFRgfuTXghqYdkf3
BV1QeiN4f1FQdGQQ/X+F4HZJMH1at3nhl3/OB3PIB4LXtwWFh32pt3oCCHupx4II6IK1l3vel3m8
531I4AZUUHSEcAUr93mNF4DEB4QcOIR/8AWhp3VLJwj+p3pLaILWt30QGIRDZ4Tst3leYIfh13tk
sH1jp3x2hwRbGHmDsHRRYHdekIfBh4YraHpxN3dIsH1maHeZF4hneH2wUILM53bPp4ODgHlG0HW1
Jwig2HWdJ4HRF4Dwx3hFZ3ai6HOF13nTF3XT5wWUGHoLmIYd+AdukIZ/QAVo2IkRQQUquAjEWIGU
EAVzSAhJ8IehcHjL6HHSOI3UWI3WeI3YmI3auI3c2I3e+I20EAgAOw==

------_=_NextPart_001_01C9DA66.34236386--

From alan@sipstation.com  Fri May 22 10:19:16 2009
Return-Path: <alan@sipstation.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84E383A6AB7 for <dispatch@core3.amsl.com>; Fri, 22 May 2009 10:19:16 -0700 (PDT)
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=[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 Ye-OhoqYpS5C for <dispatch@core3.amsl.com>; Fri, 22 May 2009 10:19:15 -0700 (PDT)
Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 7794C3A6C43 for <dispatch@ietf.org>; Fri, 22 May 2009 10:19:15 -0700 (PDT)
Received: from c-68-38-227-227.hsd1.nj.comcast.net ([68.38.227.227] helo=alan-johnstons-powerbook-g4-17.local) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from <alan@sipstation.com>) id 1M7YQP-0008Dg-RF; Fri, 22 May 2009 17:20:54 +0000
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 68.38.227.227
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX1/Z9M6FGj0r++lXJKSdEuUABZmsL71GwW8=
Message-ID: <4A16DEF2.1010505@sipstation.com>
Date: Fri, 22 May 2009 12:20:50 -0500
From: Alan Johnston <alan@sipstation.com>
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
MIME-Version: 1.0
To: dispatch@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Joanne McMillen <joanne@avaya.com>
Subject: [dispatch] Call Control UUI Problem Statement
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 May 2009 17:19:16 -0000

Several approaches to transporting the ITU-T Q.931 User to User 
Information Element (UU IE) data in SIP have been proposed.  As networks 
move to SIP it is important that applications requiring this data can 
continue to function in SIP networks as well as the ability to interwork 
with this ISDN service for end-to-end transparency.  While the 
information is carried in ISUP, the contents can be in a number of 
protocols that are not ISUP, and as such it is architecturally 
unreasonable to interwork these protocols at the SIP / ISUP gateway. 
This work area involves defining a new SIP mechanism to transport this 
information. 

Since the INFO method, RFC2976, was developed for ISUP interworking of 
user-to-user information, it might seem to be the logical choice here.  
For non-call control user-to-user information, INFO can be utilized for 
end to end transport.  However, for transport of call control 
user-to-user information, INFO can not be used.  Since the contents 
carry information that can impact call handling at the UAC, the 
information must be conveyed with the INVITE transaction.  As the call 
flows in the previous section show, the information is related to an 
attempt to establish a session and must be passed with the session setup 
request (INVITE), responses to that INVITE, or session termination 
requests.  As a result, it is not possible to use INFO in these cases.

Also, the use of message body is another obvious mechanism, but this is 
not suitable for a number of reasons including difficulty with multipart 
MIME INVITEs and 200 OKs, and in escaping UUI information into redirects 
and REFERs.

The I-D draft-johnston-sipping-cc-uui will be used as the basis for this 
work.  This draft was first submitted 3 years ago and has had plenty of 
discussion in the old SIPPING Working Group.  The requirements in this 
document completed a WGLC in SIPPING in December 2008 with strong 
support from the group.  This draft proposes a new SIP header field 
User-to-User and parameters for transporting this information.

This extension will also be used for native SIP endpoints implementing 
similar services and interworking with ISDN services.  Example use cases 
include an exchange between two user agents, retargeting by a proxy, and 
redirection.  An example application is an Automatic Call Distributor 
(ACD) in a contact center.

The coordinators for this work will be Alan Johnston 
<alan@sipstation.com> and Keith Drage <drage@alcatel-lucent.com>

Thanks,
Alan



From dean.willis@softarmor.com  Fri May 22 13:49:54 2009
Return-Path: <dean.willis@softarmor.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2FC53A6EC0 for <dispatch@core3.amsl.com>; Fri, 22 May 2009 13:49:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.381
X-Spam-Level: 
X-Spam-Status: No, score=-2.381 tagged_above=-999 required=5 tests=[AWL=0.218,  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 EDj3mU2RAJGD for <dispatch@core3.amsl.com>; Fri, 22 May 2009 13:49:53 -0700 (PDT)
Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id DD7AF3A6A6A for <dispatch@ietf.org>; Fri, 22 May 2009 13:49:52 -0700 (PDT)
Received: from [192.168.2.2] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n4MKpRQP020164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 22 May 2009 15:51:29 -0500
Message-ID: <4A17104A.80706@softarmor.com>
Date: Fri, 22 May 2009 15:51:22 -0500
From: Dean Willis <dean.willis@softarmor.com>
User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103)
MIME-Version: 1.0
To: Alan Johnston <alan@sipstation.com>
References: <4A16DEF2.1010505@sipstation.com>
In-Reply-To: <4A16DEF2.1010505@sipstation.com>
X-Enigmail-Version: 0.95.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Joanne McMillen <joanne@avaya.com>, dispatch@ietf.org
Subject: Re: [dispatch] Call Control UUI Problem Statement
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 May 2009 20:49:54 -0000

Alan Johnston wrote:
> Since the INFO method, RFC2976, was developed for ISUP interworking of
> user-to-user information, it might seem to be the logical choice here. 
> For non-call control user-to-user information, INFO can be utilized for
> end to end transport.  However, for transport of call control
> user-to-user information, INFO can not be used.  Since the contents
> carry information that can impact call handling at the UAC, the
> information must be conveyed with the INVITE transaction.  As the call
> flows in the previous section show, the information is related to an
> attempt to establish a session and must be passed with the session setup
> request (INVITE), responses to that INVITE, or session termination
> requests.  As a result, it is not possible to use INFO in these cases.

I favor extending the approach of INFO packages to allow inclusion of
informational bodies in other transactions, notably INVITE.

This lets us re-use the negotiation and encoding mechanisms already
painfully worked out for INFO, and keeps us from having to invent yet
another method for semantic content negotiation, which I see as the
weakness of the UUI-as-a-new-header-field approach that has been proposed.

Further, I really think that the headers belong in the realm of the SIP
protocol machine, whereas the bodies belong to the applications that sue
SIP. Extending SIP with application-specific header fields feels like a
layer violation; we already have enough of those and I'd like to avoid
introducing more.

>From a DISPATCH perspective, this raises the question of where to do the
work.

I'm inclined to propose a new working group, which I'll tentatively call
INFORM. The INFORM working group would assume responsibility for
informational supplementation of SIP messages, including finishing the
INFO packages work, and addressing the requirements of UUI as raised in
Alan's draft. I'd also propose a third deliverable, which would be an
informational document giving guidance on the usage of SIP's
user-to-user informational extensions, perhaps a design-usage tutorial.

So, three deliverables, a fairly mature problem statement for UUI and a
very mature document for INFO combine to give us a manageable,
achieveable scope. This is exactly the sort of short-lived,
narrowly-defined working group I've been saying we need to use to
replace the nigh-immortal behemoths like SIP and SIPPING and that we
need to be able to spin up in order to keep SIPCORE and DISPATCH from
turning into undead reanimations of SIP and SIPPING. Zombies may be
fashionable, but they don't make for effective management models.

Of course, we could call the new working group SINFORM for "Sip
INFORMation". That has a nice ring to it...

--
Dean


From christer.holmberg@ericsson.com  Mon May 25 11:56:50 2009
Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C050A3A6359 for <dispatch@core3.amsl.com>; Mon, 25 May 2009 11:56:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.88
X-Spam-Level: 
X-Spam-Status: No, score=-5.88 tagged_above=-999 required=5 tests=[AWL=0.369,  BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 5TIyprXt9Nqg for <dispatch@core3.amsl.com>; Mon, 25 May 2009 11:56:43 -0700 (PDT)
Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 830183A6F4E for <dispatch@ietf.org>; Mon, 25 May 2009 11:56:40 -0700 (PDT)
X-AuditID: c1b4fb3c-b7b94ae000000eff-d8-4a1aea4c86e4
Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 0F.AC.03839.C4AEA1A4; Mon, 25 May 2009 20:58:20 +0200 (CEST)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Mon, 25 May 2009 20:58:19 +0200
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: Mon, 25 May 2009 20:58:19 +0200
Message-ID: <CA9998CD4A020D418654FCDEF4E707DF0B168269@esealmw113.eemea.ericsson.se>
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1DE6C5C0@zrc2hxm0.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dispatch] IETF-75 plans for DISPATCH - CBUS requirements
Thread-Index: AcnNtXrnlTE+ihrURvGZPoNhaaFPuABmOAxgAC3W45ADPNzhkA==
References: <1ECE0EB50388174790F9694F77522CCF1DE6C5C0@zrc2hxm0.corp.nortel.com>
From: "Christer Holmberg" <christer.holmberg@ericsson.com>
To: "Mary Barnes" <mary.barnes@nortel.com>, <dispatch@ietf.org>, "Gonzalo Camarillo" <gonzalo.camarillo@ericsson.com>
X-OriginalArrivalTime: 25 May 2009 18:58:19.0749 (UTC) FILETIME=[C4F5E150:01C9DD6A]
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [dispatch] IETF-75 plans for DISPATCH - CBUS requirements
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 May 2009 18:56:50 -0000

=20
Hi,

I am planning to submit a draft later this week, which defines the SIP
requirements for the CBUS (Condition-based URI Selection) work currently
being done in OMA.

Regards,

Christer



> -----Original Message-----
> From: dispatch-bounces@ietf.org=20
> [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes
> Sent: 8. toukokuuta 2009 20:54
> To: dispatch@ietf.org
> Cc: rai-ads@tools.ietf.org
> Subject: [dispatch] IETF-75 plans for DISPATCH
>=20
> Hi all,
>=20
> As mentioned previously, we are setting earlier deadlines for=20
> discussing topics in DISPATCH to allow time for constructive=20
> discussions prior to the WG session at IETF-75:=20
> http://www.ietf.org/mail-archive/web/dispatch/current/msg00006.html
>=20
> We are proposing to follow the deadlines for BoFs for IETF-75:
> http://www.ietf.org/meetings/75/cutoff-dates.html
> since we anticipate that many of the topic discussions will=20
> follow a "mini-BoF" format, based on the DISPATCH charter:
> http://www.ietf.org/html.charters/dispatch-charter.html
>=20
> Thus, the following are the proposed deadlines:
>=20
> May 25th - Cutoff date to notify the chairs and DISPATCH WG=20
> mailing list of plans to submit a proposal, including the=20
> topic of the proposal. This will help folks with similar=20
> topics to work together before the meeting.
> If a preliminary charter proposal is available at this point,=20
> please include a pointer to it.
>=20
> June 8th - Cutoff for charter proposals for topics. A charter=20
> proposal must consist of a minimum of a problem statement and=20
> at least one milestone/deliverable. This deadline will allow=20
> time for consideration of proposals that could potentially be=20
> "dispatched" prior to the WG session.
>=20
> June 15th - Topics that are to be the focus of IETF-75 are announced.
> The idea here is to focus the discussion over the weeks preceding
> IETF-75 on these main topics, noting that any updates to the=20
> documents are due 4 weeks later.  This will ensure we have=20
> constructive discussions before the meeting and are actually=20
> able to determine consensus as to where work should be=20
> progressed (e.g., separate BoF, a new WG, an existing WG,=20
> individual document, etc.) at IETF-75. Contrary to the past=20
> approach in the SIPPING WG, we anticipate determining=20
> consensus as to the disposition of a work item based on the=20
> level of "commitment" by individuals to actually contribute=20
> to the work (e.g., conference calls, design team mailing=20
> lists, contributing text, etc.) rather than based on=20
> "interest" in doing the work.  Note, that the exact=20
> disposition for a topic may (per the usual process) require=20
> follow-up and confirmation by the ADS and/or IESG (e.g., for=20
> a new WG, Bof, individually sponsored document, etc.) or with=20
> another WG to ensure agreement with the DISPATCH WG consensus=20
> for the topic.
>=20
> Note the intention is not necessarily to preclude folks=20
> submitting documents on other topics, however, it is very=20
> unlikely there would be agenda time allocated to=20
> documents/topics submitted after the deadlines.
> We can include one or two slides on these topics in the=20
> DISPATCH WG chair charts, as we've done in the past in the=20
> SIPPING WG chair charts, so that the authors can gather other=20
> interested parties to contribute to the work.=20
>=20
> We appreciate the patience of the WG as we evolve the model=20
> for bringing in new work and welcome feedback.=20
>=20
> Regards,
> Mary and Gonzalo
> DISPATCH WG co-chairs=20
>=20
>=20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>=20

From mizuno.shintaro@lab.ntt.co.jp  Mon May 25 14:58:57 2009
Return-Path: <mizuno.shintaro@lab.ntt.co.jp>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 494E13A6A6A for <dispatch@core3.amsl.com>; Mon, 25 May 2009 14:58:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.11
X-Spam-Level: ***
X-Spam-Status: No, score=3.11 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_33=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 8layFSsEjFio for <dispatch@core3.amsl.com>; Mon, 25 May 2009 14:58:56 -0700 (PDT)
Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by core3.amsl.com (Postfix) with ESMTP id A31C03A67D2 for <dispatch@ietf.org>; Mon, 25 May 2009 14:58:52 -0700 (PDT)
Received: from mfs6.rdh.ecl.ntt.co.jp (mfs6.rdh.ecl.ntt.co.jp [129.60.39.149]) by tama500.ecl.ntt.co.jp (8.14.2/8.14.2) with ESMTP id n4PM0V5b022823; Tue, 26 May 2009 07:00:31 +0900 (JST)
Received: from mfs6.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id E7A336603; Tue, 26 May 2009 07:00:30 +0900 (JST)
Received: from img.m.ecl.ntt.co.jp (img.m.ecl.ntt.co.jp [129.60.5.231]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id D0F136600; Tue, 26 May 2009 07:00:30 +0900 (JST)
Received: from gwras.ecl.ntt.co.jp (webras.ecl.ntt.co.jp [129.60.57.68]) by img.m.ecl.ntt.co.jp (8.13.8/8.13.8) with SMTP id n4PM0U4D016114; Tue, 26 May 2009 07:00:30 +0900 (JST)
Message-Id: <200905252200.n4PM0U4D016114@img.m.ecl.ntt.co.jp>
From: "Shintaro Mizuno" <mizuno.shintaro@lab.ntt.co.jp>
To: dispatch@ietf.org
X-Mailer: Html Mime Mail Class
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
MasGrpSmtpServerHost: img.m.ecl.ntt.co.jp
MasGrpSmtpServerPort: 25
MasGrpPolicyRtgTable: main
Date: Tue, 26  May  2009 07:00:29 +0900
Cc: ma.saito@nttv6.jp
Subject: [dispatch] =?iso-8859-1?q?Charter_Proposal?=
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 May 2009 21:58:57 -0000

Dear WG Chair, ML members,

We would like to propose the following charter for on-demand Media/Application sharing between peers over VPN.
We've been discussing on this topic with authors of "draft-saito-mmusic-sdp-ike-04" and we thought this WG would be suitable place for further discussion.

We appreciate any feedback.

---------
"Charter Proposal for on-demand Media/Application Sharing between peers over VPN"

Intent:
 The intent of this charter is to see interests in documenting what's being deployed as an informational for on-demand Media/Application sharing between peers over VPN using SIP and discuss what in the overall effort may be standardized at IETF in the future.


Problem Statement: 
 Home servers or network-capable consumer electronic devices are becoming widely deployed and people using such devices are wanting to share contents or applications and are seeking a way to establish multitudes of communication with each other.  

 In order to allow two people to share contents or application securely using popular LAN based communication tool such as DLNA on devices that are sitting at home, secure LAN (VPN) establishments between these user devices are necessary. 
 Applications that use proprietary or multi-session protocols such as in some of LAN-based gaming will also benifit from VPN connections when users attempt to communicate remotely.

 For a deployment that's underway and considered by several other standard bodies, problem of establishing VPN between these user devices were that current standards for establishing VPN didn't provide all the toolset necessary to overcome some of the obstacles. 

 Namely following issues were found;
  (1) Name resolution mechanism under floating IP addresses and port numbers
  (2) NAT traversal and hole-punching of firewall
  (3) Authentication/authorization of users.
  (4) Pre-sharing of key for establishing VPN isn't easy when VPN is to be established on-demand between two user devices without any previous affiliation.

As a result current deployment based on "draft-saito-mmusic-sdp-ike-04" and other standard bodies are looking at the use of SIP for the following reasons. 

 (1)Name resolution can be achieved by using REGISTER method and SDP negotiation
 (2)NAT traversal and hole-punching of firewall can be achieved by applying SIP+ICE.
 (3)Authentication/authorization can be achieved by having trusted SIP proxy and user friendly SIP-URIs.

Use-cases that may see use for such standard effort;
  - Media sharing using DLNA or similar protocol over VPN between 2 users' devices.
  - Remote desktop sharing for Customer service over VPN initiated via SIP call.
    * Similar to click to call, customer service agent can access user's pc remotely to troubleshoot the problem customer is facing from the call.
  - Accessing medical equipments(medical robotics) remotely and possibly controlling medical equipments to monitor elders in a rural area that (remote care services). 
  - LAN based gaming protocol to be established peer to peer rather than via gaming server.


Discussion Point:
 - To see interests in documenting what's being deployed based on "draft-saito-mmusic-sdp-ike-04" as an  informational document. 
http://tools.ietf.org/html/draft-saito-mmusic-sdp-ike-04
 - To see interests in standardizing toolset for realizing use-cases similar to what's mentioned above, even contemplating the possibility of defining a guideline for SIP usage where SIP is used only as a rendezvous  protocol.

------------


Best Regards,

Shintaro

-----------------------------
Shintaro Mizuno
NTT Information Sharing Platform Laboratories
NTT Corporation
mizuno.shintaro@lab.ntt.co.jp


From fanyanping@huawei.com  Mon May 25 17:53:14 2009
Return-Path: <fanyanping@huawei.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 935B93A6B4E for <dispatch@core3.amsl.com>; Mon, 25 May 2009 17:53:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.131
X-Spam-Level: ****
X-Spam-Status: No, score=4.131 tagged_above=-999 required=5 tests=[AWL=0.679,  BAYES_50=0.001, HTML_MESSAGE=0.001, J_BACKHAIR_12=1, MIME_CHARSET_FARAWAY=2.45]
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 UjaKueNzHNHa for <dispatch@core3.amsl.com>; Mon, 25 May 2009 17:53:09 -0700 (PDT)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id CFC9C3A6B8B for <dispatch@ietf.org>; Mon, 25 May 2009 17:53:08 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KK8009566TWV3@szxga03-in.huawei.com> for dispatch@ietf.org; Tue, 26 May 2009 08:32:20 +0800 (CST)
Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KK80080E6TVY2@szxga03-in.huawei.com> for dispatch@ietf.org; Tue, 26 May 2009 08:32:20 +0800 (CST)
Received: from f00134301 ([10.85.29.39]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KK800JOP6TV2K@szxml06-in.huawei.com> for dispatch@ietf.org; Tue, 26 May 2009 08:32:19 +0800 (CST)
Date: Tue, 26 May 2009 08:32:19 +0800
From: fanyanping <fanyanping@huawei.com>
To: dispatch@ietf.org, scott.lawrence@nortel.com
Message-id: <003c01c9dd99$6de66400$271d550a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Office Outlook 11
Content-type: multipart/alternative; boundary="Boundary_(ID_M8LXu9JZcdg6tqGfsrLLlw)"
Thread-index: AcndmW20ce8n31vtSN+JP/fjWh/3TA==
Subject: Re: [dispatch] draft-lawrence-sip-3rd-party-authorization-00
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 May 2009 00:53:14 -0000

This is a multi-part message in MIME format.

--Boundary_(ID_M8LXu9JZcdg6tqGfsrLLlw)
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: quoted-printable

Hi Scott=A3=AC

I spend some time reading your draft=A3=ACthere is one place i =
don=A1=AFt understand
clearly, could you please explain more detail, thanks.

=A1=B0The requirement for adjacency interferes with a property of SIP =
that is
otherwise one of its great strengths: that a proxy (or other =
well-behaved
Intermediate) need not understand every aspect of the requests and =
responses
it forwards. =A1=A3=A1=A3=A1=A3=A1=A3=A1=A3=A1=A3=A1=A3=A1=A3=A1=B0

I=A1=AFm understanding that you imply a new feature needs the =
Intermediate
entites which make the authorization decision to be upgraded. =
However=A3=ACIs
there something associated with adjacency?

=20

In addition, i agree that the issues described in your draft are really =
very
important. But I don=A1=AFt understand clearly how the requirement of
=A1=B0Authorizing Third Party=A1=B1 can solve them. I can=A1=AFt get the =
requirements
you proposed from these problems.

=20

=20

=20

PS:=20

there is one suggestion about the section 2.2, I think the following
paragraphs could be in the section 2.2.1 and have a new title =A1=B0User =
Agent
Based Authorization=A1=B1. Because all of them are describing the =
problems of
=A1=B0User Agent Based Authorization=A1=B1.

=20

Specific paragraphs as below:

from

=A1=B0   Most specifications of SIP mechanisms expect that a request =
will be

    subjected to an authorization decision by the receiving User Agent

    Server.  If the Alice's UA sends a request to Bob's UA, it is Bob's

    UA that decides (presumably after authenticating that the request is

    really from Alice) whether or not Alice should be allowed whatever

    access the request requires.  This model is the correct one in many

    cases, especially those in which the actual authorization decision

=20

to

      The request might be such that the user either could not

      understand the question or be such that the user cannot reasonably

      be expected to understand why permission should be granted.  If

      Bob were asked whether or not Alice should be allowed to receive

      dialog event notices regarding the call he is on now, he would

      probably not understand the question and be annoyed at the

      interruption of his call; he could not tell whether this was in

      support of a future request to Join the call, a future request

      that Alice be able to call him when he becomes available, or just

      in support of lighting the Busy Lamp for his line on Alice's

      phone.=A1=B1

=20

If there is any problem, please correct me. thanks :)

=20

=20

Best Regards.

nancy

*******************************************************************
This email and its attachments contain confidential information from =
HUAWEI,
which is intended only for the person or entity whose address is listed
above.
Any use of the information contained herein in any way (including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons
other than the intended recipient(s) is prohibited. If you receive this
e-mail in error,
please notify the sender by phone or email immediately and delete it!
*******************************************************************
=20

--Boundary_(ID_M8LXu9JZcdg6tqGfsrLLlw)
Content-type: text/html; charset=gb2312
Content-transfer-encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dgb2312">
<META content=3D"MSHTML 6.00.2900.3527" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT size=3D2>
<DIV><FONT size=3D2>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><FONT size=3D3><SPAN =
lang=3DEN-US=20
style=3D"FONT-FAMILY: 'FrutigerNext LT Regular'; mso-bidi-font-size: =
10.5pt"><FONT=20
face=3D"Times New Roman">Hi Scott</FONT></SPAN><SPAN=20
style=3D"FONT-FAMILY: =CB=CE=CC=E5; mso-bidi-font-size: 10.5pt; =
mso-ascii-font-family: 'FrutigerNext LT Regular'; mso-hansi-font-family: =
'FrutigerNext LT Regular'">=A3=AC</SPAN><SPAN=20
lang=3DEN-US=20
style=3D"FONT-FAMILY: 'FrutigerNext LT Regular'; mso-bidi-font-size: =
10.5pt"><?xml:namespace=20
prefix =3D o ns =3D "urn:schemas-microsoft-com:office:office"=20
/><o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><FONT size=3D3><SPAN =
lang=3DEN-US=20
style=3D"FONT-FAMILY: 'FrutigerNext LT Regular'; mso-bidi-font-size: =
10.5pt"><FONT=20
face=3D"Times New Roman">I spend some time reading your =
draft</FONT></SPAN><SPAN=20
style=3D"FONT-FAMILY: =CB=CE=CC=E5; mso-bidi-font-size: 10.5pt; =
mso-ascii-font-family: 'FrutigerNext LT Regular'; mso-hansi-font-family: =
'FrutigerNext LT Regular'">=A3=AC</SPAN><SPAN=20
lang=3DEN-US=20
style=3D"FONT-FAMILY: 'FrutigerNext LT Regular'; mso-bidi-font-size: =
10.5pt"><FONT=20
face=3D"Times New Roman">there is one place i don=A1=AFt understand =
clearly, could you=20
please explain more detail, thanks.<o:p></o:p></FONT></SPAN></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><FONT size=3D3><SPAN =
lang=3DEN-US=20
style=3D"FONT-FAMILY: 'FrutigerNext LT Regular'; mso-bidi-font-size: =
10.5pt"><FONT=20
face=3D"Times New Roman">=A1=B0The requirement for adjacency interferes =
with a property=20
of SIP that is otherwise one of its great strengths: that a proxy (or =
other=20
well-behaved Intermediate) need not understand every aspect of the =
requests and=20
responses it forwards. </FONT></SPAN><SPAN=20
style=3D"FONT-FAMILY: =CB=CE=CC=E5; mso-bidi-font-size: 10.5pt; =
mso-ascii-font-family: 'FrutigerNext LT Regular'; mso-hansi-font-family: =
'FrutigerNext LT =
Regular'">=A1=A3=A1=A3=A1=A3=A1=A3=A1=A3=A1=A3=A1=A3=A1=A3</SPAN><SPAN=20
lang=3DEN-US=20
style=3D"FONT-FAMILY: 'FrutigerNext LT Regular'; mso-bidi-font-size: =
10.5pt"><FONT=20
face=3D"Times New Roman">=A1=B0<o:p></o:p></FONT></SPAN></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><FONT size=3D3><SPAN =
lang=3DEN-US=20
style=3D"FONT-FAMILY: 'FrutigerNext LT Regular'; mso-bidi-font-size: =
10.5pt"><FONT=20
face=3D"Times New Roman">I=A1=AFm understanding that you imply a new =
feature needs the=20
Intermediate entites which make the authorization decision to be =
upgraded.=20
However</FONT></SPAN><SPAN=20
style=3D"FONT-FAMILY: =CB=CE=CC=E5; mso-bidi-font-size: 10.5pt; =
mso-ascii-font-family: 'FrutigerNext LT Regular'; mso-hansi-font-family: =
'FrutigerNext LT Regular'">=A3=AC</SPAN><SPAN=20
lang=3DEN-US=20
style=3D"FONT-FAMILY: 'FrutigerNext LT Regular'; mso-bidi-font-size: =
10.5pt"><FONT=20
face=3D"Times New Roman">Is there something associated with=20
adjacency?<o:p></o:p></FONT></SPAN></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"FONT-FAMILY: 'FrutigerNext LT Regular'; mso-bidi-font-size: =
10.5pt"><o:p><FONT=20
face=3D"Times New Roman" size=3D3>&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"FONT-FAMILY: 'FrutigerNext LT Regular'; mso-bidi-font-size: =
10.5pt"><FONT=20
face=3D"Times New Roman" size=3D3>In addition, i agree that the issues =
described in=20
your draft are really very important. But I don=A1=AFt understand =
clearly how the=20
requirement of =A1=B0</FONT></SPAN><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: 'Courier New'; =
mso-font-kerning: 0pt"><FONT=20
color=3D#000000>Authorizing Third Party=A1=B1 can solve them. I =
can=A1=AFt get the=20
requirements you proposed from these problems.</FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: 'Courier New'; =
mso-font-kerning: 0pt"><FONT=20
color=3D#000000></FONT></SPAN>&nbsp;</P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: 'Courier New'; =
mso-font-kerning: 0pt"><FONT=20
color=3D#000000><o:p></o:p></FONT></SPAN>&nbsp;</P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"FONT-FAMILY: 'FrutigerNext LT Regular'; mso-bidi-font-size: =
10.5pt"><o:p><FONT=20
face=3D"Times New Roman" size=3D3>&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"FONT-FAMILY: 'FrutigerNext LT Regular'; mso-bidi-font-size: =
10.5pt"><FONT=20
face=3D"Times New Roman"><FONT size=3D3><SPAN =
class=3D977171201-25052009>PS:=20
</SPAN></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"FONT-FAMILY: 'FrutigerNext LT Regular'; mso-bidi-font-size: =
10.5pt"><FONT=20
face=3D"Times New Roman"><FONT size=3D3><SPAN =
class=3D977171201-25052009></SPAN>there=20
is one suggestion about the section 2.2, I think the following =
paragraphs could=20
be in the section <?xml:namespace prefix =3D st1 ns =3D=20
"urn:schemas-microsoft-com:office:smarttags" /><st1:chsdate w:st=3D"on"=20
IsROCDate=3D"False" IsLunarDate=3D"False" Day=3D"30" Month=3D"12"=20
Year=3D"1899"><st1:chsdate w:st=3D"on" IsROCDate=3D"False" =
IsLunarDate=3D"False"=20
Day=3D"30" Month=3D"12" Year=3D"1899">2.2.1</st1:chsdate> =
a</st1:chsdate>nd have a new=20
title =A1=B0</FONT></FONT></SPAN><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: 'Courier New'; =
mso-font-kerning: 0pt"><FONT=20
color=3D#000000>User Agent Based Authorization=A1=B1. Because all of =
them are=20
describing the problems of =A1=B0User Agent Based =
Authorization=A1=B1.</FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: 'Courier New'; =
mso-font-kerning: 0pt"><FONT=20
color=3D#000000><o:p></o:p></FONT></SPAN>&nbsp;</P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"FONT-FAMILY: 'Courier New'"><FONT size=3D3>Specific paragraphs =
as=20
below:<o:p></o:p></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><FONT size=3D3><SPAN =
lang=3DEN-US=20
style=3D"FONT-FAMILY: 'Courier New'">from</SPAN><SPAN lang=3DEN-US=20
style=3D"FONT-FAMILY: 'FrutigerNext LT Regular'; mso-bidi-font-size: =
10.5pt"><o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt; TEXT-ALIGN: left; mso-layout-grid-align: =
none"=20
align=3Dleft><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier New'; =
mso-font-kerning: 0pt">=A1=B0<SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>Most specifications of =
SIP=20
mechanisms expect that a request will be<o:p></o:p></SPAN></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt; TEXT-ALIGN: left; mso-layout-grid-align: =
none"=20
align=3Dleft><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier New'; =
mso-font-kerning: 0pt"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp; </SPAN><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;</SPAN><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;</SPAN>subjected to an authorization =
decision by=20
the receiving User Agent<o:p></o:p></SPAN></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt; TEXT-ALIGN: left; mso-layout-grid-align: =
none"=20
align=3Dleft><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier New'; =
mso-font-kerning: 0pt"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;</SPAN>Server.<SPAN=20
style=3D"mso-spacerun: yes">&nbsp; </SPAN>If the <st1:City =
w:st=3D"on"><st1:place=20
w:st=3D"on">Alice</st1:place></st1:City>'s UA sends a request to Bob's =
UA, it is=20
Bob's<o:p></o:p></SPAN></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt; TEXT-ALIGN: left; mso-layout-grid-align: =
none"=20
align=3Dleft><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier New'; =
mso-font-kerning: 0pt"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;</SPAN>UA that decides (presumably =
after=20
authenticating that the request is<o:p></o:p></SPAN></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt; TEXT-ALIGN: left; mso-layout-grid-align: =
none"=20
align=3Dleft><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier New'; =
mso-font-kerning: 0pt"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp; </SPAN><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;</SPAN><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;</SPAN>really from <st1:City=20
w:st=3D"on">Alice</st1:City>) whether or not <st1:place =
w:st=3D"on"><st1:City=20
w:st=3D"on">Alice</st1:City></st1:place> should be allowed=20
whatever<o:p></o:p></SPAN></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt; TEXT-ALIGN: left; mso-layout-grid-align: =
none"=20
align=3Dleft><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier New'; =
mso-font-kerning: 0pt"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;</SPAN>access the request =
requires.<SPAN=20
style=3D"mso-spacerun: yes">&nbsp; </SPAN>This model is the correct one =
in=20
many<o:p></o:p></SPAN></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt; TEXT-ALIGN: left; mso-layout-grid-align: =
none"=20
align=3Dleft><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier New'; =
mso-font-kerning: 0pt"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;</SPAN>cases, especially those in =
which the=20
actual authorization decision<o:p></o:p></SPAN></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt; TEXT-ALIGN: left; mso-layout-grid-align: =
none"=20
align=3Dleft><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier New'; =
mso-font-kerning: 0pt"><o:p>&nbsp;</o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"FONT-FAMILY: 'FrutigerNext LT Regular'; mso-bidi-font-size: =
10.5pt"><FONT=20
size=3D3><FONT face=3D"Times New =
Roman">to<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt; TEXT-ALIGN: left; mso-layout-grid-align: =
none"=20
align=3Dleft><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier New'; =
mso-font-kerning: 0pt"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>The =
request=20
might be such that the user either could not<o:p></o:p></SPAN></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt; TEXT-ALIGN: left; mso-layout-grid-align: =
none"=20
align=3Dleft><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier New'; =
mso-font-kerning: 0pt"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN>understand the=20
question or be such that the user cannot =
reasonably<o:p></o:p></SPAN></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt; TEXT-ALIGN: left; mso-layout-grid-align: =
none"=20
align=3Dleft><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier New'; =
mso-font-kerning: 0pt"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>be =
expected to=20
understand why permission should be granted.<SPAN=20
style=3D"mso-spacerun: yes">&nbsp; </SPAN>If<o:p></o:p></SPAN></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt; TEXT-ALIGN: left; mso-layout-grid-align: =
none"=20
align=3Dleft><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier New'; =
mso-font-kerning: 0pt"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>Bob =
were asked=20
whether or not <st1:City w:st=3D"on"><st1:place=20
w:st=3D"on">Alice</st1:place></st1:City> should be allowed to=20
receive<o:p></o:p></SPAN></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt; TEXT-ALIGN: left; mso-layout-grid-align: =
none"=20
align=3Dleft><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier New'; =
mso-font-kerning: 0pt"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>dialog =
event=20
notices regarding the call he is on now, he would<o:p></o:p></SPAN></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt; TEXT-ALIGN: left; mso-layout-grid-align: =
none"=20
align=3Dleft><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier New'; =
mso-font-kerning: 0pt"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN>probably not=20
understand the question and be annoyed at the<o:p></o:p></SPAN></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt; TEXT-ALIGN: left; mso-layout-grid-align: =
none"=20
align=3Dleft><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier New'; =
mso-font-kerning: 0pt"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN>interruption of=20
his call; he could not tell whether this was in<o:p></o:p></SPAN></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt; TEXT-ALIGN: left; mso-layout-grid-align: =
none"=20
align=3Dleft><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier New'; =
mso-font-kerning: 0pt"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN>support of a=20
future request to Join the call, a future request<o:p></o:p></SPAN></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt; TEXT-ALIGN: left; mso-layout-grid-align: =
none"=20
align=3Dleft><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier New'; =
mso-font-kerning: 0pt"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>that =
<st1:place=20
w:st=3D"on"><st1:City w:st=3D"on">Alice</st1:City></st1:place> be able =
to call him=20
when he becomes available, or just<o:p></o:p></SPAN></P>
<P class=3DMsoNormal=20
style=3D"MARGIN: 0cm 0cm 0pt; TEXT-ALIGN: left; mso-layout-grid-align: =
none"=20
align=3Dleft><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier New'; =
mso-font-kerning: 0pt"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>in =
support of=20
lighting the Busy Lamp for his line on <st1:place w:st=3D"on"><st1:City=20
w:st=3D"on">Alice</st1:City></st1:place>'s<o:p></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier New'; =
mso-font-kerning: 0pt"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</SPAN></SPAN><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: black; FONT-FAMILY: 'Courier New'; =
mso-font-kerning: 0pt; mso-ansi-language: =
ZH-CN">phone.=A1=B1</SPAN><SPAN=20
lang=3DEN-US=20
style=3D"FONT-FAMILY: 'FrutigerNext LT Regular'; mso-bidi-font-size: =
10.5pt"><o:p></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"FONT-FAMILY: 'FrutigerNext LT Regular'; mso-bidi-font-size: =
10.5pt"><o:p><FONT=20
face=3D"Times New Roman" size=3D3>&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"FONT-FAMILY: 'FrutigerNext LT Regular'; mso-bidi-font-size: =
10.5pt"><FONT=20
face=3D"Times New Roman"><FONT size=3D3>If there is any problem, please =
correct=20
me.<SPAN class=3D977171201-25052009> thanks=20
</SPAN>:)<o:p></o:p></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"FONT-FAMILY: 'FrutigerNext LT Regular'; mso-bidi-font-size: =
10.5pt"><o:p><FONT=20
face=3D"Times New Roman" size=3D3>&nbsp;</FONT></o:p></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm =
0pt"></FONT>&nbsp;</P></DIV>
<DIV align=3Dleft>
<P class=3DMsoNormal align=3Dleft><FONT face=3D"Times New Roman" =
size=3D2><SPAN=20
lang=3DEN-US style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New =
Roman'">Best=20
Regards.</SPAN></FONT></P>
<P class=3DMsoNormal align=3Dleft><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'"></SPAN><SPAN=20
lang=3DEN-US><o:p><SPAN class=3D977171201-25052009><FONT face=3D"Times =
New Roman"=20
size=3D2>nancy</FONT></SPAN></o:p></SPAN></FONT></P></DIV></DIV>
<DIV align=3Dleft>
<DIV><FONT face=3D"Times New Roman" size=3D2><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New Roman'">
<DIV><FONT face=3D"Times New Roman" size=3D2><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Times New =
Roman'">*****************************************************************=
**<BR>This=20
email and its attachments contain confidential information from =
HUAWEI,<BR>which=20
is intended only for the person or entity whose address is listed =
above.<BR>Any=20
use of the information contained herein in any way (including,<BR>but =
not=20
limited to, total or partial disclosure, reproduction, or dissemination) =
by=20
persons<BR>other than the intended recipient(s) is prohibited. If you =
receive=20
this e-mail in error,<BR>please notify the sender by phone or email =
immediately=20
and delete=20
it!<BR>******************************************************************=
*</SPAN></FONT><SPAN=20
lang=3DEN-US><o:p></o:p></SPAN></DIV></SPAN></FONT></DIV></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

--Boundary_(ID_M8LXu9JZcdg6tqGfsrLLlw)--

From scott.lawrence@nortel.com  Tue May 26 07:43:08 2009
Return-Path: <scott.lawrence@nortel.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9327828C31A for <dispatch@core3.amsl.com>; Tue, 26 May 2009 07:43:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.064
X-Spam-Level: 
X-Spam-Status: No, score=-6.064 tagged_above=-999 required=5 tests=[AWL=0.535,  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 vEFIBlfbBXsg for <dispatch@core3.amsl.com>; Tue, 26 May 2009 07:43:07 -0700 (PDT)
Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 24C943A710B for <dispatch@ietf.org>; Tue, 26 May 2009 07:41:35 -0700 (PDT)
Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n4QEgwa12676; Tue, 26 May 2009 14:42:59 GMT
Received: from [127.0.0.1] ([47.17.25.99]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 May 2009 10:42:57 -0400
From: "Scott Lawrence" <scott.lawrence@nortel.com>
To: fanyanping <fanyanping@huawei.com>
In-Reply-To: <003c01c9dd99$6de66400$271d550a@china.huawei.com>
References: <003c01c9dd99$6de66400$271d550a@china.huawei.com>
Content-Type: text/plain; charset="UTF-8"
Organization: Nortel Networks
Date: Tue, 26 May 2009 14:42:56 +0000
Message-Id: <1243348976.3432.4114.camel@host.home.skrb.org>
Mime-Version: 1.0
X-Mailer: Evolution 2.24.5 (2.24.5-1.fc10) 
Content-Transfer-Encoding: quoted-printable
X-OriginalArrivalTime: 26 May 2009 14:42:57.0770 (UTC) FILETIME=[42C32CA0:01C9DE10]
Cc: dispatch@ietf.org
Subject: Re: [dispatch] draft-lawrence-sip-3rd-party-authorization-00
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 May 2009 14:43:08 -0000

On Tue, 2009-05-26 at 08:32 +0800, fanyanping wrote:
> Hi Scott=EF=BC=8C
>=20
> I spend some time reading your draft=EF=BC=8Cthere is one place i don=E2=
=80=99t
> understand clearly, could you please explain more detail, thanks.
>=20
> =E2=80=9CThe requirement for adjacency interferes with a property of SIP =
that
> is otherwise one of its great strengths: that a proxy (or other
> well-behaved Intermediate) need not understand every aspect of the
> requests and responses it forwards. =E3=80=82=E3=80=82=E3=80=82=E3=80=82=
=E3=80=82=E3=80=82=E3=80=82=E3=80=82=E2=80=9C
>=20
> I=E2=80=99m understanding that you imply a new feature needs the Intermed=
iate
> entites which make the authorization decision to be upgraded.
> However=EF=BC=8CIs there something associated with adjacency?
>=20
Clearly this point needs elaboration... I don't know if you saw my reply
last week to Alan on this same point [1] - the example I gave was:
       =20
        Suppose I have a wiz-bang new feature.  I figure out how to negotia=
te
        sessions that use it in SIP, and implement it in some spiffy new UA=
s.
        Given a good SIP fabric, the feature works.  But this feature has s=
ome
        characteristics that mean that I want it to be subject to an
        organizational security policy (using it has privacy implications, =
or it
        costs lots of money).  If I don't want to trust the endpoints to
        evaluate the policy (for reasons described elsewhere), then I need =
to
        have something else do so.  But the next-hop device those spiffy ne=
w UAs
        are attached to is my old-reliable edge intermediate; it's hard to =
get
        changes made to that, and it doesn't know anything about my new wiz=
-bang
        feature, so there's no way to get it to do any security policy
        evaluation for me on that feature.   If delivery implies authorizat=
ion,
        then all an attacker needs to do is find a way to get the request t=
o the
        next-hop old-reliable edge intermediate (probably not hard).
       =20
Authorization-by-delivery is weakened by each hop (including the last
one) by which the authorizing entity is separated from the protected
resource.  If the authorizing entity and the protected resource are
separated by only one hop, and if that hop is always TLS used so that
the protected resource can authenticate the authorizing entity, then
there is little opportunity for an attacker to exploit the separation;
but if there is more than one hop, then TLS cannot be used to
authenticate the authorizing entity and the authorization-by-delivery
model breaks down. =20

> In addition, i agree that the issues described in your draft are
> really very important. But I don=E2=80=99t understand clearly how the
> requirement of =E2=80=9CAuthorizing Third Party=E2=80=9D can solve them. =
I can=E2=80=99t get
> the requirements you proposed from these problems.

I guess I'd have to ask you what problem you think is not addressed.

> PS:=20
>=20
> there is one suggestion about the section 2.2, I think the following
> paragraphs could be in the section 2.2.1 and have a new title =E2=80=9CUs=
er
> Agent Based Authorization=E2=80=9D. Because all of them are describing th=
e
> problems of =E2=80=9CUser Agent Based Authorization=E2=80=9D.

That's a thought...=20


[1] http://www.ietf.org/mail-archive/web/dispatch/current/msg00070.html



From dworley@nortel.com  Tue May 26 12:25:37 2009
Return-Path: <dworley@nortel.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37E3E3A6835 for <dispatch@core3.amsl.com>; Tue, 26 May 2009 12:25:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.519
X-Spam-Level: 
X-Spam-Status: No, score=-6.519 tagged_above=-999 required=5 tests=[AWL=0.080,  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 3aR4siUy1TYe for <dispatch@core3.amsl.com>; Tue, 26 May 2009 12:25:32 -0700 (PDT)
Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 4354A3A7162 for <dispatch@ietf.org>; Tue, 26 May 2009 12:25:28 -0700 (PDT)
Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n4QJQnV21900; Tue, 26 May 2009 19:26:49 GMT
Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 26 May 2009 15:26:48 -0400
From: "Dale Worley" <dworley@nortel.com>
To: Alan Hawrylyshen <ahawrylyshen@ditechnetworks.com>
In-Reply-To: <BB945FE3-76FD-4DCB-802F-391667C4F3CD@ditechnetworks.com>
References: <BB945FE3-76FD-4DCB-802F-391667C4F3CD@ditechnetworks.com>
Content-Type: text/plain; charset=utf-8
Organization: Nortel Networks
Date: Tue, 26 May 2009 15:26:47 -0400
Message-Id: <1243366007.3754.25.camel@victoria-pingtel-com.us.nortel.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) 
Content-Transfer-Encoding: quoted-printable
X-OriginalArrivalTime: 26 May 2009 19:26:48.0295 (UTC) FILETIME=[E9BF0F70:01C9DE37]
Cc: dispatch@ietf.org
Subject: Re: [dispatch] Comments on	draft-lawrence-sip-3rd-party-authorization-00
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 May 2009 19:25:37 -0000

On Mon, 2009-05-18 at 11:24 -0700, Alan Hawrylyshen wrote:
> p.5 =C2=A7 2.2 par 10
>=20
> This hints at a much larger problem in SIP.
> Can Bob determine from Alice's subscription requests the (minimum)
> degree of disclosure required to satisfy Alice's interests? How can
> Bob know the application of the information requested. As you indicate
> later in the draft, this remains a significant challenge, although it
> is quite likely outside the scope of your draft. The JOIN vs 'line in
> use' indications being a great example of the two extremes.

I'm not sure that this is a problem in quite the way you write it.

All that is needed, I think, is for Bob to determine the information
which Alice is authorized to see.  From that information, Alice can
determine if that is enough information to satisfy her interests.

This approach avoids Alice having to be able to declare her interests,
and Bob having to interpret the declaration.

What makes the problem messy is if the question of what Alice is
authorized to know is variable or duration-sensitive.

Dale



From jason.fischl@skype.net  Tue May 26 16:16:51 2009
Return-Path: <jason.fischl@skype.net>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC5643A7010 for <dispatch@core3.amsl.com>; Tue, 26 May 2009 16:16:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.532
X-Spam-Level: 
X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067]
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 XWcwkY3fh+Ge for <dispatch@core3.amsl.com>; Tue, 26 May 2009 16:16:44 -0700 (PDT)
Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) by core3.amsl.com (Postfix) with ESMTP id D2ECF3A68BD for <dispatch@ietf.org>; Tue, 26 May 2009 16:16:43 -0700 (PDT)
X-EBay-Corp: Yes
X-IronPort-AV: E=Sophos;i="4.41,254,1241420400"; d="scan'208";a="48742743"
Received: from unknown (HELO den-exb-01.corp.ebay.com) ([10.101.44.9]) by den-mipot-002.corp.ebay.com with ESMTP; 26 May 2009 16:18:25 -0700
Received: from DEN-EXM-04.corp.ebay.com ([10.241.16.37]) by den-exb-01.corp.ebay.com with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 26 May 2009 17:18:24 -0600
Received: from 68.26.45.105 ([68.26.45.105]) by DEN-EXM-04.corp.ebay.com ([10.241.16.74]) via Exchange Front-End Server electron.corp.ebay.com ([10.101.112.26]) with Microsoft Exchange Server HTTP-DAV ; Tue, 26 May 2009 23:18:24 +0000
User-Agent: Microsoft-Entourage/12.17.0.090302
Date: Tue, 26 May 2009 16:18:22 -0700
From: Jason Fischl <jason.fischl@skype.net>
To: <dispatch@ietf.org>
Message-ID: <C641C6CE.D74E%jason.fischl@skype.net>
Thread-Topic: Proposal to form Internet Wideband Audio Codec WG
Thread-Index: AcneWEMKfMLxcIB/zk+aK3yDPFDcEw==
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 26 May 2009 23:18:24.0740 (UTC) FILETIME=[44AC4A40:01C9DE58]
Subject: [dispatch] Proposal to form Internet Wideband Audio Codec WG
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 May 2009 23:16:52 -0000

All,

I would like to request agenda time inside the DISPATCH meeting to propose
the formation of a new working group to define a Proposed Standard wideband
audio codec.

The text of the proposal is below. Comments, questions, and suggestions
welcomed.

Regards, 
Jason


Internet Wideband Audio Codec (IWAC)
Mailing Lists: TBD
Chairs: TBD
Area Directorate: Real Time Applications (RAI)

Purpose:

This new working group would be chartered with the purpose of collecting
expertise within the IETF in order to review the design of audio codecs
specifically for use with the Internet. Unlike other SDOs, these codecs
would be optimized for use on the Internet, and as much as possible choose
technology that does not require paying patent royalties.

The Internet Low Bit Rate Codec (iLBC)  work was done in AVT but it was felt
that subsequent work should not be done in the AVT working group. This new
working group will have as its primary purpose the standardization of a
multi-purpose audio codec that can be used in various situations on the
Internet. Some of the proposed Internet-specific requirements include:
* scalable and adaptive bit rate;
* various sampling rate profiles from narrow-band to super-wideband;
* scalable complexity;
* low latency; and 
* resilience to packet loss.

There are a number of wide-band capable codecs defined by other SDOs. For
instance, G.722 is seeing adoption in Enterprise applications since it is
relatively simple and low-cost to deploy. However, it has a high, fixed
bitrate and is not appropriate for mobile applications where spectrum
efficiency is important or in consumer applications where available
bandwidth is fluctuating or limited. G.722.2 (AMR-wideband) has been adopted
by the 3GPP as a wideband standard for mobile applications. G.722.2 is
relatively high cost due to patent royalties and is seeing minimal
deployments outside of mobile handsets making it challenging to create
wideband experiences on Internet-capable mobile devices when extending
beyond the mobile network. In other cases, proprietary codecs are being
adopted which further create islands with no interoperability unless
widespread transcoding is performed. Transcoding leads to higher costs and
lower quality. 

The goal of this working group is to define a single codec with multiple
profiles which can be made available on a wide variety of Internet-capable
devices including low-power, mobile devices as well as devices capable of
utilizing high quality, high bitrate audio.

Proposed Deliverables:

1) Requirements for wideband, Internet audio codec(s).
2) Algorithm description for wideband, Internet audio codec(s) as Proposed
Standard. 
3) Specification of payload format(s) for defined codecs as Proposed
Standard


From fanyanping@huawei.com  Tue May 26 22:37:12 2009
Return-Path: <fanyanping@huawei.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBC353A6DFD for <dispatch@core3.amsl.com>; Tue, 26 May 2009 22:37:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.387
X-Spam-Level: **
X-Spam-Status: No, score=2.387 tagged_above=-999 required=5 tests=[AWL=2.197,  BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45]
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 DAX0FoLgzcmR for <dispatch@core3.amsl.com>; Tue, 26 May 2009 22:37:12 -0700 (PDT)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id F105A3A6B30 for <dispatch@ietf.org>; Tue, 26 May 2009 22:37:11 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KKA0031IFOS7J@szxga04-in.huawei.com> for dispatch@ietf.org; Wed, 27 May 2009 13:38:52 +0800 (CST)
Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KKA0004VFOSIC@szxga04-in.huawei.com> for dispatch@ietf.org; Wed, 27 May 2009 13:38:52 +0800 (CST)
Received: from f00134301 ([10.85.29.39]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KKA00MP4FOSKW@szxml06-in.huawei.com> for dispatch@ietf.org; Wed, 27 May 2009 13:38:52 +0800 (CST)
Date: Wed, 27 May 2009 13:38:52 +0800
From: fanyanping <fanyanping@huawei.com>
In-reply-to: <1243348976.3432.4114.camel@host.home.skrb.org>
To: 'Scott Lawrence' <scott.lawrence@nortel.com>
Message-id: <00cb01c9de8d$6b2b61d0$271d550a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: quoted-printable
Thread-index: AcneHbgM0qQTb1LDSc6uBSEDr9OZLQAY6FHg
Cc: dispatch@ietf.org
Subject: Re: [dispatch] draft-lawrence-sip-3rd-party-authorization-00
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 May 2009 05:37:12 -0000

=20

-----=D3=CA=BC=FE=D4=AD=BC=FE-----
=B7=A2=BC=FE=C8=CB: Scott Lawrence [mailto:scott.lawrence@nortel.com]=20
=B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA5=D4=C226=C8=D5 22:43
=CA=D5=BC=FE=C8=CB: fanyanping
=B3=AD=CB=CD: dispatch@ietf.org
=D6=F7=CC=E2: Re: [dispatch] =
draft-lawrence-sip-3rd-party-authorization-00

> Clearly this point needs elaboration... I don't know if you saw my =
reply
last week to Alan on this same point [1] - the example I gave was:
       =20
       > Suppose I have a wiz-bang new feature.  I figure out how to
negotiate
       > sessions that use it in SIP, and implement it in some spiffy =
new
UAs.
       > Given a good SIP fabric, the feature works.  But this feature =
has
some
       > characteristics that mean that I want it to be subject to an
       > organizational security policy (using it has privacy =
implications,
or it
       > costs lots of money).  If I don't want to trust the endpoints =
to
       > evaluate the policy (for reasons described elsewhere), then I =
need
to
       > have something else do so.  But the next-hop device those =
spiffy
new UAs
       > are attached to is my old-reliable edge intermediate; it's hard =
to
get
       > changes made to that, and it doesn't know anything about my new
wiz-bang
       > feature, so there's no way to get it to do any security policy
       > evaluation for me on that feature.   If delivery implies
authorization,
       > then all an attacker needs to do is find a way to get the =
request
to the
       > next-hop old-reliable edge intermediate (probably not hard).
  =20
> Authorization-by-delivery is weakened by each hop (including the last
> one) by which the authorizing entity is separated from the protected
resource.  If the authorizing entity and the protected resource are
separated by only one > > hop, and if that hop is always TLS used so =
that
the protected resource can authenticate the authorizing entity, then =
there
is little opportunity for an attacker > to exploit the separation; but =
if
there is more than one hop, then TLS cannot be used to authenticate the
authorizing entity and the authorization-by-delivery > > model breaks =
down.=20

it's very clear, thanks :)=20

    > > In addition, i agree that the issues described in your draft are =

    > > really very important. But I don=A1=AFt understand clearly how =
the=20
    > > requirement of =A1=B0Authorizing Third Party=A1=B1 can solve =
them. I can=A1=AFt
get=20
    > > the requirements you proposed from these problems.

> I guess I'd have to ask you what problem you think is not addressed.

the section 3  in your draft describe the problem that  authorizing =
entity
doesn't know the service which the request is being used to implement , =
so
it  can not  make the authorization decision  appropriately. is it =
right?
I don=A1=AFt understand clearly how the requirement of =A1=B0Authorizing =
Third
Party=A1=B1 can solve the problem.

=20


[1] http://www.ietf.org/mail-archive/web/dispatch/current/msg00070.html



From root@core3.amsl.com  Tue May 26 16:00:02 2009
Return-Path: <root@core3.amsl.com>
X-Original-To: dispatch@ietf.org
Delivered-To: dispatch@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id 0854428C17F; Tue, 26 May 2009 16:00:01 -0700 (PDT)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20090526230002.0854428C17F@core3.amsl.com>
Date: Tue, 26 May 2009 16:00:02 -0700 (PDT)
X-Mailman-Approved-At: Wed, 27 May 2009 00:28:00 -0700
Cc: dispatch@ietf.org
Subject: [dispatch] I-D Action:draft-ietf-sip-outbound-18.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 May 2009 23:00:02 -0000

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Dispatch Working Group of the IETF.


	Title           : Managing Client Initiated Connections in the Session Initiation Protocol (SIP)
	Author(s)       : C. Jennings
	Filename        : draft-ietf-sip-outbound-18.txt
	Pages           : 49
	Date            : 2009-05-26

The Session Initiation Protocol (SIP) allows proxy servers to
initiate TCP connections or to send asynchronous UDP datagrams to
User Agents in order to deliver requests.  However, in a large number
of real deployments, many practical considerations, such as the
existence of firewalls and Network Address Translators (NATs) or the
use of TLS with server-provided certificates, prevent servers from
connecting to User Agents in this way.  This specification defines
behaviors for User Agents, registrars and proxy servers that allow
requests to be delivered on existing connections established by the
User Agent.  It also defines keep alive behaviors needed to keep NAT
bindings open and specifies the usage of multiple connections from
the User Agent to its Registrar.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-18.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-sip-outbound-18.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2009-05-26154854.I-D@ietf.org>


--NextPart--

From christer.holmberg@ericsson.com  Wed May 27 05:44:17 2009
Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 421AE3A6FD9 for <dispatch@core3.amsl.com>; Wed, 27 May 2009 05:44:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.88
X-Spam-Level: 
X-Spam-Status: No, score=-5.88 tagged_above=-999 required=5 tests=[AWL=0.368,  BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 3GnJA2BW5Rn9 for <dispatch@core3.amsl.com>; Wed, 27 May 2009 05:44:15 -0700 (PDT)
Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 460403A685F for <dispatch@ietf.org>; Wed, 27 May 2009 05:44:15 -0700 (PDT)
X-AuditID: c1b4fb3c-b7b28ae000005484-bf-4a1d35dc021c
Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id E3.58.21636.CD53D1A4; Wed, 27 May 2009 14:45:16 +0200 (CEST)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 27 May 2009 14:45:16 +0200
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_01C9DEC8.FC5892E7"
Date: Wed, 27 May 2009 14:45:16 +0200
Message-ID: <CA9998CD4A020D418654FCDEF4E707DF0D234264@esealmw113.eemea.ericsson.se>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Draft: CBUS (Condition-based URI Subscription) requirements draft - draft-holmberg-dispatch-cbus-00.txt
Thread-Index: AcneyPwcW0sabEV2R2qCUMnu274EKQ==
From: "Christer Holmberg" <christer.holmberg@ericsson.com>
To: <dispatch@ietf.org>
X-OriginalArrivalTime: 27 May 2009 12:45:16.0575 (UTC) FILETIME=[FC6012F0:01C9DEC8]
X-Brightmail-Tracker: AAAAAA==
Subject: [dispatch] Draft: CBUS (Condition-based URI Subscription) requirements draft - draft-holmberg-dispatch-cbus-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 May 2009 12:44:17 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9DEC8.FC5892E7
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi,

I've submitted a draft which proposes SIP requirements for CBUS, based
on work ongoing in OMA.

(The most likely protocol output is going to be a new event package, and
some mechanism to provide conditions to the CBUS server).

The document can also be found in:

http://users.piuha.net/cholmber/drafts/draft-holmberg-dispatch-cbus-00.t
xt

Regards,

Christer

------_=_NextPart_001_01C9DEC8.FC5892E7
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7654.12">
<TITLE>Draft: CBUS (Condition-based URI Subscription) requirements draft =
- draft-holmberg-dispatch-cbus-00.txt</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I've submitted a draft which proposes =
SIP requirements for CBUS, based on work ongoing in OMA.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">(The most likely protocol output is =
going to be a new event package, and some mechanism to provide =
conditions to the CBUS server).</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The document can also be found =
in:</FONT>
</P>

<P><A =
HREF=3D"http://users.piuha.net/cholmber/drafts/draft-holmberg-dispatch-cb=
us-00.txt"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">http://users.piuha.net/cholmber/drafts/draft-holmberg-disp=
atch-cbus-00.txt</FONT></U></A>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Regards,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Christer</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C9DEC8.FC5892E7--

From scott.lawrence@nortel.com  Wed May 27 07:29:29 2009
Return-Path: <scott.lawrence@nortel.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFF533A69C5 for <dispatch@core3.amsl.com>; Wed, 27 May 2009 07:29:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.123
X-Spam-Level: 
X-Spam-Status: No, score=-6.123 tagged_above=-999 required=5 tests=[AWL=0.476,  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 dklt1aS2Uw4A for <dispatch@core3.amsl.com>; Wed, 27 May 2009 07:29:29 -0700 (PDT)
Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id D06023A6870 for <dispatch@ietf.org>; Wed, 27 May 2009 07:29:28 -0700 (PDT)
Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n4REUGP04485; Wed, 27 May 2009 14:30:16 GMT
Received: from [127.0.0.1] ([47.17.25.99]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 May 2009 10:30:16 -0400
From: "Scott Lawrence" <scott.lawrence@nortel.com>
To: fanyanping <fanyanping@huawei.com>
In-Reply-To: <00cb01c9de8d$6b2b61d0$271d550a@china.huawei.com>
References: <00cb01c9de8d$6b2b61d0$271d550a@china.huawei.com>
Content-Type: text/plain; charset="UTF-8"
Organization: Nortel Networks
Date: Wed, 27 May 2009 10:30:15 -0400
Message-Id: <1243434615.13614.33.camel@host.home.skrb.org>
Mime-Version: 1.0
X-Mailer: Evolution 2.24.5 (2.24.5-1.fc10) 
Content-Transfer-Encoding: quoted-printable
X-OriginalArrivalTime: 27 May 2009 14:30:16.0280 (UTC) FILETIME=[A74AC580:01C9DED7]
Cc: dispatch@ietf.org
Subject: Re: [dispatch] draft-lawrence-sip-3rd-party-authorization-00
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 May 2009 14:29:29 -0000

On Wed, 2009-05-27 at 13:38 +0800, fanyanping wrote:
>=20
> > I guess I'd have to ask you what problem you think is not addressed.
>=20
> the section 3  in your draft describe the problem that  authorizing entit=
y
> doesn't know the service which the request is being used to implement , s=
o
> it  can not  make the authorization decision  appropriately. is it right?
> I don=E2=80=99t understand clearly how the requirement of =E2=80=9CAuthor=
izing Third
> Party=E2=80=9D can solve the problem.

If I have a new capability that needs new security evaluation
capability, with third party authorization I can add the ability to do
that evaluation anywhere in my network, but use the Authorization
Indication to carry that to the appropriate point of enforcement.  The
enforcement point does not need to understand general security policies,
or characteristics of new services - it only needs to understand how to
validate an Authorization Indication.  This separation of
responsibilities allows me to incrementally deploy new features while
maintaining enforcement of my security policies.


From jmh@joelhalpern.com  Wed May 27 08:03:44 2009
Return-Path: <jmh@joelhalpern.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCD4C3A6892 for <dispatch@core3.amsl.com>; Wed, 27 May 2009 08:03:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.459
X-Spam-Level: 
X-Spam-Status: No, score=-3.459 tagged_above=-999 required=5 tests=[AWL=0.140,  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 Ocl4cIqdxCj8 for <dispatch@core3.amsl.com>; Wed, 27 May 2009 08:03:40 -0700 (PDT)
Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id D7EC03A68F6 for <dispatch@ietf.org>; Wed, 27 May 2009 08:03:40 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C04044303B6 for <dispatch@ietf.org>; Wed, 27 May 2009 08:05:01 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net
Received: from [10.10.10.100] (pool-71-161-52-172.clppva.btas.verizon.net [71.161.52.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 307E0430380 for <dispatch@ietf.org>; Wed, 27 May 2009 08:05:01 -0700 (PDT)
Message-ID: <4A1D569B.3040401@joelhalpern.com>
Date: Wed, 27 May 2009 11:04:59 -0400
From: "Joel M. Halpern" <jmh@joelhalpern.com>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: dispatch@ietf.org
References: <CA9998CD4A020D418654FCDEF4E707DF0D234264@esealmw113.eemea.ericsson.se>
In-Reply-To: <CA9998CD4A020D418654FCDEF4E707DF0D234264@esealmw113.eemea.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [dispatch] Draft: CBUS (Condition-based URI Subscription)	requirements draft - draft-holmberg-dispatch-cbus-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 May 2009 15:03:44 -0000

Reading this draft, I am wondering if this actually has anything to do 
with SIP?  (Other than the fact that OMA chose to work on it, and 
decided SIP was the right solution space.)

It appears that the client is looking for some "servers" (which may be 
people) which meet certain constraints.  I am as likely to want xmpp: 
URIs, or even HTTP: URIs, as SIP: URIs (should I say TEL:?) for the 
cases that I can imagine based on the example in the draft.

This seems an interesting general application.  Unless we really want to 
turn SIP into the next HTTP: (REST over HTTP as a general application 
infrastructure), I am slightly confused.

Yours,
Joel

Christer Holmberg wrote:
> 
> 
> Hi,
> 
> I've submitted a draft which proposes SIP requirements for CBUS, based 
> on work ongoing in OMA.
> 
> (The most likely protocol output is going to be a new event package, and 
> some mechanism to provide conditions to the CBUS server).
> 
> The document can also be found in:
> 
> http://users.piuha.net/cholmber/drafts/draft-holmberg-dispatch-cbus-00.txt 
> <http://users.piuha.net/cholmber/drafts/draft-holmberg-dispatch-cbus-00.txt> 
> 
> 
> Regards,
> 
> Christer
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

From fluffy@cisco.com  Wed May 27 10:03:21 2009
Return-Path: <fluffy@cisco.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98D643A6D4E for <dispatch@core3.amsl.com>; Wed, 27 May 2009 10:03:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.57
X-Spam-Level: 
X-Spam-Status: No, score=-106.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 Hp2-QuefG2Rm for <dispatch@core3.amsl.com>; Wed, 27 May 2009 10:03:14 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id AC3AD3A6BD6 for <dispatch@ietf.org>; Wed, 27 May 2009 10:03:14 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.41,260,1241395200"; d="scan'208";a="311640585"
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 27 May 2009 17:03:27 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n4RH3RcI029887;  Wed, 27 May 2009 10:03:27 -0700
Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n4RH3Q1s022292; Wed, 27 May 2009 17:03:27 GMT
From: Cullen Jennings <fluffy@cisco.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
In-Reply-To: <CA9998CD4A020D418654FCDEF4E707DF0D234264@esealmw113.eemea.ericsson.se>
Impp: xmpp:cullenfluffyjennings@jabber.org
References: <CA9998CD4A020D418654FCDEF4E707DF0D234264@esealmw113.eemea.ericsson.se>
Message-Id: <3FFC95D4-2A4F-49D4-A5EA-482EBE61AFF0@cisco.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Wed, 27 May 2009 11:03:26 -0600
X-Mailer: Apple Mail (2.935.3)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=720; t=1243443807; x=1244307807; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20<fluffy@cisco.com> |Subject:=20Re=3A=20[dispatch]=20Draft=3A=20CBUS=20(Conditi on-based=20URI=20Subscription)=20requirements=20draft=20-=20 draft-holmberg-dispatch-cbus-00.txt |Sender:=20; bh=OU5Bx6TN1vG2dW7UTDLsFFPf2yoRTAyy5eZ47T48SuA=; b=dgIt/O7+RHLssFpZyQrVV2kP8yYlsByr36a7q12/fFv/FsmHjg+6BFWEKG AKCmMGS55cot1PbTnMqEKQ1yjiFEzVqt1QH0wg6edea5oqGVp7xY+x61KBGI qUSoi1KaKs;
Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); 
Cc: dispatch@ietf.org
Subject: Re: [dispatch] Draft: CBUS (Condition-based URI Subscription) requirements draft - draft-holmberg-dispatch-cbus-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 May 2009 17:03:21 -0000

I read this but I could not really figure out what it was about or  
what work it was proposing.

On May 27, 2009, at 6:45 AM, Christer Holmberg wrote:

>
> Hi,
>
> I've submitted a draft which proposes SIP requirements for CBUS,  
> based on work ongoing in OMA.
>
> (The most likely protocol output is going to be a new event package,  
> and some mechanism to provide conditions to the CBUS server).
>
> The document can also be found in:
>
> http://users.piuha.net/cholmber/drafts/draft-holmberg-dispatch-cbus-00.txt
>
> Regards,
>
> Christer
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch


From fluffy@cisco.com  Wed May 27 10:08:50 2009
Return-Path: <fluffy@cisco.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59B823A6A7F for <dispatch@core3.amsl.com>; Wed, 27 May 2009 10:08:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.57
X-Spam-Level: 
X-Spam-Status: No, score=-106.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 V7QK1VL09492 for <dispatch@core3.amsl.com>; Wed, 27 May 2009 10:08:49 -0700 (PDT)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 683853A7111 for <dispatch@ietf.org>; Wed, 27 May 2009 10:08:49 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.41,260,1241395200"; d="scan'208";a="169574004"
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 27 May 2009 17:08:35 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n4RH8Z55000900 for <dispatch@ietf.org>; Wed, 27 May 2009 10:08:35 -0700
Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n4RH8Xhw028815 for <dispatch@ietf.org>; Wed, 27 May 2009 17:08:34 GMT
Message-Id: <D7CF96E3-8046-4AFA-AE7D-7CCC546C3950@cisco.com>
From: Cullen Jennings <fluffy@cisco.com>
To: dispatch@ietf.org
In-Reply-To: <20090526230002.0854428C17F@core3.amsl.com>
Impp: xmpp:cullenfluffyjennings@jabber.org
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Wed, 27 May 2009 11:08:33 -0600
References: <20090526230002.0854428C17F@core3.amsl.com>
X-Mailer: Apple Mail (2.935.3)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2217; t=1243444115; x=1244308115; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20<fluffy@cisco.com> |Subject:=20Re=3A=20I-D=20Action=3Adraft-ietf-sip-outbound- 18.txt=20 |Sender:=20; bh=oP777r4cIArIBP/Ift58wj/08sTfEXrjFzRb+I2f38c=; b=ouQ1B+fvsLwnh6QWVDynxk/1+3IM42qu3JmA69VDe3EVn/WWH9auasgMX7 SZAJQN9wAdlIFZe11bkD4gOA5PgW8fcls7DL0E7Kb5LtPn1Uf/fPYsT1BKrJ nYiObv4m8E;
Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); 
Subject: Re: [dispatch] I-D Action:draft-ietf-sip-outbound-18.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 May 2009 17:08:50 -0000

Just as note for folks, this is not actually a dispatch WG document.  
It is a SIP WG draft but due to fun an excitement with data-tracker  
tools, notifications about this draft and a few other SIP and SIPPING  
WG drafts will sometimes end up up in dispatch.


On May 26, 2009, at 5:00 PM, internet-drafts@ietf.org wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
> This draft is a work item of the Dispatch Working Group of the IETF.
>
>
> 	Title           : Managing Client Initiated Connections in the  
> Session Initiation Protocol (SIP)
> 	Author(s)       : C. Jennings
> 	Filename        : draft-ietf-sip-outbound-18.txt
> 	Pages           : 49
> 	Date            : 2009-05-26
>
> The Session Initiation Protocol (SIP) allows proxy servers to
> initiate TCP connections or to send asynchronous UDP datagrams to
> User Agents in order to deliver requests.  However, in a large number
> of real deployments, many practical considerations, such as the
> existence of firewalls and Network Address Translators (NATs) or the
> use of TLS with server-provided certificates, prevent servers from
> connecting to User Agents in this way.  This specification defines
> behaviors for User Agents, registrars and proxy servers that allow
> requests to be delivered on existing connections established by the
> User Agent.  It also defines keep alive behaviors needed to keep NAT
> bindings open and specifies the usage of multiple connections from
> the User Agent to its Registrar.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-18.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.
> <mime-attachment>_______________________________________________
> 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 fluffy@cisco.com  Wed May 27 10:15:00 2009
Return-Path: <fluffy@cisco.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DC0A3A6C6A for <dispatch@core3.amsl.com>; Wed, 27 May 2009 10:15:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.571
X-Spam-Level: 
X-Spam-Status: No, score=-106.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 uzAeQeX5j2No for <dispatch@core3.amsl.com>; Wed, 27 May 2009 10:14:59 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 24E703A694C for <dispatch@ietf.org>; Wed, 27 May 2009 10:14:59 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.41,260,1241395200"; d="scan'208";a="311650030"
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 27 May 2009 17:15:00 +0000
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n4RHF0gg003257;  Wed, 27 May 2009 10:15:00 -0700
Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n4RHExuI022936; Wed, 27 May 2009 17:15:00 GMT
From: Cullen Jennings <fluffy@cisco.com>
To: Emil Ivov <emcho@sip-communicator.org>
In-Reply-To: <4A15D99F.9060100@sip-communicator.org>
Impp: xmpp:cullenfluffyjennings@jabber.org
References: <4A15D99F.9060100@sip-communicator.org>
Message-Id: <EA1CBEDB-319A-43BC-B874-909B8267F017@cisco.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Wed, 27 May 2009 11:14:59 -0600
X-Mailer: Apple Mail (2.935.3)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1806; t=1243444501; x=1244308501; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20<fluffy@cisco.com> |Subject:=20Re=3A=20[dispatch]=20Yet=20another=20problem=20 to=20dispatch |Sender:=20; bh=SmoIR2j2hxUzfMOdB/eT/ylJuI01l6Pu2XlU7Ei/z5A=; b=NIxiz+yDm4kQq013AXOKkzVMuDT7wXdVstZvsKrxyVbNEyOznyv8CnK66f XS50+aSOe9GKxfZZzGw0xFvN5IdlEE7zhy1beYmPRticm3qr7pDW52JUaoHE UItoWgOCp6;
Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); 
Cc: dispatch@ietf.org
Subject: Re: [dispatch] Yet another problem to dispatch
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 May 2009 17:15:00 -0000

I find this "active speaker" problem very interesting. Often the  
device that wants to display the active speaker information is not the  
same as the device dealing with the RTP. For example, most the  
conference systems I am using a phone but there is a web interface  
that is dealing with active speaker information on my browser which is  
no on my phone. Be interesting to look at all the existing approaches  
to this.


Cullen <in my individual contributor role>

On May 21, 2009, at 4:45 PM, Emil Ivov wrote:

> Hey folks,
>
> We have been working on client side conference calls  for SIP
> Communicator lately and were thinking about implementing participant
> sound level indicators. The feature was inspired by Skype's Mac OS X  
> GUI
> which you can have a look at over here:
>
> http://sip-communicator.org/skypeconf/skypeconf.png
>
> Since we couldn't find an existing IETF mechanism for a mixer to
> dispatch information on sound level to conference participants, Enrico
> and I thought that this may be an issue that is worth addressing  
> through
> dispatch.
>
> After talking to some of you privately and discussing it among  
> ourselves
> we have decided to come up with a document presenting the issue in  
> some
> more detail. We are also including short descriptions of what we
> consider to be possible approaches for resolving it.
>
> http://www.ietf.org/internet-drafts/draft-ivov-dispatch-slic-ps-00.txt
>
> Comments are most welcome, as well as any show of interest or
> indications of what you think would be the right place(s) to work on  
> the
> subject.
>
> Thanks,
> Emil
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch


From scott.lawrence@nortel.com  Wed May 27 11:18:14 2009
Return-Path: <scott.lawrence@nortel.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4EFC3A7151 for <dispatch@core3.amsl.com>; Wed, 27 May 2009 11:18:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.171
X-Spam-Level: 
X-Spam-Status: No, score=-6.171 tagged_above=-999 required=5 tests=[AWL=0.428,  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 OC1vCHB2WAmf for <dispatch@core3.amsl.com>; Wed, 27 May 2009 11:18:14 -0700 (PDT)
Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 40FB728C1B8 for <dispatch@ietf.org>; Wed, 27 May 2009 11:16:37 -0700 (PDT)
Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n4RIGtS13161; Wed, 27 May 2009 18:16:56 GMT
Received: from [127.0.0.1] ([47.17.25.99]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 27 May 2009 14:18:04 -0400
From: "Scott Lawrence" <scott.lawrence@nortel.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
In-Reply-To: <CA9998CD4A020D418654FCDEF4E707DF0D234264@esealmw113.eemea.ericsson.se>
References: <CA9998CD4A020D418654FCDEF4E707DF0D234264@esealmw113.eemea.ericsson.se>
Content-Type: text/plain
Organization: Nortel Networks
Date: Wed, 27 May 2009 14:18:03 -0400
Message-Id: <1243448283.13614.283.camel@host.home.skrb.org>
Mime-Version: 1.0
X-Mailer: Evolution 2.24.5 (2.24.5-1.fc10) 
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 27 May 2009 18:18:04.0421 (UTC) FILETIME=[7A239350:01C9DEF7]
Cc: dispatch@ietf.org
Subject: Re: [dispatch] Draft: CBUS (Condition-based URI Subscription) requirements draft - draft-holmberg-dispatch-cbus-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 May 2009 18:18:14 -0000

On Wed, 2009-05-27 at 14:45 +0200, Christer Holmberg wrote:

> I've submitted a draft which proposes SIP requirements for CBUS, based
> on work ongoing in OMA.

> (The most likely protocol output is going to be a new event package,
> and some mechanism to provide conditions to the CBUS server).

The document would have been significantly easier to understand had it
actually defined some of the several acronyms it used.

As far as I can tell, this describes (in very very general terms) a
framework for a particular application.  I don't see anything here that
motivates any new feature in the SIP protocol, or indeed any reason why
SIP is especially well suited to the application.



From enrico.marocco@telecomitalia.it  Wed May 27 13:00:41 2009
Return-Path: <enrico.marocco@telecomitalia.it>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F4613A6F67 for <dispatch@core3.amsl.com>; Wed, 27 May 2009 13:00:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.607
X-Spam-Level: 
X-Spam-Status: No, score=-0.607 tagged_above=-999 required=5 tests=[AWL=0.112,  BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
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 QUetfFaKKa9y for <dispatch@core3.amsl.com>; Wed, 27 May 2009 13:00:40 -0700 (PDT)
Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by core3.amsl.com (Postfix) with ESMTP id 40CDF3A6AC4 for <dispatch@ietf.org>; Wed, 27 May 2009 13:00:40 -0700 (PDT)
Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 27 May 2009 22:01:50 +0200
Received: from [172.16.82.18] (163.162.180.246) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.1.359.3; Wed, 27 May 2009 22:01:49 +0200
Message-ID: <4A1D9C2C.8030108@telecomitalia.it>
Date: Wed, 27 May 2009 22:01:48 +0200
From: Enrico Marocco <enrico.marocco@telecomitalia.it>
User-Agent: Mozilla-Thunderbird 2.0.0.17 (X11/20081018)
MIME-Version: 1.0
To: Cullen Jennings <fluffy@cisco.com>
References: <4A15D99F.9060100@sip-communicator.org> <EA1CBEDB-319A-43BC-B874-909B8267F017@cisco.com>
In-Reply-To: <EA1CBEDB-319A-43BC-B874-909B8267F017@cisco.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030907080706080607090407"
Cc: "dispatch@ietf.org" <dispatch@ietf.org>
Subject: Re: [dispatch] Yet another problem to dispatch
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 May 2009 20:00:41 -0000

--------------ms030907080706080607090407
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Cullen Jennings wrote:
> I find this "active speaker" problem very interesting. Often the  
> device that wants to display the active speaker information is not the  
> same as the device dealing with the RTP. For example, most the  
> conference systems I am using a phone but there is a web interface  
> that is dealing with active speaker information on my browser which is  
> no on my phone. Be interesting to look at all the existing approaches  
> to this.

Yes, I'm familiar with that kind of systems. However, the information we
are considering -- instantaneous sound levels of each participant -- is
definitely changing more rapidly than just active speaker indication and
also has more stringent synchronization requirements. That's why our
favorite approach would be to carry it in the media streams themselves,
 with some sort of a modulation of the RTP CSRC fields that could be
considered either an hack or an elegant solution. I would be very
interested in hearing any opinions about that.

-- 
Ciao,
Enrico

--------------ms030907080706080607090407
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJOzCC
AvgwggJhoAMCAQICEBtZixsKeF4i2Os0viEP+ncwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDMyOTE2Mjg1OVoX
DTEwMDMyOTE2Mjg1OVowUTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEuMCwG
CSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBALhn5sIqd2hv7B6UBs4823vUHLamD/+tFSXZKQ4Yw5oQ
5hOdPUoJazGMDOyB9tWcqXdJxt0WqHxdgeCeAS0zV85Uf6cQcvkSe//umVkZvPuAYTKWRBJw
8rLfVuYhk9t2KraXyVfWIdoceZP0/v4eIoLyPw2/wQS3AvxujvkyL2N94S7IOmPCP6WXZmmW
zNRzabSLLl50UA2jKbcYcWpKfQUFma9B1S3hAZTDiQTvXIJVmRdwYmnuwId9QTsm+7RB7oiy
EC7+zeOORQk1Y6NjKinZmLb/C0tq40NIIPpBqNaZ+V6UmQ0jtYIlBQrlG6OpSPgjAS9IWsMg
7mbratVpsNkCAwEAAaM8MDowKgYDVR0RBCMwIYEfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0
YWxpYS5pdDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADfh68XGwHIccDd0a+Fw
D7LEP2QxLEqgP/gR73fsvT6y1COD7vGZY4BkYvryiU5sPkW4ulizN1ASSMJJIVMkQdzzKS+H
e4dR5CpiPqz8b1LJdae8G7CUsBZ9KHYN4n6pGpdcq9YsGtfELp1W25MMppJcpKniscResCQF
BWmw3EsAMIIC+DCCAmGgAwIBAgIQG1mLGwp4XiLY6zS+IQ/6dzANBgkqhkiG9w0BAQUFADBi
MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEs
MCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDkwMzI5
MTYyODU5WhcNMTAwMzI5MTYyODU5WjBRMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVt
YmVyMS4wLAYJKoZIhvcNAQkBFh9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MIIB
IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuGfmwip3aG/sHpQGzjzbe9QctqYP/60V
JdkpDhjDmhDmE509SglrMYwM7IH21Zypd0nG3RaofF2B4J4BLTNXzlR/pxBy+RJ7/+6ZWRm8
+4BhMpZEEnDyst9W5iGT23YqtpfJV9Yh2hx5k/T+/h4igvI/Db/BBLcC/G6O+TIvY33hLsg6
Y8I/pZdmaZbM1HNptIsuXnRQDaMptxhxakp9BQWZr0HVLeEBlMOJBO9cglWZF3Biae7Ah31B
Oyb7tEHuiLIQLv7N445FCTVjo2MqKdmYtv8LS2rjQ0gg+kGo1pn5XpSZDSO1giUFCuUbo6lI
+CMBL0hawyDuZutq1Wmw2QIDAQABozwwOjAqBgNVHREEIzAhgR9lbnJpY28ubWFyb2Njb0B0
ZWxlY29taXRhbGlhLml0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAN+HrxcbA
chxwN3Rr4XAPssQ/ZDEsSqA/+BHvd+y9PrLUI4Pu8ZljgGRi+vKJTmw+Rbi6WLM3UBJIwkkh
UyRB3PMpL4d7h1HkKmI+rPxvUsl1p7wbsJSwFn0odg3ifqkal1yr1iwa18QunVbbkwymklyk
qeKxxF6wJAUFabDcSwAwggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYD
VQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAY
BgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZp
Y2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzAp
BgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAw
MDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENv
bnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls
IElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5o
wHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuv
PAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAe
ZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0
hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDAL
BgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4
MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6ot
nzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V
2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDcTCCA20CAQEwdjBi
MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEs
MCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBtZixsKeF4i
2Os0viEP+ncwCQYFKw4DAhoFAKCCAdAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq
hkiG9w0BCQUxDxcNMDkwNTI3MjAwMTQ4WjAjBgkqhkiG9w0BCQQxFgQUhs0w0SFSv4tmZ/pi
onCmWMusEMkwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI
KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGF
BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs
dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz
dWluZyBDQQIQG1mLGwp4XiLY6zS+IQ/6dzCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNV
BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQD
EyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQG1mLGwp4XiLY6zS+IQ/6
dzANBgkqhkiG9w0BAQEFAASCAQCS48kj2YcOlihWU/vuMPTeOwOq1HiwAFmNLS1PB17O5azK
r7MM8HXaO78pExQ1KC2gwPa8hFYOVGxGJwP9lvEUg/49j5twjBOxGwCQurQVCdnsx+SA25lV
uGVeQVdkZQwTxt0VOE6ON0vHlBLO/nnf7Fapqpy4WTrDBWhBB8AVmxNv/gtoUXiWYkpRnIiJ
LbA+gru8kZduaKkBAS2CuZ513AoQXXvFm2ddNfFJHm54IxWMx85Bmzyf9qbZT+pnPawgbF6M
30dP40wMhvCk2Tg4sq5YJRWRlvQdFy290t5CPqL+sKM9AMIhPeadcXo5YyKhyo3a2OgVDP3t
gCkXMWmWAAAAAAAA
--------------ms030907080706080607090407--

From dworley@nortel.com  Wed May 27 14:53:53 2009
Return-Path: <dworley@nortel.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FC5128C146 for <dispatch@core3.amsl.com>; Wed, 27 May 2009 14:53:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.52
X-Spam-Level: 
X-Spam-Status: No, score=-6.52 tagged_above=-999 required=5 tests=[AWL=0.079,  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 P-sIvR7im72x for <dispatch@core3.amsl.com>; Wed, 27 May 2009 14:53:53 -0700 (PDT)
Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id B6F2528C105 for <dispatch@ietf.org>; Wed, 27 May 2009 14:53:52 -0700 (PDT)
Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n4RLsIS19799; Wed, 27 May 2009 21:54:19 GMT
Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 27 May 2009 17:55:25 -0400
From: "Dale Worley" <dworley@nortel.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
In-Reply-To: <CA9998CD4A020D418654FCDEF4E707DF0D234264@esealmw113.eemea.ericsson.se>
References: <CA9998CD4A020D418654FCDEF4E707DF0D234264@esealmw113.eemea.ericsson.se>
Content-Type: text/plain
Organization: Nortel Networks
Date: Wed, 27 May 2009 17:55:25 -0400
Message-Id: <1243461325.9392.6.camel@victoria-pingtel-com.us.nortel.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) 
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 27 May 2009 21:55:25.0546 (UTC) FILETIME=[D74154A0:01C9DF15]
Cc: dispatch@ietf.org
Subject: Re: [dispatch] Draft: CBUS (Condition-based URI Subscription)	requirements draft - draft-holmberg-dispatch-cbus-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 May 2009 21:53:53 -0000

On Wed, 2009-05-27 at 14:45 +0200, Christer Holmberg wrote:
> I've submitted a draft which proposes SIP requirements for CBUS, based
> on work ongoing in OMA.

You're going to have to revise the Abstract:

   This specification defines CBUS requirements for the SIP interface
   between the CBUS Client and the CBUS server, based on the
   requirements in OMA.

I've been on the SIP mailing lists for several years, and I have
absolutely no idea what this is referring to (except the appearance of
"SIP").

Dale



From dworley@nortel.com  Wed May 27 14:58:44 2009
Return-Path: <dworley@nortel.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC2C63A6A7E for <dispatch@core3.amsl.com>; Wed, 27 May 2009 14:58:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.521
X-Spam-Level: 
X-Spam-Status: No, score=-6.521 tagged_above=-999 required=5 tests=[AWL=0.078,  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 vf7HcebwyEQq for <dispatch@core3.amsl.com>; Wed, 27 May 2009 14:58:43 -0700 (PDT)
Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 973E23A6F5F for <dispatch@ietf.org>; Wed, 27 May 2009 14:58:43 -0700 (PDT)
Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n4RLxES20374; Wed, 27 May 2009 21:59:14 GMT
Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 27 May 2009 18:00:20 -0400
From: "Dale Worley" <dworley@nortel.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
In-Reply-To: <CA9998CD4A020D418654FCDEF4E707DF0D234264@esealmw113.eemea.ericsson.se>
References: <CA9998CD4A020D418654FCDEF4E707DF0D234264@esealmw113.eemea.ericsson.se>
Content-Type: text/plain
Organization: Nortel Networks
Date: Wed, 27 May 2009 18:00:19 -0400
Message-Id: <1243461619.9392.9.camel@victoria-pingtel-com.us.nortel.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) 
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 27 May 2009 22:00:20.0206 (UTC) FILETIME=[86E2E0E0:01C9DF16]
Cc: dispatch@ietf.org
Subject: Re: [dispatch] Draft: CBUS (Condition-based URI Subscription)	requirements draft - draft-holmberg-dispatch-cbus-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 May 2009 21:58:45 -0000

On Wed, 2009-05-27 at 14:45 +0200, Christer Holmberg wrote:
> I've submitted a draft which proposes SIP requirements for CBUS, based
> on work ongoing in OMA.
> 
> (The most likely protocol output is going to be a new event package,
> and some mechanism to provide conditions to the CBUS server).
> 
> The document can also be found in:
> 
> http://users.piuha.net/cholmber/drafts/draft-holmberg-dispatch-cbus-00.txt

As far as I can tell, the functionality is a pure request/response
protocol.  As there are quite a number of request/response protocols out
there, is it useful to embed this in SIP?

Dale



From dean.willis@softarmor.com  Wed May 27 16:31:38 2009
Return-Path: <dean.willis@softarmor.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D3D528C269 for <dispatch@core3.amsl.com>; Wed, 27 May 2009 16:31:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.426
X-Spam-Level: 
X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.173,  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 EsmBN5xfT+CW for <dispatch@core3.amsl.com>; Wed, 27 May 2009 16:31:37 -0700 (PDT)
Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 2B2753A67F3 for <dispatch@ietf.org>; Wed, 27 May 2009 16:31:37 -0700 (PDT)
Received: from [192.168.2.103] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n4RNXCkI005302 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 27 May 2009 18:33:14 -0500
Message-Id: <9A1E3501-4871-48B3-B39A-80E8E167F4A5@softarmor.com>
From: Dean Willis <dean.willis@softarmor.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
In-Reply-To: <CA9998CD4A020D418654FCDEF4E707DF0D234264@esealmw113.eemea.ericsson.se>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Wed, 27 May 2009 18:33:07 -0500
References: <CA9998CD4A020D418654FCDEF4E707DF0D234264@esealmw113.eemea.ericsson.se>
X-Mailer: Apple Mail (2.935.3)
Cc: dispatch@ietf.org
Subject: Re: [dispatch] Draft: CBUS (Condition-based URI Subscription) requirements draft - draft-holmberg-dispatch-cbus-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 May 2009 23:31:38 -0000

On May 27, 2009, at 7:45 AM, Christer Holmberg wrote:

>
> Hi,
>
> I've submitted a draft which proposes SIP requirements for CBUS,  
> based on work ongoing in OMA.
>
> (The most likely protocol output is going to be a new event package,  
> and some mechanism to provide conditions to the CBUS server).
>
> The document can also be found in:
>
> http://users.piuha.net/cholmber/drafts/draft-holmberg-dispatch-cbus-00.txt
>
> Regards,
>
> Christer
>

I confess to having lost touch with OMA and that may have contributed,  
but after reading the draft, I must say I don't get it.

It seems like some sort of configuration-delivery problem.

--
Dean


From ingemar.s.johansson@ericsson.com  Wed May 27 22:53:33 2009
Return-Path: <ingemar.s.johansson@ericsson.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 438253A68E1 for <dispatch@core3.amsl.com>; Wed, 27 May 2009 22:53:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.649
X-Spam-Level: 
X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_53=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 PXJI9Dj191wf for <dispatch@core3.amsl.com>; Wed, 27 May 2009 22:53:31 -0700 (PDT)
Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 691BA3A68E8 for <dispatch@ietf.org>; Wed, 27 May 2009 22:53:31 -0700 (PDT)
X-AuditID: c1b4fb3c-b7b28ae000005484-6a-4a1e273eb035
Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 69.C7.21636.E372E1A4; Thu, 28 May 2009 07:55:11 +0200 (CEST)
Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 28 May 2009 07:55:10 +0200
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: Thu, 28 May 2009 07:54:29 +0200
Message-ID: <130EBB38279E9847BAAAE0B8F9905F8C01336559@esealmw109.eemea.ericsson.se>
In-Reply-To: <mailman.65.1243450808.11110.dispatch@ietf.org>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dispatch] Yet another problem to dispatch
Thread-Index: Acne/b2SaU44cbM3QRmItpfaus/7AAAVhOrA
References: <mailman.65.1243450808.11110.dispatch@ietf.org>
From: "Ingemar Johansson S" <ingemar.s.johansson@ericsson.com>
To: <dispatch@ietf.org>
X-OriginalArrivalTime: 28 May 2009 05:55:10.0738 (UTC) FILETIME=[DC910F20:01C9DF58]
X-Brightmail-Tracker: AAAAAA==
Cc: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
Subject: Re: [dispatch] Yet another problem to dispatch
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 May 2009 05:53:33 -0000

Hi

When it comes to the use of header extensions I would believe that it is
better to reference to the freshly baked RFC5285 which describes a
general mechanism for the use of header extensions.=20

Of all the listed options I personally find the header extension option
the most useful. The extension format would also be relatively compact
as the levels for each contributor can be put in the same order as the
contributors listed on the CSRC list. In addition, the header extension
does not need to be included in each packet, if a 10Hz update of the
meters is sufficient then the header extension would only be added every
5 packets (assuming a 20ms codec). The reading would be fast and most
important.. synchronized with the speech signal. The worst thing that
could happen if an endpoint (or whatever) discards the header extension
is that the client has to fall back to a binary CSRC activity
indication.=20
Given that the levels are represented with one octet each a header
extension would add ~5+CC bytes to the packets size padded to the
nearest 32bit boundary (CC =3D number of CSRC) , I believe that this is
manageable especially as each CSRC cost 4 bytes.

I don't believe that implementing an alternative use/interpretation of
the CSRC list is a good idea, first of all I suspect that it would
likely be unsynchronized with the speech signal as one need to average
the activity for each contributor. Also participants makes all kinds of
noise (besides talking), often very short noise burst but they will
trigger an actvity signal for a longer time than the actual noise burst,
leading to unrealisticly high levels for the noisy persons. Finally, as
you point out there may be some interop issues.

Regards
Ingemar

> ------------------------------
>=20
> Message: 2
> Date: Wed, 27 May 2009 11:14:59 -0600
> From: Cullen Jennings <fluffy@cisco.com>
> Subject: Re: [dispatch] Yet another problem to dispatch
> To: Emil Ivov <emcho@sip-communicator.org>
> Cc: dispatch@ietf.org
> Message-ID: <EA1CBEDB-319A-43BC-B874-909B8267F017@cisco.com>
> Content-Type: text/plain; charset=3DUS-ASCII; format=3Dflowed; =
delsp=3Dyes
>=20
>=20
> I find this "active speaker" problem very interesting. Often=20
> the device that wants to display the active speaker=20
> information is not the same as the device dealing with the=20
> RTP. For example, most the conference systems I am using a=20
> phone but there is a web interface that is dealing with=20
> active speaker information on my browser which is no on my=20
> phone. Be interesting to look at all the existing approaches to this.
>=20
>=20
> Cullen <in my individual contributor role>
>=20
> On May 21, 2009, at 4:45 PM, Emil Ivov wrote:
>=20
> > Hey folks,
> >
> > We have been working on client side conference calls  for SIP=20
> > Communicator lately and were thinking about implementing=20
> participant=20
> > sound level indicators. The feature was inspired by Skype's=20
> Mac OS X=20
> > GUI which you can have a look at over here:
> >
> > http://sip-communicator.org/skypeconf/skypeconf.png
> >
> > Since we couldn't find an existing IETF mechanism for a mixer to=20
> > dispatch information on sound level to conference=20
> participants, Enrico=20
> > and I thought that this may be an issue that is worth addressing=20
> > through dispatch.
> >
> > After talking to some of you privately and discussing it among=20
> > ourselves we have decided to come up with a document presenting the=20
> > issue in some more detail. We are also including short=20
> descriptions of=20
> > what we consider to be possible approaches for resolving it.
> >
> >=20
> http://www.ietf.org/internet-drafts/draft-ivov-dispatch-slic-ps-00.txt
> >
> > Comments are most welcome, as well as any show of interest or=20
> > indications of what you think would be the right place(s)=20
> to work on=20
> > the subject.
> >
> > Thanks,
> > Emil
> > _______________________________________________
> > dispatch mailing list
> > dispatch@ietf.org
> > https://www.ietf.org/mailman/listinfo/dispatch
>=20
>=20
>=20
> ------------------------------
>=20
> Message: 3
> Date: Wed, 27 May 2009 14:18:03 -0400
> From: "Scott Lawrence" <scott.lawrence@nortel.com>
> Subject: Re: [dispatch] Draft: CBUS (Condition-based URI Subscription)
> 	requirements draft - draft-holmberg-dispatch-cbus-00.txt
> To: Christer Holmberg <christer.holmberg@ericsson.com>
> Cc: dispatch@ietf.org
> Message-ID: <1243448283.13614.283.camel@host.home.skrb.org>
> Content-Type: text/plain
>=20
> On Wed, 2009-05-27 at 14:45 +0200, Christer Holmberg wrote:
>=20
> > I've submitted a draft which proposes SIP requirements for=20
> CBUS, based=20
> > on work ongoing in OMA.
>=20
> > (The most likely protocol output is going to be a new event=20
> package,=20
> > and some mechanism to provide conditions to the CBUS server).
>=20
> The document would have been significantly easier to=20
> understand had it actually defined some of the several=20
> acronyms it used.
>=20
> As far as I can tell, this describes (in very very general=20
> terms) a framework for a particular application.  I don't see=20
> anything here that motivates any new feature in the SIP=20
> protocol, or indeed any reason why SIP is especially well=20
> suited to the application.
>=20
>=20
>=20
>=20
> ------------------------------
>=20
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>=20
>=20
> End of dispatch Digest, Vol 2, Issue 22
> ***************************************
>=20

From christer.holmberg@ericsson.com  Wed May 27 23:33:22 2009
Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C45293A6A78 for <dispatch@core3.amsl.com>; Wed, 27 May 2009 23:33:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.884
X-Spam-Level: 
X-Spam-Status: No, score=-5.884 tagged_above=-999 required=5 tests=[AWL=0.365,  BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 u-jUIUGwz1nz for <dispatch@core3.amsl.com>; Wed, 27 May 2009 23:33:15 -0700 (PDT)
Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id CE4643A6846 for <dispatch@ietf.org>; Wed, 27 May 2009 23:33:14 -0700 (PDT)
X-AuditID: c1b4fb3e-b7b78ae000007894-1f-4a1e309180f3
Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id AA.9B.30868.1903E1A4; Thu, 28 May 2009 08:34:57 +0200 (CEST)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 28 May 2009 08:34:57 +0200
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: Thu, 28 May 2009 08:34:55 +0200
Message-ID: <CA9998CD4A020D418654FCDEF4E707DF0D25EA7B@esealmw113.eemea.ericsson.se>
In-Reply-To: <4A1D569B.3040401@joelhalpern.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dispatch] Draft: CBUS (Condition-based URI Subscription)	requirements draft - draft-holmberg-dispatch-cbus-00.txt
Thread-Index: Acne3JRJKFXoROoGRmygtAWKFzdaKAAgKoig
References: <CA9998CD4A020D418654FCDEF4E707DF0D234264@esealmw113.eemea.ericsson.se> <4A1D569B.3040401@joelhalpern.com>
From: "Christer Holmberg" <christer.holmberg@ericsson.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>, <dispatch@ietf.org>
X-OriginalArrivalTime: 28 May 2009 06:34:57.0003 (UTC) FILETIME=[6AE433B0:01C9DF5E]
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [dispatch] Draft: CBUS (Condition-based URI Subscription)	requirements draft - draft-holmberg-dispatch-cbus-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 May 2009 06:33:22 -0000

Hi,

>Reading this draft, I am wondering if this actually has=20
>anything to do with SIP?  (Other than the fact that OMA chose=20
>to work on it, and decided SIP was the right solution space.)

My assumption is that the most likely protocol output of this would be a
new SIP event package (used to transport the URI list), and some
mechanism to provide the conditions from the CBUS client to the CBUS
server (most likely as part of the subscription). However, in order to
follow the procedures I decided to start with requirements.

The CBUS enabler does contain more requirements than those listed in the
draft, but those are not related to SIP. The draft only contains the
requirements on the SIP interface between the CBUS client and CBUS
server.

>It appears that the client is looking for some "servers" (which may be
>people) which meet certain constraints.  I am as likely to want xmpp:=20
>URIs, or even HTTP: URIs, as SIP: URIs (should I say TEL:?)=20
>for the cases that I can imagine based on the example in the draft.

The client is not looking for servers. The client is looking for users,
which fulfills certain conditions.

>This seems an interesting general application.  Unless we=20
>really want to turn SIP into the next HTTP: (REST over HTTP=20
>as a general application infrastructure), I am slightly confused.

Event notifications is already we something have in SIP, so there is
nothing new there. The new thing would be that the subscriber, in
addition to only indicate which event he wants to describe also, also
indicate conditions.

Regards,

Christer



> Christer Holmberg wrote:
> >=20
> >=20
> > Hi,
> >=20
> > I've submitted a draft which proposes SIP requirements for=20
> CBUS, based=20
> > on work ongoing in OMA.
> >=20
> > (The most likely protocol output is going to be a new event=20
> package,=20
> > and some mechanism to provide conditions to the CBUS server).
> >=20
> > The document can also be found in:
> >=20
> >=20
> http://users.piuha.net/cholmber/drafts/draft-holmberg-dispatch-cbus-00
> > .txt=20
> >=20
> <http://users.piuha.net/cholmber/drafts/draft-holmberg-dispatch-cbus-0
> > 0.txt>
> >=20
> >=20
> > Regards,
> >=20
> > Christer
> >=20
> >=20
> >=20
> ----------------------------------------------------------------------
> > --
> >=20
> > _______________________________________________
> > dispatch mailing list
> > dispatch@ietf.org
> > https://www.ietf.org/mailman/listinfo/dispatch
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>=20

From christer.holmberg@ericsson.com  Wed May 27 23:51:52 2009
Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D26C3A6939 for <dispatch@core3.amsl.com>; Wed, 27 May 2009 23:51:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.885
X-Spam-Level: 
X-Spam-Status: No, score=-5.885 tagged_above=-999 required=5 tests=[AWL=0.364,  BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 G9ExcmVv0dmx for <dispatch@core3.amsl.com>; Wed, 27 May 2009 23:51:47 -0700 (PDT)
Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id AF3E63A6BC0 for <dispatch@ietf.org>; Wed, 27 May 2009 23:51:46 -0700 (PDT)
X-AuditID: c1b4fb3e-b7b78ae000007894-b9-4a1e34d7f900
Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 67.8D.30868.7D43E1A4; Thu, 28 May 2009 08:53:11 +0200 (CEST)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 28 May 2009 08:53:11 +0200
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: Thu, 28 May 2009 08:53:10 +0200
Message-ID: <CA9998CD4A020D418654FCDEF4E707DF0D25EB35@esealmw113.eemea.ericsson.se>
In-Reply-To: <9A1E3501-4871-48B3-B39A-80E8E167F4A5@softarmor.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dispatch] Draft: CBUS (Condition-based URI Subscription) requirements draft - draft-holmberg-dispatch-cbus-00.txt
Thread-Index: AcnfI4Lr2BFiH9xjTrWsBiJHYtdaJAAOyvXg
References: <CA9998CD4A020D418654FCDEF4E707DF0D234264@esealmw113.eemea.ericsson.se> <9A1E3501-4871-48B3-B39A-80E8E167F4A5@softarmor.com>
From: "Christer Holmberg" <christer.holmberg@ericsson.com>
To: "Dean Willis" <dean.willis@softarmor.com>
X-OriginalArrivalTime: 28 May 2009 06:53:11.0157 (UTC) FILETIME=[F70EDA50:01C9DF60]
X-Brightmail-Tracker: AAAAAA==
Cc: dispatch@ietf.org
Subject: Re: [dispatch] Draft: CBUS (Condition-based URI Subscription) requirements draft - draft-holmberg-dispatch-cbus-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 May 2009 06:51:52 -0000

Hi,

I will try to address the comments given by Dean, Cullen, Dale and
others in a single reply. Please let me know if I forgot something.

First, I didn't want to copy/past the whole OMA spec into the draft, but
if there are problems to understand what the proposal is about more text
will of course be added. I thought I had covered all the acronyms, but
that can of course also be fixed.

Second, as I said in another e-mail, my assumption is that the outcome
of this is (at least):

1. An event package in order to deliver the URI list
2. A mechanism to provide the conditions, which the server will use for
the evaluation

So, the idea is to use the existing SIP SUB/NOT mechanism. The only
"new" thing is to provide the conditions as part of the subscription.

Third, I am not sure I would call it a configuration-delivery problem.
Of course, the conditions can be said to "configure" the CBUS server,
when it starts looking for matching URIs. But, the conditions can be
unique for every subscription, so that is the reason why it is proposed
to deliver the subscription specific conditions as part of the
subscription.

Last, I don't agree to that the the functionality is a pure
request/response protocol. It is a sub/not functionaltiy: you may not
get the "response" (notification") immediately, and in some cases a
single subscription may trigger multiple notifications.

Regards,

Christer



=20

> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com]=20
> Sent: 28. toukokuuta 2009 2:33
> To: Christer Holmberg
> Cc: dispatch@ietf.org
> Subject: Re: [dispatch] Draft: CBUS (Condition-based URI=20
> Subscription) requirements draft - draft-holmberg-dispatch-cbus-00.txt
>=20
>=20
> On May 27, 2009, at 7:45 AM, Christer Holmberg wrote:
>=20
> >
> > Hi,
> >
> > I've submitted a draft which proposes SIP requirements for=20
> CBUS, based=20
> > on work ongoing in OMA.
> >
> > (The most likely protocol output is going to be a new event=20
> package,=20
> > and some mechanism to provide conditions to the CBUS server).
> >
> > The document can also be found in:
> >
> >=20
> http://users.piuha.net/cholmber/drafts/draft-holmberg-dispatch-cbus-00
> > .txt
> >
> > Regards,
> >
> > Christer
> >
>=20
> I confess to having lost touch with OMA and that may have=20
> contributed, but after reading the draft, I must say I don't get it.
>=20
> It seems like some sort of configuration-delivery problem.
>=20
> --
> Dean
>=20
>=20

From john.elwell@siemens-enterprise.com  Thu May 28 00:40:27 2009
Return-Path: <john.elwell@siemens-enterprise.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91D913A6C92 for <dispatch@core3.amsl.com>; Thu, 28 May 2009 00:40:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.452
X-Spam-Level: 
X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[AWL=0.147,  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 EuTB31PsrN1f for <dispatch@core3.amsl.com>; Thu, 28 May 2009 00:40:26 -0700 (PDT)
Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id A024B3A6C91 for <dispatch@ietf.org>; Thu, 28 May 2009 00:40:26 -0700 (PDT)
Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KKC0070YG28M2@siemenscomms.co.uk> for dispatch@ietf.org; Thu, 28 May 2009 08:42:08 +0100 (BST)
Date: Thu, 28 May 2009 08:42:07 +0100
From: "Elwell, John" <john.elwell@siemens-enterprise.com>
In-reply-to: <4A1D9C2C.8030108@telecomitalia.it>
To: Enrico Marocco <enrico.marocco@telecomitalia.it>, Cullen Jennings <fluffy@cisco.com>
Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001F17EE4@GBNTHT12009MSX.gb002.siemens.net>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: quoted-printable
Thread-Topic: [dispatch] Yet another problem to dispatch
Thread-Index: AcnfBibxOpGyGPlBR2ersPGUTTzRjQAXQrqw
Content-class: urn:content-classes:message
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
References: <4A15D99F.9060100@sip-communicator.org> <EA1CBEDB-319A-43BC-B874-909B8267F017@cisco.com> <4A1D9C2C.8030108@telecomitalia.it>
Cc: dispatch@ietf.org
Subject: Re: [dispatch] Yet another problem to dispatch
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 May 2009 07:40:27 -0000

Background noise in conferences is certainly a big issue. The web-type
interface that Cullen mentions does in fact allow the moderator to
momentarily mute each suspected noisy party in turn to discover who is
the culprit. Clearly this is not scalable to large conferences. But also
a simultaneous display of noise levels (e.g., in the form of bar graphs)
is not scalable. Whilst it might be easy to find protocol solutions, we
need to be confident that people will find ways of exploiting them in a
reasonable way at the user interface. Certainly worth exploring.

John


> -----Original Message-----
> From: dispatch-bounces@ietf.org=20
> [mailto:dispatch-bounces@ietf.org] On Behalf Of Enrico Marocco
> Sent: 27 May 2009 21:02
> To: Cullen Jennings
> Cc: dispatch@ietf.org
> Subject: Re: [dispatch] Yet another problem to dispatch
>=20
> Cullen Jennings wrote:
> > I find this "active speaker" problem very interesting. Often the =20
> > device that wants to display the active speaker information=20
> is not the =20
> > same as the device dealing with the RTP. For example, most the =20
> > conference systems I am using a phone but there is a web interface =20
> > that is dealing with active speaker information on my=20
> browser which is =20
> > no on my phone. Be interesting to look at all the existing=20
> approaches =20
> > to this.
>=20
> Yes, I'm familiar with that kind of systems. However, the=20
> information we
> are considering -- instantaneous sound levels of each=20
> participant -- is
> definitely changing more rapidly than just active speaker=20
> indication and
> also has more stringent synchronization requirements. That's why our
> favorite approach would be to carry it in the media streams=20
> themselves,
>  with some sort of a modulation of the RTP CSRC fields that could be
> considered either an hack or an elegant solution. I would be very
> interested in hearing any opinions about that.
>=20
> --=20
> Ciao,
> Enrico
>=20

From gonzalo.camarillo@ericsson.com  Thu May 28 03:10:34 2009
Return-Path: <gonzalo.camarillo@ericsson.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B4283A6BF4 for <dispatch@core3.amsl.com>; Thu, 28 May 2009 03:10:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.486
X-Spam-Level: 
X-Spam-Status: No, score=-5.486 tagged_above=-999 required=5 tests=[AWL=0.763,  BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 1qExtdmL3X-9 for <dispatch@core3.amsl.com>; Thu, 28 May 2009 03:10:33 -0700 (PDT)
Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id ADD2D3A6BB5 for <dispatch@ietf.org>; Thu, 28 May 2009 03:10:32 -0700 (PDT)
X-AuditID: c1b4fb3c-b7b28ae000005484-42-4a1e5f985695
Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id B4.48.21636.89F5E1A4; Thu, 28 May 2009 11:55:36 +0200 (CEST)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 28 May 2009 11:55:35 +0200
Received: from [131.160.37.44] ([131.160.37.44]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 28 May 2009 11:55:35 +0200
Message-ID: <4A1E5F97.3010102@ericsson.com>
Date: Thu, 28 May 2009 12:55:35 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: DISPATCH <dispatch@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 28 May 2009 09:55:35.0860 (UTC) FILETIME=[729BFF40:01C9DF7A]
X-Brightmail-Tracker: AAAAAA==
Subject: [dispatch] Documents in our charter page
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 May 2009 10:10:34 -0000

Folks,

FYI: as some of you may have noticed, a few documents have been added to 
our charter page. This is just an error caused by a misbehaving tool 
used by the secretariat. Our ADs are working on solving this issue.

Cheers,

Gonzalo
DISPATCH co-chair

From enrico.marocco@telecomitalia.it  Thu May 28 05:56:16 2009
Return-Path: <enrico.marocco@telecomitalia.it>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44C593A6D40 for <dispatch@core3.amsl.com>; Thu, 28 May 2009 05:56:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.538
X-Spam-Level: 
X-Spam-Status: No, score=-0.538 tagged_above=-999 required=5 tests=[AWL=0.181,  BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
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 aT5mSIQmPox0 for <dispatch@core3.amsl.com>; Thu, 28 May 2009 05:56:15 -0700 (PDT)
Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by core3.amsl.com (Postfix) with ESMTP id 1F6603A68BC for <dispatch@ietf.org>; Thu, 28 May 2009 05:55:51 -0700 (PDT)
Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 28 May 2009 14:57:31 +0200
Received: from [10.229.8.41] (10.229.8.41) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.1.359.3; Thu, 28 May 2009 14:57:30 +0200
Message-ID: <4A1E8A3E.4060908@telecomitalia.it>
Date: Thu, 28 May 2009 14:57:34 +0200
From: Enrico Marocco <enrico.marocco@telecomitalia.it>
User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103)
MIME-Version: 1.0
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
References: <mailman.65.1243450808.11110.dispatch@ietf.org> <130EBB38279E9847BAAAE0B8F9905F8C01336559@esealmw109.eemea.ericsson.se>
In-Reply-To: <130EBB38279E9847BAAAE0B8F9905F8C01336559@esealmw109.eemea.ericsson.se>
X-Enigmail-Version: 0.95.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030108000403020809000607"
Cc: "dispatch@ietf.org" <dispatch@ietf.org>
Subject: Re: [dispatch] Yet another problem to dispatch
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 May 2009 12:56:16 -0000

--------------ms030108000403020809000607
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Ingemar Johansson S wrote:
> When it comes to the use of header extensions I would believe that it is
> better to reference to the freshly baked RFC5285 which describes a
> general mechanism for the use of header extensions. 

Yes, if people agree that such a problem will be best addressed with an
RTP extension, 5285 is probably the right way to go.

> I don't believe that implementing an alternative use/interpretation of
> the CSRC list is a good idea, first of all I suspect that it would
> likely be unsynchronized with the speech signal as one need to average
> the activity for each contributor. Also participants makes all kinds of
> noise (besides talking), often very short noise burst but they will
> trigger an actvity signal for a longer time than the actual noise burst,
> leading to unrealisticly high levels for the noisy persons. Finally, as
> you point out there may be some interop issues.

Hmm, I'm not sure if that's what would actually happen. If a noise burst
reached, say, volume level 8 for 40ms, that would be signaled only in
two RTP packets, resulting in the client detecting just a level-2 signal.

-- 
Ciao,
Enrico

--------------ms030108000403020809000607
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJwTCC
AzswggKkoAMCAQICEEIEYmjMZBX3Us1Th/pMjJYwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDMxNjE3NTMwMloX
DTEwMDMxNjE3NTMwMlowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEuMCwG
CSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEnMCUGCSqGSIb3
DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A
MIIBCgKCAQEAvd38YWuquonbz4lP4GKp0qij0v4MgXpK/BW87GvoqHz3iQvO1Tb6f4yEtFel
vpK2drtUHWyY+ww6QQSOGJvSWEKTRVX5KsXpN2yNeY4kceezCjsXBvwNPlGHrzJifUByvwzD
QSnQLocE1i89x7P2T5brcaGBBgricwQL1Cggg97zp1yGrj2VIJE03GSpEL01d+omAFUou3mx
8R/9XOnGnSlDpcOV6s2Ww3NN07+7sSBaE0vcvlYF8pr1BWDl2JJobG9qpC9DlplpDZOdmsAG
u/qwsI0AsucY5ZBFKqzKizQ5PGhrh3u2PHRGNncuHUANF0cPfVs7AHjHjudH7PzU2wIDAQAB
o1YwVDBEBgNVHREEPTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJp
Y28ubWFyb2Njb0BnbWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQB3
Mi6SymgE1cfsbmr5LWvWVdO58/a0O95kXL2puRn9kGjFN1tAzHQc/UxJs0gIyRRs3gGBR+p6
TT1gmnucO8Ji0gJBMBL+ogcfyaV30hZtUceiRevemXvZW2QOCLdYUf6KdB6ccX7r3a58SRRL
l5YTZ7bIhyAEmeI60ioyMI8U5jCCAzswggKkoAMCAQICEEIEYmjMZBX3Us1Th/pMjJYwDQYJ
KoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n
IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n
IENBMB4XDTA5MDMxNjE3NTMwMloXDTEwMDMxNjE3NTMwMlowejEfMB0GA1UEAxMWVGhhd3Rl
IEZyZWVtYWlsIE1lbWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNv
bWl0YWxpYS5pdDEnMCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIB
IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvd38YWuquonbz4lP4GKp0qij0v4MgXpK
/BW87GvoqHz3iQvO1Tb6f4yEtFelvpK2drtUHWyY+ww6QQSOGJvSWEKTRVX5KsXpN2yNeY4k
ceezCjsXBvwNPlGHrzJifUByvwzDQSnQLocE1i89x7P2T5brcaGBBgricwQL1Cggg97zp1yG
rj2VIJE03GSpEL01d+omAFUou3mx8R/9XOnGnSlDpcOV6s2Ww3NN07+7sSBaE0vcvlYF8pr1
BWDl2JJobG9qpC9DlplpDZOdmsAGu/qwsI0AsucY5ZBFKqzKizQ5PGhrh3u2PHRGNncuHUAN
F0cPfVs7AHjHjudH7PzU2wIDAQABo1YwVDBEBgNVHREEPTA7gR9lbnJpY28ubWFyb2Njb0B0
ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0BnbWFpbC5jb20wDAYDVR0TAQH/BAIw
ADANBgkqhkiG9w0BAQUFAAOBgQB3Mi6SymgE1cfsbmr5LWvWVdO58/a0O95kXL2puRn9kGjF
N1tAzHQc/UxJs0gIyRRs3gGBR+p6TT1gmnucO8Ji0gJBMBL+ogcfyaV30hZtUceiRevemXvZ
W2QOCLdYUf6KdB6ccX7r3a58SRRLl5YTZ7bIhyAEmeI60ioyMI8U5jCCAz8wggKooAMCAQIC
AQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh
cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAm
BgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0
ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h
aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV
BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQD
EyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEF
AAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B
1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79A
gAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E
CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3
dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEa
MBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7M
DaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa
C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk1
3iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3
dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl
ZW1haWwgSXNzdWluZyBDQQIQQgRiaMxkFfdSzVOH+kyMljAJBgUrDgMCGgUAoIIB0DAYBgkq
hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA1MjgxMjU3MzRaMCMG
CSqGSIb3DQEJBDEWBBT1Y7HH8dDuHBocju6Xg3yvAAFVIjBfBgkqhkiG9w0BCQ8xUjBQMAsG
CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw
BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC
WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro
YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBCBGJozGQV91LNU4f6TIyWMIGH
BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z
dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ
c3N1aW5nIENBAhBCBGJozGQV91LNU4f6TIyWMA0GCSqGSIb3DQEBAQUABIIBAJ3Oh8w/n+8k
qIaKU8pY1aSZvxa0ny6Mkypl0vgIvAO9W44fIg9vvUXOO6sLe+H8F9R1nCCwJwKZPS7I36d/
+psyGFRzMOqiH4oL85m3TFwLQroKf03lu44zQBcUmZyF6NowgTyE6zfNkoYyVals8ICcwymO
CHZ26j69/C2Zu/ReUrIaY3bEsuGHP+0SLBQ5iOVOnUl5w9bdOPCJKQd3HZ72xfbrBBleZ4Cn
Kokm8Hvb9UNCKEaJS8LCDxr1CU0ajTVzmSwXIrjQXkbjtb9hQppCQJUATIniaJ1eoycwuVjG
9igwX174Scwj6HI017liSGkcFx0hLwDqhSwy6qTqjHUAAAAAAAA=
--------------ms030108000403020809000607--

From emil@sip-communicator.org  Thu May 28 05:58:19 2009
Return-Path: <emil@sip-communicator.org>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2BF73A6E08 for <dispatch@core3.amsl.com>; Thu, 28 May 2009 05:58:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level: 
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_53=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 D1Ru7aT8i+gw for <dispatch@core3.amsl.com>; Thu, 28 May 2009 05:58:17 -0700 (PDT)
Received: from mail-bw0-f222.google.com (mail-bw0-f222.google.com [209.85.218.222]) by core3.amsl.com (Postfix) with ESMTP id 2CEB73A6D2E for <dispatch@ietf.org>; Thu, 28 May 2009 05:58:17 -0700 (PDT)
Received: by bwz22 with SMTP id 22so5418068bwz.37 for <dispatch@ietf.org>; Thu, 28 May 2009 05:59:57 -0700 (PDT)
Received: by 10.103.169.18 with SMTP id w18mr796033muo.101.1243515597766; Thu, 28 May 2009 05:59:57 -0700 (PDT)
Received: from porcinet.u-strasbg.fr (porcinet.u-strasbg.fr [130.79.91.167]) by mx.google.com with ESMTPS id 12sm369728muq.53.2009.05.28.05.59.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 28 May 2009 05:59:55 -0700 (PDT)
Sender: Emil Ivov <emil@sip-communicator.org>
Message-ID: <4A1E8AC6.3030402@sip-communicator.org>
Date: Thu, 28 May 2009 14:59:50 +0200
From: Emil Ivov <emcho@sip-communicator.org>
Organization: SIP Communicator
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
MIME-Version: 1.0
To: dispatch@ietf.org
References: <mailman.65.1243450808.11110.dispatch@ietf.org> <130EBB38279E9847BAAAE0B8F9905F8C01336559@esealmw109.eemea.ericsson.se>
In-Reply-To: <130EBB38279E9847BAAAE0B8F9905F8C01336559@esealmw109.eemea.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
Subject: Re: [dispatch] Yet another problem to dispatch
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 May 2009 12:58:19 -0000

Hey Ingemar,

Thanks for your thoughts!

A few comments inline

Ingemar Johansson S wrote:
> Hi
> 
> When it comes to the use of header extensions I would believe that it is
> better to reference to the freshly baked RFC5285 which describes a
> general mechanism for the use of header extensions. 
> 
> Of all the listed options I personally find the header extension option
> the most useful. The extension format would also be relatively compact
> as the levels for each contributor can be put in the same order as the
> contributors listed on the CSRC list. 

As a matter of fact that would also have been our first choice but we
were a bit concerned with the use of the extension header since RFC3550
insists on its experimental nature. I guess RFC5285 obsoletes the
warnings against use of the extension header so thanks for pointing it out!

Incidentally, RFC5285 seems to be extending SDP for the extension
mappings. If we go down this path we need to be aware that we would lose
the inherent compatibility with other signaling protocols such as XMPP.
Making the solution work for them would require some extra effort.

> In addition, the header extension
> does not need to be included in each packet, if a 10Hz update of the
> meters is sufficient then the header extension would only be added every
> 5 packets (assuming a 20ms codec). 

Definitely sounds reasonable but this is also a bit of a slippery slope
since it may somewhat compromise reliability. The trade off consists in
choosing between a few extra bytes in every RTP packet or losing the
meta information which may make the UI look a bit jumpy at times. It
would probably be a good idea to leave the choice to implementors.

> The reading would be fast and most
> important.. synchronized with the speech signal. The worst thing that
> could happen if an endpoint (or whatever) discards the header extension
> is that the client has to fall back to a binary CSRC activity
> indication. 

Yes, agreed.

> Given that the levels are represented with one octet each a header
> extension would add ~5+CC bytes to the packets size padded to the
> nearest 32bit boundary (CC = number of CSRC) , I believe that this is
> manageable especially as each CSRC cost 4 bytes.
> 
> I don't believe that implementing an alternative use/interpretation of
> the CSRC list is a good idea, first of all I suspect that it would
> likely be unsynchronized with the speech signal as one need to average
> the activity for each contributor. 

Granted .. although I wouldn't say it's more of an issue than losing a
packet containing the extension header in the case where we only send it
in every fifth packet.

> Also participants makes all kinds of
> noise (besides talking), often very short noise burst but they will
> trigger an actvity signal for a longer time than the actual noise burst,

Indeed, although a noise burst representation in the UI that lasts less
than a hundred milliseconds is likely to go unnoticed by the user,
anyway. Many sound level indicators (like for example most of the
microphone configuration UIs built in popular OSs) would intentionally
add some delay when representing peaks.

> leading to unrealisticly high levels for the noisy persons. Finally, as
> you point out there may be some interop issues.

Yes and again, if the experimental nature of the RTP extension header is
no longer meant for experimentation only and the community is
comfortable with the XMPP compatibility issue then this is clearly the
way to go.

Thanks again for your comments Ingemar!

Cheers
Emil
> 
> Regards
> Ingemar
> 
>> ------------------------------
>>
>> Message: 2
>> Date: Wed, 27 May 2009 11:14:59 -0600
>> From: Cullen Jennings <fluffy@cisco.com>
>> Subject: Re: [dispatch] Yet another problem to dispatch
>> To: Emil Ivov <emcho@sip-communicator.org>
>> Cc: dispatch@ietf.org
>> Message-ID: <EA1CBEDB-319A-43BC-B874-909B8267F017@cisco.com>
>> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>>
>>
>> I find this "active speaker" problem very interesting. Often 
>> the device that wants to display the active speaker 
>> information is not the same as the device dealing with the 
>> RTP. For example, most the conference systems I am using a 
>> phone but there is a web interface that is dealing with 
>> active speaker information on my browser which is no on my 
>> phone. Be interesting to look at all the existing approaches to this.
>>
>>
>> Cullen <in my individual contributor role>
>>
>> On May 21, 2009, at 4:45 PM, Emil Ivov wrote:
>>
>>> Hey folks,
>>>
>>> We have been working on client side conference calls  for SIP 
>>> Communicator lately and were thinking about implementing 
>> participant 
>>> sound level indicators. The feature was inspired by Skype's 
>> Mac OS X 
>>> GUI which you can have a look at over here:
>>>
>>> http://sip-communicator.org/skypeconf/skypeconf.png
>>>
>>> Since we couldn't find an existing IETF mechanism for a mixer to 
>>> dispatch information on sound level to conference 
>> participants, Enrico 
>>> and I thought that this may be an issue that is worth addressing 
>>> through dispatch.
>>>
>>> After talking to some of you privately and discussing it among 
>>> ourselves we have decided to come up with a document presenting the 
>>> issue in some more detail. We are also including short 
>> descriptions of 
>>> what we consider to be possible approaches for resolving it.
>>>
>>>
>> http://www.ietf.org/internet-drafts/draft-ivov-dispatch-slic-ps-00.txt
>>> Comments are most welcome, as well as any show of interest or 
>>> indications of what you think would be the right place(s) 
>> to work on 
>>> the subject.
>>>
>>> Thanks,
>>> Emil
>>> _______________________________________________
>>> dispatch mailing list
>>> dispatch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dispatch
>>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Wed, 27 May 2009 14:18:03 -0400
>> From: "Scott Lawrence" <scott.lawrence@nortel.com>
>> Subject: Re: [dispatch] Draft: CBUS (Condition-based URI Subscription)
>> 	requirements draft - draft-holmberg-dispatch-cbus-00.txt
>> To: Christer Holmberg <christer.holmberg@ericsson.com>
>> Cc: dispatch@ietf.org
>> Message-ID: <1243448283.13614.283.camel@host.home.skrb.org>
>> Content-Type: text/plain
>>
>> On Wed, 2009-05-27 at 14:45 +0200, Christer Holmberg wrote:
>>
>>> I've submitted a draft which proposes SIP requirements for 
>> CBUS, based 
>>> on work ongoing in OMA.
>>> (The most likely protocol output is going to be a new event 
>> package, 
>>> and some mechanism to provide conditions to the CBUS server).
>> The document would have been significantly easier to 
>> understand had it actually defined some of the several 
>> acronyms it used.
>>
>> As far as I can tell, this describes (in very very general 
>> terms) a framework for a particular application.  I don't see 
>> anything here that motivates any new feature in the SIP 
>> protocol, or indeed any reason why SIP is especially well 
>> suited to the application.
>>
>>
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>>
>>
>> End of dispatch Digest, Vol 2, Issue 22
>> ***************************************
>>
> 

-- 
Emil Ivov, Ph.D.                               30a rue de la Patrie
Project Lead                                   67300 Schiltigheim
SIP Communicator
emcho@sip-communicator.org                     FAX:   +33.1.77.62.47.31
http://sip-communicator.org                    PHONE: +33.1.77.62.43.30


From emil@sip-communicator.org  Thu May 28 06:00:01 2009
Return-Path: <emil@sip-communicator.org>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 810893A6D2E for <dispatch@core3.amsl.com>; Thu, 28 May 2009 06:00:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.949
X-Spam-Level: 
X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599, HELO_EQ_FR=0.35]
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 A4Yk8jVbvENC for <dispatch@core3.amsl.com>; Thu, 28 May 2009 06:00:00 -0700 (PDT)
Received: from mail-bw0-f222.google.com (mail-bw0-f222.google.com [209.85.218.222]) by core3.amsl.com (Postfix) with ESMTP id 632B83A68F3 for <dispatch@ietf.org>; Thu, 28 May 2009 06:00:00 -0700 (PDT)
Received: by bwz22 with SMTP id 22so5419298bwz.37 for <dispatch@ietf.org>; Thu, 28 May 2009 06:01:39 -0700 (PDT)
Received: by 10.103.220.18 with SMTP id x18mr841798muq.24.1243515699531; Thu, 28 May 2009 06:01:39 -0700 (PDT)
Received: from porcinet.u-strasbg.fr (porcinet.u-strasbg.fr [130.79.91.167]) by mx.google.com with ESMTPS id j9sm359070mue.51.2009.05.28.06.01.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 28 May 2009 06:01:38 -0700 (PDT)
Sender: Emil Ivov <emil@sip-communicator.org>
Message-ID: <4A1E8B2E.1030906@sip-communicator.org>
Date: Thu, 28 May 2009 15:01:34 +0200
From: Emil Ivov <emcho@sip-communicator.org>
Organization: SIP Communicator
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
MIME-Version: 1.0
To: "Elwell, John" <john.elwell@siemens-enterprise.com>
References: <4A15D99F.9060100@sip-communicator.org>	<EA1CBEDB-319A-43BC-B874-909B8267F017@cisco.com>	<4A1D9C2C.8030108@telecomitalia.it> <0D5F89FAC29E2C41B98A6A762007F5D001F17EE4@GBNTHT12009MSX.gb002.siemens.net>
In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001F17EE4@GBNTHT12009MSX.gb002.siemens.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: dispatch@ietf.org
Subject: Re: [dispatch] Yet another problem to dispatch
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 May 2009 13:00:01 -0000

Hey John,

Elwell, John wrote:
> Background noise in conferences is certainly a big issue. The web-type
> interface that Cullen mentions does in fact allow the moderator to
> momentarily mute each suspected noisy party in turn to discover who is
> the culprit. Clearly this is not scalable to large conferences. But also
> a simultaneous display of noise levels (e.g., in the form of bar graphs)
> is not scalable. 

One way to address this would be to allow mixer implementors to only
include sound levels for the N loudest participants. UI implementors
could then use a similar algorithm when presenting the information.

How does this sound?

Cheers
Emil


> Whilst it might be easy to find protocol solutions, we
> need to be confident that people will find ways of exploiting them in a
> reasonable way at the user interface. Certainly worth exploring.
> 
> John
> 
> 
>> -----Original Message-----
>> From: dispatch-bounces@ietf.org 
>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Enrico Marocco
>> Sent: 27 May 2009 21:02
>> To: Cullen Jennings
>> Cc: dispatch@ietf.org
>> Subject: Re: [dispatch] Yet another problem to dispatch
>>
>> Cullen Jennings wrote:
>>> I find this "active speaker" problem very interesting. Often the  
>>> device that wants to display the active speaker information 
>> is not the  
>>> same as the device dealing with the RTP. For example, most the  
>>> conference systems I am using a phone but there is a web interface  
>>> that is dealing with active speaker information on my 
>> browser which is  
>>> no on my phone. Be interesting to look at all the existing 
>> approaches  
>>> to this.
>> Yes, I'm familiar with that kind of systems. However, the 
>> information we
>> are considering -- instantaneous sound levels of each 
>> participant -- is
>> definitely changing more rapidly than just active speaker 
>> indication and
>> also has more stringent synchronization requirements. That's why our
>> favorite approach would be to carry it in the media streams 
>> themselves,
>>  with some sort of a modulation of the RTP CSRC fields that could be
>> considered either an hack or an elegant solution. I would be very
>> interested in hearing any opinions about that.
>>
>> -- 
>> Ciao,
>> Enrico
>>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
> 

-- 
Emil Ivov, Ph.D.                               30a rue de la Patrie
Project Lead                                   67300 Schiltigheim
SIP Communicator
emcho@sip-communicator.org                     FAX:   +33.1.77.62.47.31
http://sip-communicator.org                    PHONE: +33.1.77.62.43.30

From john.elwell@siemens-enterprise.com  Thu May 28 06:17:54 2009
Return-Path: <john.elwell@siemens-enterprise.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9AC83A6BAA for <dispatch@core3.amsl.com>; Thu, 28 May 2009 06:17:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.462
X-Spam-Level: 
X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.138,  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 P0VX34lZVzbS for <dispatch@core3.amsl.com>; Thu, 28 May 2009 06:17:53 -0700 (PDT)
Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 4A74F3A6C2E for <dispatch@ietf.org>; Thu, 28 May 2009 06:17:53 -0700 (PDT)
Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KKC0048ZVOLXU@siemenscomms.co.uk> for dispatch@ietf.org; Thu, 28 May 2009 14:19:33 +0100 (BST)
Date: Thu, 28 May 2009 14:19:33 +0100
From: "Elwell, John" <john.elwell@siemens-enterprise.com>
In-reply-to: <4A1E8B2E.1030906@sip-communicator.org>
To: Emil Ivov <emcho@sip-communicator.org>
Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001F18237@GBNTHT12009MSX.gb002.siemens.net>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: quoted-printable
Thread-Topic: [dispatch] Yet another problem to dispatch
Thread-Index: AcnflHJTZOkq2lS5T1SXnEWQMJdYHQAAb18g
Content-class: urn:content-classes:message
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
References: <4A15D99F.9060100@sip-communicator.org> <EA1CBEDB-319A-43BC-B874-909B8267F017@cisco.com> <4A1D9C2C.8030108@telecomitalia.it> <0D5F89FAC29E2C41B98A6A762007F5D001F17EE4@GBNTHT12009MSX.gb002.siemens.net> <4A1E8B2E.1030906@sip-communicator.org>
Cc: dispatch@ietf.org
Subject: Re: [dispatch] Yet another problem to dispatch
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 May 2009 13:17:55 -0000

Emil,

But then you would need some sort of throttling, to prevent the UI
constantly changing the list of names whose volumes are displayed. If
the mixer were to do this throttling it would reduce the frequency of
messages, which might allow a bigger choice of potential solutions.

These are just initial thoughts on my part, not firm opinions.

John


> -----Original Message-----
> From: Emil Ivov [mailto:emil@sip-communicator.org] On Behalf=20
> Of Emil Ivov
> Sent: 28 May 2009 14:02
> To: Elwell, John
> Cc: Enrico Marocco; Cullen Jennings; dispatch@ietf.org
> Subject: Re: [dispatch] Yet another problem to dispatch
>=20
> Hey John,
>=20
> Elwell, John wrote:
> > Background noise in conferences is certainly a big issue.=20
> The web-type
> > interface that Cullen mentions does in fact allow the moderator to
> > momentarily mute each suspected noisy party in turn to=20
> discover who is
> > the culprit. Clearly this is not scalable to large=20
> conferences. But also
> > a simultaneous display of noise levels (e.g., in the form=20
> of bar graphs)
> > is not scalable.=20
>=20
> One way to address this would be to allow mixer implementors to only
> include sound levels for the N loudest participants. UI implementors
> could then use a similar algorithm when presenting the information.
>=20
> How does this sound?
>=20
> Cheers
> Emil
>=20
>=20
> > Whilst it might be easy to find protocol solutions, we
> > need to be confident that people will find ways of=20
> exploiting them in a
> > reasonable way at the user interface. Certainly worth exploring.
> >=20
> > John
> >=20
> >=20
> >> -----Original Message-----
> >> From: dispatch-bounces@ietf.org=20
> >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Enrico Marocco
> >> Sent: 27 May 2009 21:02
> >> To: Cullen Jennings
> >> Cc: dispatch@ietf.org
> >> Subject: Re: [dispatch] Yet another problem to dispatch
> >>
> >> Cullen Jennings wrote:
> >>> I find this "active speaker" problem very interesting. Often the =20
> >>> device that wants to display the active speaker information=20
> >> is not the =20
> >>> same as the device dealing with the RTP. For example, most the =20
> >>> conference systems I am using a phone but there is a web=20
> interface =20
> >>> that is dealing with active speaker information on my=20
> >> browser which is =20
> >>> no on my phone. Be interesting to look at all the existing=20
> >> approaches =20
> >>> to this.
> >> Yes, I'm familiar with that kind of systems. However, the=20
> >> information we
> >> are considering -- instantaneous sound levels of each=20
> >> participant -- is
> >> definitely changing more rapidly than just active speaker=20
> >> indication and
> >> also has more stringent synchronization requirements.=20
> That's why our
> >> favorite approach would be to carry it in the media streams=20
> >> themselves,
> >>  with some sort of a modulation of the RTP CSRC fields=20
> that could be
> >> considered either an hack or an elegant solution. I would be very
> >> interested in hearing any opinions about that.
> >>
> >> --=20
> >> Ciao,
> >> Enrico
> >>
> > _______________________________________________
> > dispatch mailing list
> > dispatch@ietf.org
> > https://www.ietf.org/mailman/listinfo/dispatch
> >=20
>=20
> --=20
> Emil Ivov, Ph.D.                               30a rue de la Patrie
> Project Lead                                   67300 Schiltigheim
> SIP Communicator
> emcho@sip-communicator.org                     FAX:  =20
> +33.1.77.62.47.31
> http://sip-communicator.org                    PHONE:=20
> +33.1.77.62.43.30
>=20

From scott.lawrence@nortel.com  Thu May 28 06:52:31 2009
Return-Path: <scott.lawrence@nortel.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 941B53A6ED1 for <dispatch@core3.amsl.com>; Thu, 28 May 2009 06:52:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.21
X-Spam-Level: 
X-Spam-Status: No, score=-6.21 tagged_above=-999 required=5 tests=[AWL=0.389,  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 TXmAIbag22Rb for <dispatch@core3.amsl.com>; Thu, 28 May 2009 06:52:30 -0700 (PDT)
Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 6FD273A6DF8 for <dispatch@ietf.org>; Thu, 28 May 2009 06:52:30 -0700 (PDT)
Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n4SDqpf00243; Thu, 28 May 2009 13:52:51 GMT
Received: from [127.0.0.1] ([47.17.25.99]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 May 2009 09:53:58 -0400
From: "Scott Lawrence" <scott.lawrence@nortel.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
In-Reply-To: <CA9998CD4A020D418654FCDEF4E707DF0D25EB35@esealmw113.eemea.ericsson.se>
References: <CA9998CD4A020D418654FCDEF4E707DF0D234264@esealmw113.eemea.ericsson.se> <9A1E3501-4871-48B3-B39A-80E8E167F4A5@softarmor.com> <CA9998CD4A020D418654FCDEF4E707DF0D25EB35@esealmw113.eemea.ericsson.se>
Content-Type: text/plain
Organization: Nortel Networks
Date: Thu, 28 May 2009 09:53:55 -0400
Message-Id: <1243518835.3422.10.camel@scott>
Mime-Version: 1.0
X-Mailer: Evolution 2.24.5 (2.24.5-1.fc10) 
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 28 May 2009 13:53:59.0176 (UTC) FILETIME=[C00CD080:01C9DF9B]
Cc: dispatch@ietf.org
Subject: Re: [dispatch] Draft: CBUS (Condition-based URI Subscription) requirements draft - draft-holmberg-dispatch-cbus-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 May 2009 13:52:31 -0000

On Thu, 2009-05-28 at 08:53 +0200, Christer Holmberg wrote:
> 
> So, the idea is to use the existing SIP SUB/NOT mechanism. The only
> "new" thing is to provide the conditions as part of the subscription.

What's new about that?  The target of a SUBSCRIBE is a URI, which can
include parameters.  Putting a body on a SUBSCRIBE request that further
extends those parameters is already allowed (eg RFC 5367), and a server
is free to use any part of a SUBSCRIBE request to determine whether or
not to create a subscription and what data to send in the resulting
NOTIFY messages.

Neither defining an event package for a particular application (which is
what this appears to be), nor defining how to communicate parameters in
the requests used by that application require any change to the
protocol.

While I'm sure this is interesting work, I don't see any reason why it
should consume IETF working group time - you'd spend almost all the time
educating other participants about the application requirements.  

I'd say go ahead and develop what you need, and if you think it would be
useful to publish the results as an Informational document there's no
reason not to do so as an individual submission.

Of course, if you find some prohibition or constraint in the existing
specifications that you think needs modifying, then that would be worth
IETF review.



From eburger@standardstrack.com  Thu May 28 07:17:11 2009
Return-Path: <eburger@standardstrack.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B048B3A6D7E for <dispatch@core3.amsl.com>; Thu, 28 May 2009 07:17:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.394
X-Spam-Level: 
X-Spam-Status: No, score=-2.394 tagged_above=-999 required=5 tests=[AWL=0.205,  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 hJ62RjiyBlNm for <dispatch@core3.amsl.com>; Thu, 28 May 2009 07:17:10 -0700 (PDT)
Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id 8A9653A6B03 for <dispatch@ietf.org>; Thu, 28 May 2009 07:17:08 -0700 (PDT)
Received: from c-75-68-112-157.hsd1.nh.comcast.net ([75.68.112.157] helo=[192.168.45.100]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from <eburger@standardstrack.com>) id 1M9gRC-00033S-NR; Thu, 28 May 2009 07:18:31 -0700
Message-Id: <5B79A4F1-5AEE-48B0-9D8B-D6F1549A759D@standardstrack.com>
From: Eric Burger <eburger@standardstrack.com>
To: Jason Fischl <jason.fischl@skype.net>
In-Reply-To: <C641C6CE.D74E%jason.fischl@skype.net>
Content-Type: multipart/signed; boundary=Apple-Mail-133-1072623550; micalg=sha1; protocol="application/pkcs7-signature"
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Thu, 28 May 2009 10:18:32 -0400
References: <C641C6CE.D74E%jason.fischl@skype.net>
X-Mailer: Apple Mail (2.935.3)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Cc: dispatch@ietf.org
Subject: Re: [dispatch] Proposal to form Internet Wideband Audio Codec WG
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 May 2009 14:17:11 -0000

--Apple-Mail-133-1072623550
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: 7bit

Smells to me either a binary situation:

Best Case: A bunch of people know exactly what they want and they just  
need to document it. Do it in AVT.

Worst Case: We know what we need in terms of requirements, but we are  
not sure how to get there. Smells like a math problem. Do it in the  
IRTF.

Either way, I don't see a work group here.

Just a personal opinion.

On May 26, 2009, at 7:18 PM, Jason Fischl wrote:

> All,
>
> I would like to request agenda time inside the DISPATCH meeting to  
> propose
> the formation of a new working group to define a Proposed Standard  
> wideband
> audio codec.
>
> The text of the proposal is below. Comments, questions, and  
> suggestions
> welcomed.
>
> Regards,
> Jason
>
>
> Internet Wideband Audio Codec (IWAC)
> Mailing Lists: TBD
> Chairs: TBD
> Area Directorate: Real Time Applications (RAI)
>
> Purpose:
>
> This new working group would be chartered with the purpose of  
> collecting
> expertise within the IETF in order to review the design of audio  
> codecs
> specifically for use with the Internet. Unlike other SDOs, these  
> codecs
> would be optimized for use on the Internet, and as much as possible  
> choose
> technology that does not require paying patent royalties.
>
> The Internet Low Bit Rate Codec (iLBC)  work was done in AVT but it  
> was felt
> that subsequent work should not be done in the AVT working group.  
> This new
> working group will have as its primary purpose the standardization  
> of a
> multi-purpose audio codec that can be used in various situations on  
> the
> Internet. Some of the proposed Internet-specific requirements include:
> * scalable and adaptive bit rate;
> * various sampling rate profiles from narrow-band to super-wideband;
> * scalable complexity;
> * low latency; and
> * resilience to packet loss.
>
> There are a number of wide-band capable codecs defined by other  
> SDOs. For
> instance, G.722 is seeing adoption in Enterprise applications since  
> it is
> relatively simple and low-cost to deploy. However, it has a high,  
> fixed
> bitrate and is not appropriate for mobile applications where spectrum
> efficiency is important or in consumer applications where available
> bandwidth is fluctuating or limited. G.722.2 (AMR-wideband) has been  
> adopted
> by the 3GPP as a wideband standard for mobile applications. G.722.2 is
> relatively high cost due to patent royalties and is seeing minimal
> deployments outside of mobile handsets making it challenging to create
> wideband experiences on Internet-capable mobile devices when extending
> beyond the mobile network. In other cases, proprietary codecs are  
> being
> adopted which further create islands with no interoperability unless
> widespread transcoding is performed. Transcoding leads to higher  
> costs and
> lower quality.
>
> The goal of this working group is to define a single codec with  
> multiple
> profiles which can be made available on a wide variety of Internet- 
> capable
> devices including low-power, mobile devices as well as devices  
> capable of
> utilizing high quality, high bitrate audio.
>
> Proposed Deliverables:
>
> 1) Requirements for wideband, Internet audio codec(s).
> 2) Algorithm description for wideband, Internet audio codec(s) as  
> Proposed
> Standard.
> 3) Specification of payload format(s) for defined codecs as Proposed
> Standard
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch


--Apple-Mail-133-1072623550
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGPTCCBjkw
ggUhoAMCAQICEC+VK1RLWxrF8KJZDR9k8p8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVT
MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS
VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQD
Ey1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwODEz
MDAwMDAwWhcNMDkwODEzMjM1OTU5WjCB4TE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsg
LSBQRVJTT05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9m
IHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMg
Q29tb2RvIExpbWl0ZWQxFDASBgNVBAMTC0VyaWMgQnVyZ2VyMSkwJwYJKoZIhvcNAQkBFhplYnVy
Z2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMTF
RRoA4LgOACMFph0aomRC/UpqoA5C/d6DUTOvTMrYSEqkjwnU4zxDtBcHlcB4AxKAov00MYsUvEU4
loz7BHjfDjv76AIkcwu33VYQbzGmarVnyaXsVb6f/cyRL3fPT0VOVO2tQAEEgwg//CX0jN8Kn2jH
uXD/HEvko7cmpL3Pwevf3+DwB61v7ca79PpEZfn/WhaqRKA4uVNPj/JbieeaLo2v/0RJzrEElZK0
pHCqxiD3mQ8ossPkA9fUCSxLlbdMcPU3be5x8vt8Q8mYTXF5Z3d9RZmYrmNkvTQtdzVpfYWr/hgV
Xqm9tByOOAR+hoN3FKbubR/OrAHL9yDAd4sCAwEAAaOCAhwwggIYMB8GA1UdIwQYMBaAFImCZ33E
nSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRDWgutb7b8R/L7G3Y3D+molAA3VzAOBgNVHQ8BAf8E
BAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJ
YIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEW
HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6
Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRF
bWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVu
dEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYq
aHR0cDovL2NydC5jb21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhho
dHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJQYDVR0RBB4wHIEaZWJ1cmdlckBzdGFuZGFyZHN0cmFj
ay5jb20wDQYJKoZIhvcNAQEFBQADggEBAGeBR7NPCvrY3GQoIi49JOuciatY2r4st905Jw1etp6J
umFFWlaCBl11tFSclk/3S45B+lUv3SEvG4CEjUByPScprVmCqHR+y8BAQaB/CV+N1y14x3MbhJ+Z
8XDGKeUXuuyGd9w0l3/t/QPid6TRXQjQFrLPFs1IALuNpNiFMHEF/xFbMG1Z2vznR/gSPlePekoZ
TqcExIDBNZTBebpZqwAXzPpedNNOclbMLFLWDMOAozVRpkfjI0eiFsk8SF1Ho1Gb9Bx8DeG4peE2
KRVOR9FFnZZgBpFjXYRcglsMOSKCY8HgE+NGvbbqbrMoBV/BlYyxRXwfti71RL9Zs2Cq1eQxggP8
MIID+AIBATCBwzCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh
a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v
d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp
Y2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkNH2TynzAJBgUrDgMCGgUAoIICDTAYBgkqhkiG
9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA1MjgxNDE4MzJaMCMGCSqGSIb3
DQEJBDEWBBQKph8s7cMaqI79wNzyXSj1Y1FlzDCB1AYJKwYBBAGCNxAEMYHGMIHDMIGuMQswCQYD
VQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVU
aGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2
MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhAv
lStUS1saxfCiWQ0fZPKfMIHWBgsqhkiG9w0BCRACCzGBxqCBwzCBrjELMAkGA1UEBhMCVVMxCzAJ
BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT
VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU
Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkN
H2TynzANBgkqhkiG9w0BAQEFAASCAQCTBrP2PULkmSw+WoprhnyQUAkJdYHj8RKfkn1fgtoW7Pi2
14srapa1Lc2iL6QMC8NXA/G2FkWuBdtprbQi068Yc73MXsdW9GnvFQQhCLl+pFpn3SNRK/FJsUA3
/Ir71ZQ0MUff6vEQEBd9ZQu6Wkeh9QN6D42r4Wmq5PQDPDEPy10LiIuSsjE7v+AyrhzOG67+B+mK
LEeQdIpD241HBpJbCj6vM+U9k8wdqNQnKgBK7QuCX/BBW8eLhpKKpdStmCS0XFPBE82qU2vOMA71
alLY+HzatM3um5Fumdh40Bm7D2we1RH0c5uEgADe8TLOoQ3TsUu4eNbSPoT/XntjLw1VAAAAAAAA

--Apple-Mail-133-1072623550--

From ron.even.tlv@gmail.com  Thu May 28 07:45:30 2009
Return-Path: <ron.even.tlv@gmail.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FDE83A6EEF for <dispatch@core3.amsl.com>; Thu, 28 May 2009 07:45:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.499
X-Spam-Level: 
X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100,  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 vk3ScC3bJgPY for <dispatch@core3.amsl.com>; Thu, 28 May 2009 07:45:25 -0700 (PDT)
Received: from mail-bw0-f222.google.com (mail-bw0-f222.google.com [209.85.218.222]) by core3.amsl.com (Postfix) with ESMTP id 9EA763A6E87 for <dispatch@ietf.org>; Thu, 28 May 2009 07:45:24 -0700 (PDT)
Received: by bwz22 with SMTP id 22so5494491bwz.37 for <dispatch@ietf.org>; Thu, 28 May 2009 07:46:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=c9LZD3syDEaLepUlJsrOweJIdpl9+3DVn+hgq99oG6o=; b=rEMJ01z2OX0Pp8wS2J/8EIaPtAxWUG+fu+0v93DRrKkCLflY2MXO3hmZpxFo6CnfID 2nb2srqAZ8cpWB4AvG58Xp7NE7g7eBfvpxR8d/RSkvgg2I5lZAfGmNU2daybeiDFcFyy IK61z2oYWYCxhLAnHPJAgG9qkQikWer9m6nVE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; b=PGafeKNI3M2Q6w262Rc+SaucDq8rbCheATm4h+QH9RRbCSihKhggPb91XDR1XCrKhk rJNmJZIZwnPMvP8UEml8lW331rWyJSZQHDNtub21CFktWcM/E1hIDNvVJlaBFGZnnAg1 xqtTOTD+lItUtuNlznYgrtVH6I5ljgvtnwm7U=
Received: by 10.103.226.10 with SMTP id d10mr863009mur.105.1243522019424; Thu, 28 May 2009 07:46:59 -0700 (PDT)
Received: from windows8d787f9 (bzq-79-181-138-75.red.bezeqint.net [79.181.138.75]) by mx.google.com with ESMTPS id s10sm210289mue.8.2009.05.28.07.46.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 28 May 2009 07:46:58 -0700 (PDT)
From: "Roni Even" <ron.even.tlv@gmail.com>
To: "'Jason Fischl'" <jason.fischl@skype.net>, <dispatch@ietf.org>
References: <C641C6CE.D74E%jason.fischl@skype.net>
In-Reply-To: <C641C6CE.D74E%jason.fischl@skype.net>
Date: Thu, 28 May 2009 17:45:53 +0300
Message-ID: <4a1ea3e2.0aaa660a.0cc2.18d4@mx.google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcneWEMKfMLxcIB/zk+aK3yDPFDcEwBSLupQ
Content-Language: en-us
Subject: Re: [dispatch] Proposal to form Internet Wideband Audio Codec WG
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 May 2009 14:45:30 -0000

Hi,
Like you mention other SDOs like ITU-T are doing just that. They have the
expertise to specify, and evaluate the result. These SDOs can receive
requirements and select a proper codec based on the requirements.


As for the other reasons:

1. Defining a codec in the IETF or even in MPEG / ITU-T does not make it a
mandatory part of a system solution, this is done by other standard bodies
like 3GPP, ETSI.

2. The IETF, similar to other standard bodies is not rubber stamping a
specific solution, so you will most probably see in the final result some
technology that carry IPR.

3. If this group will be established, you will probably see here the audio
experts now working in ITU-T arguing the same issues since they are the
expertise you need and they work for the same companies that are already
members of IETF. 

I think that if you have a specific codec in mind you  can make it publicly
available maybe with quality results and standardized in AVT a payload
specification.

BTW: The ITU is keeping a list of codecs (Not only ITU-T ones) in a table
that describes their features. 

Regards
Roni Even

-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf
Of Jason Fischl
Sent: Wednesday, May 27, 2009 2:18 AM
To: dispatch@ietf.org
Subject: [dispatch] Proposal to form Internet Wideband Audio Codec WG

All,

I would like to request agenda time inside the DISPATCH meeting to propose
the formation of a new working group to define a Proposed Standard wideband
audio codec.

The text of the proposal is below. Comments, questions, and suggestions
welcomed.

Regards, 
Jason


Internet Wideband Audio Codec (IWAC)
Mailing Lists: TBD
Chairs: TBD
Area Directorate: Real Time Applications (RAI)

Purpose:

This new working group would be chartered with the purpose of collecting
expertise within the IETF in order to review the design of audio codecs
specifically for use with the Internet. Unlike other SDOs, these codecs
would be optimized for use on the Internet, and as much as possible choose
technology that does not require paying patent royalties.

The Internet Low Bit Rate Codec (iLBC)  work was done in AVT but it was felt
that subsequent work should not be done in the AVT working group. This new
working group will have as its primary purpose the standardization of a
multi-purpose audio codec that can be used in various situations on the
Internet. Some of the proposed Internet-specific requirements include:
* scalable and adaptive bit rate;
* various sampling rate profiles from narrow-band to super-wideband;
* scalable complexity;
* low latency; and 
* resilience to packet loss.

There are a number of wide-band capable codecs defined by other SDOs. For
instance, G.722 is seeing adoption in Enterprise applications since it is
relatively simple and low-cost to deploy. However, it has a high, fixed
bitrate and is not appropriate for mobile applications where spectrum
efficiency is important or in consumer applications where available
bandwidth is fluctuating or limited. G.722.2 (AMR-wideband) has been adopted
by the 3GPP as a wideband standard for mobile applications. G.722.2 is
relatively high cost due to patent royalties and is seeing minimal
deployments outside of mobile handsets making it challenging to create
wideband experiences on Internet-capable mobile devices when extending
beyond the mobile network. In other cases, proprietary codecs are being
adopted which further create islands with no interoperability unless
widespread transcoding is performed. Transcoding leads to higher costs and
lower quality. 

The goal of this working group is to define a single codec with multiple
profiles which can be made available on a wide variety of Internet-capable
devices including low-power, mobile devices as well as devices capable of
utilizing high quality, high bitrate audio.

Proposed Deliverables:

1) Requirements for wideband, Internet audio codec(s).
2) Algorithm description for wideband, Internet audio codec(s) as Proposed
Standard. 
3) Specification of payload format(s) for defined codecs as Proposed
Standard

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


From scott.lawrence@nortel.com  Thu May 28 08:16:29 2009
Return-Path: <scott.lawrence@nortel.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7DD73A6A5E for <dispatch@core3.amsl.com>; Thu, 28 May 2009 08:16:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.242
X-Spam-Level: 
X-Spam-Status: No, score=-6.242 tagged_above=-999 required=5 tests=[AWL=0.357,  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 hbGnWUuM+FIy for <dispatch@core3.amsl.com>; Thu, 28 May 2009 08:16:29 -0700 (PDT)
Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id D73753A6860 for <dispatch@ietf.org>; Thu, 28 May 2009 08:16:01 -0700 (PDT)
Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n4SFHer28132; Thu, 28 May 2009 15:17:40 GMT
Received: from [127.0.0.1] ([47.17.25.99]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 May 2009 11:17:36 -0400
From: "Scott Lawrence" <scott.lawrence@nortel.com>
To: Jason Fischl <jason.fischl@skype.net>
In-Reply-To: <C641C6CE.D74E%jason.fischl@skype.net>
References: <C641C6CE.D74E%jason.fischl@skype.net>
Content-Type: text/plain
Organization: Nortel Networks
Date: Thu, 28 May 2009 11:17:35 -0400
Message-Id: <1243523855.5376.4.camel@scott>
Mime-Version: 1.0
X-Mailer: Evolution 2.24.5 (2.24.5-1.fc10) 
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 28 May 2009 15:17:37.0006 (UTC) FILETIME=[6EE8E8E0:01C9DFA7]
Cc: dispatch@ietf.org
Subject: Re: [dispatch] Proposal to form Internet Wideband Audio Codec WG
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 May 2009 15:16:29 -0000

On Tue, 2009-05-26 at 16:18 -0700, Jason Fischl wrote:
> 
> This new working group would be chartered with the purpose of collecting
> expertise within the IETF in order to review the design of audio codecs
> specifically for use with the Internet. Unlike other SDOs, these codecs
> would be optimized for use on the Internet, and as much as possible choose
> technology that does not require paying patent royalties.

This last: "as much as possible choose technology that does not require
paying patent royalties" is a bit of a minefield.  The IETF IPR regime
is not a good one for even checking whether or not you are getting that
result (in some ways our disclosure policies amount to "don't ask don't
tell"), much less making it enforceable.  Other SDOs have 'membership'
and IPR provisions that at least make it possible to make agreements
about mutual licensing among participants - the IETF does not have any
such structures.



From emil@sip-communicator.org  Thu May 28 09:26:56 2009
Return-Path: <emil@sip-communicator.org>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B751C3A6D6B for <dispatch@core3.amsl.com>; Thu, 28 May 2009 09:26:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.150,  BAYES_00=-2.599, HELO_EQ_FR=0.35]
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 ORNN3vic4LN4 for <dispatch@core3.amsl.com>; Thu, 28 May 2009 09:26:55 -0700 (PDT)
Received: from mail-bw0-f222.google.com (mail-bw0-f222.google.com [209.85.218.222]) by core3.amsl.com (Postfix) with ESMTP id 2EE4D3A6C2E for <dispatch@ietf.org>; Thu, 28 May 2009 09:26:54 -0700 (PDT)
Received: by bwz22 with SMTP id 22so5567011bwz.37 for <dispatch@ietf.org>; Thu, 28 May 2009 09:28:35 -0700 (PDT)
Received: by 10.103.226.10 with SMTP id d10mr928226mur.84.1243528115280; Thu, 28 May 2009 09:28:35 -0700 (PDT)
Received: from porcinet.u-strasbg.fr (porcinet.u-strasbg.fr [130.79.91.167]) by mx.google.com with ESMTPS id 14sm540236muo.33.2009.05.28.09.28.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 28 May 2009 09:28:33 -0700 (PDT)
Sender: Emil Ivov <emil@sip-communicator.org>
Message-ID: <4A1EBBAE.4090609@sip-communicator.org>
Date: Thu, 28 May 2009 18:28:30 +0200
From: Emil Ivov <emcho@sip-communicator.org>
Organization: SIP Communicator
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
MIME-Version: 1.0
To: dispatch@ietf.org
References: <4A15D99F.9060100@sip-communicator.org> <EA1CBEDB-319A-43BC-B874-909B8267F017@cisco.com> <4A1D9C2C.8030108@telecomitalia.it> <0D5F89FAC29E2C41B98A6A762007F5D001F17EE4@GBNTHT12009MSX.gb002.siemens.net> <4A1E8B2E.1030906@sip-communicator.org> <0D5F89FAC29E2C41B98A6A762007F5D001F18237@GBNTHT12009MSX.gb002.siemens.net>
In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001F18237@GBNTHT12009MSX.gb002.siemens.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [dispatch] Yet another problem to dispatch
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 May 2009 16:26:56 -0000

Hey John,

Elwell, John wrote:
> Emil,
> 
> But then you would need some sort of throttling, to prevent the UI
> constantly changing the list of names whose volumes are displayed. If
> the mixer were to do this throttling it would reduce the frequency of
> messages, which might allow a bigger choice of potential solutions.

I am not sure I understand exactly what you mean by throttling. Mixers
could be implemented to only include sound level information for the
loudest speakers thus having the possibility to ignore silent and almost
silent ones. It should be up to the mixer to determine the exact
threshold since that's where bandwidth would be most precious. Is this
what you are suggesting?

Then, once a client gets this information it can consider (and I guess
that's in line with 3550) that all CSRCs not present in a particular
packet have been silent for the corresponding period of time.

As to how exactly the client would render the sound level information,
whether or not it would display all of it, and whether it would somehow
rearrange participants, that should really be up to the UI implementors.

Does this make sense?

Cheers
Emil


> 
> These are just initial thoughts on my part, not firm opinions.
> 
> John
> 
> 
>> -----Original Message-----
>> From: Emil Ivov [mailto:emil@sip-communicator.org] On Behalf 
>> Of Emil Ivov
>> Sent: 28 May 2009 14:02
>> To: Elwell, John
>> Cc: Enrico Marocco; Cullen Jennings; dispatch@ietf.org
>> Subject: Re: [dispatch] Yet another problem to dispatch
>>
>> Hey John,
>>
>> Elwell, John wrote:
>>> Background noise in conferences is certainly a big issue. 
>> The web-type
>>> interface that Cullen mentions does in fact allow the moderator to
>>> momentarily mute each suspected noisy party in turn to 
>> discover who is
>>> the culprit. Clearly this is not scalable to large 
>> conferences. But also
>>> a simultaneous display of noise levels (e.g., in the form 
>> of bar graphs)
>>> is not scalable. 
>> One way to address this would be to allow mixer implementors to only
>> include sound levels for the N loudest participants. UI implementors
>> could then use a similar algorithm when presenting the information.
>>
>> How does this sound?
>>
>> Cheers
>> Emil
>>
>>
>>> Whilst it might be easy to find protocol solutions, we
>>> need to be confident that people will find ways of 
>> exploiting them in a
>>> reasonable way at the user interface. Certainly worth exploring.
>>>
>>> John
>>>
>>>
>>>> -----Original Message-----
>>>> From: dispatch-bounces@ietf.org 
>>>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Enrico Marocco
>>>> Sent: 27 May 2009 21:02
>>>> To: Cullen Jennings
>>>> Cc: dispatch@ietf.org
>>>> Subject: Re: [dispatch] Yet another problem to dispatch
>>>>
>>>> Cullen Jennings wrote:
>>>>> I find this "active speaker" problem very interesting. Often the  
>>>>> device that wants to display the active speaker information 
>>>> is not the  
>>>>> same as the device dealing with the RTP. For example, most the  
>>>>> conference systems I am using a phone but there is a web 
>> interface  
>>>>> that is dealing with active speaker information on my 
>>>> browser which is  
>>>>> no on my phone. Be interesting to look at all the existing 
>>>> approaches  
>>>>> to this.
>>>> Yes, I'm familiar with that kind of systems. However, the 
>>>> information we
>>>> are considering -- instantaneous sound levels of each 
>>>> participant -- is
>>>> definitely changing more rapidly than just active speaker 
>>>> indication and
>>>> also has more stringent synchronization requirements. 
>> That's why our
>>>> favorite approach would be to carry it in the media streams 
>>>> themselves,
>>>>  with some sort of a modulation of the RTP CSRC fields 
>> that could be
>>>> considered either an hack or an elegant solution. I would be very
>>>> interested in hearing any opinions about that.
>>>>
>>>> -- 
>>>> Ciao,
>>>> Enrico
>>>>
>>> _______________________________________________
>>> dispatch mailing list
>>> dispatch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dispatch
>>>
>> -- 
>> Emil Ivov, Ph.D.                               30a rue de la Patrie
>> Project Lead                                   67300 Schiltigheim
>> SIP Communicator
>> emcho@sip-communicator.org                     FAX:   
>> +33.1.77.62.47.31
>> http://sip-communicator.org                    PHONE: 
>> +33.1.77.62.43.30
>>
> 

-- 
Emil Ivov, Ph.D.                               30a rue de la Patrie
Project Lead                                   67300 Schiltigheim
SIP Communicator
emcho@sip-communicator.org                     FAX:   +33.1.77.62.47.31
http://sip-communicator.org                    PHONE: +33.1.77.62.43.30

From dean.willis@softarmor.com  Thu May 28 11:01:21 2009
Return-Path: <dean.willis@softarmor.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB3A03A6C5C for <dispatch@core3.amsl.com>; Thu, 28 May 2009 11:01:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.432
X-Spam-Level: 
X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167,  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 3tntoUw+Pjsg for <dispatch@core3.amsl.com>; Thu, 28 May 2009 11:01:20 -0700 (PDT)
Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id CD0CB3A6A40 for <dispatch@ietf.org>; Thu, 28 May 2009 11:00:50 -0700 (PDT)
Received: from [192.168.2.103] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n4SI2TV9014051 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 28 May 2009 13:02:31 -0500
Message-Id: <5F03A1A1-B082-4FDD-8037-56728EA6A8E4@softarmor.com>
From: Dean Willis <dean.willis@softarmor.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
In-Reply-To: <CA9998CD4A020D418654FCDEF4E707DF0D25EB35@esealmw113.eemea.ericsson.se>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Thu, 28 May 2009 13:02:24 -0500
References: <CA9998CD4A020D418654FCDEF4E707DF0D234264@esealmw113.eemea.ericsson.se> <9A1E3501-4871-48B3-B39A-80E8E167F4A5@softarmor.com> <CA9998CD4A020D418654FCDEF4E707DF0D25EB35@esealmw113.eemea.ericsson.se>
X-Mailer: Apple Mail (2.935.3)
Cc: dispatch@ietf.org
Subject: Re: [dispatch] Draft: CBUS (Condition-based URI Subscription) requirements draft - draft-holmberg-dispatch-cbus-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 May 2009 18:01:21 -0000

On May 28, 2009, at 1:53 AM, Christer Holmberg wrote:
> ...

> So, the idea is to use the existing SIP SUB/NOT mechanism. The only
> "new" thing is to provide the conditions as part of the subscription.
>
> Third, I am not sure I would call it a configuration-delivery problem.
> Of course, the conditions can be said to "configure" the CBUS server,
> when it starts looking for matching URIs. But, the conditions can be
> unique for every subscription, so that is the reason why it is  
> proposed
> to deliver the subscription specific conditions as part of the
> subscription.
>

Ok, this is starting to make more sense to me. I suspect it's a case  
of SIP-for-light-bulbs, but that's OK with me; I liked the idea of  
controlling light bulbs using SIP to start with. We have a general- 
purpose rendezvous, messaging,  and pub/sub protocol here, and it  
seems silly to say it's only usable for phone calls. Of course, the  
same could be said for XMPP ;-).

How are these "conditions" you describe different from the "filters"  
of  RFC 4660?

 From RFC 4660's abstract:

> This document describes the operations a subscriber performs in  
> order to put filtering rules associated with a subscription to event  
> notification information in place. The handling, by the subscriber,  
> of responses to subscriptions carrying filtering rules and the  
> handling of notifications with filtering rules applied to them are  
> also described. Furthermore, the document conveys how the notifier  
> behaves when receiving such filtering rules and how a notification  
> is constructed.

Could the "conditions" requirement be met using RFC 4660? If so, we  
don't have a WG problem; we have an individual submission of a new  
informational-track event package.


--
Dean


From christer.holmberg@ericsson.com  Thu May 28 11:07:56 2009
Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40CC03A6E63 for <dispatch@core3.amsl.com>; Thu, 28 May 2009 11:07:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.886
X-Spam-Level: 
X-Spam-Status: No, score=-5.886 tagged_above=-999 required=5 tests=[AWL=0.363,  BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 e2D+-7s-vMTn for <dispatch@core3.amsl.com>; Thu, 28 May 2009 11:07:55 -0700 (PDT)
Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id CB5443A6D2E for <dispatch@ietf.org>; Thu, 28 May 2009 11:07:36 -0700 (PDT)
X-AuditID: c1b4fb3c-b7b28ae000005484-97-4a1ed34e5fa1
Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id EA.39.21636.E43DE1A4; Thu, 28 May 2009 20:09:18 +0200 (CEST)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 28 May 2009 20:09:18 +0200
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: Thu, 28 May 2009 20:09:17 +0200
Message-ID: <CA9998CD4A020D418654FCDEF4E707DF0B16826D@esealmw113.eemea.ericsson.se>
In-Reply-To: <1243518835.3422.10.camel@scott>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dispatch] Draft: CBUS (Condition-based URI Subscription) requirements draft - draft-holmberg-dispatch-cbus-00.txt
Thread-Index: AcnfrDmnMCvIIgZoStyxqrH1h5R0EAADk8cA
References: <CA9998CD4A020D418654FCDEF4E707DF0D234264@esealmw113.eemea.ericsson.se> <9A1E3501-4871-48B3-B39A-80E8E167F4A5@softarmor.com> <CA9998CD4A020D418654FCDEF4E707DF0D25EB35@esealmw113.eemea.ericsson.se> <1243518835.3422.10.camel@scott>
From: "Christer Holmberg" <christer.holmberg@ericsson.com>
To: "Scott Lawrence" <scott.lawrence@nortel.com>
X-OriginalArrivalTime: 28 May 2009 18:09:18.0241 (UTC) FILETIME=[6AECA110:01C9DFBF]
X-Brightmail-Tracker: AAAAAA==
Cc: dispatch@ietf.org
Subject: Re: [dispatch] Draft: CBUS (Condition-based URI Subscription) requirements draft - draft-holmberg-dispatch-cbus-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 May 2009 18:07:56 -0000

Hi,=20

>>So, the idea is to use the existing SIP SUB/NOT mechanism. The only
"new" thing is to provide the conditions as part of the subscription.
>
>What's new about that?  The target of a SUBSCRIBE is a URI, which can
include parameters.=20

Correct. What I meant by "new" was that I wasn't sure we had existing
event packages where you actually provided additional input information
in the SUBSCRIBE request, but I may be wrong.

>Putting a body on a SUBSCRIBE request that further extends those
parameters is already allowed (eg RFC 5367), and a server is free to use
any part of a SUBSCRIBE request to determine whether or not to=20
>create a subscription and what data to send in the resulting NOTIFY
messages.

Yes, but you need to define the parameters/bodies which are used to
carry the conditions, and you need to define the event package which
carries the URIs, and in order to do that you need requirements. That is
what this is all about.

>Neither defining an event package for a particular application (which
is what this appears to be), nor defining how to communicate parameters
in the requests used by that application require any change=20
>to the protocol.

I am not proposing a change to the protocol. I am proposing requirements
for new SIP parameters/body and event package. I didn't talk about SIP
parameters etc in the document, since we are supposed to provide
requirements first. But, I guess I SHOULD say that the document
specifies requirements for new parameter, body and event package, in
order to make it more clear what it is all about.

>While I'm sure this is interesting work, I don't see any reason why it
should consume IETF working group time - you'd spend almost all the time
educating other participants about the application=20
>requirements. =20

So, where do you think the SIP parameters etc should be defined? I
thought IETF was the place to do that...=20

Are you saying that OMA should do it on their own?

>I'd say go ahead and develop what you need, and if you think it would
be useful to publish the results as an Informational document there's no
reason not to do so as an individual submission.

I thought new SIP parameters, bodies and event packages required more
than an informational document.

>Of course, if you find some prohibition or constraint in the existing
specifications that you think needs modifying, then that would be worth
IETF review.

I don't think there is anything in existing specifications that need to
be modified. I was thinking about whether using bodies in SUBSCRIBE
requests would cause some issues (assuming a body would be used to carry
the conditions), but you seem to indicate that it is already allowed...

Regards,

Christer




From christer.holmberg@ericsson.com  Thu May 28 11:15:28 2009
Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 513283A6DF0 for <dispatch@core3.amsl.com>; Thu, 28 May 2009 11:15:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.888
X-Spam-Level: 
X-Spam-Status: No, score=-5.888 tagged_above=-999 required=5 tests=[AWL=0.361,  BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 eDoOdysnCbRP for <dispatch@core3.amsl.com>; Thu, 28 May 2009 11:15:22 -0700 (PDT)
Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id B63623A6E57 for <dispatch@ietf.org>; Thu, 28 May 2009 11:15:14 -0700 (PDT)
X-AuditID: c1b4fb3e-b7b78ae000007894-66-4a1ed517710f
Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id FA.19.30868.715DE1A4; Thu, 28 May 2009 20:16:55 +0200 (CEST)
Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 28 May 2009 20:16:55 +0200
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: Thu, 28 May 2009 20:16:55 +0200
Message-ID: <CA9998CD4A020D418654FCDEF4E707DF0B16826E@esealmw113.eemea.ericsson.se>
In-Reply-To: <5F03A1A1-B082-4FDD-8037-56728EA6A8E4@softarmor.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dispatch] Draft: CBUS (Condition-based URI Subscription) requirements draft - draft-holmberg-dispatch-cbus-00.txt
Thread-Index: AcnfvnoF8HskPKu1RC+C47EC9Z07AAAAQSQg
References: <CA9998CD4A020D418654FCDEF4E707DF0D234264@esealmw113.eemea.ericsson.se> <9A1E3501-4871-48B3-B39A-80E8E167F4A5@softarmor.com> <CA9998CD4A020D418654FCDEF4E707DF0D25EB35@esealmw113.eemea.ericsson.se> <5F03A1A1-B082-4FDD-8037-56728EA6A8E4@softarmor.com>
From: "Christer Holmberg" <christer.holmberg@ericsson.com>
To: "Dean Willis" <dean.willis@softarmor.com>
X-OriginalArrivalTime: 28 May 2009 18:16:55.0207 (UTC) FILETIME=[7B4C1B70:01C9DFC0]
X-Brightmail-Tracker: AAAAAA==
Cc: dispatch@ietf.org
Subject: Re: [dispatch] Draft: CBUS (Condition-based URI Subscription) requirements draft - draft-holmberg-dispatch-cbus-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 May 2009 18:15:28 -0000

Hi,=20

>> So, the idea is to use the existing SIP SUB/NOT mechanism. The only=20
>> "new" thing is to provide the conditions as part of the subscription.
>>
>> Third, I am not sure I would call it a configuration-delivery
problem.
>> Of course, the conditions can be said to "configure" the CBUS server,

>> when it starts looking for matching URIs. But, the conditions can be=20
>> unique for every subscription, so that is the reason why it is=20
>> proposed to deliver the subscription specific conditions as part of=20
>> the subscription.
>>
>
>Ok, this is starting to make more sense to me. I suspect it's a case of
SIP-for-light-bulbs, but that's OK with me; I liked the idea of
controlling light bulbs using SIP to start with. We have a general-=20
>purpose rendezvous, messaging,  and pub/sub protocol here, and it seems
silly to say it's only usable for phone calls. Of course, the same could
be said for XMPP ;-).

I am not sure I would call it SIP-for-light-bulbs either, because you
aren't really "controlling" anything. You are simply providing input
information, which is used by the server to determine which URIs to send
back to you in notifications. But, whatever people want to call it :)

>How are these "conditions" you describe different from the "filters" of
RFC 4660?
>
>From RFC 4660's abstract:
>
> This document describes the operations a subscriber performs in order=20
> to put filtering rules associated with a subscription to event=20
> notification information in place. The handling, by the subscriber, of

> responses to subscriptions carrying filtering rules and the handling=20
> of notifications with filtering rules applied to them are also=20
> described. Furthermore, the document conveys how the notifier behaves=20
> when receiving such filtering rules and how a notification is=20
> constructed.
>
>Could the "conditions" requirement be met using RFC 4660?

I will need to take a closer look at 4660. If it solves the
requirements, that's great.

>If so, we don't have a WG problem; we have an individual submission of
a new informational-track event package.

Ok.

Regards,

Christer

From hsinnrei@adobe.com  Thu May 28 15:15:08 2009
Return-Path: <hsinnrei@adobe.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 200A93A6A53 for <dispatch@core3.amsl.com>; Thu, 28 May 2009 15:15:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.023
X-Spam-Level: 
X-Spam-Status: No, score=-6.023 tagged_above=-999 required=5 tests=[AWL=0.575,  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 JLd3wxwTqKNs for <dispatch@core3.amsl.com>; Thu, 28 May 2009 15:15:06 -0700 (PDT)
Received: from exprod6og106.obsmtp.com (exprod6og106.obsmtp.com [64.18.1.191]) by core3.amsl.com (Postfix) with ESMTP id 281063A691E for <dispatch@ietf.org>; Thu, 28 May 2009 15:15:06 -0700 (PDT)
Received: from source ([192.150.8.22]) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP ID DSNKSh8NTe8+6e8QpeN1KaHOE9Eg9o0MQiBO@postini.com; Thu, 28 May 2009 15:16:50 PDT
Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n4SMGgE0025063; Thu, 28 May 2009 15:16:43 -0700 (PDT)
Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id n4SMFJYf010667; Thu, 28 May 2009 15:16:38 -0700 (PDT)
Received: from fe01.corp.adobe.com (10.8.192.82) by nacas02.corp.adobe.com (10.8.189.100) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 28 May 2009 15:15:16 -0700
Received: from nambx05.corp.adobe.com ([10.8.189.124]) by fe01.corp.adobe.com ([10.8.192.82]) with mapi; Thu, 28 May 2009 08:28:15 -0700
From: Henry Sinnreich <hsinnrei@adobe.com>
To: Roni Even <ron.even.tlv@gmail.com>, Jason Fischl <jason.fischl@skype.net>,  "dispatch@ietf.org" <dispatch@ietf.org>
Date: Thu, 28 May 2009 08:28:13 -0700
Thread-Topic: [dispatch] Proposal to form Internet Wideband Audio Codec WG
Thread-Index: AcneWEMKfMLxcIB/zk+aK3yDPFDcEwBSLupQAAH60o0=
Message-ID: <C64417BD.3D59%hsinnrei@adobe.com>
In-Reply-To: <4a1ea3e2.0aaa660a.0cc2.18d4@mx.google.com>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_C64417BD3D59hsinnreiadobecom_"
MIME-Version: 1.0
Subject: Re: [dispatch] Proposal to form Internet Wideband Audio Codec WG
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 May 2009 22:15:08 -0000

--_000_C64417BD3D59hsinnreiadobecom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Roni,

Sorry, we have here a fundamental disagreement.
The IETF is chartered for Internet standards and may or may not chose solut=
ions that apply to ITU-T networks.
The Internet has different criteria than ITU-T networks may have.
A worldwide Internet standard for a wideband codec will be very beneficial =
IMO.

Henry


On 5/28/09 9:45 AM, "Roni Even" <ron.even.tlv@gmail.com> wrote:

Hi,
Like you mention other SDOs like ITU-T are doing just that. They have the
expertise to specify, and evaluate the result. These SDOs can receive
requirements and select a proper codec based on the requirements.


As for the other reasons:

1. Defining a codec in the IETF or even in MPEG / ITU-T does not make it a
mandatory part of a system solution, this is done by other standard bodies
like 3GPP, ETSI.

2. The IETF, similar to other standard bodies is not rubber stamping a
specific solution, so you will most probably see in the final result some
technology that carry IPR.

3. If this group will be established, you will probably see here the audio
experts now working in ITU-T arguing the same issues since they are the
expertise you need and they work for the same companies that are already
members of IETF.

I think that if you have a specific codec in mind you  can make it publicly
available maybe with quality results and standardized in AVT a payload
specification.

BTW: The ITU is keeping a list of codecs (Not only ITU-T ones) in a table
that describes their features.

Regards
Roni Even

-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal=
f
Of Jason Fischl
Sent: Wednesday, May 27, 2009 2:18 AM
To: dispatch@ietf.org
Subject: [dispatch] Proposal to form Internet Wideband Audio Codec WG

All,

I would like to request agenda time inside the DISPATCH meeting to propose
the formation of a new working group to define a Proposed Standard wideband
audio codec.

The text of the proposal is below. Comments, questions, and suggestions
welcomed.

Regards,
Jason


Internet Wideband Audio Codec (IWAC)
Mailing Lists: TBD
Chairs: TBD
Area Directorate: Real Time Applications (RAI)

Purpose:

This new working group would be chartered with the purpose of collecting
expertise within the IETF in order to review the design of audio codecs
specifically for use with the Internet. Unlike other SDOs, these codecs
would be optimized for use on the Internet, and as much as possible choose
technology that does not require paying patent royalties.

The Internet Low Bit Rate Codec (iLBC)  work was done in AVT but it was fel=
t
that subsequent work should not be done in the AVT working group. This new
working group will have as its primary purpose the standardization of a
multi-purpose audio codec that can be used in various situations on the
Internet. Some of the proposed Internet-specific requirements include:
* scalable and adaptive bit rate;
* various sampling rate profiles from narrow-band to super-wideband;
* scalable complexity;
* low latency; and
* resilience to packet loss.

There are a number of wide-band capable codecs defined by other SDOs. For
instance, G.722 is seeing adoption in Enterprise applications since it is
relatively simple and low-cost to deploy. However, it has a high, fixed
bitrate and is not appropriate for mobile applications where spectrum
efficiency is important or in consumer applications where available
bandwidth is fluctuating or limited. G.722.2 (AMR-wideband) has been adopte=
d
by the 3GPP as a wideband standard for mobile applications. G.722.2 is
relatively high cost due to patent royalties and is seeing minimal
deployments outside of mobile handsets making it challenging to create
wideband experiences on Internet-capable mobile devices when extending
beyond the mobile network. In other cases, proprietary codecs are being
adopted which further create islands with no interoperability unless
widespread transcoding is performed. Transcoding leads to higher costs and
lower quality.

The goal of this working group is to define a single codec with multiple
profiles which can be made available on a wide variety of Internet-capable
devices including low-power, mobile devices as well as devices capable of
utilizing high quality, high bitrate audio.

Proposed Deliverables:

1) Requirements for wideband, Internet audio codec(s).
2) Algorithm description for wideband, Internet audio codec(s) as Proposed
Standard.
3) Specification of payload format(s) for defined codecs as Proposed
Standard

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

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


--_000_C64417BD3D59hsinnreiadobecom_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [dispatch] Proposal to form Internet Wideband Audio Codec WG</TI=
TLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:=
18pt'>Roni,<BR>
<BR>
Sorry, we have here a fundamental disagreement.<BR>
The IETF is chartered for Internet standards and may or may not chose solut=
ions that apply to ITU-T networks.<BR>
The Internet has different criteria than ITU-T networks may have.<BR>
A worldwide Internet standard for a wideband codec will be very beneficial =
IMO.<BR>
<BR>
Henry<BR>
<BR>
<BR>
On 5/28/09 9:45 AM, &quot;Roni Even&quot; &lt;<a href=3D"ron.even.tlv@gmail=
.com">ron.even.tlv@gmail.com</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:18pt'>Hi,<BR>
Like you mention other SDOs like ITU-T are doing just that. They have the<B=
R>
expertise to specify, and evaluate the result. These SDOs can receive<BR>
requirements and select a proper codec based on the requirements.<BR>
<BR>
<BR>
As for the other reasons:<BR>
<BR>
1. Defining a codec in the IETF or even in MPEG / ITU-T does not make it a<=
BR>
mandatory part of a system solution, this is done by other standard bodies<=
BR>
like 3GPP, ETSI.<BR>
<BR>
2. The IETF, similar to other standard bodies is not rubber stamping a<BR>
specific solution, so you will most probably see in the final result some<B=
R>
technology that carry IPR.<BR>
<BR>
3. If this group will be established, you will probably see here the audio<=
BR>
experts now working in ITU-T arguing the same issues since they are the<BR>
expertise you need and they work for the same companies that are already<BR=
>
members of IETF.<BR>
<BR>
I think that if you have a specific codec in mind you &nbsp;can make it pub=
licly<BR>
available maybe with quality results and standardized in AVT a payload<BR>
specification.<BR>
<BR>
BTW: The ITU is keeping a list of codecs (Not only ITU-T ones) in a table<B=
R>
that describes their features.<BR>
<BR>
Regards<BR>
Roni Even<BR>
<BR>
-----Original Message-----<BR>
From: <a href=3D"dispatch-bounces@ietf.org">dispatch-bounces@ietf.org</a> [=
<a href=3D"mailto:dispatch-bounces@ietf.org">mailto:dispatch-bounces@ietf.o=
rg</a>] On Behalf<BR>
Of Jason Fischl<BR>
Sent: Wednesday, May 27, 2009 2:18 AM<BR>
To: <a href=3D"dispatch@ietf.org">dispatch@ietf.org</a><BR>
Subject: [dispatch] Proposal to form Internet Wideband Audio Codec WG<BR>
<BR>
All,<BR>
<BR>
I would like to request agenda time inside the DISPATCH meeting to propose<=
BR>
the formation of a new working group to define a Proposed Standard wideband=
<BR>
audio codec.<BR>
<BR>
The text of the proposal is below. Comments, questions, and suggestions<BR>
welcomed.<BR>
<BR>
Regards,<BR>
Jason<BR>
<BR>
<BR>
Internet Wideband Audio Codec (IWAC)<BR>
Mailing Lists: TBD<BR>
Chairs: TBD<BR>
Area Directorate: Real Time Applications (RAI)<BR>
<BR>
Purpose:<BR>
<BR>
This new working group would be chartered with the purpose of collecting<BR=
>
expertise within the IETF in order to review the design of audio codecs<BR>
specifically for use with the Internet. Unlike other SDOs, these codecs<BR>
would be optimized for use on the Internet, and as much as possible choose<=
BR>
technology that does not require paying patent royalties.<BR>
<BR>
The Internet Low Bit Rate Codec (iLBC) &nbsp;work was done in AVT but it wa=
s felt<BR>
that subsequent work should not be done in the AVT working group. This new<=
BR>
working group will have as its primary purpose the standardization of a<BR>
multi-purpose audio codec that can be used in various situations on the<BR>
Internet. Some of the proposed Internet-specific requirements include:<BR>
* scalable and adaptive bit rate;<BR>
* various sampling rate profiles from narrow-band to super-wideband;<BR>
* scalable complexity;<BR>
* low latency; and<BR>
* resilience to packet loss.<BR>
<BR>
There are a number of wide-band capable codecs defined by other SDOs. For<B=
R>
instance, G.722 is seeing adoption in Enterprise applications since it is<B=
R>
relatively simple and low-cost to deploy. However, it has a high, fixed<BR>
bitrate and is not appropriate for mobile applications where spectrum<BR>
efficiency is important or in consumer applications where available<BR>
bandwidth is fluctuating or limited. G.722.2 (AMR-wideband) has been adopte=
d<BR>
by the 3GPP as a wideband standard for mobile applications. G.722.2 is<BR>
relatively high cost due to patent royalties and is seeing minimal<BR>
deployments outside of mobile handsets making it challenging to create<BR>
wideband experiences on Internet-capable mobile devices when extending<BR>
beyond the mobile network. In other cases, proprietary codecs are being<BR>
adopted which further create islands with no interoperability unless<BR>
widespread transcoding is performed. Transcoding leads to higher costs and<=
BR>
lower quality.<BR>
<BR>
The goal of this working group is to define a single codec with multiple<BR=
>
profiles which can be made available on a wide variety of Internet-capable<=
BR>
devices including low-power, mobile devices as well as devices capable of<B=
R>
utilizing high quality, high bitrate audio.<BR>
<BR>
Proposed Deliverables:<BR>
<BR>
1) Requirements for wideband, Internet audio codec(s).<BR>
2) Algorithm description for wideband, Internet audio codec(s) as Proposed<=
BR>
Standard.<BR>
3) Specification of payload format(s) for defined codecs as Proposed<BR>
Standard<BR>
<BR>
_______________________________________________<BR>
dispatch mailing list<BR>
<a href=3D"dispatch@ietf.org">dispatch@ietf.org</a><BR>
<a href=3D"https://www.ietf.org/mailman/listinfo/dispatch">https://www.ietf=
.org/mailman/listinfo/dispatch</a><BR>
<BR>
_______________________________________________<BR>
dispatch mailing list<BR>
<a href=3D"dispatch@ietf.org">dispatch@ietf.org</a><BR>
<a href=3D"https://www.ietf.org/mailman/listinfo/dispatch">https://www.ietf=
.org/mailman/listinfo/dispatch</a><BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--_000_C64417BD3D59hsinnreiadobecom_--

From jason.fischl@skype.net  Thu May 28 18:35:40 2009
Return-Path: <jason.fischl@skype.net>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D4AD3A68E3 for <dispatch@core3.amsl.com>; Thu, 28 May 2009 18:35:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.532
X-Spam-Level: 
X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067]
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 iCrEDsxTWkL8 for <dispatch@core3.amsl.com>; Thu, 28 May 2009 18:35:39 -0700 (PDT)
Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) by core3.amsl.com (Postfix) with ESMTP id C19153A691E for <dispatch@ietf.org>; Thu, 28 May 2009 18:35:39 -0700 (PDT)
X-EBay-Corp: Yes
X-IronPort-AV: E=Sophos;i="4.41,268,1241420400"; d="scan'208";a="48946851"
Received: from den-exb-03.corp.ebay.com ([10.101.44.11]) by den-mipot-002.corp.ebay.com with ESMTP; 28 May 2009 18:37:22 -0700
Received: from DEN-EXM-04.corp.ebay.com ([10.241.16.37]) by DEN-EXB-03.corp.ebay.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 28 May 2009 19:37:22 -0600
Received: from 69.181.180.22 ([69.181.180.22]) by DEN-EXM-04.corp.ebay.com ([10.241.16.74]) via Exchange Front-End Server electron.corp.ebay.com ([10.101.112.24]) with Microsoft Exchange Server HTTP-DAV ; Fri, 29 May 2009 01:37:21 +0000
User-Agent: Microsoft-Entourage/12.17.0.090302
Date: Thu, 28 May 2009 18:37:21 -0700
From: Jason Fischl <jason.fischl@skype.net>
To: Eric Burger <eburger@standardstrack.com>
Message-ID: <C6448A61.D7D0%jason.fischl@skype.net>
Thread-Topic: [dispatch] Proposal to form Internet Wideband Audio Codec WG
Thread-Index: Acnf/gJMhI57HwDHakK1zQlZHDySfw==
In-Reply-To: <5B79A4F1-5AEE-48B0-9D8B-D6F1549A759D@standardstrack.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 29 May 2009 01:37:22.0487 (UTC) FILETIME=[032F0470:01C9DFFE]
Cc: dispatch@ietf.org
Subject: Re: [dispatch] Proposal to form Internet Wideband Audio Codec WG
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 May 2009 01:35:40 -0000

On 5/28/09 7:18 AM, "Eric Burger" <eburger@standardstrack.com> wrote:

> Smells to me either a binary situation:
> 
> Best Case: A bunch of people know exactly what they want and they just
> need to document it. Do it in AVT.
>
I think it is closer to this case. The issue with doing this in AVT is that
the expertise required to review an audio codec may be quite different from
what is available in AVT. If we do decide to do the work in AVT, we'll need
to update the charter as it explicitly forbids codec work.

>From AVT charter: 
>>> - to develop payload formats for new media codecs, and to document
>>> best-current practices in payload format design. The group
>>> continues to be precluded from work on codecs themselves because of
>>> overlap with the other standards bodies, and because the IETF does not
>>> have the ability to effectively review new codecs. An exception was
>>> made for the freeware iLBC codec on a highly experimental basis, but
>>> acceptance of new codec work is unexpected and subject to rechartering.

 
> Worst Case: We know what we need in terms of requirements, but we are
> not sure how to get there. Smells like a math problem. Do it in the
> IRTF.
>


From ingemar.s.johansson@ericsson.com  Fri May 29 00:16:16 2009
Return-Path: <ingemar.s.johansson@ericsson.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BC713A6A38 for <dispatch@core3.amsl.com>; Fri, 29 May 2009 00:16:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.8
X-Spam-Level: 
X-Spam-Status: No, score=-5.8 tagged_above=-999 required=5 tests=[AWL=0.449, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 rGTpOTHPbse1 for <dispatch@core3.amsl.com>; Fri, 29 May 2009 00:16:15 -0700 (PDT)
Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id DAB413A6B5B for <dispatch@ietf.org>; Fri, 29 May 2009 00:16:13 -0700 (PDT)
X-AuditID: c1b4fb3e-b7b78ae000007894-05-4a1f8c2438db
Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 9A.2F.30868.42C8F1A4; Fri, 29 May 2009 09:17:56 +0200 (CEST)
Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Fri, 29 May 2009 09:17:55 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
MIME-Version: 1.0
Content-Type: application/x-pkcs7-mime; smime-type=signed-data; name=smime.p7m; smime-type=signed-data; name="smime.p7m"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7m"
Content-class: urn:content-classes:message
Date: Fri, 29 May 2009 09:17:35 +0200
Message-ID: <130EBB38279E9847BAAAE0B8F9905F8C013693A1@esealmw109.eemea.ericsson.se>
In-Reply-To: <4A1E8A3E.4060908@telecomitalia.it>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: [dispatch] Yet another problem to dispatch
Thread-Index: Acnfk+ZnaytLovn8Rsmq9XAu76Wj4gAmPIbg
References: <mailman.65.1243450808.11110.dispatch@ietf.org> <130EBB38279E9847BAAAE0B8F9905F8C01336559@esealmw109.eemea.ericsson.se> <4A1E8A3E.4060908@telecomitalia.it>
From: "Ingemar Johansson S" <ingemar.s.johansson@ericsson.com>
To: "Enrico Marocco" <enrico.marocco@telecomitalia.it>
X-OriginalArrivalTime: 29 May 2009 07:17:55.0069 (UTC) FILETIME=[95F39AD0:01C9E02D]
X-Brightmail-Tracker: AAAAAA==
Cc: dispatch@ietf.org
Subject: Re: [dispatch] Yet another problem to dispatch
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 May 2009 07:16:16 -0000

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEggcPQ29u
dGVudC1UeXBlOiB0ZXh0L3BsYWluOw0KCWNoYXJzZXQ9InVzLWFzY2lpIg0KQ29udGVudC1UcmFu
c2Zlci1FbmNvZGluZzogN2JpdA0KDQpIaQ0KDQpTZWUgY29tbWVudHMgYmVsb3cgDQoNClJlZ2Fy
ZHMNCkluZ2VtYXINCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEVu
cmljbyBNYXJvY2NvIFttYWlsdG86ZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdF0gDQo+
IFNlbnQ6IGRlbiAyOCBtYWogMjAwOSAxNDo1OA0KPiBUbzogSW5nZW1hciBKb2hhbnNzb24gUw0K
PiBDYzogZGlzcGF0Y2hAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtkaXNwYXRjaF0gWWV0IGFu
b3RoZXIgcHJvYmxlbSB0byBkaXNwYXRjaA0KPiANCj4gSW5nZW1hciBKb2hhbnNzb24gUyB3cm90
ZToNCj4gPiBXaGVuIGl0IGNvbWVzIHRvIHRoZSB1c2Ugb2YgaGVhZGVyIGV4dGVuc2lvbnMgSSB3
b3VsZCANCj4gYmVsaWV2ZSB0aGF0IGl0IA0KPiA+IGlzIGJldHRlciB0byByZWZlcmVuY2UgdG8g
dGhlIGZyZXNobHkgYmFrZWQgUkZDNTI4NSB3aGljaCANCj4gZGVzY3JpYmVzIGEgDQo+ID4gZ2Vu
ZXJhbCBtZWNoYW5pc20gZm9yIHRoZSB1c2Ugb2YgaGVhZGVyIGV4dGVuc2lvbnMuDQo+IA0KPiBZ
ZXMsIGlmIHBlb3BsZSBhZ3JlZSB0aGF0IHN1Y2ggYSBwcm9ibGVtIHdpbGwgYmUgYmVzdCANCj4g
YWRkcmVzc2VkIHdpdGggYW4gUlRQIGV4dGVuc2lvbiwgNTI4NSBpcyBwcm9iYWJseSB0aGUgcmln
aHQgd2F5IHRvIGdvLg0KPiANCj4gPiBJIGRvbid0IGJlbGlldmUgdGhhdCBpbXBsZW1lbnRpbmcg
YW4gYWx0ZXJuYXRpdmUgDQo+IHVzZS9pbnRlcnByZXRhdGlvbiBvZiANCj4gPiB0aGUgQ1NSQyBs
aXN0IGlzIGEgZ29vZCBpZGVhLCBmaXJzdCBvZiBhbGwgSSBzdXNwZWN0IHRoYXQgaXQgd291bGQg
DQo+ID4gbGlrZWx5IGJlIHVuc3luY2hyb25pemVkIHdpdGggdGhlIHNwZWVjaCBzaWduYWwgYXMg
b25lIG5lZWQgDQo+IHRvIGF2ZXJhZ2UgDQo+ID4gdGhlIGFjdGl2aXR5IGZvciBlYWNoIGNvbnRy
aWJ1dG9yLiBBbHNvIHBhcnRpY2lwYW50cyBtYWtlcyANCj4gYWxsIGtpbmRzIA0KPiA+IG9mIG5v
aXNlIChiZXNpZGVzIHRhbGtpbmcpLCBvZnRlbiB2ZXJ5IHNob3J0IG5vaXNlIGJ1cnN0IA0KPiBi
dXQgdGhleSB3aWxsIA0KPiA+IHRyaWdnZXIgYW4gYWN0dml0eSBzaWduYWwgZm9yIGEgbG9uZ2Vy
IHRpbWUgdGhhbiB0aGUgYWN0dWFsIG5vaXNlIA0KPiA+IGJ1cnN0LCBsZWFkaW5nIHRvIHVucmVh
bGlzdGljbHkgaGlnaCBsZXZlbHMgZm9yIHRoZSBub2lzeSBwZXJzb25zLiANCj4gPiBGaW5hbGx5
LCBhcyB5b3UgcG9pbnQgb3V0IHRoZXJlIG1heSBiZSBzb21lIGludGVyb3AgaXNzdWVzLg0KPiAN
Cj4gSG1tLCBJJ20gbm90IHN1cmUgaWYgdGhhdCdzIHdoYXQgd291bGQgYWN0dWFsbHkgaGFwcGVu
LiBJZiBhIA0KPiBub2lzZSBidXJzdCByZWFjaGVkLCBzYXksIHZvbHVtZSBsZXZlbCA4IGZvciA0
MG1zLCB0aGF0IHdvdWxkIA0KPiBiZSBzaWduYWxlZCBvbmx5IGluIHR3byBSVFAgcGFja2V0cywg
cmVzdWx0aW5nIGluIHRoZSBjbGllbnQgDQo+IGRldGVjdGluZyBqdXN0IGEgbGV2ZWwtMiBzaWdu
YWwuDQoNClRoZSB3YXkgSSB1bmRlcnN0YW5kIGl0IHRoZXJlIHdpbGwgb25seSBiZSBhIDAlIG9y
IDEwMCUgaW5kaWNhdGlvbi4gU28gaWYNCm9uZSBDU1JDIGlzIGlubHVkZWQgaW4gMiBvdXQgb2Yg
MTAgcGFja2V0cyB0aGUgcmVzdWx0aW5nIGF2ZXJhZ2UgbGV2ZWwgd291bGQNCmJlIDIwJS4NCg0K
DQoNCj4gDQo+IC0tDQo+IENpYW8sDQo+IEVucmljbw0KPiANCgAAAAAAAKCCEGMwggNhMIICSaAD
AgECAhAKAQEBAAACfAAAAAoAAAACMA0GCSqGSIb3DQEBBQUAMDoxGTAXBgNVBAoTEFJTQSBTZWN1
cml0eSBJbmMxHTAbBgNVBAsTFFJTQSBTZWN1cml0eSAyMDQ4IFYzMB4XDTAxMDIyMjIwMzkyM1oX
DTI2MDIyMjIwMzkyM1owOjEZMBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNB
IFNlY3VyaXR5IDIwNDggVjMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC3j1Vx0oDd
e2l5p/AYUDI8Ymf2CpUH3eYb857Z0kFUa62ffL4ZzftGq0FoHhjqVcgvkXiJKPsnKWD/34+MO8lJ
m7WklM4B6j61Y3t/Jv0Z3cAhvYTRLU9Gw07c2Dc5Oyivy50a6iuvIaXBIyK4uBtaE4dXg9HwIOfo
TyNCsAClfYnp6WFzlJhxJrwtauD3TfDxtio4MYENKeEAwVEPTFL4BFqqfXLTuIcqu2MQAyqzoU8N
Wl5Gtz0O9XTsmZ/5PSSBiKbdYFTolTY9xgmTmqMSgABVmRlHvdClfMO6+x/39Q/4rLm19DeYExje
hVu3DII7h2+VOVgw2m4BaBcizMALAgMBAAGjYzBhMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/
BAQDAgEGMB8GA1UdIwQYMBaAFAfDUTCkqulFrjUk+v8kLDPQsZ2MMB0GA1UdDgQWBBQHw1EwpKrp
Ra41JPr/JCwz0LGdjDANBgkqhkiG9w0BAQUFAAOCAQEAXz6Gdm64NTxONhweeZi//dUSEXlSDu4x
ibzdf/nRxhUh6IoBVA06+1S51mPUsaqWTaJCTdRTH4sQ3n9lvmATJ3GIpHPjhGPRpFXhUJPmGw55
0Ge8Rsi/PxcNlebGkGne57Qv3pV90BI/PT5/TT8UaPURUNXB9JClCB0xYP9gjCNUCq/+oW7F0Xoq
aHjPHoIKILQfreWFsmpodU6tJTeUhb69odTqtwxLPJ3oEgDwX6wN4axwY3P3f3mfMiVCdAWAKL+9
wSSWWBWxFyHpiUvbB4hn9BWtcD4vTYU7wrfb/phoI4nhdA/e9MWEYykbzMsHyQCkqdfCIk9n13fs
IAVh3jCCBEAwggMooAMCAQICEQCESG4JedyxTX2VeCytmEY8MA0GCSqGSIb3DQEBBQUAMDkxETAP
BgNVBAoMCEVyaWNzc29uMSQwIgYDVQQDDBtFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBMDEwHhcN
MDgwNDAyMTIyMzIzWhcNMTEwNDAyMTIyMzIwWjByMREwDwYDVQQKDAhFcmljc3NvbjEaMBgGA1UE
AwwRSW5nZW1hciBKb2hhbnNzb24xEDAOBgNVBAUTB2VwbGlqb2gxLzAtBgkqhkiG9w0BCQEWIGlu
Z2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
gQDVt8PSIhyWtR8WWIFyCn2+czyaeHcEErfJ8vtMZODl7qqOxB73W5PoQ8HccT0YRIlfrUvrjpbp
nwNnEihugS01q2n2GHrEhaxbrHXgcGP+aQyMigxwSjLJLgbvyEpne2E6vnTMA+5jAxVqlRl4sjVb
QMu1sTIIjzW50FX6HSjn6wIDAQABo4IBjDCCAYgwgcAGA1UdHwSBuDCBtTCBsqCBr6CBrIY3aHR0
cDovL2NybC50cnVzdC50ZWxpYS5jb20vRXJpY3Nzb25OTEluZGl2aWR1YWxDQTAxLmNybIZxbGRh
cDovL2xkYXAudHJ1c3QudGVsaWEuY29tL2NuPUVyaWNzc29uJTIwTkwlMjBJbmRpdmlkdWFsJTIw
Q0EwMSxvPUVyaWNzc29uP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2UwKwYD
VR0RBCQwIoEgaW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYq
hXBrAQEwMTAvBggrBgEFBQcCARYjaHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWww
HQYDVR0OBBYEFIwLUdM0ukIKAllxyxcKTsWjp1RwMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVF
sXZfYzCbMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQUFAAOCAQEAaatzFILvWlh/I1wnb2Yu
vCPOAQ2EAxMsZPmfhEZvkWTRlwHUX2X16o268S0Ii/dq5O81AujwyfRx4KmKIj1FqnLroKVHVXtM
ivBFZBy/HDu6C+KvhOtIIo5mGCdlcKBvckEXXu4rFoQ5PcBPtEICk3yqjcjDxcXfDJblQkrkZdf/
31CoZBuGM6hMVarlPNrWjClY516i0qpgtxLA9VR3Sg/god4CvUm9hYVhL3xiKhIO4u1iU1jUWtiS
64YeGSaLImozqBATwY5dCpEVK53Jth49x+D7tcKxXwWlcXApORmZrSZyj8TYH7RepvLPAt0RNmAl
gusXWBlVGv2pGrSn2jCCBEUwggMtoAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEF
BQAwRDEaMBgGA1UECgwRVGVsaWFTb25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1
YmxpYyBSb290IENBIHYxMB4XDTA2MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UE
CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4
QYFe1HACqavqNLwUGIqIEyHv1rLnfub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl
84Sc+Fx09IrDU/SZSWFSfhqTu3TT39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzG
LSYWgt6/tpwuOH5lcfNfHWMcCYXRlobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0e
XPujKT7tU5xxSI2SdceJqzUbAz2oFRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEA
AaOCATwwggE4MBIGA1UdEwEB/wQIMAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYI
KwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/
MH2ge6B5hndsZGFwOi8vbGRhcC50cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJs
aWMlMjBSb290JTIwQ0ElMjB2MSxvPVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2Nh
dGlvbmxpc3Q/YmFzZTAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZf
YzCbMB8GA1UdIwQYMBaAFEXb8I+4GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2
AEoqQz+M3Ra9alkpn/YnwhXIv6tPjhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x
/GK3in/mik8i/PK2/q8HutzYFSzz6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/he
wS8s6dFFn70w795xUwJBWZ67OzIKXrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk
+xQbgehCEi7mu3cXsaU1Xq3kMXuiNuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy
2iXGKjdlxlWTsdDyulXYz+OYCMZ9lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuG
Wj0wDQYJKoZIhvcNAQEFBQAwOjEZMBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMU
UlNBIFNlY3VyaXR5IDIwNDggVjMwHhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRow
GAYDVQQKDBFUZWxpYVNvbmVyYSBHcm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJv
b3QgQ0EgdjEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt
+WZe5QKGnaVEQSyY7lICKF5DuVdWPMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5Nck
dBWPWp/T2uaQdOAwgqHpN0pe1X7/jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgoox
KnCS+ZjB5icWAg+Qd1QpQhF46H1ibp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBo
pzQBj6s5SyVh8A+j5liDBjghXYpw/+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhME
mytMNbGicR1mRH6tAgMBAAGjggFiMIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGd
jDAdBgNVHQ4EFgQURdvwj7gaYqGoIxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYD
VR0gBH4wfDA9BgkqhkiG9w0FBgEwMDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRy
dXN0LnRlbGlhLmNvbTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9y
eS50cnVzdC50ZWxpYS5jb20wcAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0
eS5jb20vcHJvZHVjdHMva2Vvbi9yZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2Vj
dXJpdHlfMjA0OF92My5DUkwwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos
2CnIm7/872ytSrEHWZgvhOUEkUm25PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6
K7hidWBDOm46bNdM3ZwhMyDCfkDJSgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW
6r73coraDP8diOpiQouMvM6bKuTPBH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Ln
e2oT0JI3pwdA2v6jO4p/OLHntP+npjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg
1JRIliSphrqr9kbfwHdeVxPdOI5GtDYPMYICfjCCAnoCAQEwTjA5MREwDwYDVQQKDAhFcmljc3Nv
bjEkMCIGA1UEAwwbRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQTAxAhEAhEhuCXncsU19lXgsrZhG
PDAJBgUrDgMCGgUAoIIBhjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wOTA1MjkwNzE3MzVaMCMGCSqGSIb3DQEJBDEWBBTQm+rd6YT7bo6UFTbNX6thUrwkLDBdBgkr
BgEEAYI3EAQxUDBOMDkxETAPBgNVBAoMCEVyaWNzc29uMSQwIgYDVQQDDBtFcmljc3NvbiBOTCBJ
bmRpdmlkdWFsIENBMDECEQCESG4JedyxTX2VeCytmEY8MF8GCyqGSIb3DQEJEAILMVCgTjA5MREw
DwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQTAxAhEA
hEhuCXncsU19lXgsrZhGPDBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMC
AgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggq
hkiG9w0CBTANBgkqhkiG9w0BAQEFAASBgFPEh2glRX3ymkN8+jR59gJXNQ7vDh5lXDtwoAOFoFK9
7puqetOpt7WVn7lBipGA7g7RAkVIWQOd7uz2wEDkPGh9j/LrgAXy3rlFGlOchWhvYczJW5DsYC1w
j+3SX8wQm/N4duIzhJJ9Zc9Y2spNF/tcjEL+YQ1okzfc1L6Y/9vdAAAAAAAA

From enrico.marocco@telecomitalia.it  Fri May 29 00:32:52 2009
Return-Path: <enrico.marocco@telecomitalia.it>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75A993A68C3 for <dispatch@core3.amsl.com>; Fri, 29 May 2009 00:32:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.546
X-Spam-Level: 
X-Spam-Status: No, score=-0.546 tagged_above=-999 required=5 tests=[AWL=0.173,  BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
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 l9Q4M6En9mY7 for <dispatch@core3.amsl.com>; Fri, 29 May 2009 00:32:51 -0700 (PDT)
Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by core3.amsl.com (Postfix) with ESMTP id 5C0553A6E3A for <dispatch@ietf.org>; Fri, 29 May 2009 00:30:52 -0700 (PDT)
Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.1.340.0; Fri, 29 May 2009 09:32:34 +0200
Received: from [10.229.8.41] (10.229.8.41) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.1.359.3; Fri, 29 May 2009 09:32:33 +0200
Message-ID: <4A1F8F95.4000609@telecomitalia.it>
Date: Fri, 29 May 2009 09:32:37 +0200
From: Enrico Marocco <enrico.marocco@telecomitalia.it>
User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103)
MIME-Version: 1.0
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
References: <mailman.65.1243450808.11110.dispatch@ietf.org> <130EBB38279E9847BAAAE0B8F9905F8C01336559@esealmw109.eemea.ericsson.se> <4A1E8A3E.4060908@telecomitalia.it> <130EBB38279E9847BAAAE0B8F9905F8C013693A1@esealmw109.eemea.ericsson.se>
In-Reply-To: <130EBB38279E9847BAAAE0B8F9905F8C013693A1@esealmw109.eemea.ericsson.se>
X-Enigmail-Version: 0.95.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050204030203090902060104"
Cc: "dispatch@ietf.org" <dispatch@ietf.org>
Subject: Re: [dispatch] Yet another problem to dispatch
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 May 2009 07:32:52 -0000

--------------ms050204030203090902060104
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Ingemar Johansson S wrote:
>> Hmm, I'm not sure if that's what would actually happen. If a 
>> noise burst reached, say, volume level 8 for 40ms, that would 
>> be signaled only in two RTP packets, resulting in the client 
>> detecting just a level-2 signal.
> 
> The way I understand it there will only be a 0% or 100% indication. So if
> one CSRC is inluded in 2 out of 10 packets the resulting average level would
> be 20%.

Correct. IOW, the problem with very short noise bursts is that their
representation in the UI would be smoothed, but they would not cause a
longer activity signal.

-- 
Ciao,
Enrico

--------------ms050204030203090902060104
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJwTCC
AzswggKkoAMCAQICEEIEYmjMZBX3Us1Th/pMjJYwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDMxNjE3NTMwMloX
DTEwMDMxNjE3NTMwMlowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEuMCwG
CSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEnMCUGCSqGSIb3
DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A
MIIBCgKCAQEAvd38YWuquonbz4lP4GKp0qij0v4MgXpK/BW87GvoqHz3iQvO1Tb6f4yEtFel
vpK2drtUHWyY+ww6QQSOGJvSWEKTRVX5KsXpN2yNeY4kceezCjsXBvwNPlGHrzJifUByvwzD
QSnQLocE1i89x7P2T5brcaGBBgricwQL1Cggg97zp1yGrj2VIJE03GSpEL01d+omAFUou3mx
8R/9XOnGnSlDpcOV6s2Ww3NN07+7sSBaE0vcvlYF8pr1BWDl2JJobG9qpC9DlplpDZOdmsAG
u/qwsI0AsucY5ZBFKqzKizQ5PGhrh3u2PHRGNncuHUANF0cPfVs7AHjHjudH7PzU2wIDAQAB
o1YwVDBEBgNVHREEPTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJp
Y28ubWFyb2Njb0BnbWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQB3
Mi6SymgE1cfsbmr5LWvWVdO58/a0O95kXL2puRn9kGjFN1tAzHQc/UxJs0gIyRRs3gGBR+p6
TT1gmnucO8Ji0gJBMBL+ogcfyaV30hZtUceiRevemXvZW2QOCLdYUf6KdB6ccX7r3a58SRRL
l5YTZ7bIhyAEmeI60ioyMI8U5jCCAzswggKkoAMCAQICEEIEYmjMZBX3Us1Th/pMjJYwDQYJ
KoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n
IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n
IENBMB4XDTA5MDMxNjE3NTMwMloXDTEwMDMxNjE3NTMwMlowejEfMB0GA1UEAxMWVGhhd3Rl
IEZyZWVtYWlsIE1lbWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNv
bWl0YWxpYS5pdDEnMCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIB
IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvd38YWuquonbz4lP4GKp0qij0v4MgXpK
/BW87GvoqHz3iQvO1Tb6f4yEtFelvpK2drtUHWyY+ww6QQSOGJvSWEKTRVX5KsXpN2yNeY4k
ceezCjsXBvwNPlGHrzJifUByvwzDQSnQLocE1i89x7P2T5brcaGBBgricwQL1Cggg97zp1yG
rj2VIJE03GSpEL01d+omAFUou3mx8R/9XOnGnSlDpcOV6s2Ww3NN07+7sSBaE0vcvlYF8pr1
BWDl2JJobG9qpC9DlplpDZOdmsAGu/qwsI0AsucY5ZBFKqzKizQ5PGhrh3u2PHRGNncuHUAN
F0cPfVs7AHjHjudH7PzU2wIDAQABo1YwVDBEBgNVHREEPTA7gR9lbnJpY28ubWFyb2Njb0B0
ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0BnbWFpbC5jb20wDAYDVR0TAQH/BAIw
ADANBgkqhkiG9w0BAQUFAAOBgQB3Mi6SymgE1cfsbmr5LWvWVdO58/a0O95kXL2puRn9kGjF
N1tAzHQc/UxJs0gIyRRs3gGBR+p6TT1gmnucO8Ji0gJBMBL+ogcfyaV30hZtUceiRevemXvZ
W2QOCLdYUf6KdB6ccX7r3a58SRRLl5YTZ7bIhyAEmeI60ioyMI8U5jCCAz8wggKooAMCAQIC
AQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh
cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAm
BgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0
ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h
aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV
BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQD
EyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEF
AAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B
1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79A
gAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E
CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3
dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEa
MBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7M
DaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa
C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk1
3iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3
dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl
ZW1haWwgSXNzdWluZyBDQQIQQgRiaMxkFfdSzVOH+kyMljAJBgUrDgMCGgUAoIIB0DAYBgkq
hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA1MjkwNzMyMzdaMCMG
CSqGSIb3DQEJBDEWBBS/Z1SU1mj2rGO8k1CqNBtUEWDm9jBfBgkqhkiG9w0BCQ8xUjBQMAsG
CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw
BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC
WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro
YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBCBGJozGQV91LNU4f6TIyWMIGH
BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z
dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ
c3N1aW5nIENBAhBCBGJozGQV91LNU4f6TIyWMA0GCSqGSIb3DQEBAQUABIIBAK0PodFMqxbC
1EpAxFQAaYE/7cMfRCsLOF7OQIJCjKUjx592bfL3Aei9meJedGcnRxlWYMpivzmAy5lL/ugI
DnKDsk4f1mpMOzO2b5ChhqaIgJ3lKjteK2xrVFFoPdrb5g9Vtr/+lZ65Nkcb4zpybOHTdKL1
7mDd1PydFuePQx4AXpLoaK3pUzZPjwg+XfbhkMby75CE8aDeyrmXjCCyq7P4Pr/evWjZHggE
ZhpBmZLYDZ1sHJMbOfQteiyVvqoO9MUEZGX7B2gG08EqaEbnTy2+8HGqk5czJmchdSfYwrxA
eeG8CFkXFbHHGhhpt7J2sz/MJ1HTmSSUsYgBme1Aw6MAAAAAAAA=
--------------ms050204030203090902060104--

From ron.even.tlv@gmail.com  Fri May 29 00:55:25 2009
Return-Path: <ron.even.tlv@gmail.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 422813A67BD for <dispatch@core3.amsl.com>; Fri, 29 May 2009 00:55:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.513
X-Spam-Level: 
X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086,  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 GI1UUBsq4UJH for <dispatch@core3.amsl.com>; Fri, 29 May 2009 00:55:24 -0700 (PDT)
Received: from mail-bw0-f222.google.com (mail-bw0-f222.google.com [209.85.218.222]) by core3.amsl.com (Postfix) with ESMTP id CE5213A6E63 for <dispatch@ietf.org>; Fri, 29 May 2009 00:55:23 -0700 (PDT)
Received: by bwz22 with SMTP id 22so5951144bwz.37 for <dispatch@ietf.org>; Fri, 29 May 2009 00:57:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=Exfm+9aTnDrrZP9+jHvxaboFrMikDsMPyKuTDYNGK9c=; b=jC8qAwRnsFDRzYy7cJiotEDUys5x32/fAG4zP3Bznqj5vSwLl1AAeeSE++/2iP3gOn L4SFqoSLL930NHCSD9kou+d78t23uKhzLAPaMU5/HbfsCrVmPqzE8H2slEKzkAoK3gpQ 9ozfqn5mD4nDL67u53img/UNhZGpJ41C3fNEc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; b=hSENGJez/niiQ9KseQqm1vSOdwK9a94gvW/Tfh0Kj6SGWxbSqx3Fim6DTlhxLYjusO 8SAQT5Mqm4i1SmS31f6OyDf3f49f6qnt3OUtUaMW17masiDAqbv/ZrsRK6USGAadTyZq 3VyUUCxwpcJRBERBgNbHhmi1aaSKJVnoZM+nQ=
Received: by 10.103.189.18 with SMTP id r18mr1383688mup.80.1243583823939; Fri, 29 May 2009 00:57:03 -0700 (PDT)
Received: from windows8d787f9 (bzq-79-181-138-75.red.bezeqint.net [79.181.138.75]) by mx.google.com with ESMTPS id j2sm2715612mue.12.2009.05.29.00.57.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 29 May 2009 00:57:03 -0700 (PDT)
From: "Roni Even" <ron.even.tlv@gmail.com>
To: "'Jason Fischl'" <jason.fischl@skype.net>, <dispatch@ietf.org>
References: <C641C6CE.D74E%jason.fischl@skype.net>
In-Reply-To: <C641C6CE.D74E%jason.fischl@skype.net>
Date: Fri, 29 May 2009 10:56:18 +0300
Message-ID: <4a1f954f.02a1660a.0c5a.115d@mx.google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcneWEMKfMLxcIB/zk+aK3yDPFDcEwB2Du1g
Content-Language: en-us
Subject: Re: [dispatch] Proposal to form Internet Wideband Audio Codec WG
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 May 2009 07:55:25 -0000

Hi,
A small correction.
iLBC work was not done in AVT it was done by Global IP Sound. The AVT just
published a specification of the codec as an experimental RFC. I want to
assume that you are not proposing such a method to define a codec but want
an open for all way to contribute to a codec based on approved requirements

I also have a suggestion to send a liaison to ITU-T SG16 asking for the
comparison table they have on all codecs (we can add the ones that are
missing if there are) in order not to create a yet another same codec.

Roni Even



-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf
Of Jason Fischl
Sent: Wednesday, May 27, 2009 2:18 AM
To: dispatch@ietf.org
Subject: [dispatch] Proposal to form Internet Wideband Audio Codec WG

All,

I would like to request agenda time inside the DISPATCH meeting to propose
the formation of a new working group to define a Proposed Standard wideband
audio codec.

The text of the proposal is below. Comments, questions, and suggestions
welcomed.

Regards, 
Jason


Internet Wideband Audio Codec (IWAC)
Mailing Lists: TBD
Chairs: TBD
Area Directorate: Real Time Applications (RAI)

Purpose:

This new working group would be chartered with the purpose of collecting
expertise within the IETF in order to review the design of audio codecs
specifically for use with the Internet. Unlike other SDOs, these codecs
would be optimized for use on the Internet, and as much as possible choose
technology that does not require paying patent royalties.

The Internet Low Bit Rate Codec (iLBC)  work was done in AVT but it was felt
that subsequent work should not be done in the AVT working group. This new
working group will have as its primary purpose the standardization of a
multi-purpose audio codec that can be used in various situations on the
Internet. Some of the proposed Internet-specific requirements include:
* scalable and adaptive bit rate;
* various sampling rate profiles from narrow-band to super-wideband;
* scalable complexity;
* low latency; and 
* resilience to packet loss.

There are a number of wide-band capable codecs defined by other SDOs. For
instance, G.722 is seeing adoption in Enterprise applications since it is
relatively simple and low-cost to deploy. However, it has a high, fixed
bitrate and is not appropriate for mobile applications where spectrum
efficiency is important or in consumer applications where available
bandwidth is fluctuating or limited. G.722.2 (AMR-wideband) has been adopted
by the 3GPP as a wideband standard for mobile applications. G.722.2 is
relatively high cost due to patent royalties and is seeing minimal
deployments outside of mobile handsets making it challenging to create
wideband experiences on Internet-capable mobile devices when extending
beyond the mobile network. In other cases, proprietary codecs are being
adopted which further create islands with no interoperability unless
widespread transcoding is performed. Transcoding leads to higher costs and
lower quality. 

The goal of this working group is to define a single codec with multiple
profiles which can be made available on a wide variety of Internet-capable
devices including low-power, mobile devices as well as devices capable of
utilizing high quality, high bitrate audio.

Proposed Deliverables:

1) Requirements for wideband, Internet audio codec(s).
2) Algorithm description for wideband, Internet audio codec(s) as Proposed
Standard. 
3) Specification of payload format(s) for defined codecs as Proposed
Standard

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


From spencer@wonderhamster.org  Fri May 29 07:56:49 2009
Return-Path: <spencer@wonderhamster.org>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2598D3A6C77 for <dispatch@core3.amsl.com>; Fri, 29 May 2009 07:56:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.126
X-Spam-Level: 
X-Spam-Status: No, score=-2.126 tagged_above=-999 required=5 tests=[AWL=0.472,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 B86BocCNoMYe for <dispatch@core3.amsl.com>; Fri, 29 May 2009 07:56:47 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id C0B1B3A6F20 for <dispatch@ietf.org>; Fri, 29 May 2009 07:56:14 -0700 (PDT)
Received: from S73602b (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1MA3Vl0KK7-000fke; Fri, 29 May 2009 10:56:50 -0400
Message-ID: <8DA8EBE683E74919A662C925A153F1CD@china.huawei.com>
From: "Spencer Dawkins" <spencer@wonderhamster.org>
To: "Henry Sinnreich" <hsinnrei@adobe.com>, "Roni Even" <ron.even.tlv@gmail.com>, "Jason Fischl" <jason.fischl@skype.net>, <dispatch@ietf.org>
References: <C64417BD.3D59%hsinnrei@adobe.com>
Date: Fri, 29 May 2009 09:56:35 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_2C73_01C9E043.C0DBF100"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5512
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-Provags-ID: V01U2FsdGVkX19WIeCfEohS/B2yszgKAS98x/khR/0Hni0aTdJ qFVy4FwHzX3zHg6h6z1d104unnbXsSijo9foQ3sMtHH1NHdxOy y2pRqL9GHixivvWbmSuz09SS8jkzltQSBxxRQQsQqs=
Subject: Re: [dispatch] Proposal to form Internet Wideband Audio Codec WG
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 May 2009 14:56:49 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_2C73_01C9E043.C0DBF100
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Re: [dispatch] Proposal to form Internet Wideband Audio Codec WGHi, =
Henry,

I may have misunderstood Roni's point, but I thought that he was saying =
that audio codec types don't participate in the IETF today, because the =
IETF does not develop audio codecs (and AVT is prohibited by charter =
from producing one, because of a stated belief that we don't have the =
expertise in the IETF to do this work).

Thanks,

Spencer
  ----- Original Message -----=20
  From: Henry Sinnreich=20
  To: Roni Even ; Jason Fischl ; dispatch@ietf.org=20
  Sent: Thursday, May 28, 2009 10:28 AM
  Subject: Re: [dispatch] Proposal to form Internet Wideband Audio Codec =
WG


  Roni,

  Sorry, we have here a fundamental disagreement.
  The IETF is chartered for Internet standards and may or may not chose =
solutions that apply to ITU-T networks.
  The Internet has different criteria than ITU-T networks may have.
  A worldwide Internet standard for a wideband codec will be very =
beneficial IMO.

  Henry


  On 5/28/09 9:45 AM, "Roni Even" <ron.even.tlv@gmail.com> wrote:


    Hi,
    Like you mention other SDOs like ITU-T are doing just that. They =
have the
    expertise to specify, and evaluate the result. These SDOs can =
receive
    requirements and select a proper codec based on the requirements.


    As for the other reasons:

    1. Defining a codec in the IETF or even in MPEG / ITU-T does not =
make it a
    mandatory part of a system solution, this is done by other standard =
bodies
    like 3GPP, ETSI.

    2. The IETF, similar to other standard bodies is not rubber stamping =
a
    specific solution, so you will most probably see in the final result =
some
    technology that carry IPR.

    3. If this group will be established, you will probably see here the =
audio
    experts now working in ITU-T arguing the same issues since they are =
the
    expertise you need and they work for the same companies that are =
already
    members of IETF.

    I think that if you have a specific codec in mind you  can make it =
publicly
    available maybe with quality results and standardized in AVT a =
payload
    specification.

    BTW: The ITU is keeping a list of codecs (Not only ITU-T ones) in a =
table
    that describes their features.

    Regards
    Roni Even

    -----Original Message-----
    From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] =
On Behalf
    Of Jason Fischl
    Sent: Wednesday, May 27, 2009 2:18 AM
    To: dispatch@ietf.org
    Subject: [dispatch] Proposal to form Internet Wideband Audio Codec =
WG

    All,

    I would like to request agenda time inside the DISPATCH meeting to =
propose
    the formation of a new working group to define a Proposed Standard =
wideband
    audio codec.

    The text of the proposal is below. Comments, questions, and =
suggestions
    welcomed.

    Regards,
    Jason


    Internet Wideband Audio Codec (IWAC)
    Mailing Lists: TBD
    Chairs: TBD
    Area Directorate: Real Time Applications (RAI)

    Purpose:

    This new working group would be chartered with the purpose of =
collecting
    expertise within the IETF in order to review the design of audio =
codecs
    specifically for use with the Internet. Unlike other SDOs, these =
codecs
    would be optimized for use on the Internet, and as much as possible =
choose
    technology that does not require paying patent royalties.

    The Internet Low Bit Rate Codec (iLBC)  work was done in AVT but it =
was felt
    that subsequent work should not be done in the AVT working group. =
This new
    working group will have as its primary purpose the standardization =
of a
    multi-purpose audio codec that can be used in various situations on =
the
    Internet. Some of the proposed Internet-specific requirements =
include:
    * scalable and adaptive bit rate;
    * various sampling rate profiles from narrow-band to super-wideband;
    * scalable complexity;
    * low latency; and
    * resilience to packet loss.

    There are a number of wide-band capable codecs defined by other =
SDOs. For
    instance, G.722 is seeing adoption in Enterprise applications since =
it is
    relatively simple and low-cost to deploy. However, it has a high, =
fixed
    bitrate and is not appropriate for mobile applications where =
spectrum
    efficiency is important or in consumer applications where available
    bandwidth is fluctuating or limited. G.722.2 (AMR-wideband) has been =
adopted
    by the 3GPP as a wideband standard for mobile applications. G.722.2 =
is
    relatively high cost due to patent royalties and is seeing minimal
    deployments outside of mobile handsets making it challenging to =
create
    wideband experiences on Internet-capable mobile devices when =
extending
    beyond the mobile network. In other cases, proprietary codecs are =
being
    adopted which further create islands with no interoperability unless
    widespread transcoding is performed. Transcoding leads to higher =
costs and
    lower quality.

    The goal of this working group is to define a single codec with =
multiple
    profiles which can be made available on a wide variety of =
Internet-capable
    devices including low-power, mobile devices as well as devices =
capable of
    utilizing high quality, high bitrate audio.

    Proposed Deliverables:

    1) Requirements for wideband, Internet audio codec(s).
    2) Algorithm description for wideband, Internet audio codec(s) as =
Proposed
    Standard.
    3) Specification of payload format(s) for defined codecs as Proposed
    Standard

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

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




-------------------------------------------------------------------------=
-----


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

------=_NextPart_000_2C73_01C9E043.C0DBF100
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Re: [dispatch] Proposal to form Internet Wideband =
Audio Codec WG</TITLE>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META name=3DGENERATOR content=3D"MSHTML 8.00.6001.18702">
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>Hi, Henry,</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>I may have misunderstood Roni's point, but I thought =
that he=20
was saying that audio codec types don't participate in the IETF today, =
because=20
the IETF does not develop audio codecs (and AVT is prohibited by charter =
from=20
producing one, because of a stated belief that we don't have the =
expertise in=20
the IETF to do this work).</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Thanks,</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Spencer</FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; PADDING-LEFT: 5px; =
PADDING-RIGHT: 0px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"FONT: 10pt arial; BACKGROUND: #e4e4e4; font-color: =
black"><B>From:</B>=20
  <A title=3Dhsinnrei@adobe.com href=3D"mailto:hsinnrei@adobe.com">Henry =

  Sinnreich</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=3Dron.even.tlv@gmail.com=20
  href=3D"mailto:ron.even.tlv@gmail.com">Roni Even</A> ; <A=20
  title=3Djason.fischl@skype.net =
href=3D"mailto:jason.fischl@skype.net">Jason=20
  Fischl</A> ; <A title=3Ddispatch@ietf.org=20
  href=3D"mailto:dispatch@ietf.org">dispatch@ietf.org</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Thursday, May 28, 2009 =
10:28=20
  AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: [dispatch] =
Proposal to form=20
  Internet Wideband Audio Codec WG</DIV>
  <DIV><BR></DIV><FONT face=3D"Calibri, Verdana, Helvetica, Arial"><SPAN =

  style=3D"FONT-SIZE: 18pt">Roni,<BR><BR>Sorry, we have here a =
fundamental=20
  disagreement.<BR>The IETF is chartered for Internet standards and may =
or may=20
  not chose solutions that apply to ITU-T networks.<BR>The Internet has=20
  different criteria than ITU-T networks may have.<BR>A worldwide =
Internet=20
  standard for a wideband codec will be very beneficial=20
  IMO.<BR><BR>Henry<BR><BR><BR>On 5/28/09 9:45 AM, "Roni Even" &lt;<A=20
  href=3D"mailto:ron.even.tlv@gmail.com">ron.even.tlv@gmail.com</A>&gt;=20
  wrote:<BR><BR></SPAN></FONT>
  <BLOCKQUOTE><FONT face=3D"Calibri, Verdana, Helvetica, Arial"><SPAN=20
    style=3D"FONT-SIZE: 18pt">Hi,<BR>Like you mention other SDOs like =
ITU-T are=20
    doing just that. They have the<BR>expertise to specify, and evaluate =
the=20
    result. These SDOs can receive<BR>requirements and select a proper =
codec=20
    based on the requirements.<BR><BR><BR>As for the other =
reasons:<BR><BR>1.=20
    Defining a codec in the IETF or even in MPEG / ITU-T does not make =
it=20
    a<BR>mandatory part of a system solution, this is done by other =
standard=20
    bodies<BR>like 3GPP, ETSI.<BR><BR>2. The IETF, similar to other =
standard=20
    bodies is not rubber stamping a<BR>specific solution, so you will =
most=20
    probably see in the final result some<BR>technology that carry=20
    IPR.<BR><BR>3. If this group will be established, you will probably =
see here=20
    the audio<BR>experts now working in ITU-T arguing the same issues =
since they=20
    are the<BR>expertise you need and they work for the same companies =
that are=20
    already<BR>members of IETF.<BR><BR>I think that if you have a =
specific codec=20
    in mind you &nbsp;can make it publicly<BR>available maybe with =
quality=20
    results and standardized in AVT a =
payload<BR>specification.<BR><BR>BTW: The=20
    ITU is keeping a list of codecs (Not only ITU-T ones) in a =
table<BR>that=20
    describes their features.<BR><BR>Regards<BR>Roni =
Even<BR><BR>-----Original=20
    Message-----<BR>From: <A=20
    href=3D"dispatch-bounces@ietf.org">dispatch-bounces@ietf.org</A> [<A =

    =
href=3D"mailto:dispatch-bounces@ietf.org">mailto:dispatch-bounces@ietf.or=
g</A>]=20
    On Behalf<BR>Of Jason Fischl<BR>Sent: Wednesday, May 27, 2009 2:18 =
AM<BR>To:=20
    <A href=3D"dispatch@ietf.org">dispatch@ietf.org</A><BR>Subject: =
[dispatch]=20
    Proposal to form Internet Wideband Audio Codec =
WG<BR><BR>All,<BR><BR>I would=20
    like to request agenda time inside the DISPATCH meeting to =
propose<BR>the=20
    formation of a new working group to define a Proposed Standard=20
    wideband<BR>audio codec.<BR><BR>The text of the proposal is below. =
Comments,=20
    questions, and=20
    =
suggestions<BR>welcomed.<BR><BR>Regards,<BR>Jason<BR><BR><BR>Internet=20
    Wideband Audio Codec (IWAC)<BR>Mailing Lists: TBD<BR>Chairs: =
TBD<BR>Area=20
    Directorate: Real Time Applications =
(RAI)<BR><BR>Purpose:<BR><BR>This new=20
    working group would be chartered with the purpose of =
collecting<BR>expertise=20
    within the IETF in order to review the design of audio=20
    codecs<BR>specifically for use with the Internet. Unlike other SDOs, =
these=20
    codecs<BR>would be optimized for use on the Internet, and as much as =

    possible choose<BR>technology that does not require paying patent=20
    royalties.<BR><BR>The Internet Low Bit Rate Codec (iLBC) &nbsp;work =
was done=20
    in AVT but it was felt<BR>that subsequent work should not be done in =
the AVT=20
    working group. This new<BR>working group will have as its primary =
purpose=20
    the standardization of a<BR>multi-purpose audio codec that can be =
used in=20
    various situations on the<BR>Internet. Some of the proposed=20
    Internet-specific requirements include:<BR>* scalable and adaptive =
bit=20
    rate;<BR>* various sampling rate profiles from narrow-band to=20
    super-wideband;<BR>* scalable complexity;<BR>* low latency; and<BR>* =

    resilience to packet loss.<BR><BR>There are a number of wide-band =
capable=20
    codecs defined by other SDOs. For<BR>instance, G.722 is seeing =
adoption in=20
    Enterprise applications since it is<BR>relatively simple and =
low-cost to=20
    deploy. However, it has a high, fixed<BR>bitrate and is not =
appropriate for=20
    mobile applications where spectrum<BR>efficiency is important or in =
consumer=20
    applications where available<BR>bandwidth is fluctuating or limited. =
G.722.2=20
    (AMR-wideband) has been adopted<BR>by the 3GPP as a wideband =
standard for=20
    mobile applications. G.722.2 is<BR>relatively high cost due to =
patent=20
    royalties and is seeing minimal<BR>deployments outside of mobile =
handsets=20
    making it challenging to create<BR>wideband experiences on =
Internet-capable=20
    mobile devices when extending<BR>beyond the mobile network. In other =
cases,=20
    proprietary codecs are being<BR>adopted which further create islands =
with no=20
    interoperability unless<BR>widespread transcoding is performed. =
Transcoding=20
    leads to higher costs and<BR>lower quality.<BR><BR>The goal of this =
working=20
    group is to define a single codec with multiple<BR>profiles which =
can be=20
    made available on a wide variety of Internet-capable<BR>devices =
including=20
    low-power, mobile devices as well as devices capable of<BR>utilizing =
high=20
    quality, high bitrate audio.<BR><BR>Proposed Deliverables:<BR><BR>1) =

    Requirements for wideband, Internet audio codec(s).<BR>2) Algorithm=20
    description for wideband, Internet audio codec(s) as=20
    Proposed<BR>Standard.<BR>3) Specification of payload format(s) for =
defined=20
    codecs as=20
    =
Proposed<BR>Standard<BR><BR>_____________________________________________=
__<BR>dispatch=20
    mailing list<BR><A =
href=3D"dispatch@ietf.org">dispatch@ietf.org</A><BR><A=20
    =
href=3D"https://www.ietf.org/mailman/listinfo/dispatch">https://www.ietf.=
org/mailman/listinfo/dispatch</A><BR><BR>________________________________=
_______________<BR>dispatch=20
    mailing list<BR><A =
href=3D"dispatch@ietf.org">dispatch@ietf.org</A><BR><A=20
    =
href=3D"https://www.ietf.org/mailman/listinfo/dispatch">https://www.ietf.=
org/mailman/listinfo/dispatch</A><BR><BR></SPAN></FONT></BLOCKQUOTE>
  <P>
  <HR>

  <P></P>_______________________________________________<BR>dispatch =
mailing=20
  =
list<BR>dispatch@ietf.org<BR>https://www.ietf.org/mailman/listinfo/dispat=
ch<BR></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_2C73_01C9E043.C0DBF100--



From ron.even.tlv@gmail.com  Fri May 29 08:39:19 2009
Return-Path: <ron.even.tlv@gmail.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BA813A6B6F for <dispatch@core3.amsl.com>; Fri, 29 May 2009 08:39:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.094
X-Spam-Level: 
X-Spam-Status: No, score=-1.094 tagged_above=-999 required=5 tests=[AWL=-0.951, BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001]
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 d8hFyPDUxAC7 for <dispatch@core3.amsl.com>; Fri, 29 May 2009 08:39:18 -0700 (PDT)
Received: from mail-fx0-f168.google.com (mail-fx0-f168.google.com [209.85.220.168]) by core3.amsl.com (Postfix) with ESMTP id 49D3D3A6C68 for <dispatch@ietf.org>; Fri, 29 May 2009 08:39:17 -0700 (PDT)
Received: by fxm12 with SMTP id 12so4473222fxm.37 for <dispatch@ietf.org>; Fri, 29 May 2009 08:40:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:references :in-reply-to:subject:date:message-id:mime-version:content-type :x-mailer:thread-index:content-language; bh=e4+bBJ+lWUQw+Jc8gGLEZeb6l8SNUDWjh+4BGFdLqFk=; b=YK8xujMtMewvNdZ+SuzaGAxBOWWxJn0u62chAViUj5PlOwDgU+T7xxBYR1d/afaIFW PTlFdsoZpT1PxOko3JJHeXPoZ8sd7kSvz49AGzfFmX1042i5sedAJjvnkS2zkx7+D9eG b4fOfRKEVRPFXyGJt2+RQQMD4a5j2covB3olE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; b=AToRrcgh31+eenO+WSy24IqzrZRFdtOtqbPxTfQ0J19kY3RJstU5EirvA1Uaxv3z1Q t0n9l0iHKM6BEGR+Kom8zyahMnWJuUP0uCoacgR91Lyx8wLxjI4qDkdZ+vi7sTeG1oxW DeXcAlqmTVer/sJvCfwyL/TwP1uXJc5qAwjdk=
Received: by 10.103.226.10 with SMTP id d10mr1681157mur.105.1243611641205; Fri, 29 May 2009 08:40:41 -0700 (PDT)
Received: from windows8d787f9 (bzq-79-177-104-43.red.bezeqint.net [79.177.104.43]) by mx.google.com with ESMTPS id y6sm699007mug.10.2009.05.29.08.40.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 29 May 2009 08:40:40 -0700 (PDT)
From: "Roni Even" <ron.even.tlv@gmail.com>
To: "'Spencer Dawkins'" <spencer@wonderhamster.org>, "'Henry Sinnreich'" <hsinnrei@adobe.com>, "'Jason Fischl'" <jason.fischl@skype.net>, <dispatch@ietf.org>
References: <C64417BD.3D59%hsinnrei@adobe.com> <8DA8EBE683E74919A662C925A153F1CD@china.huawei.com>
In-Reply-To: <8DA8EBE683E74919A662C925A153F1CD@china.huawei.com>
Date: Fri, 29 May 2009 18:39:37 +0300
Message-ID: <4a2001f8.06e2660a.0e62.ffffa1c9@mx.google.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01C9E08C.D2C55200"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcngbdvFs25OiIT7RkaMm/yBABUzPgABXnBg
Content-Language: en-us
Subject: Re: [dispatch] Proposal to form Internet Wideband Audio Codec WG
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 May 2009 15:39:19 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0014_01C9E08C.D2C55200
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Spencer,

Thanks, you are right, I also want to point out that you may end up with
companies asking their audio expert to do also IETF work, adding more travel
and time budget on top of the work they are doing in MPEG and ITU.

 

Roni

 

From: Spencer Dawkins [mailto:spencer@wonderhamster.org] 
Sent: Friday, May 29, 2009 5:57 PM
To: Henry Sinnreich; Roni Even; Jason Fischl; dispatch@ietf.org
Subject: Re: [dispatch] Proposal to form Internet Wideband Audio Codec WG

 

Hi, Henry,

 

I may have misunderstood Roni's point, but I thought that he was saying that
audio codec types don't participate in the IETF today, because the IETF does
not develop audio codecs (and AVT is prohibited by charter from producing
one, because of a stated belief that we don't have the expertise in the IETF
to do this work).

 

Thanks,

 

Spencer

----- Original Message ----- 

From: Henry Sinnreich <mailto:hsinnrei@adobe.com>  

To: Roni Even <mailto:ron.even.tlv@gmail.com>  ; Jason
<mailto:jason.fischl@skype.net>  Fischl ; dispatch@ietf.org 

Sent: Thursday, May 28, 2009 10:28 AM

Subject: Re: [dispatch] Proposal to form Internet Wideband Audio Codec WG

 

Roni,

Sorry, we have here a fundamental disagreement.
The IETF is chartered for Internet standards and may or may not chose
solutions that apply to ITU-T networks.
The Internet has different criteria than ITU-T networks may have.
A worldwide Internet standard for a wideband codec will be very beneficial
IMO.

Henry


On 5/28/09 9:45 AM, "Roni Even" <ron.even.tlv@gmail.com> wrote:

Hi,
Like you mention other SDOs like ITU-T are doing just that. They have the
expertise to specify, and evaluate the result. These SDOs can receive
requirements and select a proper codec based on the requirements.


As for the other reasons:

1. Defining a codec in the IETF or even in MPEG / ITU-T does not make it a
mandatory part of a system solution, this is done by other standard bodies
like 3GPP, ETSI.

2. The IETF, similar to other standard bodies is not rubber stamping a
specific solution, so you will most probably see in the final result some
technology that carry IPR.

3. If this group will be established, you will probably see here the audio
experts now working in ITU-T arguing the same issues since they are the
expertise you need and they work for the same companies that are already
members of IETF.

I think that if you have a specific codec in mind you  can make it publicly
available maybe with quality results and standardized in AVT a payload
specification.

BTW: The ITU is keeping a list of codecs (Not only ITU-T ones) in a table
that describes their features.

Regards
Roni Even

-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf
Of Jason Fischl
Sent: Wednesday, May 27, 2009 2:18 AM
To: dispatch@ietf.org
Subject: [dispatch] Proposal to form Internet Wideband Audio Codec WG

All,

I would like to request agenda time inside the DISPATCH meeting to propose
the formation of a new working group to define a Proposed Standard wideband
audio codec.

The text of the proposal is below. Comments, questions, and suggestions
welcomed.

Regards,
Jason


Internet Wideband Audio Codec (IWAC)
Mailing Lists: TBD
Chairs: TBD
Area Directorate: Real Time Applications (RAI)

Purpose:

This new working group would be chartered with the purpose of collecting
expertise within the IETF in order to review the design of audio codecs
specifically for use with the Internet. Unlike other SDOs, these codecs
would be optimized for use on the Internet, and as much as possible choose
technology that does not require paying patent royalties.

The Internet Low Bit Rate Codec (iLBC)  work was done in AVT but it was felt
that subsequent work should not be done in the AVT working group. This new
working group will have as its primary purpose the standardization of a
multi-purpose audio codec that can be used in various situations on the
Internet. Some of the proposed Internet-specific requirements include:
* scalable and adaptive bit rate;
* various sampling rate profiles from narrow-band to super-wideband;
* scalable complexity;
* low latency; and
* resilience to packet loss.

There are a number of wide-band capable codecs defined by other SDOs. For
instance, G.722 is seeing adoption in Enterprise applications since it is
relatively simple and low-cost to deploy. However, it has a high, fixed
bitrate and is not appropriate for mobile applications where spectrum
efficiency is important or in consumer applications where available
bandwidth is fluctuating or limited. G.722.2 (AMR-wideband) has been adopted
by the 3GPP as a wideband standard for mobile applications. G.722.2 is
relatively high cost due to patent royalties and is seeing minimal
deployments outside of mobile handsets making it challenging to create
wideband experiences on Internet-capable mobile devices when extending
beyond the mobile network. In other cases, proprietary codecs are being
adopted which further create islands with no interoperability unless
widespread transcoding is performed. Transcoding leads to higher costs and
lower quality.

The goal of this working group is to define a single codec with multiple
profiles which can be made available on a wide variety of Internet-capable
devices including low-power, mobile devices as well as devices capable of
utilizing high quality, high bitrate audio.

Proposed Deliverables:

1) Requirements for wideband, Internet audio codec(s).
2) Algorithm description for wideband, Internet audio codec(s) as Proposed
Standard.
3) Specification of payload format(s) for defined codecs as Proposed
Standard

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

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

  _____  

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


------=_NextPart_000_0014_01C9E08C.D2C55200
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>Re: [dispatch] Proposal to form Internet Wideband Audio Codec =
WG</title>
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body bgcolor=3Dwhite lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Spencer,<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Thanks, you are right, I also want to point out that you =
may end
up with companies asking their audio expert to do also IETF work, adding =
more
travel and time budget on top of the work they are doing in MPEG and =
ITU.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Roni<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0in 0in 0in'>

<p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Spencer =
Dawkins
[mailto:spencer@wonderhamster.org] <br>
<b>Sent:</b> Friday, May 29, 2009 5:57 PM<br>
<b>To:</b> Henry Sinnreich; Roni Even; Jason Fischl; =
dispatch@ietf.org<br>
<b>Subject:</b> Re: [dispatch] Proposal to form Internet Wideband Audio =
Codec
WG<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<div>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt'>Hi, =
Henry,</span><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><span style=3D'font-size:10.0pt'>I may have =
misunderstood
Roni's point, but I thought that he was saying that audio codec types =
don't
participate in the IETF today, because the IETF does not develop audio =
codecs
(and AVT is prohibited by charter from producing one, because of a =
stated
belief that we don't have the expertise in the IETF to do this =
work).</span><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt'>Thanks,</span><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt'>Spencer</span><o:p></o:p></p>

</div>

<blockquote style=3D'border:none;border-left:solid black =
1.5pt;padding:0in 0in 0in 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'=
>

<div>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>-----
Original Message ----- <o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal style=3D'background:#E4E4E4'><b><span =
style=3D'font-size:10.0pt;
font-family:"Arial","sans-serif"'>From:</span></b><span =
style=3D'font-size:10.0pt;
font-family:"Arial","sans-serif"'> <a href=3D"mailto:hsinnrei@adobe.com"
title=3D"hsinnrei@adobe.com">Henry Sinnreich</a> <o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>To:</span></b=
><span
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'> <a
href=3D"mailto:ron.even.tlv@gmail.com" =
title=3D"ron.even.tlv@gmail.com">Roni Even</a>
; <a href=3D"mailto:jason.fischl@skype.net" =
title=3D"jason.fischl@skype.net">Jason
Fischl</a> ; <a href=3D"mailto:dispatch@ietf.org" =
title=3D"dispatch@ietf.org">dispatch@ietf.org</a>
<o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Sent:</span><=
/b><span
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'> Thursday, =
May 28,
2009 10:28 AM<o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>Subject:</spa=
n></b><span
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'> Re: =
[dispatch]
Proposal to form Internet Wideband Audio Codec WG<o:p></o:p></span></p>

</div>

<div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><span =
style=3D'font-size:18.0pt;
font-family:"Calibri","sans-serif"'>Roni,<br>
<br>
Sorry, we have here a fundamental disagreement.<br>
The IETF is chartered for Internet standards and may or may not chose =
solutions
that apply to ITU-T networks.<br>
The Internet has different criteria than ITU-T networks may have.<br>
A worldwide Internet standard for a wideband codec will be very =
beneficial IMO.<br>
<br>
Henry<br>
<br>
<br>
On 5/28/09 9:45 AM, &quot;Roni Even&quot; &lt;<a
href=3D"mailto:ron.even.tlv@gmail.com">ron.even.tlv@gmail.com</a>&gt; =
wrote:</span><o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><span =
style=3D'font-size:18.0pt;
font-family:"Calibri","sans-serif"'>Hi,<br>
Like you mention other SDOs like ITU-T are doing just that. They have =
the<br>
expertise to specify, and evaluate the result. These SDOs can =
receive<br>
requirements and select a proper codec based on the requirements.<br>
<br>
<br>
As for the other reasons:<br>
<br>
1. Defining a codec in the IETF or even in MPEG / ITU-T does not make it =
a<br>
mandatory part of a system solution, this is done by other standard =
bodies<br>
like 3GPP, ETSI.<br>
<br>
2. The IETF, similar to other standard bodies is not rubber stamping =
a<br>
specific solution, so you will most probably see in the final result =
some<br>
technology that carry IPR.<br>
<br>
3. If this group will be established, you will probably see here the =
audio<br>
experts now working in ITU-T arguing the same issues since they are =
the<br>
expertise you need and they work for the same companies that are =
already<br>
members of IETF.<br>
<br>
I think that if you have a specific codec in mind you &nbsp;can make it
publicly<br>
available maybe with quality results and standardized in AVT a =
payload<br>
specification.<br>
<br>
BTW: The ITU is keeping a list of codecs (Not only ITU-T ones) in a =
table<br>
that describes their features.<br>
<br>
Regards<br>
Roni Even<br>
<br>
-----Original Message-----<br>
From: <a =
href=3D"dispatch-bounces@ietf.org">dispatch-bounces@ietf.org</a> [<a
href=3D"mailto:dispatch-bounces@ietf.org">mailto:dispatch-bounces@ietf.or=
g</a>]
On Behalf<br>
Of Jason Fischl<br>
Sent: Wednesday, May 27, 2009 2:18 AM<br>
To: <a href=3D"dispatch@ietf.org">dispatch@ietf.org</a><br>
Subject: [dispatch] Proposal to form Internet Wideband Audio Codec =
WG<br>
<br>
All,<br>
<br>
I would like to request agenda time inside the DISPATCH meeting to =
propose<br>
the formation of a new working group to define a Proposed Standard =
wideband<br>
audio codec.<br>
<br>
The text of the proposal is below. Comments, questions, and =
suggestions<br>
welcomed.<br>
<br>
Regards,<br>
Jason<br>
<br>
<br>
Internet Wideband Audio Codec (IWAC)<br>
Mailing Lists: TBD<br>
Chairs: TBD<br>
Area Directorate: Real Time Applications (RAI)<br>
<br>
Purpose:<br>
<br>
This new working group would be chartered with the purpose of =
collecting<br>
expertise within the IETF in order to review the design of audio =
codecs<br>
specifically for use with the Internet. Unlike other SDOs, these =
codecs<br>
would be optimized for use on the Internet, and as much as possible =
choose<br>
technology that does not require paying patent royalties.<br>
<br>
The Internet Low Bit Rate Codec (iLBC) &nbsp;work was done in AVT but it =
was
felt<br>
that subsequent work should not be done in the AVT working group. This =
new<br>
working group will have as its primary purpose the standardization of =
a<br>
multi-purpose audio codec that can be used in various situations on =
the<br>
Internet. Some of the proposed Internet-specific requirements =
include:<br>
* scalable and adaptive bit rate;<br>
* various sampling rate profiles from narrow-band to super-wideband;<br>
* scalable complexity;<br>
* low latency; and<br>
* resilience to packet loss.<br>
<br>
There are a number of wide-band capable codecs defined by other SDOs. =
For<br>
instance, G.722 is seeing adoption in Enterprise applications since it =
is<br>
relatively simple and low-cost to deploy. However, it has a high, =
fixed<br>
bitrate and is not appropriate for mobile applications where =
spectrum<br>
efficiency is important or in consumer applications where available<br>
bandwidth is fluctuating or limited. G.722.2 (AMR-wideband) has been =
adopted<br>
by the 3GPP as a wideband standard for mobile applications. G.722.2 =
is<br>
relatively high cost due to patent royalties and is seeing minimal<br>
deployments outside of mobile handsets making it challenging to =
create<br>
wideband experiences on Internet-capable mobile devices when =
extending<br>
beyond the mobile network. In other cases, proprietary codecs are =
being<br>
adopted which further create islands with no interoperability unless<br>
widespread transcoding is performed. Transcoding leads to higher costs =
and<br>
lower quality.<br>
<br>
The goal of this working group is to define a single codec with =
multiple<br>
profiles which can be made available on a wide variety of =
Internet-capable<br>
devices including low-power, mobile devices as well as devices capable =
of<br>
utilizing high quality, high bitrate audio.<br>
<br>
Proposed Deliverables:<br>
<br>
1) Requirements for wideband, Internet audio codec(s).<br>
2) Algorithm description for wideband, Internet audio codec(s) as =
Proposed<br>
Standard.<br>
3) Specification of payload format(s) for defined codecs as Proposed<br>
Standard<br>
<br>
_______________________________________________<br>
dispatch mailing list<br>
<a href=3D"dispatch@ietf.org">dispatch@ietf.org</a><br>
<a =
href=3D"https://www.ietf.org/mailman/listinfo/dispatch">https://www.ietf.=
org/mailman/listinfo/dispatch</a><br>
<br>
_______________________________________________<br>
dispatch mailing list<br>
<a href=3D"dispatch@ietf.org">dispatch@ietf.org</a><br>
<a =
href=3D"https://www.ietf.org/mailman/listinfo/dispatch">https://www.ietf.=
org/mailman/listinfo/dispatch</a></span><o:p></o:p></p>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'>

<hr size=3D2 width=3D"100%" align=3Dcenter>

</div>

<p class=3DMsoNormal>_______________________________________________<br>
dispatch mailing list<br>
dispatch@ietf.org<br>
https://www.ietf.org/mailman/listinfo/dispatch<o:p></o:p></p>

</blockquote>

</div>

</body>

</html>

------=_NextPart_000_0014_01C9E08C.D2C55200--


From hsinnrei@adobe.com  Fri May 29 08:44:47 2009
Return-Path: <hsinnrei@adobe.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 758A43A6B45 for <dispatch@core3.amsl.com>; Fri, 29 May 2009 08:44:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.866
X-Spam-Level: 
X-Spam-Status: No, score=-4.866 tagged_above=-999 required=5 tests=[AWL=-0.723, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 i373fEDbvjic for <dispatch@core3.amsl.com>; Fri, 29 May 2009 08:44:45 -0700 (PDT)
Received: from psmtp.com (exprod6ob111.obsmtp.com [64.18.1.26]) by core3.amsl.com (Postfix) with ESMTP id 9FE663A6A8E for <dispatch@ietf.org>; Fri, 29 May 2009 08:44:38 -0700 (PDT)
Received: from source ([192.150.11.134]) by exprod6ob111.postini.com ([64.18.5.12]) with SMTP ID DSNKSiADL69bFVTJU6edLDpKjqQwzkTYKb/y@postini.com; Fri, 29 May 2009 08:46:27 PDT
Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n4TFdmao000898; Fri, 29 May 2009 08:39:48 -0700 (PDT)
Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n4TFjotQ011907; Fri, 29 May 2009 08:45:50 -0700 (PDT)
Received: from excas02.corp.adobe.com (10.8.188.212) by nahub01.corp.adobe.com (10.8.189.97) with Microsoft SMTP Server (TLS) id 8.1.340.0; Fri, 29 May 2009 08:45:50 -0700
Received: from nambx05.corp.adobe.com ([10.8.189.124]) by excas02.corp.adobe.com ([10.8.188.212]) with mapi; Fri, 29 May 2009 08:45:50 -0700
From: Henry Sinnreich <hsinnrei@adobe.com>
To: Spencer Dawkins <spencer@wonderhamster.org>, Roni Even <ron.even.tlv@gmail.com>, Jason Fischl <jason.fischl@skype.net>, "dispatch@ietf.org" <dispatch@ietf.org>
Date: Fri, 29 May 2009 08:45:47 -0700
Thread-Topic: [dispatch] Proposal to form Internet Wideband Audio Codec WG
Thread-Index: AcngbbX2cFJE1ySyQpi03lncPtePIQABtKs0
Message-ID: <C6456D5B.3DA1%hsinnrei@adobe.com>
In-Reply-To: <8DA8EBE683E74919A662C925A153F1CD@china.huawei.com>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_C6456D5B3DA1hsinnreiadobecom_"
MIME-Version: 1.0
Subject: Re: [dispatch] Proposal to form Internet Wideband Audio Codec WG
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 May 2009 15:44:47 -0000

--_000_C6456D5B3DA1hsinnreiadobecom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Spencer,

Yes, your points show exactly why we need a new WG in the IETF chartered sp=
ecifically for a standard for an Internet voice (and why not video as well)=
 codec.

The _global_ standard nature, royalty free, open source aspects will most l=
ikely warm the heart of most Internet folks.

The determining factor will be if there are contributors willing to do the =
work of writing the I-Ds for the requirements, algorithm, code and last but=
 not least show  measurements about performance. I see signs that we may ha=
ve very valuable contributions.

We can gage the interest for such a WG by the attendance in the BOF at the =
75 IETF in July.
Please just give it a chance.
We may soon be in the fortunate position to finally have an Internet voice =
codec standard!

Henry


On 5/29/09 9:56 AM, "Spencer Dawkins" <spencer@wonderhamster.org> wrote:

Hi, Henry,

I may have misunderstood Roni's point, but I thought that he was saying tha=
t audio codec types don't participate in the IETF today, because the IETF d=
oes not develop audio codecs (and AVT is prohibited by charter from produci=
ng one, because of a stated belief that we don't have the expertise in the =
IETF to do this work).

Thanks,

Spencer

----- Original Message -----

From:  Henry  Sinnreich <mailto:hsinnrei@adobe.com>

To: Roni Even <mailto:ron.even.tlv@gmail.com>  ; Jason  Fischl <mailto:jaso=
n.fischl@skype.net>  ; dispatch@ietf.org

Sent: Thursday, May 28, 2009 10:28  AM

Subject: Re: [dispatch] Proposal to form  Internet Wideband Audio Codec WG


Roni,

Sorry, we have here a fundamental  disagreement.
The IETF is chartered for Internet standards and may or may  not chose solu=
tions that apply to ITU-T networks.
The Internet has  different criteria than ITU-T networks may have.
A worldwide Internet  standard for a wideband codec will be very beneficial=
  IMO.

Henry


On 5/28/09 9:45 AM, "Roni Even" <ron.even.tlv@gmail.com>  wrote:


Hi,
Like you mention other SDOs like ITU-T are  doing just that. They have the
expertise to specify, and evaluate the  result. These SDOs can receive
requirements and select a proper codec  based on the requirements.


As for the other reasons:

1.  Defining a codec in the IETF or even in MPEG / ITU-T does not make it  =
a
mandatory part of a system solution, this is done by other standard  bodies
like 3GPP, ETSI.

2. The IETF, similar to other standard  bodies is not rubber stamping a
specific solution, so you will most  probably see in the final result some
technology that carry  IPR.

3. If this group will be established, you will probably see here  the audio
experts now working in ITU-T arguing the same issues since they  are the
expertise you need and they work for the same companies that are  already
members of IETF.

I think that if you have a specific codec  in mind you  can make it publicl=
y
available maybe with quality  results and standardized in AVT a payload
specification.

BTW: The  ITU is keeping a list of codecs (Not only ITU-T ones) in a table
that  describes their features.

Regards
Roni Even

-----Original  Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org]  On Beha=
lf
Of Jason Fischl
Sent: Wednesday, May 27, 2009 2:18 AM
To:  dispatch@ietf.org
Subject: [dispatch]  Proposal to form Internet Wideband Audio Codec WG

All,

I would  like to request agenda time inside the DISPATCH meeting to propose
the  formation of a new working group to define a Proposed Standard  wideba=
nd
audio codec.

The text of the proposal is below. Comments,  questions, and  suggestions
welcomed.

Regards,
Jason


Internet  Wideband Audio Codec (IWAC)
Mailing Lists: TBD
Chairs: TBD
Area  Directorate: Real Time Applications (RAI)

Purpose:

This new  working group would be chartered with the purpose of collecting
expertise  within the IETF in order to review the design of audio  codecs
specifically for use with the Internet. Unlike other SDOs, these  codecs
would be optimized for use on the Internet, and as much as  possible choose
technology that does not require paying patent  royalties.

The Internet Low Bit Rate Codec (iLBC)  work was done  in AVT but it was fe=
lt
that subsequent work should not be done in the AVT  working group. This new
working group will have as its primary purpose  the standardization of a
multi-purpose audio codec that can be used in  various situations on the
Internet. Some of the proposed  Internet-specific requirements include:
* scalable and adaptive bit  rate;
* various sampling rate profiles from narrow-band to  super-wideband;
* scalable complexity;
* low latency; and
*  resilience to packet loss.

There are a number of wide-band capable  codecs defined by other SDOs. For
instance, G.722 is seeing adoption in  Enterprise applications since it is
relatively simple and low-cost to  deploy. However, it has a high, fixed
bitrate and is not appropriate for  mobile applications where spectrum
efficiency is important or in consumer  applications where available
bandwidth is fluctuating or limited. G.722.2  (AMR-wideband) has been adopt=
ed
by the 3GPP as a wideband standard for  mobile applications. G.722.2 is
relatively high cost due to patent  royalties and is seeing minimal
deployments outside of mobile handsets  making it challenging to create
wideband experiences on Internet-capable  mobile devices when extending
beyond the mobile network. In other cases,  proprietary codecs are being
adopted which further create islands with no  interoperability unless
widespread transcoding is performed. Transcoding  leads to higher costs and
lower quality.

The goal of this working  group is to define a single codec with multiple
profiles which can be  made available on a wide variety of Internet-capable
devices including  low-power, mobile devices as well as devices capable of
utilizing high  quality, high bitrate audio.

Proposed Deliverables:

1)  Requirements for wideband, Internet audio codec(s).
2) Algorithm  description for wideband, Internet audio codec(s) as  Propose=
d
Standard.
3) Specification of payload format(s) for defined  codecs as  Proposed
Standard

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

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




________________________________


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


--_000_C6456D5B3DA1hsinnreiadobecom_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [dispatch] Proposal to form Internet Wideband Audio Codec WG</TI=
TLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:=
18pt'>Spencer,<BR>
<BR>
Yes, your points show exactly why we need a new WG in the IETF chartered sp=
ecifically for a standard for an Internet voice (and why not video as well)=
 codec. <BR>
<BR>
The _global_ standard nature, royalty free, open source aspects will most l=
ikely warm the heart of most Internet folks.<BR>
<BR>
The determining factor will be if there are contributors willing to do the =
work of writing the I-Ds for the requirements, algorithm, code and last but=
 not least show &nbsp;measurements about performance. I see signs that we m=
ay have very valuable contributions.<BR>
<BR>
We can gage the interest for such a WG by the attendance in the BOF at the =
75 IETF in July.<BR>
Please just give it a chance.<BR>
We may soon be in the fortunate position to finally have an Internet voice =
codec standard!<BR>
<BR>
Henry<BR>
<BR>
<BR>
On 5/29/09 9:56 AM, &quot;Spencer Dawkins&quot; &lt;<a href=3D"spencer@wond=
erhamster.org">spencer@wonderhamster.org</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:18pt'>Hi, Henry,<BR>
&nbsp;<BR>
I may have misunderstood Roni's point, but I thought that he was saying tha=
t audio codec types don't participate in the IETF today, because the IETF d=
oes not develop audio codecs (and AVT is prohibited by charter from produci=
ng one, because of a stated belief that we don't have the expertise in the =
IETF to do this work).<BR>
&nbsp;<BR>
Thanks,<BR>
&nbsp;<BR>
Spencer<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:18pt'> <BR>
----- Original Message ----- <BR>
&nbsp;<BR>
<B>From:</B> &nbsp;Henry &nbsp;Sinnreich &lt;<a href=3D"mailto:hsinnrei@ado=
be.com">mailto:hsinnrei@adobe.com</a>&gt; &nbsp;<BR>
&nbsp;<BR>
<B>To:</B> Roni Even &lt;<a href=3D"mailto:ron.even.tlv@gmail.com">mailto:r=
on.even.tlv@gmail.com</a>&gt; &nbsp;; Jason &nbsp;Fischl &lt;<a href=3D"mai=
lto:jason.fischl@skype.net">mailto:jason.fischl@skype.net</a>&gt; &nbsp;; <=
a href=3D"dispatch@ietf.org">dispatch@ietf.org</a> <BR>
&nbsp;<BR>
<B>Sent:</B> Thursday, May 28, 2009 10:28 &nbsp;AM<BR>
&nbsp;<BR>
<B>Subject:</B> Re: [dispatch] Proposal to form &nbsp;Internet Wideband Aud=
io Codec WG<BR>
&nbsp;<BR>
<BR>
Roni,<BR>
<BR>
Sorry, we have here a fundamental &nbsp;disagreement.<BR>
The IETF is chartered for Internet standards and may or may &nbsp;not chose=
 solutions that apply to ITU-T networks.<BR>
The Internet has &nbsp;different criteria than ITU-T networks may have.<BR>
A worldwide Internet &nbsp;standard for a wideband codec will be very benef=
icial &nbsp;IMO.<BR>
<BR>
Henry<BR>
<BR>
<BR>
On 5/28/09 9:45 AM, &quot;Roni Even&quot; &lt;<a href=3D"ron.even.tlv@gmail=
.com">ron.even.tlv@gmail.com</a>&gt; &nbsp;wrote:<BR>
<BR>
&nbsp;<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:18pt'>Hi,<BR>
Like you mention other SDOs like ITU-T are &nbsp;doing just that. They have=
 the<BR>
expertise to specify, and evaluate the &nbsp;result. These SDOs can receive=
<BR>
requirements and select a proper codec &nbsp;based on the requirements.<BR>
<BR>
<BR>
As for the other reasons:<BR>
<BR>
1. &nbsp;Defining a codec in the IETF or even in MPEG / ITU-T does not make=
 it &nbsp;a<BR>
mandatory part of a system solution, this is done by other standard &nbsp;b=
odies<BR>
like 3GPP, ETSI.<BR>
<BR>
2. The IETF, similar to other standard &nbsp;bodies is not rubber stamping =
a<BR>
specific solution, so you will most &nbsp;probably see in the final result =
some<BR>
technology that carry &nbsp;IPR.<BR>
<BR>
3. If this group will be established, you will probably see here &nbsp;the =
audio<BR>
experts now working in ITU-T arguing the same issues since they &nbsp;are t=
he<BR>
expertise you need and they work for the same companies that are &nbsp;alre=
ady<BR>
members of IETF.<BR>
<BR>
I think that if you have a specific codec &nbsp;in mind you &nbsp;can make =
it publicly<BR>
available maybe with quality &nbsp;results and standardized in AVT a payloa=
d<BR>
specification.<BR>
<BR>
BTW: The &nbsp;ITU is keeping a list of codecs (Not only ITU-T ones) in a t=
able<BR>
that &nbsp;describes their features.<BR>
<BR>
Regards<BR>
Roni Even<BR>
<BR>
-----Original &nbsp;Message-----<BR>
From: <a href=3D"dispatch-bounces@ietf.org">dispatch-bounces@ietf.org</a> [=
<a href=3D"mailto:dispatch-bounces@ietf.org">mailto:dispatch-bounces@ietf.o=
rg</a>] &nbsp;On Behalf<BR>
Of Jason Fischl<BR>
Sent: Wednesday, May 27, 2009 2:18 AM<BR>
To: &nbsp;<a href=3D"dispatch@ietf.org">dispatch@ietf.org</a><BR>
Subject: [dispatch] &nbsp;Proposal to form Internet Wideband Audio Codec WG=
<BR>
<BR>
All,<BR>
<BR>
I would &nbsp;like to request agenda time inside the DISPATCH meeting to pr=
opose<BR>
the &nbsp;formation of a new working group to define a Proposed Standard &n=
bsp;wideband<BR>
audio codec.<BR>
<BR>
The text of the proposal is below. Comments, &nbsp;questions, and &nbsp;sug=
gestions<BR>
welcomed.<BR>
<BR>
Regards,<BR>
Jason<BR>
<BR>
<BR>
Internet &nbsp;Wideband Audio Codec (IWAC)<BR>
Mailing Lists: TBD<BR>
Chairs: TBD<BR>
Area &nbsp;Directorate: Real Time Applications (RAI)<BR>
<BR>
Purpose:<BR>
<BR>
This new &nbsp;working group would be chartered with the purpose of collect=
ing<BR>
expertise &nbsp;within the IETF in order to review the design of audio &nbs=
p;codecs<BR>
specifically for use with the Internet. Unlike other SDOs, these &nbsp;code=
cs<BR>
would be optimized for use on the Internet, and as much as &nbsp;possible c=
hoose<BR>
technology that does not require paying patent &nbsp;royalties.<BR>
<BR>
The Internet Low Bit Rate Codec (iLBC) &nbsp;work was done &nbsp;in AVT but=
 it was felt<BR>
that subsequent work should not be done in the AVT &nbsp;working group. Thi=
s new<BR>
working group will have as its primary purpose &nbsp;the standardization of=
 a<BR>
multi-purpose audio codec that can be used in &nbsp;various situations on t=
he<BR>
Internet. Some of the proposed &nbsp;Internet-specific requirements include=
:<BR>
* scalable and adaptive bit &nbsp;rate;<BR>
* various sampling rate profiles from narrow-band to &nbsp;super-wideband;<=
BR>
* scalable complexity;<BR>
* low latency; and<BR>
* &nbsp;resilience to packet loss.<BR>
<BR>
There are a number of wide-band capable &nbsp;codecs defined by other SDOs.=
 For<BR>
instance, G.722 is seeing adoption in &nbsp;Enterprise applications since i=
t is<BR>
relatively simple and low-cost to &nbsp;deploy. However, it has a high, fix=
ed<BR>
bitrate and is not appropriate for &nbsp;mobile applications where spectrum=
<BR>
efficiency is important or in consumer &nbsp;applications where available<B=
R>
bandwidth is fluctuating or limited. G.722.2 &nbsp;(AMR-wideband) has been =
adopted<BR>
by the 3GPP as a wideband standard for &nbsp;mobile applications. G.722.2 i=
s<BR>
relatively high cost due to patent &nbsp;royalties and is seeing minimal<BR=
>
deployments outside of mobile handsets &nbsp;making it challenging to creat=
e<BR>
wideband experiences on Internet-capable &nbsp;mobile devices when extendin=
g<BR>
beyond the mobile network. In other cases, &nbsp;proprietary codecs are bei=
ng<BR>
adopted which further create islands with no &nbsp;interoperability unless<=
BR>
widespread transcoding is performed. Transcoding &nbsp;leads to higher cost=
s and<BR>
lower quality.<BR>
<BR>
The goal of this working &nbsp;group is to define a single codec with multi=
ple<BR>
profiles which can be &nbsp;made available on a wide variety of Internet-ca=
pable<BR>
devices including &nbsp;low-power, mobile devices as well as devices capabl=
e of<BR>
utilizing high &nbsp;quality, high bitrate audio.<BR>
<BR>
Proposed Deliverables:<BR>
<BR>
1) &nbsp;Requirements for wideband, Internet audio codec(s).<BR>
2) Algorithm &nbsp;description for wideband, Internet audio codec(s) as &nb=
sp;Proposed<BR>
Standard.<BR>
3) Specification of payload format(s) for defined &nbsp;codecs as &nbsp;Pro=
posed<BR>
Standard<BR>
<BR>
_______________________________________________<BR>
dispatch &nbsp;mailing list<BR>
<a href=3D"dispatch@ietf.org">dispatch@ietf.org</a><BR>
<a href=3D"https://www.ietf.org/mailman/listinfo/dispatch">https://www.ietf=
.org/mailman/listinfo/dispatch</a><BR>
<BR>
_______________________________________________<BR>
dispatch &nbsp;mailing list<BR>
<a href=3D"dispatch@ietf.org">dispatch@ietf.org</a><BR>
<a href=3D"https://www.ietf.org/mailman/listinfo/dispatch">https://www.ietf=
.org/mailman/listinfo/dispatch</a><BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial=
"><SPAN STYLE=3D'font-size:18pt'> <BR>
<BR>
&nbsp;<BR>
<HR ALIGN=3DCENTER SIZE=3D"3" WIDTH=3D"100%"> <BR>
<BR>
_______________________________________________<BR>
dispatch mailing &nbsp;list<BR>
<a href=3D"dispatch@ietf.org">dispatch@ietf.org</a><BR>
<a href=3D"https://www.ietf.org/mailman/listinfo/dispatch">https://www.ietf=
.org/mailman/listinfo/dispatch</a><BR>
<BR>
</SPAN></FONT></BLOCKQUOTE></BLOCKQUOTE>
</BODY>
</HTML>


--_000_C6456D5B3DA1hsinnreiadobecom_--

From jmh@joelhalpern.com  Fri May 29 08:53:06 2009
Return-Path: <jmh@joelhalpern.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96F943A6F20 for <dispatch@core3.amsl.com>; Fri, 29 May 2009 08:53:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.234
X-Spam-Level: 
X-Spam-Status: No, score=-2.234 tagged_above=-999 required=5 tests=[AWL=-1.090, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 GzO-jgLStmOp for <dispatch@core3.amsl.com>; Fri, 29 May 2009 08:53:05 -0700 (PDT)
Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 360FE3A6F11 for <dispatch@ietf.org>; Fri, 29 May 2009 08:53:05 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 827224302A5 for <dispatch@ietf.org>; Fri, 29 May 2009 08:54:10 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net
Received: from [10.10.10.100] (pool-71-161-52-172.clppva.btas.verizon.net [71.161.52.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 7A3794302A0 for <dispatch@ietf.org>; Fri, 29 May 2009 08:54:09 -0700 (PDT)
Message-ID: <4A20051D.3070302@joelhalpern.com>
Date: Fri, 29 May 2009 11:54:05 -0400
From: "Joel M. Halpern" <jmh@joelhalpern.com>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: "dispatch@ietf.org" <dispatch@ietf.org>
References: <C6456D5B.3DA1%hsinnrei@adobe.com>
In-Reply-To: <C6456D5B.3DA1%hsinnrei@adobe.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [dispatch] Proposal to form Internet Wideband Audio Codec WG
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 May 2009 15:53:06 -0000

By that model, the IETF should do work on any and every application.
a) We do not have the capacity
b) more importantly, we do not have the expertise.

Codecs is a very good example.  It is a highly specialized field, with 
its own technology base.  None of our leadership or structures are 
designed to have that expertise.  Other groups do have that expertise.

The very fact that AVT, which would be the only place in the IETF that 
could vaguely consider undertaking such work, was explicitly chartered 
not to do this reflects the sensible decision for us to stay out of 
other people's playgrounds.  (Which is fair since we expect them to stay 
out of ours.)

Yours,
Joel M. Halpern

Henry Sinnreich wrote:
>   Spencer,
> 
> Yes, your points show exactly why we need a new WG in the IETF chartered 
> specifically for a standard for an Internet voice (and why not video as 
> well) codec.
> 
> The _global_ standard nature, royalty free, open source aspects will 
> most likely warm the heart of most Internet folks.
> 
> The determining factor will be if there are contributors willing to do 
> the work of writing the I-Ds for the requirements, algorithm, code and 
> last but not least show  measurements about performance. I see signs 
> that we may have very valuable contributions.
> 
> We can gage the interest for such a WG by the attendance in the BOF at 
> the 75 IETF in July.
> Please just give it a chance.
> We may soon be in the fortunate position to finally have an Internet 
> voice codec standard!
> 
> Henry
> 
> 
> On 5/29/09 9:56 AM, "Spencer Dawkins" <spencer@wonderhamster.org> wrote:
> 
>     Hi, Henry,
>      
>     I may have misunderstood Roni's point, but I thought that he was
>     saying that audio codec types don't participate in the IETF today,
>     because the IETF does not develop audio codecs (and AVT is
>     prohibited by charter from producing one, because of a stated belief
>     that we don't have the expertise in the IETF to do this work).
>      
>     Thanks,
>      
>     Spencer
> 
> 
>         ----- Original Message -----
>          
>         *From:*  Henry  Sinnreich <mailto:hsinnrei@adobe.com>  
>          
>         *To:* Roni Even <mailto:ron.even.tlv@gmail.com>  ; Jason  Fischl
>         <mailto:jason.fischl@skype.net>  ; dispatch@ietf.org
>          
>         *Sent:* Thursday, May 28, 2009 10:28  AM
>          
>         *Subject:* Re: [dispatch] Proposal to form  Internet Wideband
>         Audio Codec WG
>          
> 
>         Roni,
> 
>         Sorry, we have here a fundamental  disagreement.
>         The IETF is chartered for Internet standards and may or may  not
>         chose solutions that apply to ITU-T networks.
>         The Internet has  different criteria than ITU-T networks may have.
>         A worldwide Internet  standard for a wideband codec will be very
>         beneficial  IMO.
> 
>         Henry
> 
> 
>         On 5/28/09 9:45 AM, "Roni Even" <ron.even.tlv@gmail.com>  wrote:
> 
>          
> 
>             Hi,
>             Like you mention other SDOs like ITU-T are  doing just that.
>             They have the
>             expertise to specify, and evaluate the  result. These SDOs
>             can receive
>             requirements and select a proper codec  based on the
>             requirements.
> 
> 
>             As for the other reasons:
> 
>             1.  Defining a codec in the IETF or even in MPEG / ITU-T
>             does not make it  a
>             mandatory part of a system solution, this is done by other
>             standard  bodies
>             like 3GPP, ETSI.
> 
>             2. The IETF, similar to other standard  bodies is not rubber
>             stamping a
>             specific solution, so you will most  probably see in the
>             final result some
>             technology that carry  IPR.
> 
>             3. If this group will be established, you will probably see
>             here  the audio
>             experts now working in ITU-T arguing the same issues since
>             they  are the
>             expertise you need and they work for the same companies that
>             are  already
>             members of IETF.
> 
>             I think that if you have a specific codec  in mind you  can
>             make it publicly
>             available maybe with quality  results and standardized in
>             AVT a payload
>             specification.
> 
>             BTW: The  ITU is keeping a list of codecs (Not only ITU-T
>             ones) in a table
>             that  describes their features.
> 
>             Regards
>             Roni Even
> 
>             -----Original  Message-----
>             From: dispatch-bounces@ietf.org
>             [mailto:dispatch-bounces@ietf.org]  On Behalf
>             Of Jason Fischl
>             Sent: Wednesday, May 27, 2009 2:18 AM
>             To:  dispatch@ietf.org
>             Subject: [dispatch]  Proposal to form Internet Wideband
>             Audio Codec WG
> 
>             All,
> 
>             I would  like to request agenda time inside the DISPATCH
>             meeting to propose
>             the  formation of a new working group to define a Proposed
>             Standard  wideband
>             audio codec.
> 
>             The text of the proposal is below. Comments,  questions, and
>              suggestions
>             welcomed.
> 
>             Regards,
>             Jason
> 
> 
>             Internet  Wideband Audio Codec (IWAC)
>             Mailing Lists: TBD
>             Chairs: TBD
>             Area  Directorate: Real Time Applications (RAI)
> 
>             Purpose:
> 
>             This new  working group would be chartered with the purpose
>             of collecting
>             expertise  within the IETF in order to review the design of
>             audio  codecs
>             specifically for use with the Internet. Unlike other SDOs,
>             these  codecs
>             would be optimized for use on the Internet, and as much as
>              possible choose
>             technology that does not require paying patent  royalties.
> 
>             The Internet Low Bit Rate Codec (iLBC)  work was done  in
>             AVT but it was felt
>             that subsequent work should not be done in the AVT  working
>             group. This new
>             working group will have as its primary purpose  the
>             standardization of a
>             multi-purpose audio codec that can be used in  various
>             situations on the
>             Internet. Some of the proposed  Internet-specific
>             requirements include:
>             * scalable and adaptive bit  rate;
>             * various sampling rate profiles from narrow-band to
>              super-wideband;
>             * scalable complexity;
>             * low latency; and
>             *  resilience to packet loss.
> 
>             There are a number of wide-band capable  codecs defined by
>             other SDOs. For
>             instance, G.722 is seeing adoption in  Enterprise
>             applications since it is
>             relatively simple and low-cost to  deploy. However, it has a
>             high, fixed
>             bitrate and is not appropriate for  mobile applications
>             where spectrum
>             efficiency is important or in consumer  applications where
>             available
>             bandwidth is fluctuating or limited. G.722.2  (AMR-wideband)
>             has been adopted
>             by the 3GPP as a wideband standard for  mobile applications.
>             G.722.2 is
>             relatively high cost due to patent  royalties and is seeing
>             minimal
>             deployments outside of mobile handsets  making it
>             challenging to create
>             wideband experiences on Internet-capable  mobile devices
>             when extending
>             beyond the mobile network. In other cases,  proprietary
>             codecs are being
>             adopted which further create islands with no
>              interoperability unless
>             widespread transcoding is performed. Transcoding  leads to
>             higher costs and
>             lower quality.
> 
>             The goal of this working  group is to define a single codec
>             with multiple
>             profiles which can be  made available on a wide variety of
>             Internet-capable
>             devices including  low-power, mobile devices as well as
>             devices capable of
>             utilizing high  quality, high bitrate audio.
> 
>             Proposed Deliverables:
> 
>             1)  Requirements for wideband, Internet audio codec(s).
>             2) Algorithm  description for wideband, Internet audio
>             codec(s) as  Proposed
>             Standard.
>             3) Specification of payload format(s) for defined  codecs as
>              Proposed
>             Standard
> 
>             _______________________________________________
>             dispatch  mailing list
>             dispatch@ietf.org
>             https://www.ietf.org/mailman/listinfo/dispatch
> 
>             _______________________________________________
>             dispatch  mailing list
>             dispatch@ietf.org
>             https://www.ietf.org/mailman/listinfo/dispatch
> 
> 
> 
>          
> 
> 
>         _______________________________________________
>         dispatch mailing  list
>         dispatch@ietf.org
>         https://www.ietf.org/mailman/listinfo/dispatch
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

From hsinnrei@adobe.com  Fri May 29 10:34:46 2009
Return-Path: <hsinnrei@adobe.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60DE33A6E03 for <dispatch@core3.amsl.com>; Fri, 29 May 2009 10:34:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.828
X-Spam-Level: 
X-Spam-Status: No, score=-4.828 tagged_above=-999 required=5 tests=[AWL=-0.685, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 ic-hfwVOGhR5 for <dispatch@core3.amsl.com>; Fri, 29 May 2009 10:34:44 -0700 (PDT)
Received: from exprod6og105.obsmtp.com (exprod6og105.obsmtp.com [64.18.1.189]) by core3.amsl.com (Postfix) with ESMTP id B2B9D3A6D7D for <dispatch@ietf.org>; Fri, 29 May 2009 10:34:43 -0700 (PDT)
Received: from source ([192.150.8.22]) by exprod6ob105.postini.com ([64.18.5.12]) with SMTP ID DSNKSiAc4wOyQt3KyyPiUuL742LV2xaoZ/VA@postini.com; Fri, 29 May 2009 10:36:28 PDT
Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n4TG9UE0001667; Fri, 29 May 2009 09:09:31 -0700 (PDT)
Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n4TG9TtQ016732; Fri, 29 May 2009 09:09:29 -0700 (PDT)
Received: from excas03.corp.adobe.com (10.8.189.123) by nahub01.corp.adobe.com (10.8.189.97) with Microsoft SMTP Server (TLS) id 8.1.340.0; Fri, 29 May 2009 09:09:29 -0700
Received: from nambx05.corp.adobe.com ([10.8.189.124]) by excas03.corp.adobe.com ([10.8.189.123]) with mapi; Fri, 29 May 2009 09:09:29 -0700
From: Henry Sinnreich <hsinnrei@adobe.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>, "dispatch@ietf.org" <dispatch@ietf.org>
Date: Fri, 29 May 2009 09:09:26 -0700
Thread-Topic: [dispatch] Proposal to form Internet Wideband Audio Codec WG
Thread-Index: Acngdc7UlBad9u+7Q2aWwPB6fAZ1UgAAgeb4
Message-ID: <C64572E6.3DAB%hsinnrei@adobe.com>
In-Reply-To: <4A20051D.3070302@joelhalpern.com>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_C64572E63DABhsinnreiadobecom_"
MIME-Version: 1.0
Subject: Re: [dispatch] Proposal to form Internet Wideband Audio Codec WG
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 May 2009 17:34:46 -0000

--_000_C64572E63DABhsinnreiadobecom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Joel,

>a) We do not have the capacity
>b) more importantly, we do not have the expertise.

How do you know this before even counting the volunteering contributors?

Henry


On 5/29/09 10:54 AM, "Joel M. Halpern" <jmh@joelhalpern.com> wrote:

By that model, the IETF should do work on any and every application.
a) We do not have the capacity
b) more importantly, we do not have the expertise.

Codecs is a very good example.  It is a highly specialized field, with
its own technology base.  None of our leadership or structures are
designed to have that expertise.  Other groups do have that expertise.

The very fact that AVT, which would be the only place in the IETF that
could vaguely consider undertaking such work, was explicitly chartered
not to do this reflects the sensible decision for us to stay out of
other people's playgrounds.  (Which is fair since we expect them to stay
out of ours.)

Yours,
Joel M. Halpern

Henry Sinnreich wrote:
>   Spencer,
>
> Yes, your points show exactly why we need a new WG in the IETF chartered
> specifically for a standard for an Internet voice (and why not video as
> well) codec.
>
> The _global_ standard nature, royalty free, open source aspects will
> most likely warm the heart of most Internet folks.
>
> The determining factor will be if there are contributors willing to do
> the work of writing the I-Ds for the requirements, algorithm, code and
> last but not least show  measurements about performance. I see signs
> that we may have very valuable contributions.
>
> We can gage the interest for such a WG by the attendance in the BOF at
> the 75 IETF in July.
> Please just give it a chance.
> We may soon be in the fortunate position to finally have an Internet
> voice codec standard!
>
> Henry
>
>
> On 5/29/09 9:56 AM, "Spencer Dawkins" <spencer@wonderhamster.org> wrote:
>
>     Hi, Henry,
>
>     I may have misunderstood Roni's point, but I thought that he was
>     saying that audio codec types don't participate in the IETF today,
>     because the IETF does not develop audio codecs (and AVT is
>     prohibited by charter from producing one, because of a stated belief
>     that we don't have the expertise in the IETF to do this work).
>
>     Thanks,
>
>     Spencer
>
>
>         ----- Original Message -----
>
>         *From:*  Henry  Sinnreich <mailto:hsinnrei@adobe.com>
>
>         *To:* Roni Even <mailto:ron.even.tlv@gmail.com>  ; Jason  Fischl
>         <mailto:jason.fischl@skype.net>  ; dispatch@ietf.org
>
>         *Sent:* Thursday, May 28, 2009 10:28  AM
>
>         *Subject:* Re: [dispatch] Proposal to form  Internet Wideband
>         Audio Codec WG
>
>
>         Roni,
>
>         Sorry, we have here a fundamental  disagreement.
>         The IETF is chartered for Internet standards and may or may  not
>         chose solutions that apply to ITU-T networks.
>         The Internet has  different criteria than ITU-T networks may have=
.
>         A worldwide Internet  standard for a wideband codec will be very
>         beneficial  IMO.
>
>         Henry
>
>
>         On 5/28/09 9:45 AM, "Roni Even" <ron.even.tlv@gmail.com>  wrote:
>
>
>
>             Hi,
>             Like you mention other SDOs like ITU-T are  doing just that.
>             They have the
>             expertise to specify, and evaluate the  result. These SDOs
>             can receive
>             requirements and select a proper codec  based on the
>             requirements.
>
>
>             As for the other reasons:
>
>             1.  Defining a codec in the IETF or even in MPEG / ITU-T
>             does not make it  a
>             mandatory part of a system solution, this is done by other
>             standard  bodies
>             like 3GPP, ETSI.
>
>             2. The IETF, similar to other standard  bodies is not rubber
>             stamping a
>             specific solution, so you will most  probably see in the
>             final result some
>             technology that carry  IPR.
>
>             3. If this group will be established, you will probably see
>             here  the audio
>             experts now working in ITU-T arguing the same issues since
>             they  are the
>             expertise you need and they work for the same companies that
>             are  already
>             members of IETF.
>
>             I think that if you have a specific codec  in mind you  can
>             make it publicly
>             available maybe with quality  results and standardized in
>             AVT a payload
>             specification.
>
>             BTW: The  ITU is keeping a list of codecs (Not only ITU-T
>             ones) in a table
>             that  describes their features.
>
>             Regards
>             Roni Even
>
>             -----Original  Message-----
>             From: dispatch-bounces@ietf.org
>             [mailto:dispatch-bounces@ietf.org]  On Behalf
>             Of Jason Fischl
>             Sent: Wednesday, May 27, 2009 2:18 AM
>             To:  dispatch@ietf.org
>             Subject: [dispatch]  Proposal to form Internet Wideband
>             Audio Codec WG
>
>             All,
>
>             I would  like to request agenda time inside the DISPATCH
>             meeting to propose
>             the  formation of a new working group to define a Proposed
>             Standard  wideband
>             audio codec.
>
>             The text of the proposal is below. Comments,  questions, and
>              suggestions
>             welcomed.
>
>             Regards,
>             Jason
>
>
>             Internet  Wideband Audio Codec (IWAC)
>             Mailing Lists: TBD
>             Chairs: TBD
>             Area  Directorate: Real Time Applications (RAI)
>
>             Purpose:
>
>             This new  working group would be chartered with the purpose
>             of collecting
>             expertise  within the IETF in order to review the design of
>             audio  codecs
>             specifically for use with the Internet. Unlike other SDOs,
>             these  codecs
>             would be optimized for use on the Internet, and as much as
>              possible choose
>             technology that does not require paying patent  royalties.
>
>             The Internet Low Bit Rate Codec (iLBC)  work was done  in
>             AVT but it was felt
>             that subsequent work should not be done in the AVT  working
>             group. This new
>             working group will have as its primary purpose  the
>             standardization of a
>             multi-purpose audio codec that can be used in  various
>             situations on the
>             Internet. Some of the proposed  Internet-specific
>             requirements include:
>             * scalable and adaptive bit  rate;
>             * various sampling rate profiles from narrow-band to
>              super-wideband;
>             * scalable complexity;
>             * low latency; and
>             *  resilience to packet loss.
>
>             There are a number of wide-band capable  codecs defined by
>             other SDOs. For
>             instance, G.722 is seeing adoption in  Enterprise
>             applications since it is
>             relatively simple and low-cost to  deploy. However, it has a
>             high, fixed
>             bitrate and is not appropriate for  mobile applications
>             where spectrum
>             efficiency is important or in consumer  applications where
>             available
>             bandwidth is fluctuating or limited. G.722.2  (AMR-wideband)
>             has been adopted
>             by the 3GPP as a wideband standard for  mobile applications.
>             G.722.2 is
>             relatively high cost due to patent  royalties and is seeing
>             minimal
>             deployments outside of mobile handsets  making it
>             challenging to create
>             wideband experiences on Internet-capable  mobile devices
>             when extending
>             beyond the mobile network. In other cases,  proprietary
>             codecs are being
>             adopted which further create islands with no
>              interoperability unless
>             widespread transcoding is performed. Transcoding  leads to
>             higher costs and
>             lower quality.
>
>             The goal of this working  group is to define a single codec
>             with multiple
>             profiles which can be  made available on a wide variety of
>             Internet-capable
>             devices including  low-power, mobile devices as well as
>             devices capable of
>             utilizing high  quality, high bitrate audio.
>
>             Proposed Deliverables:
>
>             1)  Requirements for wideband, Internet audio codec(s).
>             2) Algorithm  description for wideband, Internet audio
>             codec(s) as  Proposed
>             Standard.
>             3) Specification of payload format(s) for defined  codecs as
>              Proposed
>             Standard
>
>             _______________________________________________
>             dispatch  mailing list
>             dispatch@ietf.org
>             https://www.ietf.org/mailman/listinfo/dispatch
>
>             _______________________________________________
>             dispatch  mailing list
>             dispatch@ietf.org
>             https://www.ietf.org/mailman/listinfo/dispatch
>
>
>
>
>
>
>         _______________________________________________
>         dispatch mailing  list
>         dispatch@ietf.org
>         https://www.ietf.org/mailman/listinfo/dispatch
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


--_000_C64572E63DABhsinnreiadobecom_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [dispatch] Proposal to form Internet Wideband Audio Codec WG</TI=
TLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:=
18pt'>Joel,<BR>
<BR>
&gt;a) We do not have the capacity<BR>
&gt;b) more importantly, we do not have the expertise.<BR>
<BR>
How do you know this before even counting the volunteering contributors?<BR=
>
<BR>
Henry<BR>
<BR>
<BR>
On 5/29/09 10:54 AM, &quot;Joel M. Halpern&quot; &lt;<a href=3D"jmh@joelhal=
pern.com">jmh@joelhalpern.com</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:18pt'>By that model, the IETF should do work on a=
ny and every application.<BR>
a) We do not have the capacity<BR>
b) more importantly, we do not have the expertise.<BR>
<BR>
Codecs is a very good example. &nbsp;It is a highly specialized field, with=
<BR>
its own technology base. &nbsp;None of our leadership or structures are<BR>
designed to have that expertise. &nbsp;Other groups do have that expertise.=
<BR>
<BR>
The very fact that AVT, which would be the only place in the IETF that<BR>
could vaguely consider undertaking such work, was explicitly chartered<BR>
not to do this reflects the sensible decision for us to stay out of<BR>
other people's playgrounds. &nbsp;(Which is fair since we expect them to st=
ay<BR>
out of ours.)<BR>
<BR>
Yours,<BR>
Joel M. Halpern<BR>
<BR>
Henry Sinnreich wrote:<BR>
&gt; &nbsp;&nbsp;Spencer,<BR>
&gt;<BR>
&gt; Yes, your points show exactly why we need a new WG in the IETF charter=
ed<BR>
&gt; specifically for a standard for an Internet voice (and why not video a=
s<BR>
&gt; well) codec.<BR>
&gt;<BR>
&gt; The _global_ standard nature, royalty free, open source aspects will<B=
R>
&gt; most likely warm the heart of most Internet folks.<BR>
&gt;<BR>
&gt; The determining factor will be if there are contributors willing to do=
<BR>
&gt; the work of writing the I-Ds for the requirements, algorithm, code and=
<BR>
&gt; last but not least show &nbsp;measurements about performance. I see si=
gns<BR>
&gt; that we may have very valuable contributions.<BR>
&gt;<BR>
&gt; We can gage the interest for such a WG by the attendance in the BOF at=
<BR>
&gt; the 75 IETF in July.<BR>
&gt; Please just give it a chance.<BR>
&gt; We may soon be in the fortunate position to finally have an Internet<B=
R>
&gt; voice codec standard!<BR>
&gt;<BR>
&gt; Henry<BR>
&gt;<BR>
&gt;<BR>
&gt; On 5/29/09 9:56 AM, &quot;Spencer Dawkins&quot; &lt;<a href=3D"spencer=
@wonderhamster.org">spencer@wonderhamster.org</a>&gt; wrote:<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;Hi, Henry,<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;I may have misunderstood Roni's point, but I t=
hought that he was<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;saying that audio codec types don't participat=
e in the IETF today,<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;because the IETF does not develop audio codecs=
 (and AVT is<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;prohibited by charter from producing one, beca=
use of a stated belief<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;that we don't have the expertise in the IETF t=
o do this work).<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;Thanks,<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;Spencer<BR>
&gt;<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;----- Original Message=
 -----<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*From:* &nbsp;Henry &n=
bsp;Sinnreich &lt;<a href=3D"mailto:hsinnrei@adobe.com">mailto:hsinnrei@ado=
be.com</a>&gt; <BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*To:* Roni Even &lt;<a=
 href=3D"mailto:ron.even.tlv@gmail.com">mailto:ron.even.tlv@gmail.com</a>&g=
t; &nbsp;; Jason &nbsp;Fischl<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;<a href=3D"mailto:=
jason.fischl@skype.net">mailto:jason.fischl@skype.net</a>&gt; &nbsp;; <a hr=
ef=3D"dispatch@ietf.org">dispatch@ietf.org</a><BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*Sent:* Thursday, May =
28, 2009 10:28 &nbsp;AM<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*Subject:* Re: [dispat=
ch] Proposal to form &nbsp;Internet Wideband<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Audio Codec WG<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Roni,<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Sorry, we have here a =
fundamental &nbsp;disagreement.<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;The IETF is chartered =
for Internet standards and may or may &nbsp;not<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;chose solutions that a=
pply to ITU-T networks.<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;The Internet has &nbsp=
;different criteria than ITU-T networks may have.<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;A worldwide Internet &=
nbsp;standard for a wideband codec will be very<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;beneficial &nbsp;IMO.<=
BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Henry<BR>
&gt;<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;On 5/28/09 9:45 AM, &q=
uot;Roni Even&quot; &lt;<a href=3D"ron.even.tlv@gmail.com">ron.even.tlv@gma=
il.com</a>&gt; &nbsp;wrote:<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;Hi,<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;Like you mention other SDOs like ITU-T are &nbsp;doing just that.<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;They have the<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;expertise to specify, and evaluate the &nbsp;result. These SDOs<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;can receive<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;requirements and select a proper codec &nbsp;based on the<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;requirements.<BR>
&gt;<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;As for the other reasons:<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;1. &nbsp;Defining a codec in the IETF or even in MPEG / ITU-T<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;does not make it &nbsp;a<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;mandatory part of a system solution, this is done by other<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;standard &nbsp;bodies<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;like 3GPP, ETSI.<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;2. The IETF, similar to other standard &nbsp;bodies is not rubber<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;stamping a<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;specific solution, so you will most &nbsp;probably see in the<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;final result some<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;technology that carry &nbsp;IPR.<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;3. If this group will be established, you will probably see<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;here &nbsp;the audio<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;experts now working in ITU-T arguing the same issues since<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;they &nbsp;are the<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;expertise you need and they work for the same companies that<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;are &nbsp;already<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;members of IETF.<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;I think that if you have a specific codec &nbsp;in mind you &nbsp;can<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;make it publicly<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;available maybe with quality &nbsp;results and standardized in<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;AVT a payload<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;specification.<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;BTW: The &nbsp;ITU is keeping a list of codecs (Not only ITU-T<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;ones) in a table<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;that &nbsp;describes their features.<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;Regards<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;Roni Even<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;-----Original &nbsp;Message-----<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;From: <a href=3D"dispatch-bounces@ietf.org">dispatch-bounces@ietf.org</a>=
<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;[<a href=3D"mailto:dispatch-bounces@ietf.org">mailto:dispatch-bounces@iet=
f.org</a>] &nbsp;On Behalf<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;Of Jason Fischl<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;Sent: Wednesday, May 27, 2009 2:18 AM<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;To: &nbsp;<a href=3D"dispatch@ietf.org">dispatch@ietf.org</a><BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;Subject: [dispatch] &nbsp;Proposal to form Internet Wideband<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;Audio Codec WG<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;All,<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;I would &nbsp;like to request agenda time inside the DISPATCH<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;meeting to propose<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;the &nbsp;formation of a new working group to define a Proposed<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;Standard &nbsp;wideband<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;audio codec.<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;The text of the proposal is below. Comments, &nbsp;questions, and<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;suggestions<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;welcomed.<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;Regards,<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;Jason<BR>
&gt;<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;Internet &nbsp;Wideband Audio Codec (IWAC)<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;Mailing Lists: TBD<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;Chairs: TBD<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;Area &nbsp;Directorate: Real Time Applications (RAI)<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;Purpose:<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;This new &nbsp;working group would be chartered with the purpose<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;of collecting<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;expertise &nbsp;within the IETF in order to review the design of<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;audio &nbsp;codecs<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;specifically for use with the Internet. Unlike other SDOs,<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;these &nbsp;codecs<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;would be optimized for use on the Internet, and as much as<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;possible choose<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;technology that does not require paying patent &nbsp;royalties.<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;The Internet Low Bit Rate Codec (iLBC) &nbsp;work was done &nbsp;in<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;AVT but it was felt<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;that subsequent work should not be done in the AVT &nbsp;working<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;group. This new<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;working group will have as its primary purpose &nbsp;the<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;standardization of a<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;multi-purpose audio codec that can be used in &nbsp;various<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;situations on the<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;Internet. Some of the proposed &nbsp;Internet-specific<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;requirements include:<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;* scalable and adaptive bit &nbsp;rate;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;* various sampling rate profiles from narrow-band to<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;super-wideband;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;* scalable complexity;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;* low latency; and<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;* &nbsp;resilience to packet loss.<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;There are a number of wide-band capable &nbsp;codecs defined by<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;other SDOs. For<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;instance, G.722 is seeing adoption in &nbsp;Enterprise<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;applications since it is<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;relatively simple and low-cost to &nbsp;deploy. However, it has a<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;high, fixed<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;bitrate and is not appropriate for &nbsp;mobile applications<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;where spectrum<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;efficiency is important or in consumer &nbsp;applications where<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;available<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;bandwidth is fluctuating or limited. G.722.2 &nbsp;(AMR-wideband)<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;has been adopted<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;by the 3GPP as a wideband standard for &nbsp;mobile applications.<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;G.722.2 is<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;relatively high cost due to patent &nbsp;royalties and is seeing<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;minimal<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;deployments outside of mobile handsets &nbsp;making it<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;challenging to create<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;wideband experiences on Internet-capable &nbsp;mobile devices<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;when extending<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;beyond the mobile network. In other cases, &nbsp;proprietary<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;codecs are being<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;adopted which further create islands with no<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;interoperability unless<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;widespread transcoding is performed. Transcoding &nbsp;leads to<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;higher costs and<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;lower quality.<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;The goal of this working &nbsp;group is to define a single codec<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;with multiple<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;profiles which can be &nbsp;made available on a wide variety of<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;Internet-capable<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;devices including &nbsp;low-power, mobile devices as well as<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;devices capable of<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;utilizing high &nbsp;quality, high bitrate audio.<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;Proposed Deliverables:<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;1) &nbsp;Requirements for wideband, Internet audio codec(s).<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;2) Algorithm &nbsp;description for wideband, Internet audio<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;codec(s) as &nbsp;Proposed<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;Standard.<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;3) Specification of payload format(s) for defined &nbsp;codecs as<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;Proposed<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;Standard<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;_______________________________________________<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;dispatch &nbsp;mailing list<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;<a href=3D"dispatch@ietf.org">dispatch@ietf.org</a><BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;<a href=3D"https://www.ietf.org/mailman/listinfo/dispatch">https://www.ie=
tf.org/mailman/listinfo/dispatch</a><BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;_______________________________________________<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;dispatch &nbsp;mailing list<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;<a href=3D"dispatch@ietf.org">dispatch@ietf.org</a><BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;<a href=3D"https://www.ietf.org/mailman/listinfo/dispatch">https://www.ie=
tf.org/mailman/listinfo/dispatch</a><BR>
&gt;<BR>
&gt;<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&gt;<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;______________________=
_________________________<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;dispatch mailing &nbsp=
;list<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href=3D"dispatch@ie=
tf.org">dispatch@ietf.org</a><BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href=3D"https://www=
.ietf.org/mailman/listinfo/dispatch">https://www.ietf.org/mailman/listinfo/=
dispatch</a><BR>
&gt;<BR>
&gt;<BR>
&gt; ----------------------------------------------------------------------=
--<BR>
&gt;<BR>
&gt; _______________________________________________<BR>
&gt; dispatch mailing list<BR>
&gt; <a href=3D"dispatch@ietf.org">dispatch@ietf.org</a><BR>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/dispatch">https://www=
.ietf.org/mailman/listinfo/dispatch</a><BR>
_______________________________________________<BR>
dispatch mailing list<BR>
<a href=3D"dispatch@ietf.org">dispatch@ietf.org</a><BR>
<a href=3D"https://www.ietf.org/mailman/listinfo/dispatch">https://www.ietf=
.org/mailman/listinfo/dispatch</a><BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--_000_C64572E63DABhsinnreiadobecom_--

From ron.even.tlv@gmail.com  Fri May 29 11:22:31 2009
Return-Path: <ron.even.tlv@gmail.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BA903A6774 for <dispatch@core3.amsl.com>; Fri, 29 May 2009 11:22:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.021
X-Spam-Level: 
X-Spam-Status: No, score=-1.021 tagged_above=-999 required=5 tests=[AWL=-0.877, BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001]
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 ZXkwFETSDkxg for <dispatch@core3.amsl.com>; Fri, 29 May 2009 11:22:27 -0700 (PDT)
Received: from mail-fx0-f168.google.com (mail-fx0-f168.google.com [209.85.220.168]) by core3.amsl.com (Postfix) with ESMTP id CC5AB3A6B6C for <dispatch@ietf.org>; Fri, 29 May 2009 11:22:26 -0700 (PDT)
Received: by fxm12 with SMTP id 12so4564950fxm.37 for <dispatch@ietf.org>; Fri, 29 May 2009 11:23:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:references :in-reply-to:subject:date:message-id:mime-version:content-type :x-mailer:thread-index:content-language; bh=s2MO22IavE8Yw2g5XqVVCFedmzApFh/tCEhRpmZYVRA=; b=PWCT+J9BxA6YMUEZaZbmti7zvsytpB974cDyeHna31atvyZV01qbkZiTfuzOYJJYnY VhEJPQmsOnpr/aHCeWDr/r+ZCSClLwgNIZzvSwiLiOwY8vHq+tV3Jp9xz98w/CF5tRgs guBS7BhiCW5MALL/AsCntXtbDTxLe0JbobPEU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; b=DIXimlf9XEsysOrdBlyGa+ktBWTBAdL0ymojfi9jxaEcyRt5Me84SSc31xF4FB/W2s /lVQwUmfnZMKfF67QnsZin0SQ3D4SpHtQRvysRg57Wql9TvWk5xgyJnSPwgPPjSNPkGg KhmjUz4W2UjRIrcC0lf6TqwZgpZ49PBKZoPNo=
Received: by 10.103.160.10 with SMTP id m10mr1763700muo.50.1243620954698; Fri, 29 May 2009 11:15:54 -0700 (PDT)
Received: from windows8d787f9 (bzq-79-177-104-43.red.bezeqint.net [79.177.104.43]) by mx.google.com with ESMTPS id i5sm159672mue.25.2009.05.29.11.15.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 29 May 2009 11:15:53 -0700 (PDT)
From: "Roni Even" <ron.even.tlv@gmail.com>
To: "'Henry Sinnreich'" <hsinnrei@adobe.com>, "'Joel M. Halpern'" <jmh@joelhalpern.com>, <dispatch@ietf.org>
References: <4A20051D.3070302@joelhalpern.com> <C64572E6.3DAB%hsinnrei@adobe.com>
In-Reply-To: <C64572E6.3DAB%hsinnrei@adobe.com>
Date: Fri, 29 May 2009 21:14:48 +0300
Message-ID: <4a202659.05a0660a.7bcd.1d52@mx.google.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0036_01C9E0A2.81DD0840"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acngdc7UlBad9u+7Q2aWwPB6fAZ1UgAAgeb4AARI6rA=
Content-Language: en-us
Subject: Re: [dispatch] Proposal to form Internet Wideband Audio Codec WG
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 May 2009 18:22:31 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0036_01C9E0A2.81DD0840
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Henry,

You can ask it on the mailing list, no need for a session. I would just
suggest that it will be done not on dispatch mailing list because if any
audio coding expert is subscribed to a list it will be AVT and not Dispatch.

 

BTW: I forwarded the email to AVT and there are some people responding
there, again they are not on Dispatch

 

Roni 

 

From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf
Of Henry Sinnreich
Sent: Friday, May 29, 2009 7:09 PM
To: Joel M. Halpern; dispatch@ietf.org
Subject: Re: [dispatch] Proposal to form Internet Wideband Audio Codec WG

 

Joel,

>a) We do not have the capacity
>b) more importantly, we do not have the expertise.

How do you know this before even counting the volunteering contributors?

Henry


On 5/29/09 10:54 AM, "Joel M. Halpern" <jmh@joelhalpern.com> wrote:

By that model, the IETF should do work on any and every application.
a) We do not have the capacity
b) more importantly, we do not have the expertise.

Codecs is a very good example.  It is a highly specialized field, with
its own technology base.  None of our leadership or structures are
designed to have that expertise.  Other groups do have that expertise.

The very fact that AVT, which would be the only place in the IETF that
could vaguely consider undertaking such work, was explicitly chartered
not to do this reflects the sensible decision for us to stay out of
other people's playgrounds.  (Which is fair since we expect them to stay
out of ours.)

Yours,
Joel M. Halpern

Henry Sinnreich wrote:
>   Spencer,
>
> Yes, your points show exactly why we need a new WG in the IETF chartered
> specifically for a standard for an Internet voice (and why not video as
> well) codec.
>
> The _global_ standard nature, royalty free, open source aspects will
> most likely warm the heart of most Internet folks.
>
> The determining factor will be if there are contributors willing to do
> the work of writing the I-Ds for the requirements, algorithm, code and
> last but not least show  measurements about performance. I see signs
> that we may have very valuable contributions.
>
> We can gage the interest for such a WG by the attendance in the BOF at
> the 75 IETF in July.
> Please just give it a chance.
> We may soon be in the fortunate position to finally have an Internet
> voice codec standard!
>
> Henry
>
>
> On 5/29/09 9:56 AM, "Spencer Dawkins" <spencer@wonderhamster.org> wrote:
>
>     Hi, Henry,
>     
>     I may have misunderstood Roni's point, but I thought that he was
>     saying that audio codec types don't participate in the IETF today,
>     because the IETF does not develop audio codecs (and AVT is
>     prohibited by charter from producing one, because of a stated belief
>     that we don't have the expertise in the IETF to do this work).
>     
>     Thanks,
>     
>     Spencer
>
>
>         ----- Original Message -----
>         
>         *From:*  Henry  Sinnreich <mailto:hsinnrei@adobe.com> 
>         
>         *To:* Roni Even <mailto:ron.even.tlv@gmail.com>  ; Jason  Fischl
>         <mailto:jason.fischl@skype.net>  ; dispatch@ietf.org
>         
>         *Sent:* Thursday, May 28, 2009 10:28  AM
>         
>         *Subject:* Re: [dispatch] Proposal to form  Internet Wideband
>         Audio Codec WG
>         
>
>         Roni,
>
>         Sorry, we have here a fundamental  disagreement.
>         The IETF is chartered for Internet standards and may or may  not
>         chose solutions that apply to ITU-T networks.
>         The Internet has  different criteria than ITU-T networks may have.
>         A worldwide Internet  standard for a wideband codec will be very
>         beneficial  IMO.
>
>         Henry
>
>
>         On 5/28/09 9:45 AM, "Roni Even" <ron.even.tlv@gmail.com>  wrote:
>
>         
>
>             Hi,
>             Like you mention other SDOs like ITU-T are  doing just that.
>             They have the
>             expertise to specify, and evaluate the  result. These SDOs
>             can receive
>             requirements and select a proper codec  based on the
>             requirements.
>
>
>             As for the other reasons:
>
>             1.  Defining a codec in the IETF or even in MPEG / ITU-T
>             does not make it  a
>             mandatory part of a system solution, this is done by other
>             standard  bodies
>             like 3GPP, ETSI.
>
>             2. The IETF, similar to other standard  bodies is not rubber
>             stamping a
>             specific solution, so you will most  probably see in the
>             final result some
>             technology that carry  IPR.
>
>             3. If this group will be established, you will probably see
>             here  the audio
>             experts now working in ITU-T arguing the same issues since
>             they  are the
>             expertise you need and they work for the same companies that
>             are  already
>             members of IETF.
>
>             I think that if you have a specific codec  in mind you  can
>             make it publicly
>             available maybe with quality  results and standardized in
>             AVT a payload
>             specification.
>
>             BTW: The  ITU is keeping a list of codecs (Not only ITU-T
>             ones) in a table
>             that  describes their features.
>
>             Regards
>             Roni Even
>
>             -----Original  Message-----
>             From: dispatch-bounces@ietf.org
>             [mailto:dispatch-bounces@ietf.org]  On Behalf
>             Of Jason Fischl
>             Sent: Wednesday, May 27, 2009 2:18 AM
>             To:  dispatch@ietf.org
>             Subject: [dispatch]  Proposal to form Internet Wideband
>             Audio Codec WG
>
>             All,
>
>             I would  like to request agenda time inside the DISPATCH
>             meeting to propose
>             the  formation of a new working group to define a Proposed
>             Standard  wideband
>             audio codec.
>
>             The text of the proposal is below. Comments,  questions, and
>              suggestions
>             welcomed.
>
>             Regards,
>             Jason
>
>
>             Internet  Wideband Audio Codec (IWAC)
>             Mailing Lists: TBD
>             Chairs: TBD
>             Area  Directorate: Real Time Applications (RAI)
>
>             Purpose:
>
>             This new  working group would be chartered with the purpose
>             of collecting
>             expertise  within the IETF in order to review the design of
>             audio  codecs
>             specifically for use with the Internet. Unlike other SDOs,
>             these  codecs
>             would be optimized for use on the Internet, and as much as
>              possible choose
>             technology that does not require paying patent  royalties.
>
>             The Internet Low Bit Rate Codec (iLBC)  work was done  in
>             AVT but it was felt
>             that subsequent work should not be done in the AVT  working
>             group. This new
>             working group will have as its primary purpose  the
>             standardization of a
>             multi-purpose audio codec that can be used in  various
>             situations on the
>             Internet. Some of the proposed  Internet-specific
>             requirements include:
>             * scalable and adaptive bit  rate;
>             * various sampling rate profiles from narrow-band to
>              super-wideband;
>             * scalable complexity;
>             * low latency; and
>             *  resilience to packet loss.
>
>             There are a number of wide-band capable  codecs defined by
>             other SDOs. For
>             instance, G.722 is seeing adoption in  Enterprise
>             applications since it is
>             relatively simple and low-cost to  deploy. However, it has a
>             high, fixed
>             bitrate and is not appropriate for  mobile applications
>             where spectrum
>             efficiency is important or in consumer  applications where
>             available
>             bandwidth is fluctuating or limited. G.722.2  (AMR-wideband)
>             has been adopted
>             by the 3GPP as a wideband standard for  mobile applications.
>             G.722.2 is
>             relatively high cost due to patent  royalties and is seeing
>             minimal
>             deployments outside of mobile handsets  making it
>             challenging to create
>             wideband experiences on Internet-capable  mobile devices
>             when extending
>             beyond the mobile network. In other cases,  proprietary
>             codecs are being
>             adopted which further create islands with no
>              interoperability unless
>             widespread transcoding is performed. Transcoding  leads to
>             higher costs and
>             lower quality.
>
>             The goal of this working  group is to define a single codec
>             with multiple
>             profiles which can be  made available on a wide variety of
>             Internet-capable
>             devices including  low-power, mobile devices as well as
>             devices capable of
>             utilizing high  quality, high bitrate audio.
>
>             Proposed Deliverables:
>
>             1)  Requirements for wideband, Internet audio codec(s).
>             2) Algorithm  description for wideband, Internet audio
>             codec(s) as  Proposed
>             Standard.
>             3) Specification of payload format(s) for defined  codecs as
>              Proposed
>             Standard
>
>             _______________________________________________
>             dispatch  mailing list
>             dispatch@ietf.org
>             https://www.ietf.org/mailman/listinfo/dispatch
>
>             _______________________________________________
>             dispatch  mailing list
>             dispatch@ietf.org
>             https://www.ietf.org/mailman/listinfo/dispatch
>
>
>
>         
>
>
>         _______________________________________________
>         dispatch mailing  list
>         dispatch@ietf.org
>         https://www.ietf.org/mailman/listinfo/dispatch
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


------=_NextPart_000_0036_01C9E0A2.81DD0840
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<title>Re: [dispatch] Proposal to form Internet Wideband Audio Codec =
WG</title>
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Henry,<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>You can ask it on the mailing list, no need for a =
session. I
would just suggest that it will be done not on dispatch mailing list =
because if
any audio coding expert is subscribed to a list it will be AVT and not
Dispatch.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>BTW: I forwarded the email to AVT and there are some =
people responding
there, again they are not on Dispatch<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Roni <o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0in 0in 0in'>

<p class=3DMsoNormal><b><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] <b>On =
Behalf Of </b>Henry
Sinnreich<br>
<b>Sent:</b> Friday, May 29, 2009 7:09 PM<br>
<b>To:</b> Joel M. Halpern; dispatch@ietf.org<br>
<b>Subject:</b> Re: [dispatch] Proposal to form Internet Wideband Audio =
Codec
WG<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><span =
style=3D'font-size:18.0pt;
font-family:"Calibri","sans-serif"'>Joel,<br>
<br>
&gt;a) We do not have the capacity<br>
&gt;b) more importantly, we do not have the expertise.<br>
<br>
How do you know this before even counting the volunteering =
contributors?<br>
<br>
Henry<br>
<br>
<br>
On 5/29/09 10:54 AM, &quot;Joel M. Halpern&quot; &lt;<a
href=3D"jmh@joelhalpern.com">jmh@joelhalpern.com</a>&gt; =
wrote:</span><o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><span =
style=3D'font-size:18.0pt;
font-family:"Calibri","sans-serif"'>By that model, the IETF should do =
work on
any and every application.<br>
a) We do not have the capacity<br>
b) more importantly, we do not have the expertise.<br>
<br>
Codecs is a very good example. &nbsp;It is a highly specialized field, =
with<br>
its own technology base. &nbsp;None of our leadership or structures =
are<br>
designed to have that expertise. &nbsp;Other groups do have that =
expertise.<br>
<br>
The very fact that AVT, which would be the only place in the IETF =
that<br>
could vaguely consider undertaking such work, was explicitly =
chartered<br>
not to do this reflects the sensible decision for us to stay out of<br>
other people's playgrounds. &nbsp;(Which is fair since we expect them to =
stay<br>
out of ours.)<br>
<br>
Yours,<br>
Joel M. Halpern<br>
<br>
Henry Sinnreich wrote:<br>
&gt; &nbsp;&nbsp;Spencer,<br>
&gt;<br>
&gt; Yes, your points show exactly why we need a new WG in the IETF =
chartered<br>
&gt; specifically for a standard for an Internet voice (and why not =
video as<br>
&gt; well) codec.<br>
&gt;<br>
&gt; The _global_ standard nature, royalty free, open source aspects =
will<br>
&gt; most likely warm the heart of most Internet folks.<br>
&gt;<br>
&gt; The determining factor will be if there are contributors willing to =
do<br>
&gt; the work of writing the I-Ds for the requirements, algorithm, code =
and<br>
&gt; last but not least show &nbsp;measurements about performance. I see =
signs<br>
&gt; that we may have very valuable contributions.<br>
&gt;<br>
&gt; We can gage the interest for such a WG by the attendance in the BOF =
at<br>
&gt; the 75 IETF in July.<br>
&gt; Please just give it a chance.<br>
&gt; We may soon be in the fortunate position to finally have an =
Internet<br>
&gt; voice codec standard!<br>
&gt;<br>
&gt; Henry<br>
&gt;<br>
&gt;<br>
&gt; On 5/29/09 9:56 AM, &quot;Spencer Dawkins&quot; &lt;<a
href=3D"spencer@wonderhamster.org">spencer@wonderhamster.org</a>&gt; =
wrote:<br>
&gt;<br>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;Hi, Henry,<br>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;<br>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;I may have misunderstood Roni's point, but =
I
thought that he was<br>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;saying that audio codec types don't =
participate in
the IETF today,<br>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;because the IETF does not develop audio =
codecs (and
AVT is<br>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;prohibited by charter from producing one, =
because
of a stated belief<br>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;that we don't have the expertise in the =
IETF to do
this work).<br>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;<br>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;Thanks,<br>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;<br>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;Spencer<br>
&gt;<br>
&gt;<br>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;----- Original =
Message
-----<br>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*From:* &nbsp;Henry
&nbsp;Sinnreich &lt;<a =
href=3D"mailto:hsinnrei@adobe.com">mailto:hsinnrei@adobe.com</a>&gt;
<br>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*To:* Roni Even =
&lt;<a
href=3D"mailto:ron.even.tlv@gmail.com">mailto:ron.even.tlv@gmail.com</a>&=
gt;
&nbsp;; Jason &nbsp;Fischl<br>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;<a
href=3D"mailto:jason.fischl@skype.net">mailto:jason.fischl@skype.net</a>&=
gt;
&nbsp;; <a href=3D"dispatch@ietf.org">dispatch@ietf.org</a><br>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*Sent:* Thursday, =
May 28,
2009 10:28 &nbsp;AM<br>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*Subject:* Re: =
[dispatch]
Proposal to form &nbsp;Internet Wideband<br>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Audio Codec WG<br>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
&gt;<br>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Roni,<br>
&gt;<br>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Sorry, we have here =
a
fundamental &nbsp;disagreement.<br>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;The IETF is =
chartered for
Internet standards and may or may &nbsp;not<br>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;chose solutions =
that apply
to ITU-T networks.<br>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;The Internet has
&nbsp;different criteria than ITU-T networks may have.<br>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;A worldwide =
Internet
&nbsp;standard for a wideband codec will be very<br>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;beneficial =
&nbsp;IMO.<br>
&gt;<br>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Henry<br>
&gt;<br>
&gt;<br>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;On 5/28/09 9:45 AM,
&quot;Roni Even&quot; &lt;<a =
href=3D"ron.even.tlv@gmail.com">ron.even.tlv@gmail.com</a>&gt;
&nbsp;wrote:<br>
&gt;<br>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
&gt;<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;H=
i,<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;L=
ike
you mention other SDOs like ITU-T are &nbsp;doing just that.<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;T=
hey
have the<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;e=
xpertise
to specify, and evaluate the &nbsp;result. These SDOs<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;c=
an
receive<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;r=
equirements
and select a proper codec &nbsp;based on the<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;r=
equirements.<br>
&gt;<br>
&gt;<br>
&gt; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;A=
s
for the other reasons:<br>
&gt;<br>
&gt; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1=
.
&nbsp;Defining a codec in the IETF or even in MPEG / ITU-T<br>
&gt; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;d=
oes
not make it &nbsp;a<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;m=
andatory
part of a system solution, this is done by other<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;s=
tandard
&nbsp;bodies<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;l=
ike
3GPP, ETSI.<br>
&gt;<br>
&gt; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2=
.
The IETF, similar to other standard &nbsp;bodies is not rubber<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;s=
tamping
a<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;s=
pecific
solution, so you will most &nbsp;probably see in the<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;f=
inal
result some<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;t=
echnology
that carry &nbsp;IPR.<br>
&gt;<br>
&gt; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3=
.
If this group will be established, you will probably see<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;h=
ere
&nbsp;the audio<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;e=
xperts
now working in ITU-T arguing the same issues since<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;t=
hey
&nbsp;are the<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;e=
xpertise
you need and they work for the same companies that<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;a=
re
&nbsp;already<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;m=
embers
of IETF.<br>
&gt;<br>
&gt; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I=

think that if you have a specific codec &nbsp;in mind you &nbsp;can<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;m=
ake it
publicly<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;a=
vailable
maybe with quality &nbsp;results and standardized in<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;A=
VT a
payload<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;s=
pecification.<br>
&gt;<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;B=
TW:
The &nbsp;ITU is keeping a list of codecs (Not only ITU-T<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;o=
nes)
in a table<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;t=
hat
&nbsp;describes their features.<br>
&gt;<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;R=
egards<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;R=
oni
Even<br>
&gt;<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-=
----Original
&nbsp;Message-----<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;F=
rom: <a
href=3D"dispatch-bounces@ietf.org">dispatch-bounces@ietf.org</a><br>
&gt; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[=
<a
href=3D"mailto:dispatch-bounces@ietf.org">mailto:dispatch-bounces@ietf.or=
g</a>]
&nbsp;On Behalf<br>
&gt; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;O=
f
Jason Fischl<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;S=
ent:
Wednesday, May 27, 2009 2:18 AM<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;T=
o:
&nbsp;<a href=3D"dispatch@ietf.org">dispatch@ietf.org</a><br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;S=
ubject:
[dispatch] &nbsp;Proposal to form Internet Wideband<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;A=
udio
Codec WG<br>
&gt;<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;A=
ll,<br>
&gt;<br>
&gt; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I=

would &nbsp;like to request agenda time inside the DISPATCH<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;m=
eeting
to propose<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;t=
he
&nbsp;formation of a new working group to define a Proposed<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;S=
tandard
&nbsp;wideband<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;a=
udio
codec.<br>
&gt;<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;T=
he
text of the proposal is below. Comments, &nbsp;questions, and<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;suggestions<br>
&gt; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;w=
elcomed.<br>
&gt;<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;R=
egards,<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;J=
ason<br>
&gt;<br>
&gt;<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I=
nternet
&nbsp;Wideband Audio Codec (IWAC)<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;M=
ailing
Lists: TBD<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;C=
hairs:
TBD<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;A=
rea
&nbsp;Directorate: Real Time Applications (RAI)<br>
&gt;<br>
&gt; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;P=
urpose:<br>
&gt;<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;T=
his
new &nbsp;working group would be chartered with the purpose<br>
&gt; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;o=
f
collecting<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;e=
xpertise
&nbsp;within the IETF in order to review the design of<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;a=
udio
&nbsp;codecs<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;s=
pecifically
for use with the Internet. Unlike other SDOs,<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;t=
hese
&nbsp;codecs<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;w=
ould
be optimized for use on the Internet, and as much as<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;possible
choose<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;t=
echnology
that does not require paying patent &nbsp;royalties.<br>
&gt;<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;T=
he Internet
Low Bit Rate Codec (iLBC) &nbsp;work was done &nbsp;in<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;A=
VT but
it was felt<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;t=
hat
subsequent work should not be done in the AVT &nbsp;working<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;g=
roup.
This new<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;w=
orking
group will have as its primary purpose &nbsp;the<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;s=
tandardization
of a<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;m=
ulti-purpose
audio codec that can be used in &nbsp;various<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;s=
ituations
on the<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I=
nternet.
Some of the proposed &nbsp;Internet-specific<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;r=
equirements
include:<br>
&gt; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*=

scalable and adaptive bit &nbsp;rate;<br>
&gt; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*=

various sampling rate profiles from narrow-band to<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;super-wideband;<br>
&gt; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*=

scalable complexity;<br>
&gt; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*=

low latency; and<br>
&gt; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*=

&nbsp;resilience to packet loss.<br>
&gt;<br>
&gt; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;T=
here
are a number of wide-band capable &nbsp;codecs defined by<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;o=
ther
SDOs. For<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;i=
nstance,
G.722 is seeing adoption in &nbsp;Enterprise<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;a=
pplications
since it is<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;r=
elatively
simple and low-cost to &nbsp;deploy. However, it has a<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;h=
igh,
fixed<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;b=
itrate
and is not appropriate for &nbsp;mobile applications<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;w=
here
spectrum<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;e=
fficiency
is important or in consumer &nbsp;applications where<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;a=
vailable<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;b=
andwidth
is fluctuating or limited. G.722.2 &nbsp;(AMR-wideband)<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;h=
as
been adopted<br>
&gt; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;b=
y
the 3GPP as a wideband standard for &nbsp;mobile applications.<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;G=
.722.2
is<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;r=
elatively
high cost due to patent &nbsp;royalties and is seeing<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;m=
inimal<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;d=
eployments
outside of mobile handsets &nbsp;making it<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;c=
hallenging
to create<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;w=
ideband
experiences on Internet-capable &nbsp;mobile devices<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;w=
hen
extending<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;b=
eyond
the mobile network. In other cases, &nbsp;proprietary<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;c=
odecs
are being<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;a=
dopted
which further create islands with no<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;interoperability
unless<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;w=
idespread
transcoding is performed. Transcoding &nbsp;leads to<br>
&gt; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;h=
igher
costs and<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;l=
ower
quality.<br>
&gt;<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;T=
he
goal of this working &nbsp;group is to define a single codec<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;w=
ith
multiple<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;p=
rofiles
which can be &nbsp;made available on a wide variety of<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I=
nternet-capable<br>
&gt; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;d=
evices
including &nbsp;low-power, mobile devices as well as<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;d=
evices
capable of<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;u=
tilizing
high &nbsp;quality, high bitrate audio.<br>
&gt;<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;P=
roposed
Deliverables:<br>
&gt;<br>
&gt; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1=
)
&nbsp;Requirements for wideband, Internet audio codec(s).<br>
&gt; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2=
)
Algorithm &nbsp;description for wideband, Internet audio<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;c=
odec(s)
as &nbsp;Proposed<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;S=
tandard.<br>
&gt; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3=
)
Specification of payload format(s) for defined &nbsp;codecs as<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;Proposed<br>
&gt; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;S=
tandard<br>
&gt;<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;_=
______________________________________________<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;d=
ispatch
&nbsp;mailing list<br>
&gt; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<=
a
href=3D"dispatch@ietf.org">dispatch@ietf.org</a><br>
&gt; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<=
a
href=3D"https://www.ietf.org/mailman/listinfo/dispatch">https://www.ietf.=
org/mailman/listinfo/dispatch</a><br>
&gt;<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;_=
______________________________________________<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;d=
ispatch
&nbsp;mailing list<br>
&gt; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<=
a
href=3D"dispatch@ietf.org">dispatch@ietf.org</a><br>
&gt; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<=
a
href=3D"https://www.ietf.org/mailman/listinfo/dispatch">https://www.ietf.=
org/mailman/listinfo/dispatch</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
&gt;<br>
&gt;<br>
&gt;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;_________________________=
______________________<br>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;dispatch mailing
&nbsp;list<br>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a =
href=3D"dispatch@ietf.org">dispatch@ietf.org</a><br>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a
href=3D"https://www.ietf.org/mailman/listinfo/dispatch">https://www.ietf.=
org/mailman/listinfo/dispatch</a><br>
&gt;<br>
&gt;<br>
&gt; =
------------------------------------------------------------------------<=
br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; dispatch mailing list<br>
&gt; <a href=3D"dispatch@ietf.org">dispatch@ietf.org</a><br>
&gt; <a =
href=3D"https://www.ietf.org/mailman/listinfo/dispatch">https://www.ietf.=
org/mailman/listinfo/dispatch</a><br>
_______________________________________________<br>
dispatch mailing list<br>
<a href=3D"dispatch@ietf.org">dispatch@ietf.org</a><br>
<a =
href=3D"https://www.ietf.org/mailman/listinfo/dispatch">https://www.ietf.=
org/mailman/listinfo/dispatch</a></span><o:p></o:p></p>

</div>

</body>

</html>

------=_NextPart_000_0036_01C9E0A2.81DD0840--


From mary.barnes@nortel.com  Fri May 29 11:44:55 2009
Return-Path: <mary.barnes@nortel.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70DB33A6AC1 for <dispatch@core3.amsl.com>; Fri, 29 May 2009 11:44:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.262
X-Spam-Level: 
X-Spam-Status: No, score=-5.262 tagged_above=-999 required=5 tests=[AWL=-1.119, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 M963irwjdVuN for <dispatch@core3.amsl.com>; Fri, 29 May 2009 11:44:53 -0700 (PDT)
Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 9D6AE3A6ADE for <dispatch@ietf.org>; Fri, 29 May 2009 11:44:52 -0700 (PDT)
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n4TIXaI08023; Fri, 29 May 2009 18:33:36 GMT
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_01C9E08C.1849A2A6"
Date: Fri, 29 May 2009 13:37:04 -0500
Message-ID: <1ECE0EB50388174790F9694F77522CCF1E3DF458@zrc2hxm0.corp.nortel.com>
In-Reply-To: <4a202659.05a0660a.7bcd.1d52@mx.google.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [dispatch] Proposal to form Internet Wideband Audio Codec WG
Thread-Index: Acngdc7UlBad9u+7Q2aWwPB6fAZ1UgAAgeb4AARI6rAAANONIA==
References: <4A20051D.3070302@joelhalpern.com><C64572E6.3DAB%hsinnrei@adobe.com> <4a202659.05a0660a.7bcd.1d52@mx.google.com>
From: "Mary Barnes" <mary.barnes@nortel.com>
To: "Roni Even" <ron.even.tlv@gmail.com>, "Henry Sinnreich" <hsinnrei@adobe.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, <dispatch@ietf.org>
Subject: Re: [dispatch] Proposal to form Internet Wideband Audio Codec WG
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 May 2009 18:44:55 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9E08C.1849A2A6
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Roni,
=20
It would be helpful then if you could summarize the AVT opinions on this
topic, including pointers to the most relevant discussions.=20
=20
Thanks,
Mary.=20

________________________________

From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
Behalf Of Roni Even
Sent: Friday, May 29, 2009 1:15 PM
To: 'Henry Sinnreich'; 'Joel M. Halpern'; dispatch@ietf.org
Subject: Re: [dispatch] Proposal to form Internet Wideband Audio Codec
WG



Henry,

You can ask it on the mailing list, no need for a session. I would just
suggest that it will be done not on dispatch mailing list because if any
audio coding expert is subscribed to a list it will be AVT and not
Dispatch.

=20

BTW: I forwarded the email to AVT and there are some people responding
there, again they are not on Dispatch

=20

Roni=20

=20

From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
Behalf Of Henry Sinnreich
Sent: Friday, May 29, 2009 7:09 PM
To: Joel M. Halpern; dispatch@ietf.org
Subject: Re: [dispatch] Proposal to form Internet Wideband Audio Codec
WG

=20

Joel,

>a) We do not have the capacity
>b) more importantly, we do not have the expertise.

How do you know this before even counting the volunteering contributors?

Henry


On 5/29/09 10:54 AM, "Joel M. Halpern" <jmh@joelhalpern.com> wrote:

By that model, the IETF should do work on any and every application.
a) We do not have the capacity
b) more importantly, we do not have the expertise.

Codecs is a very good example.  It is a highly specialized field, with
its own technology base.  None of our leadership or structures are
designed to have that expertise.  Other groups do have that expertise.

The very fact that AVT, which would be the only place in the IETF that
could vaguely consider undertaking such work, was explicitly chartered
not to do this reflects the sensible decision for us to stay out of
other people's playgrounds.  (Which is fair since we expect them to stay
out of ours.)

Yours,
Joel M. Halpern

Henry Sinnreich wrote:
>   Spencer,
>
> Yes, your points show exactly why we need a new WG in the IETF
chartered
> specifically for a standard for an Internet voice (and why not video
as
> well) codec.
>
> The _global_ standard nature, royalty free, open source aspects will
> most likely warm the heart of most Internet folks.
>
> The determining factor will be if there are contributors willing to do
> the work of writing the I-Ds for the requirements, algorithm, code and
> last but not least show  measurements about performance. I see signs
> that we may have very valuable contributions.
>
> We can gage the interest for such a WG by the attendance in the BOF at
> the 75 IETF in July.
> Please just give it a chance.
> We may soon be in the fortunate position to finally have an Internet
> voice codec standard!
>
> Henry
>
>
> On 5/29/09 9:56 AM, "Spencer Dawkins" <spencer@wonderhamster.org>
wrote:
>
>     Hi, Henry,
>    =20
>     I may have misunderstood Roni's point, but I thought that he was
>     saying that audio codec types don't participate in the IETF today,
>     because the IETF does not develop audio codecs (and AVT is
>     prohibited by charter from producing one, because of a stated
belief
>     that we don't have the expertise in the IETF to do this work).
>    =20
>     Thanks,
>    =20
>     Spencer
>
>
>         ----- Original Message -----
>        =20
>         *From:*  Henry  Sinnreich <mailto:hsinnrei@adobe.com>=20
>        =20
>         *To:* Roni Even <mailto:ron.even.tlv@gmail.com>  ; Jason
Fischl
>         <mailto:jason.fischl@skype.net>  ; dispatch@ietf.org
>        =20
>         *Sent:* Thursday, May 28, 2009 10:28  AM
>        =20
>         *Subject:* Re: [dispatch] Proposal to form  Internet Wideband
>         Audio Codec WG
>        =20
>
>         Roni,
>
>         Sorry, we have here a fundamental  disagreement.
>         The IETF is chartered for Internet standards and may or may
not
>         chose solutions that apply to ITU-T networks.
>         The Internet has  different criteria than ITU-T networks may
have.
>         A worldwide Internet  standard for a wideband codec will be
very
>         beneficial  IMO.
>
>         Henry
>
>
>         On 5/28/09 9:45 AM, "Roni Even" <ron.even.tlv@gmail.com>
wrote:
>
>        =20
>
>             Hi,
>             Like you mention other SDOs like ITU-T are  doing just
that.
>             They have the
>             expertise to specify, and evaluate the  result. These SDOs
>             can receive
>             requirements and select a proper codec  based on the
>             requirements.
>
>
>             As for the other reasons:
>
>             1.  Defining a codec in the IETF or even in MPEG / ITU-T
>             does not make it  a
>             mandatory part of a system solution, this is done by other
>             standard  bodies
>             like 3GPP, ETSI.
>
>             2. The IETF, similar to other standard  bodies is not
rubber
>             stamping a
>             specific solution, so you will most  probably see in the
>             final result some
>             technology that carry  IPR.
>
>             3. If this group will be established, you will probably
see
>             here  the audio
>             experts now working in ITU-T arguing the same issues since
>             they  are the
>             expertise you need and they work for the same companies
that
>             are  already
>             members of IETF.
>
>             I think that if you have a specific codec  in mind you
can
>             make it publicly
>             available maybe with quality  results and standardized in
>             AVT a payload
>             specification.
>
>             BTW: The  ITU is keeping a list of codecs (Not only ITU-T
>             ones) in a table
>             that  describes their features.
>
>             Regards
>             Roni Even
>
>             -----Original  Message-----
>             From: dispatch-bounces@ietf.org
>             [mailto:dispatch-bounces@ietf.org]  On Behalf
>             Of Jason Fischl
>             Sent: Wednesday, May 27, 2009 2:18 AM
>             To:  dispatch@ietf.org
>             Subject: [dispatch]  Proposal to form Internet Wideband
>             Audio Codec WG
>
>             All,
>
>             I would  like to request agenda time inside the DISPATCH
>             meeting to propose
>             the  formation of a new working group to define a Proposed
>             Standard  wideband
>             audio codec.
>
>             The text of the proposal is below. Comments,  questions,
and
>              suggestions
>             welcomed.
>
>             Regards,
>             Jason
>
>
>             Internet  Wideband Audio Codec (IWAC)
>             Mailing Lists: TBD
>             Chairs: TBD
>             Area  Directorate: Real Time Applications (RAI)
>
>             Purpose:
>
>             This new  working group would be chartered with the
purpose
>             of collecting
>             expertise  within the IETF in order to review the design
of
>             audio  codecs
>             specifically for use with the Internet. Unlike other SDOs,
>             these  codecs
>             would be optimized for use on the Internet, and as much as
>              possible choose
>             technology that does not require paying patent  royalties.
>
>             The Internet Low Bit Rate Codec (iLBC)  work was done  in
>             AVT but it was felt
>             that subsequent work should not be done in the AVT
working
>             group. This new
>             working group will have as its primary purpose  the
>             standardization of a
>             multi-purpose audio codec that can be used in  various
>             situations on the
>             Internet. Some of the proposed  Internet-specific
>             requirements include:
>             * scalable and adaptive bit  rate;
>             * various sampling rate profiles from narrow-band to
>              super-wideband;
>             * scalable complexity;
>             * low latency; and
>             *  resilience to packet loss.
>
>             There are a number of wide-band capable  codecs defined by
>             other SDOs. For
>             instance, G.722 is seeing adoption in  Enterprise
>             applications since it is
>             relatively simple and low-cost to  deploy. However, it has
a
>             high, fixed
>             bitrate and is not appropriate for  mobile applications
>             where spectrum
>             efficiency is important or in consumer  applications where
>             available
>             bandwidth is fluctuating or limited. G.722.2
(AMR-wideband)
>             has been adopted
>             by the 3GPP as a wideband standard for  mobile
applications.
>             G.722.2 is
>             relatively high cost due to patent  royalties and is
seeing
>             minimal
>             deployments outside of mobile handsets  making it
>             challenging to create
>             wideband experiences on Internet-capable  mobile devices
>             when extending
>             beyond the mobile network. In other cases,  proprietary
>             codecs are being
>             adopted which further create islands with no
>              interoperability unless
>             widespread transcoding is performed. Transcoding  leads to
>             higher costs and
>             lower quality.
>
>             The goal of this working  group is to define a single
codec
>             with multiple
>             profiles which can be  made available on a wide variety of
>             Internet-capable
>             devices including  low-power, mobile devices as well as
>             devices capable of
>             utilizing high  quality, high bitrate audio.
>
>             Proposed Deliverables:
>
>             1)  Requirements for wideband, Internet audio codec(s).
>             2) Algorithm  description for wideband, Internet audio
>             codec(s) as  Proposed
>             Standard.
>             3) Specification of payload format(s) for defined  codecs
as
>              Proposed
>             Standard
>
>             _______________________________________________
>             dispatch  mailing list
>             dispatch@ietf.org
>             https://www.ietf.org/mailman/listinfo/dispatch
>
>             _______________________________________________
>             dispatch  mailing list
>             dispatch@ietf.org
>             https://www.ietf.org/mailman/listinfo/dispatch
>
>
>
>        =20
>
>
>         _______________________________________________
>         dispatch mailing  list
>         dispatch@ietf.org
>         https://www.ietf.org/mailman/listinfo/dispatch
>
>
>
------------------------------------------------------------------------
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


------_=_NextPart_001_01C9E08C.1849A2A6
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:m =3D=20
"http://schemas.microsoft.com/office/2004/12/omml"><HEAD><TITLE>Re: =
[dispatch] Proposal to form Internet Wideband Audio Codec WG</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.3527" name=3DGENERATOR>
<STYLE>@font-face {
	font-family: Cambria Math;
}
@font-face {
	font-family: Calibri;
}
@font-face {
	font-family: Tahoma;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New =
Roman","serif"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New =
Roman","serif"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New =
Roman","serif"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.EmailStyle17 {
	COLOR: #1f497d; FONT-FAMILY: "Calibri","sans-serif"; mso-style-type: =
personal-reply
}
.MsoChpDefault {
	FONT-SIZE: 10pt; mso-style-type: export-only
}
DIV.Section1 {
	page: Section1
}
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=3DEN-US vLink=3Dpurple link=3Dblue>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D968463518-29052009>Roni,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D968463518-29052009></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D968463518-29052009>It=20
would be helpful then if you could summarize the AVT opinions on this =
topic,=20
including pointers to the most relevant discussions. =
</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D968463518-29052009></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D968463518-29052009>Thanks,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D968463518-29052009>Mary.=20
</SPAN></FONT></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> dispatch-bounces@ietf.org=20
[mailto:dispatch-bounces@ietf.org] <B>On Behalf Of </B>Roni =
Even<BR><B>Sent:</B>=20
Friday, May 29, 2009 1:15 PM<BR><B>To:</B> 'Henry Sinnreich'; 'Joel M. =
Halpern';=20
dispatch@ietf.org<BR><B>Subject:</B> Re: [dispatch] Proposal to form =
Internet=20
Wideband Audio Codec WG<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV class=3DSection1>
<P class=3DMsoNormal><SPAN=20
style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">Henry,<o:p></o:p></SPAN></P>
<P class=3DMsoNormal><SPAN=20
style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">You=20
can ask it on the mailing list, no need for a session. I would just =
suggest that=20
it will be done not on dispatch mailing list because if any audio coding =
expert=20
is subscribed to a list it will be AVT and not =
Dispatch.<o:p></o:p></SPAN></P>
<P class=3DMsoNormal><SPAN=20
style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
<P class=3DMsoNormal><SPAN=20
style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">BTW:=20
I forwarded the email to AVT and there are some people responding there, =
again=20
they are not on Dispatch<o:p></o:p></SPAN></P>
<P class=3DMsoNormal><SPAN=20
style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
<P class=3DMsoNormal><SPAN=20
style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'">Roni=20
<o:p></o:p></SPAN></P>
<P class=3DMsoNormal><SPAN=20
style=3D"FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: =
'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P>
<DIV>
<DIV=20
style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: =
#b5c4df 1pt solid; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; BORDER-LEFT: =
medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none">
<P class=3DMsoNormal><B><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
'Tahoma','sans-serif'">From:</SPAN></B><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'">=20
dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] <B>On =
Behalf Of=20
</B>Henry Sinnreich<BR><B>Sent:</B> Friday, May 29, 2009 7:09 =
PM<BR><B>To:</B>=20
Joel M. Halpern; dispatch@ietf.org<BR><B>Subject:</B> Re: [dispatch] =
Proposal to=20
form Internet Wideband Audio Codec WG<o:p></o:p></SPAN></P></DIV></DIV>
<P class=3DMsoNormal><o:p>&nbsp;</o:p></P>
<P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><SPAN=20
style=3D"FONT-SIZE: 18pt; FONT-FAMILY: =
'Calibri','sans-serif'">Joel,<BR><BR>&gt;a)=20
We do not have the capacity<BR>&gt;b) more importantly, we do not have =
the=20
expertise.<BR><BR>How do you know this before even counting the =
volunteering=20
contributors?<BR><BR>Henry<BR><BR><BR>On 5/29/09 10:54 AM, "Joel M. =
Halpern"=20
&lt;<A href=3D"jmh@joelhalpern.com">jmh@joelhalpern.com</A>&gt;=20
wrote:</SPAN><o:p></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN-BOTTOM: 12pt"><SPAN=20
style=3D"FONT-SIZE: 18pt; FONT-FAMILY: 'Calibri','sans-serif'">By that =
model, the=20
IETF should do work on any and every application.<BR>a) We do not have =
the=20
capacity<BR>b) more importantly, we do not have the =
expertise.<BR><BR>Codecs is=20
a very good example. &nbsp;It is a highly specialized field, with<BR>its =
own=20
technology base. &nbsp;None of our leadership or structures =
are<BR>designed to=20
have that expertise. &nbsp;Other groups do have that =
expertise.<BR><BR>The very=20
fact that AVT, which would be the only place in the IETF that<BR>could =
vaguely=20
consider undertaking such work, was explicitly chartered<BR>not to do =
this=20
reflects the sensible decision for us to stay out of<BR>other people's=20
playgrounds. &nbsp;(Which is fair since we expect them to stay<BR>out of =

ours.)<BR><BR>Yours,<BR>Joel M. Halpern<BR><BR>Henry Sinnreich =
wrote:<BR>&gt;=20
&nbsp;&nbsp;Spencer,<BR>&gt;<BR>&gt; Yes, your points show exactly why =
we need a=20
new WG in the IETF chartered<BR>&gt; specifically for a standard for an =
Internet=20
voice (and why not video as<BR>&gt; well) codec.<BR>&gt;<BR>&gt; The =
_global_=20
standard nature, royalty free, open source aspects will<BR>&gt; most =
likely warm=20
the heart of most Internet folks.<BR>&gt;<BR>&gt; The determining factor =
will be=20
if there are contributors willing to do<BR>&gt; the work of writing the =
I-Ds for=20
the requirements, algorithm, code and<BR>&gt; last but not least show=20
&nbsp;measurements about performance. I see signs<BR>&gt; that we may =
have very=20
valuable contributions.<BR>&gt;<BR>&gt; We can gage the interest for =
such a WG=20
by the attendance in the BOF at<BR>&gt; the 75 IETF in July.<BR>&gt; =
Please just=20
give it a chance.<BR>&gt; We may soon be in the fortunate position to =
finally=20
have an Internet<BR>&gt; voice codec standard!<BR>&gt;<BR>&gt;=20
Henry<BR>&gt;<BR>&gt;<BR>&gt; On 5/29/09 9:56 AM, "Spencer Dawkins" =
&lt;<A=20
href=3D"spencer@wonderhamster.org">spencer@wonderhamster.org</A>&gt;=20
wrote:<BR>&gt;<BR>&gt; &nbsp;&nbsp;&nbsp;&nbsp;Hi, Henry,<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt; &nbsp;&nbsp;&nbsp;&nbsp;I may have=20
misunderstood Roni's point, but I thought that he was<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;saying that audio codec types don't participate =
in the=20
IETF today,<BR>&gt; &nbsp;&nbsp;&nbsp;&nbsp;because the IETF does not =
develop=20
audio codecs (and AVT is<BR>&gt; &nbsp;&nbsp;&nbsp;&nbsp;prohibited by =
charter=20
from producing one, because of a stated belief<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;that we don't have the expertise in the IETF to =
do this=20
work).<BR>&gt; &nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;Thanks,<BR>&gt; &nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt; =

&nbsp;&nbsp;&nbsp;&nbsp;Spencer<BR>&gt;<BR>&gt;<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;----- Original Message=20
-----<BR>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*From:* &nbsp;Henry=20
&nbsp;Sinnreich &lt;<A=20
href=3D"mailto:hsinnrei@adobe.com">mailto:hsinnrei@adobe.com</A>&gt; =
<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*To:* Roni Even &lt;<A=20
href=3D"mailto:ron.even.tlv@gmail.com">mailto:ron.even.tlv@gmail.com</A>&=
gt;=20
&nbsp;; Jason &nbsp;Fischl<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;<A=20
href=3D"mailto:jason.fischl@skype.net">mailto:jason.fischl@skype.net</A>&=
gt;=20
&nbsp;; <A href=3D"dispatch@ietf.org">dispatch@ietf.org</A><BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*Sent:* Thursday, May =
28, 2009=20
10:28 &nbsp;AM<BR>&gt; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*Subject:* Re: =
[dispatch]=20
Proposal to form &nbsp;Internet Wideband<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Audio Codec WG<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Roni,<BR>&gt;<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Sorry, we have here a=20
fundamental &nbsp;disagreement.<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;The IETF is chartered =
for=20
Internet standards and may or may &nbsp;not<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;chose solutions that =
apply to=20
ITU-T networks.<BR>&gt; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;The=20
Internet has &nbsp;different criteria than ITU-T networks may =
have.<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;A worldwide Internet=20
&nbsp;standard for a wideband codec will be very<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;beneficial=20
&nbsp;IMO.<BR>&gt;<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Henry<BR>&gt;<BR>&gt;<BR>=
&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;On 5/28/09 9:45 AM, =
"Roni Even"=20
&lt;<A href=3D"ron.even.tlv@gmail.com">ron.even.tlv@gmail.com</A>&gt;=20
&nbsp;wrote:<BR>&gt;<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;H=
i,<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;L=
ike you=20
mention other SDOs like ITU-T are &nbsp;doing just that.<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;T=
hey=20
have the<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;e=
xpertise=20
to specify, and evaluate the &nbsp;result. These SDOs<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;c=
an=20
receive<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;r=
equirements=20
and select a proper codec &nbsp;based on the<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;r=
equirements.<BR>&gt;<BR>&gt;<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;A=
s for=20
the other reasons:<BR>&gt;<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1=
.=20
&nbsp;Defining a codec in the IETF or even in MPEG / ITU-T<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;d=
oes not=20
make it &nbsp;a<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;m=
andatory=20
part of a system solution, this is done by other<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;s=
tandard=20
&nbsp;bodies<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;l=
ike=20
3GPP, ETSI.<BR>&gt;<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2=
. The=20
IETF, similar to other standard &nbsp;bodies is not rubber<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;s=
tamping=20
a<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;s=
pecific=20
solution, so you will most &nbsp;probably see in the<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;f=
inal=20
result some<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;t=
echnology=20
that carry &nbsp;IPR.<BR>&gt;<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3=
. If=20
this group will be established, you will probably see<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;h=
ere=20
&nbsp;the audio<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;e=
xperts=20
now working in ITU-T arguing the same issues since<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;t=
hey=20
&nbsp;are the<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;e=
xpertise=20
you need and they work for the same companies that<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;a=
re=20
&nbsp;already<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;m=
embers=20
of IETF.<BR>&gt;<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I=
 think=20
that if you have a specific codec &nbsp;in mind you &nbsp;can<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;m=
ake it=20
publicly<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;a=
vailable=20
maybe with quality &nbsp;results and standardized in<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;A=
VT a=20
payload<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;s=
pecification.<BR>&gt;<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;B=
TW: The=20
&nbsp;ITU is keeping a list of codecs (Not only ITU-T<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;o=
nes) in=20
a table<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;t=
hat=20
&nbsp;describes their features.<BR>&gt;<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;R=
egards<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;R=
oni=20
Even<BR>&gt;<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-=
----Original=20
&nbsp;Message-----<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;F=
rom: <A=20
href=3D"dispatch-bounces@ietf.org">dispatch-bounces@ietf.org</A><BR>&gt; =

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[=
<A=20
href=3D"mailto:dispatch-bounces@ietf.org">mailto:dispatch-bounces@ietf.or=
g</A>]=20
&nbsp;On Behalf<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;O=
f Jason=20
Fischl<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;S=
ent:=20
Wednesday, May 27, 2009 2:18 AM<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;T=
o:=20
&nbsp;<A href=3D"dispatch@ietf.org">dispatch@ietf.org</A><BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;S=
ubject:=20
[dispatch] &nbsp;Proposal to form Internet Wideband<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;A=
udio=20
Codec WG<BR>&gt;<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;A=
ll,<BR>&gt;<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I=
 would=20
&nbsp;like to request agenda time inside the DISPATCH<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;m=
eeting=20
to propose<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;t=
he=20
&nbsp;formation of a new working group to define a Proposed<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;S=
tandard=20
&nbsp;wideband<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;a=
udio=20
codec.<BR>&gt;<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;T=
he text=20
of the proposal is below. Comments, &nbsp;questions, and<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;suggestions<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;w=
elcomed.<BR>&gt;<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;R=
egards,<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;J=
ason<BR>&gt;<BR>&gt;<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I=
nternet=20
&nbsp;Wideband Audio Codec (IWAC)<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;M=
ailing=20
Lists: TBD<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;C=
hairs:=20
TBD<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;A=
rea=20
&nbsp;Directorate: Real Time Applications (RAI)<BR>&gt;<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;P=
urpose:<BR>&gt;<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;T=
his new=20
&nbsp;working group would be chartered with the purpose<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;o=
f=20
collecting<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;e=
xpertise=20
&nbsp;within the IETF in order to review the design of<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;a=
udio=20
&nbsp;codecs<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;s=
pecifically=20
for use with the Internet. Unlike other SDOs,<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;t=
hese=20
&nbsp;codecs<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;w=
ould be=20
optimized for use on the Internet, and as much as<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;possible=20
choose<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;t=
echnology=20
that does not require paying patent &nbsp;royalties.<BR>&gt;<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;T=
he=20
Internet Low Bit Rate Codec (iLBC) &nbsp;work was done &nbsp;in<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;A=
VT but=20
it was felt<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;t=
hat=20
subsequent work should not be done in the AVT &nbsp;working<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;g=
roup.=20
This new<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;w=
orking=20
group will have as its primary purpose &nbsp;the<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;s=
tandardization=20
of a<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;m=
ulti-purpose=20
audio codec that can be used in &nbsp;various<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;s=
ituations=20
on the<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I=
nternet.=20
Some of the proposed &nbsp;Internet-specific<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;r=
equirements=20
include:<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*=
=20
scalable and adaptive bit &nbsp;rate;<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*=
=20
various sampling rate profiles from narrow-band to<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;super-wideband;<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*=
=20
scalable complexity;<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*=
 low=20
latency; and<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*=
=20
&nbsp;resilience to packet loss.<BR>&gt;<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;T=
here=20
are a number of wide-band capable &nbsp;codecs defined by<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;o=
ther=20
SDOs. For<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;i=
nstance,=20
G.722 is seeing adoption in &nbsp;Enterprise<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;a=
pplications=20
since it is<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;r=
elatively=20
simple and low-cost to &nbsp;deploy. However, it has a<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;h=
igh,=20
fixed<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;b=
itrate=20
and is not appropriate for &nbsp;mobile applications<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;w=
here=20
spectrum<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;e=
fficiency=20
is important or in consumer &nbsp;applications where<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;a=
vailable<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;b=
andwidth=20
is fluctuating or limited. G.722.2 &nbsp;(AMR-wideband)<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;h=
as been=20
adopted<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;b=
y the=20
3GPP as a wideband standard for &nbsp;mobile applications.<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;G=
.722.2=20
is<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;r=
elatively=20
high cost due to patent &nbsp;royalties and is seeing<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;m=
inimal<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;d=
eployments=20
outside of mobile handsets &nbsp;making it<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;c=
hallenging=20
to create<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;w=
ideband=20
experiences on Internet-capable &nbsp;mobile devices<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;w=
hen=20
extending<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;b=
eyond=20
the mobile network. In other cases, &nbsp;proprietary<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;c=
odecs=20
are being<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;a=
dopted=20
which further create islands with no<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;interoperability=20
unless<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;w=
idespread=20
transcoding is performed. Transcoding &nbsp;leads to<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;h=
igher=20
costs and<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;l=
ower=20
quality.<BR>&gt;<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;T=
he goal=20
of this working &nbsp;group is to define a single codec<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;w=
ith=20
multiple<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;p=
rofiles=20
which can be &nbsp;made available on a wide variety of<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I=
nternet-capable<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;d=
evices=20
including &nbsp;low-power, mobile devices as well as<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;d=
evices=20
capable of<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;u=
tilizing=20
high &nbsp;quality, high bitrate audio.<BR>&gt;<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;P=
roposed=20
Deliverables:<BR>&gt;<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1=
)=20
&nbsp;Requirements for wideband, Internet audio codec(s).<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2=
)=20
Algorithm &nbsp;description for wideband, Internet audio<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;c=
odec(s)=20
as &nbsp;Proposed<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;S=
tandard.<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3=
)=20
Specification of payload format(s) for defined &nbsp;codecs as<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;Proposed<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;S=
tandard<BR>&gt;<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;_=
______________________________________________<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;d=
ispatch=20
&nbsp;mailing list<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<=
A=20
href=3D"dispatch@ietf.org">dispatch@ietf.org</A><BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<=
A=20
href=3D"https://www.ietf.org/mailman/listinfo/dispatch">https://www.ietf.=
org/mailman/listinfo/dispatch</A><BR>&gt;<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;_=
______________________________________________<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;d=
ispatch=20
&nbsp;mailing list<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<=
A=20
href=3D"dispatch@ietf.org">dispatch@ietf.org</A><BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<=
A=20
href=3D"https://www.ietf.org/mailman/listinfo/dispatch">https://www.ietf.=
org/mailman/listinfo/dispatch</A><BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;<BR>&gt;<BR>&gt; =

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;_________________________=
______________________<BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;dispatch mailing=20
&nbsp;list<BR>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<A=20
href=3D"dispatch@ietf.org">dispatch@ietf.org</A><BR>&gt;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<A=20
href=3D"https://www.ietf.org/mailman/listinfo/dispatch">https://www.ietf.=
org/mailman/listinfo/dispatch</A><BR>&gt;<BR>&gt;<BR>&gt;=20
------------------------------------------------------------------------<=
BR>&gt;<BR>&gt;=20
_______________________________________________<BR>&gt; dispatch mailing =

list<BR>&gt; <A href=3D"dispatch@ietf.org">dispatch@ietf.org</A><BR>&gt; =
<A=20
href=3D"https://www.ietf.org/mailman/listinfo/dispatch">https://www.ietf.=
org/mailman/listinfo/dispatch</A><BR>____________________________________=
___________<BR>dispatch=20
mailing list<BR><A =
href=3D"dispatch@ietf.org">dispatch@ietf.org</A><BR><A=20
href=3D"https://www.ietf.org/mailman/listinfo/dispatch">https://www.ietf.=
org/mailman/listinfo/dispatch</A></SPAN><o:p></o:p></P></DIV></BODY></HTM=
L>

------_=_NextPart_001_01C9E08C.1849A2A6--

From gonzalo.camarillo@ericsson.com  Fri May 29 23:16:17 2009
Return-Path: <gonzalo.camarillo@ericsson.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE5433A67F8 for <dispatch@core3.amsl.com>; Fri, 29 May 2009 23:16:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.504
X-Spam-Level: 
X-Spam-Status: No, score=-5.504 tagged_above=-999 required=5 tests=[AWL=0.745,  BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 rauC4UXwjLAX for <dispatch@core3.amsl.com>; Fri, 29 May 2009 23:16:16 -0700 (PDT)
Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 86ED43A69CE for <dispatch@ietf.org>; Fri, 29 May 2009 23:16:04 -0700 (PDT)
X-AuditID: c1b4fb3c-b7b28ae000005484-ed-4a20cf8a7181
Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 61.6B.21636.A8FC02A4; Sat, 30 May 2009 08:17:47 +0200 (CEST)
Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Sat, 30 May 2009 08:17:46 +0200
Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830);  Sat, 30 May 2009 08:17:46 +0200
Received: from [131.160.126.232] (rvi2-126-232.lmf.ericsson.se [131.160.126.232]) by mail.lmf.ericsson.se (Postfix) with ESMTP id E4D4D245E; Sat, 30 May 2009 09:17:45 +0300 (EEST)
Message-ID: <4A20CF89.80003@ericsson.com>
Date: Sat, 30 May 2009 09:17:45 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: Roni Even <ron.even.tlv@gmail.com>
References: <C641C6CE.D74E%jason.fischl@skype.net> <4a1ea3e2.0aaa660a.0cc2.18d4@mx.google.com>
In-Reply-To: <4a1ea3e2.0aaa660a.0cc2.18d4@mx.google.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 30 May 2009 06:17:46.0221 (UTC) FILETIME=[5952D9D0:01C9E0EE]
X-Brightmail-Tracker: AAAAAA==
Cc: dispatch@ietf.org
Subject: Re: [dispatch] Proposal to form Internet Wideband Audio Codec WG
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 May 2009 06:16:17 -0000

Hi,

I think Roni touches upon an important point here. The first question we 
need to answer (not only for this proposal; for any proposal) is whether 
or not the IETF in general and RAI in particular have the expertise to 
do this or at least review it when it is done. Comments?

Cheers,

Gonzalo

Roni Even wrote:
> Hi,
> Like you mention other SDOs like ITU-T are doing just that. They have the
> expertise to specify, and evaluate the result. These SDOs can receive
> requirements and select a proper codec based on the requirements.
> 
> 
> As for the other reasons:
> 
> 1. Defining a codec in the IETF or even in MPEG / ITU-T does not make it a
> mandatory part of a system solution, this is done by other standard bodies
> like 3GPP, ETSI.
> 
> 2. The IETF, similar to other standard bodies is not rubber stamping a
> specific solution, so you will most probably see in the final result some
> technology that carry IPR.
> 
> 3. If this group will be established, you will probably see here the audio
> experts now working in ITU-T arguing the same issues since they are the
> expertise you need and they work for the same companies that are already
> members of IETF. 
> 
> I think that if you have a specific codec in mind you  can make it publicly
> available maybe with quality results and standardized in AVT a payload
> specification.
> 
> BTW: The ITU is keeping a list of codecs (Not only ITU-T ones) in a table
> that describes their features. 
> 
> Regards
> Roni Even
> 
> -----Original Message-----
> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf
> Of Jason Fischl
> Sent: Wednesday, May 27, 2009 2:18 AM
> To: dispatch@ietf.org
> Subject: [dispatch] Proposal to form Internet Wideband Audio Codec WG
> 
> All,
> 
> I would like to request agenda time inside the DISPATCH meeting to propose
> the formation of a new working group to define a Proposed Standard wideband
> audio codec.
> 
> The text of the proposal is below. Comments, questions, and suggestions
> welcomed.
> 
> Regards, 
> Jason
> 
> 
> Internet Wideband Audio Codec (IWAC)
> Mailing Lists: TBD
> Chairs: TBD
> Area Directorate: Real Time Applications (RAI)
> 
> Purpose:
> 
> This new working group would be chartered with the purpose of collecting
> expertise within the IETF in order to review the design of audio codecs
> specifically for use with the Internet. Unlike other SDOs, these codecs
> would be optimized for use on the Internet, and as much as possible choose
> technology that does not require paying patent royalties.
> 
> The Internet Low Bit Rate Codec (iLBC)  work was done in AVT but it was felt
> that subsequent work should not be done in the AVT working group. This new
> working group will have as its primary purpose the standardization of a
> multi-purpose audio codec that can be used in various situations on the
> Internet. Some of the proposed Internet-specific requirements include:
> * scalable and adaptive bit rate;
> * various sampling rate profiles from narrow-band to super-wideband;
> * scalable complexity;
> * low latency; and 
> * resilience to packet loss.
> 
> There are a number of wide-band capable codecs defined by other SDOs. For
> instance, G.722 is seeing adoption in Enterprise applications since it is
> relatively simple and low-cost to deploy. However, it has a high, fixed
> bitrate and is not appropriate for mobile applications where spectrum
> efficiency is important or in consumer applications where available
> bandwidth is fluctuating or limited. G.722.2 (AMR-wideband) has been adopted
> by the 3GPP as a wideband standard for mobile applications. G.722.2 is
> relatively high cost due to patent royalties and is seeing minimal
> deployments outside of mobile handsets making it challenging to create
> wideband experiences on Internet-capable mobile devices when extending
> beyond the mobile network. In other cases, proprietary codecs are being
> adopted which further create islands with no interoperability unless
> widespread transcoding is performed. Transcoding leads to higher costs and
> lower quality. 
> 
> The goal of this working group is to define a single codec with multiple
> profiles which can be made available on a wide variety of Internet-capable
> devices including low-power, mobile devices as well as devices capable of
> utilizing high quality, high bitrate audio.
> 
> Proposed Deliverables:
> 
> 1) Requirements for wideband, Internet audio codec(s).
> 2) Algorithm description for wideband, Internet audio codec(s) as Proposed
> Standard. 
> 3) Specification of payload format(s) for defined codecs as Proposed
> Standard
> 
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
> 
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>