From dworley@nortel.com Mon Jun 1 11:56:57 2009 Return-Path: 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 AC0FB3A6E5B for ; Mon, 1 Jun 2009 11:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 0W00q+u4+OxT for ; Mon, 1 Jun 2009 11:56:57 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id BE95D3A6813 for ; Mon, 1 Jun 2009 11:56:56 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n51ItdG06121; Mon, 1 Jun 2009 18:55:39 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Jun 2009 14:56:51 -0400 From: "Dale Worley" To: Christer Holmberg In-Reply-To: References: <9A1E3501-4871-48B3-B39A-80E8E167F4A5@softarmor.com> Content-Type: text/plain Organization: Nortel Networks Date: Mon, 01 Jun 2009 14:56:50 -0400 Message-Id: <1243882610.3743.50.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: 01 Jun 2009 18:56:51.0868 (UTC) FILETIME=[B9788DC0:01C9E2EA] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2009 18:56:57 -0000 On Thu, 2009-05-28 at 08:53 +0200, Christer Holmberg wrote: > 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. That last phrase is key, and isn't something that's mentioned very clearly in the draft. That is, that once the criteria are established, the "answer" may change with time and that the CBUS server is expected to dynamically revise its answer. Dale From mramalho@cisco.com Mon Jun 1 14:18:33 2009 Return-Path: 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 F1F623A6B9A for ; Mon, 1 Jun 2009 14:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jrEQGzwTyqg for ; Mon, 1 Jun 2009 14:18:25 -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 E29F83A692E for ; Mon, 1 Jun 2009 14:18:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,286,1241395200"; d="scan'208,217";a="45794809" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 01 Jun 2009 21:18:24 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n51LIORu008407 for ; Mon, 1 Jun 2009 17:18:24 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n51LIO3O029964 for ; Mon, 1 Jun 2009 21:18:24 GMT Received: from xmb-rtp-219.amer.cisco.com ([64.102.31.101]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Jun 2009 17:18:24 -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_01C9E2FE.7F85F402" Date: Mon, 1 Jun 2009 17:18:47 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF "Royalty-Free" codecs Thread-Index: Acni/oz+T97fyHVwSuKgma6uS9Zeqg== X-Priority: 5 Priority: Non-Urgent Importance: low From: "Michael Ramalho (mramalho)" To: X-OriginalArrivalTime: 01 Jun 2009 21:18:24.0728 (UTC) FILETIME=[7F9C2580:01C9E2FE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=24760; t=1243891104; x=1244755104; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mramalho@cisco.com; z=From:=20=22Michael=20Ramalho=20(mramalho)=22=20 |Subject:=20IETF=20=22Royalty-Free=22=20codecs |Sender:=20 |To:=20; bh=I5yyf7XQnGwFWzlwgxYMQOF/J51LLTlmGEyt97mGRWc=; b=XvJFhG+qWuECiXcIFTTQJ+qf6qhKKi9dfGGkefjcYqHh+CGhFzEdhhWdZj Il+erb8ZELPxBpxacULSZuUkIoEWLgrcV+Cr1MOAKYcVsvInJyAbouqXxO3P DVt87lSleu; Authentication-Results: rtp-dkim-1; header.From=mramalho@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Mailman-Approved-At: Mon, 01 Jun 2009 14:23:10 -0700 Subject: [dispatch] IETF "Royalty-Free" codecs X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2009 21:18:34 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9E2FE.7F85F402 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable All,=20 =20 I have read, with some interest and comment, Jason Fischl's email proposing a working group for codec development that would produce a "royalty-free" codec designed "specifically for the Internet". =20 While one cannot always know if there is IPR "lurking" in something that someone has built (i.e., an "unknowing" infringement on a 3rd party right), the goal of designing a codec with "old or otherwise unencumbered" technology is an idea worth pursuing. =20 I do note, as Roni Even did, that most of the of the "codec expertise" resides in other SDO groups (such as ITU-T SG16, and ETSI). Most of those subject matter experts are represented by companies that also participate in the IEFT. =20 I also remember that AVT has been down this road before with iLBC (the result being an EXPERIMENTAL RFC - not a standards track RFC). =20 However, I have explicitly noted that other SDO groups such as ITU-T SG16 have NO APPARENT INTEREST in developing a "royalty-free" designs. In my observation the ITU-T SG16 tends to focus on bringing the "best technology" from participating members to create a codec that meets a given goal (specified by a Terms of Reference, ToR, document). Since the requirements are written from the perspective of what "new technology can do", they have the tendency to rule out "old/known/existing" technology. =20 Thus, it doesn't appear to me that the ITU-T or similar groups would even strive to have a goal of "royalty-free" as a codec design criteria. And that is OK, given the way they operate. They produce high-quality results for the work they perform. =20 Additionally, some SDOs explicitly request that "royalty", or "royalty-free" statements NOT be made at their meetings except in a narrow-context of what their company position is given the SDOs IPR policy. In other words, detailed discussion of the IPR dimensions of the work are not to be discussed when developing the codec. =20 So given: =20 Given 1: There are a bunch of folks that desire to specify a codec that does not KNOWINGLY infringe on IPR/patents (perhaps by using "old or previously disclosed" technology), =20 Given 2: That no SDO organization that I know of that works on codec issues explicitly allows the discussion of specific IPR issues or "royalties" in their meetings, and =20 Given 3: That some IETF participants desire a codec that does not KNOWINGLY infringe on IPR and can be made "royalty-free" (except for potentially lurking IPR). =20 The questions (for me) become: =20 Question 1: Where is such work to be performed? =20 Corollary Question 1: Does anyone know of a SDO that would allow for the criteria of "no known IPR" in the design? =20 Question 2: Assuming that the IETF would allow such a "royalty-free" criteria and that this work COULD be performed here, are there enough "qualified people" in the IETF to perform such work? =20 I don't know the answers to the above, but I would be interested in this work. =20 Regardds, =20 Michael A. Ramalho, Ph.D. =20 =20 All, =20 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. =20 The text of the proposal is below. Comments, questions, and suggestions welcomed. =20 Regards,=20 Jason =20 =20 Internet Wideband Audio Codec (IWAC) Mailing Lists: TBD Chairs: TBD Area Directorate: Real Time Applications (RAI) =20 Purpose: =20 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. =20 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=20 * resilience to packet loss. =20 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.=20 =20 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. =20 Proposed Deliverables: =20 1) Requirements for wideband, Internet audio codec(s). 2) Algorithm description for wideband, Internet audio codec(s) as Proposed Standard.=20 3) Specification of payload format(s) for defined codecs as Proposed Standard =20 ------_=_NextPart_001_01C9E2FE.7F85F402 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

All,

 

I have read, with some interest and comment, Jason = Fischl’s email proposing a working group for codec development that would produce = a “royalty-free” codec designed “specifically for the = Internet”.

 

While one cannot always know if there is IPR = “lurking” in something that someone has built (i.e., an “unknowing” infringement on a 3rd party right), the goal of designing a = codec with “old or otherwise unencumbered” technology is an idea = worth pursuing.

 

I do note, as Roni Even did, that most of the of = the “codec expertise” resides in other SDO groups (such as ITU-T SG16, and = ETSI). Most of those subject matter experts are represented by companies that = also participate in the IEFT.

 

I also remember that AVT has been down this road = before with iLBC (the result being an EXPERIMENTAL RFC  - not a standards track = RFC).

 

However, I have explicitly noted that other SDO = groups such as ITU-T SG16 have NO APPARENT INTEREST in developing a = “royalty-free” designs. In my observation the ITU-T SG16 tends to focus on bringing the = “best technology” from participating members to create a codec that = meets a given goal (specified by a Terms of Reference, ToR, document). Since the = requirements are written from the perspective of what “new technology can = do”, they have the tendency to rule out “old/known/existing” = technology.

 

Thus, it doesn’t appear to me that the ITU-T = or similar groups would even strive to have a goal of = “royalty-free” as a codec design criteria.  And that is OK, given the way they = operate. They produce high-quality results for the work they = perform.

 

Additionally, some SDOs explicitly request that =  “royalty”, or “royalty-free” statements NOT be made at their meetings = except in a narrow-context of what their company position is given the SDOs IPR = policy. In other words, detailed discussion of the IPR dimensions of the work = are not to be discussed when developing the codec.

 

So  given:

 

Given 1: There are a bunch of folks that desire to = specify a codec that does not KNOWINGLY infringe on IPR/patents (perhaps by using = “old or previously disclosed” technology),

 

Given 2: That no SDO organization that I know of = that works on codec issues explicitly allows the discussion of specific IPR issues = or “royalties” in their meetings, and

 

Given 3: That some IETF participants desire a codec = that does not KNOWINGLY infringe on IPR and can be made = “royalty-free” (except for potentially lurking IPR).

 

The questions (for me) become:

 

Question 1: Where is such work to be = performed?

 

Corollary Question 1: Does anyone know of a SDO = that would allow for the criteria of “no known IPR” in the = design?

 

Question 2: Assuming that the IETF would allow such = a “royalty-free” criteria and that this work COULD be performed here, are there enough = “qualified people” in the IETF to perform such work?

 

I don’t know the answers to the above, but I = would be interested in this work.

 

Regardds,

 

Michael A. Ramalho, Ph.D.

 

<Jason’s initial email on dispatch@ietf.org follows>

 

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

 

------_=_NextPart_001_01C9E2FE.7F85F402-- From root@core3.amsl.com Mon Jun 1 11:00:01 2009 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id EEC8C3A6BDF; Mon, 1 Jun 2009 11: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: <20090601180001.EEC8C3A6BDF@core3.amsl.com> Date: Mon, 1 Jun 2009 11:00:01 -0700 (PDT) X-Mailman-Approved-At: Mon, 01 Jun 2009 14:23:17 -0700 Cc: dispatch@ietf.org Subject: [dispatch] I-D Action:draft-ietf-sip-outbound-19.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2009 18: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-19.txt Pages : 49 Date : 2009-06-01 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-19.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-19.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-06-01105004.I-D@ietf.org> --NextPart-- From eburger@standardstrack.com Mon Jun 1 15:02:32 2009 Return-Path: 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 2359C3A6A4F for ; Mon, 1 Jun 2009 15:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.144 X-Spam-Level: X-Spam-Status: No, score=-0.144 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_ADOBE2=2.455] 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 FJDTe6MIfWw4 for ; Mon, 1 Jun 2009 15:02:31 -0700 (PDT) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id E6B3B3A69AB for ; Mon, 1 Jun 2009 15:02:30 -0700 (PDT) Received: from 224.sub-97-22-24.myvzw.com ([97.22.24.224]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1MBFaF-0001zx-5i; Mon, 01 Jun 2009 15:02:22 -0700 Message-Id: <5B65DEDD-2877-41A3-9311-2BD93E39B510@standardstrack.com> From: Eric Burger To: Henry Sinnreich In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-264--701429739; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 1 Jun 2009 18:02:22 -0400 References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2009 22:02:32 -0000 --Apple-Mail-264--701429739 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I again have to point out, as I did with iLBC, that just because something is Open Source and submitted Without IPR and, as proposed here, done in a non-IPR regime, does NOT necessarily mean the result is without encumbrances. Since I like to keep people away from trouble, I won't quote existing IPR. Let's look at some expired IPR instead. If your proposed codec used LPC, it would violate a Philips patent. For that matter, it would step on a handful of TI patents. I would guess (but I have NOT done a search), if the proposed codec used FFT, DCT, physiological modeling, filtering, etc., it would step on a handful of patents. I would offer the math work for developing a codec is something outside the IETF area of expertise. I suppose it is right and proper to ask the question, as to counter Joel's take-it-to-the-logical- conclusion the IETF should do everything (not), one could ask if the IETF should not ever do anything new (I would offer: not). I would also offer the protocol work for such a codec is something the IETF really, really should do. If that work is somehow different than the AVT work, for example, if such a codec required a transport that RTP/SRTP cannot provide, then a new work group would be in order. My vote is the IETF does not have the expertise to do the math part. My vote is the IETF has the best expertise for the protocol part. On May 29, 2009, at 11:45 AM, 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" > 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 > > To: Roni Even ; Jason 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" 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 --Apple-Mail-264--701429739 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 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA2MDEyMjAyMjJaMCMGCSqGSIb3 DQEJBDEWBBSya4XJvDguErTw62+rxW/6KT9SZDCB1AYJKwYBBAGCNxAEMYHGMIHDMIGuMQswCQYD VQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVU aGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhAv lStUS1saxfCiWQ0fZPKfMIHWBgsqhkiG9w0BCRACCzGBxqCBwzCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkN H2TynzANBgkqhkiG9w0BAQEFAASCAQASyxZt6nUGyBN0izLgFClWpQ2g2PAOB2kGDyoDll7ljRd/ 7dwr2akbdA5pXVRcWUGBhrIF/HnbSC0MUstNZSNsSevQZbLg0SZTGpD4fEVOfn8fBDv/iM2+6X/a HfwxJ/jYWnU9YcyLYCQQ9uMYcVJdZRl67ZmdJPOLBYyjabA3xa9WvZzxHT5P6ShreQgkFQ7tX/gc YBmB9pX0576BMv3O6gxGbjd68EEjfwBZE13LGxx6qxDYpP2IX84zpns/xTCRLNqJuydIp0rNQ1LY H9Rnz1Ga3z0350/gJXWM1TUxSL3/HZPNqbL8jfQPlBkO5RS1G000nNZ4mPqBFPLw1YqwAAAAAAAA --Apple-Mail-264--701429739-- From fluffy@cisco.com Mon Jun 1 17:12:27 2009 Return-Path: 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 5809C3A6802 for ; Mon, 1 Jun 2009 17:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25mi7YSBCC2q for ; Mon, 1 Jun 2009 17:12:26 -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 733D93A67FE for ; Mon, 1 Jun 2009 17:12:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,287,1241395200"; d="scan'208";a="314620202" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 02 Jun 2009 00:12:12 +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 n520CCj5018951; Mon, 1 Jun 2009 17:12:12 -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 n520CBta012254; Tue, 2 Jun 2009 00:12:12 GMT From: Cullen Jennings To: Eric Burger In-Reply-To: <5B65DEDD-2877-41A3-9311-2BD93E39B510@standardstrack.com> Impp: xmpp:cullenfluffyjennings@jabber.org References: <5B65DEDD-2877-41A3-9311-2BD93E39B510@standardstrack.com> Message-Id: 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: Mon, 1 Jun 2009 18:12:11 -0600 X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=734; t=1243901532; x=1244765532; 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 |Subject:=20Re=3A=20[dispatch]=20Proposal=20to=20form=20Int ernet=20Wideband=20Audio=20Codec=20WG |Sender:=20; bh=ywKTBmA04hAi1Am4a+TngcUJteRhyzDSW3+6BTOaufo=; b=acI8C24c6B1ESrEbM1X+bsTQ6gK+0ekLCVAr0LCav52XttYwAT9QEgYsOn GRdWhv6FPCvqVEC2DYOCaTjey27IxgOkYaBrTh4pmltVJ/c2uglhz3ZtGRSG MOSaV4vMHz; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: Henry Sinnreich , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 00:12:27 -0000 On Jun 1, 2009, at 4:02 PM, Eric Burger wrote: > I again have to point out, as I did with iLBC, that just because > something is Open Source and submitted Without IPR and, as proposed > here, done in a non-IPR regime, does NOT necessarily mean the result > is without encumbrances. > > Since I like to keep people away from trouble, I won't quote > existing IPR. Let's look at some expired IPR instead. > > If your proposed codec used LPC, it would violate a Philips patent. > For that matter, it would step on a handful of TI patents. That's an interesting assertion given LPC was published in the late 60's and research goes back earlier than that. Would you like to comment on "valid patents" :-) From SRS0=/b51WB=B5=standardstrack.com=eburger@srs.bis.na.blackberry.com Mon Jun 1 17:20:23 2009 Return-Path: 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 179563A6D73 for ; Mon, 1 Jun 2009 17:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_AUTODESK=1, 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 WcyyOlJr6TNr for ; Mon, 1 Jun 2009 17:20:22 -0700 (PDT) Received: from smtp12.bis.na.blackberry.com (smtp12.bis.na.blackberry.com [216.9.248.26]) by core3.amsl.com (Postfix) with ESMTP id 131743A6E95 for ; Mon, 1 Jun 2009 17:19:40 -0700 (PDT) Received: from bda380.bisx.prod.on.blackberry (bda380.bisx.prod.on.blackberry [172.20.234.80]) by srs.bis.na.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id n520KESo030445; Tue, 2 Jun 2009 00:20:14 GMT Received: from bda380.bisx.prod.on.blackberry (localhost.localdomain [127.0.0.1]) by bda380.bisx.prod.on.blackberry (8.13.7 TEAMON/8.13.7) with ESMTP id n520JaId025175; Tue, 2 Jun 2009 00:19:36 GMT X-rim-org-msg-ref-id: 1992243646 Message-ID: <1992243646-1243901975-cardhu_decombobulator_blackberry.rim.net-467117812-@bxe1059.bisx.prod.on.blackberry> Content-Transfer-Encoding: base64 X-Priority: Normal Sensitivity: Normal Importance: Normal To: "Cullen Jennings" From: "eburger" Date: Tue, 2 Jun 2009 00:19:38 +0000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 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 Reply-To: eburger@standardstrack.com List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 00:22:19 -0000 SSwgb2YgY291cnNlLCB3b3VsZCBuZXZlciBlbHVjaWRhdGUgb24gdGhlIGV4aXN0ZW5jZSBvciB2 YWxpZGl0eSBvZiBhbnkgZ2l2ZW4gcGF0ZW50IGluIGFuIG9wZW4gZm9ydW0gOy0pDQoNCkdldCBh IHJlYWwgbGF3eWVyIHRvIHBvaW50IGF0IHdoYXRldmVyIGFpbHMgeW91LiANCg0KUmVtZW1iZXIs IGEgbm92ZWwgdXNlIGZvciBzb21ldGhpbmcgb2xkIGNhbiBiZSBub3ZlbC4gQW5vdGhlciBleHBp cmVkIG9uZSBpcyBYT1IgKHByb2JhYmx5IGFuY2llbnQgR3JlZWtzKSBhcyBwcmlvciBhcnQgdG8g dGhlIEF1dG9kZXNrICJzZWUgeW91ciBjdXJzb3Igb3ZlciB0aGUgZGFyayBzcG90cyBvbiB0aGUg ZGlzcGxheSIsIGEuay5hLiBYT1IgcGF0ZW50LiANCi0tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LS0NCkZyb206IEN1bGxlbiBKZW5uaW5ncw0KVG86IEVyaWMgQnVyZ2VyDQpDYzogSGVucnkgU2lu bnJlaWNoDQpDYzogZGlzcGF0Y2hAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbZGlzcGF0Y2hdIFBy b3Bvc2FsIHRvIGZvcm0gSW50ZXJuZXQgV2lkZWJhbmQgQXVkaW8gQ29kZWMgV0cNClNlbnQ6IEp1 biAxLCAyMDA5IDg6MTIgUE0NCg0KDQpPbiBKdW4gMSwgMjAwOSwgYXQgNDowMiBQTSwgRXJpYyBC dXJnZXIgd3JvdGU6DQoNCj4gSSBhZ2FpbiBoYXZlIHRvIHBvaW50IG91dCwgYXMgSSBkaWQgd2l0 aCBpTEJDLCB0aGF0IGp1c3QgYmVjYXVzZSAgDQo+IHNvbWV0aGluZyBpcyBPcGVuIFNvdXJjZSBh bmQgc3VibWl0dGVkIFdpdGhvdXQgSVBSIGFuZCwgYXMgcHJvcG9zZWQgIA0KPiBoZXJlLCBkb25l IGluIGEgbm9uLUlQUiByZWdpbWUsIGRvZXMgTk9UIG5lY2Vzc2FyaWx5IG1lYW4gdGhlIHJlc3Vs dCAgDQo+IGlzIHdpdGhvdXQgZW5jdW1icmFuY2VzLg0KPg0KPiBTaW5jZSBJIGxpa2UgdG8ga2Vl cCBwZW9wbGUgYXdheSBmcm9tIHRyb3VibGUsIEkgd29uJ3QgcXVvdGUgIA0KPiBleGlzdGluZyBJ UFIuIExldCdzIGxvb2sgYXQgc29tZSBleHBpcmVkIElQUiBpbnN0ZWFkLg0KPg0KPiBJZiB5b3Vy IHByb3Bvc2VkIGNvZGVjIHVzZWQgTFBDLCBpdCB3b3VsZCB2aW9sYXRlIGEgUGhpbGlwcyBwYXRl bnQuICANCj4gRm9yIHRoYXQgbWF0dGVyLCBpdCB3b3VsZCBzdGVwIG9uIGEgaGFuZGZ1bCBvZiBU SSBwYXRlbnRzLg0KDQpUaGF0J3MgYW4gaW50ZXJlc3RpbmcgYXNzZXJ0aW9uIGdpdmVuIExQQyB3 YXMgcHVibGlzaGVkIGluIHRoZSBsYXRlICANCjYwJ3MgYW5kIHJlc2VhcmNoIGdvZXMgYmFjayBl YXJsaWVyIHRoYW4gdGhhdC4gV291bGQgeW91IGxpa2UgdG8gIA0KY29tbWVudCBvbiAidmFsaWQg cGF0ZW50cyIgOi0pDQoNCg0KDQoNCi0tDQpFcmljIEJ1cmdlcg0KDQpTZW50IGZyb20gbXkgbW9i aWxlIGRldmljZTsgc29ycnkgaWYgdGVyc2UuIEFsbCBtb2JpbGUgdXNlcnMgbmVlZCBsZW1vbmFk ZS4gIFNlZSA8aHR0cDovL3d3dy5zdGFuZGFyZHN0cmFjay5jb20vaWV0Zi9sZW1vbmFkZT4gZm9y IG1vcmUgaW5mb3JtYXRpb24u From ron.even.tlv@gmail.com Mon Jun 1 22:27:07 2009 Return-Path: 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 E8F7828C155 for ; Mon, 1 Jun 2009 22:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.619] 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 twUSX1qrj0BA for ; Mon, 1 Jun 2009 22:26:58 -0700 (PDT) Received: from mail-fx0-f216.google.com (mail-fx0-f216.google.com [209.85.220.216]) by core3.amsl.com (Postfix) with ESMTP id CAAF928C118 for ; Mon, 1 Jun 2009 22:26:57 -0700 (PDT) Received: by fxm12 with SMTP id 12so6230683fxm.37 for ; Mon, 01 Jun 2009 22:26:56 -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=WvklXu4UpdEccAY8udcHAVIIlxp2wWl9e5AQ3jqOV5k=; b=eYu8A6ZLWh6Qm46ykaguzDrf2k5SjPo3dwu6uvGHAxw6fGnPE7TO45rrz1uDLeY59V 9luxmWA2K0NdwHudK/cXkzZtMatq0qhPNeJON+7y112pqMLoKHDqx391LBcgxzWjPIJ5 Nf9LAoqr2vHf6gburkHjbnvYUm0Lm0FzzzC+8= 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=hSceelLDdTbYOAdunNdGkvdTIGXLnZVeLShUzULGnKdmUuqxhPta1aOPWY/mFZnk3q +bCq5GX+PVfFrrz1YwVp8DtxG4aD/HtkBLoFJR17Q4IK/61jwh7MzOKILimlxTD7yCqi B2TKgFJuWbgO2M/ISESWFt1JWqVfiHPZDbOFU= Received: by 10.86.82.17 with SMTP id f17mr7456549fgb.65.1243920416374; Mon, 01 Jun 2009 22:26:56 -0700 (PDT) Received: from windows8d787f9 (bzq-79-180-78-211.red.bezeqint.net [79.180.78.211]) by mx.google.com with ESMTPS id 3sm1101530fge.9.2009.06.01.22.26.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 01 Jun 2009 22:26:55 -0700 (PDT) From: "Roni Even" To: "'Michael Ramalho \(mramalho\)'" , References: In-Reply-To: Date: Tue, 2 Jun 2009 08:25:51 +0300 Message-ID: <4a24b81f.0305560a.26e5.21dd@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007F_01C9E35B.C18BBF20" X-Mailer: Microsoft Office Outlook 12.0 thread-index: Acni/oz+T97fyHVwSuKgma6uS9ZeqgAQCldA Content-Language: en-us Subject: Re: [dispatch] IETF "Royalty-Free" codecs X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 05:27:08 -0000 This is a multipart message in MIME format. ------=_NextPart_000_007F_01C9E35B.C18BBF20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Michael, I think your observation is valid. As a matter of fact even at the ITU some companies wanted to have "royalty free" codecs and as far as I know some of the audio codecs like G.722.1C are royalty free. (I am not sure about your ITU WP3 work) I think that you cannot write as part of the term of reference (or charter) that the codec must be "royalty free" since this is a business decision for the technology contributor and not a technical one and will probably be against some of the competition laws in some countries. Roni Even From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Michael Ramalho (mramalho) Sent: Tuesday, June 02, 2009 12:19 AM To: dispatch@ietf.org Subject: [dispatch] IETF "Royalty-Free" codecs Importance: Low All, I have read, with some interest and comment, Jason Fischl's email proposing a working group for codec development that would produce a "royalty-free" codec designed "specifically for the Internet". While one cannot always know if there is IPR "lurking" in something that someone has built (i.e., an "unknowing" infringement on a 3rd party right), the goal of designing a codec with "old or otherwise unencumbered" technology is an idea worth pursuing. I do note, as Roni Even did, that most of the of the "codec expertise" resides in other SDO groups (such as ITU-T SG16, and ETSI). Most of those subject matter experts are represented by companies that also participate in the IEFT. I also remember that AVT has been down this road before with iLBC (the result being an EXPERIMENTAL RFC - not a standards track RFC). However, I have explicitly noted that other SDO groups such as ITU-T SG16 have NO APPARENT INTEREST in developing a "royalty-free" designs. In my observation the ITU-T SG16 tends to focus on bringing the "best technology" from participating members to create a codec that meets a given goal (specified by a Terms of Reference, ToR, document). Since the requirements are written from the perspective of what "new technology can do", they have the tendency to rule out "old/known/existing" technology. Thus, it doesn't appear to me that the ITU-T or similar groups would even strive to have a goal of "royalty-free" as a codec design criteria. And that is OK, given the way they operate. They produce high-quality results for the work they perform. Additionally, some SDOs explicitly request that "royalty", or "royalty-free" statements NOT be made at their meetings except in a narrow-context of what their company position is given the SDOs IPR policy. In other words, detailed discussion of the IPR dimensions of the work are not to be discussed when developing the codec. So given: Given 1: There are a bunch of folks that desire to specify a codec that does not KNOWINGLY infringe on IPR/patents (perhaps by using "old or previously disclosed" technology), Given 2: That no SDO organization that I know of that works on codec issues explicitly allows the discussion of specific IPR issues or "royalties" in their meetings, and Given 3: That some IETF participants desire a codec that does not KNOWINGLY infringe on IPR and can be made "royalty-free" (except for potentially lurking IPR). The questions (for me) become: Question 1: Where is such work to be performed? Corollary Question 1: Does anyone know of a SDO that would allow for the criteria of "no known IPR" in the design? Question 2: Assuming that the IETF would allow such a "royalty-free" criteria and that this work COULD be performed here, are there enough "qualified people" in the IETF to perform such work? I don't know the answers to the above, but I would be interested in this work. Regardds, Michael A. Ramalho, Ph.D. 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 ------=_NextPart_000_007F_01C9E35B.C18BBF20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Michael,

I think your = observation is valid. As a matter of fact even at the ITU some companies wanted to have = "royalty free" codecs and as far as I know some of the audio codecs like = G.722.1C are royalty free.  (I am not sure about your ITU WP3 = work)

I think that you = cannot write as part of the term of reference (or charter) that the codec must be = "royalty free" since this is a business decision for the technology = contributor and not a technical one and will probably be against some of the competition = laws in some countries.

 

Roni = Even

 

 

 

From:= dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Michael Ramalho (mramalho)
Sent: Tuesday, June 02, 2009 12:19 AM
To: dispatch@ietf.org
Subject: [dispatch] IETF "Royalty-Free" codecs
Importance: Low

 

All,

 

I have read, with some interest and comment, Jason Fischl’s email proposing a working group for codec development = that would produce a “royalty-free” codec designed “specifically = for the Internet”.

 

While one cannot always know if there is IPR = “lurking” in something that someone has built (i.e., an “unknowing” infringement on a 3rd party right), the goal of designing a = codec with “old or otherwise unencumbered” technology is an idea = worth pursuing.

 

I do note, as Roni Even did, that most of the of = the “codec expertise” resides in other SDO groups (such as ITU-T = SG16, and ETSI). Most of those subject matter experts are represented by = companies that also participate in the IEFT.

 

I also remember that AVT has been down this road = before with iLBC (the result being an EXPERIMENTAL RFC  - not a standards track = RFC).

 

However, I have explicitly noted that other SDO = groups such as ITU-T SG16 have NO APPARENT INTEREST in developing a “royalty-free” designs. In my observation the ITU-T SG16 = tends to focus on bringing the “best technology” from participating = members to create a codec that meets a given goal (specified by a Terms of = Reference, ToR, document). Since the requirements are written from the perspective = of what “new technology can do”, they have the tendency to rule out “old/known/existing” technology.

 

Thus, it doesn’t appear to me that the ITU-T = or similar groups would even strive to have a goal of = “royalty-free” as a codec design criteria.  And that is OK, given the way they = operate. They produce high-quality results for the work they = perform.

 

Additionally, some SDOs explicitly request that  “royalty”, or “royalty-free” statements = NOT be made at their meetings except in a narrow-context of what their company position is given the SDOs IPR policy. In other words, detailed = discussion of the IPR dimensions of the work are not to be discussed when developing = the codec.

 

So  given:

 

Given 1: There are a bunch of folks that desire to = specify a codec that does not KNOWINGLY infringe on IPR/patents (perhaps by using “old or previously disclosed” technology),

 

Given 2: That no SDO organization that I know of = that works on codec issues explicitly allows the discussion of specific IPR issues = or “royalties” in their meetings, and

 

Given 3: That some IETF participants desire a codec = that does not KNOWINGLY infringe on IPR and can be made = “royalty-free” (except for potentially lurking IPR).

 

The questions (for me) become:

 

Question 1: Where is such work to be = performed?

 

Corollary Question 1: Does anyone know of a SDO = that would allow for the criteria of “no known IPR” in the = design?

 

Question 2: Assuming that the IETF would allow such = a “royalty-free” criteria and that this work COULD be = performed here, are there enough “qualified people” in the IETF to perform = such work?

 

I don’t know the answers to the above, but I = would be interested in this work.

 

Regardds,

 

Michael A. Ramalho, Ph.D.

 

<Jason’s initial email on dispatch@ietf.org follows>

 

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

 

------=_NextPart_000_007F_01C9E35B.C18BBF20-- From Borilin@spiritdsp.com Tue Jun 2 08:08:16 2009 Return-Path: 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 143AB28C257 for ; Tue, 2 Jun 2009 08:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.371 X-Spam-Level: X-Spam-Status: No, score=-1.371 tagged_above=-999 required=5 tests=[AWL=-1.228, 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 RwTcNwXEV4D7 for ; Tue, 2 Jun 2009 08:08:09 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id 11FA028C19B for ; Tue, 2 Jun 2009 08:08:08 -0700 (PDT) Received: from mail-srv.spiritcorp.com (mail-srv.spiritcorp.com [192.168.125.3]) by mail3.spiritcorp.com (8.13.8/8.14.3) with SMTP id n52F7Z2u063597; Tue, 2 Jun 2009 19:07:36 +0400 (MSD) (envelope-from Borilin@spiritdsp.com) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9E393.D8DC653C" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 2 Jun 2009 19:07:28 +0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Proposal to form Internet Wideband Audio Codec WG Thread-Index: AcnjPsupfF5mOurzS56CspyVx1UVAAASp85lAABC9mAAAk428A== References: <4A24B17A.5000408@ericsson.com> From: "Slava Borilin" To: "Roni Even" , "Jason Fischl" , "Mary Barnes" , "Peterson, Jon" , "Cullen Jennings" , "Gonzalo Camarillo" X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 X-Mailman-Approved-At: Tue, 02 Jun 2009 08:26:35 -0700 Cc: Henry Sinnreich , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 15:08:16 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9E393.D8DC653C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Gonzalo, =20 by "to convince them may be to have IETF people with knowledge in this area volunteer to work on this and review the results." Gonzalo means find IETF voluntiers to review the idea of the WG?" you mean to find the IETF people who will vounteers to review the idea of such Wideband WG? =20 regards, Slava Borilin =20 ------ Forwarded Message From: Gonzalo Camarillo Date: Mon, 1 Jun 2009 21:58:34 -0700 To: Adobe Systems Cc: Roni Even , Jason Fischl , Mary Barnes , "Peterson, Jon" , Cullen Jennings Subject: Re: [dispatch] Proposal to form Internet Wideband Audio Codec WG Hi Henry, given that some people on the list think that the IETF does not have that type of expertise, we need to have those list discussions so that the WG reaches consensus (one way or the other). It seems that when iLBC was developed, it was difficult to find IETF people to review it. That is probably why some people are hesitant about this. A way to convince them may be to have IETF people with knowledge in this area volunteer to work on this and review the results. Thanks, Gonzalo Henry Sinnreich wrote: > (list deleted) > > Gonzalo, > >>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? > > The folks from Skype driving this proposal have without any doubt the > best qualifications for building voice codecs, just as have many other > IETF AVT contributors, such as for the iLBC, SPEEX, IP-MR and other codecs. > > The pushback for the proposal for a WG for an Internet Audio Codec, is > quite amazing, especially the argument on available expertise. > (You certainly understand my arguments why the better expertise for an > _Internet_ codec is just in the IETF, and certainly not in the ITU-T, > ETSI, OMA, etc.). > > I don't plan therefore to participate any more in this discussion. > > Henry > > > On 5/30/09 1:17 AM, "Gonzalo Camarillo" > wrote: > > 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 > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > ------ End of Forwarded Message ------_=_NextPart_001_01C9E393.D8DC653C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FW: [dispatch] Proposal to form Internet Wideband = Audio Codec WG
Dear Gonzalo,
 
by "to convince=20 them may be to have IETF people with knowledge in this area volunteer = to
work=20 on this and review the results." Gonzalo means find IETF voluntiers to = review=20 the idea of the WG?"

you mean to find the IETF people who will vounteers = to review=20 the idea of such Wideband WG?
 
regards,
Slava Borilin
 
------ Forwarded Message
From: = Gonzalo=20 Camarillo <Gonzalo.Camarillo@ericsson.com>
Date:=20 Mon, 1 Jun 2009 21:58:34 -0700
To: Adobe Systems <hsinnrei@adobe.com>
Cc: = Roni Even=20 <ron.even.tlv@gmail.com>, = Jason=20 Fischl <jason.fischl@skype.net>, Mary=20 Barnes <mary.barnes@nortel.com>,=20 "Peterson, Jon" <jon.peterson@neustar.biz>, = Cullen=20 Jennings <fluffy@cisco.com>
Subject:=20 Re: [dispatch] Proposal to form Internet Wideband Audio Codec = WG

Hi=20 Henry,

given that some people on the list think that the IETF = does not=20 have
that type of expertise, we need to have those list discussions = so=20 that
the WG reaches consensus (one way or the other). It seems that = when=20 iLBC
was developed, it was difficult to find IETF people to review = it.=20 That
is probably why some people are hesitant about this. A way to=20 convince
them may be to have IETF people with knowledge in this area=20 volunteer to
work on this and review the=20 results.

Thanks,

Gonzalo

Henry Sinnreich = wrote:
>=20 (list deleted)
>
> Gonzalo,
>
>>whether or = not the=20 IETF in general and RAI in particular have the
> expertise=20 to
>>do this or at least review it when it is done.=20 Comments?
>
> The folks from Skype driving this proposal = have=20 without any doubt the
> best qualifications for building voice = codecs,=20 just as have many other
> IETF AVT contributors, such as for the = iLBC,=20 SPEEX, IP-MR and other codecs.
>
> The pushback for the = proposal for=20 a WG for an Internet Audio Codec, is
> quite amazing, especially = the=20 argument on available expertise.
> (You certainly understand my = arguments=20 why the better expertise for an
> _Internet_ codec is just in the = IETF,=20 and certainly not in the ITU-T,
> ETSI, OMA, = etc.).
>
> I=20 don’t plan therefore to participate any more in this = discussion.
>
>=20 Henry
>
>
> On 5/30/09 1:17 AM, "Gonzalo Camarillo" = <Gonzalo.Camarillo@ericsson.com>
>=20 wrote:
>
>     Hi,
>
>=20     I think Roni touches upon an important point = here. The=20 first question we
>     need to answer (not = only for=20 this proposal; for any proposal) is whether
> =     or=20 not the IETF in general and RAI in particular have the expertise = to
>=20     do this or at least review it when it is done.=20 Comments?
>
> =     Cheers,
>
>=20     Gonzalo
>
> =     Roni=20 Even wrote:
>     >  Hi,
>=20     >  Like you mention other SDOs like = ITU-T are=20 doing just that. They
>     have the
>=20     >  expertise to specify, and evaluate = the=20 result. These SDOs can receive
>     >=20  requirements and select a proper codec based on the = requirements.
>=20     >
> =     >
>=20     >  As for the other reasons:
>=20     >
>     > =  1.=20 Defining a codec in the IETF or even in MPEG / ITU-T does not
>=20     make it a
>     >=20  mandatory part of a system solution, this is done by other
> =     standard bodies
> =     >=20  like 3GPP, ETSI.
>     >
>=20     >  2. The IETF, similar to other = standard bodies=20 is not rubber stamping a
>     > =  specific=20 solution, so you will most probably see in the final
>=20     result some
>     > =  technology that carry IPR.
> =     >
>=20     >  3. If this group will be established, = you=20 will probably see here
>     the audio
> =     >  experts now working in ITU-T arguing = the same=20 issues since they
>     are the
>=20     >  expertise you need and they work for = the same=20 companies that are
>     already
>=20     >  members of IETF.
>=20     >
>     > =  I think=20 that if you have a specific codec in mind you  can make it
>=20     publicly
>     >=20  available maybe with quality results and standardized in AVT a=20 payload
>     > =  specification.
>=20     >
>     > =  BTW: The=20 ITU is keeping a list of codecs (Not only ITU-T ones) in
>=20     a table
>     > =  that=20 describes their features.
>     >
>=20     >  Regards
> =     >=20  Roni Even
>     >
>=20     >  -----Original Message-----
>=20     >  From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.or= g]
>=20     On Behalf
>     > =  Of=20 Jason Fischl
>     >  Sent: Wednesday, = May 27,=20 2009 2:18 AM
>     >  To: dispatch@ietf.org
>=20     >  Subject: [dispatch] Proposal to form = Internet=20 Wideband Audio Codec WG
>     >
>=20     >  All,
>=20     >
>     > =  I would=20 like to request agenda time inside the DISPATCH meeting to
>=20     propose
>     > =  the=20 formation of a new working group to define a Proposed Standard
>=20     wideband
>     >=20  audio codec.
>     >
>=20     >  The text of the proposal is below. = Comments,=20 questions, and
>     suggestions
>=20     >  welcomed.
>=20     >
>     >=20  Regards,
>     >  Jason
>=20     >
> =     >
>=20     >  Internet Wideband Audio Codec = (IWAC)
>=20     >  Mailing Lists: TBD
>=20     >  Chairs: TBD
>=20     >  Area Directorate: Real Time = Applications=20 (RAI)
>     >
> =     >=20  Purpose:
>     >
>=20     >  This new working group would be = chartered=20 with the purpose of
>     collecting
>=20     >  expertise within the IETF in order to = review=20 the design of audio
>     codecs
>=20     >  specifically for use with the = Internet.=20 Unlike other SDOs, these
>     codecs
>=20     >  would be optimized for use on the = Internet,=20 and as much as
>     possible choose
>=20     >  technology that does not require = paying=20 patent royalties.
>     >
>=20     >  The Internet Low Bit Rate Codec = (iLBC)=20  work was done in AVT but
>     it was=20 felt
>     >  that subsequent work = should not=20 be done in the AVT working group.
>     This=20 new
>     >  working group will have = as its=20 primary purpose the standardization
>     of = a
>=20     >  multi-purpose audio codec that can be = used in=20 various situations
>     on the
>=20     >  Internet. Some of the proposed=20 Internet-specific requirements include:
> =     >=20  * scalable and adaptive bit rate;
> =     >=20  * various sampling rate profiles from narrow-band to=20 super-wideband;
>     >  * scalable=20 complexity;
>     >  * low latency;=20 and
>     >  * resilience to packet=20 loss.
>     >
> =     >=20  There are a number of wide-band capable codecs defined by = other
>=20     SDOs. For
>     >=20  instance, G.722 is seeing adoption in Enterprise = applications
>=20     since it is
>     > =  relatively simple and low-cost to deploy. However, it has a = high,
>=20     fixed
>     > =  bitrate=20 and is not appropriate for mobile applications where spectrum
>=20     >  efficiency is important or in = consumer=20 applications where available
>     >=20  bandwidth is fluctuating or limited. G.722.2 (AMR-wideband) = has
>=20     been adopted
> =     >=20  by the 3GPP as a wideband standard for mobile applications. = G.722.2=20 is
>     >  relatively high cost due = to patent=20 royalties and is seeing minimal
>     >=20  deployments outside of mobile handsets making it challenging to=20 create
>     >  wideband experiences = on=20 Internet-capable mobile devices when extending
>=20     >  beyond the mobile network. In other = cases,=20 proprietary codecs are
>     being
>=20     >  adopted which further create islands = with no=20 interoperability unless
>     > =  widespread=20 transcoding is performed. Transcoding leads to higher
>=20     costs and
>     >=20  lower quality.
>     >
>=20     >  The goal of this working group is to = define a=20 single codec with
>     multiple
>=20     >  profiles which can be made available = on a=20 wide variety of
>     Internet-capable
> =     >  devices including low-power, mobile = devices=20 as well as devices
>     capable of
>=20     >  utilizing high quality, high bitrate=20 audio.
>     >
> =     >=20  Proposed Deliverables:
> =     >
>=20     >  1) Requirements for wideband, = Internet audio=20 codec(s).
>     >  2) Algorithm = description=20 for wideband, Internet audio codec(s) as
>=20     Proposed
>     >=20  Standard.
>     >  3) = Specification of=20 payload format(s) for defined codecs as Proposed
>=20     >  Standard
>=20     >
>     >=20  _______________________________________________
>=20     >  dispatch mailing list
>=20     >  dispatch@ietf.org
>=20     >  https://www.ietf.= org/mailman/listinfo/dispatch
>=20     >
>     >=20  _______________________________________________
>=20     >  dispatch mailing list
>=20     >  dispatch@ietf.org
>=20     >  https://www.ietf.= org/mailman/listinfo/dispatch
>=20     >
>
>=20     _______________________________________________>=20     dispatch mailing list
> =     dispatch@ietf.org
>=20     https://www.ietf.= org/mailman/listinfo/dispatch
>



------=20 End of Forwarded Message
------_=_NextPart_001_01C9E393.D8DC653C-- From jean-marc.valin@octasic.com Tue Jun 2 08:13:39 2009 Return-Path: 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 E717C3A6C78; Tue, 2 Jun 2009 08:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.299 X-Spam-Level: X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_INXPNS=2.3] 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 UvztSh8hFe8U; Tue, 2 Jun 2009 08:13:38 -0700 (PDT) Received: from MAILEXCH.octasic.com (mail.octasic.com [216.208.79.2]) by core3.amsl.com (Postfix) with ESMTP id 986B93A682D; Tue, 2 Jun 2009 08:13:38 -0700 (PDT) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Jun 2009 11:13:39 -0400 Message-ID: <4A2541B9.2000805@octasic.com> Date: Tue, 02 Jun 2009 11:14:01 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Roni Even References: <00a401c9e388$b25c2350$171469f0$%roni@huawei.com> In-Reply-To: <00a401c9e388$b25c2350$171469f0$%roni@huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Jun 2009 15:13:39.0041 (UTC) FILETIME=[B5231510:01C9E394] X-Mailman-Approved-At: Tue, 02 Jun 2009 08:27:01 -0700 Cc: dispatch@ietf.org, hsinnrei@adobe.com, 'Slava Borilin' , avt@ietf.org Subject: Re: [dispatch] [AVT] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 15:13:40 -0000 Hi, Roni Even wrote: > > I am not sure what prevented you from doing it today at the ITU or > MPEG, why do you see the IETF handling it differently. > > I would also like to remind you and Jean-Marc that once you are > bringing work to a standard body it may require collaboration with > other people who will have other proposals that will also address the > same requirements and you may need to invest money in comparative > testing by independent listening labs. > > I also think that you will need to supply the codec in source code and > provide copy right to the IETF. > I am well aware that bringing work to the IETF would require collaboration with others. I am not seeking control over the work I am currently doing and would really welcome such collaboration. The idea is only to have the best wideband codec possible without IPR issues. Given the ITU and MPEG track record, I think it would be very unlikely for any of those organisations to work on an IPR-free codec. I also agree with Henry that "the Internet has different criteria than ITU-T networks may have". Internet adoption follows different patterns than adoption in the ITU primary target markets. For example, the Internet has more consumer-reconfigurable software, while the ITU has to deal with a lot of fixed hardware deployments. At the ITU, it makes sense to invest large sums of money into testing and characterisation of codecs because the codecs deployed there usually stay around for a long time and the infrastructure investments are usually very large. On the other hand, I would say the investments in codecs for the Internet are comparatively smaller and, while testing is still important, it is not as critical as it is for the ITU. It's also a choice one has to make. It is unlikely that companies would invest money in expensive testing if they are not going to obtain royalties in return. However, I think we may be able to define some more lightweight (collaborative?) testing that is sufficient and doesn't involve as much investments as what the ITU does. For the Internet, I believe an IPR-free codec that everyone agrees performs well is better than a patent-encumbered codec that has had more extensive testing. This is again another difference with the ITU: patent-encumbered codecs tend to hurt a lot more on the Internet because many applications (e.g. giving away the client) are very hard (or impossible) when one has to pay per-channel royalties. As for the source code issue you pointed out, all the Xiph codecs are already published under a very permissive open source license (BSD), so this would not really change. Jean-Marc > Roni > > > > *From:* avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] *On Behalf > Of *Slava Borilin > *Sent:* Monday, June 01, 2009 11:50 PM > *To:* jean-marc.valin@octasic.com > *Cc:* avt@ietf.org; Jason Fischl > *Subject:* Re: [AVT] [dispatch] Proposal to form Internet Wideband > Audio Codec WG > > > > Agree with Jean-Marc. > SPIRIT is interested to contribute as well - having a dozen of proprietary codecs developed, including > one specifically desgined for internet (SPIRIT IP-MR, which is now under WGLC on draft-ietf-avt-rtp-ipmr-04) - > multi-rate, scalable, adaptive, wideband codec. > > We can also continue this work with IETF. > > Moreover, most if not all efforts coming from ITU on codecs unfortunately are NOT really focused on > internet-specific codecs (that's why several companies have had to invent) - as ITU preference is mainly > specific (i.e. cellular) networks at first. > > however, as we see the greant rise of pure "internet-basd communications" (skype, webex/citrix, and many others) - > we all (and users) are suffering from inefficiency in all currently "standard" codecs and ambiguity in the choice of > internet-targeted ones. > > Again, we probably can put together enough number of contributors to the WG to have the expertise. > > regards, > Slava Borilin > > -- > John Lazzaro wrote: > > A traditional response to this type of request is to note that the IETF > > really doesn't have much in the way of expertise in audio codec design. > > I don't see many of the regulars who present at the AES codec paper sessions > > posting here on AVT (ditto ICASSP paper sessions for voice codecs). It's > > a full-time job to keep up-to-date and contribute to that > > signal-processing lore. > > > > Well, there's no reason that the IETF cannot build such an expertise > in audio codecs. This is actually something in which I'd be interested > in getting involved and I'm sure others at Xiph.Org would be > interested as well. We have several people with audio codec expertise > from working on Vorbis, Speex and (more recently) CELT. It turns out > that the CELT codec currently under development at Xiph actually meets > most of the requirements from the original proposal in being a very > low delay codec with adaptive bit-rate and sampling rate (up to 48 > kHz), scalable complexity, and good robustness to packet loss. We'd be > willing to continue the development with the IETF. Even if not with > CELT, it's still like to be involved in such a new WG. > > Cheers, > > Jean-Marc From hsinnrei@adobe.com Tue Jun 2 09:12:50 2009 Return-Path: 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 AD12128C28F; Tue, 2 Jun 2009 09:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.843 X-Spam-Level: X-Spam-Status: No, score=-1.843 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, MANGLED_INXPNS=2.3, 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 onZsQ93cTp7L; Tue, 2 Jun 2009 09:12:48 -0700 (PDT) Received: from exprod6og115.obsmtp.com (exprod6og115.obsmtp.com [64.18.1.35]) by core3.amsl.com (Postfix) with ESMTP id 96EE628C27C; Tue, 2 Jun 2009 09:12:45 -0700 (PDT) Received: from source ([192.150.8.22]) by exprod6ob115.postini.com ([64.18.5.12]) with SMTP ID DSNKSiVPcdhJ83E2d+kEqESeABgiYpZrBkv6@postini.com; Tue, 02 Jun 2009 09:12:50 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 n52GCUWG028262; Tue, 2 Jun 2009 09:12:30 -0700 (PDT) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n52GCTtQ022330; Tue, 2 Jun 2009 09:12:29 -0700 (PDT) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nacas02.corp.adobe.com ([10.8.189.100]) with mapi; Tue, 2 Jun 2009 09:12:29 -0700 From: Henry Sinnreich To: Roni Even , Jean-Marc Valin Date: Tue, 2 Jun 2009 09:12:26 -0700 Thread-Topic: [AVT] [dispatch] Proposal to form Internet Wideband Audio Codec WG Thread-Index: AcnjlMn504Jo+DIAQwytQ2cXiyrF0wABKOlwAADfcI0= Message-ID: In-Reply-To: <00d501c9e39a$dcbbbe50$96333af0$%roni@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_C64AB99A3E55hsinnreiadobecom_" MIME-Version: 1.0 Cc: "dispatch@ietf.org" , Slava Borilin , "avt@ietf.org" Subject: Re: [dispatch] [AVT] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 16:12:50 -0000 --_000_C64AB99A3E55hsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >This leaves the other reasons I heard for doing it at the IETF which is th= e >price of participating This is an important point. Given the travel constraints for some of the most valuable potential contri= butors and reviewers, could we envisage online work until the economy impro= ves, so that an eventual BOF to start with should not be starved of attende= es? An online BOF? There are several free online meeting tools available... How can this be done within the IETF policy? Henry On 6/2/09 10:57 AM, "Roni Even" wrote: Hi, I do not want to sound like someone who is for IPR (I am not), but why stop at codec, let's require it for all IETF work. There are IPR on IETF work which is must simpler, in my view, than wide band audio codecs. I think that we can start with "royalty free" even though I am not sure tha= t it will accepted as part of the charter of any other work group so why pick on codecs which require more work. This leaves the other reasons I heard for doing it at the IETF which is the price of participating (cheaper than being an ITU-T member) and maybe desig= n less expensive characterization tests. Roni -----Original Message----- From: Jean-Marc Valin [mailto:jean-marc.valin@octasic.com] Sent: Tuesday, June 02, 2009 6:14 PM To: Roni Even Cc: 'Slava Borilin'; avt@ietf.org; 'Jason Fischl'; dispatch@ietf.org; hsinnrei@adobe.com Subject: Re: [AVT] [dispatch] Proposal to form Internet Wideband Audio Code= c WG Hi, Roni Even wrote: > > I am not sure what prevented you from doing it today at the ITU or > MPEG, why do you see the IETF handling it differently. > > I would also like to remind you and Jean-Marc that once you are > bringing work to a standard body it may require collaboration with > other people who will have other proposals that will also address the > same requirements and you may need to invest money in comparative > testing by independent listening labs. > > I also think that you will need to supply the codec in source code and > provide copy right to the IETF. > I am well aware that bringing work to the IETF would require collaboration with others. I am not seeking control over the work I am currently doing and would really welcome such collaboration. The idea is only to have the best wideband codec possible without IPR issues. Given the ITU and MPEG track record, I think it would be very unlikely for any of those organisations to work on an IPR-free codec. I also agree with Henry that "the Internet has different criteria than ITU-T networks may have". Internet adoption follows different patterns than adoption in the ITU primary target markets. For example, the Internet has more consumer-reconfigurable software, while the ITU has to deal with a lot of fixed hardware deployments. At the ITU, it makes sense to invest large sums of money into testing and characterisation of codecs because the codecs deployed there usually stay around for a long time and the infrastructure investments are usually very large. On the other hand, I would say the investments in codecs for the Internet are comparatively smaller and, while testing is still important, it is not as critical as it is for the ITU. It's also a choice one has to make. It is unlikely that companies would invest money in expensive testing if they are not going to obtain royalties in return. However, I think we may be able to define some more lightweight (collaborative?) testing that is sufficient and doesn't involve as much investments as what the ITU does. For the Internet, I believe an IPR-free codec that everyone agrees performs well is better than a patent-encumbered codec that has had more extensive testing. This is again another difference with the ITU: patent-encumbered codecs tend to hurt a lot more on the Internet because many applications (e.g. giving away the client) are very hard (or impossible) when one has to pay per-channel royalties. As for the source code issue you pointed out, all the Xiph codecs are already published under a very permissive open source license (BSD), so this would not really change. Jean-Marc > Roni > > > > *From:* avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] *On Behalf > Of *Slava Borilin > *Sent:* Monday, June 01, 2009 11:50 PM > *To:* jean-marc.valin@octasic.com > *Cc:* avt@ietf.org; Jason Fischl > *Subject:* Re: [AVT] [dispatch] Proposal to form Internet Wideband > Audio Codec WG > > > > Agree with Jean-Marc. > SPIRIT is interested to contribute as well - having a dozen of proprietar= y codecs developed, including > one specifically desgined for internet (SPIRIT IP-MR, which is now under WGLC on draft-ietf-avt-rtp-ipmr-04) - > multi-rate, scalable, adaptive, wideband codec. > > We can also continue this work with IETF. > > Moreover, most if not all efforts coming from ITU on codecs unfortunately are NOT really focused on > internet-specific codecs (that's why several companies have had to invent= ) - as ITU preference is mainly > specific (i.e. cellular) networks at first. > > however, as we see the greant rise of pure "internet-basd communications" (skype, webex/citrix, and many others) - > we all (and users) are suffering from inefficiency in all currently "standard" codecs and ambiguity in the choice of > internet-targeted ones. > > Again, we probably can put together enough number of contributors to the WG to have the expertise. > > regards, > Slava Borilin > > -- > John Lazzaro wrote: > > A traditional response to this type of request is to note that the IETF > > really doesn't have much in the way of expertise in audio codec design. > > I don't see many of the regulars who present at the AES codec paper sessions > > posting here on AVT (ditto ICASSP paper sessions for voice codecs). It's > > a full-time job to keep up-to-date and contribute to that > > signal-processing lore. > > > > Well, there's no reason that the IETF cannot build such an expertise > in audio codecs. This is actually something in which I'd be interested > in getting involved and I'm sure others at Xiph.Org would be > interested as well. We have several people with audio codec expertise > from working on Vorbis, Speex and (more recently) CELT. It turns out > that the CELT codec currently under development at Xiph actually meets > most of the requirements from the original proposal in being a very > low delay codec with adaptive bit-rate and sampling rate (up to 48 > kHz), scalable complexity, and good robustness to packet loss. We'd be > willing to continue the development with the IETF. Even if not with > CELT, it's still like to be involved in such a new WG. > > Cheers, > > Jean-Marc --_000_C64AB99A3E55hsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [AVT] [dispatch] Proposal to form Internet Wideband Audio Codec = WG >This leaves the other reasons I heard for doing it at the IETF wh= ich is the
>price of participating

This is an important point.
Given the travel constraints for some of the most valuable potential contri= butors and reviewers, could we envisage online work until the economy impro= ves, so that an eventual BOF to start with should not be starved of attende= es? An online BOF?

There are several free online meeting tools available...

How can this be done within the IETF policy?

Henry


On 6/2/09 10:57 AM, "Roni Even" <Even.roni@huawei.com> wrote:

Hi,
I do not want to sound like someone who is for IPR (I am not), but why stop=
at codec, let's require it for all IETF work. There are IPR on IETF work which is must simpler, in my view, than wide band audio codecs.

I think that we can start with "royalty free" even though I am no= t sure that
it will accepted as part of the charter of any other work group so why pick=
on codecs which require more work.

This leaves the other reasons I heard for doing it at the IETF which is the=
price of participating (cheaper than being an ITU-T member) and maybe desig= n
less expensive characterization tests.

Roni


-----Original Message-----
From: Jean-Marc Valin [mailt= o:jean-marc.valin@octasic.com]
Sent: Tuesday, June 02, 2009 6:14 PM
To: Roni Even
Cc: 'Slava Borilin'; avt@ietf.org; 'Jason Fisc= hl'; dispatch@ietf.org;
hsinnrei@adobe.com
Subject: Re: [AVT] [dispatch] Proposal to form Internet Wideband Audio Code= c
WG

Hi,

Roni Even wrote:
>
> I am not sure what prevented you from doing it today at the ITU or
> MPEG, why do you see the IETF handling it differently.
>
> I would also like to remind you and Jean-Marc that once you are
> bringing work to a standard body it may require collaboration with
> other people who will have other proposals that will also address the<= BR> > same requirements and you may need to invest money in comparative
> testing by independent listening labs.
>
> I also think that you will need to supply the codec in source code and=
> provide copy right to the IETF.
>

I am well aware that bringing work to the IETF would require
collaboration with others. I am not seeking control over the work I am
currently doing and would really welcome such collaboration. The idea is only to have the best wideband codec possible without IPR issues. Given
the ITU and MPEG track record, I think it would be very unlikely for any of those organisations to work on an IPR-free codec.

I also agree with Henry that "the Internet has different criteria than=
ITU-T networks may have". Internet adoption follows different patterns=
than adoption in the ITU primary target markets. For example, the
Internet has more consumer-reconfigurable software, while the ITU has to deal with a lot of fixed hardware deployments. At the ITU, it makes
sense to invest large sums of money into testing and characterisation of codecs because the codecs deployed there usually stay around for a long
time and the infrastructure investments are usually very large. On the
other hand, I would say the investments in codecs for the Internet are
comparatively smaller and, while testing is still important, it is not
as critical as it is for the ITU.

It's also a choice one has to make. It is unlikely that companies would
invest money in expensive testing if they are not going to obtain
royalties in return. However, I think we may be able to define some more lightweight (collaborative?) testing that is sufficient and doesn't
involve as much investments as what the ITU does. For the Internet, I
believe an IPR-free codec that everyone agrees performs well is better
than a patent-encumbered codec that has had more extensive testing. This is again another difference with the ITU: patent-encumbered codecs tend
to hurt a lot more on the Internet because many applications (e.g.
giving away the client) are very hard (or impossible) when one has to
pay per-channel royalties.

As for the source code issue you pointed out, all the Xiph codecs are
already published under a very permissive open source license (BSD), so
this would not really change.

    Jean-Marc

> Roni
>
>
>
> *From:* avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] *On B= ehalf
> Of *Slava Borilin
> *Sent:* Monday, June 01, 2009 11:50 PM
> *To:* jean-marc.valin@octasic.= com
> *Cc:* avt@ietf.org; Jason Fischl
> *Subject:* Re: [AVT] [dispatch] Proposal to form Internet Wideband
> Audio Codec WG
>
>
>
> Agree with Jean-Marc.
> SPIRIT is interested to contribute as well - having a dozen of proprie= tary
codecs developed, including
> one specifically desgined for internet (SPIRIT IP-MR, which is now und= er
WGLC on draft-ietf-avt-rtp-ipmr-04) -
> multi-rate, scalable, adaptive, wideband codec.
>
> We can also continue this work with IETF.
>
> Moreover, most if not all efforts coming from ITU on codecs unfortunat= ely
are NOT really focused on
> internet-specific codecs (that's why several companies have had to inv= ent)
- as ITU preference is mainly
> specific (i.e. cellular) networks at first.
>
> however, as we see the greant rise of pure "internet-basd communi= cations"
(skype, webex/citrix, and many others) -
> we all (and users) are suffering from inefficiency in all currently "standard" codecs and ambiguity in the choice of
> internet-targeted ones.
>
> Again, we probably can put together enough number of contributors to t= he
WG to have the expertise.
>
> regards,
> Slava Borilin
>
> --
> John Lazzaro wrote:
>
>     A traditional response to this type of request= is to note that the
IETF
>
>     really doesn't have much in the way of experti= se in audio codec
design.
>
>     I don't see many of the regulars who present a= t the AES codec paper
sessions
>
>     posting here on AVT (ditto ICASSP paper sessio= ns for voice codecs).
It's
>
>     a full-time job to keep up-to-date and contrib= ute to that
>
>     signal-processing lore.
>
>     
>
> Well, there's no reason that the IETF cannot build such an expertise > in audio codecs. This is actually something in which I'd be interested=
> in getting involved and I'm sure others at Xiph.Org would be
> interested as well. We have several people with audio codec expertise<= BR> > from working on Vorbis, Speex and (more recently) CELT. It turns out > that the CELT codec currently under development at Xiph actually meets=
> most of the requirements from the original proposal in being a very > low delay codec with adaptive bit-rate and sampling rate (up to 48
> kHz), scalable complexity, and good robustness to packet loss. We'd be=
> willing to continue the development with the IETF. Even if not with > CELT, it's still like to be involved in such a new WG.
>
> Cheers,
>
>    Jean-Marc


--_000_C64AB99A3E55hsinnreiadobecom_-- From Even.roni@huawei.com Tue Jun 2 09:00:33 2009 Return-Path: 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 D23263A68DD; Tue, 2 Jun 2009 09:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.831 X-Spam-Level: X-Spam-Status: No, score=0.831 tagged_above=-999 required=5 tests=[AWL=-1.325, BAYES_00=-2.599, FRT_ADOBE2=2.455, MANGLED_INXPNS=2.3] 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 3x-J11suuf71; Tue, 2 Jun 2009 09:00:31 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 7A39E3A6FFC; Tue, 2 Jun 2009 08:58:43 -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 <0KKM00DASCDTRW@szxga04-in.huawei.com>; Tue, 02 Jun 2009 23:58:41 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KKM00KHMCDTTW@szxga04-in.huawei.com>; Tue, 02 Jun 2009 23:58:41 +0800 (CST) Received: from windows8d787f9 (bzq-79-182-66-238.red.bezeqint.net [79.182.66.238]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KKM0091DCD2K7@szxml02-in.huawei.com>; Tue, 02 Jun 2009 23:58:41 +0800 (CST) Date: Tue, 02 Jun 2009 18:57:16 +0300 From: Roni Even In-reply-to: <4A2541B9.2000805@octasic.com> To: 'Jean-Marc Valin' Message-id: <00d501c9e39a$dcbbbe50$96333af0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcnjlMn504Jo+DIAQwytQ2cXiyrF0wABKOlw References: <00a401c9e388$b25c2350$171469f0$%roni@huawei.com> <4A2541B9.2000805@octasic.com> X-Mailman-Approved-At: Tue, 02 Jun 2009 09:12:54 -0700 Cc: dispatch@ietf.org, hsinnrei@adobe.com, 'Slava Borilin' , avt@ietf.org Subject: Re: [dispatch] [AVT] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 16:00:33 -0000 Hi, I do not want to sound like someone who is for IPR (I am not), but why stop at codec, let's require it for all IETF work. There are IPR on IETF work which is must simpler, in my view, than wide band audio codecs. I think that we can start with "royalty free" even though I am not sure that it will accepted as part of the charter of any other work group so why pick on codecs which require more work. This leaves the other reasons I heard for doing it at the IETF which is the price of participating (cheaper than being an ITU-T member) and maybe design less expensive characterization tests. Roni -----Original Message----- From: Jean-Marc Valin [mailto:jean-marc.valin@octasic.com] Sent: Tuesday, June 02, 2009 6:14 PM To: Roni Even Cc: 'Slava Borilin'; avt@ietf.org; 'Jason Fischl'; dispatch@ietf.org; hsinnrei@adobe.com Subject: Re: [AVT] [dispatch] Proposal to form Internet Wideband Audio Codec WG Hi, Roni Even wrote: > > I am not sure what prevented you from doing it today at the ITU or > MPEG, why do you see the IETF handling it differently. > > I would also like to remind you and Jean-Marc that once you are > bringing work to a standard body it may require collaboration with > other people who will have other proposals that will also address the > same requirements and you may need to invest money in comparative > testing by independent listening labs. > > I also think that you will need to supply the codec in source code and > provide copy right to the IETF. > I am well aware that bringing work to the IETF would require collaboration with others. I am not seeking control over the work I am currently doing and would really welcome such collaboration. The idea is only to have the best wideband codec possible without IPR issues. Given the ITU and MPEG track record, I think it would be very unlikely for any of those organisations to work on an IPR-free codec. I also agree with Henry that "the Internet has different criteria than ITU-T networks may have". Internet adoption follows different patterns than adoption in the ITU primary target markets. For example, the Internet has more consumer-reconfigurable software, while the ITU has to deal with a lot of fixed hardware deployments. At the ITU, it makes sense to invest large sums of money into testing and characterisation of codecs because the codecs deployed there usually stay around for a long time and the infrastructure investments are usually very large. On the other hand, I would say the investments in codecs for the Internet are comparatively smaller and, while testing is still important, it is not as critical as it is for the ITU. It's also a choice one has to make. It is unlikely that companies would invest money in expensive testing if they are not going to obtain royalties in return. However, I think we may be able to define some more lightweight (collaborative?) testing that is sufficient and doesn't involve as much investments as what the ITU does. For the Internet, I believe an IPR-free codec that everyone agrees performs well is better than a patent-encumbered codec that has had more extensive testing. This is again another difference with the ITU: patent-encumbered codecs tend to hurt a lot more on the Internet because many applications (e.g. giving away the client) are very hard (or impossible) when one has to pay per-channel royalties. As for the source code issue you pointed out, all the Xiph codecs are already published under a very permissive open source license (BSD), so this would not really change. Jean-Marc > Roni > > > > *From:* avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] *On Behalf > Of *Slava Borilin > *Sent:* Monday, June 01, 2009 11:50 PM > *To:* jean-marc.valin@octasic.com > *Cc:* avt@ietf.org; Jason Fischl > *Subject:* Re: [AVT] [dispatch] Proposal to form Internet Wideband > Audio Codec WG > > > > Agree with Jean-Marc. > SPIRIT is interested to contribute as well - having a dozen of proprietary codecs developed, including > one specifically desgined for internet (SPIRIT IP-MR, which is now under WGLC on draft-ietf-avt-rtp-ipmr-04) - > multi-rate, scalable, adaptive, wideband codec. > > We can also continue this work with IETF. > > Moreover, most if not all efforts coming from ITU on codecs unfortunately are NOT really focused on > internet-specific codecs (that's why several companies have had to invent) - as ITU preference is mainly > specific (i.e. cellular) networks at first. > > however, as we see the greant rise of pure "internet-basd communications" (skype, webex/citrix, and many others) - > we all (and users) are suffering from inefficiency in all currently "standard" codecs and ambiguity in the choice of > internet-targeted ones. > > Again, we probably can put together enough number of contributors to the WG to have the expertise. > > regards, > Slava Borilin > > -- > John Lazzaro wrote: > > A traditional response to this type of request is to note that the IETF > > really doesn't have much in the way of expertise in audio codec design. > > I don't see many of the regulars who present at the AES codec paper sessions > > posting here on AVT (ditto ICASSP paper sessions for voice codecs). It's > > a full-time job to keep up-to-date and contribute to that > > signal-processing lore. > > > > Well, there's no reason that the IETF cannot build such an expertise > in audio codecs. This is actually something in which I'd be interested > in getting involved and I'm sure others at Xiph.Org would be > interested as well. We have several people with audio codec expertise > from working on Vorbis, Speex and (more recently) CELT. It turns out > that the CELT codec currently under development at Xiph actually meets > most of the requirements from the original proposal in being a very > low delay codec with adaptive bit-rate and sampling rate (up to 48 > kHz), scalable complexity, and good robustness to packet loss. We'd be > willing to continue the development with the IETF. Even if not with > CELT, it's still like to be involved in such a new WG. > > Cheers, > > Jean-Marc From hgs@cs.columbia.edu Tue Jun 2 09:16:31 2009 Return-Path: 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 3A5903A6F2D; Tue, 2 Jun 2009 09:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.844 X-Spam-Level: X-Spam-Status: No, score=-1.844 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_ADOBE2=2.455, MANGLED_INXPNS=2.3, 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 RtHrmCP8GIPz; Tue, 2 Jun 2009 09:16:30 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id D1F103A6BDE; Tue, 2 Jun 2009 09:16:29 -0700 (PDT) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id n52GFqU0013510 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 2 Jun 2009 12:15:52 -0400 (EDT) Message-Id: From: Henning Schulzrinne To: Roni Even In-Reply-To: <00d501c9e39a$dcbbbe50$96333af0$%roni@huawei.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: Tue, 2 Jun 2009 12:15:51 -0400 References: <00a401c9e388$b25c2350$171469f0$%roni@huawei.com> <4A2541B9.2000805@octasic.com> <00d501c9e39a$dcbbbe50$96333af0$%roni@huawei.com> X-Mailer: Apple Mail (2.935.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8 Cc: dispatch@ietf.org, 'Jean-Marc Valin' , avt@ietf.org, hsinnrei@adobe.com, 'Slava Borilin' Subject: Re: [dispatch] [AVT] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 16:16:31 -0000 I view this as a trade-off. If we pursue this, there are risks: - nothing may come of it since there are no experts willing to help - somebody will claim IPR on the resulting work - the quality of the codec may not be competitive However, if we don't do this, we are stuck with the status quo, which is not all that satisfactory. Thus, unless there are significant costs for "innocent bystanders", I see this as a risk worth taking. In the worst case, we are no worse off than we are today. In all other cases, we'll have an additional choice for a wideband codec, even if it's not "the best", just "good enough". After all, most people use G.711 today, which has a really hard time making that claim. Most real work in the IETF is done by very small teams, typically less than 10, so as long as we have a handful of people that are willing to contribute, this can work. It might even work better, since you may get fewer people who have half-baked opinions - we may skip the binary vs. XML debates... We can set some ground rules ("must be tested with packet loss of 5%") and then see what happens. Compared to most network protocols, the likely negative impacts (such as security or congestion control issues) of even a badly-designed codec are pretty limited. Henning On Jun 2, 2009, at 11:57 AM, Roni Even wrote: > Hi, > I do not want to sound like someone who is for IPR (I am not), but > why stop > at codec, let's require it for all IETF work. There are IPR on IETF > work > which is must simpler, in my view, than wide band audio codecs. > > I think that we can start with "royalty free" even though I am not > sure that > it will accepted as part of the charter of any other work group so > why pick > on codecs which require more work. > > This leaves the other reasons I heard for doing it at the IETF which > is the > price of participating (cheaper than being an ITU-T member) and > maybe design > less expensive characterization tests. > > Roni > > > -----Original Message----- > From: Jean-Marc Valin [mailto:jean-marc.valin@octasic.com] > Sent: Tuesday, June 02, 2009 6:14 PM > To: Roni Even > Cc: 'Slava Borilin'; avt@ietf.org; 'Jason Fischl'; dispatch@ietf.org; > hsinnrei@adobe.com > Subject: Re: [AVT] [dispatch] Proposal to form Internet Wideband > Audio Codec > WG > > Hi, > > Roni Even wrote: >> >> I am not sure what prevented you from doing it today at the ITU or >> MPEG, why do you see the IETF handling it differently. >> >> I would also like to remind you and Jean-Marc that once you are >> bringing work to a standard body it may require collaboration with >> other people who will have other proposals that will also address the >> same requirements and you may need to invest money in comparative >> testing by independent listening labs. >> >> I also think that you will need to supply the codec in source code >> and >> provide copy right to the IETF. >> > > I am well aware that bringing work to the IETF would require > collaboration with others. I am not seeking control over the work I am > currently doing and would really welcome such collaboration. The > idea is > only to have the best wideband codec possible without IPR issues. > Given > the ITU and MPEG track record, I think it would be very unlikely for > any > of those organisations to work on an IPR-free codec. > > I also agree with Henry that "the Internet has different criteria than > ITU-T networks may have". Internet adoption follows different patterns > than adoption in the ITU primary target markets. For example, the > Internet has more consumer-reconfigurable software, while the ITU > has to > deal with a lot of fixed hardware deployments. At the ITU, it makes > sense to invest large sums of money into testing and > characterisation of > codecs because the codecs deployed there usually stay around for a > long > time and the infrastructure investments are usually very large. On the > other hand, I would say the investments in codecs for the Internet are > comparatively smaller and, while testing is still important, it is not > as critical as it is for the ITU. > > It's also a choice one has to make. It is unlikely that companies > would > invest money in expensive testing if they are not going to obtain > royalties in return. However, I think we may be able to define some > more > lightweight (collaborative?) testing that is sufficient and doesn't > involve as much investments as what the ITU does. For the Internet, I > believe an IPR-free codec that everyone agrees performs well is better > than a patent-encumbered codec that has had more extensive testing. > This > is again another difference with the ITU: patent-encumbered codecs > tend > to hurt a lot more on the Internet because many applications (e.g. > giving away the client) are very hard (or impossible) when one has to > pay per-channel royalties. > > As for the source code issue you pointed out, all the Xiph codecs are > already published under a very permissive open source license (BSD), > so > this would not really change. > > Jean-Marc > >> Roni >> >> >> >> *From:* avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] *On Behalf >> Of *Slava Borilin >> *Sent:* Monday, June 01, 2009 11:50 PM >> *To:* jean-marc.valin@octasic.com >> *Cc:* avt@ietf.org; Jason Fischl >> *Subject:* Re: [AVT] [dispatch] Proposal to form Internet Wideband >> Audio Codec WG >> >> >> >> Agree with Jean-Marc. >> SPIRIT is interested to contribute as well - having a dozen of >> proprietary > codecs developed, including >> one specifically desgined for internet (SPIRIT IP-MR, which is now >> under > WGLC on draft-ietf-avt-rtp-ipmr-04) - >> multi-rate, scalable, adaptive, wideband codec. >> >> We can also continue this work with IETF. >> >> Moreover, most if not all efforts coming from ITU on codecs >> unfortunately > are NOT really focused on >> internet-specific codecs (that's why several companies have had to >> invent) > - as ITU preference is mainly >> specific (i.e. cellular) networks at first. >> >> however, as we see the greant rise of pure "internet-basd >> communications" > (skype, webex/citrix, and many others) - >> we all (and users) are suffering from inefficiency in all currently > "standard" codecs and ambiguity in the choice of >> internet-targeted ones. >> >> Again, we probably can put together enough number of contributors >> to the > WG to have the expertise. >> >> regards, >> Slava Borilin >> >> -- >> John Lazzaro wrote: >> >> A traditional response to this type of request is to note that the > IETF >> >> really doesn't have much in the way of expertise in audio codec > design. >> >> I don't see many of the regulars who present at the AES codec >> paper > sessions >> >> posting here on AVT (ditto ICASSP paper sessions for voice >> codecs). > It's >> >> a full-time job to keep up-to-date and contribute to that >> >> signal-processing lore. >> >> >> >> Well, there's no reason that the IETF cannot build such an expertise >> in audio codecs. This is actually something in which I'd be >> interested >> in getting involved and I'm sure others at Xiph.Org would be >> interested as well. We have several people with audio codec expertise >> from working on Vorbis, Speex and (more recently) CELT. It turns out >> that the CELT codec currently under development at Xiph actually >> meets >> most of the requirements from the original proposal in being a very >> low delay codec with adaptive bit-rate and sampling rate (up to 48 >> kHz), scalable complexity, and good robustness to packet loss. We'd >> be >> willing to continue the development with the IETF. Even if not with >> CELT, it's still like to be involved in such a new WG. >> >> Cheers, >> >> Jean-Marc > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > From jmpolk@cisco.com Tue Jun 2 09:16:33 2009 Return-Path: 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 8C80E28C29C; Tue, 2 Jun 2009 09:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[AWL=-2.377, BAYES_00=-2.599, FRT_ADOBE2=2.455, MANGLED_INXPNS=2.3, 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 Qz-BDaRFzs87; Tue, 2 Jun 2009 09:16:32 -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 3A8513A6FC2; Tue, 2 Jun 2009 09:16:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,291,1241395200"; d="scan'208";a="171678238" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 02 Jun 2009 16:16:33 +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 n52GGXSB019885; Tue, 2 Jun 2009 09:16:33 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n52GGXMA015591; Tue, 2 Jun 2009 16:16:33 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Jun 2009 09:16:33 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.0.152]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Jun 2009 09:16:32 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 02 Jun 2009 11:16:31 -0500 To: Henry Sinnreich , Roni Even , Jean-Marc Valin From: "James M. Polk" In-Reply-To: References: <00d501c9e39a$dcbbbe50$96333af0$%roni@huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 02 Jun 2009 16:16:32.0704 (UTC) FILETIME=[7E6A5C00:01C9E39D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7706; t=1243959393; x=1244823393; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[dispatch]=20[AVT]=20Proposal=20to=20fo rm=20Internet=20Wideband=20Audio=0A=20=20Codec=20WG |Sender:=20; bh=iScs2EaZ+GLpaCSs1vNnyMWptupqhMRFmxvY19FRjb0=; b=rEvBuThACgVGd3LO6bu9FCn41q0MIIRgn59qOgd7tgFwzynPZJqo0luMBE K3YDlvee3ReKlPKaSr9vI15M+ocXcmom02oyNcaCnqDdlyZNwd/JNUVyfUN8 C4VVCGtaLz; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: "dispatch@ietf.org" , Slava Borilin , "avt@ietf.org" Subject: Re: [dispatch] [AVT] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 16:16:33 -0000 At 11:12 AM 6/2/2009, Henry Sinnreich wrote: >Content-Language: en >Content-Type: multipart/alternative; > boundary="_000_C64AB99A3E55hsinnreiadobecom_" > > >This leaves the other reasons I heard for doing it at the IETF which is the > >price of participating > >This is an important point. >Given the travel constraints for some of the most valuable potential >contributors and reviewers, could we envisage online work until the >economy improves, so that an eventual BOF to start with should not >be starved of attendees? Henry this economic constraint will exist no matter which SDO this work eventually gets done in. >An online BOF? > >There are several free online meeting tools available... > >How can this be done within the IETF policy? > >Henry > > >On 6/2/09 10:57 AM, "Roni Even" ><Even.roni@huawei.com> wrote: > >Hi, >I do not want to sound like someone who is for IPR (I am not), but why stop >at codec, let's require it for all IETF work. There are IPR on IETF work >which is must simpler, in my view, than wide band audio codecs. > >I think that we can start with "royalty free" even though I am not sure that >it will accepted as part of the charter of any other work group so why pick >on codecs which require more work. > >This leaves the other reasons I heard for doing it at the IETF which is the >price of participating (cheaper than being an ITU-T member) and maybe design >less expensive characterization tests. > >Roni > > >-----Original Message----- >From: Jean-Marc Valin >[mailto:jean-marc.valin@octasic.com] >Sent: Tuesday, June 02, 2009 6:14 PM >To: Roni Even >Cc: 'Slava Borilin'; avt@ietf.org; 'Jason Fischl'; >dispatch@ietf.org; >hsinnrei@adobe.com >Subject: Re: [AVT] [dispatch] Proposal to form Internet Wideband Audio Codec >WG > >Hi, > >Roni Even wrote: > > > > I am not sure what prevented you from doing it today at the ITU or > > MPEG, why do you see the IETF handling it differently. > > > > I would also like to remind you and Jean-Marc that once you are > > bringing work to a standard body it may require collaboration with > > other people who will have other proposals that will also address the > > same requirements and you may need to invest money in comparative > > testing by independent listening labs. > > > > I also think that you will need to supply the codec in source code and > > provide copy right to the IETF. > > > >I am well aware that bringing work to the IETF would require >collaboration with others. I am not seeking control over the work I am >currently doing and would really welcome such collaboration. The idea is >only to have the best wideband codec possible without IPR issues. Given >the ITU and MPEG track record, I think it would be very unlikely for any >of those organisations to work on an IPR-free codec. > >I also agree with Henry that "the Internet has different criteria than >ITU-T networks may have". Internet adoption follows different patterns >than adoption in the ITU primary target markets. For example, the >Internet has more consumer-reconfigurable software, while the ITU has to >deal with a lot of fixed hardware deployments. At the ITU, it makes >sense to invest large sums of money into testing and characterisation of >codecs because the codecs deployed there usually stay around for a long >time and the infrastructure investments are usually very large. On the >other hand, I would say the investments in codecs for the Internet are >comparatively smaller and, while testing is still important, it is not >as critical as it is for the ITU. > >It's also a choice one has to make. It is unlikely that companies would >invest money in expensive testing if they are not going to obtain >royalties in return. However, I think we may be able to define some more >lightweight (collaborative?) testing that is sufficient and doesn't >involve as much investments as what the ITU does. For the Internet, I >believe an IPR-free codec that everyone agrees performs well is better >than a patent-encumbered codec that has had more extensive testing. This >is again another difference with the ITU: patent-encumbered codecs tend >to hurt a lot more on the Internet because many applications (e.g. >giving away the client) are very hard (or impossible) when one has to >pay per-channel royalties. > >As for the source code issue you pointed out, all the Xiph codecs are >already published under a very permissive open source license (BSD), so >this would not really change. > > Jean-Marc > > > Roni > > > > > > > > *From:* avt-bounces@ietf.org > [mailto:avt-bounces@ietf.org] *On Behalf > > Of *Slava Borilin > > *Sent:* Monday, June 01, 2009 11:50 PM > > *To:* jean-marc.valin@octasic.com > > *Cc:* avt@ietf.org; Jason Fischl > > *Subject:* Re: [AVT] [dispatch] Proposal to form Internet Wideband > > Audio Codec WG > > > > > > > > Agree with Jean-Marc. > > SPIRIT is interested to contribute as well - having a dozen of proprietary >codecs developed, including > > one specifically desgined for internet (SPIRIT IP-MR, which is now under >WGLC on draft-ietf-avt-rtp-ipmr-04) - > > multi-rate, scalable, adaptive, wideband codec. > > > > We can also continue this work with IETF. > > > > Moreover, most if not all efforts coming from ITU on codecs unfortunately >are NOT really focused on > > internet-specific codecs (that's why several companies have had to invent) >- as ITU preference is mainly > > specific (i.e. cellular) networks at first. > > > > however, as we see the greant rise of pure "internet-basd communications" >(skype, webex/citrix, and many others) - > > we all (and users) are suffering from inefficiency in all currently >"standard" codecs and ambiguity in the choice of > > internet-targeted ones. > > > > Again, we probably can put together enough number of contributors to the >WG to have the expertise. > > > > regards, > > Slava Borilin > > > > -- > > John Lazzaro wrote: > > > > A traditional response to this type of request is to note that the >IETF > > > > really doesn't have much in the way of expertise in audio codec >design. > > > > I don't see many of the regulars who present at the AES codec paper >sessions > > > > posting here on AVT (ditto ICASSP paper sessions for voice codecs). >It's > > > > a full-time job to keep up-to-date and contribute to that > > > > signal-processing lore. > > > > > > > > Well, there's no reason that the IETF cannot build such an expertise > > in audio codecs. This is actually something in which I'd be interested > > in getting involved and I'm sure others at Xiph.Org would be > > interested as well. We have several people with audio codec expertise > > from working on Vorbis, Speex and (more recently) CELT. It turns out > > that the CELT codec currently under development at Xiph actually meets > > most of the requirements from the original proposal in being a very > > low delay codec with adaptive bit-rate and sampling rate (up to 48 > > kHz), scalable complexity, and good robustness to packet loss. We'd be > > willing to continue the development with the IETF. Even if not with > > CELT, it's still like to be involved in such a new WG. > > > > Cheers, > > > > Jean-Marc > > >_______________________________________________ >dispatch mailing list >dispatch@ietf.org >https://www.ietf.org/mailman/listinfo/dispatch From spencer@wonderhamster.org Tue Jun 2 09:46:32 2009 Return-Path: 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 5F9753A67CC; Tue, 2 Jun 2009 09:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.157 X-Spam-Level: ** X-Spam-Status: No, score=2.157 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, MANGLED_INXPNS=2.3] 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 nLppJH6FHq-m; Tue, 2 Jun 2009 09:46:30 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 7AD0E3A6FFC; Tue, 2 Jun 2009 09:45:12 -0700 (PDT) Received: from S73602b (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1MBX6j3fcO-000cju; Tue, 02 Jun 2009 12:45:09 -0400 Message-ID: From: "Spencer Dawkins" To: "Henry Sinnreich" , "Roni Even" , "Jean-Marc Valin" References: Date: Tue, 2 Jun 2009 11:44:51 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_330A_01C9E377.8A1F24C0" 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: V01U2FsdGVkX191DGjPNv7ANdr3PHcraEsSPZydSTH+9ISA8Ip tqJZeWdCDEhUz9iSMjrs4FaJFxz15P9mkScqz97UwkBO6gpPlE YvU5yu1pDMeRa1CHRbxZLqJ0KgDL8MVmYgzycumlqY= Cc: dispatch@ietf.org, Slava Borilin , avt@ietf.org Subject: Re: [dispatch] [AVT] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 16:46:32 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_330A_01C9E377.8A1F24C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [AVT] [dispatch] Proposal to form Internet Wideband Audio Codec WGI = am not an area director, nor do i play one on IPTV, but my suggestion = for anyone interested would be to=20 - request a non-WG mailing list (from either of the RAI area directors), - announce it on this mailing list (and others that seem to be = appropriate, and=20 - start discussions, which the area directors typically look at when = judging whether there's enough interest and enough clue to justify = approving a BOF and/or chartering a working group. I didn't see a mailing list included in Jason's proposal - if I missed = one, my apologies. If people at the IETF can do this work, and want to do this work, IETF = process policies should not get in the way of that happening. And I haven't heard of an AD turning down a request for a non-WG mailing = list yet, keeping in mind that one of said lists is ietf-sailors, for = people interested in sailing to/from/at IETF meetings - the bar is = (appropriately) low. Thanks, Spencer ----- Original Message -----=20 From: Henry Sinnreich=20 To: Roni Even ; Jean-Marc Valin=20 Cc: dispatch@ietf.org ; Slava Borilin ; avt@ietf.org=20 Sent: Tuesday, June 02, 2009 11:12 AM Subject: Re: [dispatch] [AVT] Proposal to form Internet Wideband Audio = Codec WG >This leaves the other reasons I heard for doing it at the IETF which = is the=20 >price of participating=20 This is an important point. Given the travel constraints for some of the most valuable potential = contributors and reviewers, could we envisage online work until the = economy improves, so that an eventual BOF to start with should not be = starved of attendees? An online BOF? There are several free online meeting tools available... How can this be done within the IETF policy? Henry On 6/2/09 10:57 AM, "Roni Even" wrote: Hi, I do not want to sound like someone who is for IPR (I am not), but = why stop at codec, let's require it for all IETF work. There are IPR on IETF = work which is must simpler, in my view, than wide band audio codecs. I think that we can start with "royalty free" even though I am not = sure that it will accepted as part of the charter of any other work group so = why pick on codecs which require more work. This leaves the other reasons I heard for doing it at the IETF which = is the price of participating (cheaper than being an ITU-T member) and = maybe design less expensive characterization tests. Roni -----Original Message----- From: Jean-Marc Valin [mailto:jean-marc.valin@octasic.com] Sent: Tuesday, June 02, 2009 6:14 PM To: Roni Even Cc: 'Slava Borilin'; avt@ietf.org; 'Jason Fischl'; = dispatch@ietf.org; hsinnrei@adobe.com Subject: Re: [AVT] [dispatch] Proposal to form Internet Wideband = Audio Codec WG Hi, Roni Even wrote: > > I am not sure what prevented you from doing it today at the ITU or > MPEG, why do you see the IETF handling it differently. > > I would also like to remind you and Jean-Marc that once you are > bringing work to a standard body it may require collaboration with > other people who will have other proposals that will also address = the > same requirements and you may need to invest money in comparative > testing by independent listening labs. > > I also think that you will need to supply the codec in source code = and > provide copy right to the IETF. > I am well aware that bringing work to the IETF would require collaboration with others. I am not seeking control over the work I = am currently doing and would really welcome such collaboration. The = idea is only to have the best wideband codec possible without IPR issues. = Given the ITU and MPEG track record, I think it would be very unlikely for = any of those organisations to work on an IPR-free codec. I also agree with Henry that "the Internet has different criteria = than ITU-T networks may have". Internet adoption follows different = patterns than adoption in the ITU primary target markets. For example, the Internet has more consumer-reconfigurable software, while the ITU = has to deal with a lot of fixed hardware deployments. At the ITU, it makes sense to invest large sums of money into testing and = characterisation of codecs because the codecs deployed there usually stay around for a = long time and the infrastructure investments are usually very large. On = the other hand, I would say the investments in codecs for the Internet = are comparatively smaller and, while testing is still important, it is = not as critical as it is for the ITU. It's also a choice one has to make. It is unlikely that companies = would invest money in expensive testing if they are not going to obtain royalties in return. However, I think we may be able to define some = more lightweight (collaborative?) testing that is sufficient and doesn't involve as much investments as what the ITU does. For the Internet, = I believe an IPR-free codec that everyone agrees performs well is = better than a patent-encumbered codec that has had more extensive testing. = This is again another difference with the ITU: patent-encumbered codecs = tend to hurt a lot more on the Internet because many applications (e.g. giving away the client) are very hard (or impossible) when one has = to pay per-channel royalties. As for the source code issue you pointed out, all the Xiph codecs = are already published under a very permissive open source license (BSD), = so this would not really change. Jean-Marc > Roni > >=20 > > *From:* avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] *On = Behalf > Of *Slava Borilin > *Sent:* Monday, June 01, 2009 11:50 PM > *To:* jean-marc.valin@octasic.com > *Cc:* avt@ietf.org; Jason Fischl > *Subject:* Re: [AVT] [dispatch] Proposal to form Internet Wideband > Audio Codec WG > >=20 > > Agree with Jean-Marc. > SPIRIT is interested to contribute as well - having a dozen of = proprietary codecs developed, including > one specifically desgined for internet (SPIRIT IP-MR, which is now = under WGLC on draft-ietf-avt-rtp-ipmr-04) - > multi-rate, scalable, adaptive, wideband codec. >=20 > We can also continue this work with IETF. >=20 > Moreover, most if not all efforts coming from ITU on codecs = unfortunately are NOT really focused on > internet-specific codecs (that's why several companies have had to = invent) - as ITU preference is mainly > specific (i.e. cellular) networks at first. >=20 > however, as we see the greant rise of pure "internet-basd = communications" (skype, webex/citrix, and many others) - > we all (and users) are suffering from inefficiency in all = currently "standard" codecs and ambiguity in the choice of > internet-targeted ones. >=20 > Again, we probably can put together enough number of contributors = to the WG to have the expertise. >=20 > regards, > Slava Borilin >=20 > -- > John Lazzaro wrote: > > A traditional response to this type of request is to note that = the IETF > > really doesn't have much in the way of expertise in audio = codec design. > > I don't see many of the regulars who present at the AES codec = paper sessions > > posting here on AVT (ditto ICASSP paper sessions for voice = codecs). It's > > a full-time job to keep up-to-date and contribute to that > > signal-processing lore. > > =20 > > Well, there's no reason that the IETF cannot build such an = expertise > in audio codecs. This is actually something in which I'd be = interested > in getting involved and I'm sure others at Xiph.Org would be > interested as well. We have several people with audio codec = expertise > from working on Vorbis, Speex and (more recently) CELT. It turns = out > that the CELT codec currently under development at Xiph actually = meets > most of the requirements from the original proposal in being a = very > low delay codec with adaptive bit-rate and sampling rate (up to 48 > kHz), scalable complexity, and good robustness to packet loss. = We'd be > willing to continue the development with the IETF. Even if not = with > CELT, it's still like to be involved in such a new WG. > > Cheers, >=20 > Jean-Marc -------------------------------------------------------------------------= ----- _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch ------=_NextPart_000_330A_01C9E377.8A1F24C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [AVT] [dispatch] Proposal to form Internet = Wideband Audio Codec WG
I am not an area director, nor do i play one on = IPTV, but my=20 suggestion for anyone interested would be to
 
- request a non-WG mailing list (from either of the = RAI area=20 directors),
 
- announce it on this mailing list (and others that = seem to be=20 appropriate, and
 
- start discussions, which the area directors = typically look=20 at when judging whether there's enough interest and enough clue to = justify=20 approving a BOF and/or chartering a working group.
 
I didn't see a mailing list included in Jason's = proposal - if=20 I missed one, my apologies.
 
If people at the IETF can do this work, and want to = do this=20 work, IETF process policies should not get in the way of that=20 happening.
 
And I haven't heard of an AD turning down a request = for a=20 non-WG mailing list yet, keeping in mind that one of said lists is = ietf-sailors,=20 for people interested in sailing to/from/at IETF meetings - the bar is=20 (appropriately) low.
 
Thanks,

Spencer
----- Original Message -----
From:=20 Henry = Sinnreich
To: Roni Even ; Jean-Marc Valin
Cc: dispatch@ietf.org ; Slava=20 Borilin ; avt@ietf.org
Sent: Tuesday, June 02, 2009 = 11:12=20 AM
Subject: Re: [dispatch] [AVT] = Proposal to=20 form Internet Wideband Audio Codec WG

>This leaves the other reasons I heard = for doing it=20 at the IETF which is the
>price of participating

This = is an=20 important point.
Given the travel constraints for some of the most = valuable=20 potential contributors and reviewers, could we envisage online work = until the=20 economy improves, so that an eventual BOF to start with should not be = starved=20 of attendees? An online BOF?

There are several free online = meeting=20 tools available...

How can this be done within the IETF=20 policy?

Henry


On 6/2/09 10:57 AM, "Roni Even" <Even.roni@huawei.com>=20 wrote:
Hi,
I do not want to sound like someone = who is=20 for IPR (I am not), but why stop
at codec, let's require it for = all IETF=20 work. There are IPR on IETF work
which is must simpler, in my = view, than=20 wide band audio codecs.

I think that we can start with = "royalty free"=20 even though I am not sure that
it will accepted as part of the = charter of=20 any other work group so why pick
on codecs which require more=20 work.

This leaves the other reasons I heard for doing it at = the IETF=20 which is the
price of participating (cheaper than being an ITU-T = member)=20 and maybe design
less expensive characterization=20 tests.

Roni


-----Original Message-----
From: = Jean-Marc=20 Valin [mailto:jean-marc.valin@octasi= c.com]
Sent:=20 Tuesday, June 02, 2009 6:14 PM
To: Roni Even
Cc: 'Slava = Borilin'; avt@ietf.org; 'Jason Fischl'; dispatch@ietf.org;
hsinnrei@adobe.com
Subject: Re: = [AVT]=20 [dispatch] Proposal to form Internet Wideband Audio=20 Codec
WG

Hi,

Roni Even wrote:
>
> I am = not sure=20 what prevented you from doing it today at the ITU or
> MPEG, = why do=20 you see the IETF handling it differently.
>
> I would = also like=20 to remind you and Jean-Marc that once you are
> bringing work = to a=20 standard body it may require collaboration with
> other people = who=20 will have other proposals that will also address the
> same=20 requirements and you may need to invest money in comparative
> = testing=20 by independent listening labs.
>
> I also think that you = will=20 need to supply the codec in source code and
> provide copy = right to=20 the IETF.
>

I am well aware that bringing work to the = IETF=20 would require
collaboration with others. I am not seeking control = over=20 the work I am
currently doing and would really welcome such=20 collaboration. The idea is
only to have the best wideband codec = possible=20 without IPR issues. Given
the ITU and MPEG track record, I think = it would=20 be very unlikely for any
of those organisations to work on an = IPR-free=20 codec.

I also agree with Henry that "the Internet has = different=20 criteria than
ITU-T networks may have". Internet adoption follows = different patterns
than adoption in the ITU primary target = markets. For=20 example, the
Internet has more consumer-reconfigurable software, = while=20 the ITU has to
deal with a lot of fixed hardware deployments. At = the ITU,=20 it makes
sense to invest large sums of money into testing and=20 characterisation of
codecs because the codecs deployed there = usually stay=20 around for a long
time and the infrastructure investments are = usually=20 very large. On the
other hand, I would say the investments in = codecs for=20 the Internet are
comparatively smaller and, while testing is = still=20 important, it is not
as critical as it is for the = ITU.

It's also a=20 choice one has to make. It is unlikely that companies = would
invest money=20 in expensive testing if they are not going to obtain
royalties in = return.=20 However, I think we may be able to define some more
lightweight=20 (collaborative?) testing that is sufficient and doesn't
involve = as much=20 investments as what the ITU does. For the Internet, I
believe an = IPR-free=20 codec that everyone agrees performs well is better
than a=20 patent-encumbered codec that has had more extensive testing. = This
is=20 again another difference with the ITU: patent-encumbered codecs = tend
to=20 hurt a lot more on the Internet because many applications = (e.g.
giving=20 away the client) are very hard (or impossible) when one has = to
pay=20 per-channel royalties.

As for the source code issue you = pointed out,=20 all the Xiph codecs are
already published under a very permissive = open=20 source license (BSD), so
this would not really=20 change.

    Jean-Marc

>=20 Roni
>
>
>
> *From:* avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] = *On=20 Behalf
> Of *Slava Borilin
> *Sent:* Monday, June 01, = 2009 11:50=20 PM
> *To:* jean-marc.valin@octasic.com
&= gt;=20 *Cc:* avt@ietf.org; Jason = Fischl
>=20 *Subject:* Re: [AVT] [dispatch] Proposal to form Internet = Wideband
>=20 Audio Codec WG
>
>
>
> Agree with=20 Jean-Marc.
> SPIRIT is interested to contribute as well - = having a=20 dozen of proprietary
codecs developed, including
> one = specifically=20 desgined for internet (SPIRIT IP-MR, which is now under
WGLC on=20 draft-ietf-avt-rtp-ipmr-04) -
> multi-rate, scalable, = adaptive,=20 wideband codec.
>
> We can also continue this work with = IETF.
>
> Moreover, most if not all efforts coming from = ITU on=20 codecs unfortunately
are NOT really focused on
> = internet-specific=20 codecs (that's why several companies have had to invent)
- as ITU = preference is mainly
> specific (i.e. cellular) networks at=20 first.
>
> however, as we see the greant rise of pure=20 "internet-basd communications"
(skype, webex/citrix, and many = others)=20 -
> we all (and users) are suffering from inefficiency in all=20 currently
"standard" codecs and ambiguity in the choice = of
>=20 internet-targeted ones.
>
> Again, we probably can put = together=20 enough number of contributors to the
WG to have the = expertise.
>=20
> regards,
> Slava Borilin
>
> --
> = John=20 Lazzaro wrote:
>
>     A traditional = response to this type of request is to note that = the
IETF
>
>=20     really doesn't have much in the way of = expertise in=20 audio codec
design.
>
>     I = don't see=20 many of the regulars who present at the AES codec=20 paper
sessions
>
>     posting = here on=20 AVT (ditto ICASSP paper sessions for voice = codecs).
It's
>
>=20     a full-time job to keep up-to-date and = contribute to=20 that
>
>     signal-processing=20 lore.
>
>     
>
> Well, = there's=20 no reason that the IETF cannot build such an expertise
> in = audio=20 codecs. This is actually something in which I'd be = interested
> in=20 getting involved and I'm sure others at Xiph.Org would be
> = interested=20 as well. We have several people with audio codec expertise
> = from=20 working on Vorbis, Speex and (more recently) CELT. It turns = out
> that=20 the CELT codec currently under development at Xiph actually = meets
>=20 most of the requirements from the original proposal in being a = very
>=20 low delay codec with adaptive bit-rate and sampling rate (up to = 48
>=20 kHz), scalable complexity, and good robustness to packet loss. We'd=20 be
> willing to continue the development with the IETF. Even = if not=20 with
> CELT, it's still like to be involved in such a new=20 WG.
>
> Cheers,
>
>=20    Jean-Marc


_______________________________________________
dispatch = mailing=20 = list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispat= ch
------=_NextPart_000_330A_01C9E377.8A1F24C0-- From Borilin@spiritdsp.com Tue Jun 2 10:34:42 2009 Return-Path: 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 081FE3A6B0A; Tue, 2 Jun 2009 10:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.188 X-Spam-Level: X-Spam-Status: No, score=0.188 tagged_above=-999 required=5 tests=[AWL=-1.969, BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, MANGLED_INXPNS=2.3] 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 1jjpmJKmbzZw; Tue, 2 Jun 2009 10:34:40 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id 236F03A6F44; Tue, 2 Jun 2009 10:34:36 -0700 (PDT) Received: from mail-srv.spiritcorp.com (mail-srv.spiritcorp.com [192.168.125.3]) by mail3.spiritcorp.com (8.13.8/8.14.3) with SMTP id n52HXu8Z066709; Tue, 2 Jun 2009 21:33:57 +0400 (MSD) (envelope-from Borilin@spiritdsp.com) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9E3A8.4D82F4FA" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 2 Jun 2009 21:33:54 +0400 Message-ID: In-Reply-To: <6e9223710906021031i31e024dam5673ca9608017d73@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] [dispatch] Proposal to form Internet Wideband Audio Codec WG Thread-Index: AcnjqANErfh4GUqeQ4SC5NZuzNxHZgAAB2LQ References: <00a401c9e388$b25c2350$171469f0$%roni@huawei.com> <4A2541B9.2000805@octasic.com> <00d501c9e39a$dcbbbe50$96333af0$%roni@huawei.com> <6e9223710906021031i31e024dam5673ca9608017d73@mail.gmail.com> From: "Slava Borilin" To: "stephen botzko" , "Henning Schulzrinne" X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Cc: hsinnrei@adobe.com, dispatch@ietf.org, avt@ietf.org, Roni Even Subject: Re: [dispatch] [AVT] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 17:34:42 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9E3A8.4D82F4FA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I do not beleive the one that will come wil be low quality. at least people from the potential contributors (at least Skype, Speex, SPIRIT) are already pretty-good in the commercially exploiting their own codecs on the market. i think this is probably false alert. =20 regards, Slava Borilin =20 =20 ________________________________ From: stephen botzko [mailto:stephen.botzko@gmail.com]=20 Sent: Tuesday, June 02, 2009 9:32 PM To: Henning Schulzrinne Cc: Roni Even; dispatch@ietf.org; Jason Fischl; avt@ietf.org; hsinnrei@adobe.com; Slava Borilin Subject: Re: [AVT] [dispatch] Proposal to form Internet Wideband Audio Codec WG >>> - the quality of the codec may not be competitive I think its very important that the codec quality be competitive. People expect excellence from IETF standards Standardizing non-competitive codecs because they are cheap does not seem to be a good choce. Steve B. On Tue, Jun 2, 2009 at 12:15 PM, Henning Schulzrinne wrote: I view this as a trade-off. If we pursue this, there are risks: =09 - nothing may come of it since there are no experts willing to help - somebody will claim IPR on the resulting work - the quality of the codec may not be competitive =09 However, if we don't do this, we are stuck with the status quo, which is not all that satisfactory. Thus, unless there are significant costs for "innocent bystanders", I see this as a risk worth taking. In the worst case, we are no worse off than we are today. In all other cases, we'll have an additional choice for a wideband codec, even if it's not "the best", just "good enough". After all, most people use G.711 today, which has a really hard time making that claim. =09 Most real work in the IETF is done by very small teams, typically less than 10, so as long as we have a handful of people that are willing to contribute, this can work. It might even work better, since you may get fewer people who have half-baked opinions - we may skip the binary vs. XML debates... =09 We can set some ground rules ("must be tested with packet loss of 5%") and then see what happens. Compared to most network protocols, the likely negative impacts (such as security or congestion control issues) of even a badly-designed codec are pretty limited. =09 Henning=20 On Jun 2, 2009, at 11:57 AM, Roni Even wrote: =09 =09 Hi, I do not want to sound like someone who is for IPR (I am not), but why stop at codec, let's require it for all IETF work. There are IPR on IETF work which is must simpler, in my view, than wide band audio codecs. =09 I think that we can start with "royalty free" even though I am not sure that it will accepted as part of the charter of any other work group so why pick on codecs which require more work. =09 This leaves the other reasons I heard for doing it at the IETF which is the price of participating (cheaper than being an ITU-T member) and maybe design less expensive characterization tests. =09 Roni =09 =09 -----Original Message----- From: Jean-Marc Valin [mailto:jean-marc.valin@octasic.com] Sent: Tuesday, June 02, 2009 6:14 PM To: Roni Even Cc: 'Slava Borilin'; avt@ietf.org; 'Jason Fischl'; dispatch@ietf.org; hsinnrei@adobe.com Subject: Re: [AVT] [dispatch] Proposal to form Internet Wideband Audio Codec WG =09 Hi, =09 Roni Even wrote: =09 I am not sure what prevented you from doing it today at the ITU or MPEG, why do you see the IETF handling it differently. =09 I would also like to remind you and Jean-Marc that once you are bringing work to a standard body it may require collaboration with other people who will have other proposals that will also address the same requirements and you may need to invest money in comparative testing by independent listening labs. =09 I also think that you will need to supply the codec in source code and provide copy right to the IETF. =09 =09 I am well aware that bringing work to the IETF would require collaboration with others. I am not seeking control over the work I am currently doing and would really welcome such collaboration. The idea is only to have the best wideband codec possible without IPR issues. Given the ITU and MPEG track record, I think it would be very unlikely for any of those organisations to work on an IPR-free codec. =09 I also agree with Henry that "the Internet has different criteria than ITU-T networks may have". Internet adoption follows different patterns than adoption in the ITU primary target markets. For example, the Internet has more consumer-reconfigurable software, while the ITU has to deal with a lot of fixed hardware deployments. At the ITU, it makes sense to invest large sums of money into testing and characterisation of codecs because the codecs deployed there usually stay around for a long time and the infrastructure investments are usually very large. On the other hand, I would say the investments in codecs for the Internet are comparatively smaller and, while testing is still important, it is not as critical as it is for the ITU. =09 It's also a choice one has to make. It is unlikely that companies would invest money in expensive testing if they are not going to obtain royalties in return. However, I think we may be able to define some more lightweight (collaborative?) testing that is sufficient and doesn't involve as much investments as what the ITU does. For the Internet, I believe an IPR-free codec that everyone agrees performs well is better than a patent-encumbered codec that has had more extensive testing. This is again another difference with the ITU: patent-encumbered codecs tend to hurt a lot more on the Internet because many applications (e.g. giving away the client) are very hard (or impossible) when one has to pay per-channel royalties. =09 As for the source code issue you pointed out, all the Xiph codecs are already published under a very permissive open source license (BSD), so this would not really change. =09 Jean-Marc =09 =09 Roni =09 =09 =09 *From:* avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] *On Behalf Of *Slava Borilin *Sent:* Monday, June 01, 2009 11:50 PM *To:* jean-marc.valin@octasic.com *Cc:* avt@ietf.org; Jason Fischl *Subject:* Re: [AVT] [dispatch] Proposal to form Internet Wideband Audio Codec WG =09 =09 =09 Agree with Jean-Marc. SPIRIT is interested to contribute as well - having a dozen of proprietary =09 codecs developed, including =09 one specifically desgined for internet (SPIRIT IP-MR, which is now under =09 WGLC on draft-ietf-avt-rtp-ipmr-04) - =09 multi-rate, scalable, adaptive, wideband codec. =09 We can also continue this work with IETF. =09 Moreover, most if not all efforts coming from ITU on codecs unfortunately =09 are NOT really focused on =09 internet-specific codecs (that's why several companies have had to invent) =09 - as ITU preference is mainly =09 specific (i.e. cellular) networks at first. =09 however, as we see the greant rise of pure "internet-basd communications" =09 (skype, webex/citrix, and many others) - =09 we all (and users) are suffering from inefficiency in all currently =09 "standard" codecs and ambiguity in the choice of =09 internet-targeted ones. =09 Again, we probably can put together enough number of contributors to the =09 WG to have the expertise. =09 regards, Slava Borilin =09 -- John Lazzaro wrote: =09 A traditional response to this type of request is to note that the =09 IETF =09 really doesn't have much in the way of expertise in audio codec =09 design. =09 I don't see many of the regulars who present at the AES codec paper =09 sessions =09 posting here on AVT (ditto ICASSP paper sessions for voice codecs). =09 It's =09 a full-time job to keep up-to-date and contribute to that =09 signal-processing lore. =09 =09 =09 Well, there's no reason that the IETF cannot build such an expertise in audio codecs. This is actually something in which I'd be interested in getting involved and I'm sure others at Xiph.Org would be interested as well. We have several people with audio codec expertise from working on Vorbis, Speex and (more recently) CELT. It turns out that the CELT codec currently under development at Xiph actually meets most of the requirements from the original proposal in being a very low delay codec with adaptive bit-rate and sampling rate (up to 48 kHz), scalable complexity, and good robustness to packet loss. We'd be willing to continue the development with the IETF. Even if not with CELT, it's still like to be involved in such a new WG. =09 Cheers, =09 Jean-Marc =09 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www.ietf.org/mailman/listinfo/avt =09 =09 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www.ietf.org/mailman/listinfo/avt =09 ------_=_NextPart_001_01C9E3A8.4D82F4FA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I do not beleive the one that will come wil be = low=20 quality.
at least people from the potential contributors = (at least=20 Skype, Speex, SPIRIT) are already pretty-good in the commercially = exploiting=20 their own codecs on the market.
i think this is probably false = alert.
 
regards,
Slava Borilin
 
 

From: stephen botzko=20 [mailto:stephen.botzko@gmail.com]
Sent: Tuesday, June 02, = 2009 9:32=20 PM
To: Henning Schulzrinne
Cc: Roni Even; = dispatch@ietf.org;=20 Jason Fischl; avt@ietf.org; hsinnrei@adobe.com; Slava = Borilin
Subject:=20 Re: [AVT] [dispatch] Proposal to form Internet Wideband Audio Codec=20 WG

>>> - the quality of the codec may not be=20 competitive

I think its very important that the codec quality be=20 competitive.  People expect excellence from IETF standards =20 Standardizing non-competitive codecs because they are cheap does not = seem to be=20 a good choce.

Steve B.

On Tue, Jun 2, 2009 at 12:15 PM, Henning = Schulzrinne=20 <hgs@cs.columbia.edu> = wrote:
I=20 view this as a trade-off. If we pursue this, there are risks:

- = nothing=20 may come of it since there are no experts willing to help
- = somebody will=20 claim IPR on the resulting work
- the quality of the codec may not = be=20 competitive

However, if we don't do this, we are stuck with the = status=20 quo, which is not all that satisfactory. Thus, unless there are = significant=20 costs for "innocent bystanders", I see this as a risk worth taking. In = the=20 worst case, we are no worse off than we are today. In all other cases, = we'll=20 have an additional choice for a wideband codec, even if it's not "the = best",=20 just "good enough". After all, most people use G.711 today, which has = a really=20 hard time making that claim.

Most real work in the IETF is done = by very=20 small teams, typically less than 10, so as long as we have a handful = of people=20 that are willing to contribute, this can work. It might even work = better,=20 since you may get fewer people who have half-baked opinions - we may = skip the=20 binary vs. XML debates...

We can set some ground rules ("must = be tested=20 with packet loss of 5%") and then see what happens. Compared to most = network=20 protocols, the likely negative impacts (such as security or congestion = control=20 issues) of even a badly-designed codec are pretty limited.

Henning


On Jun 2, 2009, at 11:57 AM, Roni Even = wrote:

Hi,
I=20 do not want to sound like someone who is for IPR (I am not), but why = stop
at codec, let's require it for all IETF work. There are IPR = on IETF=20 work
which is must simpler, in my view, than wide band audio=20 codecs.

I think that we can start with "royalty free" even = though I=20 am not sure that
it will accepted as part of the charter of any = other=20 work group so why pick
on codecs which require more = work.

This=20 leaves the other reasons I heard for doing it at the IETF which is=20 the
price of participating (cheaper than being an ITU-T member) = and maybe=20 design
less expensive characterization=20 tests.

Roni


-----Original Message-----
From: = Jean-Marc=20 Valin [mailto:jean-marc.valin@octasic.com]
Sent: Tuesday, = June 02,=20 2009 6:14 PM
To: Roni Even
Cc: 'Slava Borilin'; avt@ietf.org; = 'Jason Fischl';=20 dispatch@ietf.org;
hsinnrei@adobe.com
Subject: Re: [AVT] = [dispatch]=20 Proposal to form Internet Wideband Audio = Codec
WG

Hi,

Roni=20 Even wrote:

I=20 am not sure what prevented you from doing it today at the ITU = or
MPEG,=20 why do you see the IETF handling it differently.

I would = also like=20 to remind you and Jean-Marc that once you are
bringing work to = a=20 standard body it may require collaboration with
other people = who will=20 have other proposals that will also address the
same = requirements and=20 you may need to invest money in comparative
testing by = independent=20 listening labs.

I also think that you will need to supply = the codec=20 in source code and
provide copy right to the=20 IETF.


I am well aware that bringing work to = the IETF=20 would require
collaboration with others. I am not seeking control = over=20 the work I am
currently doing and would really welcome such=20 collaboration. The idea is
only to have the best wideband codec = possible=20 without IPR issues. Given
the ITU and MPEG track record, I think = it would=20 be very unlikely for any
of those organisations to work on an = IPR-free=20 codec.

I also agree with Henry that "the Internet has = different=20 criteria than
ITU-T networks may have". Internet adoption follows = different patterns
than adoption in the ITU primary target = markets. For=20 example, the
Internet has more consumer-reconfigurable software, = while=20 the ITU has to
deal with a lot of fixed hardware deployments. At = the ITU,=20 it makes
sense to invest large sums of money into testing and=20 characterisation of
codecs because the codecs deployed there = usually stay=20 around for a long
time and the infrastructure investments are = usually=20 very large. On the
other hand, I would say the investments in = codecs for=20 the Internet are
comparatively smaller and, while testing is = still=20 important, it is not
as critical as it is for the = ITU.

It's also a=20 choice one has to make. It is unlikely that companies = would
invest money=20 in expensive testing if they are not going to obtain
royalties in = return.=20 However, I think we may be able to define some more
lightweight=20 (collaborative?) testing that is sufficient and doesn't
involve = as much=20 investments as what the ITU does. For the Internet, I
believe an = IPR-free=20 codec that everyone agrees performs well is better
than a=20 patent-encumbered codec that has had more extensive testing. = This
is=20 again another difference with the ITU: patent-encumbered codecs = tend
to=20 hurt a lot more on the Internet because many applications = (e.g.
giving=20 away the client) are very hard (or impossible) when one has = to
pay=20 per-channel royalties.

As for the source code issue you = pointed out,=20 all the Xiph codecs are
already published under a very permissive = open=20 source license (BSD), so
this would not really = change.

 =20 Jean-Marc

Roni



*From:*=20 avt-bounces@ietf.org [mailto:avt-bounces@ietf.org]=20 *On Behalf
Of *Slava Borilin
*Sent:* Monday, June 01, 2009 = 11:50=20 PM
*To:* jean-marc.valin@octasic.com
*Cc:* avt@ietf.org; = Jason=20 Fischl
*Subject:* Re: [AVT] [dispatch] Proposal to form = Internet=20 Wideband
Audio Codec WG



Agree with = Jean-Marc.
SPIRIT=20 is interested to contribute as well - having a dozen of=20 proprietary
codecs developed, including
one=20 specifically desgined for internet (SPIRIT IP-MR, which is now=20 under
WGLC on draft-ietf-avt-rtp-ipmr-04) -
multi-rate,=20 scalable, adaptive, wideband codec.

We can also continue = this work=20 with IETF.

Moreover, most if not all efforts coming from = ITU on=20 codecs unfortunately
are NOT really focused on
internet-specific=20 codecs (that's why several companies have had to = invent)
-=20 as ITU preference is mainly
specific=20 (i.e. cellular) networks at first.

however, as we see the = greant=20 rise of pure "internet-basd = communications"
(skype,=20 webex/citrix, and many others) -
we=20 all (and users) are suffering from inefficiency in all=20 currently
"standard" codecs and ambiguity in the = choice=20 of
internet-targeted=20 ones.

Again, we probably can put together enough number of=20 contributors to the
WG to have the expertise.

regards,
Slava=20 Borilin

--
John Lazzaro wrote:

  A = traditional=20 response to this type of request is to note that=20 the
IETF

 =20 really doesn't have much in the way of expertise in audio=20 codec
design.

 =20 I don't see many of the regulars who present at the AES codec=20 paper
sessions

 =20 posting here on AVT (ditto ICASSP paper sessions for voice=20 codecs).
It's

 =20 a full-time job to keep up-to-date and contribute to = that

 =20 signal-processing lore.



Well, there's no reason = that the=20 IETF cannot build such an expertise
in audio codecs. This is = actually=20 something in which I'd be interested
in getting involved and = I'm sure=20 others at Xiph.Org would be
interested as well. We have several = people=20 with audio codec expertise
from working on Vorbis, Speex and = (more=20 recently) CELT. It turns out
that the CELT codec currently = under=20 development at Xiph actually meets
most of the requirements = from the=20 original proposal in being a very
low delay codec with adaptive = bit-rate and sampling rate (up to 48
kHz), scalable complexity, = and=20 good robustness to packet loss. We'd be
willing to continue the = development with the IETF. Even if not with
CELT, it's still = like to be=20 involved in such a new=20 = WG.

Cheers,

 Jean-Marc

___________= ____________________________________
Audio/Video=20 Transport Working Group
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt


_______________________________________________
Audio/Vid= eo=20 Transport Working Group
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt

------_=_NextPart_001_01C9E3A8.4D82F4FA-- From stephen.botzko@gmail.com Tue Jun 2 10:31:47 2009 Return-Path: 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 779443A6A98; Tue, 2 Jun 2009 10:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.221 X-Spam-Level: X-Spam-Status: No, score=-0.221 tagged_above=-999 required=5 tests=[AWL=-2.377, BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, MANGLED_INXPNS=2.3] 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 osBeYUdR697a; Tue, 2 Jun 2009 10:31:45 -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 9238E3A6A67; Tue, 2 Jun 2009 10:31:44 -0700 (PDT) Received: by bwz22 with SMTP id 22so8322580bwz.37 for ; Tue, 02 Jun 2009 10:31:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=jkgqDHIpZ6KxglHw47dOJDV66Sr19ceaA57LXBLDBa4=; b=ZFUPck9V+oxspYr4lAd8gUipdsmz8vdZm737zDg3+n2sjj0mh0OCukghUVzur8Xo63 GelUjxMPQymA4eUPSf4omJ0+2yCpAzQzqJUhjghAsbAmV3NfYVjAXI52ESuzej5AvROF MYSzBYyQwNzr0eJSjsemPl37FBuTdY9g4ViaY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NL+k3qvpjGJos1pqDCTyizg4V1h7XIWlbnOj2yFtjMEv15DPRdSgWwC83nPuwVoeex 0aZh+bk6HEVlb7P765mqLcAd2uFFCZJ8OjH2CITYqalqzhSL4iscnnk8UBkNYoVte0ok iBNqRPmQv9xXCAEUCeWIg9I5s0hTycQE66sok= MIME-Version: 1.0 Received: by 10.103.176.20 with SMTP id d20mr4127295mup.27.1243963899982; Tue, 02 Jun 2009 10:31:39 -0700 (PDT) In-Reply-To: References: <00a401c9e388$b25c2350$171469f0$%roni@huawei.com> <4A2541B9.2000805@octasic.com> <00d501c9e39a$dcbbbe50$96333af0$%roni@huawei.com> Date: Tue, 2 Jun 2009 13:31:39 -0400 Message-ID: <6e9223710906021031i31e024dam5673ca9608017d73@mail.gmail.com> From: stephen botzko To: Henning Schulzrinne Content-Type: multipart/alternative; boundary=00163641759b5f3983046b60ea82 X-Mailman-Approved-At: Tue, 02 Jun 2009 10:37:24 -0700 Cc: dispatch@ietf.org, avt@ietf.org, Roni Even , hsinnrei@adobe.com, Slava Borilin Subject: Re: [dispatch] [AVT] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 17:31:47 -0000 --00163641759b5f3983046b60ea82 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit >>> - the quality of the codec may not be competitive I think its very important that the codec quality be competitive. People expect excellence from IETF standards Standardizing non-competitive codecs because they are cheap does not seem to be a good choce. Steve B. On Tue, Jun 2, 2009 at 12:15 PM, Henning Schulzrinne wrote: > I view this as a trade-off. If we pursue this, there are risks: > > - nothing may come of it since there are no experts willing to help > - somebody will claim IPR on the resulting work > - the quality of the codec may not be competitive > > However, if we don't do this, we are stuck with the status quo, which is > not all that satisfactory. Thus, unless there are significant costs for > "innocent bystanders", I see this as a risk worth taking. In the worst case, > we are no worse off than we are today. In all other cases, we'll have an > additional choice for a wideband codec, even if it's not "the best", just > "good enough". After all, most people use G.711 today, which has a really > hard time making that claim. > > Most real work in the IETF is done by very small teams, typically less than > 10, so as long as we have a handful of people that are willing to > contribute, this can work. It might even work better, since you may get > fewer people who have half-baked opinions - we may skip the binary vs. XML > debates... > > We can set some ground rules ("must be tested with packet loss of 5%") and > then see what happens. Compared to most network protocols, the likely > negative impacts (such as security or congestion control issues) of even a > badly-designed codec are pretty limited. > > Henning > > > On Jun 2, 2009, at 11:57 AM, Roni Even wrote: > > Hi, >> I do not want to sound like someone who is for IPR (I am not), but why >> stop >> at codec, let's require it for all IETF work. There are IPR on IETF work >> which is must simpler, in my view, than wide band audio codecs. >> >> I think that we can start with "royalty free" even though I am not sure >> that >> it will accepted as part of the charter of any other work group so why >> pick >> on codecs which require more work. >> >> This leaves the other reasons I heard for doing it at the IETF which is >> the >> price of participating (cheaper than being an ITU-T member) and maybe >> design >> less expensive characterization tests. >> >> Roni >> >> >> -----Original Message----- >> From: Jean-Marc Valin [mailto:jean-marc.valin@octasic.com] >> Sent: Tuesday, June 02, 2009 6:14 PM >> To: Roni Even >> Cc: 'Slava Borilin'; avt@ietf.org; 'Jason Fischl'; dispatch@ietf.org; >> hsinnrei@adobe.com >> Subject: Re: [AVT] [dispatch] Proposal to form Internet Wideband Audio >> Codec >> WG >> >> Hi, >> >> Roni Even wrote: >> >>> >>> I am not sure what prevented you from doing it today at the ITU or >>> MPEG, why do you see the IETF handling it differently. >>> >>> I would also like to remind you and Jean-Marc that once you are >>> bringing work to a standard body it may require collaboration with >>> other people who will have other proposals that will also address the >>> same requirements and you may need to invest money in comparative >>> testing by independent listening labs. >>> >>> I also think that you will need to supply the codec in source code and >>> provide copy right to the IETF. >>> >>> >> I am well aware that bringing work to the IETF would require >> collaboration with others. I am not seeking control over the work I am >> currently doing and would really welcome such collaboration. The idea is >> only to have the best wideband codec possible without IPR issues. Given >> the ITU and MPEG track record, I think it would be very unlikely for any >> of those organisations to work on an IPR-free codec. >> >> I also agree with Henry that "the Internet has different criteria than >> ITU-T networks may have". Internet adoption follows different patterns >> than adoption in the ITU primary target markets. For example, the >> Internet has more consumer-reconfigurable software, while the ITU has to >> deal with a lot of fixed hardware deployments. At the ITU, it makes >> sense to invest large sums of money into testing and characterisation of >> codecs because the codecs deployed there usually stay around for a long >> time and the infrastructure investments are usually very large. On the >> other hand, I would say the investments in codecs for the Internet are >> comparatively smaller and, while testing is still important, it is not >> as critical as it is for the ITU. >> >> It's also a choice one has to make. It is unlikely that companies would >> invest money in expensive testing if they are not going to obtain >> royalties in return. However, I think we may be able to define some more >> lightweight (collaborative?) testing that is sufficient and doesn't >> involve as much investments as what the ITU does. For the Internet, I >> believe an IPR-free codec that everyone agrees performs well is better >> than a patent-encumbered codec that has had more extensive testing. This >> is again another difference with the ITU: patent-encumbered codecs tend >> to hurt a lot more on the Internet because many applications (e.g. >> giving away the client) are very hard (or impossible) when one has to >> pay per-channel royalties. >> >> As for the source code issue you pointed out, all the Xiph codecs are >> already published under a very permissive open source license (BSD), so >> this would not really change. >> >> Jean-Marc >> >> Roni >>> >>> >>> >>> *From:* avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] *On Behalf >>> Of *Slava Borilin >>> *Sent:* Monday, June 01, 2009 11:50 PM >>> *To:* jean-marc.valin@octasic.com >>> *Cc:* avt@ietf.org; Jason Fischl >>> *Subject:* Re: [AVT] [dispatch] Proposal to form Internet Wideband >>> Audio Codec WG >>> >>> >>> >>> Agree with Jean-Marc. >>> SPIRIT is interested to contribute as well - having a dozen of >>> proprietary >>> >> codecs developed, including >> >>> one specifically desgined for internet (SPIRIT IP-MR, which is now under >>> >> WGLC on draft-ietf-avt-rtp-ipmr-04) - >> >>> multi-rate, scalable, adaptive, wideband codec. >>> >>> We can also continue this work with IETF. >>> >>> Moreover, most if not all efforts coming from ITU on codecs unfortunately >>> >> are NOT really focused on >> >>> internet-specific codecs (that's why several companies have had to >>> invent) >>> >> - as ITU preference is mainly >> >>> specific (i.e. cellular) networks at first. >>> >>> however, as we see the greant rise of pure "internet-basd communications" >>> >> (skype, webex/citrix, and many others) - >> >>> we all (and users) are suffering from inefficiency in all currently >>> >> "standard" codecs and ambiguity in the choice of >> >>> internet-targeted ones. >>> >>> Again, we probably can put together enough number of contributors to the >>> >> WG to have the expertise. >> >>> >>> regards, >>> Slava Borilin >>> >>> -- >>> John Lazzaro wrote: >>> >>> A traditional response to this type of request is to note that the >>> >> IETF >> >>> >>> really doesn't have much in the way of expertise in audio codec >>> >> design. >> >>> >>> I don't see many of the regulars who present at the AES codec paper >>> >> sessions >> >>> >>> posting here on AVT (ditto ICASSP paper sessions for voice codecs). >>> >> It's >> >>> >>> a full-time job to keep up-to-date and contribute to that >>> >>> signal-processing lore. >>> >>> >>> >>> Well, there's no reason that the IETF cannot build such an expertise >>> in audio codecs. This is actually something in which I'd be interested >>> in getting involved and I'm sure others at Xiph.Org would be >>> interested as well. We have several people with audio codec expertise >>> from working on Vorbis, Speex and (more recently) CELT. It turns out >>> that the CELT codec currently under development at Xiph actually meets >>> most of the requirements from the original proposal in being a very >>> low delay codec with adaptive bit-rate and sampling rate (up to 48 >>> kHz), scalable complexity, and good robustness to packet loss. We'd be >>> willing to continue the development with the IETF. Even if not with >>> CELT, it's still like to be involved in such a new WG. >>> >>> Cheers, >>> >>> Jean-Marc >>> >> >> _______________________________________________ >> Audio/Video Transport Working Group >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt >> >> > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > --00163641759b5f3983046b60ea82 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >>> - the quality of the codec may not be competitive

I thi= nk its very important that the codec quality be competitive.=A0 People expe= ct excellence from IETF standards=A0 Standardizing non-competitive codecs b= ecause they are cheap does not seem to be a good choce.

Steve B.

On Tue, Jun 2, 2009 at 12:15= PM, Henning Schulzrinne <hgs@cs.columbia.edu> wrote:
I view this as a trade-off. If we pursue this, there are risks:

- nothing may come of it since there are no experts willing to help
- somebody will claim IPR on the resulting work
- the quality of the codec may not be competitive

However, if we don't do this, we are stuck with the status quo, which i= s not all that satisfactory. Thus, unless there are significant costs for &= quot;innocent bystanders", I see this as a risk worth taking. In the w= orst case, we are no worse off than we are today. In all other cases, we= 9;ll have an additional choice for a wideband codec, even if it's not &= quot;the best", just "good enough". After all, most people u= se G.711 today, which has a really hard time making that claim.

Most real work in the IETF is done by very small teams, typically less than= 10, so as long as we have a handful of people that are willing to contribu= te, this can work. It might even work better, since you may get fewer peopl= e who have half-baked opinions - we may skip the binary vs. XML debates...<= br>
We can set some ground rules ("must be tested with packet loss of 5%&q= uot;) and then see what happens. Compared to most network protocols, the li= kely negative impacts (such as security or congestion control issues) of ev= en a badly-designed codec are pretty limited.

Henning


On Jun 2, 2009, at 11:57 AM, Roni Even wrote:

Hi,
I do not want to sound like someone who is for IPR (I am not), but why stop=
at codec, let's require it for all IETF work. There are IPR on IETF wor= k
which is must simpler, in my view, than wide band audio codecs.

I think that we can start with "royalty free" even though I am no= t sure that
it will accepted as part of the charter of any other work group so why pick=
on codecs which require more work.

This leaves the other reasons I heard for doing it at the IETF which is the=
price of participating (cheaper than being an ITU-T member) and maybe desig= n
less expensive characterization tests.

Roni


-----Original Message-----
From: Jean-Marc Valin [mailto:jean-marc.valin@octasic.com]
Sent: Tuesday, June 02, 2009 6:14 PM
To: Roni Even
Cc: 'Slava Borilin'; avt@ietf.org; 'Jason Fischl'; dispatch@ietf.org;
hsinnrei@adobe.com<= /a>
Subject: Re: [AVT] [dispatch] Proposal to form Internet Wideband Audio Code= c
WG

Hi,

Roni Even wrote:

I am not sure what prevented you from doing it today at the ITU or
MPEG, why do you see the IETF handling it differently.

I would also like to remind you and Jean-Marc that once you are
bringing work to a standard body it may require collaboration with
other people who will have other proposals that will also address the
same requirements and you may need to invest money in comparative
testing by independent listening labs.

I also think that you will need to supply the codec in source code and
provide copy right to the IETF.


I am well aware that bringing work to the IETF would require
collaboration with others. I am not seeking control over the work I am
currently doing and would really welcome such collaboration. The idea is only to have the best wideband codec possible without IPR issues. Given
the ITU and MPEG track record, I think it would be very unlikely for any of those organisations to work on an IPR-free codec.

I also agree with Henry that "the Internet has different criteria than=
ITU-T networks may have". Internet adoption follows different patterns=
than adoption in the ITU primary target markets. For example, the
Internet has more consumer-reconfigurable software, while the ITU has to deal with a lot of fixed hardware deployments. At the ITU, it makes
sense to invest large sums of money into testing and characterisation of codecs because the codecs deployed there usually stay around for a long
time and the infrastructure investments are usually very large. On the
other hand, I would say the investments in codecs for the Internet are
comparatively smaller and, while testing is still important, it is not
as critical as it is for the ITU.

It's also a choice one has to make. It is unlikely that companies would=
invest money in expensive testing if they are not going to obtain
royalties in return. However, I think we may be able to define some more lightweight (collaborative?) testing that is sufficient and doesn't
involve as much investments as what the ITU does. For the Internet, I
believe an IPR-free codec that everyone agrees performs well is better
than a patent-encumbered codec that has had more extensive testing. This is again another difference with the ITU: patent-encumbered codecs tend
to hurt a lot more on the Internet because many applications (e.g.
giving away the client) are very hard (or impossible) when one has to
pay per-channel royalties.

As for the source code issue you pointed out, all the Xiph codecs are
already published under a very permissive open source license (BSD), so
this would not really change.

=A0 Jean-Marc

Roni



*From:* avt-bounc= es@ietf.org [mailto:avt-bounces@ietf.org] *On Behalf
Of *Slava Borilin
*Sent:* Monday, June 01, 2009 11:50 PM
*To:* jean= -marc.valin@octasic.com
*Cc:* avt@ietf.org; J= ason Fischl
*Subject:* Re: [AVT] [dispatch] Proposal to form Internet Wideband
Audio Codec WG



Agree with Jean-Marc.
SPIRIT is interested to contribute as well - having a dozen of proprietary<= br>
codecs developed, including
one specifically desgined for internet (SPIRIT IP-MR, which is now under
WGLC on draft-ietf-avt-rtp-ipmr-04) -
multi-rate, scalable, adaptive, wideband codec.

We can also continue this work with IETF.

Moreover, most if not all efforts coming from ITU on codecs unfortunately
are NOT really focused on
internet-specific codecs (that's why several companies have had to inve= nt)
- as ITU preference is mainly
specific (i.e. cellular) networks at first.

however, as we see the greant rise of pure "internet-basd communicatio= ns"
(skype, webex/citrix, and many others) -
we all (and users) are suffering from inefficiency in all currently
"standard" codecs and ambiguity in the choice of
internet-targeted ones.

Again, we probably can put together enough number of contributors to the
WG to have the expertise.

regards,
Slava Borilin

--
John Lazzaro wrote:

=A0 A traditional response to this type of request is to note that the
IETF

=A0 really doesn't have much in the way of expertise in audio codec
design.

=A0 I don't see many of the regulars who present at the AES codec pape= r
sessions

=A0 posting here on AVT (ditto ICASSP paper sessions for voice codecs).
It's

=A0 a full-time job to keep up-to-date and contribute to that

=A0 signal-processing lore.



Well, there's no reason that the IETF cannot build such an expertise in audio codecs. This is actually something in which I'd be interested<= br> in getting involved and I'm sure others at Xiph.Org would be
interested as well. We have several people with audio codec expertise
from working on Vorbis, Speex and (more recently) CELT. It turns out
that the CELT codec currently under development at Xiph actually meets
most of the requirements from the original proposal in being a very
low delay codec with adaptive bit-rate and sampling rate (up to 48
kHz), scalable complexity, and good robustness to packet loss. We'd be<= br> willing to continue the development with the IETF. Even if not with
CELT, it's still like to be involved in such a new WG.

Cheers,

=A0Jean-Marc

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/avt


_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/avt

--00163641759b5f3983046b60ea82-- From stephen.botzko@gmail.com Tue Jun 2 11:13:17 2009 Return-Path: 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 A8FDD28C133; Tue, 2 Jun 2009 11:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.968 X-Spam-Level: X-Spam-Status: No, score=0.968 tagged_above=-999 required=5 tests=[AWL=-1.189, BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, MANGLED_INXPNS=2.3] 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 LgXl-tmn6var; Tue, 2 Jun 2009 11:13:15 -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 D3B1328C12A; Tue, 2 Jun 2009 11:13:14 -0700 (PDT) Received: by bwz22 with SMTP id 22so8347888bwz.37 for ; Tue, 02 Jun 2009 11:13:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=kAh8a/DuAVpEEz58lf3r3fiqzsCQV7ZU6G+WM7tSUSo=; b=f1kQkkz3hGhUsIAfrV0NmGDUyWElYnBxg48sIn2VYL3A12rukSCDW8qdJXZps2i2/Y ZDjEw5U1s5fLVEpHzsjxmi0ht1eHRx78TqKIiA0lFDZ8FTCQ0tidfvaxtN7Ied7PIRaf YslbuFAQqA/NCgJfEsyk2V53yYZIbgoYAr6BU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=HYcTohrGrtWpjlOuM8P4RMf3s5jIqQ7O+MyJ/eIyBgWFD+9YgzVwhbTrk3oml0/Rtm QuOTFiHoPmptdRc+XicRD7shtTR0lZ1LSceXkNzMR/L5h484tRK3a5XBCSrKC2l+lMw5 o5yGzVWqKbk6A9wCMyF5Uk4KotZ6vaGKQIzMg= MIME-Version: 1.0 Received: by 10.103.241.15 with SMTP id t15mr4118708mur.85.1243966393155; Tue, 02 Jun 2009 11:13:13 -0700 (PDT) In-Reply-To: References: <00a401c9e388$b25c2350$171469f0$%roni@huawei.com> <4A2541B9.2000805@octasic.com> <00d501c9e39a$dcbbbe50$96333af0$%roni@huawei.com> <6e9223710906021031i31e024dam5673ca9608017d73@mail.gmail.com> Date: Tue, 2 Jun 2009 14:13:13 -0400 Message-ID: <6e9223710906021113w30a16a6cg7347f83c0162ba58@mail.gmail.com> From: stephen botzko To: Slava Borilin Content-Type: multipart/alternative; boundary=001636b430c8fa044c046b617ead Cc: dispatch@ietf.org, avt@ietf.org, Roni Even , hsinnrei@adobe.com Subject: Re: [dispatch] [AVT] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 18:13:17 -0000 --001636b430c8fa044c046b617ead Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit >>> i think this is probably false alert. I would hope so. I think its important that the characterization testing (however it is done) prevent the standardization of a codec that is sub-standard. So I'd prefer Henning's last risk item to be that "a standardizable codec might not result". Steve B. On Tue, Jun 2, 2009 at 1:33 PM, Slava Borilin wrote: > I do not beleive the one that will come wil be low quality. > at least people from the potential contributors (at least Skype, Speex, > SPIRIT) are already pretty-good in the commercially exploiting their own > codecs on the market. > i think this is probably false alert. > > regards, > Slava Borilin > > > > ------------------------------ > *From:* stephen botzko [mailto:stephen.botzko@gmail.com] > *Sent:* Tuesday, June 02, 2009 9:32 PM > *To:* Henning Schulzrinne > *Cc:* Roni Even; dispatch@ietf.org; Jason Fischl; avt@ietf.org; > hsinnrei@adobe.com; Slava Borilin > > *Subject:* Re: [AVT] [dispatch] Proposal to form Internet Wideband Audio > Codec WG > > >>> - the quality of the codec may not be competitive > > I think its very important that the codec quality be competitive. People > expect excellence from IETF standards Standardizing non-competitive codecs > because they are cheap does not seem to be a good choce. > > Steve B. > > On Tue, Jun 2, 2009 at 12:15 PM, Henning Schulzrinne wrote: > >> I view this as a trade-off. If we pursue this, there are risks: >> >> - nothing may come of it since there are no experts willing to help >> - somebody will claim IPR on the resulting work >> - the quality of the codec may not be competitive >> >> However, if we don't do this, we are stuck with the status quo, which is >> not all that satisfactory. Thus, unless there are significant costs for >> "innocent bystanders", I see this as a risk worth taking. In the worst case, >> we are no worse off than we are today. In all other cases, we'll have an >> additional choice for a wideband codec, even if it's not "the best", just >> "good enough". After all, most people use G.711 today, which has a really >> hard time making that claim. >> >> Most real work in the IETF is done by very small teams, typically less >> than 10, so as long as we have a handful of people that are willing to >> contribute, this can work. It might even work better, since you may get >> fewer people who have half-baked opinions - we may skip the binary vs. XML >> debates... >> >> We can set some ground rules ("must be tested with packet loss of 5%") and >> then see what happens. Compared to most network protocols, the likely >> negative impacts (such as security or congestion control issues) of even a >> badly-designed codec are pretty limited. >> >> Henning >> >> >> On Jun 2, 2009, at 11:57 AM, Roni Even wrote: >> >> Hi, >>> I do not want to sound like someone who is for IPR (I am not), but why >>> stop >>> at codec, let's require it for all IETF work. There are IPR on IETF work >>> which is must simpler, in my view, than wide band audio codecs. >>> >>> I think that we can start with "royalty free" even though I am not sure >>> that >>> it will accepted as part of the charter of any other work group so why >>> pick >>> on codecs which require more work. >>> >>> This leaves the other reasons I heard for doing it at the IETF which is >>> the >>> price of participating (cheaper than being an ITU-T member) and maybe >>> design >>> less expensive characterization tests. >>> >>> Roni >>> >>> >>> -----Original Message----- >>> From: Jean-Marc Valin [mailto:jean-marc.valin@octasic.com] >>> Sent: Tuesday, June 02, 2009 6:14 PM >>> To: Roni Even >>> Cc: 'Slava Borilin'; avt@ietf.org; 'Jason Fischl'; dispatch@ietf.org; >>> hsinnrei@adobe.com >>> Subject: Re: [AVT] [dispatch] Proposal to form Internet Wideband Audio >>> Codec >>> WG >>> >>> Hi, >>> >>> Roni Even wrote: >>> >>>> >>>> I am not sure what prevented you from doing it today at the ITU or >>>> MPEG, why do you see the IETF handling it differently. >>>> >>>> I would also like to remind you and Jean-Marc that once you are >>>> bringing work to a standard body it may require collaboration with >>>> other people who will have other proposals that will also address the >>>> same requirements and you may need to invest money in comparative >>>> testing by independent listening labs. >>>> >>>> I also think that you will need to supply the codec in source code and >>>> provide copy right to the IETF. >>>> >>>> >>> I am well aware that bringing work to the IETF would require >>> collaboration with others. I am not seeking control over the work I am >>> currently doing and would really welcome such collaboration. The idea is >>> only to have the best wideband codec possible without IPR issues. Given >>> the ITU and MPEG track record, I think it would be very unlikely for any >>> of those organisations to work on an IPR-free codec. >>> >>> I also agree with Henry that "the Internet has different criteria than >>> ITU-T networks may have". Internet adoption follows different patterns >>> than adoption in the ITU primary target markets. For example, the >>> Internet has more consumer-reconfigurable software, while the ITU has to >>> deal with a lot of fixed hardware deployments. At the ITU, it makes >>> sense to invest large sums of money into testing and characterisation of >>> codecs because the codecs deployed there usually stay around for a long >>> time and the infrastructure investments are usually very large. On the >>> other hand, I would say the investments in codecs for the Internet are >>> comparatively smaller and, while testing is still important, it is not >>> as critical as it is for the ITU. >>> >>> It's also a choice one has to make. It is unlikely that companies would >>> invest money in expensive testing if they are not going to obtain >>> royalties in return. However, I think we may be able to define some more >>> lightweight (collaborative?) testing that is sufficient and doesn't >>> involve as much investments as what the ITU does. For the Internet, I >>> believe an IPR-free codec that everyone agrees performs well is better >>> than a patent-encumbered codec that has had more extensive testing. This >>> is again another difference with the ITU: patent-encumbered codecs tend >>> to hurt a lot more on the Internet because many applications (e.g. >>> giving away the client) are very hard (or impossible) when one has to >>> pay per-channel royalties. >>> >>> As for the source code issue you pointed out, all the Xiph codecs are >>> already published under a very permissive open source license (BSD), so >>> this would not really change. >>> >>> Jean-Marc >>> >>> Roni >>>> >>>> >>>> >>>> *From:* avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] *On Behalf >>>> Of *Slava Borilin >>>> *Sent:* Monday, June 01, 2009 11:50 PM >>>> *To:* jean-marc.valin@octasic.com >>>> *Cc:* avt@ietf.org; Jason Fischl >>>> *Subject:* Re: [AVT] [dispatch] Proposal to form Internet Wideband >>>> Audio Codec WG >>>> >>>> >>>> >>>> Agree with Jean-Marc. >>>> SPIRIT is interested to contribute as well - having a dozen of >>>> proprietary >>>> >>> codecs developed, including >>> >>>> one specifically desgined for internet (SPIRIT IP-MR, which is now under >>>> >>> WGLC on draft-ietf-avt-rtp-ipmr-04) - >>> >>>> multi-rate, scalable, adaptive, wideband codec. >>>> >>>> We can also continue this work with IETF. >>>> >>>> Moreover, most if not all efforts coming from ITU on codecs >>>> unfortunately >>>> >>> are NOT really focused on >>> >>>> internet-specific codecs (that's why several companies have had to >>>> invent) >>>> >>> - as ITU preference is mainly >>> >>>> specific (i.e. cellular) networks at first. >>>> >>>> however, as we see the greant rise of pure "internet-basd >>>> communications" >>>> >>> (skype, webex/citrix, and many others) - >>> >>>> we all (and users) are suffering from inefficiency in all currently >>>> >>> "standard" codecs and ambiguity in the choice of >>> >>>> internet-targeted ones. >>>> >>>> Again, we probably can put together enough number of contributors to the >>>> >>> WG to have the expertise. >>> >>>> >>>> regards, >>>> Slava Borilin >>>> >>>> -- >>>> John Lazzaro wrote: >>>> >>>> A traditional response to this type of request is to note that the >>>> >>> IETF >>> >>>> >>>> really doesn't have much in the way of expertise in audio codec >>>> >>> design. >>> >>>> >>>> I don't see many of the regulars who present at the AES codec paper >>>> >>> sessions >>> >>>> >>>> posting here on AVT (ditto ICASSP paper sessions for voice codecs). >>>> >>> It's >>> >>>> >>>> a full-time job to keep up-to-date and contribute to that >>>> >>>> signal-processing lore. >>>> >>>> >>>> >>>> Well, there's no reason that the IETF cannot build such an expertise >>>> in audio codecs. This is actually something in which I'd be interested >>>> in getting involved and I'm sure others at Xiph.Org would be >>>> interested as well. We have several people with audio codec expertise >>>> from working on Vorbis, Speex and (more recently) CELT. It turns out >>>> that the CELT codec currently under development at Xiph actually meets >>>> most of the requirements from the original proposal in being a very >>>> low delay codec with adaptive bit-rate and sampling rate (up to 48 >>>> kHz), scalable complexity, and good robustness to packet loss. We'd be >>>> willing to continue the development with the IETF. Even if not with >>>> CELT, it's still like to be involved in such a new WG. >>>> >>>> Cheers, >>>> >>>> Jean-Marc >>>> >>> >>> _______________________________________________ >>> Audio/Video Transport Working Group >>> avt@ietf.org >>> https://www.ietf.org/mailman/listinfo/avt >>> >>> >> _______________________________________________ >> Audio/Video Transport Working Group >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt >> > > --001636b430c8fa044c046b617ead Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >>> i thin= k this is probably false alert.
I would hope so.=A0 I think its important that the characterization testing (however it is done) prevent the standardization of a codec that is sub-standard.=A0

So I'd prefer Henning's last risk item to be that "a stand= ardizable codec might not result".

Steve B.
On Tue, Jun 2, 2009 at 1:33 PM, Slava Borilin = <Borilin@spir= itdsp.com> wrote:
I do not beleive the one that will come wil be low=20 quality.
at least people from the potential contributors (at least=20 Skype, Speex, SPIRIT) are already pretty-good in the commercially exploitin= g=20 their own codecs on the market.
i think this is probably false alert.
=A0
regards,
Slava Borilin
=A0
=A0

From: stephen botzko=20 [mailto:steph= en.botzko@gmail.com]
Sent: Tuesday, June 02, 2009 9:32=20 PM
To: Henning Schulzrinne
Cc: Roni Even; dispatch@ietf.org;=20 Jason Fischl; avt@ietf.or= g; hsinnrei@ado= be.com; Slava Borilin

Subject:<= /b>=20 Re: [AVT] [dispatch] Proposal to form Internet Wideband Audio Codec=20 WG

>>> - the quality of the codec may not be=20 competitive

I think its very important that the codec quality be=20 competitive.=A0 People expect excellence from IETF standards=A0=20 Standardizing non-competitive codecs because they are cheap does not seem t= o be=20 a good choce.

Steve B.

On Tue, Jun 2, 2009 at 12:15 PM, Henning Schulzr= inne=20 <hgs@cs.columbia.edu> wrote:
I=20 view this as a trade-off. If we pursue this, there are risks:

- no= thing=20 may come of it since there are no experts willing to help
- somebody w= ill=20 claim IPR on the resulting work
- the quality of the codec may not be= =20 competitive

However, if we don't do this, we are stuck with th= e status=20 quo, which is not all that satisfactory. Thus, unless there are significa= nt=20 costs for "innocent bystanders", I see this as a risk worth tak= ing. In the=20 worst case, we are no worse off than we are today. In all other cases, we= 'll=20 have an additional choice for a wideband codec, even if it's not &quo= t;the best",=20 just "good enough". After all, most people use G.711 today, whi= ch has a really=20 hard time making that claim.

Most real work in the IETF is done by= very=20 small teams, typically less than 10, so as long as we have a handful of p= eople=20 that are willing to contribute, this can work. It might even work better,= =20 since you may get fewer people who have half-baked opinions - we may skip= the=20 binary vs. XML debates...

We can set some ground rules ("must= be tested=20 with packet loss of 5%") and then see what happens. Compared to most= network=20 protocols, the likely negative impacts (such as security or congestion co= ntrol=20 issues) of even a badly-designed codec are pretty limited.

Henning


On Jun 2, 2009, at 11:57 AM, Roni Even wrote:

Hi,
I=20 do not want to sound like someone who is for IPR (I am not), but why=20 stop
at codec, let's require it for all IETF work. There are IPR= on IETF=20 work
which is must simpler, in my view, than wide band audio=20 codecs.

I think that we can start with "royalty free" = even though I=20 am not sure that
it will accepted as part of the charter of any othe= r=20 work group so why pick
on codecs which require more work.

Thi= s=20 leaves the other reasons I heard for doing it at the IETF which is=20 the
price of participating (cheaper than being an ITU-T member) and = maybe=20 design
less expensive characterization=20 tests.

Roni


-----Original Message-----
From: Jean-= Marc=20 Valin [mailto:jean-marc.valin@octasic.com]
Sent: Tuesday, June 02,=20 2009 6:14 PM
To: Roni Even
Cc: 'Slava Borilin'; avt@ietf.org; 'Jason Fis= chl';=20 dispatch@ietf.or= g;
hsinnrei@= adobe.com
Subject: Re: [AVT] [dispatch]=20 Proposal to form Internet Wideband Audio Codec
WG

Hi,

= Roni=20 Even wrote:

I=20 am not sure what prevented you from doing it today at the ITU or
M= PEG,=20 why do you see the IETF handling it differently.

I would also = like=20 to remind you and Jean-Marc that once you are
bringing work to a= =20 standard body it may require collaboration with
other people who w= ill=20 have other proposals that will also address the
same requirements = and=20 you may need to invest money in comparative
testing by independent= =20 listening labs.

I also think that you will need to supply the = codec=20 in source code and
provide copy right to the=20 IETF.


I am well aware that bringing work to the= IETF=20 would require
collaboration with others. I am not seeking control ov= er=20 the work I am
currently doing and would really welcome such=20 collaboration. The idea is
only to have the best wideband codec poss= ible=20 without IPR issues. Given
the ITU and MPEG track record, I think it = would=20 be very unlikely for any
of those organisations to work on an IPR-fr= ee=20 codec.

I also agree with Henry that "the Internet has diffe= rent=20 criteria than
ITU-T networks may have". Internet adoption follo= ws=20 different patterns
than adoption in the ITU primary target markets. = For=20 example, the
Internet has more consumer-reconfigurable software, whi= le=20 the ITU has to
deal with a lot of fixed hardware deployments. At the= ITU,=20 it makes
sense to invest large sums of money into testing and=20 characterisation of
codecs because the codecs deployed there usually= stay=20 around for a long
time and the infrastructure investments are usuall= y=20 very large. On the
other hand, I would say the investments in codecs= for=20 the Internet are
comparatively smaller and, while testing is still= =20 important, it is not
as critical as it is for the ITU.

It'= ;s also a=20 choice one has to make. It is unlikely that companies would
invest m= oney=20 in expensive testing if they are not going to obtain
royalties in re= turn.=20 However, I think we may be able to define some more
lightweight=20 (collaborative?) testing that is sufficient and doesn't
involve = as much=20 investments as what the ITU does. For the Internet, I
believe an IPR= -free=20 codec that everyone agrees performs well is better
than a=20 patent-encumbered codec that has had more extensive testing. This
is= =20 again another difference with the ITU: patent-encumbered codecs tendto=20 hurt a lot more on the Internet because many applications (e.g.
givi= ng=20 away the client) are very hard (or impossible) when one has to
pay= =20 per-channel royalties.

As for the source code issue you pointed = out,=20 all the Xiph codecs are
already published under a very permissive op= en=20 source license (BSD), so
this would not really change.

=A0=20 Jean-Marc

Roni

<= br>
*From:*=20 avt-bounces= @ietf.org [mailto:avt-bounces@ietf.org]=20 *On Behalf
Of *Slava Borilin
*Sent:* Monday, June 01, 2009 11:5= 0=20 PM
*To:* jean-marc.valin@octasic.com
*Cc:* avt@ietf.org; Jason=20 Fischl
*Subject:* Re: [AVT] [dispatch] Proposal to form Internet= =20 Wideband
Audio Codec WG



Agree with Jean-Marc.
SP= IRIT=20 is interested to contribute as well - having a dozen of=20 proprietary
codecs developed, including
one=20 specifically desgined for internet (SPIRIT IP-MR, which is now=20 under
WGLC on draft-ietf-avt-rtp-ipmr-04) -
multi-rate,= =20 scalable, adaptive, wideband codec.

We can also continue this = work=20 with IETF.

Moreover, most if not all efforts coming from ITU o= n=20 codecs unfortunately
are NOT really focused on
internet-spec= ific=20 codecs (that's why several companies have had to invent)
-=20 as ITU preference is mainly
specific=20 (i.e. cellular) networks at first.

however, as we see the grea= nt=20 rise of pure "internet-basd communications"
(skype,=20 webex/citrix, and many others) -
we=20 all (and users) are suffering from inefficiency in all=20 currently
"standard" codecs and ambiguity in = the choice=20 of
internet-targ= eted=20 ones.

Again, we probably can put together enough number of=20 contributors to the
WG to have the expertise.

regards,<= br>Slava=20 Borilin

--
John Lazzaro wrote:

=A0 A traditional=20 response to this type of request is to note that=20 the
IETF

=A0=20 really doesn't have much in the way of expertise in audio=20 codec
design.

=A0=20 I don't see many of the regulars who present at the AES codec=20 paper
sessions

=A0=20 posting here on AVT (ditto ICASSP paper sessions for voice=20 codecs).
It's

=A0=20 a full-time job to keep up-to-date and contribute to that

=A0= =20 signal-processing lore.



Well, there's no reason th= at the=20 IETF cannot build such an expertise
in audio codecs. This is actua= lly=20 something in which I'd be interested
in getting involved and I= 'm sure=20 others at Xiph.Org would be
interested as well. We have several pe= ople=20 with audio codec expertise
from working on Vorbis, Speex and (more= =20 recently) CELT. It turns out
that the CELT codec currently under= =20 development at Xiph actually meets
most of the requirements from t= he=20 original proposal in being a very
low delay codec with adaptive=20 bit-rate and sampling rate (up to 48
kHz), scalable complexity, an= d=20 good robustness to packet loss. We'd be
willing to continue th= e=20 development with the IETF. Even if not with
CELT, it's still l= ike to be=20 involved in such a new=20 WG.

Cheers,

=A0Jean-Marc

____________= ___________________________________
Audio/Video=20 Transport Working Group
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt

_______________________________________________
Audio/Video=20 Transport Working Group
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt


--001636b430c8fa044c046b617ead-- From hgs@cs.columbia.edu Tue Jun 2 11:14:19 2009 Return-Path: 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 9EA7628C24B; Tue, 2 Jun 2009 11:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[AWL=2.377, 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 bnVWJztc8x6U; Tue, 2 Jun 2009 11:14:19 -0700 (PDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id B69C528C217; Tue, 2 Jun 2009 11:13:49 -0700 (PDT) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id n52ICIqj002364 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 2 Jun 2009 14:12:19 -0400 (EDT) Message-Id: <2B4B0335-916C-4CD4-9E40-63BBA6B1DF8B@cs.columbia.edu> From: Henning Schulzrinne To: stephen botzko In-Reply-To: <6e9223710906021031i31e024dam5673ca9608017d73@mail.gmail.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: Tue, 2 Jun 2009 14:12:18 -0400 References: <00a401c9e388$b25c2350$171469f0$%roni@huawei.com> <4A2541B9.2000805@octasic.com> <00d501c9e39a$dcbbbe50$96333af0$%roni@huawei.com> <6e9223710906021031i31e024dam5673ca9608017d73@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.6 Cc: dispatch@ietf.org, avt@ietf.org, Roni Even , hsinnrei@adobe.com, Slava Borilin Subject: Re: [dispatch] [AVT] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 18:14:19 -0000 On Jun 2, 2009, at 1:31 PM, stephen botzko wrote: > >>> - the quality of the codec may not be competitive > > I think its very important that the codec quality be competitive. > People expect excellence from IETF standards Standardizing non- > competitive codecs because they are cheap does not seem to be a good > choce. This is an engineering trade-off. Ogg Vorbis is probably not the "best" codec out there, but fills a need. From stephen.botzko@gmail.com Tue Jun 2 11:32:27 2009 Return-Path: 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 0A51C28C244; Tue, 2 Jun 2009 11:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.013 X-Spam-Level: X-Spam-Status: No, score=-1.013 tagged_above=-999 required=5 tests=[AWL=1.585, 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 JCnw-FOFW+fr; Tue, 2 Jun 2009 11:32:26 -0700 (PDT) Received: from mail-fx0-f216.google.com (mail-fx0-f216.google.com [209.85.220.216]) by core3.amsl.com (Postfix) with ESMTP id 95C7428C1FF; Tue, 2 Jun 2009 11:32:25 -0700 (PDT) Received: by fxm12 with SMTP id 12so6722635fxm.37 for ; Tue, 02 Jun 2009 11:32:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=QnFAfUB+X/eRw6Ucnc7oCRFiXFCUvjl/ccmz654dBQQ=; b=pkgsx941sSrPozCkc79AE/rIhdikwaALrV4Rt4kl8lbgf8qRFMKJJWmf+oBITb7cHJ 1sK+w8/aCGCl8Fhz8NQJCcXlG1LZ9x59qa+s7q2fRYdY9zjpj7ura2TkKF6htndjVvIl QVheE97jcpLPBYncUOn1dhYMJu/1biM2swgbc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=k7M7NnNFz3OwV3JmDKIJvmyJ8tnL4mDgyGbEAWwwnpUv2WNwFsJMKjaK1T+9L5D7et KMacVl5sqX0LfoWbQyte6RBEDtSggXdertCska0kqxaw/aeXVKa+j9FlEe5b/pFaBULn LShesdIKoR+Ye8zY64qGFs2+VjcBGPpOH66QY= MIME-Version: 1.0 Received: by 10.102.228.19 with SMTP id a19mr30502muh.10.1243967542188; Tue, 02 Jun 2009 11:32:22 -0700 (PDT) In-Reply-To: <2B4B0335-916C-4CD4-9E40-63BBA6B1DF8B@cs.columbia.edu> References: <00a401c9e388$b25c2350$171469f0$%roni@huawei.com> <4A2541B9.2000805@octasic.com> <00d501c9e39a$dcbbbe50$96333af0$%roni@huawei.com> <6e9223710906021031i31e024dam5673ca9608017d73@mail.gmail.com> <2B4B0335-916C-4CD4-9E40-63BBA6B1DF8B@cs.columbia.edu> Date: Tue, 2 Jun 2009 14:32:21 -0400 Message-ID: <6e9223710906021132wa2d5c5cg4b095fd3e936e575@mail.gmail.com> From: stephen botzko To: Henning Schulzrinne Content-Type: multipart/alternative; boundary=0016363ba72076dbd1046b61c3d5 Cc: dispatch@ietf.org, avt@ietf.org, Roni Even , hsinnrei@adobe.com, Slava Borilin Subject: Re: [dispatch] [AVT] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 18:32:27 -0000 --0016363ba72076dbd1046b61c3d5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Of course there are multiple dimensions in the engineering - including complexity, delay, bitrate, audio bandwidth, and fidelity. I'm not saying there is a "best" codec, let alone that the IETF should attempt to build it. But I think any codec standardized by IETF should be competitive, and hopefully would have some advantage (not just price) over other available codecs for its stated application(s). Steve B. On Tue, Jun 2, 2009 at 2:12 PM, Henning Schulzrinne wrote: > > On Jun 2, 2009, at 1:31 PM, stephen botzko wrote: > > >>> - the quality of the codec may not be competitive >> >> I think its very important that the codec quality be competitive. People >> expect excellence from IETF standards Standardizing non-competitive codecs >> because they are cheap does not seem to be a good choce. >> > > This is an engineering trade-off. Ogg Vorbis is probably not the "best" > codec out there, but fills a need. > --0016363ba72076dbd1046b61c3d5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Of course there are multiple dimensions in the engineering - including comp= lexity, delay, bitrate, audio bandwidth, and fidelity.

I'm not = saying there is a "best" codec, let alone that the IETF should at= tempt to build it.=A0

But I think any codec standardized by IETF should be competitive, and h= opefully would have some advantage (not just price) over other available co= decs for its stated application(s).

Steve B.

On Tue, Jun 2, 2009 at 2:12 PM, Henning Schulzrinne <<= a href=3D"mailto:hgs@cs.columbia.edu">hgs@cs.columbia.edu> wr= ote:

On Jun 2, 2009, at 1:31 PM, stephen botzko wrote:

>>> - the quality of the codec may not be competitive

I think its very important that the codec quality be competitive. =A0People= expect excellence from IETF standards =A0Standardizing non-competitive cod= ecs because they are cheap does not seem to be a good choce.

This is an engineering trade-off. Ogg Vorbis is probably not the "best= " codec out there, but fills a need.

--0016363ba72076dbd1046b61c3d5-- From hsinnrei@adobe.com Tue Jun 2 12:11:00 2009 Return-Path: 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 E693128C28B; Tue, 2 Jun 2009 12:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.843 X-Spam-Level: X-Spam-Status: No, score=-1.843 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, MANGLED_INXPNS=2.3, 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 CuPXqTdXXPw2; Tue, 2 Jun 2009 12:10:59 -0700 (PDT) Received: from exprod6og107.obsmtp.com (exprod6og107.obsmtp.com [64.18.1.208]) by core3.amsl.com (Postfix) with ESMTP id 4A2AE28C284; Tue, 2 Jun 2009 12:10:56 -0700 (PDT) Received: from source ([192.150.11.134]) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP ID DSNKSiV5NasuM3anKRadEd4fjqNVi/FGHTi2@postini.com; Tue, 02 Jun 2009 12:11:00 PDT Received: from inner-relay-3.eur.adobe.com ([192.150.8.236]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n52J4eao017579; Tue, 2 Jun 2009 12:04:40 -0700 (PDT) Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id n52JAeY2021497; Tue, 2 Jun 2009 12:10:41 -0700 (PDT) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nahub01.corp.adobe.com ([10.8.189.97]) with mapi; Tue, 2 Jun 2009 12:10:40 -0700 From: Henry Sinnreich To: Slava Borilin , stephen botzko , Henning Schulzrinne Date: Tue, 2 Jun 2009 12:10:38 -0700 Thread-Topic: [AVT] [dispatch] Proposal to form Internet Wideband Audio Codec WG Thread-Index: AcnjqANErfh4GUqeQ4SC5NZuzNxHZgAAB2LQAANr4HU= Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C64AE35E3E6Ehsinnreiadobecom_" MIME-Version: 1.0 Cc: "dispatch@ietf.org" , "avt@ietf.org" , Roni Even Subject: Re: [dispatch] [AVT] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 19:11:01 -0000 --_000_C64AE35E3E6Ehsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >at least people from the potential contributors (at least Skype, Speex, SP= IRIT) are already pretty-good As a user of all three codecs and some other as well: The seem to me clearly among the best technology and in wide-spread use as = well. This should put to rest the questions of expertise, quality and availabilit= y of contributors and reviewers. Henry On 6/2/09 12:33 PM, "Slava Borilin" wrote: I do not beleive the one that will come wil be low quality. at least people from the potential contributors (at least Skype, Speex, SPI= RIT) are already pretty-good in the commercially exploiting their own codec= s on the market. i think this is probably false alert. regards, Slava Borilin ________________________________ From: stephen botzko [mailto:stephen.botzko@gmail.com] Sent: Tuesday, June 02, 2009 9:32 PM To: Henning Schulzrinne Cc: Roni Even; dispatch@ietf.org; Jason Fischl; avt@ietf.org; hsinnrei@adob= e.com; Slava Borilin Subject: Re: [AVT] [dispatch] Proposal to form Internet Wideband Audio Code= c WG >>> - the quality of the codec may not be competitive I think its very important that the codec quality be competitive. People e= xpect excellence from IETF standards Standardizing non-competitive codecs = because they are cheap does not seem to be a good choce. Steve B. On Tue, Jun 2, 2009 at 12:15 PM, Henning Schulzrinne = wrote: I view this as a trade-off. If we pursue this, there are risks: - nothing may come of it since there are no experts willing to help - somebody will claim IPR on the resulting work - the quality of the codec may not be competitive However, if we don't do this, we are stuck with the status quo, which is n= ot all that satisfactory. Thus, unless there are significant costs for "in= nocent bystanders", I see this as a risk worth taking. In the worst case, = we are no worse off than we are today. In all other cases, we'll have an a= dditional choice for a wideband codec, even if it's not "the best", just "= good enough". After all, most people use G.711 today, which has a really h= ard time making that claim. Most real work in the IETF is done by very small teams, typically less tha= n 10, so as long as we have a handful of people that are willing to contri= bute, this can work. It might even work better, since you may get fewer pe= ople who have half-baked opinions - we may skip the binary vs. XML debates= ... We can set some ground rules ("must be tested with packet loss of 5%") and= then see what happens. Compared to most network protocols, the likely neg= ative impacts (such as security or congestion control issues) of even a ba= dly-designed codec are pretty limited. Henning On Jun 2, 2009, at 11:57 AM, Roni Even wrote: Hi, I do not want to sound like someone who is for IPR (I am not), but why st= op at codec, let's require it for all IETF work. There are IPR on IETF work which is must simpler, in my view, than wide band audio codecs. I think that we can start with "royalty free" even though I am not sure th= at it will accepted as part of the charter of any other work group so why pic= k on codecs which require more work. This leaves the other reasons I heard for doing it at the IETF which is t= he price of participating (cheaper than being an ITU-T member) and maybe desi= gn less expensive characterization tests. Roni -----Original Message----- From: Jean-Marc Valin [mailto:jean-marc.valin@octasic.com] Sent: Tuesday, June 02, 2009 6:14 PM To: Roni Even Cc: 'Slava Borilin'; avt@ietf.org; 'Jason Fischl'; dispatch@ietf.org; hsinnrei@adobe.com Subject: Re: [AVT] [dispatch] Proposal to form Internet Wideband Audio Cod= ec WG Hi, Roni Even wrote: I am not sure what prevented you from doing it today at the ITU or MPEG, why do you see the IETF handling it differently. I would also like to remind you and Jean-Marc that once you are bringing work to a standard body it may require collaboration with other people who will have other proposals that will also address the same requirements and you may need to invest money in comparative testing by independent listening labs. I also think that you will need to supply the codec in source code and provide copy right to the IETF. I am well aware that bringing work to the IETF would require collaboration with others. I am not seeking control over the work I am currently doing and would really welcome such collaboration. The idea is only to have the best wideband codec possible without IPR issues. Given the ITU and MPEG track record, I think it would be very unlikely for any of those organisations to work on an IPR-free codec. I also agree with Henry that "the Internet has different criteria than ITU-T networks may have". Internet adoption follows different patterns than adoption in the ITU primary target markets. For example, the Internet has more consumer-reconfigurable software, while the ITU has to deal with a lot of fixed hardware deployments. At the ITU, it makes sense to invest large sums of money into testing and characterisation of codecs because the codecs deployed there usually stay around for a long time and the infrastructure investments are usually very large. On the other hand, I would say the investments in codecs for the Internet are comparatively smaller and, while testing is still important, it is not as critical as it is for the ITU. It's also a choice one has to make. It is unlikely that companies would invest money in expensive testing if they are not going to obtain royalties in return. However, I think we may be able to define some more lightweight (collaborative?) testing that is sufficient and doesn't involve as much investments as what the ITU does. For the Internet, I believe an IPR-free codec that everyone agrees performs well is better than a patent-encumbered codec that has had more extensive testing. This is again another difference with the ITU: patent-encumbered codecs tend to hurt a lot more on the Internet because many applications (e.g. giving away the client) are very hard (or impossible) when one has to pay per-channel royalties. As for the source code issue you pointed out, all the Xiph codecs are already published under a very permissive open source license (BSD), so this would not really change. Jean-Marc Roni *From:* avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] *On Behalf Of *Slava Borilin *Sent:* Monday, June 01, 2009 11:50 PM *To:* jean-marc.valin@octasic.com *Cc:* avt@ietf.org; Jason Fischl *Subject:* Re: [AVT] [dispatch] Proposal to form Internet Wideband Audio Codec WG Agree with Jean-Marc. SPIRIT is interested to contribute as well - having a dozen of proprietar= y codecs developed, including one specifically desgined for internet (SPIRIT IP-MR, which is now under WGLC on draft-ietf-avt-rtp-ipmr-04) - multi-rate, scalable, adaptive, wideband codec. We can also continue this work with IETF. Moreover, most if not all efforts coming from ITU on codecs unfortunately are NOT really focused on internet-specific codecs (that's why several companies have had to invent) - as ITU preference is mainly specific (i.e. cellular) networks at first. however, as we see the greant rise of pure "internet-basd communications" (skype, webex/citrix, and many others) - we all (and users) are suffering from inefficiency in all currently "standard" codecs and ambiguity in the choice of internet-targeted ones. Again, we probably can put together enough number of contributors to the WG to have the expertise. regards, Slava Borilin -- John Lazzaro wrote: A traditional response to this type of request is to note that the IETF really doesn't have much in the way of expertise in audio codec design. I don't see many of the regulars who present at the AES codec paper sessions posting here on AVT (ditto ICASSP paper sessions for voice codecs). It's a full-time job to keep up-to-date and contribute to that signal-processing lore. Well, there's no reason that the IETF cannot build such an expertise in audio codecs. This is actually something in which I'd be interested in getting involved and I'm sure others at Xiph.Org would be interested as well. We have several people with audio codec expertise from working on Vorbis, Speex and (more recently) CELT. It turns out that the CELT codec currently under development at Xiph actually meets most of the requirements from the original proposal in being a very low delay codec with adaptive bit-rate and sampling rate (up to 48 kHz), scalable complexity, and good robustness to packet loss. We'd be willing to continue the development with the IETF. Even if not with CELT, it's still like to be involved in such a new WG. Cheers, Jean-Marc _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www.ietf.org/mailman/listinfo/avt --_000_C64AE35E3E6Ehsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [AVT] [dispatch] Proposal to form Internet Wideband Audio Codec = WG >at least people from the potential contributors (a= t least Skype, Speex, SPIRIT) are already pretty-good

As a user of all three codecs and some o= ther as well:
The seem to me clearly among the best technology and in wide-spread use as = well.

This should put to rest the questions of expertise, quality and availabilit= y of contributors and reviewers.

Henry


On 6/2/09 12:33 PM, "Slava Borilin" <Borilin@spiritdsp.com> wrote:

I do not beleive the one that will come wil be l= ow quality.
at least people from the potential contributors (at least Skype, Speex, SPI= RIT) are already pretty-good in the commercially exploiting their own codec= s on the market.
i think this is probably false alert.
regards,
Slava Borilin
 

From: stephen botzko [mailto:stephen.botzko@gmail.com]
Sent: Tuesday, June 02, 2009 9:32 PM
To: Henning Schulzrinne
Cc: Roni Even; dispatch@ietf.org; = Jason Fischl; avt@ietf.org; hsinnrei@adobe.com; Slava Borilin
Subject: Re: [AVT] [dispatch] Proposal to form Internet Wideband Aud= io Codec WG

>>> - the quality of the codec may not be competitive

I think its very important that the codec quality be competitive.  Peo= ple expect excellence from IETF standards  Standardizing non-competiti= ve codecs because they are cheap does not seem to be a good choce.

Steve B.

On Tue, Jun 2, 2009 at 12:15 PM, Henning Schulzrinne <hgs@cs.columbia.edu> wrote:
I  view this as a trade-off. If we pur= sue this, there are risks:

- nothing  may come of it since there are no experts willing to help - somebody will  claim IPR on the resulting work
- the quality of the codec may not be  competitive

However, if we don't do this, we are stuck with the status  quo, which= is not all that satisfactory. Thus, unless there are significant  cos= ts for "innocent bystanders", I see this as a risk worth taking. = In the  worst case, we are no worse off than we are today. In all othe= r cases, we'll  have an additional choice for a wideband codec, even i= f it's not "the best",  just "good enough". After = all, most people use G.711 today, which has a really  hard time making= that claim.

Most real work in the IETF is done by very  small teams, typically les= s than 10, so as long as we have a handful of people  that are willing= to contribute, this can work. It might even work better,  since you m= ay get fewer people who have half-baked opinions - we may skip the  bi= nary vs. XML debates...

We can set some ground rules ("must be tested  with packet loss o= f 5%") and then see what happens. Compared to most network  proto= cols, the likely negative impacts (such as security or congestion control &= nbsp;issues) of even a badly-designed codec are pretty limited.

Henning
 
 


On Jun 2, 2009, at 11:57 AM, Roni Even wrote:

 
Hi,
I  do not want to sound like someone who is for IPR (I am not), but wh= y  stop
at codec, let's require it for all IETF work. There are IPR on IETF  w= ork
which is must simpler, in my view, than wide band audio  codecs.

I think that we can start with "royalty free" even though I  = ;am not sure that
it will accepted as part of the charter of any other  work group so wh= y pick
on codecs which require more work.

This  leaves the other reasons I heard for doing it at the IETF which = is  the
price of participating (cheaper than being an ITU-T member) and maybe  = ;design
less expensive characterization  tests.

Roni


-----Original Message-----
From: Jean-Marc  Valin [mailto:jean-marc.valin@octasic.com]
Sent: Tuesday, June 02,  2009 6:14 PM
To: Roni Even
Cc: 'Slava Borilin'; avt@ietf.org; 'Jason Fisc= hl';  dispatch@ietf.org;
hsinnrei@adobe.com
Subject: Re: [AVT] [dispatch]  Proposal to form Internet Wideband Audi= o Codec
WG

Hi,

Roni  Even wrote:
 

I  am not sure what prevented you from doing it today at the ITU or MPEG,  why do you see the IETF handling it differently.

I would also like  to remind you and Jean-Marc that once you are
bringing work to a  standard body it may require collaboration with other people who will  have other proposals that will also address the=
same requirements and  you may need to invest money in comparative
testing by independent  listening labs.

I also think that you will need to supply the codec  in source code an= d
provide copy right to the  IETF.


I am well aware that bringing work to the IETF  would require
collaboration with others. I am not seeking control over  the work I a= m
currently doing and would really welcome such  collaboration. The idea= is
only to have the best wideband codec possible  without IPR issues. Giv= en
the ITU and MPEG track record, I think it would  be very unlikely for = any
of those organisations to work on an IPR-free  codec.

I also agree with Henry that "the Internet has different  criteri= a than
ITU-T networks may have". Internet adoption follows  different pa= tterns
than adoption in the ITU primary target markets. For  example, the
Internet has more consumer-reconfigurable software, while  the ITU has= to
deal with a lot of fixed hardware deployments. At the ITU,  it makes sense to invest large sums of money into testing and  characterisation= of
codecs because the codecs deployed there usually stay  around for a lo= ng
time and the infrastructure investments are usually  very large. On th= e
other hand, I would say the investments in codecs for  the Internet ar= e
comparatively smaller and, while testing is still  important, it is no= t
as critical as it is for the ITU.

It's also a  choice one has to make. It is unlikely that companies wou= ld
invest money  in expensive testing if they are not going to obtain
royalties in return.  However, I think we may be able to define some m= ore
lightweight  (collaborative?) testing that is sufficient and doesn't involve as much  investments as what the ITU does. For the Internet, I=
believe an IPR-free  codec that everyone agrees performs well is bette= r
than a  patent-encumbered codec that has had more extensive testing. T= his
is  again another difference with the ITU: patent-encumbered codecs te= nd
to  hurt a lot more on the Internet because many applications (e.g. giving  away the client) are very hard (or impossible) when one has to=
pay  per-channel royalties.

As for the source code issue you pointed out,  all the Xiph codecs are=
already published under a very permissive open  source license (BSD), = so
this would not really change.

   Jean-Marc

 
Roni



*From:*  avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] &nbs= p;*On Behalf
Of *Slava Borilin
*Sent:* Monday, June 01, 2009 11:50  PM
*To:* jean-marc.valin@octasic.com
*Cc:* avt@ietf.org; Jason  Fischl
*Subject:* Re: [AVT] [dispatch] Proposal to form Internet  Wideband Audio Codec WG



Agree with Jean-Marc.
SPIRIT  is interested to contribute as well - having a dozen of  = proprietary
codecs developed, including
 
one  specifically desgined for interne= t (SPIRIT IP-MR, which is now  under
WGLC on draft-ietf-avt-rtp-ipmr-04) -
 
multi-rate,  scalable, adaptive, wideb= and codec.

We can also continue this work  with IETF.

Moreover, most if not all efforts coming from ITU on  codecs unfortuna= tely
are NOT really focused on
 
internet-specific  codecs (that's why = several companies have had to invent)
-  as ITU preference is mainly
 
specific  (i.e. cellular) networks at = first.

however, as we see the greant  rise of pure "internet-basd commun= ications"
(skype,  webex/citrix, and many other= s) -
 
we  all (and users) are suffering from= inefficiency in all  currently
"standard" codecs and ambiguity = in the choice  of
 
internet-targeted  ones.

Again, we probably can put together enough number of  contributors to = the
WG to have the expertise.
 

regards,
Slava  Borilin

--
John Lazzaro wrote:

  A traditional  response to this type of request is to note= that the
IETF
 

   really doesn't have much in the way of expertise in audio=  codec
design.
 

   I don't see many of the regulars who present at the AES c= odec  paper
sessions
 

   posting here on AVT (ditto ICASSP paper sessions for voic= e  codecs).
It's
 

   a full-time job to keep up-to-date and contribute to that=

   signal-processing lore.



Well, there's no reason that the  IETF cannot build such an expertise<= BR> in audio codecs. This is actually  something in which I'd be intereste= d
in getting involved and I'm sure  others at Xiph.Org would be
interested as well. We have several people  with audio codec expertise=
from working on Vorbis, Speex and (more  recently) CELT. It turns out<= BR> that the CELT codec currently under  development at Xiph actually meet= s
most of the requirements from the  original proposal in being a very low delay codec with adaptive  bit-rate and sampling rate (up to 48 kHz), scalable complexity, and  good robustness to packet loss. We'd b= e
willing to continue the  development with the IETF. Even if not with CELT, it's still like to be  involved in such a new  WG.

Cheers,

 Jean-Marc

_______________________________________________
Audio/Video  Transport Working Group
avt@ietf.org
https://www.ietf.org/= mailman/listinfo/avt


_______________________________________________
Audio/Video  Transport Working Group
avt@ietf.org
https://www.ietf.org/= mailman/listinfo/avt


--_000_C64AE35E3E6Ehsinnreiadobecom_-- From singer@apple.com Tue Jun 2 11:38:13 2009 Return-Path: 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 3753328C180; Tue, 2 Jun 2009 11:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EG8TRJnI8Lg1; Tue, 2 Jun 2009 11:38:12 -0700 (PDT) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 8A3173A7047; Tue, 2 Jun 2009 11:38:12 -0700 (PDT) Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out4.apple.com (Postfix) with ESMTP id C8AAA65EFABC; Tue, 2 Jun 2009 11:38:13 -0700 (PDT) Received: from relay15.apple.com (unknown [127.0.0.1]) by relay15.apple.com (Symantec Brightmail Gateway) with ESMTP id BC28D5A0002; Tue, 2 Jun 2009 11:38:13 -0700 (PDT) X-AuditID: 11807136-a5cfbbb00000447e-f4-4a257195030a Received: from [10.0.1.8] (singda.apple.com [17.202.35.52]) by relay15.apple.com (Apple SCV relay) with ESMTP id 7E89F558003; Tue, 2 Jun 2009 11:38:13 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <2B4B0335-916C-4CD4-9E40-63BBA6B1DF8B@cs.columbia.edu> References: <00a401c9e388$b25c2350$171469f0$%roni@huawei.com> <4A2541B9.2000805@octasic.com> <00d501c9e39a$dcbbbe50$96333af0$%roni@huawei.com> <6e9223710906021031i31e024dam5673ca9608017d73@mail.gmail.com> <2B4B0335-916C-4CD4-9E40-63BBA6B1DF8B@cs.columbia.edu> Date: Tue, 2 Jun 2009 11:36:40 -0700 To: Henning Schulzrinne , stephen botzko From: David Singer Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Tue, 02 Jun 2009 12:19:01 -0700 Cc: dispatch@ietf.org, avt@ietf.org, Roni Even , hsinnrei@adobe.com, Slava Borilin Subject: Re: [dispatch] [AVT] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 18:38:13 -0000 It would also be hard to 'object' to transport work being done in traditional 'codec shops' (such as the ITU and MPEG) if this goes ahead. A quality codec standard is usually backed by * testing * conformance files * reference software and a fairly rigorous design process. When SMPTE took on VC-1 from Microsoft, I think both they and Microsoft were surprised by the amount of work involved. FWIW, 3GPP SA4 is also a place with interest in codecs for packet networks, and has standardized codecs in the past. Opening a new work item there is not trivial, but can be done. -- David Singer Multimedia Standards, Apple Inc. From singer@apple.com Tue Jun 2 12:32:15 2009 Return-Path: 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 B6D9B3A6D62; Tue, 2 Jun 2009 12:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ry59NX7lJluL; Tue, 2 Jun 2009 12:32:11 -0700 (PDT) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 41F2028C124; Tue, 2 Jun 2009 12:32:11 -0700 (PDT) Received: from relay16.apple.com (relay16.apple.com [17.128.113.55]) by mail-out3.apple.com (Postfix) with ESMTP id 84EE062DD73A; Tue, 2 Jun 2009 12:32:12 -0700 (PDT) Received: from relay16.apple.com (unknown [127.0.0.1]) by relay16.apple.com (Symantec Brightmail Gateway) with ESMTP id 68B9C5A0005; Tue, 2 Jun 2009 12:32:12 -0700 (PDT) X-AuditID: 11807137-a4d67bb00000380b-2f-4a257e3cc68f Received: from [10.0.1.8] (singda.apple.com [17.202.35.52]) by relay16.apple.com (Apple SCV relay) with ESMTP id 1C543558016; Tue, 2 Jun 2009 12:32:12 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <00a401c9e388$b25c2350$171469f0$%roni@huawei.com> <4A2541B9.2000805@octasic.com> <00d501c9e39a$dcbbbe50$96333af0$%roni@huawei.com> <6e9223710906021031i31e024dam5673ca9608017d73@mail.gmail.com> <2B4B0335-916C-4CD4-9E40-63BBA6B1DF8B@cs.columbia.edu> Date: Tue, 2 Jun 2009 12:31:53 -0700 To: Randell Jesup From: David Singer Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Brightmail-Tracker: AAAAAA== Cc: dispatch@ietf.org, avt@ietf.org, Roni Even , hsinnrei@adobe.com, Slava Borilin , stephen botzko Subject: Re: [dispatch] [AVT] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 19:32:15 -0000 At 15:23 -0400 2/06/09, Randell Jesup wrote: > >FWIW, 3GPP SA4 is also a place with interest in codecs for packet networks, >>and has standardized codecs in the past. Opening a new work item there is >>not trivial, but can be done. > >Again, I imagine even getting involved in 3GPP is tough with many hoops, >let alone getting the rest of them to sanction a new codec not designed for >radio use specifically. You can't even directly apply to join; you have to >go through an "Organizational Partner" like ATIS. Not going to happen here... The only hoop is an organizational partner. For large companies, it can be expensive (e.g. ETSI sets your dues based on your telecoms related revenue, if I recall correctly). On a spectrum of desirability of process etc., I'd guess that * codecs from international bodies with a procedure and track record for doing them thoroughly, are preferred (MPEG, ITU, 3GPP) * codecs from international bodies not normally in the codec field offer at least a stable specification and the opportunity for critique and refinement, leading to that specification (e.g. IETF) * codecs developed in open-source are at least open to anyone, but they have the issue that they lack a formal reference, a formal consensus process, a stable publication 'home', IPR rules for contributors, and so on * commercial codecs have the backing of a company, and generally stability, interop, and so on are well managed (if they want to succeed), but are typically confidential and 'take it or leave it'. And yes, it gets a little cheaper each time we move down a rung here, which is the trade-off. -- David Singer Multimedia Standards, Apple Inc. From rjesup@wgate.com Tue Jun 2 12:23:00 2009 Return-Path: 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 41D1528C288; Tue, 2 Jun 2009 12:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.734 X-Spam-Level: X-Spam-Status: No, score=-1.734 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPPmqRvTVoGp; Tue, 2 Jun 2009 12:22:59 -0700 (PDT) Received: from exchange1.wgate.com (pr-66-150-46-254.wgate.com [66.150.46.254]) by core3.amsl.com (Postfix) with ESMTP id 4329328C124; Tue, 2 Jun 2009 12:22:59 -0700 (PDT) Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Jun 2009 15:22:58 -0400 To: David Singer References: <00a401c9e388$b25c2350$171469f0$%roni@huawei.com> <4A2541B9.2000805@octasic.com> <00d501c9e39a$dcbbbe50$96333af0$%roni@huawei.com> <6e9223710906021031i31e024dam5673ca9608017d73@mail.gmail.com> <2B4B0335-916C-4CD4-9E40-63BBA6B1DF8B@cs.columbia.edu> From: Randell Jesup Date: Tue, 02 Jun 2009 15:23:34 -0400 In-Reply-To: (David Singer's message of "Tue\, 2 Jun 2009 11\:36\:40 -0700") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 02 Jun 2009 19:22:58.0041 (UTC) FILETIME=[89655690:01C9E3B7] X-Mailman-Approved-At: Tue, 02 Jun 2009 12:37:14 -0700 Cc: dispatch@ietf.org, avt@ietf.org, Roni Even , hsinnrei@adobe.com, Slava Borilin , stephen botzko Subject: Re: [dispatch] [AVT] Proposal to form Internet Wideband Audio Codec WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Randell Jesup List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 19:23:00 -0000 David Singer writes: >It would also be hard to 'object' to transport work being done in >traditional 'codec shops' (such as the ITU and MPEG) if this goes ahead. > >A quality codec standard is usually backed by >* testing >* conformance files >* reference software > >and a fairly rigorous design process. When SMPTE took on VC-1 from >Microsoft, I think both they and Microsoft were surprised by the amount of >work involved. All relevant and indicative of the level of work required, but not disqualifying I think. >FWIW, 3GPP SA4 is also a place with interest in codecs for packet networks, >and has standardized codecs in the past. Opening a new work item there is >not trivial, but can be done. Again, I imagine even getting involved in 3GPP is tough with many hoops, let alone getting the rest of them to sanction a new codec not designed for radio use specifically. You can't even directly apply to join; you have to go through an "Organizational Partner" like ATIS. Not going to happen here... -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) From Borilin@spiritdsp.com Tue Jun 2 13:28:24 2009 Return-Path: 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 B13A63A6E03; Tue, 2 Jun 2009 13:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.47 X-Spam-Level: X-Spam-Status: No, score=-0.47 tagged_above=-999 required=5 tests=[AWL=-0.326, BAYES_00=-2.599, FRT_ADOBE2=2.455] 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 VCG4aWOB9mD3; Tue, 2 Jun 2009 13:28:24 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id BD7C03A6D90; Tue, 2 Jun 2009 13:28:23 -0700 (PDT) Received: from mail-srv.spiritcorp.com (mail-srv.spiritcorp.com [192.168.125.3]) by mail3.spiritcorp.com (8.13.8/8.14.3) with SMTP id n52KRqZe070405; Wed, 3 Jun 2009 00:27:52 +0400 (MSD) (envelope-from Borilin@spiritdsp.com) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 3 Jun 2009 00:27:45 +0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] [dispatch] Proposal to form Internet Wideband Audio Codec WG Thread-Index: AcnjsU5SS3xT32TWQ8uT5QDgSonGngADwutQ References: <00a401c9e388$b25c2350$171469f0$%roni@huawei.com> <4A2541B9.2000805@octasic.com> <00d501c9e39a$dcbbbe50$96333af0$%roni@huawei.com> <6e9223710906021031i31e024dam5673ca9608017d73@mail.gmail.com> <2B4B0335-916C-4CD4-9E40-63BBA6B1DF8B@cs.columbia.edu> From: "Slava Borilin" To: "David Singer" , "Henning Schulzrinne" , "stephen botzko" X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Cc: hsinnrei@adobe.com, dispatch@ietf.org, avt@ietf.org, Roni Even Subject: Re: [dispatch] [AVT] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 20:28:24 -0000 David- SA4 is definitely the option, but they are focused, again, on LTE only, around EVRC family, so they has a differetnt roots and different agendas from IETF now. regards, Slava Borilin =20 -----Original Message----- From: David Singer [mailto:singer@apple.com]=20 Sent: Tuesday, June 02, 2009 10:37 PM To: Henning Schulzrinne; stephen botzko Cc: dispatch@ietf.org; Jason Fischl; avt@ietf.org; Roni Even; hsinnrei@adobe.com; Slava Borilin Subject: Re: [AVT] [dispatch] Proposal to form Internet Wideband Audio Codec WG It would also be hard to 'object' to transport work being done in traditional 'codec shops' (such as the ITU and MPEG) if this goes ahead. A quality codec standard is usually backed by * testing * conformance files * reference software and a fairly rigorous design process. When SMPTE took on VC-1 from Microsoft, I think both they and Microsoft were surprised by the amount of work involved. FWIW, 3GPP SA4 is also a place with interest in codecs for packet networks, and has standardized codecs in the past. Opening a new work item there is not trivial, but can be done. -- David Singer Multimedia Standards, Apple Inc. From eburger@standardstrack.com Tue Jun 2 18:50:37 2009 Return-Path: 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 473E33A6A80; Tue, 2 Jun 2009 18:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.222 X-Spam-Level: X-Spam-Status: No, score=-0.222 tagged_above=-999 required=5 tests=[AWL=-2.377, BAYES_00=-2.599, FRT_ADOBE2=2.455, MANGLED_INXPNS=2.3] 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 6-NZ5ewKEryq; Tue, 2 Jun 2009 18:50:35 -0700 (PDT) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id C16FB3A6850; Tue, 2 Jun 2009 18:50:35 -0700 (PDT) Received: from [12.46.252.162] (helo=[172.17.136.184]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1MBfcX-000621-My; Tue, 02 Jun 2009 18:50:26 -0700 Message-Id: From: Eric Burger To: Henry Sinnreich In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-334--601341967; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) X-Priority: 3 Date: Tue, 2 Jun 2009 21:50:30 -0400 References: 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, avt@ietf.org Subject: Re: [dispatch] [AVT] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 01:50:37 -0000 --Apple-Mail-334--601341967 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit To directly answer Henry, having a mail list and the initial (and possibly detailed) discussion hosted at the IETF costs less than the discussion we are having here. If a codec comes out of it, without having a BOF or WG, that's great! If not, at least there was a forum for doing it. I can also offer a SIP Forum list if people still really, really don't like the idea of even discussing the topic under even the most faintest of auspices of the IETF. If you think I am schizophrenic by offering we can have a discussion in the IETF and at the same time I doubt we could ever have a formal work group to create the codec, you would be only slightly correct :-) But seriously: the IETF (AVT in particular) can pickup the wire format for a codec, once the codec exists. Having a mail list WITHOUT A WORK GROUP give people who want to work on this a venue to do the work, without burdening the AD's, IESG, and the rest of the community. If a codec pops out, then we can run with it. On Jun 2, 2009, at 12:44 PM, Spencer Dawkins wrote: > I am not an area director, nor do i play one on IPTV, but my > suggestion for anyone interested would be to > > - request a non-WG mailing list (from either of the RAI area > directors), > > - announce it on this mailing list (and others that seem to be > appropriate, and > > - start discussions, which the area directors typically look at when > judging whether there's enough interest and enough clue to justify > approving a BOF and/or chartering a working group. > > I didn't see a mailing list included in Jason's proposal - if I > missed one, my apologies. > > If people at the IETF can do this work, and want to do this work, > IETF process policies should not get in the way of that happening. > > And I haven't heard of an AD turning down a request for a non-WG > mailing list yet, keeping in mind that one of said lists is ietf- > sailors, for people interested in sailing to/from/at IETF meetings - > the bar is (appropriately) low. > > Thanks, > > Spencer > ----- Original Message ----- > From: Henry Sinnreich > To: Roni Even ; Jean-Marc Valin > Cc: dispatch@ietf.org ; Slava Borilin ; avt@ietf.org > Sent: Tuesday, June 02, 2009 11:12 AM > Subject: Re: [dispatch] [AVT] Proposal to form Internet Wideband > Audio Codec WG > > >This leaves the other reasons I heard for doing it at the IETF > which is the > >price of participating > > This is an important point. > Given the travel constraints for some of the most valuable potential > contributors and reviewers, could we envisage online work until the > economy improves, so that an eventual BOF to start with should not > be starved of attendees? An online BOF? > > There are several free online meeting tools available... > > How can this be done within the IETF policy? > > Henry > > > On 6/2/09 10:57 AM, "Roni Even" wrote: > > Hi, > I do not want to sound like someone who is for IPR (I am not), but > why stop > at codec, let's require it for all IETF work. There are IPR on IETF > work > which is must simpler, in my view, than wide band audio codecs. > > I think that we can start with "royalty free" even though I am not > sure that > it will accepted as part of the charter of any other work group so > why pick > on codecs which require more work. > > This leaves the other reasons I heard for doing it at the IETF which > is the > price of participating (cheaper than being an ITU-T member) and > maybe design > less expensive characterization tests. > > Roni > > > -----Original Message----- > From: Jean-Marc Valin [mailto:jean-marc.valin@octasic.com] > Sent: Tuesday, June 02, 2009 6:14 PM > To: Roni Even > Cc: 'Slava Borilin'; avt@ietf.org; 'Jason Fischl';dispatch@ietf.org; > hsinnrei@adobe.com > Subject: Re: [AVT] [dispatch] Proposal to form Internet Wideband > Audio Codec > WG > > Hi, > > Roni Even wrote: > > > > I am not sure what prevented you from doing it today at the ITU or > > MPEG, why do you see the IETF handling it differently. > > > > I would also like to remind you and Jean-Marc that once you are > > bringing work to a standard body it may require collaboration with > > other people who will have other proposals that will also address > the > > same requirements and you may need to invest money in comparative > > testing by independent listening labs. > > > > I also think that you will need to supply the codec in source code > and > > provide copy right to the IETF. > > > > I am well aware that bringing work to the IETF would require > collaboration with others. I am not seeking control over the work I am > currently doing and would really welcome such collaboration. The > idea is > only to have the best wideband codec possible without IPR issues. > Given > the ITU and MPEG track record, I think it would be very unlikely for > any > of those organisations to work on an IPR-free codec. > > I also agree with Henry that "the Internet has different criteria than > ITU-T networks may have". Internet adoption follows different patterns > than adoption in the ITU primary target markets. For example, the > Internet has more consumer-reconfigurable software, while the ITU > has to > deal with a lot of fixed hardware deployments. At the ITU, it makes > sense to invest large sums of money into testing and > characterisation of > codecs because the codecs deployed there usually stay around for a > long > time and the infrastructure investments are usually very large. On the > other hand, I would say the investments in codecs for the Internet are > comparatively smaller and, while testing is still important, it is not > as critical as it is for the ITU. > > It's also a choice one has to make. It is unlikely that companies > would > invest money in expensive testing if they are not going to obtain > royalties in return. However, I think we may be able to define some > more > lightweight (collaborative?) testing that is sufficient and doesn't > involve as much investments as what the ITU does. For the Internet, I > believe an IPR-free codec that everyone agrees performs well is better > than a patent-encumbered codec that has had more extensive testing. > This > is again another difference with the ITU: patent-encumbered codecs > tend > to hurt a lot more on the Internet because many applications (e.g. > giving away the client) are very hard (or impossible) when one has to > pay per-channel royalties. > > As for the source code issue you pointed out, all the Xiph codecs are > already published under a very permissive open source license (BSD), > so > this would not really change. > > Jean-Marc > > > Roni > > > > > > > > *From:* avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] *On > Behalf > > Of *Slava Borilin > > *Sent:* Monday, June 01, 2009 11:50 PM > > *To:* jean-marc.valin@octasic.com > > *Cc:* avt@ietf.org; Jason Fischl > > *Subject:* Re: [AVT] [dispatch] Proposal to form Internet Wideband > > Audio Codec WG > > > > > > > > Agree with Jean-Marc. > > SPIRIT is interested to contribute as well - having a dozen of > proprietary > codecs developed, including > > one specifically desgined for internet (SPIRIT IP-MR, which is now > under > WGLC on draft-ietf-avt-rtp-ipmr-04) - > > multi-rate, scalable, adaptive, wideband codec. > > > > We can also continue this work with IETF. > > > > Moreover, most if not all efforts coming from ITU on codecs > unfortunately > are NOT really focused on > > internet-specific codecs (that's why several companies have had to > invent) > - as ITU preference is mainly > > specific (i.e. cellular) networks at first. > > > > however, as we see the greant rise of pure "internet-basd > communications" > (skype, webex/citrix, and many others) - > > we all (and users) are suffering from inefficiency in all currently > "standard" codecs and ambiguity in the choice of > > internet-targeted ones. > > > > Again, we probably can put together enough number of contributors > to the > WG to have the expertise. > > > > regards, > > Slava Borilin > > > > -- > > John Lazzaro wrote: > > > > A traditional response to this type of request is to note that > the > IETF > > > > really doesn't have much in the way of expertise in audio codec > design. > > > > I don't see many of the regulars who present at the AES codec > paper > sessions > > > > posting here on AVT (ditto ICASSP paper sessions for voice > codecs). > It's > > > > a full-time job to keep up-to-date and contribute to that > > > > signal-processing lore. > > > > > > > > Well, there's no reason that the IETF cannot build such an expertise > > in audio codecs. This is actually something in which I'd be > interested > > in getting involved and I'm sure others at Xiph.Org would be > > interested as well. We have several people with audio codec > expertise > > from working on Vorbis, Speex and (more recently) CELT. It turns out > > that the CELT codec currently under development at Xiph actually > meets > > most of the requirements from the original proposal in being a very > > low delay codec with adaptive bit-rate and sampling rate (up to 48 > > kHz), scalable complexity, and good robustness to packet loss. > We'd be > > willing to continue the development with the IETF. Even if not with > > CELT, it's still like to be involved in such a new WG. > > > > Cheers, > > > > Jean-Marc > > > > > _______________________________________________ > 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 --Apple-Mail-334--601341967 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 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA2MDMwMTUwMzBaMCMGCSqGSIb3 DQEJBDEWBBTZM67e5GKu6Si7O+kCGqtna/302jCB1AYJKwYBBAGCNxAEMYHGMIHDMIGuMQswCQYD VQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVU aGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhAv lStUS1saxfCiWQ0fZPKfMIHWBgsqhkiG9w0BCRACCzGBxqCBwzCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkN H2TynzANBgkqhkiG9w0BAQEFAASCAQBHOldssPuB8FynCHo0V+WE01yGgYNIi43npT88VYi2B9Fz H7ZgCWxdeXlfnpadSSefMTzvWlCQTtfKDwYul2dQYIUPTsKTfIsdmPGhnEvo9VXzmZpypaWscz1L 55IAqp7J98v1t1UHyw17URUd26A2DTSVDekMn1zLnXWsI4yX1M1isozujK/NZfTPRvRSVhw5Bmf5 dPn9frYMe1dXKTuKS6PkakVQi8qSAhHmBSsUrqzidSDV8/kjRhTI6w0kqZPCWJrEegCM1zKRjRPj EFoilO2DrqqK4vM+dAxovDUkAZqG8PqNhEmvBClGjWEPn6UI6z+30eXzNRHUFgg6czUEAAAAAAAA --Apple-Mail-334--601341967-- From eburger@standardstrack.com Tue Jun 2 18:51:57 2009 Return-Path: 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 1B9EC3A6A15; Tue, 2 Jun 2009 18:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.005 X-Spam-Level: X-Spam-Status: No, score=-2.005 tagged_above=-999 required=5 tests=[AWL=0.594, 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 J9Z0hc2lyZX2; Tue, 2 Jun 2009 18:51:56 -0700 (PDT) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id 4DA393A68DE; Tue, 2 Jun 2009 18:51:56 -0700 (PDT) Received: from [12.46.252.162] (helo=[172.17.136.184]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1MBfdp-00068B-Uk; Tue, 02 Jun 2009 18:51:47 -0700 Message-Id: From: Eric Burger To: Henning Schulzrinne In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-335--601262898; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 2 Jun 2009 21:51:49 -0400 References: <00a401c9e388$b25c2350$171469f0$%roni@huawei.com> <4A2541B9.2000805@octasic.com> <00d501c9e39a$dcbbbe50$96333af0$%roni@huawei.com> 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, avt@ietf.org Subject: Re: [dispatch] [AVT] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 01:51:57 -0000 --Apple-Mail-335--601262898 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I would strike > - somebody will claim IPR on the resulting work from the list of risks. The *resulting* work would clearly be predicated by both prior art and Note Well. On Jun 2, 2009, at 12:15 PM, Henning Schulzrinne wrote: > I view this as a trade-off. If we pursue this, there are risks: > > - nothing may come of it since there are no experts willing to help > - somebody will claim IPR on the resulting work > - the quality of the codec may not be competitive > > However, if we don't do this, we are stuck with the status quo, > which is not all that satisfactory. Thus, unless there are > significant costs for "innocent bystanders", I see this as a risk > worth taking. In the worst case, we are no worse off than we are > today. In all other cases, we'll have an additional choice for a > wideband codec, even if it's not "the best", just "good enough". > After all, most people use G.711 today, which has a really hard time > making that claim. > > Most real work in the IETF is done by very small teams, typically > less than 10, so as long as we have a handful of people that are > willing to contribute, this can work. It might even work better, > since you may get fewer people who have half-baked opinions - we may > skip the binary vs. XML debates... > > We can set some ground rules ("must be tested with packet loss of > 5%") and then see what happens. Compared to most network protocols, > the likely negative impacts (such as security or congestion control > issues) of even a badly-designed codec are pretty limited. > > Henning > [snip] --Apple-Mail-335--601262898 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 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA2MDMwMTUxNDlaMCMGCSqGSIb3 DQEJBDEWBBQHGHkp0ZW8Gr/hmagsT2KDzR616jCB1AYJKwYBBAGCNxAEMYHGMIHDMIGuMQswCQYD VQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVU aGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhAv lStUS1saxfCiWQ0fZPKfMIHWBgsqhkiG9w0BCRACCzGBxqCBwzCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkN H2TynzANBgkqhkiG9w0BAQEFAASCAQAs42o3DaZnnG2dQw40jPH4yGWTphPw5XJI9INmfn5Dy54J rOBMchzMktJzy7LJPyE6Tkku0NH6bsTUA8Eyxy1nFD/RsVlPhgDg3HcC5OGO3eYwktCfRejcWN2k g5L6dH/ZnFhrP9NmuosyxIedfdaHpQfaU6cmVd1hhPD1fzHe8beiv7/0qLeKfIi3WBsriogzZ65i CD/NgEeybA0JjdIQEgK2Q86z04C8qNWmJ9tSnRyxL/sUl935dpBqGFuIQlbWQ5+D0Ir0MWDozRFh I7I8W05/HEnngn3B63kjOfGCG4KpyJkRKKkJgjaAyDgKO+pmmjFCoCgkAUn6MJuHfvduAAAAAAAA --Apple-Mail-335--601262898-- From Even.roni@huawei.com Wed Jun 3 10:15:52 2009 Return-Path: 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 4F04C3A6C2F; Wed, 3 Jun 2009 10:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.845 X-Spam-Level: X-Spam-Status: No, score=-0.845 tagged_above=-999 required=5 tests=[AWL=-0.351, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eiips9axHwP7; Wed, 3 Jun 2009 10:15:51 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id AFDE93A6847; Wed, 3 Jun 2009 10:15:50 -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 <0KKO003AYALSGO@szxga03-in.huawei.com>; Thu, 04 Jun 2009 01:15:28 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KKO00ABSALSPH@szxga03-in.huawei.com>; Thu, 04 Jun 2009 01:15:28 +0800 (CST) Received: from windows8d787f9 (bzq-79-183-125-11.red.bezeqint.net [79.183.125.11]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KKO00LHJAKSOX@szxml02-in.huawei.com>; Thu, 04 Jun 2009 01:15:28 +0800 (CST) Date: Wed, 03 Jun 2009 20:14:04 +0300 From: Roni Even In-reply-to: <021701c9e030$0a5deef0$1f19ccd0$%roni@huawei.com> To: 'Roni Even' , dispatch@ietf.org Message-id: <021201c9e46e$c1459c70$43d0d550$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_lpXgMXCdnGW+Yj9iFz4pwA)" Content-language: en-us Thread-index: AcngMAPzVFoLlUEtQjqFgqcok28EywENHJgg References: <021701c9e030$0a5deef0$1f19ccd0$%roni@huawei.com> Cc: avt@ietf.org Subject: Re: [dispatch] [AVT] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 17:15:52 -0000 This is a multipart message in MIME format. --Boundary_(ID_lpXgMXCdnGW+Yj9iFz4pwA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, I would like to clarify that I am not against the discussion of codecs at the IETF but I think that before deciding to standardize one at the IETF we should write requirements and analyze current codecs (standard as well as non-standards) and see if they provide a good fit. One of my points is that having an IETF standard track codec does not make it widely deployed as long as the IETF do not mandate codecs. I think that you can look at the discussion in the SIP forum about specifying a codec. I also think (and I will keep mentioning it) that one of the advantages of voice on IP or over the Internet is that you can have a higher quality user experience by using a wideband codec, it is a pity that G.711 is still widely used taking bigger bandwidth than current wideband audio with lower quality. Roni Even 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 --Boundary_(ID_lpXgMXCdnGW+Yj9iFz4pwA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi,

I would like to = clarify that I am not against the discussion of codecs at the IETF  but I think that = before deciding to standardize one at the IETF we should write requirements and = analyze current codecs (standard as well as non-standards) and see if they = provide a good fit.

 

One of my points is = that having an IETF standard track codec does not make it widely deployed as long as = the IETF do not mandate codecs. I think that you can look at the discussion = in the SIP forum about specifying a codec.

 

I also think (and I = will keep mentioning it) that one of the advantages of voice on IP or over the = Internet is that you can have a higher quality user experience by using a = wideband codec, it is a pity that G.711 is still widely used taking bigger bandwidth = than current wideband audio with lower quality.

 

Roni = Even

 

 

 

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

 

--Boundary_(ID_lpXgMXCdnGW+Yj9iFz4pwA)-- From jmh@joelhalpern.com Wed Jun 3 10:40:24 2009 Return-Path: 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 A4EC53A7074; Wed, 3 Jun 2009 10:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.532 X-Spam-Level: X-Spam-Status: No, score=-3.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 PChoUGB48Dho; Wed, 3 Jun 2009 10:40:23 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id DC9CB3A7075; Wed, 3 Jun 2009 10:39:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id E1F63430254; Wed, 3 Jun 2009 10:39:33 -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 E266443023D; Wed, 3 Jun 2009 10:39:32 -0700 (PDT) Message-ID: <4A26B54D.8070800@joelhalpern.com> Date: Wed, 03 Jun 2009 13:39:25 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: dispatch@ietf.org References: <021701c9e030$0a5deef0$1f19ccd0$%roni@huawei.com> <021201c9e46e$c1459c70$43d0d550$%roni@huawei.com> In-Reply-To: <021201c9e46e$c1459c70$43d0d550$%roni@huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: avt@ietf.org Subject: Re: [dispatch] [AVT] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 17:40:24 -0000 To be blunt, without some better explanation of why the IETF ought to do this, and how the IETF is likely to be successful in doing this, I think it would be a disservice to the folks who want to work on this to encourage them to believe that the only obstacle is a clear problem definition. To be clear, I have absolutely no problem with a community using an IETF based email list to discuss their codec ideas, work out why they want to work on a new one, organize thier ideas for where that work should be done, etc. So far, what strikes me is that most of the folks who would be called upon to evaluate a requirements document, or an actual protocol, have little or no expertise in codec design either from a mathematical or a software perspective (there are a few exceptions in both those regards, folks like Henning), and have little or no experience in the observed difficulties in actually standardizing codecs. (Folks I ahve talked to who have been down that road have indicated that it involves many aspects that are foreign to IETF experience and practice.) Yours, Joel M. Halpern Roni Even wrote: > > > Hi, > > I would like to clarify that I am not against the discussion of codecs > at the IETF but I think that before deciding to standardize one at the > IETF we should write requirements and analyze current codecs (standard > as well as non-standards) and see if they provide a good fit. > > > > One of my points is that having an IETF standard track codec does not > make it widely deployed as long as the IETF do not mandate codecs. I > think that you can look at the discussion in the SIP forum about > specifying a codec. > > > > I also think (and I will keep mentioning it) that one of the advantages > of voice on IP or over the Internet is that you can have a higher > quality user experience by using a wideband codec, it is a pity that > G.711 is still widely used taking bigger bandwidth than current wideband > audio with lower quality. > > > > Roni Even > > > > > > > > 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 From jean-marc.valin@octasic.com Wed Jun 3 11:47:39 2009 Return-Path: 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 D35343A6E68; Wed, 3 Jun 2009 11:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=1.150, 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 kKgfbGD7tXVL; Wed, 3 Jun 2009 11:47:38 -0700 (PDT) Received: from MAILEXCH.octasic.com (mail.octasic.com [216.208.79.2]) by core3.amsl.com (Postfix) with ESMTP id B5B553A6E35; Wed, 3 Jun 2009 11:47:38 -0700 (PDT) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Jun 2009 14:47:35 -0400 Message-ID: <4A26C563.8030200@octasic.com> Date: Wed, 03 Jun 2009 14:48:03 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: jmh@joelhalpern.com References: <021701c9e030$0a5deef0$1f19ccd0$%roni@huawei.com> <021201c9e46e$c1459c70$43d0d550$%roni@huawei.com> In-Reply-To: <021201c9e46e$c1459c70$43d0d550$%roni@huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Jun 2009 18:47:35.0055 (UTC) FILETIME=[C26921F0:01C9E47B] X-Mailman-Approved-At: Wed, 03 Jun 2009 12:14:57 -0700 Cc: dispatch@ietf.org, avt@ietf.org, Roni Even Subject: Re: [dispatch] [AVT] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 18:47:39 -0000 > So far, what strikes me is that most of the folks who would be called > upon to evaluate a requirements document, or an actual protocol, have > little or no expertise in codec design either from a mathematical or a > software perspective (there are a few exceptions in both those > regards, folks like Henning), and have little or no experience in the > observed difficulties in actually standardizing codecs. (Folks I ahve > talked to who have been down that road have indicated that it involves > many aspects that are foreign to IETF experience and practice.) Let me start by stating that codec design is no rocket science. There are many people out there who know how to write audio codecs and many more who have sufficient skills to contribute. At this point, there is already interest from several people with actual codec design experience at Skype, Xiph.Org and SPIRIT. The internet community has clear and considerable needs which are not being adequately met by the existing standards bodies. We have parties experienced with codec development who want to work together within the IETF. Why do you believe the risk of not succeeding justifies not even attempting the effort? Cheers, Jean-Marc From dyork@voxeo.com Wed Jun 3 12:45:51 2009 Return-Path: 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 CB1143A6DD1; Wed, 3 Jun 2009 12:45:51 -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 Hnz5GI40nFFM; Wed, 3 Jun 2009 12:45:50 -0700 (PDT) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with SMTP id 91B0F3A698C; Wed, 3 Jun 2009 12:45:50 -0700 (PDT) Received: from [66.65.231.233] (account dyork HELO pc-00148.lodestar2.local) by voxeo.com (CommuniGate Pro SMTP 5.2.3) with ESMTPSA id 46290963; Wed, 03 Jun 2009 19:45:44 +0000 Message-Id: From: Dan York To: dispatch@ietf.org In-Reply-To: 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: Wed, 3 Jun 2009 15:45:42 -0400 References: <00a401c9e388$b25c2350$171469f0$%roni@huawei.com> <4A2541B9.2000805@octasic.com> <00d501c9e39a$dcbbbe50$96333af0$%roni@huawei.com> X-Mailer: Apple Mail (2.930.3) Cc: avt@ietf.org Subject: Re: [dispatch] [AVT] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 19:45:51 -0000 I've been reading this thread with great interest as for the past probably 6 years or so I've been saying to anyone who will listen (and to those who won't ;-) that one factor that will help "IP communications/VoIP/UC/whatever-marketing-term-we-want-to-rename-our- products-to-this-week" to really find wide adoption is to provide a "rich communication experience" better than what people are used to now. Wideband audio is, to me, a huge part of that. However, I completely agree with Henning on this point: > On Jun 2, 2009, at 12:15 PM, Henning Schulzrinne wrote: > >> However, if we don't do this, we are stuck with the status quo, >> which is not all that satisfactory. The status quo is not satisfactory. If you want to add wideband audio to your product, you've got an alphabet soup of mutually incompatible options with vastly different licensing terms/fees/options and source code availability. I think we ultimately need a "G.711 for wideband", i.e. a wideband codec that anyone can implement in any device. I'd argue that a large part of the reason we are "stuck" with so many people in VoIP using G. 711 is precisely because ANYONE can implement it in basically ANY device. You can buy a G.711 codec implementation or you can write your own or find some code on the Internet (google "G.711 source code"). You can implement G.711 in your big softswitch or IP-PBX... or you can implement it in some small embedded device. And it interoperates. We need that kind of codec for wideband.... which I would say is "royalty-free" and needs to have "open source" implementations available. (And yes, I know Speex is out there - I don't have a view as to why it is not more widely implemented. And yes, I know Skype is giving away SILK royalty-free, but it's not open source.) Can the IETF help with this? I don't know... but I think it's worth a shot. If there is a group that is passionate about this (and there seems to be) then lets get the mailing list set up and have it go the regular List -> BOF -> Working Group trajectory. In the best case perhaps we come out with the codec we want/need. At the very worst I think we'd wind up with at least creating some good discussions and requirements for what we do need. My 2 cents, Dan -- Dan York, Director of Conversations Voxeo Corporation http://www.voxeo.com dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork Join the Voxeo conversation: Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Twitter: http://twitter.com/voxeo http://twitter.com/danyork Facebook: http://www.voxeo.com/facebook From jmh@joelhalpern.com Wed Jun 3 12:57:22 2009 Return-Path: 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 D1F0628C189; Wed, 3 Jun 2009 12:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.542 X-Spam-Level: X-Spam-Status: No, score=-3.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 N-bhtFBmqVZC; Wed, 3 Jun 2009 12:57:22 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 001E53A67E6; Wed, 3 Jun 2009 12:57:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 1956D43029A; Wed, 3 Jun 2009 12:57:24 -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 4CD0943025E; Wed, 3 Jun 2009 12:57:23 -0700 (PDT) Message-ID: <4A26D59B.20905@joelhalpern.com> Date: Wed, 03 Jun 2009 15:57:15 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: dispatch@ietf.org References: <00a401c9e388$b25c2350$171469f0$%roni@huawei.com> <4A2541B9.2000805@octasic.com> <00d501c9e39a$dcbbbe50$96333af0$%roni@huawei.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: avt@ietf.org Subject: Re: [dispatch] [AVT] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 19:57:22 -0000 Let's be clear. I am not trying to argue that the existing codecs are good enough. I hear everyone saying that they are not. However, the IETF is not the answer to all the worlds standards problems. In this case, there are a number of existing bodies addressing these problems. There also are apparently existing solutions with near the right properties. 1) The IETF is structurally not well suited to dealing with the kinds of patent problems that we are dealing with. 2) The IETF, based on history, is not very good at dealing with market acceptance issues (questions such as why isn't Speex or SILK being accepted.) 3) IETF WGs are very bad at working out what the real problems are. THey are good at working out protocol issues. But this is not primarily a protocol issue, from what everyone is saying. I have heard rumors of several other bodies that are working in this space. Given that we have lately been working very hard to keep other folks from encroaching on our patch, we ought to be sensitive to encroaching on theirs. And now, before I start repeating myself, I will try to stay quite for a few days and keep listening. Yours, Joel Dan York wrote: > I've been reading this thread with great interest as for the past > probably 6 years or so I've been saying to anyone who will listen (and > to those who won't ;-) that one factor that will help "IP > communications/VoIP/UC/whatever-marketing-term-we-want-to-rename-our-products-to-this-week" > to really find wide adoption is to provide a "rich communication > experience" better than what people are used to now. > > Wideband audio is, to me, a huge part of that. > > However, I completely agree with Henning on this point: > >> On Jun 2, 2009, at 12:15 PM, Henning Schulzrinne wrote: >> >>> However, if we don't do this, we are stuck with the status quo, which >>> is not all that satisfactory. > > > The status quo is not satisfactory. If you want to add wideband audio > to your product, you've got an alphabet soup of mutually incompatible > options with vastly different licensing terms/fees/options and source > code availability. > > I think we ultimately need a "G.711 for wideband", i.e. a wideband codec > that anyone can implement in any device. I'd argue that a large part of > the reason we are "stuck" with so many people in VoIP using G.711 is > precisely because ANYONE can implement it in basically ANY device. You > can buy a G.711 codec implementation or you can write your own or find > some code on the Internet (google "G.711 source code"). You can > implement G.711 in your big softswitch or IP-PBX... or you can implement > it in some small embedded device. > > And it interoperates. > > We need that kind of codec for wideband.... which I would say is > "royalty-free" and needs to have "open source" implementations > available. (And yes, I know Speex is out there - I don't have a view > as to why it is not more widely implemented. And yes, I know Skype is > giving away SILK royalty-free, but it's not open source.) > > Can the IETF help with this? I don't know... but I think it's worth a > shot. If there is a group that is passionate about this (and there > seems to be) then lets get the mailing list set up and have it go the > regular List -> BOF -> Working Group trajectory. > > In the best case perhaps we come out with the codec we want/need. At > the very worst I think we'd wind up with at least creating some good > discussions and requirements for what we do need. > > My 2 cents, > Dan > From hsinnrei@adobe.com Wed Jun 3 13:24:08 2009 Return-Path: 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 1FD2C3A698F; Wed, 3 Jun 2009 13:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[AWL=2.377, 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 TR0lM8u5q5gX; Wed, 3 Jun 2009 13:24:06 -0700 (PDT) Received: from exprod6og115.obsmtp.com (exprod6og115.obsmtp.com [64.18.1.35]) by core3.amsl.com (Postfix) with ESMTP id 6CC8028C29A; Wed, 3 Jun 2009 13:23:45 -0700 (PDT) Received: from source ([192.150.8.22]) by exprod6ob115.postini.com ([64.18.5.12]) with SMTP ID DSNKSibbxAs0V41SpXXx1qKQTTkoshCFi7dA@postini.com; Wed, 03 Jun 2009 13:23:49 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n53KNTWG000781; Wed, 3 Jun 2009 13:23:30 -0700 (PDT) Received: from nacas01.corp.adobe.com (nacas01.corp.adobe.com [10.8.189.99]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n53KNSiq008083; Wed, 3 Jun 2009 13:23:28 -0700 (PDT) Received: from nacas03.corp.adobe.com (10.8.189.121) by nacas01.corp.adobe.com (10.8.189.99) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 3 Jun 2009 13:23:28 -0700 Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nacas03.corp.adobe.com ([10.8.189.121]) with mapi; Wed, 3 Jun 2009 13:23:28 -0700 From: Henry Sinnreich To: "Joel M. Halpern" , "dispatch@ietf.org" Date: Wed, 3 Jun 2009 13:23:26 -0700 Thread-Topic: [dispatch] [AVT] Proposal to form Internet Wideband Audio Codec WG Thread-Index: AcnkhYhHhDqOeaeyS3aq802n9l5R9AAA531L Message-ID: In-Reply-To: <4A26D59B.20905@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_C64C45EE3ECEhsinnreiadobecom_" MIME-Version: 1.0 Cc: "avt@ietf.org" Subject: Re: [dispatch] [AVT] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 20:24:08 -0000 --_000_C64C45EE3ECEhsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Joel, >And now, before I start repeating myself I will also repeat here that it makes no sense to have this huge IETF work = for voice (mainly) signaling (SIP, XMPP, NSIS) and no standard for an _Inte= rnet_ voice codec. Going by your guidance for avoiding a voice codec, the IETF may also just g= ive up signaling for voice and close down all the voice related signaling W= Gs. And since we are at it, why not all the A/V codec profiles in AVT? :-) This is hard to rationalize. Henry On 6/3/09 2:57 PM, "Joel M. Halpern" wrote: Let's be clear. I am not trying to argue that the existing codecs are good enough. I hear everyone saying that they are not. However, the IETF is not the answer to all the worlds standards problems. In this case, there are a number of existing bodies addressing these problems. There also are apparently existing solutions with near the right properties. 1) The IETF is structurally not well suited to dealing with the kinds of patent problems that we are dealing with. 2) The IETF, based on history, is not very good at dealing with market acceptance issues (questions such as why isn't Speex or SILK being accepted.) 3) IETF WGs are very bad at working out what the real problems are. THey are good at working out protocol issues. But this is not primarily a protocol issue, from what everyone is saying. I have heard rumors of several other bodies that are working in this space. Given that we have lately been working very hard to keep other folks from encroaching on our patch, we ought to be sensitive to encroaching on theirs. And now, before I start repeating myself, I will try to stay quite for a few days and keep listening. Yours, Joel Dan York wrote: > I've been reading this thread with great interest as for the past > probably 6 years or so I've been saying to anyone who will listen (and > to those who won't ;-) that one factor that will help "IP > communications/VoIP/UC/whatever-marketing-term-we-want-to-rename-our-prod= ucts-to-this-week" > to really find wide adoption is to provide a "rich communication > experience" better than what people are used to now. > > Wideband audio is, to me, a huge part of that. > > However, I completely agree with Henning on this point: > >> On Jun 2, 2009, at 12:15 PM, Henning Schulzrinne wrote: >> >>> However, if we don't do this, we are stuck with the status quo, which >>> is not all that satisfactory. > > > The status quo is not satisfactory. If you want to add wideband audio > to your product, you've got an alphabet soup of mutually incompatible > options with vastly different licensing terms/fees/options and source > code availability. > > I think we ultimately need a "G.711 for wideband", i.e. a wideband codec > that anyone can implement in any device. I'd argue that a large part of > the reason we are "stuck" with so many people in VoIP using G.711 is > precisely because ANYONE can implement it in basically ANY device. You > can buy a G.711 codec implementation or you can write your own or find > some code on the Internet (google "G.711 source code"). You can > implement G.711 in your big softswitch or IP-PBX... or you can implement > it in some small embedded device. > > And it interoperates. > > We need that kind of codec for wideband.... which I would say is > "royalty-free" and needs to have "open source" implementations > available. (And yes, I know Speex is out there - I don't have a view > as to why it is not more widely implemented. And yes, I know Skype is > giving away SILK royalty-free, but it's not open source.) > > Can the IETF help with this? I don't know... but I think it's worth a > shot. If there is a group that is passionate about this (and there > seems to be) then lets get the mailing list set up and have it go the > regular List -> BOF -> Working Group trajectory. > > In the best case perhaps we come out with the codec we want/need. At > the very worst I think we'd wind up with at least creating some good > discussions and requirements for what we do need. > > My 2 cents, > Dan > _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_C64C45EE3ECEhsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [dispatch] [AVT] Proposal to form Internet Wideband Audio Codec = WG Joel,

>And now, before I start repeating myself

I will also repeat here that it makes no sense to have this huge IETF work = for voice (mainly) signaling (SIP, XMPP, NSIS) and no standard for an _Inte= rnet_ voice codec.

Going by your guidance for avoiding a voice codec, the IETF may also just g= ive up signaling for voice and close down all the voice related signaling W= Gs. And since we are at it, why not all the A/V codec profiles in AVT? :-) =
This is hard to rationalize.

Henry


On 6/3/09 2:57 PM, "Joel M. Halpern" <jmh@joelhalpern.com> wrote:

Let's be clear.  I am not trying to ar= gue that the existing codecs are
good enough.  I hear everyone saying that they are not.
However, the IETF is not the answer to all the worlds standards problems.
In this case, there are a number of existing bodies addressing these
problems.  There also are apparently existing solutions with near the<= BR> right properties.
1) The IETF is structurally not well suited to dealing with the kinds of patent problems that we are dealing with.
2) The IETF, based on history, is not very good at dealing with market
acceptance issues (questions such as why isn't Speex or SILK being
accepted.)
3) IETF WGs are very bad at working out what the real problems are.
THey are good at working out protocol issues.  But this is not primari= ly
a protocol issue, from what everyone is saying.

I have heard rumors of several other bodies that are working in this
space.  Given that we have lately been working very hard to keep other=
folks from encroaching on our patch, we ought to be sensitive to
encroaching on theirs.

And now, before I start repeating myself, I will try to stay quite for a few days and keep listening.
Yours,
Joel


Dan York wrote:
> I've been reading this thread with great interest as for the past
> probably 6 years or so I've been saying to anyone who will listen (and=
> to those who won't ;-) that one factor that will help "IP
> communications/VoIP/UC/whatever-marketing-term-we-want-to-rename-our-p= roducts-to-this-week"
> to really find wide adoption is to provide a "rich communication<= BR> > experience" better than what people are used to now.
>
> Wideband audio is, to me, a huge part of that.
>
> However, I completely agree with Henning on this point:
>
>> On Jun 2, 2009, at 12:15 PM, Henning Schulzrinne wrote:
>>
>>> However, if we don't do this, we are stuck with the status quo= , which
>>> is not all that satisfactory.
>
>
> The status quo is not satisfactory.  If you want to add wideband = audio
> to your product, you've got an alphabet soup of mutually incompatible<= BR> > options with vastly different licensing terms/fees/options and source<= BR> > code availability.
>
> I think we ultimately need a "G.711 for wideband", i.e. a wi= deband codec
> that anyone can implement in any device.  I'd argue that a large = part of
> the reason we are "stuck" with so many people in VoIP using = G.711 is
> precisely because ANYONE can implement it in basically ANY device. &nb= sp;You
> can buy a G.711 codec implementation or you can write your own or find=
> some code on the Internet (google "G.711 source code"). You = can
> implement G.711 in your big softswitch or IP-PBX... or you can impleme= nt
> it in some small embedded device.
>
> And it interoperates.
>
> We need that kind of codec for wideband.... which I would say is
> "royalty-free" and needs to have "open source" imp= lementations
> available.   (And yes, I know Speex is out there - I don't h= ave a view
> as to why it is not more widely implemented.  And yes, I know Sky= pe is
> giving away SILK royalty-free, but it's not open source.)
>
> Can the IETF help with this?  I don't know... but I think it's wo= rth a
> shot.  If there is a group that is passionate about this (and the= re
> seems to be) then lets get the mailing list set up and have it go the<= BR> > regular List -> BOF -> Working Group trajectory.
>
> In the best case perhaps we come out with the codec we want/need. &nbs= p;At
> the very worst I think we'd wind up with at least creating some good > discussions and requirements for what we do need.
>
> My 2 cents,
> Dan
>
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf= .org/mailman/listinfo/dispatch

--_000_C64C45EE3ECEhsinnreiadobecom_-- From jason.fischl@skype.net Wed Jun 3 15:09:12 2009 Return-Path: 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 570973A6C6F; Wed, 3 Jun 2009 15:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.223 X-Spam-Level: X-Spam-Status: No, score=0.223 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_ADOBE2=2.455, MANGLED_INXPNS=2.3, 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 u1wHThb5OjhD; Wed, 3 Jun 2009 15:09:04 -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 E77A728C164; Wed, 3 Jun 2009 15:08:58 -0700 (PDT) X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.41,300,1241420400"; d="scan'208";a="49412153" Received: from den-exb-02.corp.ebay.com ([10.101.44.10]) by den-mipot-002.corp.ebay.com with ESMTP; 03 Jun 2009 15:08:59 -0700 Received: from DEN-EXM-04.corp.ebay.com ([10.241.16.37]) by DEN-EXB-02.corp.ebay.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Jun 2009 16:08:59 -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.26]) with Microsoft Exchange Server HTTP-DAV ; Wed, 3 Jun 2009 22:08:58 +0000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Wed, 03 Jun 2009 15:08:41 -0700 From: Jason Fischl To: Eric Burger , Henry Sinnreich Message-ID: Thread-Topic: [dispatch] [AVT] Proposal to form Internet Wideband Audio Codec WG Thread-Index: Acnkl9pGVLeMkYWfMECYiGj9wx9NVA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 03 Jun 2009 22:08:59.0655 (UTC) FILETIME=[E564C170:01C9E497] Cc: dispatch@ietf.org, avt@ietf.org Subject: Re: [dispatch] [AVT] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 22:09:12 -0000 I've requested a mailing list and it has been approved. It should be live in a day or so. I'll post the details once it is live. Jason On 6/2/09 6:50 PM, "Eric Burger" wrote: > To directly answer Henry, having a mail list and the initial (and > possibly detailed) discussion hosted at the IETF costs less than the > discussion we are having here. If a codec comes out of it, without > having a BOF or WG, that's great! If not, at least there was a forum > for doing it. > > I can also offer a SIP Forum list if people still really, really don't > like the idea of even discussing the topic under even the most > faintest of auspices of the IETF. > > If you think I am schizophrenic by offering we can have a discussion > in the IETF and at the same time I doubt we could ever have a formal > work group to create the codec, you would be only slightly > correct :-) But seriously: the IETF (AVT in particular) can pickup > the wire format for a codec, once the codec exists. Having a mail list > WITHOUT A WORK GROUP give people who want to work on this a venue to > do the work, without burdening the AD's, IESG, and the rest of the > community. If a codec pops out, then we can run with it. > > On Jun 2, 2009, at 12:44 PM, Spencer Dawkins wrote: > >> I am not an area director, nor do i play one on IPTV, but my >> suggestion for anyone interested would be to >> >> - request a non-WG mailing list (from either of the RAI area >> directors), >> >> - announce it on this mailing list (and others that seem to be >> appropriate, and >> >> - start discussions, which the area directors typically look at when >> judging whether there's enough interest and enough clue to justify >> approving a BOF and/or chartering a working group. >> >> I didn't see a mailing list included in Jason's proposal - if I >> missed one, my apologies. >> >> If people at the IETF can do this work, and want to do this work, >> IETF process policies should not get in the way of that happening. >> >> And I haven't heard of an AD turning down a request for a non-WG >> mailing list yet, keeping in mind that one of said lists is ietf- >> sailors, for people interested in sailing to/from/at IETF meetings - >> the bar is (appropriately) low. >> >> Thanks, >> >> Spencer >> ----- Original Message ----- >> From: Henry Sinnreich >> To: Roni Even ; Jean-Marc Valin >> Cc: dispatch@ietf.org ; Slava Borilin ; avt@ietf.org >> Sent: Tuesday, June 02, 2009 11:12 AM >> Subject: Re: [dispatch] [AVT] Proposal to form Internet Wideband >> Audio Codec WG >> >>> This leaves the other reasons I heard for doing it at the IETF >> which is the >>> price of participating >> >> This is an important point. >> Given the travel constraints for some of the most valuable potential >> contributors and reviewers, could we envisage online work until the >> economy improves, so that an eventual BOF to start with should not >> be starved of attendees? An online BOF? >> >> There are several free online meeting tools available... >> >> How can this be done within the IETF policy? >> >> Henry >> >> >> On 6/2/09 10:57 AM, "Roni Even" wrote: >> >> Hi, >> I do not want to sound like someone who is for IPR (I am not), but >> why stop >> at codec, let's require it for all IETF work. There are IPR on IETF >> work >> which is must simpler, in my view, than wide band audio codecs. >> >> I think that we can start with "royalty free" even though I am not >> sure that >> it will accepted as part of the charter of any other work group so >> why pick >> on codecs which require more work. >> >> This leaves the other reasons I heard for doing it at the IETF which >> is the >> price of participating (cheaper than being an ITU-T member) and >> maybe design >> less expensive characterization tests. >> >> Roni >> >> >> -----Original Message----- >> From: Jean-Marc Valin [mailto:jean-marc.valin@octasic.com] >> Sent: Tuesday, June 02, 2009 6:14 PM >> To: Roni Even >> Cc: 'Slava Borilin'; avt@ietf.org; 'Jason Fischl';dispatch@ietf.org; >> hsinnrei@adobe.com >> Subject: Re: [AVT] [dispatch] Proposal to form Internet Wideband >> Audio Codec >> WG >> >> Hi, >> >> Roni Even wrote: >>> >>> I am not sure what prevented you from doing it today at the ITU or >>> MPEG, why do you see the IETF handling it differently. >>> >>> I would also like to remind you and Jean-Marc that once you are >>> bringing work to a standard body it may require collaboration with >>> other people who will have other proposals that will also address >> the >>> same requirements and you may need to invest money in comparative >>> testing by independent listening labs. >>> >>> I also think that you will need to supply the codec in source code >> and >>> provide copy right to the IETF. >>> >> >> I am well aware that bringing work to the IETF would require >> collaboration with others. I am not seeking control over the work I am >> currently doing and would really welcome such collaboration. The >> idea is >> only to have the best wideband codec possible without IPR issues. >> Given >> the ITU and MPEG track record, I think it would be very unlikely for >> any >> of those organisations to work on an IPR-free codec. >> >> I also agree with Henry that "the Internet has different criteria than >> ITU-T networks may have". Internet adoption follows different patterns >> than adoption in the ITU primary target markets. For example, the >> Internet has more consumer-reconfigurable software, while the ITU >> has to >> deal with a lot of fixed hardware deployments. At the ITU, it makes >> sense to invest large sums of money into testing and >> characterisation of >> codecs because the codecs deployed there usually stay around for a >> long >> time and the infrastructure investments are usually very large. On the >> other hand, I would say the investments in codecs for the Internet are >> comparatively smaller and, while testing is still important, it is not >> as critical as it is for the ITU. >> >> It's also a choice one has to make. It is unlikely that companies >> would >> invest money in expensive testing if they are not going to obtain >> royalties in return. However, I think we may be able to define some >> more >> lightweight (collaborative?) testing that is sufficient and doesn't >> involve as much investments as what the ITU does. For the Internet, I >> believe an IPR-free codec that everyone agrees performs well is better >> than a patent-encumbered codec that has had more extensive testing. >> This >> is again another difference with the ITU: patent-encumbered codecs >> tend >> to hurt a lot more on the Internet because many applications (e.g. >> giving away the client) are very hard (or impossible) when one has to >> pay per-channel royalties. >> >> As for the source code issue you pointed out, all the Xiph codecs are >> already published under a very permissive open source license (BSD), >> so >> this would not really change. >> >> Jean-Marc >> >>> Roni >>> >>> >>> >>> *From:* avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] *On >> Behalf >>> Of *Slava Borilin >>> *Sent:* Monday, June 01, 2009 11:50 PM >>> *To:* jean-marc.valin@octasic.com >>> *Cc:* avt@ietf.org; Jason Fischl >>> *Subject:* Re: [AVT] [dispatch] Proposal to form Internet Wideband >>> Audio Codec WG >>> >>> >>> >>> Agree with Jean-Marc. >>> SPIRIT is interested to contribute as well - having a dozen of >> proprietary >> codecs developed, including >>> one specifically desgined for internet (SPIRIT IP-MR, which is now >> under >> WGLC on draft-ietf-avt-rtp-ipmr-04) - >>> multi-rate, scalable, adaptive, wideband codec. >>> >>> We can also continue this work with IETF. >>> >>> Moreover, most if not all efforts coming from ITU on codecs >> unfortunately >> are NOT really focused on >>> internet-specific codecs (that's why several companies have had to >> invent) >> - as ITU preference is mainly >>> specific (i.e. cellular) networks at first. >>> >>> however, as we see the greant rise of pure "internet-basd >> communications" >> (skype, webex/citrix, and many others) - >>> we all (and users) are suffering from inefficiency in all currently >> "standard" codecs and ambiguity in the choice of >>> internet-targeted ones. >>> >>> Again, we probably can put together enough number of contributors >> to the >> WG to have the expertise. >>> >>> regards, >>> Slava Borilin >>> >>> -- >>> John Lazzaro wrote: >>> >>> A traditional response to this type of request is to note that >> the >> IETF >>> >>> really doesn't have much in the way of expertise in audio codec >> design. >>> >>> I don't see many of the regulars who present at the AES codec >> paper >> sessions >>> >>> posting here on AVT (ditto ICASSP paper sessions for voice >> codecs). >> It's >>> >>> a full-time job to keep up-to-date and contribute to that >>> >>> signal-processing lore. >>> >>> >>> >>> Well, there's no reason that the IETF cannot build such an expertise >>> in audio codecs. This is actually something in which I'd be >> interested >>> in getting involved and I'm sure others at Xiph.Org would be >>> interested as well. We have several people with audio codec >> expertise >>> from working on Vorbis, Speex and (more recently) CELT. It turns out >>> that the CELT codec currently under development at Xiph actually >> meets >>> most of the requirements from the original proposal in being a very >>> low delay codec with adaptive bit-rate and sampling rate (up to 48 >>> kHz), scalable complexity, and good robustness to packet loss. >> We'd be >>> willing to continue the development with the IETF. Even if not with >>> CELT, it's still like to be involved in such a new WG. >>> >>> Cheers, >>> >>> Jean-Marc >> >> >> >> >> _______________________________________________ >> 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 dean.willis@softarmor.com Wed Jun 3 15:16:30 2009 Return-Path: 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 DBD803A6CF7; Wed, 3 Jun 2009 15:16:30 -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 XaW1OwgVa7i0; Wed, 3 Jun 2009 15:16:30 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id AF68128C1AC; Wed, 3 Jun 2009 15:16:25 -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 n53MGPSi015788 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 3 Jun 2009 17:16:27 -0500 Message-Id: <94890500-A706-4B1A-9BA9-C0D632257E54@softarmor.com> From: Dean Willis To: Dan York In-Reply-To: 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, 3 Jun 2009 17:16:20 -0500 References: <00a401c9e388$b25c2350$171469f0$%roni@huawei.com> <4A2541B9.2000805@octasic.com> <00d501c9e39a$dcbbbe50$96333af0$%roni@huawei.com> X-Mailer: Apple Mail (2.935.3) Cc: dispatch@ietf.org, avt@ietf.org Subject: Re: [dispatch] [AVT] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 22:16:31 -0000 On Jun 3, 2009, at 2:45 PM, Dan York wrote: > I think we ultimately need a "G.711 for wideband", i.e. a wideband > codec that anyone can implement in any device. I'd argue that a > large part of the reason we are "stuck" with so many people in VoIP > using G.711 is precisely because ANYONE can implement it in > basically ANY device. You can buy a G.711 codec implementation or > you can write your own or find some code on the Internet (google "G. > 711 source code"). You can implement G.711 in your big softswitch or > IP-PBX... or you can implement it in some small embedded device. We have such a codec: 16 bit sampling at 44.1 khz, aka "what your CD player does in stereo", or L16 audio as defined in RFC 1890. While there might be some IPR on it, it clearly hasn't kept everybody and their dog from playing the audio format on devices ranging from a $3 CD player on up. We also have RFC 3190, which does RTP format for 12-bit DAT audio and 20 and 24 bit linear sampled audio. So what is it that we need for a "wideband G.711" that isn't already in there somewhere? It sounds like what you want is more a wideband iLBC, which is an intellectually much larger challenge. -- Dean From xiphmont@gmail.com Wed Jun 3 19:12:50 2009 Return-Path: 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 B25C23A6C35; Wed, 3 Jun 2009 19:12:50 -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 gAxfE+4UYJdD; Wed, 3 Jun 2009 19:12:50 -0700 (PDT) Received: from mail-qy0-f204.google.com (mail-qy0-f204.google.com [209.85.221.204]) by core3.amsl.com (Postfix) with ESMTP id 608EB3A6BCC; Wed, 3 Jun 2009 19:12:50 -0700 (PDT) Received: by qyk42 with SMTP id 42so723904qyk.29 for ; Wed, 03 Jun 2009 19:12:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=fVUQrqqX2sqRuhT5W+DSYKlzPaPovfT/ccYv0Yhrojg=; b=XYSNAD8X3feutZO5dg/TSXIW3t2Q2iY14L5DZJfbFrWh2sDeGObg+PhsYeS5n8MxYm VWjcON6FmRxoHwcxfXjmiLJb+YrxFp8Prx4lkMYeUp8T14t31EPJ94+RgH3I0StMrN4d WmWpqh5Vcg2uPiH4HHamkprzhSoU8oLI1RgQY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=P0DtVmRxs06srK+L+Yf0yMx9fMxiftJGPBfs2TaE8WEVDT7LlZOqeSkyrgpW71i90f ThWDRP2x5aPk1+XkT7yY3tEyIsZCaa3RdD0J3w237ctfKGa9Xh3o34YkKzjxxHMgaDAF Q4AXm20NQb3zZX/LT6RBuWXGe4+1rI4FH3iWc= MIME-Version: 1.0 Received: by 10.231.11.140 with SMTP id t12mr444732ibt.44.1244081568514; Wed, 03 Jun 2009 19:12:48 -0700 (PDT) Date: Wed, 3 Jun 2009 22:12:48 -0400 Message-ID: <806dafc20906031912u230d418dn55af16feabb84019@mail.gmail.com> From: Christopher Montgomery To: avt@ietf.org, dispatch@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] [AVT] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 02:12:50 -0000 I've been following this discussion through the archives, and it seems time to dip a toe in. Apologies for the vaguely formal language, I'm speaking for my organization. I'm happy to see more IETF interest in taking up the subject of royalty-free codecs for the Internet. Several of our Xiph.Org members have been quietly advocating for this within IETF for some time, and it's nice to see the call coming from other sources as well. It's no coincidence that the Internet's greatest success stories have all been unencumbered. Any new technology that rolls out with a royalty pricetag has a steep uphill climb to do anything more than fragment and muddy both social and business interoperability. The Xiph.Org Foundation is a registered non-profit created toward designing and deploying unencumered media codecs. I'd like to stand up and say officially that we would very much like to work with the IETF on roaylty-free codecs. Xiph.Org does two things: we research fundamental codec technology to further the state of the art, then develop and deploy this research without royalty or licensing restrictions. We've created and made available the Ogg container format and the Vorbis, Speex, FLAC, Theora and CELT codecs. Ogg-related protocols are already covered by a few RFCs. We exert no IP claims on our specifications and our reference implementations are all BSD licensed. Our codecs are a means to an end, not an end in and of themselves. Unfortunately, unencumbered access to basic media technology (a level playing field) has meant reinventing and reimplementing from the ground up. On the plus side, reinventing and reimplementing has allowed us to use new [and rediscovered] techniques to better fit the needs of the Internet. ...so we'd like to toss our hat into this ring and volunteer the experience our own organization has gained in the past 15 years of building royalty-free, unencumbered media tech from scratch. We look forward to working with others who recognize the importance of open and free media technology. Monty Xiph.Org From drage@alcatel-lucent.com Thu Jun 4 03:00:38 2009 Return-Path: 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 8BC7F3A6DDF; Thu, 4 Jun 2009 03:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=-0.400, 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 XF3XncQcRBNy; Thu, 4 Jun 2009 03:00:37 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id 5559B3A6C17; Thu, 4 Jun 2009 03:00:36 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n54A0aDo029072 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 4 Jun 2009 12:00:36 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Thu, 4 Jun 2009 12:00:36 +0200 From: "DRAGE, Keith (Keith)" To: Dan York , "dispatch@ietf.org" Date: Thu, 4 Jun 2009 12:00:34 +0200 Thread-Topic: [dispatch] [AVT] Proposal to form Internet Wideband Audio Codec WG Thread-Index: Acnkg+tPW7/Qit8kSMO3DzsL4DUqDgAdZA9w Message-ID: References: <00a401c9e388$b25c2350$171469f0$%roni@huawei.com> <4A2541B9.2000805@octasic.com> <00d501c9e39a$dcbbbe50$96333af0$%roni@huawei.com> In-Reply-To: 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.84 Cc: "avt@ietf.org" Subject: Re: [dispatch] [AVT] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 10:00:38 -0000 I would argue that G.711 is implemented, not because anyone can implement i= t, but because everyone else has implemented it. It essentially forms the l= owest common denominator for interoperability. If fancy codec x doesn't wor= k, then assuming you have the bandwidth availabile, G.711 probably will. An= d I suspect it is royalty free not because it was always so, but because an= y IPR that existed has pretty much expired by now. G.711 is also the one codec that is probably the most neutral to transcodin= g. I can do to codec A to G.711 and back to codec A with less impact that w= ith any other intermediate codec. For wideband there probably is not any one codec that has achieved that pos= ition. I don't believe building a better, even royalty free codec, will guarantee = a position in the market place. The world is littered with better solutions= that never made it. You need a market where everyone chooses to implement = it so that you can use that codec without having to go to transcoding. Past= ing IETF on the front cover does not achieve that. I don't really have a problem with people trying to sit down and design a n= ew codec and IETF then publishing it. Without some other selling point howe= ver it just becomes yet another codec competing for market place. As such, = put it somewhere where it does not interfere with other work. Sticking it o= n a separate mailing list, and not letting it compete for valuable IETF fac= e to face slots as a working group is fine. regards Keith =20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Dan York > Sent: Wednesday, June 03, 2009 8:46 PM > To: dispatch@ietf.org > Cc: avt@ietf.org > Subject: Re: [dispatch] [AVT] Proposal to form Internet=20 > Wideband Audio Codec WG >=20 > I've been reading this thread with great interest as for the=20 > past probably 6 years or so I've been saying to anyone who=20 > will listen (and to those who won't ;-) that one factor that=20 > will help "IP > communications/VoIP/UC/whatever-marketing-term-we-want-to-rename-our- > products-to-this-week" to really find wide adoption is to=20 > provide a "rich communication experience" better than what=20 > people are used to now. >=20 > Wideband audio is, to me, a huge part of that. >=20 > However, I completely agree with Henning on this point: >=20 > > On Jun 2, 2009, at 12:15 PM, Henning Schulzrinne wrote: > > > >> However, if we don't do this, we are stuck with the status=20 > quo, which=20 > >> is not all that satisfactory. >=20 >=20 > The status quo is not satisfactory. If you want to add=20 > wideband audio =20 > to your product, you've got an alphabet soup of mutually=20 > incompatible =20 > options with vastly different licensing terms/fees/options=20 > and source =20 > code availability. >=20 > I think we ultimately need a "G.711 for wideband", i.e. a wideband =20 > codec that anyone can implement in any device. I'd argue=20 > that a large =20 > part of the reason we are "stuck" with so many people in VoIP=20 > using G.=20 > 711 is precisely because ANYONE can implement it in basically ANY =20 > device. You can buy a G.711 codec implementation or you can write =20 > your own or find some code on the Internet (google "G.711 source =20 > code"). You can implement G.711 in your big softswitch or=20 > IP-PBX... or =20 > you can implement it in some small embedded device. >=20 > And it interoperates. >=20 > We need that kind of codec for wideband.... which I would say is =20 > "royalty-free" and needs to have "open source" implementations =20 > available. (And yes, I know Speex is out there - I don't=20 > have a view =20 > as to why it is not more widely implemented. And yes, I know=20 > Skype is =20 > giving away SILK royalty-free, but it's not open source.) >=20 > Can the IETF help with this? I don't know... but I think=20 > it's worth a =20 > shot. If there is a group that is passionate about this (and there =20 > seems to be) then lets get the mailing list set up and have=20 > it go the =20 > regular List -> BOF -> Working Group trajectory. >=20 > In the best case perhaps we come out with the codec we=20 > want/need. At =20 > the very worst I think we'd wind up with at least creating some good =20 > discussions and requirements for what we do need. >=20 > My 2 cents, > Dan >=20 > --=20 > Dan York, Director of Conversations > Voxeo Corporation http://www.voxeo.com dyork@voxeo.com > Phone: +1-407-455-5859 Skype: danyork >=20 > Join the Voxeo conversation: > Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com > Twitter: http://twitter.com/voxeo http://twitter.com/danyork > Facebook: http://www.voxeo.com/facebook >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From jbakker@rim.com Thu Jun 4 07:42:43 2009 Return-Path: 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 5D2D33A6DB3 for ; Thu, 4 Jun 2009 07:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 Y5lKNQ1L14ni for ; Thu, 4 Jun 2009 07:42:42 -0700 (PDT) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id 55F563A6E96 for ; Thu, 4 Jun 2009 07:42:42 -0700 (PDT) Received: from mhs04ykf.rim.net (unknown [127.0.0.1]) by mhs04ykf.rim.net (Symantec Brightmail Gateway) with ESMTP id E62C85C5D3 for ; Thu, 4 Jun 2009 10:42:43 -0400 (EDT) X-AuditID: 0a666446-a84acbb000002ec5-e8-4a27dd631c06 Received: from XCH39YKF.rim.net (unknown [10.64.31.40]) by mhs04ykf.rim.net (Symantec Mail Security) with ESMTP id A774D5C59B for ; Thu, 4 Jun 2009 10:42:43 -0400 (EDT) Received: from XCH02DFW.rim.net ([10.150.100.31]) by XCH39YKF.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Jun 2009 10:42:43 -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_01C9E522.B702B54D" Date: Thu, 4 Jun 2009 09:42:36 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comm-div-notification event package update thread-index: AcnlIrNkp2USEqsrSrSH3HrJogqjUA== From: "John-Luc Bakker" To: X-OriginalArrivalTime: 04 Jun 2009 14:42:43.0646 (UTC) FILETIME=[B80FC5E0:01C9E522] X-Tracking: ONC3m79J7f57zp0jFVtWxPxr7v2VYI3kBbb X-Brightmail-Tracker: AAAAAA== Subject: [dispatch] comm-div-notification event package update X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 14:42:43 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9E522.B702B54D Content-Type: text/plain; charset="US-ASCII" content-transfer-encoding: quoted-printable Hi, We have submitted a draft which proposes registration of an event package, based on work ongoing in 3GPP (and TISPAN). (The most likely protocol output is going to be a new event package). The document can also be found in: http://www.ietf.org/proceedings/staging/draft-avasarala-dispatch-comm-di v-notification-00.txt Updates since last version: Changes from draft-avasarala-sipping-comm-div-notification-01 o Changed contact details for co-author Subir Saha o Moved from SIPPING to DISPATCH WG Regards, John-Luc --- John-Luc Bakker Standards Manager Research In Motion BlackBerry: +1 (908) 463 7321 Office: +1 (972) 373-1761 Internal: (820) 63761 E-mail: jbakker@rim.com --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. ------_=_NextPart_001_01C9E522.B702B54D Content-Type: text/html; charset="US-ASCII" content-transfer-encoding: quoted-printable

Hi,

We have submitted a draft which proposes registration of an event package, base= d on work ongoing in 3GPP (and TISPAN).

(The most likely protocol output is going to be a new event package).

The document can also be found in:

= http://www.ietf.org/proceedings/staging/draft-ava= sarala-dispatch-comm-div-notification-00.txt

Updates since last version:

&n=
bsp;  Changes from draft-avasarala-sipping-comm-div-notification-01
 
  =
 o  Changed contact details for co-author Subir Saha<=
/font>
 
  =
 o  Moved from SIPPING to DISPATCH WG

Regards,

John-Luc

 

 

---
John-Luc Bakker
Standards Manager
Research In Motion
BlackBerry: +1 (908) 463 7321
Office: +1 (972) 373-1761
Internal: (820) 63761
E-mail: jbakker@rim.com

 

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. ------_=_NextPart_001_01C9E522.B702B54D-- From pkyzivat@cisco.com Thu Jun 4 08:24:02 2009 Return-Path: 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 D42063A6C7A for ; Thu, 4 Jun 2009 08:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 r6wyNLh1yr9W for ; Thu, 4 Jun 2009 08:24:02 -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 27E753A696A for ; Thu, 4 Jun 2009 08:23:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,306,1241395200"; d="scan'208";a="46210077" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 04 Jun 2009 15:23:34 +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 n54FNYVB020232; Thu, 4 Jun 2009 11:23:34 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n54FNXo9027015; Thu, 4 Jun 2009 15:23:33 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Jun 2009 11:23:33 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jun 2009 11:23:33 -0400 Message-ID: <4A27E6F5.1090707@cisco.com> Date: Thu, 04 Jun 2009 11:23:33 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: John-Luc Bakker References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Jun 2009 15:23:33.0487 (UTC) FILETIME=[6C47D7F0:01C9E528] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3376; t=1244129014; x=1244993014; 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 |Subject:=20Re=3A=20[dispatch]=20comm-div-notification=20ev ent=20package=20update |Sender:=20 |To:=20John-Luc=20Bakker=20; bh=6P4Tgyx9hZGXNCqzPIvcsqZjKI2xgm1ch/lZNduetfY=; b=Q39oq6fhTZheBRHlIMDktgXYowXLtkjuvsV+z46+pSB3m9PMxb7pNfKcbK sUBgxetDDRTJH39BNFJ5mHms3xV0hJOfob/TEgME8hnmtfoMTqN4GK0t9jai mv3YWznMvD; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: dispatch@ietf.org Subject: Re: [dispatch] comm-div-notification event package update X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 15:24:02 -0000 John-Luc, This sounds like a useful capability. Based on a quick scan, this proposal seems off to a good start. For some of us that aren't actively involved with 3gpp, the references to 3gpp documents are somewhat inconvenient. Of particular note, I would like to see the xml schema for application/comm-div-info+xml included in this draft. I'm also a bit confused, because you call for the same doc format to be used in both subscriptions and notifications. That at least seems odd, though perhaps it will become clear when I see the actual schema. Since it will perform a different role in these differing cases, it would be helpful if you could explain more about that. Also I found the references to "user" somewhat ambiguous. I see a definition of Diverting User, and a note that "user" when not qualified should mean Diverting User. But I then also see "user" used in contexts discussing the subscriber. For SUBSCRIBE, the R-URI identifies the "resource" to which a subscription is addressed. I would hope to see a very clear relationship spelled out between the subscription resource and the processing of requests that are "diverted". My assumption is that "diversion" is performed with respect to a particular R-URI in an INVITE request, and that to be notified of such a diversion one would need be subscribed to this event package addressed to the same URI. If that is so, it should be spelled out. And if that isn't quite what you mean then its even more important to spell out what you do mean. Thanks, Paul John-Luc Bakker wrote: > Hi, > > We have submitted a draft which proposes registration of an event > package, based on work ongoing in 3GPP (and TISPAN). > > (The most likely protocol output is going to be a new event package). > > The document can also be found in: > > http://www.ietf.org/proceedings/staging/draft-avasarala-dispatch-comm-div-notification-00.txt > > Updates since last version: > > Changes from draft-avasarala-sipping-comm-div-notification-01 > > > > o Changed contact details for co-author Subir Saha > > > > o Moved from SIPPING to DISPATCH WG > > Regards, > > John-Luc > > > > > > --- > John-Luc Bakker > Standards Manager > Research In Motion > BlackBerry: +1 (908) 463 7321 > Office: +1 (972) 373-1761 > Internal: (820) 63761 > E-mail: jbakker@rim.com > > > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute > non-public information. Any use of this information by anyone other than > the intended recipient is prohibited. If you have received this > transmission in error, please immediately reply to the sender and delete > this information from your system. Use, dissemination, distribution, or > reproduction of this transmission by unintended recipients is not > authorized and may be unlawful. > > > ------------------------------------------------------------------------ > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From mary.barnes@nortel.com Thu Jun 4 13:16:11 2009 Return-Path: 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 C781D3A6951 for ; Thu, 4 Jun 2009 13:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 XgbqXeF5Akj1 for ; Thu, 4 Jun 2009 13:16:10 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 65A6A3A6885 for ; Thu, 4 Jun 2009 13:16:10 -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 n54KG8q02744; Thu, 4 Jun 2009 20:16:08 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: Thu, 4 Jun 2009 15:18:43 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E590C4B@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reminder: IETF-75 plans for DISPATCH Thread-Index: AcnNtXrnlTE+ihrURvGZPoNhaaFPuABmOAxgAC3W45AFJZzbIA== From: "Mary Barnes" To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 20:16:11 -0000 Hi folks, A reminder to folks that submitted proposals for the initial deadline that the "charter proposals" are due next Monday, June 8th. The following summarizes the proposals (some already having detailed charter proposals) that have been put forth: 1) 3rd party auth: http://www.ietf.org/mail-archive/web/dispatch/current/msg00052.html 2) CBUS: http://www.ietf.org/mail-archive/web/dispatch/current/msg00083.html 3) cc-uui: http://www.ietf.org/mail-archive/web/dispatch/current/msg00073.html 4) CLF: http://www.ietf.org/mail-archive/web/dispatch/current/msg00066.html 5) Codec: http://www.ietf.org/mail-archive/web/dispatch/current/msg00080.html 6) Sound level indicator: http://www.ietf.org/mail-archive/web/dispatch/current/msg00071.html 7) On demand media/app sharing: http://www.ietf.org/mail-archive/web/dispatch/current/msg00076.html Also, if there are already drafts associated with your charter proposal, please provide appropriate links in your email.=20 For WG participants, there are less than two weeks left (June 15th) to provide input and feedback on the proposals in terms of whether there is sufficient interest to warrant discussion during a f2f session in Stockholm or whether the items can be dispatched prior to Stockholm.=20 Also, please let me know if I've missed something.=20 Regards, Mary.=20 -----Original Message----- From: Barnes, Mary (RICH2:AR00)=20 Sent: Friday, May 08, 2009 12:54 PM To: dispatch@ietf.org Cc: rai-ads@tools.ietf.org; 'Gonzalo Camarillo' Subject: IETF-75 plans for DISPATCH=20 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 Even.roni@huawei.com Thu Jun 4 14:10:04 2009 Return-Path: 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 E64023A6B06 for ; Thu, 4 Jun 2009 14:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.845 X-Spam-Level: X-Spam-Status: No, score=-0.845 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t+ijbhBWfbzo for ; Thu, 4 Jun 2009 14:10:03 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 8E5833A6A6B for ; Thu, 4 Jun 2009 14:10:03 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KKQ00JGQG4JTT@szxga02-in.huawei.com> for dispatch@ietf.org; Fri, 05 Jun 2009 05:09:55 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KKQ00A1VG4JHD@szxga02-in.huawei.com> for dispatch@ietf.org; Fri, 05 Jun 2009 05:09:55 +0800 (CST) Received: from windows8d787f9 (bzq-79-183-125-11.red.bezeqint.net [79.183.125.11]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KKQ006Y8G4AVO@szxml01-in.huawei.com>; Fri, 05 Jun 2009 05:09:55 +0800 (CST) Date: Fri, 05 Jun 2009 00:08:25 +0300 From: Roni Even In-reply-to: <1ECE0EB50388174790F9694F77522CCF1E590C4B@zrc2hxm0.corp.nortel.com> To: 'Mary Barnes' , dispatch@ietf.org Message-id: <002701c9e558$a153db80$e3fb9280$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcnNtXrnlTE+ihrURvGZPoNhaaFPuABmOAxgAC3W45AFJZzbIAAu1s3g References: <1ECE0EB50388174790F9694F77522CCF1E590C4B@zrc2hxm0.corp.nortel.com> Cc: rai-ads@tools.ietf.org Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 21:10:05 -0000 Hi Mary, Looking at the proposal I would like to point out that the last three items were typically discussed before we had the dispatch group in AVT, XCON or MMUSIC. I think that the people who follow AVT and MMUSIC are not the typical dispatch subscriber and if a meaningful discussion is solicited than those message should have gone also to the AVT and MMUSIC mailing list. I did forward the codec email to the AVT working group and urged people to join the discussion on the codec topic but maybe the dispatch chairs should look at the proposals and send them to current working groups that may provide better feedback Roni Even -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Thursday, June 04, 2009 11:19 PM To: dispatch@ietf.org Cc: rai-ads@tools.ietf.org Subject: [dispatch] Reminder: IETF-75 plans for DISPATCH Hi folks, A reminder to folks that submitted proposals for the initial deadline that the "charter proposals" are due next Monday, June 8th. The following summarizes the proposals (some already having detailed charter proposals) that have been put forth: 1) 3rd party auth: http://www.ietf.org/mail-archive/web/dispatch/current/msg00052.html 2) CBUS: http://www.ietf.org/mail-archive/web/dispatch/current/msg00083.html 3) cc-uui: http://www.ietf.org/mail-archive/web/dispatch/current/msg00073.html 4) CLF: http://www.ietf.org/mail-archive/web/dispatch/current/msg00066.html 5) Codec: http://www.ietf.org/mail-archive/web/dispatch/current/msg00080.html 6) Sound level indicator: http://www.ietf.org/mail-archive/web/dispatch/current/msg00071.html 7) On demand media/app sharing: http://www.ietf.org/mail-archive/web/dispatch/current/msg00076.html Also, if there are already drafts associated with your charter proposal, please provide appropriate links in your email. For WG participants, there are less than two weeks left (June 15th) to provide input and feedback on the proposals in terms of whether there is sufficient interest to warrant discussion during a f2f session in Stockholm or whether the items can be dispatched prior to Stockholm. Also, please let me know if I've missed something. Regards, Mary. -----Original Message----- From: Barnes, Mary (RICH2:AR00) Sent: Friday, May 08, 2009 12:54 PM To: dispatch@ietf.org Cc: rai-ads@tools.ietf.org; 'Gonzalo Camarillo' Subject: 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: 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. We appreciate the patience of the WG as we evolve the model for bringing in new work and welcome feedback. Regards, Mary and Gonzalo DISPATCH WG co-chairs _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From mary.barnes@nortel.com Thu Jun 4 14:39:03 2009 Return-Path: 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 756083A6A37 for ; Thu, 4 Jun 2009 14:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 wAzmZHCY7nh7 for ; Thu, 4 Jun 2009 14:39:02 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 08A253A6C9F for ; Thu, 4 Jun 2009 14:38:37 -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 n54Lcaq22247; Thu, 4 Jun 2009 21:38: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: Thu, 4 Jun 2009 16:41:06 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E590E43@zrc2hxm0.corp.nortel.com> In-Reply-To: <002701c9e558$a153db80$e3fb9280$%roni@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Reminder: IETF-75 plans for DISPATCH Thread-Index: AcnNtXrnlTE+ihrURvGZPoNhaaFPuABmOAxgAC3W45AFJZzbIAAu1s3gAACtu4A= References: <1ECE0EB50388174790F9694F77522CCF1E590C4B@zrc2hxm0.corp.nortel.com> <002701c9e558$a153db80$e3fb9280$%roni@huawei.com> From: "Mary Barnes" To: "Roni Even" , Cc: rai-ads@tools.ietf.org Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 21:39:03 -0000 Hi Roni, I don't disagree that any technical work for the last 3 might fit into the WGs you suggest. However, the point of the discussion is to agree how to proceed with the work - i.e., should it go to WG x or does it warrant a separate WG/BoF or is it something for which there is not sufficient interest that the work should either be progressed as individual or abandoned. I agree that those last 3 categories are beyond the scope (for the most part) of work that we discussed in the SIPPING WG in the past. But, the role of DISPATCH is far broader than SIPPING: http://www.ietf.org/html.charters/dispatch-charter.html " The Dispatch working group is chartered to consider proposals for new work in the RAI area and identify, or help create, an appropriate venue for the work."=20 There is no mention that the proposals must be SIP specific nor is there any restrictions as to what sort of work should be discussed in DISPATCH WG - if it relates to RAI in anyway, then it's appropriate. Also, keep in mind that there may be new mailing lists setup for detailed discussions of some of these topics. So, I don't think it's reasonable to suggest that anything and everything that folks that follow AVT and MMUSIC would be interested in will always be discussed in those WGs. As a WG chair, I think you can do a good job of letting your WG know when relevant topics are being discussed for folks that might not want to be on the DISPATCH WG mailing list. I have approved quite a few posts (and added the folks as being able to post without subscribing to the ML) over the past week to facilitate input from folks that are not subscribed to the DISPATCH ML.=20 My understanding was that one of the reasons for the new structure was to minimize new work having to shop for a WG - i.e., starting in one WG and being told that the work belongs in another WG and then another, etc. There have been cases in the past where potential new work items were shuttled between 3+ different WGs (with no one ever taking ownership) and others presented in multiple WGs during a given IETF meeting. In general, this new approach should avoid both those problems.=20 Now, this isn't to say that all potential new work items MUST first be discussed in DISPATCH - there will be quite clear cases where the appropriate WG is obvious from the outset.=20 And, again, we do appreciate patience as we work through this new model. Regards, Mary. (as DISPATCH WG co-chair) -----Original Message----- From: Roni Even [mailto:Even.roni@huawei.com]=20 Sent: Thursday, June 04, 2009 4:08 PM To: Barnes, Mary (RICH2:AR00); dispatch@ietf.org Cc: rai-ads@tools.ietf.org Subject: RE: [dispatch] Reminder: IETF-75 plans for DISPATCH Hi Mary, Looking at the proposal I would like to point out that the last three items were typically discussed before we had the dispatch group in AVT, XCON or MMUSIC.=20 I think that the people who follow AVT and MMUSIC are not the typical dispatch subscriber and if a meaningful discussion is solicited than those message should have gone also to the AVT and MMUSIC mailing list. I did forward the codec email to the AVT working group and urged people to join the discussion on the codec topic but maybe the dispatch chairs should look at the proposals and send them to current working groups that may provide better feedback Roni Even -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Thursday, June 04, 2009 11:19 PM To: dispatch@ietf.org Cc: rai-ads@tools.ietf.org Subject: [dispatch] Reminder: IETF-75 plans for DISPATCH Hi folks, A reminder to folks that submitted proposals for the initial deadline that the "charter proposals" are due next Monday, June 8th. The following summarizes the proposals (some already having detailed charter proposals) that have been put forth: 1) 3rd party auth: http://www.ietf.org/mail-archive/web/dispatch/current/msg00052.html 2) CBUS: http://www.ietf.org/mail-archive/web/dispatch/current/msg00083.html 3) cc-uui: http://www.ietf.org/mail-archive/web/dispatch/current/msg00073.html 4) CLF: http://www.ietf.org/mail-archive/web/dispatch/current/msg00066.html 5) Codec: http://www.ietf.org/mail-archive/web/dispatch/current/msg00080.html 6) Sound level indicator: http://www.ietf.org/mail-archive/web/dispatch/current/msg00071.html 7) On demand media/app sharing: http://www.ietf.org/mail-archive/web/dispatch/current/msg00076.html Also, if there are already drafts associated with your charter proposal, please provide appropriate links in your email.=20 For WG participants, there are less than two weeks left (June 15th) to provide input and feedback on the proposals in terms of whether there is sufficient interest to warrant discussion during a f2f session in Stockholm or whether the items can be dispatched prior to Stockholm.=20 Also, please let me know if I've missed something.=20 Regards, Mary.=20 -----Original Message----- From: Barnes, Mary (RICH2:AR00) Sent: Friday, May 08, 2009 12:54 PM To: dispatch@ietf.org Cc: rai-ads@tools.ietf.org; 'Gonzalo Camarillo' Subject: IETF-75 plans for DISPATCH=20 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 ron.even.tlv@gmail.com Thu Jun 4 14:36:38 2009 Return-Path: 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 E2FC53A68AF for ; Thu, 4 Jun 2009 14:36:38 -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 JpnWw+0l2Ves for ; Thu, 4 Jun 2009 14:36:37 -0700 (PDT) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id 2D5D73A688C for ; Thu, 4 Jun 2009 14:36:37 -0700 (PDT) Received: by fxm9 with SMTP id 9so138630fxm.37 for ; Thu, 04 Jun 2009 14:36:36 -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=qQDdWRACLp8aezqZMYkJWxsXiVL8gwjxMEeahL3xKDU=; b=NU1gjHrXCwlleibD4BM7mMgkzJUYofQv4d6tFvadQJdIIWt76FCJWcGnbi3CysrnZ4 Yd/0wf1DwPgu1K9wqAhj0AUoiGAMpVhUXs94qrPObc36sDVZ2kN4StLf39Z7YhMsYGc4 gcDXhq0OdCe/9dCJtOsoYYV5vj+8eLLDPM5qc= 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=WbwxFaEjD/OapAbx/grcu8mmklTsH4jTm4TtpaHpzqd/opffc5qOaBMDDKk7YayqND IRjSwsO0Y2GVlFUIeZc1yMN8QBSPFDqUcYTyDjd/wFQVmfPX9Y+6pT6dkD1xDyBiZk7N HIH+XP6TxGwW+fHp1UhPbWPqOcNz91rJLsk2E= Received: by 10.204.97.204 with SMTP id m12mr2440174bkn.22.1244151396448; Thu, 04 Jun 2009 14:36:36 -0700 (PDT) Received: from windows8d787f9 (bzq-79-183-125-11.red.bezeqint.net [79.183.125.11]) by mx.google.com with ESMTPS id 18sm4399894fks.10.2009.06.04.14.36.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 04 Jun 2009 14:36:34 -0700 (PDT) From: "Roni Even" To: "'Emil Ivov'" , References: <4A15D99F.9060100@sip-communicator.org> <4A1D9C2C.8030108@telecomitalia.it> <0D5F89FAC29E2C41B98A6A762007F5D001F17EE4@GBNTHT12009MSX.gb002.siemens.net> <4A1E8B2E.1030906@sip-communicator.org> <0D5F89FAC29E2C41B98A6A762007F5D001F18237@GBNTHT12009MSX.gb002.siemens.net> <4A1EBBAE.4090609@sip-communicator.org> In-Reply-To: <4A1EBBAE.4090609@sip-communicator.org> Date: Fri, 5 Jun 2009 00:35:15 +0300 Message-ID: <4a283e62.12135e0a.12c7.ffffaa0b@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: AcnfsWAGGRhyAoyqSImveOkx3VncMAFqWWQA Content-language: en-us X-Mailman-Approved-At: Thu, 04 Jun 2009 14:39:14 -0700 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 21:36:39 -0000 Emil, I think that John means that what you call loudest speaker is not necessarily a speaker but may represent some noise which is high enough to qualify as one of the N loudest speakers. The conferencing bridge try to address this problem by defining some thresholds for accepting a user to the mix. I also looked at the draft and would like to see a discussion about the current options to receive the active speakers indications. I am not so sure about the benefit of displaying sound level, note that the mixers usually do some normalization on the volume of the mixed streams to enhance the loudest speaker and to have a common level regardless of the source level in order to prevent fluctuation of the voice that may be caused by different microphones, encoders and background noise. Roni Even -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Emil Ivov Sent: Thursday, May 28, 2009 7:29 PM To: dispatch@ietf.org Subject: Re: [dispatch] Yet another problem to dispatch 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 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From mary.barnes@nortel.com Thu Jun 4 14:44:33 2009 Return-Path: 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 986A83A692E for ; Thu, 4 Jun 2009 14:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdLCMH0h2cL3 for ; Thu, 4 Jun 2009 14:44:32 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 1FAE13A67A6 for ; Thu, 4 Jun 2009 14:44:32 -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 n54LiVq23116; Thu, 4 Jun 2009 21:44:31 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: Thu, 4 Jun 2009 16:46:56 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E590E67@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E590E43@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Reminder: IETF-75 plans for DISPATCH Thread-Index: AcnNtXrnlTE+ihrURvGZPoNhaaFPuABmOAxgAC3W45AFJZzbIAAu1s3gAACtu4AAAN+uAA== References: <1ECE0EB50388174790F9694F77522CCF1E590C4B@zrc2hxm0.corp.nortel.com><002701c9e558$a153db80$e3fb9280$%roni@huawei.com> <1ECE0EB50388174790F9694F77522CCF1E590E43@zrc2hxm0.corp.nortel.com> From: "Mary Barnes" To: "Roni Even" , Cc: rai-ads@tools.ietf.org Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 21:44:33 -0000 One last point - for item 6) for example, if you as chair of AVT can gather consensus from your WG that this item is of interest, then we can dispatch the item now (pending AD approval, of course) - i.e., there is no requirement at all that we discuss something at a f2f meeting before we dispatch it. =20 Thanks, Mary.=20 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Barnes, Mary (RICH2:AR00) Sent: Thursday, June 04, 2009 4:41 PM To: Roni Even; dispatch@ietf.org Cc: rai-ads@tools.ietf.org Subject: Re: [dispatch] Reminder: IETF-75 plans for DISPATCH Hi Roni, I don't disagree that any technical work for the last 3 might fit into the WGs you suggest. However, the point of the discussion is to agree how to proceed with the work - i.e., should it go to WG x or does it warrant a separate WG/BoF or is it something for which there is not sufficient interest that the work should either be progressed as individual or abandoned. I agree that those last 3 categories are beyond the scope (for the most part) of work that we discussed in the SIPPING WG in the past. But, the role of DISPATCH is far broader than SIPPING: http://www.ietf.org/html.charters/dispatch-charter.html " The Dispatch working group is chartered to consider proposals for new work in the RAI area and identify, or help create, an appropriate venue for the work."=20 There is no mention that the proposals must be SIP specific nor is there any restrictions as to what sort of work should be discussed in DISPATCH WG - if it relates to RAI in anyway, then it's appropriate. Also, keep in mind that there may be new mailing lists setup for detailed discussions of some of these topics. So, I don't think it's reasonable to suggest that anything and everything that folks that follow AVT and MMUSIC would be interested in will always be discussed in those WGs. As a WG chair, I think you can do a good job of letting your WG know when relevant topics are being discussed for folks that might not want to be on the DISPATCH WG mailing list. I have approved quite a few posts (and added the folks as being able to post without subscribing to the ML) over the past week to facilitate input from folks that are not subscribed to the DISPATCH ML.=20 My understanding was that one of the reasons for the new structure was to minimize new work having to shop for a WG - i.e., starting in one WG and being told that the work belongs in another WG and then another, etc. There have been cases in the past where potential new work items were shuttled between 3+ different WGs (with no one ever taking ownership) and others presented in multiple WGs during a given IETF meeting. In general, this new approach should avoid both those problems.=20 Now, this isn't to say that all potential new work items MUST first be discussed in DISPATCH - there will be quite clear cases where the appropriate WG is obvious from the outset.=20 And, again, we do appreciate patience as we work through this new model. Regards, Mary. (as DISPATCH WG co-chair) -----Original Message----- From: Roni Even [mailto:Even.roni@huawei.com] Sent: Thursday, June 04, 2009 4:08 PM To: Barnes, Mary (RICH2:AR00); dispatch@ietf.org Cc: rai-ads@tools.ietf.org Subject: RE: [dispatch] Reminder: IETF-75 plans for DISPATCH Hi Mary, Looking at the proposal I would like to point out that the last three items were typically discussed before we had the dispatch group in AVT, XCON or MMUSIC.=20 I think that the people who follow AVT and MMUSIC are not the typical dispatch subscriber and if a meaningful discussion is solicited than those message should have gone also to the AVT and MMUSIC mailing list. I did forward the codec email to the AVT working group and urged people to join the discussion on the codec topic but maybe the dispatch chairs should look at the proposals and send them to current working groups that may provide better feedback Roni Even -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Thursday, June 04, 2009 11:19 PM To: dispatch@ietf.org Cc: rai-ads@tools.ietf.org Subject: [dispatch] Reminder: IETF-75 plans for DISPATCH Hi folks, A reminder to folks that submitted proposals for the initial deadline that the "charter proposals" are due next Monday, June 8th. The following summarizes the proposals (some already having detailed charter proposals) that have been put forth: 1) 3rd party auth: http://www.ietf.org/mail-archive/web/dispatch/current/msg00052.html 2) CBUS: http://www.ietf.org/mail-archive/web/dispatch/current/msg00083.html 3) cc-uui: http://www.ietf.org/mail-archive/web/dispatch/current/msg00073.html 4) CLF: http://www.ietf.org/mail-archive/web/dispatch/current/msg00066.html 5) Codec: http://www.ietf.org/mail-archive/web/dispatch/current/msg00080.html 6) Sound level indicator: http://www.ietf.org/mail-archive/web/dispatch/current/msg00071.html 7) On demand media/app sharing: http://www.ietf.org/mail-archive/web/dispatch/current/msg00076.html Also, if there are already drafts associated with your charter proposal, please provide appropriate links in your email.=20 For WG participants, there are less than two weeks left (June 15th) to provide input and feedback on the proposals in terms of whether there is sufficient interest to warrant discussion during a f2f session in Stockholm or whether the items can be dispatched prior to Stockholm.=20 Also, please let me know if I've missed something.=20 Regards, Mary.=20 -----Original Message----- From: Barnes, Mary (RICH2:AR00) Sent: Friday, May 08, 2009 12:54 PM To: dispatch@ietf.org Cc: rai-ads@tools.ietf.org; 'Gonzalo Camarillo' Subject: IETF-75 plans for DISPATCH=20 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 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From Even.roni@huawei.com Thu Jun 4 21:22:59 2009 Return-Path: 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 088253A6AE4 for ; Thu, 4 Jun 2009 21:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[AWL=0.752, 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 XNLe7iMUCzXd for ; Thu, 4 Jun 2009 21:22:57 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 5C9163A6975 for ; Thu, 4 Jun 2009 21:22:57 -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 <0KKR00KC606AYC@szxga03-in.huawei.com> for dispatch@ietf.org; Fri, 05 Jun 2009 12:22:58 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KKR00E6I06A6X@szxga03-in.huawei.com> for dispatch@ietf.org; Fri, 05 Jun 2009 12:22:58 +0800 (CST) Received: from windows8d787f9 (bzq-79-183-125-11.red.bezeqint.net [79.183.125.11]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KKR00L8S0614G@szxml02-in.huawei.com>; Fri, 05 Jun 2009 12:22:58 +0800 (CST) Date: Fri, 05 Jun 2009 07:21:29 +0300 From: Roni Even In-reply-to: <1ECE0EB50388174790F9694F77522CCF1E590E43@zrc2hxm0.corp.nortel.com> To: 'Mary Barnes' , dispatch@ietf.org Message-id: <000f01c9e595$1ed197f0$5c74c7d0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcnNtXrnlTE+ihrURvGZPoNhaaFPuABmOAxgAC3W45AFJZzbIAAu1s3gAACtu4AADoJu0A== References: <1ECE0EB50388174790F9694F77522CCF1E590C4B@zrc2hxm0.corp.nortel.com> <002701c9e558$a153db80$e3fb9280$%roni@huawei.com> <1ECE0EB50388174790F9694F77522CCF1E590E43@zrc2hxm0.corp.nortel.com> Cc: rai-ads@tools.ietf.org Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 04:22:59 -0000 Mary, I was not arguing the dispatch charter. I wanted to point out that since dispatch charter is to start discussion on any RAI new topic it would make sense from the dispatch chairs to forward these new topics to other relevant RAI WGs mailing lists since these lists members may not follow the dispatch list. Roni Even -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com] Sent: Friday, June 05, 2009 12:41 AM To: Roni Even; dispatch@ietf.org Cc: rai-ads@tools.ietf.org Subject: RE: [dispatch] Reminder: IETF-75 plans for DISPATCH Hi Roni, I don't disagree that any technical work for the last 3 might fit into the WGs you suggest. However, the point of the discussion is to agree how to proceed with the work - i.e., should it go to WG x or does it warrant a separate WG/BoF or is it something for which there is not sufficient interest that the work should either be progressed as individual or abandoned. I agree that those last 3 categories are beyond the scope (for the most part) of work that we discussed in the SIPPING WG in the past. But, the role of DISPATCH is far broader than SIPPING: http://www.ietf.org/html.charters/dispatch-charter.html " The Dispatch working group is chartered to consider proposals for new work in the RAI area and identify, or help create, an appropriate venue for the work." There is no mention that the proposals must be SIP specific nor is there any restrictions as to what sort of work should be discussed in DISPATCH WG - if it relates to RAI in anyway, then it's appropriate. Also, keep in mind that there may be new mailing lists setup for detailed discussions of some of these topics. So, I don't think it's reasonable to suggest that anything and everything that folks that follow AVT and MMUSIC would be interested in will always be discussed in those WGs. As a WG chair, I think you can do a good job of letting your WG know when relevant topics are being discussed for folks that might not want to be on the DISPATCH WG mailing list. I have approved quite a few posts (and added the folks as being able to post without subscribing to the ML) over the past week to facilitate input from folks that are not subscribed to the DISPATCH ML. My understanding was that one of the reasons for the new structure was to minimize new work having to shop for a WG - i.e., starting in one WG and being told that the work belongs in another WG and then another, etc. There have been cases in the past where potential new work items were shuttled between 3+ different WGs (with no one ever taking ownership) and others presented in multiple WGs during a given IETF meeting. In general, this new approach should avoid both those problems. Now, this isn't to say that all potential new work items MUST first be discussed in DISPATCH - there will be quite clear cases where the appropriate WG is obvious from the outset. And, again, we do appreciate patience as we work through this new model. Regards, Mary. (as DISPATCH WG co-chair) -----Original Message----- From: Roni Even [mailto:Even.roni@huawei.com] Sent: Thursday, June 04, 2009 4:08 PM To: Barnes, Mary (RICH2:AR00); dispatch@ietf.org Cc: rai-ads@tools.ietf.org Subject: RE: [dispatch] Reminder: IETF-75 plans for DISPATCH Hi Mary, Looking at the proposal I would like to point out that the last three items were typically discussed before we had the dispatch group in AVT, XCON or MMUSIC. I think that the people who follow AVT and MMUSIC are not the typical dispatch subscriber and if a meaningful discussion is solicited than those message should have gone also to the AVT and MMUSIC mailing list. I did forward the codec email to the AVT working group and urged people to join the discussion on the codec topic but maybe the dispatch chairs should look at the proposals and send them to current working groups that may provide better feedback Roni Even -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Thursday, June 04, 2009 11:19 PM To: dispatch@ietf.org Cc: rai-ads@tools.ietf.org Subject: [dispatch] Reminder: IETF-75 plans for DISPATCH Hi folks, A reminder to folks that submitted proposals for the initial deadline that the "charter proposals" are due next Monday, June 8th. The following summarizes the proposals (some already having detailed charter proposals) that have been put forth: 1) 3rd party auth: http://www.ietf.org/mail-archive/web/dispatch/current/msg00052.html 2) CBUS: http://www.ietf.org/mail-archive/web/dispatch/current/msg00083.html 3) cc-uui: http://www.ietf.org/mail-archive/web/dispatch/current/msg00073.html 4) CLF: http://www.ietf.org/mail-archive/web/dispatch/current/msg00066.html 5) Codec: http://www.ietf.org/mail-archive/web/dispatch/current/msg00080.html 6) Sound level indicator: http://www.ietf.org/mail-archive/web/dispatch/current/msg00071.html 7) On demand media/app sharing: http://www.ietf.org/mail-archive/web/dispatch/current/msg00076.html Also, if there are already drafts associated with your charter proposal, please provide appropriate links in your email. For WG participants, there are less than two weeks left (June 15th) to provide input and feedback on the proposals in terms of whether there is sufficient interest to warrant discussion during a f2f session in Stockholm or whether the items can be dispatched prior to Stockholm. Also, please let me know if I've missed something. Regards, Mary. -----Original Message----- From: Barnes, Mary (RICH2:AR00) Sent: Friday, May 08, 2009 12:54 PM To: dispatch@ietf.org Cc: rai-ads@tools.ietf.org; 'Gonzalo Camarillo' Subject: 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: 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. We appreciate the patience of the WG as we evolve the model for bringing in new work and welcome feedback. Regards, Mary and Gonzalo DISPATCH WG co-chairs _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From Even.roni@huawei.com Thu Jun 4 21:31:26 2009 Return-Path: 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 494613A6AE1 for ; Thu, 4 Jun 2009 21:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.941 X-Spam-Level: X-Spam-Status: No, score=-1.941 tagged_above=-999 required=5 tests=[AWL=0.658, 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 VmsDaH0VACn6 for ; Thu, 4 Jun 2009 21:31:24 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 8D1E03A69CB for ; Thu, 4 Jun 2009 21:31:24 -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 <0KKR001KD0KEL9@szxga03-in.huawei.com> for dispatch@ietf.org; Fri, 05 Jun 2009 12:31:26 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KKR00EGR0KE6X@szxga03-in.huawei.com> for dispatch@ietf.org; Fri, 05 Jun 2009 12:31:26 +0800 (CST) Received: from windows8d787f9 (bzq-79-183-125-11.red.bezeqint.net [79.183.125.11]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KKR00H3L0K4XU@szxml01-in.huawei.com>; Fri, 05 Jun 2009 12:31:26 +0800 (CST) Date: Fri, 05 Jun 2009 07:29:56 +0300 From: Roni Even In-reply-to: <1ECE0EB50388174790F9694F77522CCF1E590E67@zrc2hxm0.corp.nortel.com> To: 'Mary Barnes' , dispatch@ietf.org Message-id: <001001c9e596$4d3824f0$e7a86ed0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcnNtXrnlTE+ihrURvGZPoNhaaFPuABmOAxgAC3W45AFJZzbIAAu1s3gAACtu4AAAN+uAAAN3eOA References: <1ECE0EB50388174790F9694F77522CCF1E590C4B@zrc2hxm0.corp.nortel.com> <002701c9e558$a153db80$e3fb9280$%roni@huawei.com> <1ECE0EB50388174790F9694F77522CCF1E590E43@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E590E67@zrc2hxm0.corp.nortel.com> Cc: rai-ads@tools.ietf.org Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 04:31:26 -0000 Mary, On item 6 I am not sure if it is AVT or XCON. One of the problems in this request is the synchronization between the application level user of the conference (the display name) and his media streams. Today this is handled in the conference event package. Having the audio level in the mixed RTP/RTCP stream will not provide enough information to the client to synchronize the SSRC with the name the user is suing in the conference. The CNAME does not supply this relation. I think one of the challenges will be what to discuss in dispatch. I hope that the in the f2f meeting the discussion will be not on the technical solution but more on why it came to dispatch, why did the authors of the draft think that it does not fit the charter of any existing WG. Roni -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com] Sent: Friday, June 05, 2009 12:47 AM To: Roni Even; dispatch@ietf.org Cc: rai-ads@tools.ietf.org Subject: RE: [dispatch] Reminder: IETF-75 plans for DISPATCH One last point - for item 6) for example, if you as chair of AVT can gather consensus from your WG that this item is of interest, then we can dispatch the item now (pending AD approval, of course) - i.e., there is no requirement at all that we discuss something at a f2f meeting before we dispatch it. Thanks, Mary. -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Barnes, Mary (RICH2:AR00) Sent: Thursday, June 04, 2009 4:41 PM To: Roni Even; dispatch@ietf.org Cc: rai-ads@tools.ietf.org Subject: Re: [dispatch] Reminder: IETF-75 plans for DISPATCH Hi Roni, I don't disagree that any technical work for the last 3 might fit into the WGs you suggest. However, the point of the discussion is to agree how to proceed with the work - i.e., should it go to WG x or does it warrant a separate WG/BoF or is it something for which there is not sufficient interest that the work should either be progressed as individual or abandoned. I agree that those last 3 categories are beyond the scope (for the most part) of work that we discussed in the SIPPING WG in the past. But, the role of DISPATCH is far broader than SIPPING: http://www.ietf.org/html.charters/dispatch-charter.html " The Dispatch working group is chartered to consider proposals for new work in the RAI area and identify, or help create, an appropriate venue for the work." There is no mention that the proposals must be SIP specific nor is there any restrictions as to what sort of work should be discussed in DISPATCH WG - if it relates to RAI in anyway, then it's appropriate. Also, keep in mind that there may be new mailing lists setup for detailed discussions of some of these topics. So, I don't think it's reasonable to suggest that anything and everything that folks that follow AVT and MMUSIC would be interested in will always be discussed in those WGs. As a WG chair, I think you can do a good job of letting your WG know when relevant topics are being discussed for folks that might not want to be on the DISPATCH WG mailing list. I have approved quite a few posts (and added the folks as being able to post without subscribing to the ML) over the past week to facilitate input from folks that are not subscribed to the DISPATCH ML. My understanding was that one of the reasons for the new structure was to minimize new work having to shop for a WG - i.e., starting in one WG and being told that the work belongs in another WG and then another, etc. There have been cases in the past where potential new work items were shuttled between 3+ different WGs (with no one ever taking ownership) and others presented in multiple WGs during a given IETF meeting. In general, this new approach should avoid both those problems. Now, this isn't to say that all potential new work items MUST first be discussed in DISPATCH - there will be quite clear cases where the appropriate WG is obvious from the outset. And, again, we do appreciate patience as we work through this new model. Regards, Mary. (as DISPATCH WG co-chair) -----Original Message----- From: Roni Even [mailto:Even.roni@huawei.com] Sent: Thursday, June 04, 2009 4:08 PM To: Barnes, Mary (RICH2:AR00); dispatch@ietf.org Cc: rai-ads@tools.ietf.org Subject: RE: [dispatch] Reminder: IETF-75 plans for DISPATCH Hi Mary, Looking at the proposal I would like to point out that the last three items were typically discussed before we had the dispatch group in AVT, XCON or MMUSIC. I think that the people who follow AVT and MMUSIC are not the typical dispatch subscriber and if a meaningful discussion is solicited than those message should have gone also to the AVT and MMUSIC mailing list. I did forward the codec email to the AVT working group and urged people to join the discussion on the codec topic but maybe the dispatch chairs should look at the proposals and send them to current working groups that may provide better feedback Roni Even -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Thursday, June 04, 2009 11:19 PM To: dispatch@ietf.org Cc: rai-ads@tools.ietf.org Subject: [dispatch] Reminder: IETF-75 plans for DISPATCH Hi folks, A reminder to folks that submitted proposals for the initial deadline that the "charter proposals" are due next Monday, June 8th. The following summarizes the proposals (some already having detailed charter proposals) that have been put forth: 1) 3rd party auth: http://www.ietf.org/mail-archive/web/dispatch/current/msg00052.html 2) CBUS: http://www.ietf.org/mail-archive/web/dispatch/current/msg00083.html 3) cc-uui: http://www.ietf.org/mail-archive/web/dispatch/current/msg00073.html 4) CLF: http://www.ietf.org/mail-archive/web/dispatch/current/msg00066.html 5) Codec: http://www.ietf.org/mail-archive/web/dispatch/current/msg00080.html 6) Sound level indicator: http://www.ietf.org/mail-archive/web/dispatch/current/msg00071.html 7) On demand media/app sharing: http://www.ietf.org/mail-archive/web/dispatch/current/msg00076.html Also, if there are already drafts associated with your charter proposal, please provide appropriate links in your email. For WG participants, there are less than two weeks left (June 15th) to provide input and feedback on the proposals in terms of whether there is sufficient interest to warrant discussion during a f2f session in Stockholm or whether the items can be dispatched prior to Stockholm. Also, please let me know if I've missed something. Regards, Mary. -----Original Message----- From: Barnes, Mary (RICH2:AR00) Sent: Friday, May 08, 2009 12:54 PM To: dispatch@ietf.org Cc: rai-ads@tools.ietf.org; 'Gonzalo Camarillo' Subject: 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: 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. We appreciate the patience of the WG as we evolve the model for bringing in new work and welcome feedback. Regards, Mary and Gonzalo DISPATCH WG co-chairs _______________________________________________ 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 emil@sip-communicator.org Fri Jun 5 02:08:26 2009 Return-Path: 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 1A4BF3A6B9A for ; Fri, 5 Jun 2009 02:08:26 -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 hVe4B0o5ZE-E for ; Fri, 5 Jun 2009 02:08:24 -0700 (PDT) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by core3.amsl.com (Postfix) with ESMTP id D128B3A6B2E for ; Fri, 5 Jun 2009 02:08:23 -0700 (PDT) Received: by bwz9 with SMTP id 9so1335504bwz.37 for ; Fri, 05 Jun 2009 02:08:23 -0700 (PDT) Received: by 10.204.60.72 with SMTP id o8mr2896752bkh.210.1244192903039; Fri, 05 Jun 2009 02:08:23 -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 h2sm12614132fkh.16.2009.06.05.02.08.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 05 Jun 2009 02:08:22 -0700 (PDT) Sender: Emil Ivov Message-ID: <4A28E084.7040603@sip-communicator.org> Date: Fri, 05 Jun 2009 11:08:20 +0200 From: Emil Ivov Organization: SIP Communicator User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Roni Even References: <1ECE0EB50388174790F9694F77522CCF1E590C4B@zrc2hxm0.corp.nortel.com> <002701c9e558$a153db80$e3fb9280$%roni@huawei.com> <1ECE0EB50388174790F9694F77522CCF1E590E43@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E590E67@zrc2hxm0.corp.nortel.com> <001001c9e596$4d3824f0$e7a86ed0$%roni@huawei.com> In-Reply-To: <001001c9e596$4d3824f0$e7a86ed0$%roni@huawei.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org, rai-ads@tools.ietf.org Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 09:08:26 -0000 Hey Roni, Roni Even wrote: > I think one of the challenges will be what to discuss in dispatch. I hope > that the in the f2f meeting the discussion will be not on the technical > solution but more on why it came to dispatch, why did the authors of the > draft think that it does not fit the charter of any existing WG. There's no mystery here, - we simply didn't know exactly where to go with it. We are certainly not proposing a new WG. The solutions we were considering back then involved both XCON and AVT. Dispatch therefore seemed like the right place to go. Now, after some discussion, and the pointers from Ingemar it seems like AVT would be the place to do this. Cheers Emil > > > Roni > > > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: Friday, June 05, 2009 12:47 AM > To: Roni Even; dispatch@ietf.org > Cc: rai-ads@tools.ietf.org > Subject: RE: [dispatch] Reminder: IETF-75 plans for DISPATCH > > One last point - for item 6) for example, if you as chair of AVT can > gather consensus from your WG that this item is of interest, then we can > dispatch the item now (pending AD approval, of course) - i.e., there is > no requirement at all that we discuss something at a f2f meeting before > we dispatch it. > > Thanks, > Mary. > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Barnes, Mary (RICH2:AR00) > Sent: Thursday, June 04, 2009 4:41 PM > To: Roni Even; dispatch@ietf.org > Cc: rai-ads@tools.ietf.org > Subject: Re: [dispatch] Reminder: IETF-75 plans for DISPATCH > > Hi Roni, > > I don't disagree that any technical work for the last 3 might fit into > the WGs you suggest. However, the point of the discussion is to agree > how to proceed with the work - i.e., should it go to WG x or does it > warrant a separate WG/BoF or is it something for which there is not > sufficient interest that the work should either be progressed as > individual or abandoned. I agree that those last 3 categories are > beyond the scope (for the most part) of work that we discussed in the > SIPPING WG in the past. But, the role of DISPATCH is far broader than > SIPPING: http://www.ietf.org/html.charters/dispatch-charter.html > " The Dispatch working group is chartered to consider proposals for new > work in the RAI area and identify, or help create, an appropriate venue > for the work." > > There is no mention that the proposals must be SIP specific nor is there > any restrictions as to what sort of work should be discussed in DISPATCH > WG - if it relates to RAI in anyway, then it's appropriate. Also, keep > in mind that there may be new mailing lists setup for detailed > discussions of some of these topics. So, I don't think it's reasonable > to suggest that anything and everything that folks that follow AVT and > MMUSIC would be interested in will always be discussed in those WGs. As > a WG chair, I think you can do a good job of letting your WG know when > relevant topics are being discussed for folks that might not want to be > on the DISPATCH WG mailing list. I have approved quite a few posts (and > added the folks as being able to post without subscribing to the ML) > over the past week to facilitate input from folks that are not > subscribed to the DISPATCH ML. > > My understanding was that one of the reasons for the new structure was > to minimize new work having to shop for a WG - i.e., starting in one WG > and being told that the work belongs in another WG and then another, > etc. There have been cases in the past where potential new work items > were shuttled between 3+ different WGs (with no one ever taking > ownership) and others presented in multiple WGs during a given IETF > meeting. In general, this new approach should avoid both those > problems. > > Now, this isn't to say that all potential new work items MUST first be > discussed in DISPATCH - there will be quite clear cases where the > appropriate WG is obvious from the outset. > > And, again, we do appreciate patience as we work through this new model. > > > Regards, > Mary. > (as DISPATCH WG co-chair) > > -----Original Message----- > From: Roni Even [mailto:Even.roni@huawei.com] > Sent: Thursday, June 04, 2009 4:08 PM > To: Barnes, Mary (RICH2:AR00); dispatch@ietf.org > Cc: rai-ads@tools.ietf.org > Subject: RE: [dispatch] Reminder: IETF-75 plans for DISPATCH > > Hi Mary, > Looking at the proposal I would like to point out that the last three > items were typically discussed before we had the dispatch group in AVT, > XCON or MMUSIC. > I think that the people who follow AVT and MMUSIC are not the typical > dispatch subscriber and if a meaningful discussion is solicited than > those message should have gone also to the AVT and MMUSIC mailing list. > I did forward the codec email to the AVT working group and urged people > to join the discussion on the codec topic but maybe the dispatch chairs > should look at the proposals and send them to current working groups > that may provide better feedback > > Roni Even > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Mary Barnes > Sent: Thursday, June 04, 2009 11:19 PM > To: dispatch@ietf.org > Cc: rai-ads@tools.ietf.org > Subject: [dispatch] Reminder: IETF-75 plans for DISPATCH > > Hi folks, > > A reminder to folks that submitted proposals for the initial deadline > that the "charter proposals" are due next Monday, June 8th. The > following summarizes the proposals (some already having detailed charter > proposals) that have been put forth: > 1) 3rd party auth: > http://www.ietf.org/mail-archive/web/dispatch/current/msg00052.html > 2) CBUS: > http://www.ietf.org/mail-archive/web/dispatch/current/msg00083.html > 3) cc-uui: > http://www.ietf.org/mail-archive/web/dispatch/current/msg00073.html > 4) CLF: > http://www.ietf.org/mail-archive/web/dispatch/current/msg00066.html > 5) Codec: > http://www.ietf.org/mail-archive/web/dispatch/current/msg00080.html > 6) Sound level indicator: > http://www.ietf.org/mail-archive/web/dispatch/current/msg00071.html > 7) On demand media/app sharing: > http://www.ietf.org/mail-archive/web/dispatch/current/msg00076.html > > Also, if there are already drafts associated with your charter proposal, > please provide appropriate links in your email. > > For WG participants, there are less than two weeks left (June 15th) to > provide input and feedback on the proposals in terms of whether there is > sufficient interest to warrant discussion during a f2f session in > Stockholm or whether the items can be dispatched prior to Stockholm. > > Also, please let me know if I've missed something. > > Regards, > Mary. > > -----Original Message----- > From: Barnes, Mary (RICH2:AR00) > Sent: Friday, May 08, 2009 12:54 PM > To: dispatch@ietf.org > Cc: rai-ads@tools.ietf.org; 'Gonzalo Camarillo' > Subject: 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: > 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. > > We appreciate the patience of the WG as we evolve the model for bringing > in new work and welcome feedback. > > Regards, > Mary and Gonzalo > DISPATCH WG co-chairs > > > _______________________________________________ > 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 > -- Emil Ivov, Ph.D. 30a rue de la Patrie Project Lead 67300 Schiltigheim, France 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 Fri Jun 5 02:10:43 2009 Return-Path: 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 538C73A6BA7 for ; Fri, 5 Jun 2009 02:10: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=[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 1WNd1hafpvdV for ; Fri, 5 Jun 2009 02:10:36 -0700 (PDT) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id 9FDC73A6B9A for ; Fri, 5 Jun 2009 02:10:32 -0700 (PDT) Received: by fxm9 with SMTP id 9so402827fxm.37 for ; Fri, 05 Jun 2009 02:10:31 -0700 (PDT) Received: by 10.204.63.20 with SMTP id z20mr2941177bkh.200.1244193030414; Fri, 05 Jun 2009 02:10:30 -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 c28sm12669100fka.49.2009.06.05.02.10.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 05 Jun 2009 02:10:29 -0700 (PDT) Sender: Emil Ivov Message-ID: <4A28E104.8040108@sip-communicator.org> Date: Fri, 05 Jun 2009 11:10:28 +0200 From: Emil Ivov Organization: SIP Communicator User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Roni Even References: <4A15D99F.9060100@sip-communicator.org> <4A1D9C2C.8030108@telecomitalia.it> <0D5F89FAC29E2C41B98A6A762007F5D001F17EE4@GBNTHT12009MSX.gb002.siemens.net> <4A1E8B2E.1030906@sip-communicator.org> <0D5F89FAC29E2C41B98A6A762007F5D001F18237@GBNTHT12009MSX.gb002.siemens.net> <4A1EBBAE.4090609@sip-communicator.org> <4a283e62.12135e0a.12c7.ffffaa0b@mx.google.com> In-Reply-To: <4a283e62.12135e0a.12c7.ffffaa0b@mx.google.com> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 09:10:43 -0000 Hey Roni, Roni Even wrote: > Emil, > I think that John means that what you call loudest speaker is not > necessarily a speaker but may represent some noise which is high enough to > qualify as one of the N loudest speakers. Indeed, and that's one of the reasons why sound level indicators are so useful. It is far easier for a human to determine what is background noise and what is speech or other activity that is part of the conversation. > The conferencing bridge try to address this problem by defining some > thresholds for accepting a user to the mix. And they can continue doing so. Are you saying that there would be some kind of conflict between these thresholds and the fact that mixers would include sound level information for what they are sending? > I also looked at the draft and would like to see a discussion about the > current options to receive the active speakers indications. I am not so sure > about the benefit of displaying sound level, The problem with active speaker designation comes from its binary nature. Simply picking the one loudest media source (even after normalization) and dubbing it "active speaker" does not always correspond to what's actually happening in a call. Sound level indicators would help identify sources of background noise that got through the filtering on the mixer. > note that the mixers usually do > some normalization on the volume of the mixed streams to enhance the loudest > speaker and to have a common level regardless of the source level in order > to prevent fluctuation of the voice that may be caused by different > microphones, encoders and background noise. I am not sure why this is a problem. After doing all of the above a mixer would simply include sound level information for the data it is about to send (i.e. the normalized streams). Cheers Emil > > Roni Even > > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf > Of Emil Ivov > Sent: Thursday, May 28, 2009 7:29 PM > To: dispatch@ietf.org > Subject: Re: [dispatch] Yet another problem to dispatch > > 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, France 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 ron.even.tlv@gmail.com Fri Jun 5 02:26:42 2009 Return-Path: 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 995F13A6C59 for ; Fri, 5 Jun 2009 02:26:42 -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 AGBq2Wc3KiFo for ; Fri, 5 Jun 2009 02:26:41 -0700 (PDT) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id 56DD43A6C1C for ; Fri, 5 Jun 2009 02:26:40 -0700 (PDT) Received: by fxm9 with SMTP id 9so412968fxm.37 for ; Fri, 05 Jun 2009 02:26:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=NqmVnClywntkHZTQGTl42ZjtSGFOhz4bLrf00VEw9Ro=; b=CBlpbmsDC1YbKLDRlCX3yOcEL2O6s73ZLCE6BaJ8cAnqLlK2+NlFToeN48HFEf+t9y TR0ijoeSsjD+sRAtVdHLIi1k2jPszF0DUaakO9wKeDT8bsuDve94KwiEl1wT06W5YlPq v1VTnSiITdmfYi1B5eTixVV+T3PSDSmUlmHos= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=SYuUYDr5nUwciJE2geKaf4cvyXVrg5UMuENCwUnI34AZVZnwi5nBL8M04fXRej0VFK ymTe6lkbN83AxcKRWCaSzqpLuCUZesxKBt2zvHASFfW6nchiwZGO1UtNj1DVfqC6xluM Z25p6TSDZm3NTKiaOckasyIyQGczNSTMu16qA= Received: by 10.103.108.18 with SMTP id k18mr2070547mum.40.1244194000411; Fri, 05 Jun 2009 02:26:40 -0700 (PDT) Received: from windows8d787f9 (bzq-79-183-125-11.red.bezeqint.net [79.183.125.11]) by mx.google.com with ESMTPS id e8sm9165378muf.6.2009.06.05.02.26.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 05 Jun 2009 02:26:39 -0700 (PDT) From: "Roni Even" To: "'Emil Ivov'" References: <4A15D99F.9060100@sip-communicator.org> <4A1D9C2C.8030108@telecomitalia.it> <0D5F89FAC29E2C41B98A6A762007F5D001F17EE4@GBNTHT12009MSX.gb002.siemens.net> <4A1E8B2E.1030906@sip-communicator.org> <0D5F89FAC29E2C41B98A6A762007F5D001F18237@GBNTHT12009MSX.gb002.siemens.net> <4A1EBBAE.4090609@sip-communicator.org> <4a283e62.12135e0a.12c7.ffffaa0b@mx.google.com> <4A28E104.8040108@sip-communicator.org> In-Reply-To: <4A28E104.8040108@sip-communicator.org> Date: Fri, 5 Jun 2009 12:25:14 +0300 Message-ID: <4a28e4cf.08b6660a.7ebf.ffff91a6@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: AcnlvXmxwmd94nn2TAei7iBu1zH8JwAAbCww Content-Language: en-us 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 09:26:42 -0000 Hi Emil, Inline -----Original Message----- From: Emil Ivov [mailto:emil@sip-communicator.org] On Behalf Of Emil Ivov Sent: Friday, June 05, 2009 12:10 PM To: Roni Even Cc: dispatch@ietf.org Subject: Re: [dispatch] Yet another problem to dispatch Hey Roni, Roni Even wrote: > Emil, > I think that John means that what you call loudest speaker is not > necessarily a speaker but may represent some noise which is high enough to > qualify as one of the N loudest speakers. Indeed, and that's one of the reasons why sound level indicators are so useful. It is far easier for a human to determine what is background noise and what is speech or other activity that is part of the conversation. RE: the information may not be relevant since it just describes the mix, the user gets a mixed content and not the individual streams. > The conferencing bridge try to address this problem by defining some > thresholds for accepting a user to the mix. And they can continue doing so. Are you saying that there would be some kind of conflict between these thresholds and the fact that mixers would include sound level information for what they are sending? RE: I am just saying that in my view it is an interesting information which is useless. > I also looked at the draft and would like to see a discussion about the > current options to receive the active speakers indications. I am not so sure > about the benefit of displaying sound level, The problem with active speaker designation comes from its binary nature. Simply picking the one loudest media source (even after normalization) and dubbing it "active speaker" does not always correspond to what's actually happening in a call. Sound level indicators would help identify sources of background noise that got through the filtering on the mixer. RE: again the stream is already mixed. > note that the mixers usually do > some normalization on the volume of the mixed streams to enhance the loudest > speaker and to have a common level regardless of the source level in order > to prevent fluctuation of the voice that may be caused by different > microphones, encoders and background noise. I am not sure why this is a problem. After doing all of the above a mixer would simply include sound level information for the data it is about to send (i.e. the normalized streams). RE: and what does it help??? Cheers Emil > > Roni Even > > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf > Of Emil Ivov > Sent: Thursday, May 28, 2009 7:29 PM > To: dispatch@ietf.org > Subject: Re: [dispatch] Yet another problem to dispatch > > 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, France 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 enrico.marocco@telecomitalia.it Fri Jun 5 02:30:46 2009 Return-Path: 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 391AA3A6BFB for ; Fri, 5 Jun 2009 02:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[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 qZHXsLDNk1RA for ; Fri, 5 Jun 2009 02:30:45 -0700 (PDT) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by core3.amsl.com (Postfix) with ESMTP id B68673A6C20 for ; Fri, 5 Jun 2009 02:30:44 -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, 5 Jun 2009 11:30:46 +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, 5 Jun 2009 11:30:45 +0200 Message-ID: <4A28E5CB.4070306@telecomitalia.it> Date: Fri, 5 Jun 2009 11:30:51 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Roni Even References: <4A15D99F.9060100@sip-communicator.org> <4A1D9C2C.8030108@telecomitalia.it> <0D5F89FAC29E2C41B98A6A762007F5D001F17EE4@GBNTHT12009MSX.gb002.siemens.net> <4A1E8B2E.1030906@sip-communicator.org> <0D5F89FAC29E2C41B98A6A762007F5D001F18237@GBNTHT12009MSX.gb002.siemens.net> <4A1EBBAE.4090609@sip-communicator.org> <4a283e62.12135e0a.12c7.ffffaa0b@mx.google.com> In-Reply-To: <4a283e62.12135e0a.12c7.ffffaa0b@mx.google.com> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090205010004030907050806" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 09:30:46 -0000 --------------ms090205010004030907050806 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Roni Even wrote: > I also looked at the draft and would like to see a discussion about the > current options to receive the active speakers indications. I am not so sure > about the benefit of displaying sound level There are basically three reasons, apparently we should have done a better job at listing them in the draft: 1. It's cool, Skype does it. This may sound like a stupid reason, but you'll see it's not the case if you try to convince people in a service provider marketing dept. to plan an investment for a service that will have less features and a worse UI than what users can get for free on the Internet. 2. It is very useful in conferences with a fairly high number of participants to debug sources of background noise, like people typing or breathing loudly in the mic. 3. It is useful in multiparty conversations where participant know each other only by name and cannot distinguish individual voices. -- Ciao, Enrico --------------ms090205010004030907050806 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA2MDUwOTMwNTFaMCMG CSqGSIb3DQEJBDEWBBRwTnxIuFNZdJiYl8DoHLjA7q3eizBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBCBGJozGQV91LNU4f6TIyWMIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhBCBGJozGQV91LNU4f6TIyWMA0GCSqGSIb3DQEBAQUABIIBACApZQPRumB7 /Aw1F/YjRSEHK0Ea3SF77xwKnrYsmNRChBuGu66YwN74ky2A/1tRUisNPjAZoxBMrfsNckJA vCjQu8CVsKbBhYX7rHKwQwIX5BLdHAT2pu+CXgZ/CW+cQhbyY9qfdiCxfVMnyNSE9YkREuhQ 7pmY3ePyaAjkWLtunRQjuwHg4riLgwC5MHKaWdBvUMkkmH/uaiLJ8qQBO7mF9ztBBRx/NLBO FdIsCryjQuU+4zm9JeCGN3PtnaeYTudyKnfYI3BMebd7hvgOBGhDaGmxuoYdd0BQz9pv3fbt P+SMx4m0hsse29CSBtPEFLuk6V6XwZUpeTaP4x9MaKsAAAAAAAA= --------------ms090205010004030907050806-- From enrico.marocco@telecomitalia.it Fri Jun 5 02:44:02 2009 Return-Path: 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 6F55A3A6B18 for ; Fri, 5 Jun 2009 02:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 ZGzz2wJME8Ae for ; Fri, 5 Jun 2009 02:44:01 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by core3.amsl.com (Postfix) with ESMTP id AE9133A6BFB for ; Fri, 5 Jun 2009 02:43:43 -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; Fri, 5 Jun 2009 11:43:42 +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, 5 Jun 2009 11:43:42 +0200 Message-ID: <4A28E8D4.6060301@telecomitalia.it> Date: Fri, 5 Jun 2009 11:43:48 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Roni Even References: <4A15D99F.9060100@sip-communicator.org> <4A1D9C2C.8030108@telecomitalia.it> <0D5F89FAC29E2C41B98A6A762007F5D001F17EE4@GBNTHT12009MSX.gb002.siemens.net> <4A1E8B2E.1030906@sip-communicator.org> <0D5F89FAC29E2C41B98A6A762007F5D001F18237@GBNTHT12009MSX.gb002.siemens.net> <4A1EBBAE.4090609@sip-communicator.org> <4a283e62.12135e0a.12c7.ffffaa0b@mx.google.com> <4A28E104.8040108@sip-communicator.org> <4a28e4cf.08b6660a.7ebf.ffff91a6@mx.google.com> In-Reply-To: <4a28e4cf.08b6660a.7ebf.ffff91a6@mx.google.com> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000909090902080902000901" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 09:44:02 -0000 --------------ms000909090902080902000901 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Roni Even wrote: > Indeed, and that's one of the reasons why sound level indicators are so > useful. It is far easier for a human to determine what is background > noise and what is speech or other activity that is part of the conversation. > > RE: the information may not be relevant since it just describes the mix, the > user gets a mixed content and not the individual streams. Uh? The information will represent the sound level of each individual participant. If the streams are normalized by the mixer, the sound level values will be normalized as well: the mixer can do that easily and the resulting information will be consistent with the mixed stream. >> The conferencing bridge try to address this problem by defining some >> thresholds for accepting a user to the mix. > > And they can continue doing so. Are you saying that there would be some > kind of conflict between these thresholds and the fact that mixers would > include sound level information for what they are sending? > > RE: I am just saying that in my view it is an interesting information which > is useless. Useless because you don't think displaying the sound levels of the voices you hear in a multiparty conference has any value for the user, or useless because you think a mixer can't do that reliably? > The problem with active speaker designation comes from its binary > nature. Simply picking the one loudest media source (even after > normalization) and dubbing it "active speaker" does not always > correspond to what's actually happening in a call. Sound level > indicators would help identify sources of background noise that got > through the filtering on the mixer. > > RE: again the stream is already mixed. Probably you use mixers way better than mine, but in my conferences I keep hearing people typing and breathing all the time ;-) -- Ciao, Enrico --------------ms000909090902080902000901 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA2MDUwOTQzNDhaMCMG CSqGSIb3DQEJBDEWBBQgGHOb1br9He9ukDwao11Q1E1ixTBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBCBGJozGQV91LNU4f6TIyWMIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhBCBGJozGQV91LNU4f6TIyWMA0GCSqGSIb3DQEBAQUABIIBAJGc1b1SiEmK Gle+rrnYMrIqneehD1bnb1FMWgLB0WSK/frYF6MJfxns1pVmsGTn1kP8r2A6V1f+qR48nNN6 u1Z3xmhWW4AsIBDtKcp4BKaMOuKsEKPYAa6NAiO6ofdb+VnjOLvOpBGy6QSZVW8LhoFniyF7 dRG8wbzjLMenvbA8udNtisSGtODz92SWakS6jP/+ndF6N2sg9tNEGoN7jDAm5vIXFLKpJCVP 9Jpwc8n36RFZI4LJNf4CLyhweP5H828kNVlLEFAXiAUQ3UsvaWDsAfUlJ0wPcy/geSMhCKaa RADnMyej5Nr/oOOyq+PGNAAAb7cOZRsY72uGLcILR9QAAAAAAAA= --------------ms000909090902080902000901-- From ron.even.tlv@gmail.com Fri Jun 5 06:22:10 2009 Return-Path: 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 ECB4A3A6CF6 for ; Fri, 5 Jun 2009 06:22: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=[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 3A0E6Rm5wRHG for ; Fri, 5 Jun 2009 06:22:10 -0700 (PDT) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by core3.amsl.com (Postfix) with ESMTP id 90B253A69D7 for ; Fri, 5 Jun 2009 06:22:09 -0700 (PDT) Received: by bwz9 with SMTP id 9so1488449bwz.37 for ; Fri, 05 Jun 2009 06:22:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=Fo2RQlLw/XEaEv+qZzYyW0qqn7T3ZKTW5BckKsjgtPI=; b=VRfQcU0Lq7ZLLfWqHEmMz4pVsiYFPAtYFquV+ir7NmalX3yi/TB2uLvbsdbQkzTt/T mwSBG1CAshUFUUHwW3KPklXyn/Cj7dEDhstmXxQJYEX1N1g1A5CVQ9+QgVF4PjY+NS/9 WamOc1ZnCUxlzOysJ85n8yIlMoOn/XEN49gGk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=VOq1Kw4TRCTtyogw2QalgM/Lkd4TjqnzDeNNql5Z/vAN0rTKyT7iUfSDs2ISDgh+KS 3iT174oqWUlupiMnwiBRHVLsUienUiPLww473n/JPQJa49oVHjB9IamvtP+kfO5uEmzm NUYpi4+9i1Ua9T4zmyVMVLoE5tbjyXYeK77uo= Received: by 10.204.124.7 with SMTP id s7mr3099978bkr.189.1244208129719; Fri, 05 Jun 2009 06:22:09 -0700 (PDT) Received: from windows8d787f9 (bzq-79-183-125-11.red.bezeqint.net [79.183.125.11]) by mx.google.com with ESMTPS id 18sm5046296fks.40.2009.06.05.06.22.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 05 Jun 2009 06:22:09 -0700 (PDT) From: "Roni Even" To: "'Enrico Marocco'" References: <4A15D99F.9060100@sip-communicator.org> <4A1D9C2C.8030108@telecomitalia.it> <0D5F89FAC29E2C41B98A6A762007F5D001F17EE4@GBNTHT12009MSX.gb002.siemens.net> <4A1E8B2E.1030906@sip-communicator.org> <0D5F89FAC29E2C41B98A6A762007F5D001F18237@GBNTHT12009MSX.gb002.siemens.net> <4A1EBBAE.4090609@sip-communicator.org> <4a283e62.12135e0a.12c7.ffffaa0b@mx.google.com> <4A28E5CB.4070306@telecomitalia.it> In-Reply-To: <4A28E5CB.4070306@telecomitalia.it> Date: Fri, 5 Jun 2009 16:19:25 +0300 Message-ID: <4a291c01.12135e0a.14a0.6525@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: AcnlwE3jiasnfNmpR0OxMytHN/MncAAHoR+w Content-Language: en-us 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 13:22:11 -0000 Enrico, Skype also supports starting a multipoint audio conference from the UI. I would consider this more practical than showing the sound level. XCON defined this functionality in a standard draft enabling the creation of audio and video conferences in an multivendor environment. Does your client support this functionality. Do you see this as a mandatory requirement from service providers. My concern is that we develop solutions that are not deployed since they have no high priority for developers and customers. Doing a "cool" solution in a proprietary environment is simpler since you control the clients as well as the servers and do not worry about interoperability with other vendors. Roni Even -----Original Message----- From: Enrico Marocco [mailto:enrico.marocco@telecomitalia.it] Sent: Friday, June 05, 2009 12:31 PM To: Roni Even Cc: 'Emil Ivov'; dispatch@ietf.org Subject: Re: [dispatch] Yet another problem to dispatch Roni Even wrote: > I also looked at the draft and would like to see a discussion about the > current options to receive the active speakers indications. I am not so sure > about the benefit of displaying sound level There are basically three reasons, apparently we should have done a better job at listing them in the draft: 1. It's cool, Skype does it. This may sound like a stupid reason, but you'll see it's not the case if you try to convince people in a service provider marketing dept. to plan an investment for a service that will have less features and a worse UI than what users can get for free on the Internet. 2. It is very useful in conferences with a fairly high number of participants to debug sources of background noise, like people typing or breathing loudly in the mic. 3. It is useful in multiparty conversations where participant know each other only by name and cannot distinguish individual voices. -- Ciao, Enrico From emil@sip-communicator.org Fri Jun 5 06:39:42 2009 Return-Path: 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 991D33A6C62 for ; Fri, 5 Jun 2009 06:39:42 -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 ol8+zTHVRCRD for ; Fri, 5 Jun 2009 06:39:41 -0700 (PDT) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by core3.amsl.com (Postfix) with ESMTP id F1E333A682B for ; Fri, 5 Jun 2009 06:39:40 -0700 (PDT) Received: by bwz9 with SMTP id 9so1500504bwz.37 for ; Fri, 05 Jun 2009 06:39:41 -0700 (PDT) Received: by 10.103.214.8 with SMTP id r8mr2221933muq.12.1244209180850; Fri, 05 Jun 2009 06:39:40 -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 e8sm10030616muf.6.2009.06.05.06.39.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 05 Jun 2009 06:39:40 -0700 (PDT) Sender: Emil Ivov Message-ID: <4A29201A.90502@sip-communicator.org> Date: Fri, 05 Jun 2009 15:39:38 +0200 From: Emil Ivov Organization: SIP Communicator User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Roni Even References: <4A15D99F.9060100@sip-communicator.org> <4A1D9C2C.8030108@telecomitalia.it> <0D5F89FAC29E2C41B98A6A762007F5D001F17EE4@GBNTHT12009MSX.gb002.siemens.net> <4A1E8B2E.1030906@sip-communicator.org> <0D5F89FAC29E2C41B98A6A762007F5D001F18237@GBNTHT12009MSX.gb002.siemens.net> <4A1EBBAE.4090609@sip-communicator.org> <4a283e62.12135e0a.12c7.ffffaa0b@mx.google.com> <4A28E5CB.4070306@telecomitalia.it> <4a291c01.12135e0a.14a0.6525@mx.google.com> In-Reply-To: <4a291c01.12135e0a.14a0.6525@mx.google.com> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 13:39:42 -0000 Roni, Roni Even wrote: > Enrico, > > Skype also supports starting a multipoint audio conference from the UI. I > would consider this more practical than showing the sound level. XCON > defined this functionality in a standard draft enabling the creation of > audio and video conferences in an multivendor environment. Does your client > support this functionality. I believe I already mentioned this in the beginning of this thread but probably not clearly enough: this whole work has started because of the ongoing effort in the SIP Communicator community to implement support for conferences established and (in some cases) hosted by the SIP Communicator client. > Do you see this as a mandatory requirement from service providers. I guess Enrico would better answer this one but I can certainly imagine how this would become a trendy feature. > My concern is that we develop solutions that are not deployed since they > have no high priority for developers and customers. Doing a "cool" solution > in a proprietary environment is simpler since you control the clients as > well as the servers and do not worry about interoperability with other > vendors. Well you can relax then. This is of very high priority to us ( a non proprietary open source client with a significant community ) and it is certainly not a mere whim for a coolish featury. We are also very concerned about interoperability which is why we have started this whole discussion. Emil > Roni Even > > -----Original Message----- > From: Enrico Marocco [mailto:enrico.marocco@telecomitalia.it] > Sent: Friday, June 05, 2009 12:31 PM > To: Roni Even > Cc: 'Emil Ivov'; dispatch@ietf.org > Subject: Re: [dispatch] Yet another problem to dispatch > > Roni Even wrote: >> I also looked at the draft and would like to see a discussion about the >> current options to receive the active speakers indications. I am not so > sure >> about the benefit of displaying sound level > > There are basically three reasons, apparently we should have done a > better job at listing them in the draft: > > 1. It's cool, Skype does it. This may sound like a stupid reason, but > you'll see it's not the case if you try to convince people in a service > provider marketing dept. to plan an investment for a service that will > have less features and a worse UI than what users can get for free on > the Internet. > > 2. It is very useful in conferences with a fairly high number of > participants to debug sources of background noise, like people typing or > breathing loudly in the mic. > > 3. It is useful in multiparty conversations where participant know each > other only by name and cannot distinguish individual voices. > -- Emil Ivov, Ph.D. 30a rue de la Patrie Project Lead 67300 Schiltigheim, France 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 vkg@alcatel-lucent.com Fri Jun 5 07:13:05 2009 Return-Path: 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 439563A67F8 for ; Fri, 5 Jun 2009 07:13:05 -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 A5As6zj7FpKZ for ; Fri, 5 Jun 2009 07:13:04 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 029E83A6932 for ; Fri, 5 Jun 2009 07:13:03 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id n55ED2S1000051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 5 Jun 2009 09:13:02 -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 n55ED2lB019782 for ; Fri, 5 Jun 2009 09:13:02 -0500 (CDT) Message-ID: <4A2927EE.4010505@alcatel-lucent.com> Date: Fri, 05 Jun 2009 09:13:02 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: dispatch@ietf.org References: <1ECE0EB50388174790F9694F77522CCF1E590C4B@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E590C4B@zrc2hxm0.corp.nortel.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.39 Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 14:13:05 -0000 Mary Barnes wrote: > Hi folks, > > A reminder to folks that submitted proposals for the initial deadline > that the "charter proposals" are due next Monday, June 8th. [...] Folks: Here is the final "charter proposal" for the SIP CLF work. I received a couple of comments privately on typos and such, but most of the matter is the same as the one distributed on May 15th. Unless anyone has any objections, I will submit this to the dispatch list as per Mary's instructions above on or before Monday, June 8. 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 to tool writers for crafting tools that mine the log files to produce reports and trends. These log files also enable searches 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} Web: http://ect.bell-labs.com/who/vkg/ From mary.barnes@nortel.com Fri Jun 5 07:26:31 2009 Return-Path: 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 3DB8D3A6CF6 for ; Fri, 5 Jun 2009 07:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTwUfV6ynHPE for ; Fri, 5 Jun 2009 07:26:28 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 8835D3A6872 for ; Fri, 5 Jun 2009 07:26:28 -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 n55EPAd20443; Fri, 5 Jun 2009 14:25:10 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, 5 Jun 2009 09:28:27 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E5E3AE3@zrc2hxm0.corp.nortel.com> In-Reply-To: <001001c9e596$4d3824f0$e7a86ed0$%roni@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Reminder: IETF-75 plans for DISPATCH Thread-Index: AcnNtXrnlTE+ihrURvGZPoNhaaFPuABmOAxgAC3W45AFJZzbIAAu1s3gAACtu4AAAN+uAAAN3eOAABUXjoA= References: <1ECE0EB50388174790F9694F77522CCF1E590C4B@zrc2hxm0.corp.nortel.com> <002701c9e558$a153db80$e3fb9280$%roni@huawei.com> <1ECE0EB50388174790F9694F77522CCF1E590E43@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E590E67@zrc2hxm0.corp.nortel.com> <001001c9e596$4d3824f0$e7a86ed0$%roni@huawei.com> From: "Mary Barnes" To: "Roni Even" , Cc: rai-ads@tools.ietf.org Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 14:26:31 -0000 Yes, the f2f meeting should focus on the more general problem and not the specifics of a technical solution - that's the reason we're asking for input in the form of charters and proposed deliverables.=20 Your first comment is excellent feedback for and something that should be considered by the folks working on that problem.=20 Thanks, Mary. -----Original Message----- From: Roni Even [mailto:Even.roni@huawei.com]=20 Sent: Thursday, June 04, 2009 11:30 PM To: Barnes, Mary (RICH2:AR00); dispatch@ietf.org Cc: rai-ads@tools.ietf.org Subject: RE: [dispatch] Reminder: IETF-75 plans for DISPATCH Mary, On item 6 I am not sure if it is AVT or XCON. One of the problems in this request is the synchronization between the application level user of the conference (the display name) and his media streams. Today this is handled in the conference event package.=20 Having the audio level in the mixed RTP/RTCP stream will not provide enough information to the client to synchronize the SSRC with the name the user is suing in the conference. The CNAME does not supply this relation.=20 I think one of the challenges will be what to discuss in dispatch. I hope that the in the f2f meeting the discussion will be not on the technical solution but more on why it came to dispatch, why did the authors of the draft think that it does not fit the charter of any existing WG. Roni -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com] Sent: Friday, June 05, 2009 12:47 AM To: Roni Even; dispatch@ietf.org Cc: rai-ads@tools.ietf.org Subject: RE: [dispatch] Reminder: IETF-75 plans for DISPATCH One last point - for item 6) for example, if you as chair of AVT can gather consensus from your WG that this item is of interest, then we can dispatch the item now (pending AD approval, of course) - i.e., there is no requirement at all that we discuss something at a f2f meeting before we dispatch it. =20 Thanks, Mary.=20 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Barnes, Mary (RICH2:AR00) Sent: Thursday, June 04, 2009 4:41 PM To: Roni Even; dispatch@ietf.org Cc: rai-ads@tools.ietf.org Subject: Re: [dispatch] Reminder: IETF-75 plans for DISPATCH Hi Roni, I don't disagree that any technical work for the last 3 might fit into the WGs you suggest. However, the point of the discussion is to agree how to proceed with the work - i.e., should it go to WG x or does it warrant a separate WG/BoF or is it something for which there is not sufficient interest that the work should either be progressed as individual or abandoned. I agree that those last 3 categories are beyond the scope (for the most part) of work that we discussed in the SIPPING WG in the past. But, the role of DISPATCH is far broader than SIPPING: http://www.ietf.org/html.charters/dispatch-charter.html " The Dispatch working group is chartered to consider proposals for new work in the RAI area and identify, or help create, an appropriate venue for the work."=20 There is no mention that the proposals must be SIP specific nor is there any restrictions as to what sort of work should be discussed in DISPATCH WG - if it relates to RAI in anyway, then it's appropriate. Also, keep in mind that there may be new mailing lists setup for detailed discussions of some of these topics. So, I don't think it's reasonable to suggest that anything and everything that folks that follow AVT and MMUSIC would be interested in will always be discussed in those WGs. As a WG chair, I think you can do a good job of letting your WG know when relevant topics are being discussed for folks that might not want to be on the DISPATCH WG mailing list. I have approved quite a few posts (and added the folks as being able to post without subscribing to the ML) over the past week to facilitate input from folks that are not subscribed to the DISPATCH ML.=20 My understanding was that one of the reasons for the new structure was to minimize new work having to shop for a WG - i.e., starting in one WG and being told that the work belongs in another WG and then another, etc. There have been cases in the past where potential new work items were shuttled between 3+ different WGs (with no one ever taking ownership) and others presented in multiple WGs during a given IETF meeting. In general, this new approach should avoid both those problems.=20 Now, this isn't to say that all potential new work items MUST first be discussed in DISPATCH - there will be quite clear cases where the appropriate WG is obvious from the outset.=20 And, again, we do appreciate patience as we work through this new model. Regards, Mary. (as DISPATCH WG co-chair) -----Original Message----- From: Roni Even [mailto:Even.roni@huawei.com] Sent: Thursday, June 04, 2009 4:08 PM To: Barnes, Mary (RICH2:AR00); dispatch@ietf.org Cc: rai-ads@tools.ietf.org Subject: RE: [dispatch] Reminder: IETF-75 plans for DISPATCH Hi Mary, Looking at the proposal I would like to point out that the last three items were typically discussed before we had the dispatch group in AVT, XCON or MMUSIC.=20 I think that the people who follow AVT and MMUSIC are not the typical dispatch subscriber and if a meaningful discussion is solicited than those message should have gone also to the AVT and MMUSIC mailing list. I did forward the codec email to the AVT working group and urged people to join the discussion on the codec topic but maybe the dispatch chairs should look at the proposals and send them to current working groups that may provide better feedback Roni Even -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Thursday, June 04, 2009 11:19 PM To: dispatch@ietf.org Cc: rai-ads@tools.ietf.org Subject: [dispatch] Reminder: IETF-75 plans for DISPATCH Hi folks, A reminder to folks that submitted proposals for the initial deadline that the "charter proposals" are due next Monday, June 8th. The following summarizes the proposals (some already having detailed charter proposals) that have been put forth: 1) 3rd party auth: http://www.ietf.org/mail-archive/web/dispatch/current/msg00052.html 2) CBUS: http://www.ietf.org/mail-archive/web/dispatch/current/msg00083.html 3) cc-uui: http://www.ietf.org/mail-archive/web/dispatch/current/msg00073.html 4) CLF: http://www.ietf.org/mail-archive/web/dispatch/current/msg00066.html 5) Codec: http://www.ietf.org/mail-archive/web/dispatch/current/msg00080.html 6) Sound level indicator: http://www.ietf.org/mail-archive/web/dispatch/current/msg00071.html 7) On demand media/app sharing: http://www.ietf.org/mail-archive/web/dispatch/current/msg00076.html Also, if there are already drafts associated with your charter proposal, please provide appropriate links in your email.=20 For WG participants, there are less than two weeks left (June 15th) to provide input and feedback on the proposals in terms of whether there is sufficient interest to warrant discussion during a f2f session in Stockholm or whether the items can be dispatched prior to Stockholm.=20 Also, please let me know if I've missed something.=20 Regards, Mary.=20 -----Original Message----- From: Barnes, Mary (RICH2:AR00) Sent: Friday, May 08, 2009 12:54 PM To: dispatch@ietf.org Cc: rai-ads@tools.ietf.org; 'Gonzalo Camarillo' Subject: IETF-75 plans for DISPATCH=20 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 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From mary.barnes@nortel.com Fri Jun 5 07:29:04 2009 Return-Path: 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 26F093A6BB9 for ; Fri, 5 Jun 2009 07:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 0MkL3A6bl9BH for ; Fri, 5 Jun 2009 07:29:02 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 087833A6B67 for ; Fri, 5 Jun 2009 07:28:58 -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 n55ERhd20738; Fri, 5 Jun 2009 14:27:43 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, 5 Jun 2009 09:30:46 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E5E3AF3@zrc2hxm0.corp.nortel.com> In-Reply-To: <000f01c9e595$1ed197f0$5c74c7d0$%roni@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Reminder: IETF-75 plans for DISPATCH Thread-Index: AcnNtXrnlTE+ihrURvGZPoNhaaFPuABmOAxgAC3W45AFJZzbIAAu1s3gAACtu4AADoJu0AAVaPsg References: <1ECE0EB50388174790F9694F77522CCF1E590C4B@zrc2hxm0.corp.nortel.com> <002701c9e558$a153db80$e3fb9280$%roni@huawei.com> <1ECE0EB50388174790F9694F77522CCF1E590E43@zrc2hxm0.corp.nortel.com> <000f01c9e595$1ed197f0$5c74c7d0$%roni@huawei.com> From: "Mary Barnes" To: "Roni Even" , Cc: rai-ads@tools.ietf.org Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 14:29:04 -0000 Roni, I like the distributed model whereby the chairs of the specific working group decide if the topic is of enough interest to alert their WG. This also removes the DISPATCH WG chairs from implying, for example, that a particular work item should be bucketed in a specific working group before we've had enough discussion. =20 Thanks for the feedback. Mary.=20 -----Original Message----- From: Roni Even [mailto:Even.roni@huawei.com]=20 Sent: Thursday, June 04, 2009 11:21 PM To: Barnes, Mary (RICH2:AR00); dispatch@ietf.org Cc: rai-ads@tools.ietf.org Subject: RE: [dispatch] Reminder: IETF-75 plans for DISPATCH Mary, I was not arguing the dispatch charter. I wanted to point out that since dispatch charter is to start discussion on any RAI new topic it would make sense from the dispatch chairs to forward these new topics to other relevant RAI WGs mailing lists since these lists members may not follow the dispatch list. Roni Even -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com] Sent: Friday, June 05, 2009 12:41 AM To: Roni Even; dispatch@ietf.org Cc: rai-ads@tools.ietf.org Subject: RE: [dispatch] Reminder: IETF-75 plans for DISPATCH Hi Roni, I don't disagree that any technical work for the last 3 might fit into the WGs you suggest. However, the point of the discussion is to agree how to proceed with the work - i.e., should it go to WG x or does it warrant a separate WG/BoF or is it something for which there is not sufficient interest that the work should either be progressed as individual or abandoned. I agree that those last 3 categories are beyond the scope (for the most part) of work that we discussed in the SIPPING WG in the past. But, the role of DISPATCH is far broader than SIPPING: http://www.ietf.org/html.charters/dispatch-charter.html " The Dispatch working group is chartered to consider proposals for new work in the RAI area and identify, or help create, an appropriate venue for the work."=20 There is no mention that the proposals must be SIP specific nor is there any restrictions as to what sort of work should be discussed in DISPATCH WG - if it relates to RAI in anyway, then it's appropriate. Also, keep in mind that there may be new mailing lists setup for detailed discussions of some of these topics. So, I don't think it's reasonable to suggest that anything and everything that folks that follow AVT and MMUSIC would be interested in will always be discussed in those WGs. As a WG chair, I think you can do a good job of letting your WG know when relevant topics are being discussed for folks that might not want to be on the DISPATCH WG mailing list. I have approved quite a few posts (and added the folks as being able to post without subscribing to the ML) over the past week to facilitate input from folks that are not subscribed to the DISPATCH ML.=20 My understanding was that one of the reasons for the new structure was to minimize new work having to shop for a WG - i.e., starting in one WG and being told that the work belongs in another WG and then another, etc. There have been cases in the past where potential new work items were shuttled between 3+ different WGs (with no one ever taking ownership) and others presented in multiple WGs during a given IETF meeting. In general, this new approach should avoid both those problems.=20 Now, this isn't to say that all potential new work items MUST first be discussed in DISPATCH - there will be quite clear cases where the appropriate WG is obvious from the outset.=20 And, again, we do appreciate patience as we work through this new model. Regards, Mary. (as DISPATCH WG co-chair) -----Original Message----- From: Roni Even [mailto:Even.roni@huawei.com] Sent: Thursday, June 04, 2009 4:08 PM To: Barnes, Mary (RICH2:AR00); dispatch@ietf.org Cc: rai-ads@tools.ietf.org Subject: RE: [dispatch] Reminder: IETF-75 plans for DISPATCH Hi Mary, Looking at the proposal I would like to point out that the last three items were typically discussed before we had the dispatch group in AVT, XCON or MMUSIC.=20 I think that the people who follow AVT and MMUSIC are not the typical dispatch subscriber and if a meaningful discussion is solicited than those message should have gone also to the AVT and MMUSIC mailing list. I did forward the codec email to the AVT working group and urged people to join the discussion on the codec topic but maybe the dispatch chairs should look at the proposals and send them to current working groups that may provide better feedback Roni Even -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Thursday, June 04, 2009 11:19 PM To: dispatch@ietf.org Cc: rai-ads@tools.ietf.org Subject: [dispatch] Reminder: IETF-75 plans for DISPATCH Hi folks, A reminder to folks that submitted proposals for the initial deadline that the "charter proposals" are due next Monday, June 8th. The following summarizes the proposals (some already having detailed charter proposals) that have been put forth: 1) 3rd party auth: http://www.ietf.org/mail-archive/web/dispatch/current/msg00052.html 2) CBUS: http://www.ietf.org/mail-archive/web/dispatch/current/msg00083.html 3) cc-uui: http://www.ietf.org/mail-archive/web/dispatch/current/msg00073.html 4) CLF: http://www.ietf.org/mail-archive/web/dispatch/current/msg00066.html 5) Codec: http://www.ietf.org/mail-archive/web/dispatch/current/msg00080.html 6) Sound level indicator: http://www.ietf.org/mail-archive/web/dispatch/current/msg00071.html 7) On demand media/app sharing: http://www.ietf.org/mail-archive/web/dispatch/current/msg00076.html Also, if there are already drafts associated with your charter proposal, please provide appropriate links in your email.=20 For WG participants, there are less than two weeks left (June 15th) to provide input and feedback on the proposals in terms of whether there is sufficient interest to warrant discussion during a f2f session in Stockholm or whether the items can be dispatched prior to Stockholm.=20 Also, please let me know if I've missed something.=20 Regards, Mary.=20 -----Original Message----- From: Barnes, Mary (RICH2:AR00) Sent: Friday, May 08, 2009 12:54 PM To: dispatch@ietf.org Cc: rai-ads@tools.ietf.org; 'Gonzalo Camarillo' Subject: IETF-75 plans for DISPATCH=20 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 enrico.marocco@telecomitalia.it Fri Jun 5 08:05:22 2009 Return-Path: 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 17F6D3A697B for ; Fri, 5 Jun 2009 08:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[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 8v-PmmIHmDDJ for ; Fri, 5 Jun 2009 08:05:21 -0700 (PDT) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by core3.amsl.com (Postfix) with ESMTP id B7F843A6808 for ; Fri, 5 Jun 2009 08:05:20 -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, 5 Jun 2009 17:05:13 +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, 5 Jun 2009 17:05:12 +0200 Message-ID: <4A29342E.5050107@telecomitalia.it> Date: Fri, 5 Jun 2009 17:05:18 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Roni Even References: <4A15D99F.9060100@sip-communicator.org> <4A1D9C2C.8030108@telecomitalia.it> <0D5F89FAC29E2C41B98A6A762007F5D001F17EE4@GBNTHT12009MSX.gb002.siemens.net> <4A1E8B2E.1030906@sip-communicator.org> <0D5F89FAC29E2C41B98A6A762007F5D001F18237@GBNTHT12009MSX.gb002.siemens.net> <4A1EBBAE.4090609@sip-communicator.org> <4a283e62.12135e0a.12c7.ffffaa0b@mx.google.com> <4A28E5CB.4070306@telecomitalia.it> <4a291c01.12135e0a.14a0.6525@mx.google.com> In-Reply-To: <4a291c01.12135e0a.14a0.6525@mx.google.com> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080003000308040206000901" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 15:05:22 -0000 --------------ms080003000308040206000901 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Roni Even wrote: > Skype also supports starting a multipoint audio conference from the UI. I > would consider this more practical than showing the sound level. XCON > defined this functionality in a standard draft enabling the creation of > audio and video conferences in an multivendor environment. Does your client > support this functionality. Do you see this as a mandatory requirement from > service providers. Well, from my very limited perspective I actually see an increasing interest in Internet conferencing -- the technology seems to be finally usable if not mature, plus the shrinking of travel budgets pushes in that direction -- and features available in free services/applications are probably to be considered as a must-have for any commercial offering. > My concern is that we develop solutions that are not deployed since they > have no high priority for developers and customers. Doing a "cool" solution > in a proprietary environment is simpler since you control the clients as > well as the servers and do not worry about interoperability with other > vendors. The extension needed to carry such information is trivial and folks at SIP Communicator are actually going to implement that. Unfortunately such an extension does not exist yet and the IETF community can provide guidance to define and document it, rather than push them toward a proprietary solution. -- Ciao, Enrico --------------ms080003000308040206000901 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA2MDUxNTA1MThaMCMG CSqGSIb3DQEJBDEWBBSdOf+r6TfKAOudzqAZ5S0rcTOYojBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBCBGJozGQV91LNU4f6TIyWMIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhBCBGJozGQV91LNU4f6TIyWMA0GCSqGSIb3DQEBAQUABIIBAI1iHwhddiZ/ zJPOjVA3PMKVw6bl2zsVSlcV0Htc9fta6FE6Y3Iimp/HoON355S9vzqQ1FxWukeCMyDRoxMR gVNfbhdo6cMt0br89Ci9Dndk8d5+GY+OLPZHf6UXA631eb0tIRy2hImPN9YT51vyjMYfFRcq Pn4O6p+hFJr29svE0NemldgGbbdWc8TTa0aJkvyLHcM3FIV/iRQfpmovyt6XKk9L/jbJcN6A /SSFGkkUhFPFtGaPr0B1Rtfdu4KlEuc9jtqbzDcG0osCwaPx6z4dodTrAfSe5ObpoOpHo16o FtCtgZCSW/3gnvfQew3O0f/Rp4pAZp7MlJO9HIw59YIAAAAAAAA= --------------ms080003000308040206000901-- From mizuno.shintaro@lab.ntt.co.jp Mon Jun 8 02:20:10 2009 Return-Path: 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 AB8D43A684F for ; Mon, 8 Jun 2009 02:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.51 X-Spam-Level: X-Spam-Status: No, score=0.51 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 TLbntIgBd1yG for ; Mon, 8 Jun 2009 02:20:09 -0700 (PDT) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by core3.amsl.com (Postfix) with ESMTP id F26B53A687F for ; Mon, 8 Jun 2009 02:20:06 -0700 (PDT) Received: from mfs6.rdh.ecl.ntt.co.jp (mfs6.rdh.ecl.ntt.co.jp [129.60.39.149]) by tama50.ecl.ntt.co.jp (8.14.2/8.14.2) with ESMTP id n589KAXH013008; Mon, 8 Jun 2009 18:20:10 +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 CA742693A; Mon, 8 Jun 2009 18:20:10 +0900 (JST) Received: from img.m.ecl.ntt.co.jp (img0.m.ecl.ntt.co.jp [129.60.5.145]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id B4AFD6604; Mon, 8 Jun 2009 18:20:10 +0900 (JST) Received: from trout2 ([129.60.215.44]) by img.m.ecl.ntt.co.jp (8.13.8/8.13.8) with SMTP id n589KAwu027918; Mon, 8 Jun 2009 18:20:10 +0900 (JST) Date: Mon, 8 Jun 2009 18:20:16 +0900 From: Shintaro Mizuno To: dispatch@ietf.org Message-Id: <20090608182016.7a49d902.mizuno.shintaro@lab.ntt.co.jp> In-Reply-To: <200905252200.n4PM0U4D016114@img.m.ecl.ntt.co.jp> References: <200905252200.n4PM0U4D016114@img.m.ecl.ntt.co.jp> X-Mailer: Sylpheed 2.5.0 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] Charter Proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 09:20:10 -0000 Dear DISPATCH Chair, ML members, I've finalized the charter proposal for on-demand media/application sharing. Added milestone/deliverables section and some descriptions on the usage of SIP, but most of the text remains the same. -------------------------------------------------- "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. SIP/SDP will be used to negotiate parameters necessary to establish IKE/IPsec such as IP address, port numbers and authentication information of peers. Current deployment uses SIP also to manage IPsec connection, e.g. use BYE to shut down media sessions for IKE/IPsec, however, further discussions can be made to find out if there are intrests or use cases in using SIP only as a rendezvous protocol. 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 be minor-updated to -05 to conform with this charter proposal) - 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. Milestone/Deliverables: - Aug 09 Issue Internet-Draft (by updating "draft-saito-mmusic-sdp-ike-05") - Nov 09 Submit I-D to IESG for publication as an RFC (Informational) -------------------------------------------------- Best Regards, Shintaro ---------------------------------------- Shintaro MIZUNO mizuno.shintaro@lab.ntt.co.jp NTT Information Sharing Platform Laboratories NTT Corporation ---------------------------------------- From eburger@standardstrack.com Mon Jun 8 03:38:18 2009 Return-Path: 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 9F2983A693F for ; Mon, 8 Jun 2009 03:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.959 X-Spam-Level: X-Spam-Status: No, score=-1.959 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, 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 5bY-XETior-6 for ; Mon, 8 Jun 2009 03:38:17 -0700 (PDT) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id AEFA33A691D for ; Mon, 8 Jun 2009 03:38:17 -0700 (PDT) Received: from [12.46.252.162] (helo=[172.17.136.184]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1MDcF8-0006ev-KZ; Mon, 08 Jun 2009 03:38:19 -0700 Message-Id: From: Eric Burger To: Shintaro Mizuno In-Reply-To: <20090608182016.7a49d902.mizuno.shintaro@lab.ntt.co.jp> Content-Type: multipart/signed; boundary=Apple-Mail-44--137671836; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 8 Jun 2009 06:38:20 -0400 References: <200905252200.n4PM0U4D016114@img.m.ecl.ntt.co.jp> <20090608182016.7a49d902.mizuno.shintaro@lab.ntt.co.jp> 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] Charter Proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 10:38:18 -0000 --Apple-Mail-44--137671836 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Given the proposal is not really for an Internet standard, and the product is not a protocol or standards track document, why are we working on it here? On Jun 8, 2009, at 5:20 AM, Shintaro Mizuno wrote: > Dear DISPATCH Chair, ML members, > > I've finalized the charter proposal for on-demand media/application > sharing. > Added milestone/deliverables section and some descriptions on the > usage > of SIP, but most of the text remains the same. > > -------------------------------------------------- > "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. > > SIP/SDP will be used to negotiate parameters necessary to establish > IKE/IPsec such as IP address, port numbers and authentication > information of peers. Current deployment uses SIP also to manage IPsec > connection, e.g. use BYE to shut down media sessions for IKE/IPsec, > however, further discussions can be made to find out if there are > intrests or use cases in using SIP only as a rendezvous protocol. > > 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 be minor-updated to -05 to conform with this charter proposal) > - 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. > > > Milestone/Deliverables: > - Aug 09 Issue Internet-Draft > (by updating "draft-saito-mmusic-sdp-ike-05") > - Nov 09 Submit I-D to IESG for publication as an RFC (Informational) > > -------------------------------------------------- > Best Regards, > Shintaro > > ---------------------------------------- > Shintaro MIZUNO > mizuno.shintaro@lab.ntt.co.jp > > NTT Information Sharing Platform Laboratories > NTT Corporation > ---------------------------------------- > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --Apple-Mail-44--137671836 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 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA2MDgxMDM4MjBaMCMGCSqGSIb3 DQEJBDEWBBRn+l7seu7/8K/kigmfQU8/kp3s8TCB1AYJKwYBBAGCNxAEMYHGMIHDMIGuMQswCQYD VQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVU aGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhAv lStUS1saxfCiWQ0fZPKfMIHWBgsqhkiG9w0BCRACCzGBxqCBwzCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkN H2TynzANBgkqhkiG9w0BAQEFAASCAQCfu4xOFxdBE1U+BhwDgxR4Q1lVLB9VTpqhBoCURWuPhN/R 6+G/WGs9Bd65+YQG0SEzwGx7bL+WUQYZQD2wjEYH4ZQAfpzZzptoLohqNrpcgNStKKnDPARbFi4U OtDHpDK+PuaMiycF5Rfc2gjqafVhgKAGmtOFacZfIkG/diasVl/q76s9/zyzd5Wg5goxUr2YnepB X6CRRo4ZAkK1/stenpssyzPl9xCZ9vw2bafHRPSKp66ilWSBksnhGdr8ADFuH5VrDlwzyjO+xD8z 2j1j6gUC2pslmDyBYhH3SgJm/UOFh01GzqRaau6+xWcy/hHNXwIsJs/aDorZGunFV83SAAAAAAAA --Apple-Mail-44--137671836-- From vkg@alcatel-lucent.com Mon Jun 8 08:45:56 2009 Return-Path: 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 A886728C142 for ; Mon, 8 Jun 2009 08:45:56 -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 0VtaoSExEW8n for ; Mon, 8 Jun 2009 08:45:55 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 8F12A28C139 for ; Mon, 8 Jun 2009 08:45:55 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id n58Fk0FK001265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 10:46:00 -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 n58FjxoW006312; Mon, 8 Jun 2009 10:46:00 -0500 (CDT) Message-ID: <4A2D3238.30309@alcatel-lucent.com> Date: Mon, 08 Jun 2009 10:46:00 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mary Barnes Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "dispatch@ietf.org" Subject: [dispatch] sip-clf: final proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 15:45:56 -0000 Mary Barnes wrote: > Hi folks, > A reminder to folks that submitted proposals for the initial deadline > that the "charter proposals" are due next Monday, June 8th. [...] Mary: I did not receive any more follow-up comments on sip-clf proposal description since my post last week (please see http://www.ietf.org/mail-archive/web/dispatch/current/msg00176.html). So, the description contained therein constitutes the charter proposal for the sip-clf work. 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/ From alan@sipstation.com Mon Jun 8 09:17:03 2009 Return-Path: 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 0D7E128C12B for ; Mon, 8 Jun 2009 09:17:03 -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 EULkZftZtLGN for ; Mon, 8 Jun 2009 09:17:02 -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 21C7B3A6B51 for ; Mon, 8 Jun 2009 09:17:02 -0700 (PDT) Received: from 24-107-193-18.dhcp.stls.mo.charter.com ([24.107.193.18] helo=aidan-DS.sipserver.homeip.net) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1MDhX0-000CHb-GH; Mon, 08 Jun 2009 16:17:07 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.107.193.18 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+XrMinBjkOaDCQPoq97fPPaLv0LCQNFCA= Message-ID: <4A2D397F.5080408@sipstation.com> Date: Mon, 08 Jun 2009 11:17:03 -0500 From: Alan Johnston User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Dean Willis References: <4A16DEF2.1010505@sipstation.com> <4A17104A.80706@softarmor.com> In-Reply-To: <4A17104A.80706@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Joanne McMillen , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 16:17:03 -0000 Dean, Thanks for your comments - see mine below. Thanks, Alan Dean Willis wrote: > 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. > I think this is worth discussing more. I also think we can add some additional semantics and tagging with UUI. However, I don't see how the INFO approach, which does the negotiation via header fields in the initial dialog setup (INVITE/200/ACK) can work here, given the Call Control UUI must be present in the INVITE/200 exchange prior to dialog establishment. > 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. > The problem is that for call control UUI, the body approach does not meet the requirements we have discussed and agreed to in SIPPING. Also, a body would require no standardization and work in the IETF - if this approach worked, none of us would be pushing a SIP extension for this. > >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... > As it does seem silly to form a separate working group to standardize a single, trivial header field, I would not be opposed to grouping it with the INFO package work. However, this would only be for admin reasons - the mechanism and requirements are, in reality, very very different. > -- > Dean > > > From enrico.marocco@telecomitalia.it Mon Jun 8 12:33:46 2009 Return-Path: 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 5194B3A682D for ; Mon, 8 Jun 2009 12:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 WTVE5VMEI7SE for ; Mon, 8 Jun 2009 12:33:45 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by core3.amsl.com (Postfix) with ESMTP id ECD0B3A68F9 for ; Mon, 8 Jun 2009 12:33:44 -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; Mon, 8 Jun 2009 21:33:47 +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; Mon, 8 Jun 2009 21:33:47 +0200 Message-ID: <4A2D679A.8090408@telecomitalia.it> Date: Mon, 8 Jun 2009 21:33:46 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.17 (X11/20081018) MIME-Version: 1.0 To: "dispatch@ietf.org" Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050103030304020504070505" Subject: [dispatch] Milestone(s) for the Sound Level Indicators problem X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 19:33:46 -0000 --------------ms050103030304020504070505 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit After some online and offline discussion about how to address the problem described in draft-ivov-dispatch-slic-ps-00, i.e. how to enable a mixer to pass the sound levels of the contributing streams that result in a mixed stream back to the clients, it seems that a reasonable way forward would be to have the AVT WG defining the missing piece (an RTP extension to encode sound level values for the CSRCs). So, we would like to propose the following milestone for AVT: "Submit RTP header extension (as per RFC 5285) for multiple sound level indicators." For whoever has missed it, the problem was initially discussed here: http://www.ietf.org/mail-archive/web/dispatch/current/msg00071.html As usual, comments are welcome. -- Ciao, Enrico --------------ms050103030304020504070505 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 hkiG9w0BCQUxDxcNMDkwNjA4MTkzMzQ2WjAjBgkqhkiG9w0BCQQxFgQU+Qnqq8rdF6qYMRva cxNM1kTI0t8wXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQQIQG1mLGwp4XiLY6zS+IQ/6dzCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQD EyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQG1mLGwp4XiLY6zS+IQ/6 dzANBgkqhkiG9w0BAQEFAASCAQB7pIeQPs5VXS4lwlHDpkf6LdfPlMOzl5ceBcKfTfESbGR2 dDqt8o03bXTl0d7dAYzJ1vZmb2LwLyaO6Yc89T3tJG3KgQj7PdSwuJFHvCU/pGY3Ro9ob+Gc E85FCEHx5RirIVhgWajQc2axkeQqBMLfGiLT7TcBXTf7/BzrJFQqnnNRqhqMFc7l+CYfBb8K mrPR0C0dAxqGuUQx1slRkD8q9OE2pSw3x5o1LhbM2czntjKKv+TnkheEk4s/y3D6XWtQQJrx p+mJN2y2OoqLYSY6M6t1B15b+2cICM7UBWYeDoyVqd+W/mEk+RtucEyP/42R6Lyo5Cr3gZn3 F4w+V/AGAAAAAAAA --------------ms050103030304020504070505-- From ron.even.tlv@gmail.com Mon Jun 8 14:07:19 2009 Return-Path: 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 412023A6DD7 for ; Mon, 8 Jun 2009 14:07:19 -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 jM40sCsyz2Cu for ; Mon, 8 Jun 2009 14:07:18 -0700 (PDT) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by core3.amsl.com (Postfix) with ESMTP id C1D5C3A6D65 for ; Mon, 8 Jun 2009 14:07:17 -0700 (PDT) Received: by bwz9 with SMTP id 9so3397143bwz.37 for ; Mon, 08 Jun 2009 14:07:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=rnIbEtDPE40elHalfAyV/dPrA7UJBzwaTo0bD3Rnjco=; b=Ci6reHY23H7wD9pMy/ARytO5GbQnkxhqYgNM7DtFueZf2wh7msIvOC2UzHhvbGjcYt 9joC68ea4vyymJpSDrKfaOghH8SjfSr8jIGpOfe7Zr/hl46rsd/ZtHVhE0VSHx8FfE1A fpvkyDwYQFn1boih2dLm0Cb++KU0mjfC1G2Nc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=XJ1weChKw1E04mp0JGEAIPKXfS9/xylsg/2a+tDvTY5H+YEkDhnS6UOQa+yy6/mHVU 9PgzRSYZLSD1S8z8YTjNAPWGMOPgyjKXv4TUIfqOojO5Y8SEsVkf3tVvzSXUQWQNVgAO f308LbeFuogHwnP5hjTxiX3Fm9gW8PGPYUmjU= Received: by 10.204.54.198 with SMTP id r6mr7067172bkg.191.1244495240403; Mon, 08 Jun 2009 14:07:20 -0700 (PDT) Received: from windows8d787f9 (bzq-79-183-103-253.red.bezeqint.net [79.183.103.253]) by mx.google.com with ESMTPS id z15sm4340252fkz.34.2009.06.08.14.07.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 08 Jun 2009 14:07:18 -0700 (PDT) From: "Roni Even" To: "'Cullen Jennings'" , "'Emil Ivov'" References: <4A15D99F.9060100@sip-communicator.org> In-Reply-To: Date: Tue, 9 Jun 2009 00:06:10 +0300 Message-ID: <4a2d7d86.0f345e0a.59bf.0645@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: Acne7u00o8mkQK1hSc2S3m5mjgpiYQJjXuuA Content-Language: en-us 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 21:07:19 -0000 Cullen, In the PSTN integration I am aware of two methods of associating the PSTN call with the web UI. The first is when the we UI is used to dial out to the user using the PBX telephony API. The second is that when a user is defined in the UI he gets a PIN number so when he dials in to the conference bridge the user must enter this PIN number and using the telephony API it is conveyed to the we UI. There are other solutions Roni -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: Wednesday, May 27, 2009 8:15 PM To: Emil Ivov Cc: dispatch@ietf.org Subject: Re: [dispatch] Yet another problem to dispatch 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 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 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From Even.roni@huawei.com Mon Jun 8 14:29:28 2009 Return-Path: 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 3CF263A6DF5 for ; Mon, 8 Jun 2009 14:29:28 -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.526, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCHPGCOqjQir for ; Mon, 8 Jun 2009 14:29:27 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 5CB463A6D84 for ; Mon, 8 Jun 2009 14:29:27 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KKX00F07VOY7V@szxga02-in.huawei.com> for dispatch@ietf.org; Tue, 09 Jun 2009 05:29:22 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KKX006FTVOXC3@szxga02-in.huawei.com> for dispatch@ietf.org; Tue, 09 Jun 2009 05:29:21 +0800 (CST) Received: from windows8d787f9 (bzq-79-183-103-253.red.bezeqint.net [79.183.103.253]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KKX00E2AVOQCK@szxml01-in.huawei.com>; Tue, 09 Jun 2009 05:29:21 +0800 (CST) Date: Tue, 09 Jun 2009 00:28:05 +0300 From: Roni Even In-reply-to: <4A2D679A.8090408@telecomitalia.it> To: 'Enrico Marocco' , dispatch@ietf.org Message-id: <016401c9e880$0848b390$18da1ab0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcnocBJuUeJ7hFnJR3yTSArDrX1/+AADuZLg References: <4A2D679A.8090408@telecomitalia.it> Subject: Re: [dispatch] Milestone(s) for the Sound Level Indicators problem X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 21:29:28 -0000 Enrico I read draft-ivov-dispatch-slic-ps-00 and what is still bothering me is that since you do not want to use the conference event package to map between the ssrc and the display name for the user (like Bob, Alice), I am not sure how this will work. The mixer will just give the SSRCs of each original stream. It can not supply the mapping since the mixer is not supposed to know it. Are you going to address this part or will it be left to each specific implementation and is out of scope to this work. I am not sure that the client can do it by itself without any information from a central entity. Roni Even -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Enrico Marocco Sent: Monday, June 08, 2009 10:34 PM To: dispatch@ietf.org Subject: [dispatch] Milestone(s) for the Sound Level Indicators problem After some online and offline discussion about how to address the problem described in draft-ivov-dispatch-slic-ps-00, i.e. how to enable a mixer to pass the sound levels of the contributing streams that result in a mixed stream back to the clients, it seems that a reasonable way forward would be to have the AVT WG defining the missing piece (an RTP extension to encode sound level values for the CSRCs). So, we would like to propose the following milestone for AVT: "Submit RTP header extension (as per RFC 5285) for multiple sound level indicators." For whoever has missed it, the problem was initially discussed here: http://www.ietf.org/mail-archive/web/dispatch/current/msg00071.html As usual, comments are welcome. -- Ciao, Enrico From emil@sip-communicator.org Mon Jun 8 17:22:23 2009 Return-Path: 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 CB6183A69F2 for ; Mon, 8 Jun 2009 17:22:23 -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 dzuNMfHYoIJf for ; Mon, 8 Jun 2009 17:22:22 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 6B0023A63CB for ; Mon, 8 Jun 2009 17:22:22 -0700 (PDT) Received: by ewy6 with SMTP id 6so4658422ewy.37 for ; Mon, 08 Jun 2009 17:22:25 -0700 (PDT) Received: by 10.210.36.8 with SMTP id j8mr1666166ebj.40.1244506945388; Mon, 08 Jun 2009 17:22:25 -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 7sm472115eyg.27.2009.06.08.17.22.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 08 Jun 2009 17:22:24 -0700 (PDT) Sender: Emil Ivov Message-ID: <4A2DAB3E.1000201@sip-communicator.org> Date: Tue, 09 Jun 2009 02:22:22 +0200 From: Emil Ivov Organization: SIP Communicator User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Roni Even References: <4A2D679A.8090408@telecomitalia.it> <016401c9e880$0848b390$18da1ab0$%roni@huawei.com> In-Reply-To: <016401c9e880$0848b390$18da1ab0$%roni@huawei.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] Milestone(s) for the Sound Level Indicators problem X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 00:22:23 -0000 Hey Roni, We definitely want to use the conference package for the mapping. There's absolutely no doubt about this. I believe we mention it once or twice in the draft but probably not clearly enough. Apologies. What we don't want to do is use the mechanisms in the conference package to transport the sound level information itself. In other words we want the actual sound levels in RTP packets and not in SIP messages. Hope this makes it clearer. Emil Roni Even wrote: > Enrico > I read draft-ivov-dispatch-slic-ps-00 and what is still bothering me is that > since you do not want to use the conference event package to map between the > ssrc and the display name for the user (like Bob, Alice), I am not sure how > this will work. The mixer will just give the SSRCs of each original stream. > It can not supply the mapping since the mixer is not supposed to know it. > > Are you going to address this part or will it be left to each specific > implementation and is out of scope to this work. I am not sure that the > client can do it by itself without any information from a central entity. > > Roni Even > > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf > Of Enrico Marocco > Sent: Monday, June 08, 2009 10:34 PM > To: dispatch@ietf.org > Subject: [dispatch] Milestone(s) for the Sound Level Indicators problem > > After some online and offline discussion about how to address the problem > described in draft-ivov-dispatch-slic-ps-00, i.e. how to enable a mixer to > pass the sound levels of the contributing streams that result in a mixed > stream back to the clients, it seems that a reasonable way forward would be > to have the AVT WG defining the missing piece (an RTP extension to encode > sound level values for the CSRCs). So, we would like to propose the > following milestone for AVT: > > "Submit RTP header extension (as per RFC 5285) for multiple sound level > indicators." > > For whoever has missed it, the problem was initially discussed here: > http://www.ietf.org/mail-archive/web/dispatch/current/msg00071.html > > As usual, comments are welcome. > > -- > 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, France 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 Even.roni@huawei.com Mon Jun 8 22:21:33 2009 Return-Path: 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 85C413A6A9C for ; Mon, 8 Jun 2009 22:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.973 X-Spam-Level: X-Spam-Status: No, score=-0.973 tagged_above=-999 required=5 tests=[AWL=-0.478, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jKi0KtReWwA for ; Mon, 8 Jun 2009 22:21:32 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 452C23A6970 for ; Mon, 8 Jun 2009 22:21:32 -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 <0KKY008PNHJRCL@szxga03-in.huawei.com> for dispatch@ietf.org; Tue, 09 Jun 2009 13:21:27 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KKY002LPHJRKM@szxga03-in.huawei.com> for dispatch@ietf.org; Tue, 09 Jun 2009 13:21:27 +0800 (CST) Received: from windows8d787f9 (bzq-79-183-103-253.red.bezeqint.net [79.183.103.253]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KKY00MU6HJLEC@szxml01-in.huawei.com>; Tue, 09 Jun 2009 13:21:27 +0800 (CST) Date: Tue, 09 Jun 2009 08:20:10 +0300 From: Roni Even In-reply-to: <4A2DAB3E.1000201@sip-communicator.org> To: 'Emil Ivov' Message-id: <018701c9e8c1$fb944460$f2bccd20$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcnomGJho/iNfPU+SVq+dJON42bVGwAKSPSg References: <4A2D679A.8090408@telecomitalia.it> <016401c9e880$0848b390$18da1ab0$%roni@huawei.com> <4A2DAB3E.1000201@sip-communicator.org> Cc: dispatch@ietf.org Subject: Re: [dispatch] Milestone(s) for the Sound Level Indicators problem X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 05:21:33 -0000 Emil, Sorry if I did not understand but the draft mentions that SIP based solution like conference event package will not work in XMPP environment (section 2.1 of the draft) " It is probably also worth mentioning that the use of RFC 4575 [RFC4575] for such a feature would make the mechanism incompatible with non-SIP signaling protocols like, for example, XMPP [RFC3920] and its Jingle extensions." Roni -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Emil Ivov Sent: Tuesday, June 09, 2009 3:22 AM To: Roni Even Cc: dispatch@ietf.org Subject: Re: [dispatch] Milestone(s) for the Sound Level Indicators problem Hey Roni, We definitely want to use the conference package for the mapping. There's absolutely no doubt about this. I believe we mention it once or twice in the draft but probably not clearly enough. Apologies. What we don't want to do is use the mechanisms in the conference package to transport the sound level information itself. In other words we want the actual sound levels in RTP packets and not in SIP messages. Hope this makes it clearer. Emil Roni Even wrote: > Enrico > I read draft-ivov-dispatch-slic-ps-00 and what is still bothering me is that > since you do not want to use the conference event package to map between the > ssrc and the display name for the user (like Bob, Alice), I am not sure how > this will work. The mixer will just give the SSRCs of each original stream. > It can not supply the mapping since the mixer is not supposed to know it. > > Are you going to address this part or will it be left to each specific > implementation and is out of scope to this work. I am not sure that the > client can do it by itself without any information from a central entity. > > Roni Even > > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf > Of Enrico Marocco > Sent: Monday, June 08, 2009 10:34 PM > To: dispatch@ietf.org > Subject: [dispatch] Milestone(s) for the Sound Level Indicators problem > > After some online and offline discussion about how to address the problem > described in draft-ivov-dispatch-slic-ps-00, i.e. how to enable a mixer to > pass the sound levels of the contributing streams that result in a mixed > stream back to the clients, it seems that a reasonable way forward would be > to have the AVT WG defining the missing piece (an RTP extension to encode > sound level values for the CSRCs). So, we would like to propose the > following milestone for AVT: > > "Submit RTP header extension (as per RFC 5285) for multiple sound level > indicators." > > For whoever has missed it, the problem was initially discussed here: > http://www.ietf.org/mail-archive/web/dispatch/current/msg00071.html > > As usual, comments are welcome. > > -- > 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, France SIP Communicator emcho@sip-communicator.org FAX: +33.1.77.62.47.31 http://sip-communicator.org PHONE: +33.1.77.62.43.30 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From emil@sip-communicator.org Tue Jun 9 00:38:44 2009 Return-Path: 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 7F6933A6DFB for ; Tue, 9 Jun 2009 00:38:44 -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 GFCDmRLGPLsz for ; Tue, 9 Jun 2009 00:38:43 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 0071A3A6DF7 for ; Tue, 9 Jun 2009 00:38:42 -0700 (PDT) Received: by ewy6 with SMTP id 6so4909004ewy.37 for ; Tue, 09 Jun 2009 00:38:45 -0700 (PDT) Received: by 10.210.33.3 with SMTP id g3mr2261042ebg.41.1244533125241; Tue, 09 Jun 2009 00:38:45 -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 28sm1061614eye.46.2009.06.09.00.38.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 09 Jun 2009 00:38:43 -0700 (PDT) Sender: Emil Ivov Message-ID: <4A2E1182.5020409@sip-communicator.org> Date: Tue, 09 Jun 2009 09:38:42 +0200 From: Emil Ivov Organization: SIP Communicator User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Roni Even References: <4A2D679A.8090408@telecomitalia.it> <016401c9e880$0848b390$18da1ab0$%roni@huawei.com> <4A2DAB3E.1000201@sip-communicator.org> <018701c9e8c1$fb944460$f2bccd20$%roni@huawei.com> In-Reply-To: <018701c9e8c1$fb944460$f2bccd20$%roni@huawei.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] Milestone(s) for the Sound Level Indicators problem X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 07:38:44 -0000 Hey Roni, Roni Even wrote: > Emil, > Sorry if I did not understand but the draft mentions that SIP based solution > like conference event package will not work in XMPP environment (section 2.1 > of the draft) > > " It is probably also worth mentioning that the use of RFC 4575 > [RFC4575] for such a feature would make the mechanism incompatible > with non-SIP signaling protocols like, for example, XMPP [RFC3920] > and its Jingle extensions." Yes and again, this is about using 4575 to _transport_ the sound levels. We'll soon submit a draft proposing a possible solution. It will be explaining our approach in more detail and would hopefully clarify issues that were left unclear by the problem statement. Cheers Emil > > Roni > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf > Of Emil Ivov > Sent: Tuesday, June 09, 2009 3:22 AM > To: Roni Even > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Milestone(s) for the Sound Level Indicators problem > > Hey Roni, > > > We definitely want to use the conference package for the mapping. > There's absolutely no doubt about this. I believe we mention it once or > twice in the draft but probably not clearly enough. Apologies. > > What we don't want to do is use the mechanisms in the conference package > to transport the sound level information itself. In other words we want > the actual sound levels in RTP packets and not in SIP messages. > > Hope this makes it clearer. > > Emil > > Roni Even wrote: >> Enrico >> I read draft-ivov-dispatch-slic-ps-00 and what is still bothering me is > that >> since you do not want to use the conference event package to map between > the >> ssrc and the display name for the user (like Bob, Alice), I am not sure > how >> this will work. The mixer will just give the SSRCs of each original > stream. >> It can not supply the mapping since the mixer is not supposed to know it. >> >> Are you going to address this part or will it be left to each specific >> implementation and is out of scope to this work. I am not sure that the >> client can do it by itself without any information from a central entity. >> >> Roni Even >> >> >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf >> Of Enrico Marocco >> Sent: Monday, June 08, 2009 10:34 PM >> To: dispatch@ietf.org >> Subject: [dispatch] Milestone(s) for the Sound Level Indicators problem >> >> After some online and offline discussion about how to address the problem >> described in draft-ivov-dispatch-slic-ps-00, i.e. how to enable a mixer to >> pass the sound levels of the contributing streams that result in a mixed >> stream back to the clients, it seems that a reasonable way forward would > be >> to have the AVT WG defining the missing piece (an RTP extension to encode >> sound level values for the CSRCs). So, we would like to propose the >> following milestone for AVT: >> >> "Submit RTP header extension (as per RFC 5285) for multiple sound level >> indicators." >> >> For whoever has missed it, the problem was initially discussed here: >> http://www.ietf.org/mail-archive/web/dispatch/current/msg00071.html >> >> As usual, comments are welcome. >> >> -- >> 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, France 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 Tue Jun 9 01:15:01 2009 Return-Path: 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 A10ED3A68EC for ; Tue, 9 Jun 2009 01:15:01 -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 NwZUNPraNizV for ; Tue, 9 Jun 2009 01:15:00 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id C418B3A6E02 for ; Tue, 9 Jun 2009 01:15:00 -0700 (PDT) Received: from [192.168.2.102] (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 n598ExOA027468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 9 Jun 2009 03:15:00 -0500 Message-ID: <4A2E19FD.80504@softarmor.com> Date: Tue, 09 Jun 2009 03:14:53 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alan Johnston References: <4A16DEF2.1010505@sipstation.com> <4A17104A.80706@softarmor.com> <4A2D397F.5080408@sipstation.com> In-Reply-To: <4A2D397F.5080408@sipstation.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Joanne McMillen , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 08:15:01 -0000 Alan Johnston wrote: > I think this is worth discussing more. I also think we can add some > additional semantics and tagging with UUI. However, I don't see how the > INFO approach, which does the negotiation via header fields in the > initial dialog setup (INVITE/200/ACK) can work here, given the Call > Control UUI must be present in the INVITE/200 exchange prior to dialog > establishment. I'm not saying use INFO per se, but use the "do you understand this usage of INFO" style of negotiation to solve the "do you understand this type of UUI" problem. What happens before INVITE? OPTIONS can, of course. How do you reject an INVITE that carries an informational body? By rejecting the option tag that says "Understanding this sort of UUI is required". >> 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. >> > > > The problem is that for call control UUI, the body approach does not > meet the requirements we have discussed and agreed to in SIPPING. Also, > a body would require no standardization and work in the IETF - if this > approach worked, none of us would be pushing a SIP extension for this. I'm not sure I believe that. Scratch that; I'm sure I don't believe it, and I don't think SIPPING had the right to say "This MUST be a header" anyhow. Further, defining an option tag for "Understands this body type in this context" DOES require standardization. > As it does seem silly to form a separate working group to standardize a > single, trivial header field, I would not be opposed to grouping it with > the INFO package work. However, this would only be for admin reasons - > the mechanism and requirements are, in reality, very very different. It's not a trivial header field. As worded, it's a cross-layer-violating, bad-usage-encouraging very dangerous hack that is going to put us into a must-fix-the-unnegotiated-usages problem in a few years if we don't fix it the first time. -- Dean From mizuno.shintaro@lab.ntt.co.jp Tue Jun 9 06:02:43 2009 Return-Path: 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 5C4B43A6B2F for ; Tue, 9 Jun 2009 06:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.51 X-Spam-Level: X-Spam-Status: No, score=0.51 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 ePH+jn+eHSsg for ; Tue, 9 Jun 2009 06:02:42 -0700 (PDT) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by core3.amsl.com (Postfix) with ESMTP id F194A3A68A4 for ; Tue, 9 Jun 2009 06:02:41 -0700 (PDT) Received: from mfs6.rdh.ecl.ntt.co.jp (mfs6.rdh.ecl.ntt.co.jp [129.60.39.149]) by tama50.ecl.ntt.co.jp (8.14.2/8.14.2) with ESMTP id n59D2kJe015609; Tue, 9 Jun 2009 22:02:46 +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 9FAD4693A; Tue, 9 Jun 2009 22:02:46 +0900 (JST) Received: from img.m.ecl.ntt.co.jp (img0.m.ecl.ntt.co.jp [129.60.5.145]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 90ADA6604; Tue, 9 Jun 2009 22:02:46 +0900 (JST) Received: from trout2 ([129.60.215.44]) by img.m.ecl.ntt.co.jp (8.13.8/8.13.8) with SMTP id n59D2kiM024175; Tue, 9 Jun 2009 22:02:46 +0900 (JST) Date: Tue, 9 Jun 2009 22:02:42 +0900 From: Shintaro Mizuno To: Eric Burger Message-Id: <20090609220242.67b17e0a.mizuno.shintaro@lab.ntt.co.jp> In-Reply-To: References: <200905252200.n4PM0U4D016114@img.m.ecl.ntt.co.jp> <20090608182016.7a49d902.mizuno.shintaro@lab.ntt.co.jp> X-Mailer: Sylpheed 2.5.0 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] Charter Proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 13:02:43 -0000 Mr. Burger, Thank you for the comment. We don't necessary see a need for a WG to be formed to document the informational document we have listed, the document is there to see if the proposed way forward (informational document possibly as an independent submission) for the document listed is on track or whether something should be done at the WG level. On the other hand, we believe that use of SIP similar to what we have done for VPN will likely to happen more. And on that point, we are wanting to see whether IETF is interested in documenting a guideline for dealing with application that's not voice or video. As written in the discussion point of the charter, the question is how much should SIP be involved. 1. Should SIP just be used as a rendezvous protocol and leave the rest of the negotiation to whatever application? 2. Should SIP involve in management of the established session as it does for audio/video? 3. Should use of SIP not be standardized for peer to peer application beside audio/video? Regards, Shintaro On Mon, 8 Jun 2009 06:38:20 -0400 Eric Burger wrote: > Given the proposal is not really for an Internet standard, and the > product is not a protocol or standards track document, why are we > working on it here? > > On Jun 8, 2009, at 5:20 AM, Shintaro Mizuno wrote: > > > Dear DISPATCH Chair, ML members, > > > > I've finalized the charter proposal for on-demand media/application > > sharing. > > Added milestone/deliverables section and some descriptions on the > > usage > > of SIP, but most of the text remains the same. > > > > -------------------------------------------------- > > "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. > > > > SIP/SDP will be used to negotiate parameters necessary to establish > > IKE/IPsec such as IP address, port numbers and authentication > > information of peers. Current deployment uses SIP also to manage IPsec > > connection, e.g. use BYE to shut down media sessions for IKE/IPsec, > > however, further discussions can be made to find out if there are > > intrests or use cases in using SIP only as a rendezvous protocol. > > > > 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 be minor-updated to -05 to conform with this charter proposal) > > - 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. > > > > > > Milestone/Deliverables: > > - Aug 09 Issue Internet-Draft > > (by updating "draft-saito-mmusic-sdp-ike-05") > > - Nov 09 Submit I-D to IESG for publication as an RFC (Informational) > > > > -------------------------------------------------- > > Best Regards, > > Shintaro > > > > ---------------------------------------- > > Shintaro MIZUNO > > mizuno.shintaro@lab.ntt.co.jp > > > > NTT Information Sharing Platform Laboratories > > NTT Corporation > > ---------------------------------------- > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > ---------------------------------------- Shintaro MIZUNO mizuno.shintaro@lab.ntt.co.jp NTT Information Sharing Platform Laboratories NTT Corporation ---------------------------------------- From alan@sipstation.com Tue Jun 9 06:24:23 2009 Return-Path: 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 423493A68AA for ; Tue, 9 Jun 2009 06:24:23 -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 p0-R0n-SCvvf for ; Tue, 9 Jun 2009 06:24:22 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 597CA3A659B for ; Tue, 9 Jun 2009 06:24:22 -0700 (PDT) Received: from 24-107-193-18.dhcp.stls.mo.charter.com ([24.107.193.18] helo=aidan-DS.sipserver.homeip.net) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1ME1JT-000NjZ-J2; Tue, 09 Jun 2009 13:24:27 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.107.193.18 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/CLCzh5Eu7qqRxOongJrpGzvp5d5Q6Bac= Message-ID: <4A2E6288.60709@sipstation.com> Date: Tue, 09 Jun 2009 08:24:24 -0500 From: Alan Johnston User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Dean Willis References: <4A16DEF2.1010505@sipstation.com> <4A17104A.80706@softarmor.com> <4A2D397F.5080408@sipstation.com> <4A2E19FD.80504@softarmor.com> In-Reply-To: <4A2E19FD.80504@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Joanne McMillen , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 13:24:23 -0000 Dean, SIPPING didn't say it had to be a header, but one of the most important requirements is that UUI be passable in Refer-To and redirection URIs. While most simple UAs support escaping header fields into URIs for transfer, none support escaping bodies into URIs, and for good reason. However, these are discussions we can have post-DISPATCH. I don't think there really are any open issues around the strong interest in this mechanism, and as I said, I'm not opposed to bundling the work with INFO. Thanks, Alan Dean Willis wrote: > Alan Johnston wrote: > >> I think this is worth discussing more. I also think we can add some >> additional semantics and tagging with UUI. However, I don't see how >> the INFO approach, which does the negotiation via header fields in >> the initial dialog setup (INVITE/200/ACK) can work here, given the >> Call Control UUI must be present in the INVITE/200 exchange prior to >> dialog establishment. > > I'm not saying use INFO per se, but use the "do you understand this > usage of INFO" style of negotiation to solve the "do you understand > this type of UUI" problem. > > What happens before INVITE? OPTIONS can, of course. > > How do you reject an INVITE that carries an informational body? By > rejecting the option tag that says "Understanding this sort of UUI is > required". > > >>> 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. >>> >> >> >> The problem is that for call control UUI, the body approach does not >> meet the requirements we have discussed and agreed to in SIPPING. >> Also, a body would require no standardization and work in the IETF - >> if this approach worked, none of us would be pushing a SIP extension >> for this. > > I'm not sure I believe that. Scratch that; I'm sure I don't believe > it, and I don't think SIPPING had the right to say "This MUST be a > header" anyhow. > > Further, defining an option tag for "Understands this body type in > this context" DOES require standardization. > >> As it does seem silly to form a separate working group to standardize >> a single, trivial header field, I would not be opposed to grouping it >> with the INFO package work. However, this would only be for admin >> reasons - the mechanism and requirements are, in reality, very very >> different. > > It's not a trivial header field. As worded, it's a > cross-layer-violating, bad-usage-encouraging very dangerous hack that > is going to put us into a must-fix-the-unnegotiated-usages problem in > a few years if we don't fix it the first time. > > -- > Dean > From hsinnrei@adobe.com Tue Jun 9 06:32:01 2009 Return-Path: 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 EB7353A6BA9 for ; Tue, 9 Jun 2009 06:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.505 X-Spam-Level: X-Spam-Status: No, score=-5.505 tagged_above=-999 required=5 tests=[AWL=0.493, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=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 TQBHwj0aZHhD for ; Tue, 9 Jun 2009 06:32:00 -0700 (PDT) Received: from psmtp.com (exprod6ob114.obsmtp.com [64.18.1.32]) by core3.amsl.com (Postfix) with ESMTP id DE33C3A659B for ; Tue, 9 Jun 2009 06:31:53 -0700 (PDT) Received: from source ([192.150.8.22]) by exprod6ob114.postini.com ([64.18.5.12]) with SMTP ID DSNKSi5kT6zoUob18+i49Tb2oQn8wB1UNul0@postini.com; Tue, 09 Jun 2009 06:32:06 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 n59DVuWG026708; Tue, 9 Jun 2009 06:31:57 -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 n59DVstQ013029; Tue, 9 Jun 2009 06:31:54 -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; Tue, 9 Jun 2009 06:31:54 -0700 Received: from nambx05.corp.adobe.com ([10.8.189.124]) by excas02.corp.adobe.com ([10.8.188.212]) with mapi; Tue, 9 Jun 2009 06:31:54 -0700 From: Henry Sinnreich To: Shintaro Mizuno , Eric Burger Date: Tue, 9 Jun 2009 06:31:52 -0700 Thread-Topic: [dispatch] Charter Proposal Thread-Index: AcnpAppBUXNaqOQmRD6ckMyzzPNu8AABAuzw Message-ID: In-Reply-To: <20090609220242.67b17e0a.mizuno.shintaro@lab.ntt.co.jp> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C653CE783FF1hsinnreiadobecom_" MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Charter Proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 13:32:02 -0000 --_000_C653CE783FF1hsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable You may also want to consider HIP, since it solves NAT traversal for all ap= plication layer protocols, including SIP. http://www.ietf.org/internet-drafts/draft-ietf-hip-nat-traversal-07.txt It also takes care of the IPv4 to IPv6 transition for endpoints, mobility a= nd multi-homing. Open source code is plentifully available for reference implementations. http://www.ietf.org/html.charters/hip-charter.html Henry On 6/9/09 8:02 AM, "Shintaro Mizuno" wrote: Mr. Burger, Thank you for the comment. We don't necessary see a need for a WG to be formed to document the informational document we have listed, the document is there to see if the proposed way forward (informational document possibly as an independent submission) for the document listed is on track or whether something should be done at the WG level. On the other hand, we believe that use of SIP similar to what we have done for VPN will likely to happen more. And on that point, we are wanting to see whether IETF is interested in documenting a guideline for dealing with application that's not voice or video. As written in the discussion point of the charter, the question is how much should SIP be involved. 1. Should SIP just be used as a rendezvous protocol and leave the rest of the negotiation to whatever application? 2. Should SIP involve in management of the established session as it does for audio/video? 3. Should use of SIP not be standardized for peer to peer application beside audio/video? Regards, Shintaro On Mon, 8 Jun 2009 06:38:20 -0400 Eric Burger wrote: > Given the proposal is not really for an Internet standard, and the > product is not a protocol or standards track document, why are we > working on it here? > > On Jun 8, 2009, at 5:20 AM, Shintaro Mizuno wrote: > > > Dear DISPATCH Chair, ML members, > > > > I've finalized the charter proposal for on-demand media/application > > sharing. > > Added milestone/deliverables section and some descriptions on the > > usage > > of SIP, but most of the text remains the same. > > > > -------------------------------------------------- > > "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. > > > > SIP/SDP will be used to negotiate parameters necessary to establish > > IKE/IPsec such as IP address, port numbers and authentication > > information of peers. Current deployment uses SIP also to manage IPsec > > connection, e.g. use BYE to shut down media sessions for IKE/IPsec, > > however, further discussions can be made to find out if there are > > intrests or use cases in using SIP only as a rendezvous protocol. > > > > 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 be minor-updated to -05 to conform with this charter proposal) > > - 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. > > > > > > Milestone/Deliverables: > > - Aug 09 Issue Internet-Draft > > (by updating "draft-saito-mmusic-sdp-ike-05") > > - Nov 09 Submit I-D to IESG for publication as an RFC (Informational) > > > > -------------------------------------------------- > > Best Regards, > > Shintaro > > > > ---------------------------------------- > > Shintaro MIZUNO > > mizuno.shintaro@lab.ntt.co.jp > > > > NTT Information Sharing Platform Laboratories > > NTT Corporation > > ---------------------------------------- > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > ---------------------------------------- Shintaro MIZUNO mizuno.shintaro@lab.ntt.co.jp NTT Information Sharing Platform Laboratories NTT Corporation ---------------------------------------- _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_C653CE783FF1hsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [dispatch] Charter Proposal You may also want to consider HIP, since it solves NAT traversal for = all application layer protocols, including SIP.

http://www.ietf.org/internet-drafts/draft-ietf-hip-nat-traversal-0= 7.txt

It also takes care of the IPv4 to IPv6 transition for endpoints, mobility a= nd multi-homing.
Open source code is plentifully available for reference implementations.
http://www.i= etf.org/html.charters/hip-charter.html

Henry



On 6/9/09 8:02 AM, "Shintaro Mizuno" <mizuno.shintaro@lab.ntt.co.jp> wrote:

Mr. Burger,
 Thank you for the comment.

 We don't necessary see a need for a WG to be formed to document the <= BR> informational document we have listed, the document is there to see if
the proposed way forward (informational document possibly
as an independent submission) for the document listed is on track or
whether something should be done at the WG level.

 On the other hand, we believe that use of SIP similar to what we
have done for VPN will likely to happen more. And on that point, we are
wanting to see whether IETF is interested in documenting a guideline
for dealing with application that's not voice or video.
As written in the discussion point of the charter, the question is how
much should SIP be involved.

 1. Should SIP just be used as a rendezvous protocol and leave the rest of the negotiation to whatever application?
 2. Should SIP involve in management of the established session as it<= BR> does for audio/video?
 3. Should use of SIP not be standardized for peer to peer application=
beside audio/video?


Regards,
Shintaro


On Mon, 8 Jun 2009 06:38:20 -0400
Eric Burger <eburger@standardstra= ck.com> wrote:

> Given the proposal is not really for an Internet standard, and the > product is not a protocol or standards track document, why are we
> working on it here?
>
> On Jun 8, 2009, at 5:20 AM, Shintaro Mizuno wrote:
>
> > Dear DISPATCH Chair, ML members,
> >
> > I've finalized the charter proposal for on-demand media/applicati= on
> > sharing.
> > Added milestone/deliverables section and some descriptions on the=
> > usage
> > of SIP, but most of the text remains the same.
> >
> > --------------------------------------------------
> > "Charter Proposal for on-demand Media/Application Sharing be= tween
> > peers
> > over VPN"
> >
> > Intent:
> > The intent of this charter is to see interests in documenting wha= t's
> > being deployed as an informational for on-demand Media/Applicatio= n
> > sharing between peers over VPN using SIP and discuss what in the<= BR> > > 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 wantin= g 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 sec= urely
> > using popular LAN based communication tool such as DLNA on device= s
> > that
> > are sitting at home, secure LAN (VPN) establishments between thes= e
> > 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<= BR> > > standard bodies, problem of establishing VPN between these user <= BR> > > devices
> > were that current standards for establishing VPN didn't provide a= ll
> > the
> > toolset necessary to overcome some of the obstacles.
> >
> > Namely following issues were found;
> >  (1) Name resolution mechanism under floating IP addresses a= nd 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 pre= vious
> > 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 S= DP
> > 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.
> >
> > SIP/SDP will be used to negotiate parameters necessary to establi= sh
> > IKE/IPsec such as IP address, port numbers and authentication
> > information of peers. Current deployment uses SIP also to manage = IPsec
> > connection, e.g. use BYE to shut down media sessions for IKE/IPse= c,
> > however, further discussions can be made to find out if there are=
> > intrests or use cases in using SIP only as a rendezvous protocol.=
> >
> > Use-cases that may see use for such standard effort;
> >  - Media sharing using DLNA or similar protocol over VPN bet= ween 2
> > users' devices.
> >  - Remote desktop sharing for Customer service over VPN init= iated via
> > SIP call.
> >   * Similar to click to call, customer service agent ca= n access user's
> > pc remotely to troubleshoot the problem customer is facing from t= he
> > call.
> >  - Accessing medical equipments(medical robotics) remotely a= nd
> > possibly controlling medical equipments to monitor elders in a ru= ral
> > 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<= BR> > > "draft-saito-mmusic-sdp-ike-04" as an informational doc= ument.
> > http://tools.ietf.org/html/draft-saito-mmusic-sdp-ike-04
> > (to be minor-updated to -05 to conform with this charter proposal= )
> > - To see interests in standardizing toolset for realizing use-cas= es
> > similar to what's mentioned above, even contemplating the possibi= lity
> > of defining a guideline for SIP usage where SIP is used only as a=
> > rendezvous protocol.
> >
> >
> > Milestone/Deliverables:
> > - Aug 09 Issue Internet-Draft
> >    (by updating "draft-saito-mmusic-sdp-ike-0= 5")
> > - Nov 09 Submit I-D to IESG for publication as an RFC (Informatio= nal)
> >
> > --------------------------------------------------
> > Best Regards,
> > Shintaro
> >
> > ----------------------------------------
> > Shintaro MIZUNO
> > mizuno.shintaro@lab.ntt= .co.jp
> >
> > NTT Information Sharing Platform Laboratories
> > NTT Corporation
> > ----------------------------------------
> >
> > _______________________________________________
> > dispatch mailing list
> > dispatch@ietf.org
> > https:= //www.ietf.org/mailman/listinfo/dispatch
>
>


----------------------------------------
Shintaro MIZUNO
mizuno.shintaro@lab.ntt.co.jp=

NTT Information Sharing Platform Laboratories
NTT Corporation
----------------------------------------

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

--_000_C653CE783FF1hsinnreiadobecom_-- From vkg@alcatel-lucent.com Tue Jun 9 14:01:41 2009 Return-Path: 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 C94873A698F for ; Tue, 9 Jun 2009 14:01:41 -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 pKFnl5uM7Hv4 for ; Tue, 9 Jun 2009 14:01:40 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 5653B3A6C05 for ; Tue, 9 Jun 2009 14:01:40 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id n59L1ema018826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Jun 2009 16:01:40 -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 n59L1daa002622; Tue, 9 Jun 2009 16:01:39 -0500 (CDT) Message-ID: <4A2ECDB2.7000601@alcatel-lucent.com> Date: Tue, 09 Jun 2009 16:01:38 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) 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.39 Cc: Leon Portman , "Jain, Rajnish" , Hadriel Kaplan Subject: [dispatch] Session recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 21:01:41 -0000 Hi: I realize that the deadline for charter proposals was yesterday, but I hope that it is not too late to submit one more. A few interested people (Hadriel Kaplan, Dan Wing, Rajnish Jain, Leon Portman, Andrew Hutton and I) have been interested in RTP session recording in SIP. The requirement draft will be released shortly. We would like to request agenda time in dispatch to propose the formation of a new working group to define protocol extensions and an architecture for RTP recording. Session recording in SIP Mailing Lists: TBD Chairs: TBD Area Directorate: Real Time Applications (RAI) Purpose: Session recording is a critical operational requirement in many businesses, especially where voice is used as a medium for commerce and customer support. A prime example where voice is used for trade is the financial industry. The call recording requirements in this industry are quite stringent. The recorded calls are used for dispute resolution and regulatory compliance. Other businesses such as customer support call centers typically employ call recording for quality control or business analytics. Depending on the country and its regulatory requirements, financial trading floors typically must record all calls. The recorded media content must be an exact copy of the actual conversation (i.e. clipping and loss of media are unacceptable). Some deployments and regulations require that calls be aborted or rejected if the recording device is unavailable. This group will specify requirements for a SIP based protocol interface between a communications system and a recorder. The Communications System is responsible for establishing media sessions where the actual business is conducted. The Recorder is the sink of the recorded media. The recorded sessions can be of any kind such as voice, video and instant messaging. A recorded session is typically comprised of actual media content and the call metadata. The call metadata allows recording archives to be searched and filtered at a later time. The conveyance of call metadata from the communications system to the recorder is outside the scope of this document. This group will only looks into active recording, where the recorded system purposefully streams media to a recording device. Passive recording, where a recording device detects media directly from the network, is outside the scope of this document. In addition, lawful intercept is outside the scope of the group. Proposed deliverables: 1) Requirements document; 2) Solutions document, including reference architecture. 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/ From dromasca@avaya.com Wed Jun 10 02:23:42 2009 Return-Path: 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 20FCB3A67DB for ; Wed, 10 Jun 2009 02:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=0.170, 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 X51sN-rEtfga for ; Wed, 10 Jun 2009 02:23:41 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id BB0EF3A67A4 for ; Wed, 10 Jun 2009 02:23:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,339,1241409600"; d="scan'208";a="163858700" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 10 Jun 2009 05:23:46 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 10 Jun 2009 05:23:45 -0400 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, 10 Jun 2009 11:23:41 +0200 Message-ID: In-Reply-To: <4A2ECDB2.7000601@alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Session recording in SIP Thread-Index: AcnpRYT1lltupJoVRoye5fl5+wRurwAZfn1g References: <4A2ECDB2.7000601@alcatel-lucent.com> From: "Romascanu, Dan (Dan)" To: "Vijay K. Gurbani" , Cc: Leon Portman , "Jain, Rajnish" , Hadriel Kaplan Subject: Re: [dispatch] Session recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 09:23:42 -0000 I believe that this is an important application, and I support doing work in this direction.=20 Three comments on the preliminary words:=20 1. The requirement is for both signaling and media recording, right? Probably good to say it.=20 2. Security and regulations on how the information is accessed and protected are of high importance. They would probably be reflected in the requirements, but explicit wording in the future charter can help. 3. I suggest that we look at the IPFIX protocol as a possible technology to re-use Dan =20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Vijay K. Gurbani > Sent: Wednesday, June 10, 2009 12:02 AM > To: dispatch@ietf.org > Cc: Leon Portman; Jain,Rajnish; Hadriel Kaplan > Subject: [dispatch] Session recording in SIP >=20 > Hi: I realize that the deadline for charter proposals was=20 > yesterday, but I hope that it is not too late to submit one more. >=20 > A few interested people (Hadriel Kaplan, Dan Wing, Rajnish=20 > Jain, Leon Portman, Andrew Hutton and I) have been interested=20 > in RTP session recording in SIP. The requirement draft will=20 > be released shortly. >=20 > We would like to request agenda time in dispatch to propose=20 > the formation of a new working group to define protocol=20 > extensions and an architecture for RTP recording. >=20 > Session recording in SIP > Mailing Lists: TBD > Chairs: TBD > Area Directorate: Real Time Applications (RAI) >=20 > Purpose: >=20 > Session recording is a critical operational requirement in=20 > many businesses, especially where voice is used as a medium=20 > for commerce and customer support. A prime example where=20 > voice is used for trade is the financial industry. The call=20 > recording requirements in this industry are quite stringent.=20 > The recorded calls are used for dispute resolution and=20 > regulatory compliance. Other businesses such as customer=20 > support call centers typically employ call recording for=20 > quality control or business analytics. >=20 > Depending on the country and its regulatory requirements,=20 > financial trading floors typically must record all calls. The=20 > recorded media content must be an exact copy of the actual=20 > conversation (i.e. > clipping and loss of media are unacceptable). Some=20 > deployments and regulations require that calls be aborted or=20 > rejected if the recording device is unavailable. >=20 > This group will specify requirements for a SIP based protocol=20 > interface between a communications system and a recorder. The=20 > Communications System is responsible for establishing media=20 > sessions where the actual business is conducted. The Recorder=20 > is the sink of the recorded media. >=20 > The recorded sessions can be of any kind such as voice, video=20 > and instant messaging. A recorded session is typically=20 > comprised of actual media content and the call metadata. The=20 > call metadata allows recording archives to be searched and=20 > filtered at a later time. > The conveyance of call metadata from the communications=20 > system to the recorder is outside the scope of this document. >=20 > This group will only looks into active recording, where the=20 > recorded system purposefully streams media to a recording=20 > device. Passive recording, where a recording device detects=20 > media directly from the network, is outside the scope of this=20 > document. In addition, lawful intercept is outside the scope=20 > of the group. >=20 > Proposed deliverables: >=20 > 1) Requirements document; > 2) Solutions document, including reference architecture. >=20 > Thanks, >=20 > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960=20 > 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/ > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From Leon.Portman@nice.com Wed Jun 10 05:42:07 2009 Return-Path: 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 491A43A6ADA for ; Wed, 10 Jun 2009 05:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUDjbggbRgTY for ; Wed, 10 Jun 2009 05:42:06 -0700 (PDT) Received: from mailil.nice.com (unknown [192.114.148.38]) by core3.amsl.com (Postfix) with ESMTP id A6B923A67FB for ; Wed, 10 Jun 2009 05:42:05 -0700 (PDT) Received: from TLVMBX01.nice.com ([192.168.253.242]) by tlvcas01.nice.com ([192.168.253.111]) with mapi; Wed, 10 Jun 2009 15:42:07 +0300 From: Leon Portman To: "Romascanu, Dan (Dan)" , "Vijay K. Gurbani" , "dispatch@ietf.org" Date: Wed, 10 Jun 2009 15:42:07 +0300 Thread-Topic: [dispatch] Session recording in SIP Thread-Index: AcnpRYT1lltupJoVRoye5fl5+wRurwAZfn1gAAcXUbA= Message-ID: <07465C1D981ABC41A344374066AE1A2C255D9D917A@TLVMBX01.nice.com> References: <4A2ECDB2.7000601@alcatel-lucent.com> In-Reply-To: Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, he-IL Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 10 Jun 2009 06:39:43 -0700 Cc: "Jain, Rajnish" , Hadriel Kaplan Subject: Re: [dispatch] Session recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 12:42:44 -0000 Dan, Hi Thank you for the comments. Please see below Leon -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 Sent: Wednesday, June 10, 2009 12:24 PM To: Vijay K. Gurbani; dispatch@ietf.org Cc: Leon Portman; Jain,Rajnish; Hadriel Kaplan Subject: RE: [dispatch] Session recording in SIP I believe that this is an important application, and I support doing work in this direction.=20 Three comments on the preliminary words:=20 1. The requirement is for both signaling and media recording, right? Probably good to say it.=20 [LeonP] Actually we want to separate into two separate documents: Media for= king invocation (via SIP invite ) and SIP Event package for signaling repor= ting 2. Security and regulations on how the information is accessed and protected are of high importance. They would probably be reflected in the requirements, but explicit wording in the future charter can help. [LeonP] Currently it was out of scope however we can discuss it 3. I suggest that we look at the IPFIX protocol as a possible technology to re-use [LeonP] OK, we will Dan =20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Vijay K. Gurbani > Sent: Wednesday, June 10, 2009 12:02 AM > To: dispatch@ietf.org > Cc: Leon Portman; Jain,Rajnish; Hadriel Kaplan > Subject: [dispatch] Session recording in SIP >=20 > Hi: I realize that the deadline for charter proposals was=20 > yesterday, but I hope that it is not too late to submit one more. >=20 > A few interested people (Hadriel Kaplan, Dan Wing, Rajnish=20 > Jain, Leon Portman, Andrew Hutton and I) have been interested=20 > in RTP session recording in SIP. The requirement draft will=20 > be released shortly. >=20 > We would like to request agenda time in dispatch to propose=20 > the formation of a new working group to define protocol=20 > extensions and an architecture for RTP recording. >=20 > Session recording in SIP > Mailing Lists: TBD > Chairs: TBD > Area Directorate: Real Time Applications (RAI) >=20 > Purpose: >=20 > Session recording is a critical operational requirement in=20 > many businesses, especially where voice is used as a medium=20 > for commerce and customer support. A prime example where=20 > voice is used for trade is the financial industry. The call=20 > recording requirements in this industry are quite stringent.=20 > The recorded calls are used for dispute resolution and=20 > regulatory compliance. Other businesses such as customer=20 > support call centers typically employ call recording for=20 > quality control or business analytics. >=20 > Depending on the country and its regulatory requirements,=20 > financial trading floors typically must record all calls. The=20 > recorded media content must be an exact copy of the actual=20 > conversation (i.e. > clipping and loss of media are unacceptable). Some=20 > deployments and regulations require that calls be aborted or=20 > rejected if the recording device is unavailable. >=20 > This group will specify requirements for a SIP based protocol=20 > interface between a communications system and a recorder. The=20 > Communications System is responsible for establishing media=20 > sessions where the actual business is conducted. The Recorder=20 > is the sink of the recorded media. >=20 > The recorded sessions can be of any kind such as voice, video=20 > and instant messaging. A recorded session is typically=20 > comprised of actual media content and the call metadata. The=20 > call metadata allows recording archives to be searched and=20 > filtered at a later time. > The conveyance of call metadata from the communications=20 > system to the recorder is outside the scope of this document. >=20 > This group will only looks into active recording, where the=20 > recorded system purposefully streams media to a recording=20 > device. Passive recording, where a recording device detects=20 > media directly from the network, is outside the scope of this=20 > document. In addition, lawful intercept is outside the scope=20 > of the group. >=20 > Proposed deliverables: >=20 > 1) Requirements document; > 2) Solutions document, including reference architecture. >=20 > Thanks, >=20 > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960=20 > 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/ > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From alan@sipstation.com Wed Jun 10 06:42:29 2009 Return-Path: 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 849D43A6E7E for ; Wed, 10 Jun 2009 06:42:29 -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 gmOgvpfzAqjX for ; Wed, 10 Jun 2009 06:42:28 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 2B5163A6841 for ; Wed, 10 Jun 2009 06:42:28 -0700 (PDT) Received: from 24-107-193-18.dhcp.stls.mo.charter.com ([24.107.193.18] helo=aidan-DS.sipserver.homeip.net) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1MEO4W-000IME-NV; Wed, 10 Jun 2009 13:42:33 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.107.193.18 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18T/ADTDpu6MO0nMoq3rXplQpX+9gS+JWU= Message-ID: <4A2FB842.7050302@sipstation.com> Date: Wed, 10 Jun 2009 08:42:26 -0500 From: Alan Johnston User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <4A2ECDB2.7000601@alcatel-lucent.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 10 Jun 2009 07:03:31 -0700 Cc: Leon Portman , dispatch@ietf.org, "Jain, Rajnish" , Hadriel Kaplan Subject: Re: [dispatch] Session recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 13:42:29 -0000 This is important work to be done in RAI. Key management for secure recording is an important component that needs to be addressed. draft-wing-sipping-srtp-key-04 addresses many of these topics. Thanks, Alan Romascanu, Dan (Dan) wrote: > I believe that this is an important application, and I support doing > work in this direction. > > Three comments on the preliminary words: > > 1. The requirement is for both signaling and media recording, right? > Probably good to say it. > 2. Security and regulations on how the information is accessed and > protected are of high importance. They would probably be reflected in > the requirements, but explicit wording in the future charter can help. > 3. I suggest that we look at the IPFIX protocol as a possible technology > to re-use > > Dan > > > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Vijay K. Gurbani >> Sent: Wednesday, June 10, 2009 12:02 AM >> To: dispatch@ietf.org >> Cc: Leon Portman; Jain,Rajnish; Hadriel Kaplan >> Subject: [dispatch] Session recording in SIP >> >> Hi: I realize that the deadline for charter proposals was >> yesterday, but I hope that it is not too late to submit one more. >> >> A few interested people (Hadriel Kaplan, Dan Wing, Rajnish >> Jain, Leon Portman, Andrew Hutton and I) have been interested >> in RTP session recording in SIP. The requirement draft will >> be released shortly. >> >> We would like to request agenda time in dispatch to propose >> the formation of a new working group to define protocol >> extensions and an architecture for RTP recording. >> >> Session recording in SIP >> Mailing Lists: TBD >> Chairs: TBD >> Area Directorate: Real Time Applications (RAI) >> >> Purpose: >> >> Session recording is a critical operational requirement in >> many businesses, especially where voice is used as a medium >> for commerce and customer support. A prime example where >> voice is used for trade is the financial industry. The call >> recording requirements in this industry are quite stringent. >> The recorded calls are used for dispute resolution and >> regulatory compliance. Other businesses such as customer >> support call centers typically employ call recording for >> quality control or business analytics. >> >> Depending on the country and its regulatory requirements, >> financial trading floors typically must record all calls. The >> recorded media content must be an exact copy of the actual >> conversation (i.e. >> clipping and loss of media are unacceptable). Some >> deployments and regulations require that calls be aborted or >> rejected if the recording device is unavailable. >> >> This group will specify requirements for a SIP based protocol >> interface between a communications system and a recorder. The >> Communications System is responsible for establishing media >> sessions where the actual business is conducted. The Recorder >> is the sink of the recorded media. >> >> The recorded sessions can be of any kind such as voice, video >> and instant messaging. A recorded session is typically >> comprised of actual media content and the call metadata. The >> call metadata allows recording archives to be searched and >> filtered at a later time. >> The conveyance of call metadata from the communications >> system to the recorder is outside the scope of this document. >> >> This group will only looks into active recording, where the >> recorded system purposefully streams media to a recording >> device. Passive recording, where a recording device detects >> media directly from the network, is outside the scope of this >> document. In addition, lawful intercept is outside the scope >> of the group. >> >> Proposed deliverables: >> >> 1) Requirements document; >> 2) Solutions document, including reference architecture. >> >> 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/ >> _______________________________________________ >> 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 Even.roni@huawei.com Wed Jun 10 09:19:10 2009 Return-Path: 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 CC9273A68A7 for ; Wed, 10 Jun 2009 09:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.985 X-Spam-Level: X-Spam-Status: No, score=-1.985 tagged_above=-999 required=5 tests=[AWL=0.614, 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 56ht9f6xJX4T for ; Wed, 10 Jun 2009 09:19: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 3A89E3A6CDA for ; Wed, 10 Jun 2009 09:19:09 -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 <0KL10030R6O23H@szxga03-in.huawei.com> for dispatch@ietf.org; Thu, 11 Jun 2009 00:19:14 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KL100ENS6O29F@szxga03-in.huawei.com> for dispatch@ietf.org; Thu, 11 Jun 2009 00:19:14 +0800 (CST) Received: from windows8d787f9 (bzq-79-183-103-253.red.bezeqint.net [79.183.103.253]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KL1002H76NRFU@szxml01-in.huawei.com>; Thu, 11 Jun 2009 00:19:14 +0800 (CST) Date: Wed, 10 Jun 2009 19:18:20 +0300 From: Roni Even In-reply-to: <4A2FB842.7050302@sipstation.com> To: 'Alan Johnston' , "'Romascanu, Dan (Dan)'" Message-id: <023d01c9e9e7$1b015880$51040980$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: Acnp1EzxKUV301OIQi6sPyk1B+h+wgAEoFDQ References: <4A2ECDB2.7000601@alcatel-lucent.com> <4A2FB842.7050302@sipstation.com> Cc: 'Leon Portman' , dispatch@ietf.org, "'Jain, Rajnish'" , 'Hadriel Kaplan' Subject: Re: [dispatch] Session recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 16:19:10 -0000 Hi, I agree that this is an important work but I am not sure about a WG. This may be done in XCON and AVT. Note that the recording is not only for point to point call but at least for three parties like in call center scenarios I also did not notice any mention of the playback part but it should also be addressed Roni Even -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Alan Johnston Sent: Wednesday, June 10, 2009 4:42 PM To: Romascanu, Dan (Dan) Cc: Leon Portman; dispatch@ietf.org; Jain, Rajnish; Hadriel Kaplan Subject: Re: [dispatch] Session recording in SIP This is important work to be done in RAI. Key management for secure recording is an important component that needs to be addressed. draft-wing-sipping-srtp-key-04 addresses many of these topics. Thanks, Alan Romascanu, Dan (Dan) wrote: > I believe that this is an important application, and I support doing > work in this direction. > > Three comments on the preliminary words: > > 1. The requirement is for both signaling and media recording, right? > Probably good to say it. > 2. Security and regulations on how the information is accessed and > protected are of high importance. They would probably be reflected in > the requirements, but explicit wording in the future charter can help. > 3. I suggest that we look at the IPFIX protocol as a possible technology > to re-use > > Dan > > > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Vijay K. Gurbani >> Sent: Wednesday, June 10, 2009 12:02 AM >> To: dispatch@ietf.org >> Cc: Leon Portman; Jain,Rajnish; Hadriel Kaplan >> Subject: [dispatch] Session recording in SIP >> >> Hi: I realize that the deadline for charter proposals was >> yesterday, but I hope that it is not too late to submit one more. >> >> A few interested people (Hadriel Kaplan, Dan Wing, Rajnish >> Jain, Leon Portman, Andrew Hutton and I) have been interested >> in RTP session recording in SIP. The requirement draft will >> be released shortly. >> >> We would like to request agenda time in dispatch to propose >> the formation of a new working group to define protocol >> extensions and an architecture for RTP recording. >> >> Session recording in SIP >> Mailing Lists: TBD >> Chairs: TBD >> Area Directorate: Real Time Applications (RAI) >> >> Purpose: >> >> Session recording is a critical operational requirement in >> many businesses, especially where voice is used as a medium >> for commerce and customer support. A prime example where >> voice is used for trade is the financial industry. The call >> recording requirements in this industry are quite stringent. >> The recorded calls are used for dispute resolution and >> regulatory compliance. Other businesses such as customer >> support call centers typically employ call recording for >> quality control or business analytics. >> >> Depending on the country and its regulatory requirements, >> financial trading floors typically must record all calls. The >> recorded media content must be an exact copy of the actual >> conversation (i.e. >> clipping and loss of media are unacceptable). Some >> deployments and regulations require that calls be aborted or >> rejected if the recording device is unavailable. >> >> This group will specify requirements for a SIP based protocol >> interface between a communications system and a recorder. The >> Communications System is responsible for establishing media >> sessions where the actual business is conducted. The Recorder >> is the sink of the recorded media. >> >> The recorded sessions can be of any kind such as voice, video >> and instant messaging. A recorded session is typically >> comprised of actual media content and the call metadata. The >> call metadata allows recording archives to be searched and >> filtered at a later time. >> The conveyance of call metadata from the communications >> system to the recorder is outside the scope of this document. >> >> This group will only looks into active recording, where the >> recorded system purposefully streams media to a recording >> device. Passive recording, where a recording device detects >> media directly from the network, is outside the scope of this >> document. In addition, lawful intercept is outside the scope >> of the group. >> >> Proposed deliverables: >> >> 1) Requirements document; >> 2) Solutions document, including reference architecture. >> >> 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/ >> _______________________________________________ >> 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 dworley@nortel.com Wed Jun 10 13:36:43 2009 Return-Path: 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 811F73A6C14 for ; Wed, 10 Jun 2009 13:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.724 X-Spam-Level: X-Spam-Status: No, score=-6.724 tagged_above=-999 required=5 tests=[AWL=-0.125, 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 lv4WU85y7cP5 for ; Wed, 10 Jun 2009 13:36:42 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 6C59A3A6C0E for ; Wed, 10 Jun 2009 13:36:42 -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 n5AKakZ25056 for ; Wed, 10 Jun 2009 20:36:46 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Jun 2009 16:36:46 -0400 From: "Dale Worley" To: DISPATCH Content-Type: text/plain Organization: Nortel Networks Date: Wed, 10 Jun 2009 16:36:45 -0400 Message-Id: <1244666205.3769.124.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: 10 Jun 2009 20:36:46.0106 (UTC) FILETIME=[2C086FA0:01C9EA0B] Subject: [dispatch] Getting discussion going on draft-ietf-sipping-profile-datasets-03 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 20:36:43 -0000 This is the list of discussion points that I've assembled. The first 5 are from the last IETF, and the last 3 are ones that have come to mind when I reviewed the draft: DP 1: Merging rules are specified in the schema. Everyone agrees that the merging rules for each property are to be specified in the profile schema. The only interesting merge rule now used is "intersection", for combining values that are sets of an underlying data type. DP 2: Devices containing sub-devices that are separately configured The device will obtain one device profile and one local network profile. The device profile will specify the set of users, each user implying one sub-device. Each sub-device obtains its own user profile. DP 3: Relax NG schema Everyone prefers Relax NG schema language to XML schema language. DP 4: Versioning A schema is extended by defining a new schema whose properties augment or supersede the properties of the original schema (in a way defined in the new schema). This method avoids extending the set of values of an existing property. It also makes clear how the policy server intends to configure a device that does not support the extension: Such a device uses the dataset of the original schema. DP 5: Visibility Each property in a dataset can specify its visibility separately. We need to merge visibility values to determine the visibility in the merged "working profile". Should the working visibility be copied from the visibility of the value that was selected, or should the working visibility be the AND of the visibility valuses? DP 6: The policy attributes sipping-profile-datasets contains a rather messy mechanism for specifying sets of values, tagging each value as "allowed" or "disallowed", and then providing a policy for values that are not mentioned. It seems to me that this could be made much simpler by having a mechanism that specifies either sets of allowed values or sets of disallowed values, along these lines: 1 2 3 1 2 3 As long as we have an equality test for base type (that is, the strings that can appear in the elements), and can be intersected and only generate and results. (That is important because of the "intersection" merge rule.) And we assume that the base type is specified via Relax NG, which provides such an equality test. DP 7: The direction attribute sipping-profile-datasets provides for tagging values with a "direction" attribute, which has values recvonly, sendonly, and sendrecv. The implication is that each property has two values, one for incoming traffic and one for outgoing traffic. Is this a good model, since some values aren't specific for traffic direction? DP 8: The q attribute sipping-profile-datasets provides a "q" attribute that can be specified for elements of sets, so that the choices from a set can be prioritized. Is this facility needed? And if we keep it, how are q values to be combined when values are merged? Dale From wwwrun@core3.amsl.com Wed Jun 10 14:13:37 2009 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id ED76E3A6C26; Wed, 10 Jun 2009 14:13:37 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090610211337.ED76E3A6C26@core3.amsl.com> Date: Wed, 10 Jun 2009 14:13:37 -0700 (PDT) Cc: dispatch mailing list , dispatch chair , Internet Architecture Board , RFC Editor Subject: [dispatch] Protocol Action: 'Managing Client Initiated Connections in the Session Initiation Protocol (SIP)' to Proposed Standard X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 21:13:38 -0000 The IESG has approved the following document: - 'Managing Client Initiated Connections in the Session Initiation Protocol (SIP) ' as a Proposed Standard This document is the product of the Dispatch Working Group. The IESG contact persons are Robert Sparks and Cullen Jennings. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-20.txt Technical Summary This document defines an extension to the Session Initiation Protocol (SIP) that provides for persistent and reusable connections between SIP User Agents and SIP Proxy Servers. In particular, this 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. Working Group Summary The working group process on this document was exceptionally long. The first WG version of the draft appeared in the summer of 2005. Working group last call initiated in the summer of 2006 and extended until the summer of 2008, requiring several iterations of the draft and the assignment of Francois Audet as a "process champion" for the draft within the working group. Most delays seem to have been related to slow cycle time on the part of the authors, but the process was also delayed by a number of changes occurring during the review cycle. Particular sticking points included the keepalive mechanism and a requirement for binding to multiple outbound proxies if so configured. Both were eventually resolved by a widely-accepted compromises. Additional work is being pursued in SIPCORE to allow the use of the keepalive mechanism independently of the outbound mechanism. Document Quality There have been implementations of previous versions of this draft testing at SIPit events since 2005. Personnel Dean Willis is the document shepherd with significant assistance from Francois Audet. Robert Sparks is the responsible area director. From Even.roni@huawei.com Wed Jun 10 14:28:57 2009 Return-Path: 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 67BC33A6B56 for ; Wed, 10 Jun 2009 14:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.98 X-Spam-Level: X-Spam-Status: No, score=-0.98 tagged_above=-999 required=5 tests=[AWL=-0.485, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4fWvwdSlXOhU for ; Wed, 10 Jun 2009 14:28:56 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id EDE013A67AC for ; Wed, 10 Jun 2009 14:28:55 -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 <0KL100J3WL04WQ@szxga04-in.huawei.com> for dispatch@ietf.org; Thu, 11 Jun 2009 05:28:52 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KL100HQ8L04EK@szxga04-in.huawei.com> for dispatch@ietf.org; Thu, 11 Jun 2009 05:28:52 +0800 (CST) Received: from windows8d787f9 (bzq-79-183-103-253.red.bezeqint.net [79.183.103.253]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KL10097HKZU3L@szxml01-in.huawei.com>; Thu, 11 Jun 2009 05:28:52 +0800 (CST) Date: Thu, 11 Jun 2009 00:28:07 +0300 From: Roni Even In-reply-to: <4A2FB842.7050302@sipstation.com> To: 'Alan Johnston' , "'Romascanu, Dan (Dan)'" Message-id: <028a01c9ea12$5ec96e60$1c5c4b20$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: Acnp1EzxKUV301OIQi6sPyk1B+h+wgAEoFDQ References: <4A2ECDB2.7000601@alcatel-lucent.com> <4A2FB842.7050302@sipstation.com> Cc: 'Leon Portman' , dispatch@ietf.org, "'Jain, Rajnish'" , 'Hadriel Kaplan' Subject: Re: [dispatch] Session recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 21:28:57 -0000 Hi, I agree that this is an important work but I am not sure about a WG. This may be done in XCON and AVT. Note that the recording is not only for point to point call but at least for three parties like in call center scenarios I also did not notice any mention of the playback part but it should also be addressed Roni Even -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Alan Johnston Sent: Wednesday, June 10, 2009 4:42 PM To: Romascanu, Dan (Dan) Cc: Leon Portman; dispatch@ietf.org; Jain, Rajnish; Hadriel Kaplan Subject: Re: [dispatch] Session recording in SIP This is important work to be done in RAI. Key management for secure recording is an important component that needs to be addressed. draft-wing-sipping-srtp-key-04 addresses many of these topics. Thanks, Alan Romascanu, Dan (Dan) wrote: > I believe that this is an important application, and I support doing > work in this direction. > > Three comments on the preliminary words: > > 1. The requirement is for both signaling and media recording, right? > Probably good to say it. > 2. Security and regulations on how the information is accessed and > protected are of high importance. They would probably be reflected in > the requirements, but explicit wording in the future charter can help. > 3. I suggest that we look at the IPFIX protocol as a possible technology > to re-use > > Dan > > > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Vijay K. Gurbani >> Sent: Wednesday, June 10, 2009 12:02 AM >> To: dispatch@ietf.org >> Cc: Leon Portman; Jain,Rajnish; Hadriel Kaplan >> Subject: [dispatch] Session recording in SIP >> >> Hi: I realize that the deadline for charter proposals was >> yesterday, but I hope that it is not too late to submit one more. >> >> A few interested people (Hadriel Kaplan, Dan Wing, Rajnish >> Jain, Leon Portman, Andrew Hutton and I) have been interested >> in RTP session recording in SIP. The requirement draft will >> be released shortly. >> >> We would like to request agenda time in dispatch to propose >> the formation of a new working group to define protocol >> extensions and an architecture for RTP recording. >> >> Session recording in SIP >> Mailing Lists: TBD >> Chairs: TBD >> Area Directorate: Real Time Applications (RAI) >> >> Purpose: >> >> Session recording is a critical operational requirement in >> many businesses, especially where voice is used as a medium >> for commerce and customer support. A prime example where >> voice is used for trade is the financial industry. The call >> recording requirements in this industry are quite stringent. >> The recorded calls are used for dispute resolution and >> regulatory compliance. Other businesses such as customer >> support call centers typically employ call recording for >> quality control or business analytics. >> >> Depending on the country and its regulatory requirements, >> financial trading floors typically must record all calls. The >> recorded media content must be an exact copy of the actual >> conversation (i.e. >> clipping and loss of media are unacceptable). Some >> deployments and regulations require that calls be aborted or >> rejected if the recording device is unavailable. >> >> This group will specify requirements for a SIP based protocol >> interface between a communications system and a recorder. The >> Communications System is responsible for establishing media >> sessions where the actual business is conducted. The Recorder >> is the sink of the recorded media. >> >> The recorded sessions can be of any kind such as voice, video >> and instant messaging. A recorded session is typically >> comprised of actual media content and the call metadata. The >> call metadata allows recording archives to be searched and >> filtered at a later time. >> The conveyance of call metadata from the communications >> system to the recorder is outside the scope of this document. >> >> This group will only looks into active recording, where the >> recorded system purposefully streams media to a recording >> device. Passive recording, where a recording device detects >> media directly from the network, is outside the scope of this >> document. In addition, lawful intercept is outside the scope >> of the group. >> >> Proposed deliverables: >> >> 1) Requirements document; >> 2) Solutions document, including reference architecture. >> >> 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/ >> _______________________________________________ >> 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 rjsparks@nostrum.com Wed Jun 10 14:32:56 2009 Return-Path: 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 15EB13A67AC for ; Wed, 10 Jun 2009 14:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 85HJUSVlk9Iz for ; Wed, 10 Jun 2009 14:32:55 -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 CB31D3A6951 for ; Wed, 10 Jun 2009 14:32:54 -0700 (PDT) Received: from dn3-232.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n5ALWxbH067478 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 10 Jun 2009 16:32:59 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-Id: From: Robert Sparks To: dispatch mailing list , dispatch chair In-Reply-To: <20090610211337.ED76E3A6C26@core3.amsl.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: Wed, 10 Jun 2009 16:32:58 -0500 References: <20090610211337.ED76E3A6C26@core3.amsl.com> X-Mailer: Apple Mail (2.930.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: Re: [dispatch] Protocol Action: 'Managing Client Initiated Connections in the Session Initiation Protocol (SIP)' to Proposed Standard X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 21:32:56 -0000 This is, of course, a product of the SIP working group. I've asked the secretariat to issue a correction. RjS On Jun 10, 2009, at 4:13 PM, The IESG wrote: > The IESG has approved the following document: > > - 'Managing Client Initiated Connections in the Session Initiation > Protocol (SIP) ' > as a Proposed Standard > > This document is the product of the Dispatch Working Group. > > The IESG contact persons are Robert Sparks and Cullen Jennings. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-20.txt > > Technical Summary > > This document defines an extension to the Session Initiation > Protocol > (SIP) that provides for persistent and reusable connections between > SIP User Agents and SIP Proxy Servers. In particular, this 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. > > Working Group Summary > > The working group process on this document was exceptionally long. > The > > > first WG version of the draft appeared in the summer of 2005. > Working > group last call initiated in the summer of 2006 and extended until > the > summer of 2008, requiring several iterations of the draft and the > assignment of Francois Audet as a "process champion" for the draft > within the working group. Most delays seem to have been related to > slow cycle time on the part of the authors, but the process was also > delayed by a number of changes occurring during the review cycle. > > Particular sticking points included the keepalive mechanism and a > requirement for binding to multiple outbound proxies if so > configured. Both were eventually resolved by a widely-accepted > compromises. Additional work is being pursued in SIPCORE to allow > the use of the keepalive mechanism independently of the outbound > mechanism. > > Document Quality > > There have been implementations of previous versions of this > draft testing at SIPit events since 2005. > > Personnel > > Dean Willis is the document shepherd with significant assistance > from Francois Audet. Robert Sparks is the responsible area director. > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From jmpolk@cisco.com Wed Jun 10 14:59:52 2009 Return-Path: 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 B83243A6A53 for ; Wed, 10 Jun 2009 14:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.45 X-Spam-Level: X-Spam-Status: No, score=-6.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 1n1xecuq7ChQ for ; Wed, 10 Jun 2009 14:59:51 -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 05A383A6951 for ; Wed, 10 Jun 2009 14:59:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,197,1243814400"; d="scan'208";a="320825400" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 10 Jun 2009 21:59:58 +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 n5ALxvwR031030; Wed, 10 Jun 2009 14:59:57 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n5ALxvu5020508; Wed, 10 Jun 2009 21:59:57 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Jun 2009 14:59:57 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.14.21]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Jun 2009 14:59:57 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 10 Jun 2009 16:59:56 -0500 To: Roni Even , "'Alan Johnston'" , "'Romascanu, Dan (Dan)'" From: "James M. Polk" In-Reply-To: <023d01c9e9e7$1b015880$51040980$%roni@huawei.com> References: <4A2ECDB2.7000601@alcatel-lucent.com> <4A2FB842.7050302@sipstation.com> <023d01c9e9e7$1b015880$51040980$%roni@huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 10 Jun 2009 21:59:57.0377 (UTC) FILETIME=[CB0FF310:01C9EA16] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6352; t=1244671197; x=1245535197; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[dispatch]=20Session=20recording=20in=2 0SIP |Sender:=20; bh=Sjd9PBxA1oT6PbJMpRZWqt0dd9HGDnp1Cx0UT+9J8dc=; b=B3TscM4eqfmiCKxLTdWfbxh66YalwyDc22nVwSSl8TKP4LTdXYVFzwxBTS Ybcf+I5Fbj8gzEncwLKK0E0OYF+9B8nc0hruI3u39hNnqTlJyhV4VMufCmNT OIkgcAT9un; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: 'Leon Portman' , dispatch@ietf.org, "'Jain, Rajnish'" , 'Hadriel Kaplan' Subject: Re: [dispatch] Session recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 21:59:52 -0000 Hey I agree with Roni about this probably being best suited for XCON, after all, any point to point recording is likely (merely) adding a 3rd party (the recorder) to the session. This brings up probably the most glaring whole (in my mind) that is not mentioned below - the ability to have a recorder without at least one side knowing it's there. Not every time, and in fact probably most times, you don't want the other person knowing you are recording them. It's likely more of a case of not explicitly asking the called party "can I record this conversation", it just happens. James At 11:18 AM 6/10/2009, Roni Even wrote: >Hi, >I agree that this is an important work but I am not sure about a WG. This >may be done in XCON and AVT. >Note that the recording is not only for point to point call but at least for >three parties like in call center scenarios > >I also did not notice any mention of the playback part but it should also be >addressed > >Roni Even > >-----Original Message----- >From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf >Of Alan Johnston >Sent: Wednesday, June 10, 2009 4:42 PM >To: Romascanu, Dan (Dan) >Cc: Leon Portman; dispatch@ietf.org; Jain, Rajnish; Hadriel Kaplan >Subject: Re: [dispatch] Session recording in SIP > >This is important work to be done in RAI. Key management for secure >recording is an important component that needs to be addressed. > >draft-wing-sipping-srtp-key-04 addresses many of these topics. > >Thanks, >Alan > > >Romascanu, Dan (Dan) wrote: > > I believe that this is an important application, and I support doing > > work in this direction. > > > > Three comments on the preliminary words: > > > > 1. The requirement is for both signaling and media recording, right? > > Probably good to say it. > > 2. Security and regulations on how the information is accessed and > > protected are of high importance. They would probably be reflected in > > the requirements, but explicit wording in the future charter can help. > > 3. I suggest that we look at the IPFIX protocol as a possible technology > > to re-use > > > > Dan > > > > > > > >> -----Original Message----- > >> From: dispatch-bounces@ietf.org > >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Vijay K. Gurbani > >> Sent: Wednesday, June 10, 2009 12:02 AM > >> To: dispatch@ietf.org > >> Cc: Leon Portman; Jain,Rajnish; Hadriel Kaplan > >> Subject: [dispatch] Session recording in SIP > >> > >> Hi: I realize that the deadline for charter proposals was > >> yesterday, but I hope that it is not too late to submit one more. > >> > >> A few interested people (Hadriel Kaplan, Dan Wing, Rajnish > >> Jain, Leon Portman, Andrew Hutton and I) have been interested > >> in RTP session recording in SIP. The requirement draft will > >> be released shortly. > >> > >> We would like to request agenda time in dispatch to propose > >> the formation of a new working group to define protocol > >> extensions and an architecture for RTP recording. > >> > >> Session recording in SIP > >> Mailing Lists: TBD > >> Chairs: TBD > >> Area Directorate: Real Time Applications (RAI) > >> > >> Purpose: > >> > >> Session recording is a critical operational requirement in > >> many businesses, especially where voice is used as a medium > >> for commerce and customer support. A prime example where > >> voice is used for trade is the financial industry. The call > >> recording requirements in this industry are quite stringent. > >> The recorded calls are used for dispute resolution and > >> regulatory compliance. Other businesses such as customer > >> support call centers typically employ call recording for > >> quality control or business analytics. > >> > >> Depending on the country and its regulatory requirements, > >> financial trading floors typically must record all calls. The > >> recorded media content must be an exact copy of the actual > >> conversation (i.e. > >> clipping and loss of media are unacceptable). Some > >> deployments and regulations require that calls be aborted or > >> rejected if the recording device is unavailable. > >> > >> This group will specify requirements for a SIP based protocol > >> interface between a communications system and a recorder. The > >> Communications System is responsible for establishing media > >> sessions where the actual business is conducted. The Recorder > >> is the sink of the recorded media. > >> > >> The recorded sessions can be of any kind such as voice, video > >> and instant messaging. A recorded session is typically > >> comprised of actual media content and the call metadata. The > >> call metadata allows recording archives to be searched and > >> filtered at a later time. > >> The conveyance of call metadata from the communications > >> system to the recorder is outside the scope of this document. > >> > >> This group will only looks into active recording, where the > >> recorded system purposefully streams media to a recording > >> device. Passive recording, where a recording device detects > >> media directly from the network, is outside the scope of this > >> document. In addition, lawful intercept is outside the scope > >> of the group. > >> > >> Proposed deliverables: > >> > >> 1) Requirements document; > >> 2) Solutions document, including reference architecture. > >> > >> 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/ > >> _______________________________________________ > >> 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 vkg@alcatel-lucent.com Wed Jun 10 15:48:25 2009 Return-Path: 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 297823A6B4A for ; Wed, 10 Jun 2009 15:48:25 -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 foUene2do021 for ; Wed, 10 Jun 2009 15:48:24 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 11E263A6A37 for ; Wed, 10 Jun 2009 15:48:23 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id n5AMmU9N008589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 10 Jun 2009 17:48:30 -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 n5AMmU5X015624 for ; Wed, 10 Jun 2009 17:48:30 -0500 (CDT) Message-ID: <4A30383D.7060902@alcatel-lucent.com> Date: Wed, 10 Jun 2009 17:48:29 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: dispatch@ietf.org References: <4A2ECDB2.7000601@alcatel-lucent.com> <4A2FB842.7050302@sipstation.com> <023d01c9e9e7$1b015880$51040980$%roni@huawei.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: Re: [dispatch] Session recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 22:48:25 -0000 James M. Polk wrote: > I agree with Roni about this probably being best suited for XCON, after > all, any point to point recording is likely (merely) adding a 3rd party > (the recorder) to the session. Could the dispatch chairs/RAI ADs please weigh in on where to do this work? This will help target the requirements draft accordingly. Yesterday, when we had a quick email exchange between authors on where to submit it, sipcore and dispatch were the candidates, and between them, dispatch was more appropriate. And given that to get work going in dispatch required a "mini- charter", we went ahead and submitted one. Between xcon and avt, probably xcon will be more appropriate since the bulk of this work revolves more around SIP than it does on RTP-specific issues. But then, this work does not quite fit in the current xcon charter and deliverables (at least as far as I can see it; I may be wrong, of course.) 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/ From jdrosen@cisco.com Wed Jun 10 18:02:27 2009 Return-Path: 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 174723A67DD for ; Wed, 10 Jun 2009 18:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 LbMdsqKys1ig for ; Wed, 10 Jun 2009 18:02:25 -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 6F9333A67A7 for ; Wed, 10 Jun 2009 18:02:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,198,1243814400"; d="scan'208";a="320904593" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 11 Jun 2009 01:02:32 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n5B12W5b011534; Wed, 10 Jun 2009 18:02:32 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id n5B12VnB018048; Thu, 11 Jun 2009 01:02:31 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.3959); Wed, 10 Jun 2009 21:02:31 -0400 Received: from [10.82.246.45] ([10.82.246.45]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Jun 2009 21:02:31 -0400 Message-ID: <4A30579B.2010300@cisco.com> Date: Wed, 10 Jun 2009 21:02:19 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Vijay K. Gurbani" References: <4A2ECDB2.7000601@alcatel-lucent.com> In-Reply-To: <4A2ECDB2.7000601@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jun 2009 01:02:31.0170 (UTC) FILETIME=[4C081E20:01C9EA30] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3907; t=1244682152; x=1245546152; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[dispatch]=20Session=20recording=20in=2 0SIP |Sender:=20; bh=cEtgpmSXG0WklVLbM6ykTk2kXAo8xlltBJ0ElEugHyY=; b=lG54hkDtvgRPf81Lj7JzVkH9dn6tBcqQbOxb+UeydPS9BTrQZyREiI+cQL Ijn2radKs5LwkBfm/oHX8k5TcBmWSROC0cnh92cleEelv9LhlsF9PZSvnMMf +bBs+C0J+v; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Leon Portman , "dispatch@ietf.org" , "Jain, Rajnish" , Hadriel Kaplan Subject: Re: [dispatch] Session recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 01:02:27 -0000 I think this would be interesting to look at, and I'd also support work in this direction. I also think its pretty fertile ground. Though it seems simple at first blush, recording today is actually a really complicated space. Some of the issues: * where does the 'media forking' happen * interfaces from recording applications to find and request calls to record * storage of recordings * protocols for access to recordings * meta-data about recorded calls * multimedia recording - e.g., record the PPT share in conjunction with the audio I think this is pretty chunky and could merit its own group. I also don't think this is about conferencing. Conferencing and recording are not the same thing, though they both involve sending media streams to multiple places. -Jonathan R. Vijay K. Gurbani wrote: > Hi: I realize that the deadline for charter proposals > was yesterday, but I hope that it is not too late to submit > one more. > > A few interested people (Hadriel Kaplan, Dan Wing, Rajnish Jain, > Leon Portman, Andrew Hutton and I) have been interested in > RTP session recording in SIP. The requirement draft will > be released shortly. > > We would like to request agenda time in dispatch to propose > the formation of a new working group to define protocol > extensions and an architecture for RTP recording. > > Session recording in SIP > Mailing Lists: TBD > Chairs: TBD > Area Directorate: Real Time Applications (RAI) > > Purpose: > > Session recording is a critical operational requirement in many > businesses, especially where voice is used as a medium for > commerce and customer support. A prime example where voice is used > for trade is the financial industry. The call recording requirements > in this industry are quite stringent. The recorded calls are used > for dispute resolution and regulatory compliance. Other businesses > such as customer support call centers typically employ call > recording for quality control or business analytics. > > Depending on the country and its regulatory requirements, financial > trading floors typically must record all calls. The recorded media > content must be an exact copy of the actual conversation (i.e. > clipping and loss of media are unacceptable). Some deployments > and regulations require that calls be aborted or rejected if > the recording device is unavailable. > > This group will specify requirements for a SIP based protocol > interface between a communications system and a recorder. The > Communications System is responsible for establishing media sessions > where the actual business is conducted. The Recorder is the sink of > the recorded media. > > The recorded sessions can be of any kind such as voice, video and > instant messaging. A recorded session is typically comprised of > actual media content and the call metadata. The call metadata allows > recording archives to be searched and filtered at a later time. > The conveyance of call metadata from the communications system > to the recorder is outside the scope of this document. > > This group will only looks into active recording, where the recorded > system purposefully streams media to a recording device. Passive > recording, where a recording device detects media directly from > the network, is outside the scope of this document. In addition, > lawful intercept is outside the scope of the group. > > Proposed deliverables: > > 1) Requirements document; > 2) Solutions document, including reference architecture. > > Thanks, > > - vijay -- Jonathan D. Rosenberg, Ph.D. 111 Wood Avenue South Cisco Fellow Iselin, NJ 08830 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com From mary.barnes@nortel.com Wed Jun 10 19:05:52 2009 Return-Path: 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 69A2B3A6B3D for ; Wed, 10 Jun 2009 19:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.582 X-Spam-Level: X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 JG6BT4w08Cdi for ; Wed, 10 Jun 2009 19:05:51 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 1A4C93A68AF for ; Wed, 10 Jun 2009 19:05:51 -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 n5B25rL24763 for ; Thu, 11 Jun 2009 02:05:53 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, 10 Jun 2009 21:08:26 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E727D56@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A30383D.7060902@alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Session recording in SIP Thread-Index: AcnqHaie8tarQnLbRqiB7U3NWx0rUQAGvR3g References: <4A2ECDB2.7000601@alcatel-lucent.com> <4A2FB842.7050302@sipstation.com> <023d01c9e9e7$1b015880$51040980$%roni@huawei.com> <4A30383D.7060902@alcatel-lucent.com> From: "Mary Barnes" To: "Vijay K. Gurbani" , Subject: Re: [dispatch] Session recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 02:05:52 -0000 At this stage, DISPATCH is the appropriate place to be having these discussions. Since this topic was just introduced to the WG yesterday, it's a bit too early, and not obvious based on the various opinions expressed thus far, to decide that it might belong elsewhere, need a new WG/BoF, etc. So, let's continue the discussion on DISPATCH and refine the problem space and solution scope.=20 Thanks, Mary. DISPATCH WG co-chair -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Vijay K. Gurbani Sent: Wednesday, June 10, 2009 5:48 PM To: dispatch@ietf.org Subject: Re: [dispatch] Session recording in SIP James M. Polk wrote: > I agree with Roni about this probably being best suited for XCON,=20 > after all, any point to point recording is likely (merely) adding a=20 > 3rd party (the recorder) to the session. Could the dispatch chairs/RAI ADs please weigh in on where to do this work? This will help target the requirements draft accordingly. Yesterday, when we had a quick email exchange between authors on where to submit it, sipcore and dispatch were the candidates, and between them, dispatch was more appropriate. And given that to get work going in dispatch required a "mini- charter", we went ahead and submitted one. Between xcon and avt, probably xcon will be more appropriate since the bulk of this work revolves more around SIP than it does on RTP-specific issues. But then, this work does not quite fit in the current xcon charter and deliverables (at least as far as I can see it; I may be wrong, of course.) 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/ _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From Even.roni@huawei.com Wed Jun 10 22:08:13 2009 Return-Path: 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 C59D03A6A5C for ; Wed, 10 Jun 2009 22:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.247 X-Spam-Level: X-Spam-Status: No, score=-0.247 tagged_above=-999 required=5 tests=[AWL=2.352, 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 1emtofXyKgwm for ; Wed, 10 Jun 2009 22:08:12 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 726593A67A7 for ; Wed, 10 Jun 2009 22:08:12 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KL2004B369RAP@szxga02-in.huawei.com> for dispatch@ietf.org; Thu, 11 Jun 2009 13:08:16 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KL2009X469RAK@szxga02-in.huawei.com> for dispatch@ietf.org; Thu, 11 Jun 2009 13:08:15 +0800 (CST) Received: from windows8d787f9 (bzq-79-177-76-15.red.bezeqint.net [79.177.76.15]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KL200I0Q69NK5@szxml01-in.huawei.com>; Thu, 11 Jun 2009 13:08:15 +0800 (CST) Date: Thu, 11 Jun 2009 08:07:34 +0300 From: Roni Even In-reply-to: <1ECE0EB50388174790F9694F77522CCF1E727D56@zrc2hxm0.corp.nortel.com> To: 'Mary Barnes' , "'Vijay K. Gurbani'" , dispatch@ietf.org Message-id: <02c001c9ea52$8bb543a0$a31fcae0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcnqHaie8tarQnLbRqiB7U3NWx0rUQAGvR3gAAYrj1A= References: <4A2ECDB2.7000601@alcatel-lucent.com> <4A2FB842.7050302@sipstation.com> <023d01c9e9e7$1b015880$51040980$%roni@huawei.com> <4A30383D.7060902@alcatel-lucent.com> <1ECE0EB50388174790F9694F77522CCF1E727D56@zrc2hxm0.corp.nortel.com> Subject: Re: [dispatch] Session recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 05:08:14 -0000 Mary, This brings another question about dispatch, what does it mean that dispatch decides that this should be for example a specific WG work. (let's take XCON for example) Does this qualify it as an XCON WG item Does this make the topic a charter item for the XCON WG. I assume that the answer is no for both questions. If the assumption is correct, how do the chairs/Ads decide if to have a long discussion in dispatch about the problem space and solution scope or to move it to a working group and finish this discussion there in order to expedite the work and not repeat the discussion. Roni Even -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Thursday, June 11, 2009 5:08 AM To: Vijay K. Gurbani; dispatch@ietf.org Subject: Re: [dispatch] Session recording in SIP At this stage, DISPATCH is the appropriate place to be having these discussions. Since this topic was just introduced to the WG yesterday, it's a bit too early, and not obvious based on the various opinions expressed thus far, to decide that it might belong elsewhere, need a new WG/BoF, etc. So, let's continue the discussion on DISPATCH and refine the problem space and solution scope. Thanks, Mary. DISPATCH WG co-chair -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Vijay K. Gurbani Sent: Wednesday, June 10, 2009 5:48 PM To: dispatch@ietf.org Subject: Re: [dispatch] Session recording in SIP James M. Polk wrote: > I agree with Roni about this probably being best suited for XCON, > after all, any point to point recording is likely (merely) adding a > 3rd party (the recorder) to the session. Could the dispatch chairs/RAI ADs please weigh in on where to do this work? This will help target the requirements draft accordingly. Yesterday, when we had a quick email exchange between authors on where to submit it, sipcore and dispatch were the candidates, and between them, dispatch was more appropriate. And given that to get work going in dispatch required a "mini- charter", we went ahead and submitted one. Between xcon and avt, probably xcon will be more appropriate since the bulk of this work revolves more around SIP than it does on RTP-specific issues. But then, this work does not quite fit in the current xcon charter and deliverables (at least as far as I can see it; I may be wrong, of course.) 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/ _______________________________________________ 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 christer.holmberg@ericsson.com Wed Jun 10 22:45:58 2009 Return-Path: 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 471A53A6868 for ; Wed, 10 Jun 2009 22:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[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 pL5yqxaB7kev for ; Wed, 10 Jun 2009 22:45:57 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id AAC9C3A67A7 for ; Wed, 10 Jun 2009 22:45:56 -0700 (PDT) X-AuditID: c1b4fb3c-b7b9cae00000140d-4a-4a309a1a240f Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id FE.4C.05133.A1A903A4; Thu, 11 Jun 2009 07:46:02 +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, 11 Jun 2009 07:46:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Jun 2009 07:46:01 +0200 Message-ID: In-Reply-To: <02c001c9ea52$8bb543a0$a31fcae0$%roni@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Session recording in SIP Thread-Index: AcnqHaie8tarQnLbRqiB7U3NWx0rUQAGvR3gAAYrj1AAAXM/oA== References: <4A2ECDB2.7000601@alcatel-lucent.com><4A2FB842.7050302@sipstation.com><023d01c9e9e7$1b015880$51040980$%roni@huawei.com><4A30383D.7060902@alcatel-lucent.com><1ECE0EB50388174790F9694F77522CCF1E727D56@zrc2hxm0.corp.nortel.com> <02c001c9ea52$8bb543a0$a31fcae0$%roni@huawei.com> From: "Christer Holmberg" To: "Roni Even" , "Mary Barnes" , "Vijay K. Gurbani" , X-OriginalArrivalTime: 11 Jun 2009 05:46:01.0868 (UTC) FILETIME=[E732A4C0:01C9EA57] X-Brightmail-Tracker: AAAAAA== Subject: Re: [dispatch] Session recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 05:45:58 -0000 Hi, A question on the use-case behind this: Is the idea that users can record sessions, and then listen to them = later? Ie it is some kind of "network based PVR for SIP sessions" :) OR, is the idea that sessions can be recorded, because there may be some = authority which requires it? In that case, playback functionality etc = may not be needed on the interface between the user and the recorder. Regards, Christer =20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Roni Even > Sent: 11. kes=E4kuuta 2009 8:08 > To: 'Mary Barnes'; 'Vijay K. Gurbani'; dispatch@ietf.org > Subject: Re: [dispatch] Session recording in SIP >=20 > Mary, > This brings another question about dispatch, what does it=20 > mean that dispatch decides that this should be for example a=20 > specific WG work. (let's take XCON for example)=20 >=20 > Does this qualify it as an XCON WG item > Does this make the topic a charter item for the XCON WG. >=20 > I assume that the answer is no for both questions. >=20 > If the assumption is correct, how do the chairs/Ads decide if=20 > to have a long discussion in dispatch about the problem space=20 > and solution scope or to move it to a working group and=20 > finish this discussion there in order to expedite the work=20 > and not repeat the discussion. >=20 > Roni Even >=20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes > Sent: Thursday, June 11, 2009 5:08 AM > To: Vijay K. Gurbani; dispatch@ietf.org > Subject: Re: [dispatch] Session recording in SIP >=20 > At this stage, DISPATCH is the appropriate place to be having=20 > these discussions. Since this topic was just introduced to=20 > the WG yesterday, it's a bit too early, and not obvious based=20 > on the various opinions expressed thus far, to decide that it=20 > might belong elsewhere, need a new WG/BoF, etc. So, let's=20 > continue the discussion on DISPATCH and refine the problem=20 > space and solution scope.=20 >=20 > Thanks, > Mary. > DISPATCH WG co-chair >=20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Vijay K. Gurbani > Sent: Wednesday, June 10, 2009 5:48 PM > To: dispatch@ietf.org > Subject: Re: [dispatch] Session recording in SIP >=20 > James M. Polk wrote: > > I agree with Roni about this probably being best suited for XCON,=20 > > after all, any point to point recording is likely (merely) adding a=20 > > 3rd party (the recorder) to the session. >=20 > Could the dispatch chairs/RAI ADs please weigh in on where to=20 > do this work? This will help target the requirements draft=20 > accordingly. >=20 > Yesterday, when we had a quick email exchange between authors=20 > on where to submit it, sipcore and dispatch were the=20 > candidates, and between them, dispatch was more appropriate. > And given that to get work going in dispatch required a=20 > "mini- charter", we went ahead and submitted one. >=20 > Between xcon and avt, probably xcon will be more appropriate=20 > since the bulk of this work revolves more around SIP than it=20 > does on RTP-specific issues. But then, this work does not=20 > quite fit in the current xcon charter and deliverables (at=20 > least as far as I can see it; I may be wrong, of course.) >=20 > Thanks, >=20 > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960=20 > 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/ > _______________________________________________ > 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 >=20 From gonzalo.camarillo@ericsson.com Wed Jun 10 23:14:57 2009 Return-Path: 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 47EC63A6A41 for ; Wed, 10 Jun 2009 23:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[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 10Kt1zT-95GU for ; Wed, 10 Jun 2009 23:14:56 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 4417C3A68E7 for ; Wed, 10 Jun 2009 23:14:56 -0700 (PDT) X-AuditID: c1b4fb3c-b7b9cae00000140d-d4-4a30a0e686e2 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 35.0F.05133.6E0A03A4; Thu, 11 Jun 2009 08:15:02 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jun 2009 08:15:01 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jun 2009 08:15:00 +0200 Received: from [131.160.126.159] (rvi2-126-159.lmf.ericsson.se [131.160.126.159]) by mail.lmf.ericsson.se (Postfix) with ESMTP id AFF35246A; Thu, 11 Jun 2009 09:15:00 +0300 (EEST) Message-ID: <4A30A0E4.7010401@ericsson.com> Date: Thu, 11 Jun 2009 09:15:00 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: DISPATCH Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jun 2009 06:15:00.0837 (UTC) FILETIME=[F3B44150:01C9EA5B] X-Brightmail-Tracker: AAAAAA== Subject: [dispatch] Wideband audio codec proposal dispatched as a regular BOF X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 06:14:57 -0000 Folks, there have been significant list discussions on whether or not the IETF should be working on the topics proposed in the email below: http://www.ietf.org/mail-archive/web/dispatch/current/msg00080.html As a way forward, we have decided to organize the face-to-face discussions around this topic in Stockholm as a regular BOF (i.e., outside DISPATCH). We believe that, given the nature of the questions that need to be answered, this topic will benefit from discussions from a wide range of people. Organizing the meeting as a regular BOF ensures such discussions. A regular BOF also provides more time for discussions. Therefore, from now on, please use the following mailing list (instead of the DISPATCH list) for discussions on this topic: codec@ietf.org Thanks, Gonzalo DISPATCH co-chair From andrew.hutton@siemens-enterprise.com Thu Jun 11 02:07:34 2009 Return-Path: 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 5BDF53A6803 for ; Thu, 11 Jun 2009 02:07:34 -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 xWFu7Cs2KAx4 for ; Thu, 11 Jun 2009 02:07:28 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 97A653A6989 for ; Thu, 11 Jun 2009 02:07:27 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KL200E4RHCJ0I@siemenscomms.co.uk> for dispatch@ietf.org; Thu, 11 Jun 2009 10:07:31 +0100 (BST) Date: Thu, 11 Jun 2009 10:07:30 +0100 From: "Hutton, Andrew" In-reply-to: <028a01c9ea12$5ec96e60$1c5c4b20$%roni@huawei.com> To: Roni Even , Alan Johnston , "Romascanu, Dan (Dan)" Message-id: <719F9BBB3E7E71428A2D13F3D76C768F01C7BBE8@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] Session recording in SIP Thread-Index: Acnp1EzxKUV301OIQi6sPyk1B+h+wgAEoFDQACL2tqA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4A2ECDB2.7000601@alcatel-lucent.com> <4A2FB842.7050302@sipstation.com> <028a01c9ea12$5ec96e60$1c5c4b20$%roni@huawei.com> Cc: Leon Portman , dispatch@ietf.org, "Jain, Rajnish" , Hadriel Kaplan Subject: Re: [dispatch] Session recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 09:07:34 -0000 Hi, I think that currently this discussion should continue to be in the dispatch WG as the current status seems to fit exactly the Dispatch charter. In my opinion it does not belong in AVT as it does not require any changes to media formats and I also don't think it belongs in XCON as it really is not conferencing although I would agree it has some similarity. Regards Andy =20 >-----Original Message----- >From: dispatch-bounces@ietf.org=20 >[mailto:dispatch-bounces@ietf.org] On Behalf Of Roni Even >Sent: 10 June 2009 22:28 >To: 'Alan Johnston'; 'Romascanu, Dan (Dan)' >Cc: 'Leon Portman'; dispatch@ietf.org; 'Jain,Rajnish'; 'Hadriel Kaplan' >Subject: Re: [dispatch] Session recording in SIP > >Hi, >I agree that this is an important work but I am not sure about=20 >a WG. This >may be done in XCON and AVT. >Note that the recording is not only for point to point call=20 >but at least for >three parties like in call center scenarios > >I also did not notice any mention of the playback part but it=20 >should also be >addressed > >Roni Even > >-----Original Message----- >From: dispatch-bounces@ietf.org=20 >[mailto:dispatch-bounces@ietf.org] On Behalf >Of Alan Johnston >Sent: Wednesday, June 10, 2009 4:42 PM >To: Romascanu, Dan (Dan) >Cc: Leon Portman; dispatch@ietf.org; Jain, Rajnish; Hadriel Kaplan >Subject: Re: [dispatch] Session recording in SIP > >This is important work to be done in RAI. Key management for secure=20 >recording is an important component that needs to be addressed. > >draft-wing-sipping-srtp-key-04 addresses many of these topics. > >Thanks, >Alan > > >Romascanu, Dan (Dan) wrote: >> I believe that this is an important application, and I support doing >> work in this direction.=20 >> >> Three comments on the preliminary words:=20 >> >> 1. The requirement is for both signaling and media recording, right? >> Probably good to say it.=20 >> 2. Security and regulations on how the information is accessed and >> protected are of high importance. They would probably be reflected in >> the requirements, but explicit wording in the future charter=20 >can help. >> 3. I suggest that we look at the IPFIX protocol as a=20 >possible technology >> to re-use >> >> Dan >> =20 >> >> =20 >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org=20 >>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Vijay K. Gurbani >>> Sent: Wednesday, June 10, 2009 12:02 AM >>> To: dispatch@ietf.org >>> Cc: Leon Portman; Jain,Rajnish; Hadriel Kaplan >>> Subject: [dispatch] Session recording in SIP >>> >>> Hi: I realize that the deadline for charter proposals was=20 >>> yesterday, but I hope that it is not too late to submit one more. >>> >>> A few interested people (Hadriel Kaplan, Dan Wing, Rajnish=20 >>> Jain, Leon Portman, Andrew Hutton and I) have been interested=20 >>> in RTP session recording in SIP. The requirement draft will=20 >>> be released shortly. >>> >>> We would like to request agenda time in dispatch to propose=20 >>> the formation of a new working group to define protocol=20 >>> extensions and an architecture for RTP recording. >>> >>> Session recording in SIP >>> Mailing Lists: TBD >>> Chairs: TBD >>> Area Directorate: Real Time Applications (RAI) >>> >>> Purpose: >>> >>> Session recording is a critical operational requirement in=20 >>> many businesses, especially where voice is used as a medium=20 >>> for commerce and customer support. A prime example where=20 >>> voice is used for trade is the financial industry. The call=20 >>> recording requirements in this industry are quite stringent.=20 >>> The recorded calls are used for dispute resolution and=20 >>> regulatory compliance. Other businesses such as customer=20 >>> support call centers typically employ call recording for=20 >>> quality control or business analytics. >>> >>> Depending on the country and its regulatory requirements,=20 >>> financial trading floors typically must record all calls. The=20 >>> recorded media content must be an exact copy of the actual=20 >>> conversation (i.e. >>> clipping and loss of media are unacceptable). Some=20 >>> deployments and regulations require that calls be aborted or=20 >>> rejected if the recording device is unavailable. >>> >>> This group will specify requirements for a SIP based protocol=20 >>> interface between a communications system and a recorder. The=20 >>> Communications System is responsible for establishing media=20 >>> sessions where the actual business is conducted. The Recorder=20 >>> is the sink of the recorded media. >>> >>> The recorded sessions can be of any kind such as voice, video=20 >>> and instant messaging. A recorded session is typically=20 >>> comprised of actual media content and the call metadata. The=20 >>> call metadata allows recording archives to be searched and=20 >>> filtered at a later time. >>> The conveyance of call metadata from the communications=20 >>> system to the recorder is outside the scope of this document. >>> >>> This group will only looks into active recording, where the=20 >>> recorded system purposefully streams media to a recording=20 >>> device. Passive recording, where a recording device detects=20 >>> media directly from the network, is outside the scope of this=20 >>> document. In addition, lawful intercept is outside the scope=20 >>> of the group. >>> >>> Proposed deliverables: >>> >>> 1) Requirements document; >>> 2) Solutions document, including reference architecture. >>> >>> Thanks, >>> >>> - vijay >>> -- >>> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960=20 >>> 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/ >>> _______________________________________________ >>> 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 >> >> =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 Even.roni@huawei.com Thu Jun 11 03:49:33 2009 Return-Path: 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 0C8C23A6B6C for ; Thu, 11 Jun 2009 03:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.412 X-Spam-Level: X-Spam-Status: No, score=-0.412 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnQyywDzZOYp for ; Thu, 11 Jun 2009 03:49:26 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 4B43F3A696C for ; Thu, 11 Jun 2009 03:49:26 -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 <0KL200H94M293V@szxga03-in.huawei.com> for dispatch@ietf.org; Thu, 11 Jun 2009 18:49:21 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KL200JEPM29AW@szxga03-in.huawei.com> for dispatch@ietf.org; Thu, 11 Jun 2009 18:49:21 +0800 (CST) Received: from windows8d787f9 (bzq-79-177-76-15.red.bezeqint.net [79.177.76.15]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KL200435M1YYL@szxml02-in.huawei.com>; Thu, 11 Jun 2009 18:49:21 +0800 (CST) Date: Thu, 11 Jun 2009 13:47:34 +0300 From: Roni Even In-reply-to: <719F9BBB3E7E71428A2D13F3D76C768F01C7BBE8@GBNTHT12009MSX.gb002.siemens.net> To: "'Hutton, Andrew'" , 'Alan Johnston' , "'Romascanu, Dan (Dan)'" Message-id: <002801c9ea82$0da51320$28ef3960$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: Acnp1EzxKUV301OIQi6sPyk1B+h+wgAEoFDQACL2tqAAAy7rEA== References: <4A2ECDB2.7000601@alcatel-lucent.com> <4A2FB842.7050302@sipstation.com> <028a01c9ea12$5ec96e60$1c5c4b20$%roni@huawei.com> <719F9BBB3E7E71428A2D13F3D76C768F01C7BBE8@GBNTHT12009MSX.gb002.siemens.net> Cc: 'Leon Portman' , dispatch@ietf.org, "'Jain, Rajnish'" , 'Hadriel Kaplan' Subject: Re: [dispatch] Session recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 10:49:33 -0000 Hi, I looked at the suggested text and this is why I think it can be done in XCON and that there are AVT aspects The solution wants to record not only point to point calls since call center scenarios include multipoint so it can be done in XCON instead of forming a new WG . XCON is finishing its current charter and may get this as a new charter. As for the media, if you want to record multimedia RTP streams you need to be able to synchronize between the separate streams (done in RTCP now), I think Jonathan made this comment. You may also need to address the SRTP keys if you want to keep the information secure. There is some drafts on the topics currently in AVT. If not RTP is going to stored, you need to address the storage format and require some transcoding capabilities on the record server for audio and video unless you only want a G.711 solution. So if some other packetization is needed maybe this is also AVT work Roni Even -----Original Message----- From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] Sent: Thursday, June 11, 2009 12:08 PM To: Roni Even; Alan Johnston; Romascanu, Dan (Dan) Cc: Leon Portman; dispatch@ietf.org; Jain,Rajnish; Hadriel Kaplan Subject: RE: [dispatch] Session recording in SIP Hi, I think that currently this discussion should continue to be in the dispatch WG as the current status seems to fit exactly the Dispatch charter. In my opinion it does not belong in AVT as it does not require any changes to media formats and I also don't think it belongs in XCON as it really is not conferencing although I would agree it has some similarity. Regards Andy >-----Original Message----- >From: dispatch-bounces@ietf.org >[mailto:dispatch-bounces@ietf.org] On Behalf Of Roni Even >Sent: 10 June 2009 22:28 >To: 'Alan Johnston'; 'Romascanu, Dan (Dan)' >Cc: 'Leon Portman'; dispatch@ietf.org; 'Jain,Rajnish'; 'Hadriel Kaplan' >Subject: Re: [dispatch] Session recording in SIP > >Hi, >I agree that this is an important work but I am not sure about >a WG. This >may be done in XCON and AVT. >Note that the recording is not only for point to point call >but at least for >three parties like in call center scenarios > >I also did not notice any mention of the playback part but it >should also be >addressed > >Roni Even > >-----Original Message----- >From: dispatch-bounces@ietf.org >[mailto:dispatch-bounces@ietf.org] On Behalf >Of Alan Johnston >Sent: Wednesday, June 10, 2009 4:42 PM >To: Romascanu, Dan (Dan) >Cc: Leon Portman; dispatch@ietf.org; Jain, Rajnish; Hadriel Kaplan >Subject: Re: [dispatch] Session recording in SIP > >This is important work to be done in RAI. Key management for secure >recording is an important component that needs to be addressed. > >draft-wing-sipping-srtp-key-04 addresses many of these topics. > >Thanks, >Alan > > >Romascanu, Dan (Dan) wrote: >> I believe that this is an important application, and I support doing >> work in this direction. >> >> Three comments on the preliminary words: >> >> 1. The requirement is for both signaling and media recording, right? >> Probably good to say it. >> 2. Security and regulations on how the information is accessed and >> protected are of high importance. They would probably be reflected in >> the requirements, but explicit wording in the future charter >can help. >> 3. I suggest that we look at the IPFIX protocol as a >possible technology >> to re-use >> >> Dan >> >> >> >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org >>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Vijay K. Gurbani >>> Sent: Wednesday, June 10, 2009 12:02 AM >>> To: dispatch@ietf.org >>> Cc: Leon Portman; Jain,Rajnish; Hadriel Kaplan >>> Subject: [dispatch] Session recording in SIP >>> >>> Hi: I realize that the deadline for charter proposals was >>> yesterday, but I hope that it is not too late to submit one more. >>> >>> A few interested people (Hadriel Kaplan, Dan Wing, Rajnish >>> Jain, Leon Portman, Andrew Hutton and I) have been interested >>> in RTP session recording in SIP. The requirement draft will >>> be released shortly. >>> >>> We would like to request agenda time in dispatch to propose >>> the formation of a new working group to define protocol >>> extensions and an architecture for RTP recording. >>> >>> Session recording in SIP >>> Mailing Lists: TBD >>> Chairs: TBD >>> Area Directorate: Real Time Applications (RAI) >>> >>> Purpose: >>> >>> Session recording is a critical operational requirement in >>> many businesses, especially where voice is used as a medium >>> for commerce and customer support. A prime example where >>> voice is used for trade is the financial industry. The call >>> recording requirements in this industry are quite stringent. >>> The recorded calls are used for dispute resolution and >>> regulatory compliance. Other businesses such as customer >>> support call centers typically employ call recording for >>> quality control or business analytics. >>> >>> Depending on the country and its regulatory requirements, >>> financial trading floors typically must record all calls. The >>> recorded media content must be an exact copy of the actual >>> conversation (i.e. >>> clipping and loss of media are unacceptable). Some >>> deployments and regulations require that calls be aborted or >>> rejected if the recording device is unavailable. >>> >>> This group will specify requirements for a SIP based protocol >>> interface between a communications system and a recorder. The >>> Communications System is responsible for establishing media >>> sessions where the actual business is conducted. The Recorder >>> is the sink of the recorded media. >>> >>> The recorded sessions can be of any kind such as voice, video >>> and instant messaging. A recorded session is typically >>> comprised of actual media content and the call metadata. The >>> call metadata allows recording archives to be searched and >>> filtered at a later time. >>> The conveyance of call metadata from the communications >>> system to the recorder is outside the scope of this document. >>> >>> This group will only looks into active recording, where the >>> recorded system purposefully streams media to a recording >>> device. Passive recording, where a recording device detects >>> media directly from the network, is outside the scope of this >>> document. In addition, lawful intercept is outside the scope >>> of the group. >>> >>> Proposed deliverables: >>> >>> 1) Requirements document; >>> 2) Solutions document, including reference architecture. >>> >>> 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/ >>> _______________________________________________ >>> 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 mary.barnes@nortel.com Thu Jun 11 06:03:02 2009 Return-Path: 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 EE9743A68F1 for ; Thu, 11 Jun 2009 06:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.583 X-Spam-Level: X-Spam-Status: No, score=-6.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 hU+7rwbHudmT for ; Thu, 11 Jun 2009 06:03:01 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 78D883A6821 for ; Thu, 11 Jun 2009 06:03:01 -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 n5BD32l29934; Thu, 11 Jun 2009 13:03:02 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: Thu, 11 Jun 2009 08:05:05 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E727F27@zrc2hxm0.corp.nortel.com> In-Reply-To: <02c001c9ea52$8bb543a0$a31fcae0$%roni@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Session recording in SIP Thread-Index: AcnqHaie8tarQnLbRqiB7U3NWx0rUQAGvR3gAAYrj1AAEH4sIA== References: <4A2ECDB2.7000601@alcatel-lucent.com> <4A2FB842.7050302@sipstation.com> <023d01c9e9e7$1b015880$51040980$%roni@huawei.com> <4A30383D.7060902@alcatel-lucent.com> <1ECE0EB50388174790F9694F77522CCF1E727D56@zrc2hxm0.corp.nortel.com> <02c001c9ea52$8bb543a0$a31fcae0$%roni@huawei.com> From: "Mary Barnes" To: "Roni Even" , "Vijay K. Gurbani" , Subject: Re: [dispatch] Session recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 13:03:03 -0000 Roni, DISPATCH WG can tentatively agree that a work item is appropriate and scoped for a particular WG. That's certainly non-binding as are any decisions in any WG in terms of chartering new work items, until the ADs approve. But, we can ask the ADs to move the work to the appropriate WG. As far as how we decide how long to discuss a topic, that certainly depends upon the topic. But, one of the reasons we set the early deadlines for Stockholm was to get focused discussion on specific topics, so that we could fairly quickly decide if and where work should be done. We do have the milestone of June 15th to finalize the topics that are the focus for Stockholm and we are already in the process of dispatching the items that were submitted on the appropriate deadlines. We're doing those item by item so they're in the appropriate thread of discussion and we'll provide a summary. But, again, this topic has not had enough discussion to make that decision yet. If the group comes to a concensus on scope etc., then it may be possible to dispatch this item prior to Stockholm or use f2f time if needed.=20 Mary.=20 -----Original Message----- From: Roni Even [mailto:Even.roni@huawei.com]=20 Sent: Thursday, June 11, 2009 12:08 AM To: Barnes, Mary (RICH2:AR00); 'Vijay K. Gurbani'; dispatch@ietf.org Subject: RE: [dispatch] Session recording in SIP Mary, This brings another question about dispatch, what does it mean that dispatch decides that this should be for example a specific WG work. (let's take XCON for example)=20 Does this qualify it as an XCON WG item Does this make the topic a charter item for the XCON WG. I assume that the answer is no for both questions. If the assumption is correct, how do the chairs/Ads decide if to have a long discussion in dispatch about the problem space and solution scope or to move it to a working group and finish this discussion there in order to expedite the work and not repeat the discussion. Roni Even -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Thursday, June 11, 2009 5:08 AM To: Vijay K. Gurbani; dispatch@ietf.org Subject: Re: [dispatch] Session recording in SIP At this stage, DISPATCH is the appropriate place to be having these discussions. Since this topic was just introduced to the WG yesterday, it's a bit too early, and not obvious based on the various opinions expressed thus far, to decide that it might belong elsewhere, need a new WG/BoF, etc. So, let's continue the discussion on DISPATCH and refine the problem space and solution scope.=20 Thanks, Mary. DISPATCH WG co-chair -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Vijay K. Gurbani Sent: Wednesday, June 10, 2009 5:48 PM To: dispatch@ietf.org Subject: Re: [dispatch] Session recording in SIP James M. Polk wrote: > I agree with Roni about this probably being best suited for XCON,=20 > after all, any point to point recording is likely (merely) adding a=20 > 3rd party (the recorder) to the session. Could the dispatch chairs/RAI ADs please weigh in on where to do this work? This will help target the requirements draft accordingly. Yesterday, when we had a quick email exchange between authors on where to submit it, sipcore and dispatch were the candidates, and between them, dispatch was more appropriate. And given that to get work going in dispatch required a "mini- charter", we went ahead and submitted one. Between xcon and avt, probably xcon will be more appropriate since the bulk of this work revolves more around SIP than it does on RTP-specific issues. But then, this work does not quite fit in the current xcon charter and deliverables (at least as far as I can see it; I may be wrong, of course.) 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/ _______________________________________________ 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 Thu Jun 11 06:41:43 2009 Return-Path: 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 816E03A6A7B for ; Thu, 11 Jun 2009 06:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.584 X-Spam-Level: X-Spam-Status: No, score=-6.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 wkeIoREy-0C4 for ; Thu, 11 Jun 2009 06:41:42 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 7C6383A6919 for ; Thu, 11 Jun 2009 06:41:42 -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 n5BDfjl11058; Thu, 11 Jun 2009 13:41:45 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: Thu, 11 Jun 2009 08:44:19 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E727FDC@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A2D679A.8090408@telecomitalia.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Milestone(s) for the Sound Level Indicators problem Thread-Index: AcnocBNISGNcX99wRy63IYJYVbOjbACKjI3Q References: <4A2D679A.8090408@telecomitalia.it> From: "Mary Barnes" To: "Enrico Marocco" , Subject: Re: [dispatch] Milestone(s) for the Sound Level Indicators problem X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 13:41:43 -0000 Hi folks, The DISPATCH WG chairs have asked the ADs to move this work item to the AVT WG. Obviously, the work begins with an individual document in the AVT WG and the ongoing discussion in that context would be entirely on the AVT WG mailing list. =20 Thanks, Mary.=20 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Enrico Marocco Sent: Monday, June 08, 2009 2:34 PM To: dispatch@ietf.org Subject: [dispatch] Milestone(s) for the Sound Level Indicators problem After some online and offline discussion about how to address the problem described in draft-ivov-dispatch-slic-ps-00, i.e. how to enable a mixer to pass the sound levels of the contributing streams that result in a mixed stream back to the clients, it seems that a reasonable way forward would be to have the AVT WG defining the missing piece (an RTP extension to encode sound level values for the CSRCs). So, we would like to propose the following milestone for AVT: "Submit RTP header extension (as per RFC 5285) for multiple sound level indicators." For whoever has missed it, the problem was initially discussed here: http://www.ietf.org/mail-archive/web/dispatch/current/msg00071.html As usual, comments are welcome. -- Ciao, Enrico From mary.barnes@nortel.com Thu Jun 11 06:45:12 2009 Return-Path: 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 4ABBA3A6AFA; Thu, 11 Jun 2009 06:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.585 X-Spam-Level: X-Spam-Status: No, score=-6.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 jxKHEKobPHui; Thu, 11 Jun 2009 06:45:11 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 2A0493A693C; Thu, 11 Jun 2009 06:45:11 -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 n5BDhs307375; Thu, 11 Jun 2009 13:43:55 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: Thu, 11 Jun 2009 08:47:43 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E727FEF@zrc2hxm0.corp.nortel.com> In-Reply-To: <1241379400.3528.50.camel@scott> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] draft-lawrence-sip-3rd-party-authorization-00 Thread-Index: AcnMJo0K7J8DEyoPR4Wk1evGXxhUVAedGCrQ References: <1241379400.3528.50.camel@scott> From: "Mary Barnes" To: "RAI DISPATCH" Cc: SIP Operations 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 13:45:12 -0000 Hi folks, There seems to be sufficient interest in this topic to warrant f2f agenda time in Stockholm. However, additional feedback prior to IETF-75 is necessary to ensure that progress can be made in Stockholm.=20 Thanks, Mary.=20 DISPATCH WG co-chair -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Lawrence, Scott (BL60:9D30) Sent: Sunday, May 03, 2009 2:37 PM To: RAI DISPATCH Cc: SIP Operations Subject: [dispatch] draft-lawrence-sip-3rd-party-authorization-00 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. =20 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. _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From enrico.marocco@telecomitalia.it Thu Jun 11 07:00:47 2009 Return-Path: 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 5B9883A6907 for ; Thu, 11 Jun 2009 07:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 LHOqsWaKUf3I for ; Thu, 11 Jun 2009 07:00:46 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by core3.amsl.com (Postfix) with ESMTP id 0D0623A6919 for ; Thu, 11 Jun 2009 07:00:46 -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; Thu, 11 Jun 2009 16:00:51 +0200 Received: from [10.229.8.204] (10.229.8.204) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.1.359.3; Thu, 11 Jun 2009 16:00:51 +0200 Message-ID: <4A310E1A.1040501@telecomitalia.it> Date: Thu, 11 Jun 2009 16:00:58 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Mary Barnes References: <4A2D679A.8090408@telecomitalia.it> <1ECE0EB50388174790F9694F77522CCF1E727FDC@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E727FDC@zrc2hxm0.corp.nortel.com> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000608030202090709090605" Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Milestone(s) for the Sound Level Indicators problem X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 14:00:47 -0000 --------------ms000608030202090709090605 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thanks Mary, we are about to submit a new draft in AVT and will try to move the work forward there. As an unasked, gratuitous comment, I would like to say that we have quite appreciated the new process: in our particular case, a few weeks of discussion in DISPATCH have probably saved several iterations in different WGs. Enrico Mary Barnes wrote: > Hi folks, > > The DISPATCH WG chairs have asked the ADs to move this work item to the > AVT WG. Obviously, the work begins with an individual document in the > AVT WG and the ongoing discussion in that context would be entirely on > the AVT WG mailing list. > > Thanks, > Mary. > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Enrico Marocco > Sent: Monday, June 08, 2009 2:34 PM > To: dispatch@ietf.org > Subject: [dispatch] Milestone(s) for the Sound Level Indicators problem > > After some online and offline discussion about how to address the > problem described in draft-ivov-dispatch-slic-ps-00, i.e. how to enable > a mixer to pass the sound levels of the contributing streams that result > in a mixed stream back to the clients, it seems that a reasonable way > forward would be to have the AVT WG defining the missing piece (an RTP > extension to encode sound level values for the CSRCs). So, we would like > to propose the following milestone for AVT: > > "Submit RTP header extension (as per RFC 5285) for multiple sound level > indicators." > > For whoever has missed it, the problem was initially discussed here: > http://www.ietf.org/mail-archive/web/dispatch/current/msg00071.html > > As usual, comments are welcome. > > -- > Ciao, > Enrico --------------ms000608030202090709090605 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 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA2MTExNDAwNThaMCMG CSqGSIb3DQEJBDEWBBQDsDAqbPCNiJZje62IKO3xJiolFjBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBCBGJozGQV91LNU4f6TIyWMIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhBCBGJozGQV91LNU4f6TIyWMA0GCSqGSIb3DQEBAQUABIIBAISQUg2kk7NZ NqLqMfUcGcH3yss2PGXwmP/kZZV6rtp31VKOkAavLY+3gqNGrbQA/l1Z/mLsVVvJaqgNNnXu 2ASmkDklZK8E1ltxKiSWkE3vLf4hO529i6so84IKilDQU0Pal10g+Rioor+N9tb0ctYEE+j2 YNm6cbrTaVa5Chg14LKvdcXjZ/9ePEAri1s803OHYhuwjk0i54wsgcCwUEEgnLE2q6raHEAk nbONoYMCTFb9d0ceXZi5b7YEhrBhdMDewl6566es7axjgOHbwNtpRtuNNfpdFOxpmo8KGRJp 0czG6jRb7kiz8UTekqWpI5U9zrpCMfySD7atHF9i8XsAAAAAAAA= --------------ms000608030202090709090605-- From andrew.hutton@siemens-enterprise.com Thu Jun 11 07:39:15 2009 Return-Path: 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 423E83A6BCE for ; Thu, 11 Jun 2009 07:39:15 -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 wPbT1Nuia6M0 for ; Thu, 11 Jun 2009 07:39:13 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 7193F3A6B9D for ; Thu, 11 Jun 2009 07:39:13 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KL200AB6WKRTN@siemenscomms.co.uk> for dispatch@ietf.org; Thu, 11 Jun 2009 15:36:27 +0100 (BST) Date: Thu, 11 Jun 2009 15:36:11 +0100 From: "Hutton, Andrew" In-reply-to: <002801c9ea82$0da51320$28ef3960$%roni@huawei.com> To: Roni Even , Alan Johnston , "Romascanu, Dan (Dan)" Message-id: <719F9BBB3E7E71428A2D13F3D76C768F01C7BE97@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] Session recording in SIP Thread-Index: Acnp1EzxKUV301OIQi6sPyk1B+h+wgAEoFDQACL2tqAAAy7rEAAIIWwQ Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4A2ECDB2.7000601@alcatel-lucent.com> <4A2FB842.7050302@sipstation.com> <028a01c9ea12$5ec96e60$1c5c4b20$%roni@huawei.com> <719F9BBB3E7E71428A2D13F3D76C768F01C7BBE8@GBNTHT12009MSX.gb002.siemens.net> <002801c9ea82$0da51320$28ef3960$%roni@huawei.com> Cc: Leon Portman , dispatch@ietf.org, "Jain, Rajnish" , Hadriel Kaplan Subject: Re: [dispatch] Session recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 14:39:15 -0000 Hi, I am sure that there are aspects of session recording that could require work in AVT but I don't see that this is the focus of this proposed work item which I think is to define the SIP requirements and possible SIP protocol extensions that might be needed.=20 I find it harder to see how this relates to XCON. Regards Andy =20 >-----Original Message----- >From: Roni Even [mailto:Even.roni@huawei.com]=20 >Sent: 11 June 2009 11:48 >To: Hutton, Andrew; 'Alan Johnston'; 'Romascanu, Dan (Dan)' >Cc: 'Leon Portman'; dispatch@ietf.org; 'Jain,Rajnish'; 'Hadriel Kaplan' >Subject: RE: [dispatch] Session recording in SIP > >Hi, >I looked at the suggested text and this is why I think it can=20 >be done in >XCON and that there are AVT aspects > >The solution wants to record not only point to point calls=20 >since call center >scenarios include multipoint so it can be done in XCON instead=20 >of forming a >new WG . XCON is finishing its current charter and may get=20 >this as a new >charter. > >As for the media, if you want to record multimedia RTP streams=20 >you need to >be able to synchronize between the separate streams (done in=20 >RTCP now), I >think Jonathan made this comment. You may also need to address=20 >the SRTP keys >if you want to keep the information secure. There is some drafts on the >topics currently in AVT. If not RTP is going to stored, you=20 >need to address >the storage format and require some transcoding capabilities=20 >on the record >server for audio and video unless you only want a G.711=20 >solution. So if some >other packetization is needed maybe this is also AVT work > > >Roni Even > >-----Original Message----- >From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com]=20 >Sent: Thursday, June 11, 2009 12:08 PM >To: Roni Even; Alan Johnston; Romascanu, Dan (Dan) >Cc: Leon Portman; dispatch@ietf.org; Jain,Rajnish; Hadriel Kaplan >Subject: RE: [dispatch] Session recording in SIP > >Hi, > >I think that currently this discussion should continue to be in the >dispatch WG as the current status seems to fit exactly the Dispatch >charter. > >In my opinion it does not belong in AVT as it does not require any >changes to media formats and I also don't think it belongs in=20 >XCON as it >really is not conferencing although I would agree it has some >similarity. > >Regards >Andy >=20 > >>-----Original Message----- >>From: dispatch-bounces@ietf.org=20 >>[mailto:dispatch-bounces@ietf.org] On Behalf Of Roni Even >>Sent: 10 June 2009 22:28 >>To: 'Alan Johnston'; 'Romascanu, Dan (Dan)' >>Cc: 'Leon Portman'; dispatch@ietf.org; 'Jain,Rajnish';=20 >'Hadriel Kaplan' >>Subject: Re: [dispatch] Session recording in SIP >> >>Hi, >>I agree that this is an important work but I am not sure about=20 >>a WG. This >>may be done in XCON and AVT. >>Note that the recording is not only for point to point call=20 >>but at least for >>three parties like in call center scenarios >> >>I also did not notice any mention of the playback part but it=20 >>should also be >>addressed >> >>Roni Even >> >>-----Original Message----- >>From: dispatch-bounces@ietf.org=20 >>[mailto:dispatch-bounces@ietf.org] On Behalf >>Of Alan Johnston >>Sent: Wednesday, June 10, 2009 4:42 PM >>To: Romascanu, Dan (Dan) >>Cc: Leon Portman; dispatch@ietf.org; Jain, Rajnish; Hadriel Kaplan >>Subject: Re: [dispatch] Session recording in SIP >> >>This is important work to be done in RAI. Key management for secure=20 >>recording is an important component that needs to be addressed. >> >>draft-wing-sipping-srtp-key-04 addresses many of these topics. >> >>Thanks, >>Alan >> >> >>Romascanu, Dan (Dan) wrote: >>> I believe that this is an important application, and I support doing >>> work in this direction.=20 >>> >>> Three comments on the preliminary words:=20 >>> >>> 1. The requirement is for both signaling and media recording, right? >>> Probably good to say it.=20 >>> 2. Security and regulations on how the information is accessed and >>> protected are of high importance. They would probably be=20 >reflected in >>> the requirements, but explicit wording in the future charter=20 >>can help. >>> 3. I suggest that we look at the IPFIX protocol as a=20 >>possible technology >>> to re-use >>> >>> Dan >>> =20 >>> >>> =20 >>>> -----Original Message----- >>>> From: dispatch-bounces@ietf.org=20 >>>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Vijay K. Gurbani >>>> Sent: Wednesday, June 10, 2009 12:02 AM >>>> To: dispatch@ietf.org >>>> Cc: Leon Portman; Jain,Rajnish; Hadriel Kaplan >>>> Subject: [dispatch] Session recording in SIP >>>> >>>> Hi: I realize that the deadline for charter proposals was=20 >>>> yesterday, but I hope that it is not too late to submit one more. >>>> >>>> A few interested people (Hadriel Kaplan, Dan Wing, Rajnish=20 >>>> Jain, Leon Portman, Andrew Hutton and I) have been interested=20 >>>> in RTP session recording in SIP. The requirement draft will=20 >>>> be released shortly. >>>> >>>> We would like to request agenda time in dispatch to propose=20 >>>> the formation of a new working group to define protocol=20 >>>> extensions and an architecture for RTP recording. >>>> >>>> Session recording in SIP >>>> Mailing Lists: TBD >>>> Chairs: TBD >>>> Area Directorate: Real Time Applications (RAI) >>>> >>>> Purpose: >>>> >>>> Session recording is a critical operational requirement in=20 >>>> many businesses, especially where voice is used as a medium=20 >>>> for commerce and customer support. A prime example where=20 >>>> voice is used for trade is the financial industry. The call=20 >>>> recording requirements in this industry are quite stringent.=20 >>>> The recorded calls are used for dispute resolution and=20 >>>> regulatory compliance. Other businesses such as customer=20 >>>> support call centers typically employ call recording for=20 >>>> quality control or business analytics. >>>> >>>> Depending on the country and its regulatory requirements,=20 >>>> financial trading floors typically must record all calls. The=20 >>>> recorded media content must be an exact copy of the actual=20 >>>> conversation (i.e. >>>> clipping and loss of media are unacceptable). Some=20 >>>> deployments and regulations require that calls be aborted or=20 >>>> rejected if the recording device is unavailable. >>>> >>>> This group will specify requirements for a SIP based protocol=20 >>>> interface between a communications system and a recorder. The=20 >>>> Communications System is responsible for establishing media=20 >>>> sessions where the actual business is conducted. The Recorder=20 >>>> is the sink of the recorded media. >>>> >>>> The recorded sessions can be of any kind such as voice, video=20 >>>> and instant messaging. A recorded session is typically=20 >>>> comprised of actual media content and the call metadata. The=20 >>>> call metadata allows recording archives to be searched and=20 >>>> filtered at a later time. >>>> The conveyance of call metadata from the communications=20 >>>> system to the recorder is outside the scope of this document. >>>> >>>> This group will only looks into active recording, where the=20 >>>> recorded system purposefully streams media to a recording=20 >>>> device. Passive recording, where a recording device detects=20 >>>> media directly from the network, is outside the scope of this=20 >>>> document. In addition, lawful intercept is outside the scope=20 >>>> of the group. >>>> >>>> Proposed deliverables: >>>> >>>> 1) Requirements document; >>>> 2) Solutions document, including reference architecture. >>>> >>>> Thanks, >>>> >>>> - vijay >>>> -- >>>> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960=20 >>>> 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/ >>>> _______________________________________________ >>>> 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 >>> >>> =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 Thu Jun 11 07:39:22 2009 Return-Path: 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 B9DD43A6C2C for ; Thu, 11 Jun 2009 07:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.585 X-Spam-Level: X-Spam-Status: No, score=-6.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 tFdYhOSowuGV for ; Thu, 11 Jun 2009 07:39:21 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id A31893A6AF1 for ; Thu, 11 Jun 2009 07:39:21 -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 n5BEc4318682; Thu, 11 Jun 2009 14:38:04 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: Thu, 11 Jun 2009 09:40:32 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E728162@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A16DEF2.1010505@sipstation.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Call Control UUI Problem Statement Thread-Index: AcnbAdSPCrtsC2/PQuSF2euLGytg3gPoA0ng References: <4A16DEF2.1010505@sipstation.com> From: "Mary Barnes" To: "Alan Johnston" , Cc: Joanne McMillen 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 14:39:22 -0000 Hi folks,=20 Based on the amount of feedback received, as well as the level of commitment to complete the work, we (ADs/chairs) have decided to propose a new WG (a "mini-WG", if you will) for this topic. It doesn't fit SIPCORE, nor any other current WG and there is enough interest that this shouldn't be individual/AD sponsored. =20 The proposed WG would have a single deliverable and would provide a focused venue for discussions. The idea would be that it would finish very quickly.=20 We will be allocating 30 minutes of agenda time for this topic, with the focus being on the charter for the WG.=20 Regards, Mary. DISPATCH WG co-chair -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Alan Johnston Sent: Friday, May 22, 2009 12:21 PM To: dispatch@ietf.org Cc: Joanne McMillen Subject: [dispatch] Call Control UUI Problem Statement 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.=20 This work area involves defining a new SIP mechanism to transport this information.=20 Since the INFO method, RFC2976, was developed for ISUP interworking of user-to-user information, it might seem to be the logical choice here. =20 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 and Keith Drage Thanks, Alan _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From root@core3.amsl.com Wed Jun 10 13:15:01 2009 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 813BC3A69EC; Wed, 10 Jun 2009 13:15: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: <20090610201501.813BC3A69EC@core3.amsl.com> Date: Wed, 10 Jun 2009 13:15:01 -0700 (PDT) X-Mailman-Approved-At: Thu, 11 Jun 2009 08:11:55 -0700 Cc: dispatch@ietf.org Subject: [dispatch] I-D Action:draft-ietf-sip-outbound-20.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 20:15:01 -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-20.txt Pages : 49 Date : 2009-06-10 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-20.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-20.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-06-10131453.I-D@ietf.org> --NextPart-- From tme@americafree.tv Thu Jun 11 08:13:30 2009 Return-Path: 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 8A0C63A6C69 for ; Thu, 11 Jun 2009 08:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.755 X-Spam-Level: X-Spam-Status: No, score=-2.755 tagged_above=-999 required=5 tests=[AWL=-0.156, 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 Qy9vTP8XDOA5 for ; Thu, 11 Jun 2009 08:13:29 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id B2B463A691C for ; Thu, 11 Jun 2009 08:13:29 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 92EA23FEC01D; Thu, 11 Jun 2009 11:13:36 -0400 (EDT) Message-Id: From: Marshall Eubanks To: Gonzalo Camarillo In-Reply-To: <4A30A0E4.7010401@ericsson.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: Thu, 11 Jun 2009 11:13:35 -0400 References: <4A30A0E4.7010401@ericsson.com> X-Mailer: Apple Mail (2.935.3) Cc: DISPATCH Subject: Re: [dispatch] Wideband audio codec proposal dispatched as a regular BOF X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 15:13:30 -0000 On Jun 11, 2009, at 2:15 AM, Gonzalo Camarillo wrote: > Folks, > > there have been significant list discussions on whether or not the > IETF should be working on the topics proposed in the email below: > > http://www.ietf.org/mail-archive/web/dispatch/current/msg00080.html > > As a way forward, we have decided to organize the face-to-face > discussions around this topic in Stockholm as a regular BOF (i.e., > outside DISPATCH). We believe that, given the nature of the > questions that need to be answered, this topic will benefit from > discussions from a wide range of people. Organizing the meeting as a > regular BOF ensures such discussions. A regular BOF also provides > more time for discussions. > > Therefore, from now on, please use the following mailing list > (instead of the DISPATCH list) for discussions on this topic: > > codec@ietf.org > > Thanks, > > Gonzalo > DISPATCH co-chair > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From Even.roni@huawei.com Thu Jun 11 08:18:03 2009 Return-Path: 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 B00013A6CA7 for ; Thu, 11 Jun 2009 08:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.445 X-Spam-Level: X-Spam-Status: No, score=-0.445 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id duMKFG8A-4cI for ; Thu, 11 Jun 2009 08:18:02 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 134483A6C68 for ; Thu, 11 Jun 2009 08:18:02 -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 <0KL200E69YHYP3@szxga03-in.huawei.com> for dispatch@ietf.org; Thu, 11 Jun 2009 23:17:59 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KL2008AFYHYK2@szxga03-in.huawei.com> for dispatch@ietf.org; Thu, 11 Jun 2009 23:17:58 +0800 (CST) Received: from windows8d787f9 (bzq-79-177-76-15.red.bezeqint.net [79.177.76.15]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KL200LMZYHLQ4@szxml01-in.huawei.com>; Thu, 11 Jun 2009 23:17:58 +0800 (CST) Date: Thu, 11 Jun 2009 18:16:09 +0300 From: Roni Even In-reply-to: <719F9BBB3E7E71428A2D13F3D76C768F01C7BE97@GBNTHT12009MSX.gb002.siemens.net> To: "'Hutton, Andrew'" , 'Alan Johnston' , "'Romascanu, Dan (Dan)'" Message-id: <004a01c9eaa7$94ef7990$bece6cb0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: Acnp1EzxKUV301OIQi6sPyk1B+h+wgAEoFDQACL2tqAAAy7rEAAIIWwQAAG3/BA= References: <4A2ECDB2.7000601@alcatel-lucent.com> <4A2FB842.7050302@sipstation.com> <028a01c9ea12$5ec96e60$1c5c4b20$%roni@huawei.com> <719F9BBB3E7E71428A2D13F3D76C768F01C7BBE8@GBNTHT12009MSX.gb002.siemens.net> <002801c9ea82$0da51320$28ef3960$%roni@huawei.com> <719F9BBB3E7E71428A2D13F3D76C768F01C7BE97@GBNTHT12009MSX.gb002.siemens.net> Cc: 'Leon Portman' , dispatch@ietf.org, "'Jain, Rajnish'" , 'Hadriel Kaplan' Subject: Re: [dispatch] Session recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 15:18:03 -0000 Andy, You have a term called communication system in the proposal Can you clarify what it is? Is this the end points in the call is this some type of a proxy, application aware middle box? There is also a recorder in the proposal, is this a SIP UA or is it just a RTP terminating device like a "media server" in which case this is similar to mediactrl WG work Roni Even -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Hutton, Andrew Sent: Thursday, June 11, 2009 5:36 PM To: Roni Even; Alan Johnston; Romascanu, Dan (Dan) Cc: Leon Portman; dispatch@ietf.org; Jain, Rajnish; Hadriel Kaplan Subject: Re: [dispatch] Session recording in SIP Hi, I am sure that there are aspects of session recording that could require work in AVT but I don't see that this is the focus of this proposed work item which I think is to define the SIP requirements and possible SIP protocol extensions that might be needed. I find it harder to see how this relates to XCON. Regards Andy >-----Original Message----- >From: Roni Even [mailto:Even.roni@huawei.com] >Sent: 11 June 2009 11:48 >To: Hutton, Andrew; 'Alan Johnston'; 'Romascanu, Dan (Dan)' >Cc: 'Leon Portman'; dispatch@ietf.org; 'Jain,Rajnish'; 'Hadriel Kaplan' >Subject: RE: [dispatch] Session recording in SIP > >Hi, >I looked at the suggested text and this is why I think it can >be done in >XCON and that there are AVT aspects > >The solution wants to record not only point to point calls >since call center >scenarios include multipoint so it can be done in XCON instead >of forming a >new WG . XCON is finishing its current charter and may get >this as a new >charter. > >As for the media, if you want to record multimedia RTP streams >you need to >be able to synchronize between the separate streams (done in >RTCP now), I >think Jonathan made this comment. You may also need to address >the SRTP keys >if you want to keep the information secure. There is some drafts on the >topics currently in AVT. If not RTP is going to stored, you >need to address >the storage format and require some transcoding capabilities >on the record >server for audio and video unless you only want a G.711 >solution. So if some >other packetization is needed maybe this is also AVT work > > >Roni Even > >-----Original Message----- >From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] >Sent: Thursday, June 11, 2009 12:08 PM >To: Roni Even; Alan Johnston; Romascanu, Dan (Dan) >Cc: Leon Portman; dispatch@ietf.org; Jain,Rajnish; Hadriel Kaplan >Subject: RE: [dispatch] Session recording in SIP > >Hi, > >I think that currently this discussion should continue to be in the >dispatch WG as the current status seems to fit exactly the Dispatch >charter. > >In my opinion it does not belong in AVT as it does not require any >changes to media formats and I also don't think it belongs in >XCON as it >really is not conferencing although I would agree it has some >similarity. > >Regards >Andy > > >>-----Original Message----- >>From: dispatch-bounces@ietf.org >>[mailto:dispatch-bounces@ietf.org] On Behalf Of Roni Even >>Sent: 10 June 2009 22:28 >>To: 'Alan Johnston'; 'Romascanu, Dan (Dan)' >>Cc: 'Leon Portman'; dispatch@ietf.org; 'Jain,Rajnish'; >'Hadriel Kaplan' >>Subject: Re: [dispatch] Session recording in SIP >> >>Hi, >>I agree that this is an important work but I am not sure about >>a WG. This >>may be done in XCON and AVT. >>Note that the recording is not only for point to point call >>but at least for >>three parties like in call center scenarios >> >>I also did not notice any mention of the playback part but it >>should also be >>addressed >> >>Roni Even >> >>-----Original Message----- >>From: dispatch-bounces@ietf.org >>[mailto:dispatch-bounces@ietf.org] On Behalf >>Of Alan Johnston >>Sent: Wednesday, June 10, 2009 4:42 PM >>To: Romascanu, Dan (Dan) >>Cc: Leon Portman; dispatch@ietf.org; Jain, Rajnish; Hadriel Kaplan >>Subject: Re: [dispatch] Session recording in SIP >> >>This is important work to be done in RAI. Key management for secure >>recording is an important component that needs to be addressed. >> >>draft-wing-sipping-srtp-key-04 addresses many of these topics. >> >>Thanks, >>Alan >> >> >>Romascanu, Dan (Dan) wrote: >>> I believe that this is an important application, and I support doing >>> work in this direction. >>> >>> Three comments on the preliminary words: >>> >>> 1. The requirement is for both signaling and media recording, right? >>> Probably good to say it. >>> 2. Security and regulations on how the information is accessed and >>> protected are of high importance. They would probably be >reflected in >>> the requirements, but explicit wording in the future charter >>can help. >>> 3. I suggest that we look at the IPFIX protocol as a >>possible technology >>> to re-use >>> >>> Dan >>> >>> >>> >>>> -----Original Message----- >>>> From: dispatch-bounces@ietf.org >>>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Vijay K. Gurbani >>>> Sent: Wednesday, June 10, 2009 12:02 AM >>>> To: dispatch@ietf.org >>>> Cc: Leon Portman; Jain,Rajnish; Hadriel Kaplan >>>> Subject: [dispatch] Session recording in SIP >>>> >>>> Hi: I realize that the deadline for charter proposals was >>>> yesterday, but I hope that it is not too late to submit one more. >>>> >>>> A few interested people (Hadriel Kaplan, Dan Wing, Rajnish >>>> Jain, Leon Portman, Andrew Hutton and I) have been interested >>>> in RTP session recording in SIP. The requirement draft will >>>> be released shortly. >>>> >>>> We would like to request agenda time in dispatch to propose >>>> the formation of a new working group to define protocol >>>> extensions and an architecture for RTP recording. >>>> >>>> Session recording in SIP >>>> Mailing Lists: TBD >>>> Chairs: TBD >>>> Area Directorate: Real Time Applications (RAI) >>>> >>>> Purpose: >>>> >>>> Session recording is a critical operational requirement in >>>> many businesses, especially where voice is used as a medium >>>> for commerce and customer support. A prime example where >>>> voice is used for trade is the financial industry. The call >>>> recording requirements in this industry are quite stringent. >>>> The recorded calls are used for dispute resolution and >>>> regulatory compliance. Other businesses such as customer >>>> support call centers typically employ call recording for >>>> quality control or business analytics. >>>> >>>> Depending on the country and its regulatory requirements, >>>> financial trading floors typically must record all calls. The >>>> recorded media content must be an exact copy of the actual >>>> conversation (i.e. >>>> clipping and loss of media are unacceptable). Some >>>> deployments and regulations require that calls be aborted or >>>> rejected if the recording device is unavailable. >>>> >>>> This group will specify requirements for a SIP based protocol >>>> interface between a communications system and a recorder. The >>>> Communications System is responsible for establishing media >>>> sessions where the actual business is conducted. The Recorder >>>> is the sink of the recorded media. >>>> >>>> The recorded sessions can be of any kind such as voice, video >>>> and instant messaging. A recorded session is typically >>>> comprised of actual media content and the call metadata. The >>>> call metadata allows recording archives to be searched and >>>> filtered at a later time. >>>> The conveyance of call metadata from the communications >>>> system to the recorder is outside the scope of this document. >>>> >>>> This group will only looks into active recording, where the >>>> recorded system purposefully streams media to a recording >>>> device. Passive recording, where a recording device detects >>>> media directly from the network, is outside the scope of this >>>> document. In addition, lawful intercept is outside the scope >>>> of the group. >>>> >>>> Proposed deliverables: >>>> >>>> 1) Requirements document; >>>> 2) Solutions document, including reference architecture. >>>> >>>> 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/ >>>> _______________________________________________ >>>> 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 From tme@americafree.tv Thu Jun 11 08:46:27 2009 Return-Path: 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 BFAD63A6B37 for ; Thu, 11 Jun 2009 08:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.75 X-Spam-Level: X-Spam-Status: No, score=-2.75 tagged_above=-999 required=5 tests=[AWL=-0.151, 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 DqIimoCsV3LG for ; Thu, 11 Jun 2009 08:46:27 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id D96CF3A6ADC for ; Thu, 11 Jun 2009 08:46:26 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id A348A3FECCAC; Thu, 11 Jun 2009 11:46:33 -0400 (EDT) Message-Id: <28E397C5-A561-4F5D-86FB-BD033AE63435@americafree.tv> From: Marshall Eubanks To: Marshall Eubanks In-Reply-To: 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, 11 Jun 2009 11:46:32 -0400 References: <4A30A0E4.7010401@ericsson.com> X-Mailer: Apple Mail (2.935.3) Cc: DISPATCH Subject: Re: [dispatch] Wideband audio codec proposal dispatched as a regular BOF X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 15:46:27 -0000 On Jun 11, 2009, at 11:13 AM, Marshall Eubanks wrote: > > On Jun 11, 2009, at 2:15 AM, Gonzalo Camarillo wrote: > >> Folks, >> >> there have been significant list discussions on whether or not the >> IETF should be working on the topics proposed in the email below: >> >> http://www.ietf.org/mail-archive/web/dispatch/current/msg00080.html >> >> As a way forward, we have decided to organize the face-to-face >> discussions around this topic in Stockholm as a regular BOF (i.e., >> outside DISPATCH). We believe that, given the nature of the >> questions that need to be answered, this topic will benefit from >> discussions from a wide range of people. Organizing the meeting as >> a regular BOF ensures such discussions. A regular BOF also provides >> more time for discussions. >> >> Therefore, from now on, please use the following mailing list >> (instead of the DISPATCH list) for discussions on this topic: >> >> codec@ietf.org For those who are slow, like me, you can go to https://www.ietf.org/mailman/listinfo/codec to subscribe. Regards Marshall >> >> >> Thanks, >> >> Gonzalo >> DISPATCH co-chair >> _______________________________________________ >> 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 dwing@cisco.com Thu Jun 11 09:05:12 2009 Return-Path: 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 B52103A689D for ; Thu, 11 Jun 2009 09:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=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 oMJ+IsOc1CI5 for ; Thu, 11 Jun 2009 09:05:11 -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 2DDEC3A67FB for ; Thu, 11 Jun 2009 09:05:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,203,1243814400"; d="scan'208";a="174985913" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-2.cisco.com with ESMTP; 11 Jun 2009 16:05:18 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n5BG5HLj005348; Thu, 11 Jun 2009 12:05:17 -0400 Received: from dwingwxp01 ([10.32.240.194]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n5BG5HPt017317; Thu, 11 Jun 2009 16:05:17 GMT From: "Dan Wing" To: "'Henry Sinnreich'" , "'Shintaro Mizuno'" , "'Eric Burger'" References: <20090609220242.67b17e0a.mizuno.shintaro@lab.ntt.co.jp> Date: Thu, 11 Jun 2009 09:05:16 -0700 Message-ID: <0d0901c9eaae$69ef9d90$b2676b80@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcnpAppBUXNaqOQmRD6ckMyzzPNu8AABAuzwAGl6pCA= In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8967; t=1244736317; x=1245600317; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[dispatch]=20Charter=20Proposal |Sender:=20 |To:=20=22'Henry=20Sinnreich'=22=20,=0A =20=20=20=20=20=20=20=20=22'Shintaro=20Mizuno'=22=20,=0A=20=20=20=20=20=20=20=20=22'Eric= 20Burger'=22=20; bh=mO4zf4EsQG2Df8nmZiDIiyAZK4ML6Q9arPFe4wFCpAw=; b=k+W30Vup3wefABZtrF9Vx4JedqPtRU3jlTqBVND3UNw6HEMRmO/KLo8Inr eISdY5IC/vV7yTdbqjXNNSRNf9RQ8hPV05N5kGn5xD5lXzpgv49OD4+nk0ah +RCs8ZHzqf; Authentication-Results: rtp-dkim-2; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: dispatch@ietf.org Subject: Re: [dispatch] Charter Proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 16:05:12 -0000 > -----Original Message----- > From: dispatch-bounces@ietf.org > [mailto:dispatch-bounces@ietf.org] On Behalf Of Henry Sinnreich > Sent: Tuesday, June 09, 2009 6:32 AM > To: Shintaro Mizuno; Eric Burger > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Charter Proposal > > You may also want to consider HIP, since it solves NAT > traversal for all application layer protocols, including SIP. > > http://www.ietf.org/internet-drafts/draft-ietf-hip-nat-travers > al-07.txt Yes, I am aware of HIP's NAT traversal capabilities, as I encouraged its adoption of ICE methodologies. > It also takes care of the IPv4 to IPv6 transition for > endpoints, mobility and multi-homing. > Open source code is plentifully available for reference > implementations. > > http://www.ietf.org/html.charters/hip-charter.html There are always new protocols. But it is often pragmatic to leverage the investment of deployed protocols -- much like TCP which continues to evolve even though SCTP and DCCP provide superior functionality, much like how IPsec was originally intended for IPv6 but was then supported on IPv4, etc. We are interested in using SIP for establishing VPN sessions in much the same way that SIP has embraced TLS (RFC4572) and embraced file transfer (RFC5547). -d > Henry > > > > On 6/9/09 8:02 AM, "Shintaro Mizuno" > wrote: > > > > Mr. Burger, > Thank you for the comment. > > We don't necessary see a need for a WG to be formed to > document the > informational document we have listed, the document is > there to see if > the proposed way forward (informational document possibly > as an independent submission) for the document listed > is on track or > whether something should be done at the WG level. > > On the other hand, we believe that use of SIP similar > to what we > have done for VPN will likely to happen more. And on > that point, we are > wanting to see whether IETF is interested in > documenting a guideline > for dealing with application that's not voice or video. > As written in the discussion point of the charter, the > question is how > much should SIP be involved. > > 1. Should SIP just be used as a rendezvous protocol > and leave the > rest of the negotiation to whatever application? > 2. Should SIP involve in management of the established > session as it > does for audio/video? > 3. Should use of SIP not be standardized for peer to > peer application > beside audio/video? > > > Regards, > Shintaro > > > On Mon, 8 Jun 2009 06:38:20 -0400 > Eric Burger wrote: > > > Given the proposal is not really for an Internet > standard, and the > > product is not a protocol or standards track > document, why are we > > working on it here? > > > > On Jun 8, 2009, at 5:20 AM, Shintaro Mizuno wrote: > > > > > Dear DISPATCH Chair, ML members, > > > > > > I've finalized the charter proposal for on-demand > media/application > > > sharing. > > > Added milestone/deliverables section and some > descriptions on the > > > usage > > > of SIP, but most of the text remains the same. > > > > > > -------------------------------------------------- > > > "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. > > > > > > SIP/SDP will be used to negotiate parameters > necessary to establish > > > IKE/IPsec such as IP address, port numbers and > authentication > > > information of peers. Current deployment uses SIP > also to manage IPsec > > > connection, e.g. use BYE to shut down media > sessions for IKE/IPsec, > > > however, further discussions can be made to find > out if there are > > > intrests or use cases in using SIP only as a > rendezvous protocol. > > > > > > 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 be minor-updated to -05 to conform with this > charter proposal) > > > - 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. > > > > > > > > > Milestone/Deliverables: > > > - Aug 09 Issue Internet-Draft > > > (by updating "draft-saito-mmusic-sdp-ike-05") > > > - Nov 09 Submit I-D to IESG for publication as an > RFC (Informational) > > > > > > -------------------------------------------------- > > > Best Regards, > > > Shintaro > > > > > > ---------------------------------------- > > > Shintaro MIZUNO > > > mizuno.shintaro@lab.ntt.co.jp > > > > > > NTT Information Sharing Platform Laboratories > > > NTT Corporation > > > ---------------------------------------- > > > > > > _______________________________________________ > > > dispatch mailing list > > > dispatch@ietf.org > > > https://www.ietf.org/mailman/listinfo/dispatch > > > > > > > ---------------------------------------- > Shintaro MIZUNO > mizuno.shintaro@lab.ntt.co.jp > > NTT Information Sharing Platform Laboratories > NTT Corporation > ---------------------------------------- > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > > From HKaplan@acmepacket.com Thu Jun 11 11:42:42 2009 Return-Path: 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 10F5F28C1A4 for ; Thu, 11 Jun 2009 11:42:42 -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 Tkz+U+s45TAT for ; Thu, 11 Jun 2009 11:42:41 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 1BAF028C191 for ; Thu, 11 Jun 2009 11:42:41 -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; Thu, 11 Jun 2009 14:42:46 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 11 Jun 2009 14:42:46 -0400 From: Hadriel Kaplan To: Roni Even , "'Hutton, Andrew'" , 'Alan Johnston' , "'Romascanu, Dan (Dan)'" Date: Thu, 11 Jun 2009 14:42:45 -0400 Thread-Topic: [dispatch] Session recording in SIP Thread-Index: Acnp1EzxKUV301OIQi6sPyk1B+h+wgAEoFDQACL2tqAAAy7rEAAIIWwQAAG3/BAABwu0wA== Message-ID: References: <4A2ECDB2.7000601@alcatel-lucent.com> <4A2FB842.7050302@sipstation.com> <028a01c9ea12$5ec96e60$1c5c4b20$%roni@huawei.com> <719F9BBB3E7E71428A2D13F3D76C768F01C7BBE8@GBNTHT12009MSX.gb002.siemens.net> <002801c9ea82$0da51320$28ef3960$%roni@huawei.com> <719F9BBB3E7E71428A2D13F3D76C768F01C7BE97@GBNTHT12009MSX.gb002.siemens.net> <004a01c9eaa7$94ef7990$bece6cb0$%roni@huawei.com> In-Reply-To: <004a01c9eaa7$94ef7990$bece6cb0$%roni@huawei.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 Cc: 'Leon Portman' , "dispatch@ietf.org" , "'Jain, Rajnish'" Subject: Re: [dispatch] Session recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 18:42:42 -0000 > -----Original Message----- > From: Roni Even [mailto:Even.roni@huawei.com] > Sent: Thursday, June 11, 2009 11:16 AM >=20 > Andy, > You have a term called communication system in the proposal > Can you clarify what it is? Is this the end points in the call is this > some > type of a proxy, application aware middle box? Currently the proposed requirements would be to support a SIP UA be the com= munication system, i.e., the device which performs the replication from an = active UA-to-UA call to a remote recording system may be either a phone, ga= teway, or a B2BUA-type middlebox. Any SIP UA could logically perform that = role. I believe today some vendors do it in phones, others in middleboxes. =20 > There is also a recorder in the proposal, is this a SIP UA or is it just = a > RTP terminating device like a "media server" in which case this is simila= r > to mediactrl WG work Well, one possible solution to address the requirements would be to make th= e recorder in fact a SIP UA. (for example there is a requirement to possibl= y be able to inject media back into the real UA-to-UA session) I don't debate that it has obvious parallels with conferencing - I've even = argued to others that it's almost like a 3-party conf call, but where one o= r two of the parties don't know it - but it has some other requirements/nee= ds as well which really don't make it a traditional conference call scenari= o. -hadriel From jmpolk@cisco.com Thu Jun 11 12:15:12 2009 Return-Path: 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 7ACE13A6A98 for ; Thu, 11 Jun 2009 12:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.459 X-Spam-Level: X-Spam-Status: No, score=-6.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 deMAfbP5JXkD for ; Thu, 11 Jun 2009 12:15:11 -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 0E1673A6A37 for ; Thu, 11 Jun 2009 12:15:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,204,1243814400"; d="scan'208";a="175082997" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 11 Jun 2009 19:06:34 +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 n5BJ6YpI019703; Thu, 11 Jun 2009 12:06:34 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n5BJ6Y4b029262; Thu, 11 Jun 2009 19:06:34 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Jun 2009 12:06:34 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.1.94]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Jun 2009 12:06:33 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 11 Jun 2009 14:06:31 -0500 To: Hadriel Kaplan , Roni Even , "'Hutton, Andrew'" , "'Alan Johnston'" , "'Romascanu, Dan (Dan)'" From: "James M. Polk" In-Reply-To: References: <4A2ECDB2.7000601@alcatel-lucent.com> <4A2FB842.7050302@sipstation.com> <028a01c9ea12$5ec96e60$1c5c4b20$%roni@huawei.com> <719F9BBB3E7E71428A2D13F3D76C768F01C7BBE8@GBNTHT12009MSX.gb002.siemens.net> <002801c9ea82$0da51320$28ef3960$%roni@huawei.com> <719F9BBB3E7E71428A2D13F3D76C768F01C7BE97@GBNTHT12009MSX.gb002.siemens.net> <004a01c9eaa7$94ef7990$bece6cb0$%roni@huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 11 Jun 2009 19:06:33.0114 (UTC) FILETIME=[BC0D27A0:01C9EAC7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=467; t=1244747194; x=1245611194; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[dispatch]=20Session=20recording=20in=2 0SIP |Sender:=20; bh=/Qq30Qri7hoKGelqbVcCe3Ktq6d7gSxtqkxllq4om7k=; b=IWxWrXxXkvUCLWVH2GNnGig498htbVm9sJyNYpLhGdIxH+4BmY65JIRCwo ryRVs1/DrtpSoLIjifjOlwym9z4ssJ7YRvXRxjn/bK1WEN7yn304kVFf7pw3 iM4++myK1H; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: 'Leon Portman' , "dispatch@ietf.org" , "'Jain, Rajnish'" Subject: Re: [dispatch] Session recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 19:15:12 -0000 At 01:42 PM 6/11/2009, Hadriel Kaplan wrote: >I don't debate that it has obvious parallels with conferencing - >I've even argued to others that it's almost like a 3-party conf >call, but where one or two of the parties don't know it - Hadriel -- this is how I mostly see it also, at least as a foundation to work from. >but it has some other requirements/needs as well which really don't >make it a traditional conference call scenario. > >-hadriel From Even.roni@huawei.com Thu Jun 11 12:55:31 2009 Return-Path: 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 5BAE73A6A87 for ; Thu, 11 Jun 2009 12:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.454 X-Spam-Level: X-Spam-Status: No, score=-0.454 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8ipyypdptf8 for ; Thu, 11 Jun 2009 12:55:30 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 666603A6B2E for ; Thu, 11 Jun 2009 12:55:30 -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 <0KL30078JBCFQU@szxga03-in.huawei.com> for dispatch@ietf.org; Fri, 12 Jun 2009 03:55:27 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KL300MRVBCFJI@szxga03-in.huawei.com> for dispatch@ietf.org; Fri, 12 Jun 2009 03:55:27 +0800 (CST) Received: from windows8d787f9 (bzq-79-177-76-15.red.bezeqint.net [79.177.76.15]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KL300LIFBC9Q4@szxml01-in.huawei.com>; Fri, 12 Jun 2009 03:55:27 +0800 (CST) Date: Thu, 11 Jun 2009 22:53:46 +0300 From: Roni Even In-reply-to: To: 'Hadriel Kaplan' , "'Hutton, Andrew'" , 'Alan Johnston' , "'Romascanu, Dan (Dan)'" Message-id: <00ab01c9eace$58b7c190$0a2744b0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: Acnp1EzxKUV301OIQi6sPyk1B+h+wgAEoFDQACL2tqAAAy7rEAAIIWwQAAG3/BAABwu0wAACY0NA References: <4A2ECDB2.7000601@alcatel-lucent.com> <4A2FB842.7050302@sipstation.com> <028a01c9ea12$5ec96e60$1c5c4b20$%roni@huawei.com> <719F9BBB3E7E71428A2D13F3D76C768F01C7BBE8@GBNTHT12009MSX.gb002.siemens.net> <002801c9ea82$0da51320$28ef3960$%roni@huawei.com> <719F9BBB3E7E71428A2D13F3D76C768F01C7BE97@GBNTHT12009MSX.gb002.siemens.net> <004a01c9eaa7$94ef7990$bece6cb0$%roni@huawei.com> Cc: 'Leon Portman' , dispatch@ietf.org, "'Jain, Rajnish'" Subject: Re: [dispatch] Session recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 19:55:31 -0000 Hadriel, I am still confused by the following text which was the reason for the previous question "This group will specify requirements for a SIP based protocol interface between a communications system and a recorder. The Communications System is responsible for establishing media sessions where the actual business is conducted. The Recorder is the sink of the recorded media." Can someone draw a figure showing the talking parties the Communication system and the recorder and explain where is this interface. According to your response I can think that there are at least two separate architectures your are proposing one where the parties (or one of them) in the call know the recorder and somehow forwards the media to it. The other architecture has some B2BUA in the call path who is either forking the media to the recorder and to the parties or the recorder is in the middle of the media path. My humble opinion is that a preferred solution will use a B2BUA in the call path who will initiate the recording and this is why I was looking at XCON or MEDIACTRL work in order to not develop a new protocol but leverage existing ones. Thanks Roni -----Original Message----- From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Sent: Thursday, June 11, 2009 9:43 PM To: Roni Even; 'Hutton, Andrew'; 'Alan Johnston'; 'Romascanu, Dan (Dan)' Cc: 'Leon Portman'; dispatch@ietf.org; 'Jain, Rajnish' Subject: RE: [dispatch] Session recording in SIP > -----Original Message----- > From: Roni Even [mailto:Even.roni@huawei.com] > Sent: Thursday, June 11, 2009 11:16 AM > > Andy, > You have a term called communication system in the proposal > Can you clarify what it is? Is this the end points in the call is this > some > type of a proxy, application aware middle box? Currently the proposed requirements would be to support a SIP UA be the communication system, i.e., the device which performs the replication from an active UA-to-UA call to a remote recording system may be either a phone, gateway, or a B2BUA-type middlebox. Any SIP UA could logically perform that role. I believe today some vendors do it in phones, others in middleboxes. > There is also a recorder in the proposal, is this a SIP UA or is it just a > RTP terminating device like a "media server" in which case this is similar > to mediactrl WG work Well, one possible solution to address the requirements would be to make the recorder in fact a SIP UA. (for example there is a requirement to possibly be able to inject media back into the real UA-to-UA session) I don't debate that it has obvious parallels with conferencing - I've even argued to others that it's almost like a 3-party conf call, but where one or two of the parties don't know it - but it has some other requirements/needs as well which really don't make it a traditional conference call scenario. -hadriel From HKaplan@acmepacket.com Thu Jun 11 15:51:24 2009 Return-Path: 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 B58723A6E0C for ; Thu, 11 Jun 2009 15:51:24 -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 oxz3tt3JHppR for ; Thu, 11 Jun 2009 15:51:23 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id B02613A6E0B for ; Thu, 11 Jun 2009 15:51:23 -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; Thu, 11 Jun 2009 18:51:29 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 11 Jun 2009 18:51:30 -0400 From: Hadriel Kaplan To: Roni Even , "'Hutton, Andrew'" , 'Alan Johnston' , "'Romascanu, Dan (Dan)'" Date: Thu, 11 Jun 2009 18:51:28 -0400 Thread-Topic: [dispatch] Session recording in SIP Thread-Index: Acnp1EzxKUV301OIQi6sPyk1B+h+wgAEoFDQACL2tqAAAy7rEAAIIWwQAAG3/BAABwu0wAACY0NAAAXw2JA= Message-ID: References: <4A2ECDB2.7000601@alcatel-lucent.com> <4A2FB842.7050302@sipstation.com> <028a01c9ea12$5ec96e60$1c5c4b20$%roni@huawei.com> <719F9BBB3E7E71428A2D13F3D76C768F01C7BBE8@GBNTHT12009MSX.gb002.siemens.net> <002801c9ea82$0da51320$28ef3960$%roni@huawei.com> <719F9BBB3E7E71428A2D13F3D76C768F01C7BE97@GBNTHT12009MSX.gb002.siemens.net> <004a01c9eaa7$94ef7990$bece6cb0$%roni@huawei.com> <00ab01c9eace$58b7c190$0a2744b0$%roni@huawei.com> In-Reply-To: <00ab01c9eace$58b7c190$0a2744b0$%roni@huawei.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 Cc: 'Leon Portman' , "dispatch@ietf.org" , "'Jain, Rajnish'" Subject: Re: [dispatch] Session recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 22:51:24 -0000 Hey Roni, Being a middlebox man myself, a B2BUA doing the media forking makes the mos= t sense to me too, but some other folks don't do it/want-it that way. So t= he proposed work is to cover both potential models. The statement you cite reflects the belief that the solution to the require= ments will be to use SIP between the UA doing the media forking, and the re= corder doing the collection; and that the work of specification will be to = define that. So one diagram could be this, where "TBD" is the To-Be-Defined work: +-----+ +-----+ | | Call | | |UA-A +<------------>+UA-B | | | | | +-++--+ +-----+ \\ \\ TBD \\ \\+----------+ \+ | + Recorder | | | +----------+ Or this: +-----+ +-----+ +-----+ | | Call | | Call | | |UA-A +<------------>+B2BUA+<------------>+UA-B | | | | | | | +-----+ +-++--+ +-----+ \\ \\ TBD \\ \\+----------+ \+ | + Recorder | | | +----------+ -hadriel > -----Original Message----- > From: Roni Even [mailto:Even.roni@huawei.com] > Sent: Thursday, June 11, 2009 3:54 PM > To: Hadriel Kaplan; 'Hutton, Andrew'; 'Alan Johnston'; 'Romascanu, Dan > (Dan)' > Cc: 'Leon Portman'; dispatch@ietf.org; 'Jain, Rajnish' > Subject: RE: [dispatch] Session recording in SIP >=20 > Hadriel, > I am still confused by the following text which was the reason for the > previous question >=20 > "This group will specify requirements for a SIP based protocol interface > between a communications system and a recorder. The Communications System > is > responsible for establishing media sessions where the actual business is > conducted. The Recorder is the sink of the recorded media." >=20 >=20 > Can someone draw a figure showing the talking parties the Communication > system and the recorder and explain where is this interface. According to > your response I can think that there are at least two separate > architectures > your are proposing one where the parties (or one of them) in the call kno= w > the recorder and somehow forwards the media to it. The other architecture > has some B2BUA in the call path who is either forking the media to the > recorder and to the parties or the recorder is in the middle of the media > path. >=20 From pkyzivat@cisco.com Thu Jun 11 16:11:18 2009 Return-Path: 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 5C96D3A6E0B for ; Thu, 11 Jun 2009 16:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 JOFlQkqRNPQc for ; Thu, 11 Jun 2009 16:11:17 -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 E9E913A6B18 for ; Thu, 11 Jun 2009 16:11:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,204,1243814400"; d="scan'208";a="47011988" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 11 Jun 2009 23:11:24 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n5BNBOo5004043; Thu, 11 Jun 2009 19:11:24 -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 n5BNBNDG000832; Thu, 11 Jun 2009 23:11:23 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.3959); Thu, 11 Jun 2009 19:11:23 -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); Thu, 11 Jun 2009 19:11:23 -0400 Message-ID: <4A318F1E.9080308@cisco.com> Date: Thu, 11 Jun 2009 19:11:26 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Hadriel Kaplan References: <4A2ECDB2.7000601@alcatel-lucent.com> <4A2FB842.7050302@sipstation.com> <028a01c9ea12$5ec96e60$1c5c4b20$%roni@huawei.com> <719F9BBB3E7E71428A2D13F3D76C768F01C7BBE8@GBNTHT12009MSX.gb002.siemens.net> <002801c9ea82$0da51320$28ef3960$%roni@huawei.com> <719F9BBB3E7E71428A2D13F3D76C768F01C7BE97@GBNTHT12009MSX.gb002.siemens.net> <004a01c9eaa7$94ef7990$bece6cb0$%roni@huawei.com> <00ab01c9eace$58b7c190$0a2744b0$%roni@huawei.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jun 2009 23:11:23.0451 (UTC) FILETIME=[F02CB0B0:01C9EAE9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3924; t=1244761884; x=1245625884; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[dispatch]=20Session=20recording=20in=2 0SIP |Sender:=20 |To:=20Hadriel=20Kaplan=20; bh=Lt8sgRpwFHhOtVSK1gGdts2Zr1kKGXqAaTmS109rCG4=; b=pyUun9WN6DLzyB2IFmJ3nA7W1NL4rYoAQ+jftxhO0Ky2OVVcggoYRSN3YN oKtwBAFyzx8EMTCLLOyDsf7zvbi3UDgSBgRu0W0sk650CuEvyAUvs9R+fLhH hkLL1im6X4; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: 'Leon Portman' , "dispatch@ietf.org" , "'Jain, Rajnish'" , Roni Even Subject: Re: [dispatch] Session recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 23:11:18 -0000 Hadriel Kaplan wrote: > Hey Roni, > Being a middlebox man myself, a B2BUA doing the media forking makes the most sense to me too, but some other folks don't do it/want-it that way. So the proposed work is to cover both potential models. > > The statement you cite reflects the belief that the solution to the requirements will be to use SIP between the UA doing the media forking, and the recorder doing the collection; and that the work of specification will be to define that. > > So one diagram could be this, where "TBD" is the To-Be-Defined work: > > +-----+ +-----+ > | | Call | | > |UA-A +<------------>+UA-B | > | | | | > +-++--+ +-----+ > \\ > \\ > TBD \\ > \\+----------+ > \+ | > + Recorder | > | | > +----------+ This model actually can make a lot of sense in *some* circumstances. For instance, in a call center, where you may have control over what components are used throughout, it could make sense to do the media forking for recording and monitoring right at the agent phone. But in those sorts of monitoring/recording we don't talk about in IETF, its essential that the recorded parties not be able to distinguish calls that are monitored from those that are not. Anything that requires cooperation by one of the endpoints is a no-go. Even something as simple as a middlebox replacing one media port with another in order to initiate monitoring might be enough to clue in the monitored parties. So in those cases you had better have a way that looks exactly the same whether recording is happening or not, which generally requires something like your picture below. Thanks, Paul > Or this: > > > > +-----+ +-----+ +-----+ > | | Call | | Call | | > |UA-A +<------------>+B2BUA+<------------>+UA-B | > | | | | | | > +-----+ +-++--+ +-----+ > \\ > \\ > TBD \\ > \\+----------+ > \+ | > + Recorder | > | | > +----------+ > > -hadriel > >> -----Original Message----- >> From: Roni Even [mailto:Even.roni@huawei.com] >> Sent: Thursday, June 11, 2009 3:54 PM >> To: Hadriel Kaplan; 'Hutton, Andrew'; 'Alan Johnston'; 'Romascanu, Dan >> (Dan)' >> Cc: 'Leon Portman'; dispatch@ietf.org; 'Jain, Rajnish' >> Subject: RE: [dispatch] Session recording in SIP >> >> Hadriel, >> I am still confused by the following text which was the reason for the >> previous question >> >> "This group will specify requirements for a SIP based protocol interface >> between a communications system and a recorder. The Communications System >> is >> responsible for establishing media sessions where the actual business is >> conducted. The Recorder is the sink of the recorded media." >> >> >> Can someone draw a figure showing the talking parties the Communication >> system and the recorder and explain where is this interface. According to >> your response I can think that there are at least two separate >> architectures >> your are proposing one where the parties (or one of them) in the call know >> the recorder and somehow forwards the media to it. The other architecture >> has some B2BUA in the call path who is either forking the media to the >> recorder and to the parties or the recorder is in the middle of the media >> path. >> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From jmpolk@cisco.com Thu Jun 11 19:13:05 2009 Return-Path: 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 03AA33A6CFC for ; Thu, 11 Jun 2009 19:13:05 -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 kOse5sI5AWlf for ; Thu, 11 Jun 2009 19:13:03 -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 D8BAF3A6CD1 for ; Thu, 11 Jun 2009 19:13:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,205,1243814400"; d="scan'208";a="175477661" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 12 Jun 2009 02:13:10 +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 n5C2DAuJ003583; Thu, 11 Jun 2009 19:13:10 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n5C2DAJu027283; Fri, 12 Jun 2009 02:13:10 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Jun 2009 19:13:10 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.1.94]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Jun 2009 19:13:09 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 11 Jun 2009 21:13:08 -0500 To: Paul Kyzivat , Hadriel Kaplan From: "James M. Polk" In-Reply-To: <4A318F1E.9080308@cisco.com> References: <4A2ECDB2.7000601@alcatel-lucent.com> <4A2FB842.7050302@sipstation.com> <028a01c9ea12$5ec96e60$1c5c4b20$%roni@huawei.com> <719F9BBB3E7E71428A2D13F3D76C768F01C7BBE8@GBNTHT12009MSX.gb002.siemens.net> <002801c9ea82$0da51320$28ef3960$%roni@huawei.com> <719F9BBB3E7E71428A2D13F3D76C768F01C7BE97@GBNTHT12009MSX.gb002.siemens.net> <004a01c9eaa7$94ef7990$bece6cb0$%roni@huawei.com> <00ab01c9eace$58b7c190$0a2744b0$%roni@huawei.com> <4A318F1E.9080308@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 12 Jun 2009 02:13:09.0919 (UTC) FILETIME=[54EFA2F0:01C9EB03] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5262; t=1244772790; x=1245636790; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[dispatch]=20Session=20recording=20in=2 0SIP |Sender:=20; bh=+h20lw7oyq7OdMPc3apwdbnegsI6m+EzeN/1AzAZq/8=; b=tKMCLtBG1mjzgECY+FgF1KtlLYVFWOQERW4Vc68dGJ8ZbNSmCcLehQHs8D qOLajs6GYD74DFc0dPPCu0dTNMbUKpUoRRUxaTgMXiAotYA7aec1p7DW4e3x bGEadSXaxs; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: 'Leon Portman' , "dispatch@ietf.org" , "'Jain, Rajnish'" , Roni Even Subject: Re: [dispatch] Session recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 02:13:05 -0000 At 06:11 PM 6/11/2009, Paul Kyzivat wrote: >Hadriel Kaplan wrote: >>Hey Roni, >>Being a middlebox man myself, a B2BUA doing the media forking makes >>the most sense to me too, but some other folks don't do it/want-it >>that way. So the proposed work is to cover both potential models. >>The statement you cite reflects the belief that the solution to the >>requirements will be to use SIP between the UA doing the media >>forking, and the recorder doing the collection; and that the work >>of specification will be to define that. >>So one diagram could be this, where "TBD" is the To-Be-Defined work: >> +-----+ +-----+ >> | | Call | | >> |UA-A +<------------>+UA-B | >> | | | | >> +-++--+ +-----+ >> \\ >> \\ >> TBD \\ >> \\+----------+ >> \+ | >> + Recorder | >> | | >> +----------+ > >This model actually can make a lot of sense in *some* circumstances. >For instance, in a call center, where you may have control over what >components are used throughout, it could make sense to do the media >forking for recording and monitoring right at the agent phone. Paul - how is your call center example *not* better accomplished with the figure below instead of the figure above? It seems to me that any enterprise based call center would have to have a SIP server of some form (i.e., the caller is not going to have a pt-to-pt SIP established session directly with a call center call taker). It seems much easier if that call center wants to record calls (even some of the calls, that to the caller, the B2BUA is the UAS, meaning the sRTP keys only have to be between the caller and the B2BUA, and not all the way to the call taker. In this scenario, the B2BUA merely replicates the RTP stream out towards the recording device with RTCP in tact, an can allow the B2BUA provide any meta data about the specifics of the call signaling it wants to also store. This scenario also means the caller is never aware the call is being recorded, creating anonymity wrt that facet of the solution. I'm not advocating B2BUAs here, I just see this as a better solution for call center type recording than pt-to-pt between caller and call taker. >But in those sorts of monitoring/recording we don't talk about in >IETF, its essential that the recorded parties not be able to >distinguish calls that are monitored from those that are not. >Anything that requires cooperation by one of the endpoints is a >no-go. Even something as simple as a middlebox replacing one media >port with another in order to initiate monitoring might be enough to >clue in the monitored parties. So in those cases you had better >have a way that looks exactly the same whether recording is >happening or not, which generally requires something like your picture below. > > Thanks, > Paul > >>Or this: >> >>+-----+ +-----+ +-----+ >>| | Call | | Call | | >>|UA-A +<------------>+B2BUA+<------------>+UA-B | >>| | | | | | >>+-----+ +-++--+ +-----+ >> \\ >> \\ >> TBD \\ >> \\+----------+ >> \+ | >> + Recorder | >> | | >> +----------+ >>-hadriel >> >>>-----Original Message----- >>>From: Roni Even [mailto:Even.roni@huawei.com] >>>Sent: Thursday, June 11, 2009 3:54 PM >>>To: Hadriel Kaplan; 'Hutton, Andrew'; 'Alan Johnston'; 'Romascanu, Dan >>>(Dan)' >>>Cc: 'Leon Portman'; dispatch@ietf.org; 'Jain, Rajnish' >>>Subject: RE: [dispatch] Session recording in SIP >>> >>>Hadriel, >>>I am still confused by the following text which was the reason for the >>>previous question >>> >>>"This group will specify requirements for a SIP based protocol interface >>>between a communications system and a recorder. The Communications System >>>is >>>responsible for establishing media sessions where the actual business is >>>conducted. The Recorder is the sink of the recorded media." >>> >>> >>>Can someone draw a figure showing the talking parties the Communication >>>system and the recorder and explain where is this interface. According to >>>your response I can think that there are at least two separate >>>architectures >>>your are proposing one where the parties (or one of them) in the call know >>>the recorder and somehow forwards the media to it. The other architecture >>>has some B2BUA in the call path who is either forking the media to the >>>recorder and to the parties or the recorder is in the middle of the media >>>path. >>_______________________________________________ >>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 alan@sipstation.com Thu Jun 11 20:39:17 2009 Return-Path: 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 7F05E3A6ABC for ; Thu, 11 Jun 2009 20:39:17 -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 Xll5xzzIvuxm for ; Thu, 11 Jun 2009 20:39:16 -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 3DEE63A68A8 for ; Thu, 11 Jun 2009 20:39:16 -0700 (PDT) Received: from 24-107-193-18.dhcp.stls.mo.charter.com ([24.107.193.18] helo=aidan-DS.sipserver.homeip.net) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1MExbs-0000yp-1G; Fri, 12 Jun 2009 03:39:20 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.107.193.18 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+MyDvxZQ2yDQckTlN8pcpFlp//rtmLPPw= Message-ID: <4A31CDE2.7080208@sipstation.com> Date: Thu, 11 Jun 2009 22:39:14 -0500 From: Alan Johnston User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "James M. Polk" References: <4A2ECDB2.7000601@alcatel-lucent.com> <4A2FB842.7050302@sipstation.com> <028a01c9ea12$5ec96e60$1c5c4b20$%roni@huawei.com> <719F9BBB3E7E71428A2D13F3D76C768F01C7BBE8@GBNTHT12009MSX.gb002.siemens.net> <002801c9ea82$0da51320$28ef3960$%roni@huawei.com> <719F9BBB3E7E71428A2D13F3D76C768F01C7BE97@GBNTHT12009MSX.gb002.siemens.net> <004a01c9eaa7$94ef7990$bece6cb0$%roni@huawei.com> <00ab01c9eace$58b7c190$0a2744b0$%roni@huawei.com> <4A318F1E.9080308@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'Leon Portman' , "dispatch@ietf.org" , "'Jain, Rajnish'" , Roni Even , Hadriel Kaplan Subject: Re: [dispatch] Session recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 03:39:17 -0000 These various models and modes of recording are described in http://tools.ietf.org/html/draft-wing-sipping-srtp-key-04#section-5 To summarize some of the arguments for forking the media in the middle as opposed to doing it in an endpoint: 1. Requirements to use basic UAs without any extensions 2. Not always having double the media bandwidth in endpoints, especially when they are remote 3. The recording mode (always on, on demand, required, pause and resume) and policy is usually controlled centrally, and so another protocol would be needed to tell the UA to start and stop recording. Thanks, Alan James M. Polk wrote: > At 06:11 PM 6/11/2009, Paul Kyzivat wrote: > > >> Hadriel Kaplan wrote: >>> Hey Roni, >>> Being a middlebox man myself, a B2BUA doing the media forking makes >>> the most sense to me too, but some other folks don't do it/want-it >>> that way. So the proposed work is to cover both potential models. >>> The statement you cite reflects the belief that the solution to the >>> requirements will be to use SIP between the UA doing the media >>> forking, and the recorder doing the collection; and that the work of >>> specification will be to define that. >>> So one diagram could be this, where "TBD" is the To-Be-Defined work: >>> +-----+ +-----+ >>> | | Call | | >>> |UA-A +<------------>+UA-B | >>> | | | | >>> +-++--+ +-----+ >>> \\ >>> \\ >>> TBD \\ >>> \\+----------+ >>> \+ | >>> + Recorder | >>> | | >>> +----------+ >> >> This model actually can make a lot of sense in *some* circumstances. >> For instance, in a call center, where you may have control over what >> components are used throughout, it could make sense to do the media >> forking for recording and monitoring right at the agent phone. > > Paul - how is your call center example *not* better accomplished with > the figure below instead of the figure above? > > It seems to me that any enterprise based call center would have to > have a SIP server of some form (i.e., the caller is not going to have > a pt-to-pt SIP established session directly with a call center call > taker). It seems much easier if that call center wants to record calls > (even some of the calls, that to the caller, the B2BUA is the UAS, > meaning the sRTP keys only have to be between the caller and the > B2BUA, and not all the way to the call taker. In this scenario, the > B2BUA merely replicates the RTP stream out towards the recording > device with RTCP in tact, an can allow the B2BUA provide any meta data > about the specifics of the call signaling it wants to also store. > > This scenario also means the caller is never aware the call is being > recorded, creating anonymity wrt that facet of the solution. > > I'm not advocating B2BUAs here, I just see this as a better solution > for call center type recording than pt-to-pt between caller and call > taker. > > >> But in those sorts of monitoring/recording we don't talk about in >> IETF, its essential that the recorded parties not be able to >> distinguish calls that are monitored from those that are not. >> Anything that requires cooperation by one of the endpoints is a >> no-go. Even something as simple as a middlebox replacing one media >> port with another in order to initiate monitoring might be enough to >> clue in the monitored parties. So in those cases you had better have >> a way that looks exactly the same whether recording is happening or >> not, which generally requires something like your picture below. >> >> Thanks, >> Paul >> >>> Or this: >>> >>> +-----+ +-----+ +-----+ >>> | | Call | | Call | | >>> |UA-A +<------------>+B2BUA+<------------>+UA-B | >>> | | | | | | >>> +-----+ +-++--+ +-----+ >>> \\ >>> \\ >>> TBD \\ >>> \\+----------+ >>> \+ | >>> + Recorder | >>> | | >>> +----------+ >>> -hadriel >>> >>>> -----Original Message----- >>>> From: Roni Even [mailto:Even.roni@huawei.com] >>>> Sent: Thursday, June 11, 2009 3:54 PM >>>> To: Hadriel Kaplan; 'Hutton, Andrew'; 'Alan Johnston'; 'Romascanu, Dan >>>> (Dan)' >>>> Cc: 'Leon Portman'; dispatch@ietf.org; 'Jain, Rajnish' >>>> Subject: RE: [dispatch] Session recording in SIP >>>> >>>> Hadriel, >>>> I am still confused by the following text which was the reason for the >>>> previous question >>>> >>>> "This group will specify requirements for a SIP based protocol >>>> interface >>>> between a communications system and a recorder. The Communications >>>> System >>>> is >>>> responsible for establishing media sessions where the actual >>>> business is >>>> conducted. The Recorder is the sink of the recorded media." >>>> >>>> >>>> Can someone draw a figure showing the talking parties the >>>> Communication >>>> system and the recorder and explain where is this interface. >>>> According to >>>> your response I can think that there are at least two separate >>>> architectures >>>> your are proposing one where the parties (or one of them) in the >>>> call know >>>> the recorder and somehow forwards the media to it. The other >>>> architecture >>>> has some B2BUA in the call path who is either forking the media to the >>>> recorder and to the parties or the recorder is in the middle of the >>>> media >>>> path. >>> _______________________________________________ >>> 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 AUDET@nortel.com Thu Jun 11 20:42:51 2009 Return-Path: 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 4FF023A6AC1 for ; Thu, 11 Jun 2009 20:42: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 eAoVTrphkdrW for ; Thu, 11 Jun 2009 20:42:50 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id C843F3A68A8 for ; Thu, 11 Jun 2009 20:42:49 -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 n5C3gnB13204; Fri, 12 Jun 2009 03:42:50 GMT Received: from 47.102.153.21 ([47.102.153.21]) by zrc2hxm0.corp.nortel.com ([47.103.123.71]) with Microsoft Exchange Server HTTP-DAV ; Fri, 12 Jun 2009 03:42:34 +0000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Thu, 11 Jun 2009 20:42:31 -0700 From: "Francois Audet" To: "James M. Polk" , Paul Kyzivat , Hadriel Kaplan Message-ID: Thread-Topic: [dispatch] Session recording in SIP Thread-Index: AcnrD9BjXrOnCAToRe+3AbjNNYbITQ== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: 'Leon Portman' , "dispatch@ietf.org" , "'Jain, Rajnish'" , Roni Even Subject: Re: [dispatch] Session recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 03:42:51 -0000 I agree with James. There are *some* scenarios where the UA-initiated recording will work, but they are very limited. They have the following disadvantages: 1- It makes the client "aware" that it is being recorded 2- It makes it very easy to avoid being recorded by interrupting the media stream 3 - It makes it much easier to "dispute" (i.e., lawyers) the authenticity of a recorded conversation if there is potential for significant differences in the streams as seen by different ends 4 - It doubles the bandwidth requirements on the UA, which can be a problem in some scenarios 5 - It doubles the processing power required in the client (think SRTP/key negotiation & al). This can be a problem with many phones. 6 - They require phones that actually support this. Which means, you can't use "normal" SIP phones. Which means, if you get the $30 phone, you don't get tapped into, but if you get the $300 phone, you don't. But UA-initiated recording has very few advantages: 1 - Less work on servers. This is actually a big advantage because lots of servers are so complex, it is difficult to do anything new on them. 2 - Looks much more abstract and cool in an IETF RFC :-) On Jun11 2009 19:13 , "James M. Polk" wrote: > At 06:11 PM 6/11/2009, Paul Kyzivat wrote: > > >> Hadriel Kaplan wrote: >>> Hey Roni, >>> Being a middlebox man myself, a B2BUA doing the media forking makes >>> the most sense to me too, but some other folks don't do it/want-it >>> that way. So the proposed work is to cover both potential models. >>> The statement you cite reflects the belief that the solution to the >>> requirements will be to use SIP between the UA doing the media >>> forking, and the recorder doing the collection; and that the work >>> of specification will be to define that. >>> So one diagram could be this, where "TBD" is the To-Be-Defined work: >>> +-----+ +-----+ >>> | | Call | | >>> |UA-A +<------------>+UA-B | >>> | | | | >>> +-++--+ +-----+ >>> \\ >>> \\ >>> TBD \\ >>> \\+----------+ >>> \+ | >>> + Recorder | >>> | | >>> +----------+ >> >> This model actually can make a lot of sense in *some* circumstances. >> For instance, in a call center, where you may have control over what >> components are used throughout, it could make sense to do the media >> forking for recording and monitoring right at the agent phone. > > Paul - how is your call center example *not* better accomplished with > the figure below instead of the figure above? > > It seems to me that any enterprise based call center would have to > have a SIP server of some form (i.e., the caller is not going to have > a pt-to-pt SIP established session directly with a call center call > taker). It seems much easier if that call center wants to record > calls (even some of the calls, that to the caller, the B2BUA is the > UAS, meaning the sRTP keys only have to be between the caller and the > B2BUA, and not all the way to the call taker. In this scenario, the > B2BUA merely replicates the RTP stream out towards the recording > device with RTCP in tact, an can allow the B2BUA provide any meta > data about the specifics of the call signaling it wants to also store. > > This scenario also means the caller is never aware the call is being > recorded, creating anonymity wrt that facet of the solution. > > I'm not advocating B2BUAs here, I just see this as a better solution > for call center type recording than pt-to-pt between caller and call taker. > > >> But in those sorts of monitoring/recording we don't talk about in >> IETF, its essential that the recorded parties not be able to >> distinguish calls that are monitored from those that are not. >> Anything that requires cooperation by one of the endpoints is a >> no-go. Even something as simple as a middlebox replacing one media >> port with another in order to initiate monitoring might be enough to >> clue in the monitored parties. So in those cases you had better >> have a way that looks exactly the same whether recording is >> happening or not, which generally requires something like your picture below. >> >> Thanks, >> Paul >> >>> Or this: >>> >>> +-----+ +-----+ +-----+ >>> | | Call | | Call | | >>> |UA-A +<------------>+B2BUA+<------------>+UA-B | >>> | | | | | | >>> +-----+ +-++--+ +-----+ >>> \\ >>> \\ >>> TBD \\ >>> \\+----------+ >>> \+ | >>> + Recorder | >>> | | >>> +----------+ >>> -hadriel >>> >>>> -----Original Message----- >>>> From: Roni Even [mailto:Even.roni@huawei.com] >>>> Sent: Thursday, June 11, 2009 3:54 PM >>>> To: Hadriel Kaplan; 'Hutton, Andrew'; 'Alan Johnston'; 'Romascanu, Dan >>>> (Dan)' >>>> Cc: 'Leon Portman'; dispatch@ietf.org; 'Jain, Rajnish' >>>> Subject: RE: [dispatch] Session recording in SIP >>>> >>>> Hadriel, >>>> I am still confused by the following text which was the reason for the >>>> previous question >>>> >>>> "This group will specify requirements for a SIP based protocol interface >>>> between a communications system and a recorder. The Communications System >>>> is >>>> responsible for establishing media sessions where the actual business is >>>> conducted. The Recorder is the sink of the recorded media." >>>> >>>> >>>> Can someone draw a figure showing the talking parties the Communication >>>> system and the recorder and explain where is this interface. According to >>>> your response I can think that there are at least two separate >>>> architectures >>>> your are proposing one where the parties (or one of them) in the call know >>>> the recorder and somehow forwards the media to it. The other architecture >>>> has some B2BUA in the call path who is either forking the media to the >>>> recorder and to the parties or the recorder is in the middle of the media >>>> path. >>> _______________________________________________ >>> 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 HKaplan@acmepacket.com Thu Jun 11 20:55:11 2009 Return-Path: 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 80C913A6C68 for ; Thu, 11 Jun 2009 20:55:11 -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 UoQRyBO8JVaZ for ; Thu, 11 Jun 2009 20:55:10 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id ACE683A6C49 for ; Thu, 11 Jun 2009 20:55:10 -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; Thu, 11 Jun 2009 23:55:17 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 11 Jun 2009 23:55:17 -0400 From: Hadriel Kaplan To: Francois Audet , "James M. Polk" , Paul Kyzivat Date: Thu, 11 Jun 2009 23:54:26 -0400 Thread-Topic: [dispatch] Session recording in SIP Thread-Index: AcnrD9BjXrOnCAToRe+3AbjNNYbITQAAG7kg Message-ID: References: In-Reply-To: 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 Cc: 'Leon Portman' , "dispatch@ietf.org" , "'Jain, Rajnish'" , Roni Even Subject: Re: [dispatch] Session recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 03:55:11 -0000 Sure there are advantages/disadvantages to each model, but why bother argui= ng over it? I think we probably all agree we need to support at least a B2= BUA model, so once you have to standardize that doesn't the UA model come f= or virtually free? (i.e., I would presume the details of a B2BUA model are= either a superset or the same as a single UA model, not less) -hadriel From jmpolk@cisco.com Thu Jun 11 22:05:29 2009 Return-Path: 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 ABB753A6A71 for ; Thu, 11 Jun 2009 22:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.498 X-Spam-Level: X-Spam-Status: No, score=-6.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 TdvDot2Yb1yI for ; Thu, 11 Jun 2009 22:05:28 -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 5CB613A6938 for ; Thu, 11 Jun 2009 22:05:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,207,1243814400"; d="scan'208";a="198846263" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 12 Jun 2009 05:05:36 +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 n5C55adA025458; Thu, 11 Jun 2009 22:05:36 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n5C55aWG013000; Fri, 12 Jun 2009 05:05:36 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Jun 2009 22:05:36 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.1.94]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Jun 2009 22:05:35 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 12 Jun 2009 00:05:34 -0500 To: Hadriel Kaplan , Francois Audet , Paul Kyzivat From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 12 Jun 2009 05:05:35.0631 (UTC) FILETIME=[6B7601F0:01C9EB1B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1547; t=1244783136; x=1245647136; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20[dispatch]=20Session=20recording=20in=2 0SIP |Sender:=20; bh=kp9L5swxjFTqAFaMC/po1Pbv02BZLbvZa/g5xcMOhm4=; b=R9jD0YCeL2M6RUgXqsqaNeT0QWT+sr42jgr2L1A58fYXOLb+/PfAHEMlDm FguXyBTcojXopdayu8oIu+4HMgbLF1yI40oUNizZNnyPkiSsMt2G5FF/7bEY YSvwPO0SRN; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: 'Leon Portman' , "dispatch@ietf.org" , "'Jain, Rajnish'" , Roni Even Subject: Re: [dispatch] Session recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 05:05:29 -0000 I'm not sure the UA model does "come for free", give there needs to be new code telling the UA to all of a sudden replicate the media stream (if it can) back out (which may or may not have the BW or the reachability to the sink device). If the original media is sRTP, does this (or not) mean sRTP needs to be used to the media sink? That takes more negotiation (and time). Does the sink always trust what comes at it from any UA? It can be configured much more easily to trust certain (limited number of) servers that can send it media to record. I could be wet behind the ears, but I don't believe the UA model is low hanging fruit if the server model is specified. I (think I) see each as completely separate solutions, requiring however much work to do regardless of whether the other is done too (other than having the recording sink specified/developed -- that part is free once it is done for either model). This is an interesting problem space, and I think we should look into it. I think there will be more than we expect once we peel away the layers. James At 10:54 PM 6/11/2009, Hadriel Kaplan wrote: >Sure there are advantages/disadvantages to each model, but why >bother arguing over it? I think we probably all agree we need to >support at least a B2BUA model, so once you have to standardize that >doesn't the UA model come for virtually free? (i.e., I would >presume the details of a B2BUA model are either a superset or the >same as a single UA model, not less) > >-hadriel From HKaplan@acmepacket.com Thu Jun 11 22:36:35 2009 Return-Path: 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 E11F53A6AE1 for ; Thu, 11 Jun 2009 22:36:35 -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 7dr2MgcVP1wb for ; Thu, 11 Jun 2009 22:36:34 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 9CF243A6A71 for ; Thu, 11 Jun 2009 22:36:34 -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, 12 Jun 2009 01:36:41 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 12 Jun 2009 01:36:41 -0400 From: Hadriel Kaplan To: "James M. Polk" , Francois Audet , Paul Kyzivat Date: Fri, 12 Jun 2009 01:35:34 -0400 Thread-Topic: [dispatch] Session recording in SIP Thread-Index: AcnrG3JEvhllHX5rR1WgmQaf/pD/vgAAgQrQ Message-ID: References: In-Reply-To: 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 Cc: 'Leon Portman' , "dispatch@ietf.org" , "'Jain, Rajnish'" , Roni Even Subject: Re: [dispatch] Session recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 05:36:36 -0000 > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Friday, June 12, 2009 1:06 AM >=20 > I'm not sure the UA model does "come for free", give there needs to > be new code telling the UA to all of a sudden replicate the media > stream (if it can) back out (which may or may not have the BW or the > reachability to the sink device). If the original media is sRTP, > does this (or not) mean sRTP needs to be used to the media sink? That > takes more negotiation (and time). Does the sink always trust what > comes at it from any UA? It can be configured much more easily to > trust certain (limited number of) servers that can send it media to > record. When I say "for free" I sure don't mean code-wise. :) I meant from a protocol specification perspective. Any protocol issue I ca= n imagine of a UA would be likewise true of a B2BUA in any spec we define. = Can you think of any that aren't? For example, in some recording applications, a B2BUA has to tear down the c= all (or not allow it to begin with) if it does not have sufficient bandwidt= h or reachability to the recorder. Though I'm not sure the spec has to say= much about that - seems more of a local policy decision not affecting inte= roperability. Likewise any authentication of devices and protection of replicated media w= ill undoubtedly need to be covered in any RFC we try to do, no matter the m= odel, if nothing else than to get past the IESG. (and in practice I've been= told there are some cases where the recorders are not in the same domain o= f the servers either, so having such measures is appropriate) I have no do= ubt that in real-world practice many folks who deploy a server model would = just skip most of that, but I doubt we'll be able to avoid it in an RFC. -hadriel From steffen.fries@siemens.com Thu Jun 11 23:48:19 2009 Return-Path: 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 637C63A6C33 for ; Thu, 11 Jun 2009 23:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=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 zOlASJSmqnZ4 for ; Thu, 11 Jun 2009 23:48:18 -0700 (PDT) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by core3.amsl.com (Postfix) with ESMTP id 434A33A6BEB for ; Thu, 11 Jun 2009 23:48:18 -0700 (PDT) Received: from mail1.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id n5C6m5F5002617; Fri, 12 Jun 2009 08:48:06 +0200 Received: from mchp771a.ww002.siemens.net (mchp771a.ww002.siemens.net [139.25.131.189]) by mail1.siemens.de (8.12.11.20060308/8.12.11) with ESMTP id n5C6m5M8009397; Fri, 12 Jun 2009 08:48:05 +0200 Received: from MCHP7IEA.ww902.siemens.net ([139.25.131.145]) by mchp771a.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Jun 2009 08:48:04 +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: Fri, 12 Jun 2009 08:48:00 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Session recording in SIP Thread-Index: AcnrG28rW4rwV75hQV+u086Ai1f/4AADZlcQ References: From: "Fries, Steffen" To: "James M. Polk" , "Hadriel Kaplan" , "Francois Audet" , "Paul Kyzivat" X-OriginalArrivalTime: 12 Jun 2009 06:48:04.0884 (UTC) FILETIME=[BCB38D40:01C9EB29] Cc: Leon Portman , dispatch@ietf.org, "Jain, Rajnish" , Roni Even Subject: Re: [dispatch] Session recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 06:48:19 -0000 Hi,=20 > If the original media is sRTP, does this (or not) mean sRTP=20 > needs to be used to the media sink? That takes more=20 > negotiation (and time). Does the sink always trust what comes=20 > at it from any UA? It can be configured much more easily to=20 > trust certain (limited number of) servers that can send it=20 > media to record. That is one point we adressed in http://tools.ietf.org/html/draft-wing-sipping-srtp-key-04#page-15 by using a setup, were the call recording is done on the media way and the client just discloses the session key. This saves an extra encryption between the client and the recorder. Steffen >=20 > I could be wet behind the ears, but I don't believe the UA=20 > model is low hanging fruit if the server model is specified.=20 > I (think I) see each as completely separate solutions,=20 > requiring however much work to do regardless of whether the=20 > other is done too (other than having the recording sink=20 > specified/developed -- that part is free once it is done for=20 > either model). >=20 > This is an interesting problem space, and I think we should=20 > look into it. I think there will be more than we expect once=20 > we peel away the layers. >=20 > James >=20 > At 10:54 PM 6/11/2009, Hadriel Kaplan wrote: >=20 > >Sure there are advantages/disadvantages to each model, but=20 > why bother=20 > >arguing over it? I think we probably all agree we need to=20 > support at=20 > >least a B2BUA model, so once you have to standardize that=20 > doesn't the=20 > >UA model come for virtually free? (i.e., I would presume=20 > the details=20 > >of a B2BUA model are either a superset or the same as a single UA=20 > >model, not less) > > > >-hadriel >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From Even.roni@huawei.com Fri Jun 12 00:23:09 2009 Return-Path: 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 602F828C170 for ; Fri, 12 Jun 2009 00:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.46 X-Spam-Level: X-Spam-Status: No, score=-0.46 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1GRuy7UYiXU for ; Fri, 12 Jun 2009 00:23:08 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 690AB28C14D for ; Fri, 12 Jun 2009 00:23:08 -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 <0KL4000LI76H1B@szxga04-in.huawei.com> for dispatch@ietf.org; Fri, 12 Jun 2009 15:23:05 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KL40026076GVC@szxga04-in.huawei.com> for dispatch@ietf.org; Fri, 12 Jun 2009 15:23:05 +0800 (CST) Received: from windows8d787f9 (bzq-79-177-76-15.red.bezeqint.net [79.177.76.15]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KL40020S76902@szxml01-in.huawei.com>; Fri, 12 Jun 2009 15:23:04 +0800 (CST) Date: Fri, 12 Jun 2009 10:21:16 +0300 From: Roni Even In-reply-to: To: 'Hadriel Kaplan' , "'James M. Polk'" , 'Francois Audet' , 'Paul Kyzivat' Message-id: <00fc01c9eb2e$672e99a0$358bcce0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcnrG3JEvhllHX5rR1WgmQaf/pD/vgAAgQrQAAOAHmA= References: Cc: 'Leon Portman' , dispatch@ietf.org, "'Jain, Rajnish'" Subject: Re: [dispatch] Session recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 07:23:09 -0000 Hadriel, I think that there may be a different protocol if you use the B2BUA solution. In this case it will make more sense to use a "mediactrl" direction where SIP is used to open a control channel to the recorder but the recording protocol itself runs in the control channel. This control channel will be also used to deliver the meta data for the recording. So maybe the sentence " SIP based protocol interface between a communications system and a recorder" is limiting the solution space. Roni Even -----Original Message----- From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Sent: Friday, June 12, 2009 8:36 AM To: James M. Polk; Francois Audet; Paul Kyzivat Cc: 'Leon Portman'; dispatch@ietf.org; 'Jain, Rajnish'; Roni Even Subject: RE: [dispatch] Session recording in SIP > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Friday, June 12, 2009 1:06 AM > > I'm not sure the UA model does "come for free", give there needs to > be new code telling the UA to all of a sudden replicate the media > stream (if it can) back out (which may or may not have the BW or the > reachability to the sink device). If the original media is sRTP, > does this (or not) mean sRTP needs to be used to the media sink? That > takes more negotiation (and time). Does the sink always trust what > comes at it from any UA? It can be configured much more easily to > trust certain (limited number of) servers that can send it media to > record. When I say "for free" I sure don't mean code-wise. :) I meant from a protocol specification perspective. Any protocol issue I can imagine of a UA would be likewise true of a B2BUA in any spec we define. Can you think of any that aren't? For example, in some recording applications, a B2BUA has to tear down the call (or not allow it to begin with) if it does not have sufficient bandwidth or reachability to the recorder. Though I'm not sure the spec has to say much about that - seems more of a local policy decision not affecting interoperability. Likewise any authentication of devices and protection of replicated media will undoubtedly need to be covered in any RFC we try to do, no matter the model, if nothing else than to get past the IESG. (and in practice I've been told there are some cases where the recorders are not in the same domain of the servers either, so having such measures is appropriate) I have no doubt that in real-world practice many folks who deploy a server model would just skip most of that, but I doubt we'll be able to avoid it in an RFC. -hadriel From Even.roni@huawei.com Fri Jun 12 00:29:05 2009 Return-Path: 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 AB4333A683F for ; Fri, 12 Jun 2009 00:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.464 X-Spam-Level: X-Spam-Status: No, score=-0.464 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnOqxBffYDbl for ; Fri, 12 Jun 2009 00:29:04 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id EFF843A6D7F for ; Fri, 12 Jun 2009 00:28:59 -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 <0KL400KDH7G992@szxga04-in.huawei.com> for dispatch@ietf.org; Fri, 12 Jun 2009 15:28:57 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KL400KJ17G9MA@szxga04-in.huawei.com> for dispatch@ietf.org; Fri, 12 Jun 2009 15:28:57 +0800 (CST) Received: from windows8d787f9 (bzq-79-177-76-15.red.bezeqint.net [79.177.76.15]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KL4002H27G302@szxml01-in.huawei.com>; Fri, 12 Jun 2009 15:28:57 +0800 (CST) Date: Fri, 12 Jun 2009 10:27:16 +0300 From: Roni Even In-reply-to: To: "'James M. Polk'" , 'Paul Kyzivat' , 'Hadriel Kaplan' Message-id: <00fd01c9eb2f$39fa3920$adeeab60$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcnrA26dn6plCZIkQuayysm7FRTQJgAKyLQQ References: <4A2ECDB2.7000601@alcatel-lucent.com> <4A2FB842.7050302@sipstation.com> <028a01c9ea12$5ec96e60$1c5c4b20$%roni@huawei.com> <719F9BBB3E7E71428A2D13F3D76C768F01C7BBE8@GBNTHT12009MSX.gb002.siemens.net> <002801c9ea82$0da51320$28ef3960$%roni@huawei.com> <719F9BBB3E7E71428A2D13F3D76C768F01C7BE97@GBNTHT12009MSX.gb002.siemens.net> <004a01c9eaa7$94ef7990$bece6cb0$%roni@huawei.com> <00ab01c9eace$58b7c190$0a2744b0$%roni@huawei.com> <4A318F1E.9080308@cisco.com> Cc: 'Leon Portman' , dispatch@ietf.org, "'Jain, Rajnish'" Subject: Re: [dispatch] Session recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 07:29:05 -0000 James, The B2BUA does not need to see the RTP/RTCP stream they can go directly from the source to the recorder +-----+ +-----+ +-----+ | | Call | | Call | | |UA-A +<------------>+B2BUA+<------------>+UA-B | | | | | | | +-----+ +-++--+ +-----+ . \\ . . \\ control . . RTP TBD \\ .RTP . \\+----------+ . . \+ |..... . + Recorder | | | +----------+ Roni -----Original Message----- From: James M. Polk [mailto:jmpolk@cisco.com] Sent: Friday, June 12, 2009 5:13 AM To: Paul Kyzivat; Hadriel Kaplan Cc: 'Leon Portman'; dispatch@ietf.org; 'Jain, Rajnish'; Roni Even Subject: Re: [dispatch] Session recording in SIP At 06:11 PM 6/11/2009, Paul Kyzivat wrote: >Hadriel Kaplan wrote: >>Hey Roni, >>Being a middlebox man myself, a B2BUA doing the media forking makes >>the most sense to me too, but some other folks don't do it/want-it >>that way. So the proposed work is to cover both potential models. >>The statement you cite reflects the belief that the solution to the >>requirements will be to use SIP between the UA doing the media >>forking, and the recorder doing the collection; and that the work >>of specification will be to define that. >>So one diagram could be this, where "TBD" is the To-Be-Defined work: >> +-----+ +-----+ >> | | Call | | >> |UA-A +<------------>+UA-B | >> | | | | >> +-++--+ +-----+ >> \\ >> \\ >> TBD \\ >> \\+----------+ >> \+ | >> + Recorder | >> | | >> +----------+ > >This model actually can make a lot of sense in *some* circumstances. >For instance, in a call center, where you may have control over what >components are used throughout, it could make sense to do the media >forking for recording and monitoring right at the agent phone. Paul - how is your call center example *not* better accomplished with the figure below instead of the figure above? It seems to me that any enterprise based call center would have to have a SIP server of some form (i.e., the caller is not going to have a pt-to-pt SIP established session directly with a call center call taker). It seems much easier if that call center wants to record calls (even some of the calls, that to the caller, the B2BUA is the UAS, meaning the sRTP keys only have to be between the caller and the B2BUA, and not all the way to the call taker. In this scenario, the B2BUA merely replicates the RTP stream out towards the recording device with RTCP in tact, an can allow the B2BUA provide any meta data about the specifics of the call signaling it wants to also store. This scenario also means the caller is never aware the call is being recorded, creating anonymity wrt that facet of the solution. I'm not advocating B2BUAs here, I just see this as a better solution for call center type recording than pt-to-pt between caller and call taker. >But in those sorts of monitoring/recording we don't talk about in >IETF, its essential that the recorded parties not be able to >distinguish calls that are monitored from those that are not. >Anything that requires cooperation by one of the endpoints is a >no-go. Even something as simple as a middlebox replacing one media >port with another in order to initiate monitoring might be enough to >clue in the monitored parties. So in those cases you had better >have a way that looks exactly the same whether recording is >happening or not, which generally requires something like your picture below. > > Thanks, > Paul > >>Or this: >> >>+-----+ +-----+ +-----+ >>| | Call | | Call | | >>|UA-A +<------------>+B2BUA+<------------>+UA-B | >>| | | | | | >>+-----+ +-++--+ +-----+ >> \\ >> \\ >> TBD \\ >> \\+----------+ >> \+ | >> + Recorder | >> | | >> +----------+ >>-hadriel >> >>>-----Original Message----- >>>From: Roni Even [mailto:Even.roni@huawei.com] >>>Sent: Thursday, June 11, 2009 3:54 PM >>>To: Hadriel Kaplan; 'Hutton, Andrew'; 'Alan Johnston'; 'Romascanu, Dan >>>(Dan)' >>>Cc: 'Leon Portman'; dispatch@ietf.org; 'Jain, Rajnish' >>>Subject: RE: [dispatch] Session recording in SIP >>> >>>Hadriel, >>>I am still confused by the following text which was the reason for the >>>previous question >>> >>>"This group will specify requirements for a SIP based protocol interface >>>between a communications system and a recorder. The Communications System >>>is >>>responsible for establishing media sessions where the actual business is >>>conducted. The Recorder is the sink of the recorded media." >>> >>> >>>Can someone draw a figure showing the talking parties the Communication >>>system and the recorder and explain where is this interface. According to >>>your response I can think that there are at least two separate >>>architectures >>>your are proposing one where the parties (or one of them) in the call know >>>the recorder and somehow forwards the media to it. The other architecture >>>has some B2BUA in the call path who is either forking the media to the >>>recorder and to the parties or the recorder is in the middle of the media >>>path. >>_______________________________________________ >>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 drage@alcatel-lucent.com Fri Jun 12 05:00:12 2009 Return-Path: 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 4C7D93A69DE for ; Fri, 12 Jun 2009 05:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.916 X-Spam-Level: X-Spam-Status: No, score=-2.916 tagged_above=-999 required=5 tests=[AWL=-0.667, 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 GbQR89NYZkna for ; Fri, 12 Jun 2009 05:00:11 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id CB56A3A6898 for ; Fri, 12 Jun 2009 05:00:10 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n5CBxprT014837 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 12 Jun 2009 13:59:51 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Fri, 12 Jun 2009 13:59:51 +0200 From: "DRAGE, Keith (Keith)" To: Francois Audet , "James M. Polk" , Paul Kyzivat , Hadriel Kaplan Date: Fri, 12 Jun 2009 13:59:50 +0200 Thread-Topic: [dispatch] Session recording in SIP Thread-Index: AcnrD9BjXrOnCAToRe+3AbjNNYbITQARJKRw Message-ID: References: In-Reply-To: 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.84 Cc: 'Leon Portman' , "dispatch@ietf.org" , "'Jain, Rajnish'" , Roni Even Subject: Re: [dispatch] Session recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 12:00:12 -0000 I have no response to any of the other points, but please note that for 1),= in the scenarios of call centres, some jurisdictions do require the client= to be informed that the call is being recorded. Normally this is done by a= verbal announcement. So in those use cases, 1) is a non-argument. regards Keith=20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Francois Audet > Sent: Friday, June 12, 2009 4:43 AM > To: James M. Polk; Paul Kyzivat; Hadriel Kaplan > Cc: 'Leon Portman'; dispatch@ietf.org; 'Jain, Rajnish'; Roni Even > Subject: Re: [dispatch] Session recording in SIP >=20 > I agree with James. >=20 > There are *some* scenarios where the UA-initiated recording=20 > will work, but they are very limited. They have the following=20 > disadvantages: > 1- It makes the client "aware" that it is being recorded > 2- It makes it very easy to avoid being recorded by=20 > interrupting the media stream > 3 - It makes it much easier to "dispute" (i.e., lawyers) the=20 > authenticity of a recorded conversation if there is potential=20 > for significant differences in the streams as seen by different ends > 4 - It doubles the bandwidth requirements on the UA, which=20 > can be a problem in some scenarios > 5 - It doubles the processing power required in the client=20 > (think SRTP/key negotiation & al). This can be a problem with=20 > many phones. > 6 - They require phones that actually support this. Which=20 > means, you can't use "normal" SIP phones. Which means, if=20 > you get the $30 phone, you don't get tapped into, but if you=20 > get the $300 phone, you don't. >=20 >=20 > But UA-initiated recording has very few advantages: > 1 - Less work on servers. This is actually a big advantage=20 > because lots of servers are so complex, it is difficult to do=20 > anything new on them. > 2 - Looks much more abstract and cool in an IETF RFC :-) >=20 >=20 > On Jun11 2009 19:13 , "James M. Polk" wrote: >=20 > > At 06:11 PM 6/11/2009, Paul Kyzivat wrote: > >=20 > >=20 > >> Hadriel Kaplan wrote: > >>> Hey Roni, > >>> Being a middlebox man myself, a B2BUA doing the media=20 > forking makes=20 > >>> the most sense to me too, but some other folks don't do=20 > it/want-it=20 > >>> that way. So the proposed work is to cover both potential models. > >>> The statement you cite reflects the belief that the=20 > solution to the=20 > >>> requirements will be to use SIP between the UA doing the media=20 > >>> forking, and the recorder doing the collection; and that=20 > the work of=20 > >>> specification will be to define that. > >>> So one diagram could be this, where "TBD" is the=20 > To-Be-Defined work: > >>> +-----+ +-----+ > >>> | | Call | | > >>> |UA-A +<------------>+UA-B | > >>> | | | | > >>> +-++--+ +-----+ > >>> \\ > >>> \\ > >>> TBD \\ > >>> \\+----------+ > >>> \+ | > >>> + Recorder | > >>> | | > >>> +----------+ > >>=20 > >> This model actually can make a lot of sense in *some*=20 > circumstances. > >> For instance, in a call center, where you may have control=20 > over what=20 > >> components are used throughout, it could make sense to do=20 > the media=20 > >> forking for recording and monitoring right at the agent phone. > >=20 > > Paul - how is your call center example *not* better=20 > accomplished with=20 > > the figure below instead of the figure above? > >=20 > > It seems to me that any enterprise based call center would have to=20 > > have a SIP server of some form (i.e., the caller is not=20 > going to have=20 > > a pt-to-pt SIP established session directly with a call center call=20 > > taker). It seems much easier if that call center wants to=20 > record calls=20 > > (even some of the calls, that to the caller, the B2BUA is the UAS,=20 > > meaning the sRTP keys only have to be between the caller and the=20 > > B2BUA, and not all the way to the call taker. In this=20 > scenario, the=20 > > B2BUA merely replicates the RTP stream out towards the recording=20 > > device with RTCP in tact, an can allow the B2BUA provide=20 > any meta data=20 > > about the specifics of the call signaling it wants to also store. > >=20 > > This scenario also means the caller is never aware the call=20 > is being=20 > > recorded, creating anonymity wrt that facet of the solution. > >=20 > > I'm not advocating B2BUAs here, I just see this as a better=20 > solution=20 > > for call center type recording than pt-to-pt between caller=20 > and call taker. > >=20 > >=20 > >> But in those sorts of monitoring/recording we don't talk about in=20 > >> IETF, its essential that the recorded parties not be able to=20 > >> distinguish calls that are monitored from those that are not. > >> Anything that requires cooperation by one of the endpoints is a=20 > >> no-go. Even something as simple as a middlebox replacing one media=20 > >> port with another in order to initiate monitoring might be=20 > enough to=20 > >> clue in the monitored parties. So in those cases you had=20 > better have=20 > >> a way that looks exactly the same whether recording is=20 > happening or=20 > >> not, which generally requires something like your picture below. > >>=20 > >> Thanks, > >> Paul > >>=20 > >>> Or this: > >>>=20 > >>> +-----+ +-----+ +-----+ > >>> | | Call | | Call | | > >>> |UA-A +<------------>+B2BUA+<------------>+UA-B | > >>> | | | | | | > >>> +-----+ +-++--+ +-----+ > >>> \\ > >>> \\ > >>> TBD \\ > >>> \\+----------+ > >>> \+ | > >>> + Recorder | > >>> | | > >>> +----------+ -hadriel > >>>=20 > >>>> -----Original Message----- > >>>> From: Roni Even [mailto:Even.roni@huawei.com] > >>>> Sent: Thursday, June 11, 2009 3:54 PM > >>>> To: Hadriel Kaplan; 'Hutton, Andrew'; 'Alan Johnston';=20 > 'Romascanu,=20 > >>>> Dan (Dan)' > >>>> Cc: 'Leon Portman'; dispatch@ietf.org; 'Jain, Rajnish' > >>>> Subject: RE: [dispatch] Session recording in SIP > >>>>=20 > >>>> Hadriel, > >>>> I am still confused by the following text which was the=20 > reason for=20 > >>>> the previous question > >>>>=20 > >>>> "This group will specify requirements for a SIP based protocol=20 > >>>> interface between a communications system and a recorder. The=20 > >>>> Communications System is responsible for establishing media=20 > >>>> sessions where the actual business is conducted. The Recorder is=20 > >>>> the sink of the recorded media." > >>>>=20 > >>>>=20 > >>>> Can someone draw a figure showing the talking parties the=20 > >>>> Communication system and the recorder and explain where is this=20 > >>>> interface. According to your response I can think that=20 > there are at=20 > >>>> least two separate architectures your are proposing one=20 > where the=20 > >>>> parties (or one of them) in the call know the recorder=20 > and somehow=20 > >>>> forwards the media to it. The other architecture has=20 > some B2BUA in=20 > >>>> the call path who is either forking the media to the=20 > recorder and=20 > >>>> to the parties or the recorder is in the middle of the=20 > media path. > >>> _______________________________________________ > >>> 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 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From gonzalo.camarillo@ericsson.com Fri Jun 12 05:26:51 2009 Return-Path: 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 A2C643A6CC0 for ; Fri, 12 Jun 2009 05:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 cDdvEkmO9AFL for ; Fri, 12 Jun 2009 05:26:50 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 4AA923A6D41 for ; Fri, 12 Jun 2009 05:26:50 -0700 (PDT) X-AuditID: c1b4fb3c-b7bbdae0000049e3-bd-4a324990f563 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 42.F9.18915.099423A4; Fri, 12 Jun 2009 14:26:57 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jun 2009 14:26:30 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jun 2009 14:26:30 +0200 Received: from [131.160.37.44] (EV001E681B5FE2.lmf.ericsson.se [131.160.37.44]) by mail.lmf.ericsson.se (Postfix) with ESMTP id A1A9F245F; Fri, 12 Jun 2009 15:26:30 +0300 (EEST) Message-ID: <4A324976.7090203@ericsson.com> Date: Fri, 12 Jun 2009 15:26:30 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: DISPATCH Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jun 2009 12:26:30.0663 (UTC) FILETIME=[03E38970:01C9EB59] X-Brightmail-Tracker: AAAAAA== Subject: [dispatch] SIP CLF work dispatched as a new WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 12:26:51 -0000 Folks, we have had significant email discussions on the SIP CLF proposal: http://www.ietf.org/mail-archive/web/dispatch/current/msg00176.html We also set up a dedicated mailing list for this work: https://www.ietf.org/mailman/listinfo/sip-clf Based on the discussions up to now, there seems to be enough interest and energy to work on this. Our proposal is to form a new WG with a charter based on the proposal above. If there are no objections, we will proceed with the formation of the new WG and will not allocate any agenda time for this in DISPATCH in Stockholm. Only if we could not reach consensus on the list, we would discuss it face to face in Stockholm. As we have pointed out a few times, the model we want to follow in DISPATCH is to only use face-to-face time for things that cannot be agreed on the list. Comments? Thanks, Gonzalo DISPATCH co-chair From pkyzivat@cisco.com Fri Jun 12 06:12:02 2009 Return-Path: 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 4C53B3A6E08 for ; Fri, 12 Jun 2009 06:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 lTT4VF1DpN0H for ; Fri, 12 Jun 2009 06:12:01 -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 1927D3A6DFD for ; Fri, 12 Jun 2009 06:12:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,209,1243814400"; d="scan'208";a="175721810" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 12 Jun 2009 13:12:09 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n5CDC9pn008367; Fri, 12 Jun 2009 06:12:09 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id n5CDC162008355; Fri, 12 Jun 2009 13:12:09 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Jun 2009 09:12:04 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Jun 2009 09:12:04 -0400 Message-ID: <4A325424.9020901@cisco.com> Date: Fri, 12 Jun 2009 09:12:04 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "James M. Polk" References: <4A2ECDB2.7000601@alcatel-lucent.com> <4A2FB842.7050302@sipstation.com> <028a01c9ea12$5ec96e60$1c5c4b20$%roni@huawei.com> <719F9BBB3E7E71428A2D13F3D76C768F01C7BBE8@GBNTHT12009MSX.gb002.siemens.net> <002801c9ea82$0da51320$28ef3960$%roni@huawei.com> <719F9BBB3E7E71428A2D13F3D76C768F01C7BE97@GBNTHT12009MSX.gb002.siemens.net> <004a01c9eaa7$94ef7990$bece6cb0$%roni@huawei.com> <00ab01c9eace$58b7c190$0a2744b0$%roni@huawei.com> <4A318F1E.9080308@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jun 2009 13:12:04.0367 (UTC) FILETIME=[614DA9F0:01C9EB5F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6042; t=1244812329; x=1245676329; 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 |Subject:=20Re=3A=20[dispatch]=20Session=20recording=20in=2 0SIP |Sender:=20; bh=68mng+e9P+h3486nLdLChcN8Ws22eabjXj92dL9Cq2g=; b=fJaT4Lp8NhWa3GJSmeq1CpxXjjv6S3WyI2XcQQCv7SEb+YonykKCBO77HH rml1ZVrhjOKz715DPnm6Z9ig2pqIqAkpInNoc9uoi6lhE/r8Yd3SvVAZyy3x 7IQ/7gZyL0; Authentication-Results: sj-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: 'Leon Portman' , "dispatch@ietf.org" , "'Jain, Rajnish'" , Roni Even , Hadriel Kaplan Subject: Re: [dispatch] Session recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 13:12:02 -0000 James M. Polk wrote: > At 06:11 PM 6/11/2009, Paul Kyzivat wrote: > > >> Hadriel Kaplan wrote: >>> Hey Roni, >>> Being a middlebox man myself, a B2BUA doing the media forking makes >>> the most sense to me too, but some other folks don't do it/want-it >>> that way. So the proposed work is to cover both potential models. >>> The statement you cite reflects the belief that the solution to the >>> requirements will be to use SIP between the UA doing the media >>> forking, and the recorder doing the collection; and that the work of >>> specification will be to define that. >>> So one diagram could be this, where "TBD" is the To-Be-Defined work: >>> +-----+ +-----+ >>> | | Call | | >>> |UA-A +<------------>+UA-B | >>> | | | | >>> +-++--+ +-----+ >>> \\ >>> \\ >>> TBD \\ >>> \\+----------+ >>> \+ | >>> + Recorder | >>> | | >>> +----------+ >> >> This model actually can make a lot of sense in *some* circumstances. >> For instance, in a call center, where you may have control over what >> components are used throughout, it could make sense to do the media >> forking for recording and monitoring right at the agent phone. > > Paul - how is your call center example *not* better accomplished with > the figure below instead of the figure above? > > It seems to me that any enterprise based call center would have to have > a SIP server of some form (i.e., the caller is not going to have a > pt-to-pt SIP established session directly with a call center call > taker). It seems much easier if that call center wants to record calls > (even some of the calls, that to the caller, the B2BUA is the UAS, > meaning the sRTP keys only have to be between the caller and the B2BUA, > and not all the way to the call taker. In this scenario, the B2BUA > merely replicates the RTP stream out towards the recording device with > RTCP in tact, an can allow the B2BUA provide any meta data about the > specifics of the call signaling it wants to also store. > > This scenario also means the caller is never aware the call is being > recorded, creating anonymity wrt that facet of the solution. > > I'm not advocating B2BUAs here, I just see this as a better solution for > call center type recording than pt-to-pt between caller and call taker. There are pros and cons. I agree that many implemenations *will* have a central server in any case. Routing *all* the media through a central server has resource costs, especially if you then require redundancy as well. Often forking media at the phone can be "free" in that it is well within the capabilities of even a cheap sip phone. The point is that there are complex architectural tradeoffs here based on individual priorities, so it makes sense to consider both as viable. >> But in those sorts of monitoring/recording we don't talk about in >> IETF, its essential that the recorded parties not be able to >> distinguish calls that are monitored from those that are not. Anything >> that requires cooperation by one of the endpoints is a no-go. Even >> something as simple as a middlebox replacing one media port with >> another in order to initiate monitoring might be enough to clue in the >> monitored parties. So in those cases you had better have a way that >> looks exactly the same whether recording is happening or not, which >> generally requires something like your picture below. >> >> Thanks, >> Paul >> >>> Or this: >>> >>> +-----+ +-----+ +-----+ >>> | | Call | | Call | | >>> |UA-A +<------------>+B2BUA+<------------>+UA-B | >>> | | | | | | >>> +-----+ +-++--+ +-----+ >>> \\ >>> \\ >>> TBD \\ >>> \\+----------+ >>> \+ | >>> + Recorder | >>> | | >>> +----------+ >>> -hadriel >>> >>>> -----Original Message----- >>>> From: Roni Even [mailto:Even.roni@huawei.com] >>>> Sent: Thursday, June 11, 2009 3:54 PM >>>> To: Hadriel Kaplan; 'Hutton, Andrew'; 'Alan Johnston'; 'Romascanu, Dan >>>> (Dan)' >>>> Cc: 'Leon Portman'; dispatch@ietf.org; 'Jain, Rajnish' >>>> Subject: RE: [dispatch] Session recording in SIP >>>> >>>> Hadriel, >>>> I am still confused by the following text which was the reason for the >>>> previous question >>>> >>>> "This group will specify requirements for a SIP based protocol >>>> interface >>>> between a communications system and a recorder. The Communications >>>> System >>>> is >>>> responsible for establishing media sessions where the actual >>>> business is >>>> conducted. The Recorder is the sink of the recorded media." >>>> >>>> >>>> Can someone draw a figure showing the talking parties the Communication >>>> system and the recorder and explain where is this interface. >>>> According to >>>> your response I can think that there are at least two separate >>>> architectures >>>> your are proposing one where the parties (or one of them) in the >>>> call know >>>> the recorder and somehow forwards the media to it. The other >>>> architecture >>>> has some B2BUA in the call path who is either forking the media to the >>>> recorder and to the parties or the recorder is in the middle of the >>>> media >>>> path. >>> _______________________________________________ >>> 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 christer.holmberg@ericsson.com Fri Jun 12 06:22:02 2009 Return-Path: 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 6F58A3A6E2A for ; Fri, 12 Jun 2009 06:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.789 X-Spam-Level: X-Spam-Status: No, score=-5.789 tagged_above=-999 required=5 tests=[AWL=0.460, 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 8KiodozT0pRm for ; Fri, 12 Jun 2009 06:22:01 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id DADD43A6E27 for ; Fri, 12 Jun 2009 06:22:00 -0700 (PDT) X-AuditID: c1b4fb3e-b7bedae0000062bb-dd-4a32567fea07 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id FF.81.25275.F76523A4; Fri, 12 Jun 2009 15:22:07 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jun 2009 15:22:07 +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: Fri, 12 Jun 2009 15:22:06 +0200 Message-ID: In-Reply-To: <4A325424.9020901@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Session recording in SIP Thread-Index: AcnrX2wirnFXumeQReSqkt6JSlTf7AAAHwOA References: <4A2ECDB2.7000601@alcatel-lucent.com><4A2FB842.7050302@sipstation.com><028a01c9ea12$5ec96e60$1c5c4b20$%roni@huawei.com><719F9BBB3E7E71428A2D13F3D76C768F01C7BBE8@GBNTHT12009MSX.gb002.siemens.net><002801c9ea82$0da51320$28ef3960$%roni@huawei.com><719F9BBB3E7E71428A2D13F3D76C768F01C7BE97@GBNTHT12009MSX.gb002.siemens.net><004a01c9eaa7$94ef7990$bece6cb0$%roni@huawei.com><00ab01c9eace$58b7c190$0a2744b0$%roni@huawei.com><4A318F1E.9080308@cisco.com> <4A325424.9020901@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" , "James M. Polk" X-OriginalArrivalTime: 12 Jun 2009 13:22:07.0165 (UTC) FILETIME=[C89956D0:01C9EB60] X-Brightmail-Tracker: AAAAAA== Cc: Leon Portman , dispatch@ietf.org, "Jain, Rajnish" , Hadriel Kaplan , Roni Even Subject: Re: [dispatch] Session recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 13:22:02 -0000 Hi,=20 >There are pros and cons. >I agree that many implemenations *will* have a central server=20 >in any case. Routing *all* the media through a central server=20 >has resource costs, especially if you then require redundancy=20 >as well. Often forking media at the phone can be "free" in=20 >that it is well within the capabilities of even a cheap sip phone. It may have impacts on battery- and/or CPU limited devices. In addtion media forking at the phone may have resource cost on the access network, if you have limited resources on your access network and both the UA-to-UA and UA-to-recorder media has to be sent over that access network. Regards, Christer >=20 > The point is that there are complex architectural tradeoffs=20 > here based on individual priorities, so it makes sense to=20 > consider both as viable. >=20 > >> But in those sorts of monitoring/recording we don't talk about in=20 > >> IETF, its essential that the recorded parties not be able to=20 > >> distinguish calls that are monitored from those that are not.=20 > >> Anything that requires cooperation by one of the endpoints is a=20 > >> no-go. Even something as simple as a middlebox replacing one media=20 > >> port with another in order to initiate monitoring might be=20 > enough to=20 > >> clue in the monitored parties. So in those cases you had=20 > better have=20 > >> a way that looks exactly the same whether recording is=20 > happening or=20 > >> not, which generally requires something like your picture below. > >> > >> Thanks, > >> Paul > >> > >>> Or this: > >>> > >>> +-----+ +-----+ +-----+ > >>> | | Call | | Call | | > >>> |UA-A +<------------>+B2BUA+<------------>+UA-B | > >>> | | | | | | > >>> +-----+ +-++--+ +-----+ > >>> \\ > >>> \\ > >>> TBD \\ > >>> \\+----------+ > >>> \+ | > >>> + Recorder | > >>> | | > >>> +----------+ -hadriel > >>> > >>>> -----Original Message----- > >>>> From: Roni Even [mailto:Even.roni@huawei.com] > >>>> Sent: Thursday, June 11, 2009 3:54 PM > >>>> To: Hadriel Kaplan; 'Hutton, Andrew'; 'Alan Johnston';=20 > 'Romascanu,=20 > >>>> Dan (Dan)' > >>>> Cc: 'Leon Portman'; dispatch@ietf.org; 'Jain, Rajnish' > >>>> Subject: RE: [dispatch] Session recording in SIP > >>>> > >>>> Hadriel, > >>>> I am still confused by the following text which was the=20 > reason for=20 > >>>> the previous question > >>>> > >>>> "This group will specify requirements for a SIP based protocol=20 > >>>> interface between a communications system and a recorder. The=20 > >>>> Communications System is responsible for establishing media=20 > >>>> sessions where the actual business is conducted. The Recorder is=20 > >>>> the sink of the recorded media." > >>>> > >>>> > >>>> Can someone draw a figure showing the talking parties the=20 > >>>> Communication system and the recorder and explain where=20 > is this interface. > >>>> According to > >>>> your response I can think that there are at least two separate=20 > >>>> architectures your are proposing one where the parties=20 > (or one of=20 > >>>> them) in the call know the recorder and somehow forwards=20 > the media=20 > >>>> to it. The other architecture has some B2BUA in the call=20 > path who=20 > >>>> is either forking the media to the recorder and to the=20 > parties or=20 > >>>> the recorder is in the middle of the media path. > >>> _______________________________________________ > >>> 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 > >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From AUDET@nortel.com Fri Jun 12 08:06:05 2009 Return-Path: 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 5944F3A6C5D for ; Fri, 12 Jun 2009 08:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 UrJsoYnjLMcm for ; Fri, 12 Jun 2009 08:06:04 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id EB16D3A67E2 for ; Fri, 12 Jun 2009 08:06:03 -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 n5CF4gR26056; Fri, 12 Jun 2009 15:04:42 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Jun 2009 10:05:27 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E788123@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Session recording in SIP Thread-Index: AcnrD9BjXrOnCAToRe+3AbjNNYbITQARJKRwAAay4rA= References: From: "Francois Audet" To: "DRAGE, Keith (Keith)" , "James M. Polk" , "Paul Kyzivat" , "Hadriel Kaplan" Cc: Leon Portman , dispatch@ietf.org, "Jain, Rajnish" , Roni Even Subject: Re: [dispatch] Session recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 15:06:05 -0000 You are correct.=20 > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 > Sent: Friday, June 12, 2009 05:00 > To: Audet, Francois (SC100:3055); James M. Polk; Paul=20 > Kyzivat; Hadriel Kaplan > Cc: 'Leon Portman'; dispatch@ietf.org; 'Jain, Rajnish'; Roni Even > Subject: RE: [dispatch] Session recording in SIP >=20 > I have no response to any of the other points, but please=20 > note that for 1), in the scenarios of call centres, some=20 > jurisdictions do require the client to be informed that the=20 > call is being recorded. Normally this is done by a verbal=20 > announcement. >=20 > So in those use cases, 1) is a non-argument. >=20 > regards >=20 > Keith=20 >=20 > > -----Original Message----- > > From: dispatch-bounces@ietf.org > > [mailto:dispatch-bounces@ietf.org] On Behalf Of Francois Audet > > Sent: Friday, June 12, 2009 4:43 AM > > To: James M. Polk; Paul Kyzivat; Hadriel Kaplan > > Cc: 'Leon Portman'; dispatch@ietf.org; 'Jain, Rajnish'; Roni Even > > Subject: Re: [dispatch] Session recording in SIP > >=20 > > I agree with James. > >=20 > > There are *some* scenarios where the UA-initiated recording=20 > will work,=20 > > but they are very limited. They have the following > > disadvantages: > > 1- It makes the client "aware" that it is being recorded > > 2- It makes it very easy to avoid being recorded by=20 > interrupting the=20 > > media stream > > 3 - It makes it much easier to "dispute" (i.e., lawyers) the=20 > > authenticity of a recorded conversation if there is potential for=20 > > significant differences in the streams as seen by different ends > > 4 - It doubles the bandwidth requirements on the UA, which can be a=20 > > problem in some scenarios > > 5 - It doubles the processing power required in the client (think=20 > > SRTP/key negotiation & al). This can be a problem with many phones. > > 6 - They require phones that actually support this. Which=20 > means, you=20 > > can't use "normal" SIP phones. Which means, if you get the=20 > $30 phone,=20 > > you don't get tapped into, but if you get the $300 phone, you don't. > >=20 > >=20 > > But UA-initiated recording has very few advantages: > > 1 - Less work on servers. This is actually a big advantage because=20 > > lots of servers are so complex, it is difficult to do=20 > anything new on=20 > > them. > > 2 - Looks much more abstract and cool in an IETF RFC :-) > >=20 > >=20 > > On Jun11 2009 19:13 , "James M. Polk" wrote: > >=20 > > > At 06:11 PM 6/11/2009, Paul Kyzivat wrote: > > >=20 > > >=20 > > >> Hadriel Kaplan wrote: > > >>> Hey Roni, > > >>> Being a middlebox man myself, a B2BUA doing the media > > forking makes > > >>> the most sense to me too, but some other folks don't do > > it/want-it > > >>> that way. So the proposed work is to cover both=20 > potential models. > > >>> The statement you cite reflects the belief that the > > solution to the > > >>> requirements will be to use SIP between the UA doing the media=20 > > >>> forking, and the recorder doing the collection; and that > > the work of > > >>> specification will be to define that. > > >>> So one diagram could be this, where "TBD" is the > > To-Be-Defined work: > > >>> +-----+ +-----+ > > >>> | | Call | | > > >>> |UA-A +<------------>+UA-B | > > >>> | | | | > > >>> +-++--+ +-----+ > > >>> \\ > > >>> \\ > > >>> TBD \\ > > >>> \\+----------+ > > >>> \+ | > > >>> + Recorder | > > >>> | | > > >>> +----------+ > > >>=20 > > >> This model actually can make a lot of sense in *some* > > circumstances. > > >> For instance, in a call center, where you may have control > > over what > > >> components are used throughout, it could make sense to do > > the media > > >> forking for recording and monitoring right at the agent phone. > > >=20 > > > Paul - how is your call center example *not* better > > accomplished with > > > the figure below instead of the figure above? > > >=20 > > > It seems to me that any enterprise based call center=20 > would have to=20 > > > have a SIP server of some form (i.e., the caller is not > > going to have > > > a pt-to-pt SIP established session directly with a call=20 > center call=20 > > > taker). It seems much easier if that call center wants to > > record calls > > > (even some of the calls, that to the caller, the B2BUA is=20 > the UAS,=20 > > > meaning the sRTP keys only have to be between the caller and the=20 > > > B2BUA, and not all the way to the call taker. In this > > scenario, the > > > B2BUA merely replicates the RTP stream out towards the recording=20 > > > device with RTCP in tact, an can allow the B2BUA provide > > any meta data > > > about the specifics of the call signaling it wants to also store. > > >=20 > > > This scenario also means the caller is never aware the call > > is being > > > recorded, creating anonymity wrt that facet of the solution. > > >=20 > > > I'm not advocating B2BUAs here, I just see this as a better > > solution > > > for call center type recording than pt-to-pt between caller > > and call taker. > > >=20 > > >=20 > > >> But in those sorts of monitoring/recording we don't talk=20 > about in=20 > > >> IETF, its essential that the recorded parties not be able to=20 > > >> distinguish calls that are monitored from those that are not. > > >> Anything that requires cooperation by one of the endpoints is a=20 > > >> no-go. Even something as simple as a middlebox replacing=20 > one media=20 > > >> port with another in order to initiate monitoring might be > > enough to > > >> clue in the monitored parties. So in those cases you had > > better have > > >> a way that looks exactly the same whether recording is > > happening or > > >> not, which generally requires something like your picture below. > > >>=20 > > >> Thanks, > > >> Paul > > >>=20 > > >>> Or this: > > >>>=20 > > >>> +-----+ +-----+ +-----+ > > >>> | | Call | | Call | | > > >>> |UA-A +<------------>+B2BUA+<------------>+UA-B | > > >>> | | | | | | > > >>> +-----+ +-++--+ +-----+ > > >>> \\ > > >>> \\ > > >>> TBD \\ > > >>> \\+----------+ > > >>> \+ | > > >>> + Recorder | > > >>> | | > > >>> +----------+ -hadriel > > >>>=20 > > >>>> -----Original Message----- > > >>>> From: Roni Even [mailto:Even.roni@huawei.com] > > >>>> Sent: Thursday, June 11, 2009 3:54 PM > > >>>> To: Hadriel Kaplan; 'Hutton, Andrew'; 'Alan Johnston'; > > 'Romascanu, > > >>>> Dan (Dan)' > > >>>> Cc: 'Leon Portman'; dispatch@ietf.org; 'Jain, Rajnish' > > >>>> Subject: RE: [dispatch] Session recording in SIP > > >>>>=20 > > >>>> Hadriel, > > >>>> I am still confused by the following text which was the > > reason for > > >>>> the previous question > > >>>>=20 > > >>>> "This group will specify requirements for a SIP based protocol=20 > > >>>> interface between a communications system and a recorder. The=20 > > >>>> Communications System is responsible for establishing media=20 > > >>>> sessions where the actual business is conducted. The=20 > Recorder is=20 > > >>>> the sink of the recorded media." > > >>>>=20 > > >>>>=20 > > >>>> Can someone draw a figure showing the talking parties the=20 > > >>>> Communication system and the recorder and explain=20 > where is this=20 > > >>>> interface. According to your response I can think that > > there are at > > >>>> least two separate architectures your are proposing one > > where the > > >>>> parties (or one of them) in the call know the recorder > > and somehow > > >>>> forwards the media to it. The other architecture has > > some B2BUA in > > >>>> the call path who is either forking the media to the > > recorder and > > >>>> to the parties or the recorder is in the middle of the > > media path. > > >>> _______________________________________________ > > >>> 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 > >=20 > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > >=20 >=20 From dworley@nortel.com Fri Jun 12 10:06:41 2009 Return-Path: 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 2C5703A6B46 for ; Fri, 12 Jun 2009 10:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.676 X-Spam-Level: X-Spam-Status: No, score=-6.676 tagged_above=-999 required=5 tests=[AWL=-0.077, 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 n+8K5CFyra6v for ; Fri, 12 Jun 2009 10:06:40 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 230263A6A51 for ; Fri, 12 Jun 2009 10:06:40 -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 n5CH6jZ11706 for ; Fri, 12 Jun 2009 17:06:45 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Jun 2009 13:06:29 -0400 From: "Dale Worley" To: DISPATCH Content-Type: text/plain Organization: Nortel Networks Date: Fri, 12 Jun 2009 13:06:28 -0400 Message-Id: <1244826388.3768.33.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: 12 Jun 2009 17:06:29.0127 (UTC) FILETIME=[208DB970:01C9EB80] Subject: [dispatch] Incompatibility between policy dataset framework and media-policy-dataset X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 17:06:41 -0000 Currently, the only defined policy schema within the draft-ietf-sipping-profile-datasets framework is draft-ietf-sipping-media-policy-dataset. Unfortunately, the media-policy-dataset includes elements that cannot be modeled with the profile-datasets framework. Consider the example in section 7.1 of draft-ietf-sipping-media-policy-dataset-07: policy@biloxi.example.com sip:policy_manager@example.com Access network policies audio video audio/G729 audio/G723 This dataset contains bindings of the properties "media-types" and "codecs". But it also contains a element that does not fit within the system of the policy-dataset framework. One way to remove this inconsistency is to remove the from within the dataset, and rather have the and the dataset be siblings within the XML: (This example includes correcting the top-level element of the dataset to be propertySet, so we can use for the higher-level element.) policy@biloxi.example.com sip:policy_manager@example.com Access network policies audio video audio/G729 audio/G723 Worse, the element cannot be put within the policy-dataset framework at all, as it consists of an array-of-structures, which we have earlier noted is not supported within the framework. Dale From fluffy@cisco.com Fri Jun 12 10:28:03 2009 Return-Path: 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 B414D3A69D1; Fri, 12 Jun 2009 10:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.577 X-Spam-Level: X-Spam-Status: No, score=-106.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 DLkFl7gALcT7; Fri, 12 Jun 2009 10:27: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 E5D193A69EA; Fri, 12 Jun 2009 10:27:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,210,1243814400"; d="scan'208";a="322588397" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 12 Jun 2009 17:28:01 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n5CHS112011583; Fri, 12 Jun 2009 10:28:01 -0700 Received: from [192.168.0.101] (sjc-vpn7-1408.cisco.com [10.21.149.128]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n5CHR8sA016154; Fri, 12 Jun 2009 17:28:00 GMT Message-Id: <2E380046-B986-4F34-9246-C818383B27DD@cisco.com> From: Cullen Jennings To: dispatch@ietf.org, IETF AVT WG , rai@ietf.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: Fri, 12 Jun 2009 11:28:00 -0600 X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=651; t=1244827681; x=1245691681; 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 |Subject:=20CODEC=20BOF |Sender:=20; bh=wfkcTHM0n2sN63DfLRfMASTlZ4MM1mtyyyNSYvGSwvc=; b=yEJTjj+dIColrydll6m5Ad1bDMZU/SN8It7C1/6eUPdbyhm1hvF1eNHUPV vy/no62/68VhmQJ9VPihRK8U6LYqk6rFDeSl0GYRry147b3eiyTSi2k+PwPn 8Zztng7xIC; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [dispatch] CODEC BOF X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 17:28:04 -0000 The CODEC proposal to form a WG on Internet Wideband Audio Codecs has been raised many issues - I think it is better to consider this in the context of a formal BOF instead of discussing it in the DISPATCH WG. I have approved this BOF for the next meeting but there are many issues that have been raised and need discussion before this would be approved as a WG. I encourage people to take those to the codec@ietf.org list. Please to not reply to this email (particularly since I cross posted to three WG), but instead go join the threads on the codec@ietf.org mailing list to discuss this. Thanks, Cullen From fluffy@cisco.com Fri Jun 12 10:59:35 2009 Return-Path: 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 8FFFC3A6B29; Fri, 12 Jun 2009 10:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.578 X-Spam-Level: X-Spam-Status: No, score=-106.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 lqsWY7elylsv; Fri, 12 Jun 2009 10:59:34 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 69A0E28C244; Fri, 12 Jun 2009 10:59:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,210,1243814400"; d="scan'208";a="80563146" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 12 Jun 2009 17:59:11 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n5CHxB0W016218; Fri, 12 Jun 2009 10:59:11 -0700 Received: from [192.168.0.101] (sjc-vpn7-1408.cisco.com [10.21.149.128]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n5CHwImO006518; Fri, 12 Jun 2009 17:59:08 GMT Message-Id: <8867B97F-7929-47BF-9483-9158AA8300CD@cisco.com> From: Cullen Jennings To: Cullen Jennings In-Reply-To: <2E380046-B986-4F34-9246-C818383B27DD@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: Fri, 12 Jun 2009 11:59:07 -0600 References: <2E380046-B986-4F34-9246-C818383B27DD@cisco.com> X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=842; t=1244829551; x=1245693551; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20CODEC=20BOF |Sender:=20; bh=8zKkT3sdJct9hm/aLwNlpnvwYX7uw/ZRdQ3mOJO0s5E=; b=MjxIdzDJTkA/cN6dGLZmUekpZjSwoshBNMDxbmBtx7U+yCUEJewmQLYUMd bSSlSO92hKgSiwro8OKziShd1thkaYrsLz2/pm9+xgi5y1VHjK7e7IAIl6D6 HCGFSXlE986EPe4lfmLkLJQmV0UeYNNXhe50oJUINVHH/kS8KEa2M=; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: dispatch@ietf.org, rai@ietf.org, IETF AVT WG Subject: Re: [dispatch] CODEC BOF X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 17:59:35 -0000 I forgot to add, you can join the codec@ietf list at https://www.ietf.org/mailman/listinfo/codec On Jun 12, 2009, at 11:28 , Cullen Jennings wrote: > > The CODEC proposal to form a WG on Internet Wideband Audio Codecs > has been raised many issues - I think it is better to consider this > in the context of a formal BOF instead of discussing it in the > DISPATCH WG. I have approved this BOF for the next meeting but there > are many issues that have been raised and need discussion before > this would be approved as a WG. I encourage people to take those to > the codec@ietf.org list. > > Please to not reply to this email (particularly since I cross posted > to three WG), but instead go join the threads on the codec@ietf.org > mailing list to discuss this. > > Thanks, > Cullen > > From dworley@nortel.com Fri Jun 12 12:36:29 2009 Return-Path: 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 958353A6858; Fri, 12 Jun 2009 12:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.67 X-Spam-Level: X-Spam-Status: No, score=-6.67 tagged_above=-999 required=5 tests=[AWL=-0.071, 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 b1Xd3jw7it8z; Fri, 12 Jun 2009 12:36:29 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id A0ED23A68CB; Fri, 12 Jun 2009 12:36:28 -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 n5CJZC110248; Fri, 12 Jun 2009 19:35:12 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Jun 2009 15:36:31 -0400 From: "Dale Worley" To: "Mary Barnes" In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E727FEF@zrc2hxm0.corp.nortel.com> References: <1241379400.3528.50.camel@scott> <1ECE0EB50388174790F9694F77522CCF1E727FEF@zrc2hxm0.corp.nortel.com> Content-Type: text/plain Organization: Nortel Networks Date: Fri, 12 Jun 2009 15:36:30 -0400 Message-Id: <1244835390.3768.62.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: 12 Jun 2009 19:36:31.0492 (UTC) FILETIME=[16619C40:01C9EB95] Cc: SIP Operations , RAI DISPATCH 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 19:36:29 -0000 On Thu, 2009-06-11 at 08:47 -0500, Mary Barnes wrote: > There seems to be sufficient interest in this topic to warrant f2f > agenda time in Stockholm. However, additional feedback prior to IETF-75 > is necessary to ensure that progress can be made in Stockholm. It looks like a good description of the problem. Since the I-D is not to discuss solutions, I'm not sure what there is to discuss until we open the discussion to solutions. Dale From HKaplan@acmepacket.com Fri Jun 12 12:48:46 2009 Return-Path: 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 CF6E33A6812 for ; Fri, 12 Jun 2009 12:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 mBaDWCVQrasd for ; Fri, 12 Jun 2009 12:48:46 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id E85A33A67E1 for ; Fri, 12 Jun 2009 12:48:45 -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, 12 Jun 2009 15:48:53 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 12 Jun 2009 15:48:53 -0400 From: Hadriel Kaplan To: Roni Even , "'James M. Polk'" , 'Francois Audet' , 'Paul Kyzivat' Date: Fri, 12 Jun 2009 15:48:50 -0400 Thread-Topic: [dispatch] Session recording in SIP Thread-Index: AcnrG3JEvhllHX5rR1WgmQaf/pD/vgAAgQrQAAOAHmAAEgmd8A== Message-ID: References: <00fc01c9eb2e$672e99a0$358bcce0$%roni@huawei.com> In-Reply-To: <00fc01c9eb2e$672e99a0$358bcce0$%roni@huawei.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 Cc: 'Leon Portman' , "dispatch@ietf.org" , "'Jain, Rajnish'" Subject: Re: [dispatch] Session recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 19:48:46 -0000 I agree that assuming SIP is the protocol between the recordee and the reco= rder is probably premature, but I still don't see it as making us have to c= hoose whether to support a UA vs. a B2BUA. =20 I mean even from a logical perspective, a UA could just pretend to be an in= tegrated B2BUA to itself and who would know? I.e., this: UA-A +----------------------+ | +-----+ +-----+ | +-----+ | | | | | | Call | | | | UA +<---->+B2BUA+<+----------->+UA-B | | | | | | | | | | +-----+ +-++--+ | +-----+ +-----------------\\---+ \\ TBD \\ \\+----------+ \+ | + Recorder | | | +----------+ -hadriel > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Roni Even > Sent: Friday, June 12, 2009 3:21 AM >=20 > I think that there may be a different protocol if you use the B2BUA > solution. In this case it will make more sense to use a "mediactrl" > direction where SIP is used to open a control channel to the recorder but > the recording protocol itself runs in the control channel. This control > channel will be also used to deliver the meta data for the recording. So > maybe the sentence " SIP based protocol interface between a > communications > system and a recorder" is limiting the solution space. >=20 > Roni Even From jdrosen@cisco.com Fri Jun 12 12:50:33 2009 Return-Path: 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 7F8933A67E1 for ; Fri, 12 Jun 2009 12:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 S9ZXF9US+-5x for ; Fri, 12 Jun 2009 12:50:32 -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 BB9673A65A6 for ; Fri, 12 Jun 2009 12:50:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,211,1243814400"; d="scan'208";a="47140306" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 12 Jun 2009 19:50:39 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n5CJobLh024256; Fri, 12 Jun 2009 15:50:37 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n5CJocI8004224; Fri, 12 Jun 2009 19:50:38 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Jun 2009 15:50:38 -0400 Received: from [10.82.235.189] ([10.82.235.189]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Jun 2009 15:50:38 -0400 Message-ID: <4A32B18A.3010309@cisco.com> Date: Fri, 12 Jun 2009 15:50:34 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jun 2009 19:50:38.0279 (UTC) FILETIME=[0F1B0D70:01C9EB97] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8938; t=1244836237; x=1245700237; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[dispatch]=20Session=20recording=20in=2 0SIP |Sender:=20 |To:=20=22DRAGE,=20Keith=20(Keith)=22=20; bh=/DwO+cgyv7LQWs3Tk8WlvFG4Z21vRRfwGXljeWxLmr4=; b=uMP/CQ92sCSm3iA0zGTEIHf5WOB8ibEUKv9K7UvgfggI/gH2BrW8xttP4K Zi2TAFLlRW1xklOZuI12MsTjelESvDwN/OVU9PQNHSY5lauqihrfnbVj8LrM 8R01OsJYCp; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: 'Leon Portman' , "dispatch@ietf.org" , "'Jain, Rajnish'" , Hadriel Kaplan , Roni Even Subject: Re: [dispatch] Session recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 19:50:33 -0000 I'll add - from a dispatch perspective - that the liveliness of this discussion, and the breadth of opinions/options on architecture - show pretty clearly that this is big enough to warrant its own group, rather than just another thing to do in AVT or XCON. -Jonathan R. DRAGE, Keith (Keith) wrote: > I have no response to any of the other points, but please note that for 1), in the scenarios of call centres, some jurisdictions do require the client to be informed that the call is being recorded. Normally this is done by a verbal announcement. > > So in those use cases, 1) is a non-argument. > > regards > > Keith > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Francois Audet >> Sent: Friday, June 12, 2009 4:43 AM >> To: James M. Polk; Paul Kyzivat; Hadriel Kaplan >> Cc: 'Leon Portman'; dispatch@ietf.org; 'Jain, Rajnish'; Roni Even >> Subject: Re: [dispatch] Session recording in SIP >> >> I agree with James. >> >> There are *some* scenarios where the UA-initiated recording >> will work, but they are very limited. They have the following >> disadvantages: >> 1- It makes the client "aware" that it is being recorded >> 2- It makes it very easy to avoid being recorded by >> interrupting the media stream >> 3 - It makes it much easier to "dispute" (i.e., lawyers) the >> authenticity of a recorded conversation if there is potential >> for significant differences in the streams as seen by different ends >> 4 - It doubles the bandwidth requirements on the UA, which >> can be a problem in some scenarios >> 5 - It doubles the processing power required in the client >> (think SRTP/key negotiation & al). This can be a problem with >> many phones. >> 6 - They require phones that actually support this. Which >> means, you can't use "normal" SIP phones. Which means, if >> you get the $30 phone, you don't get tapped into, but if you >> get the $300 phone, you don't. >> >> >> But UA-initiated recording has very few advantages: >> 1 - Less work on servers. This is actually a big advantage >> because lots of servers are so complex, it is difficult to do >> anything new on them. >> 2 - Looks much more abstract and cool in an IETF RFC :-) >> >> >> On Jun11 2009 19:13 , "James M. Polk" wrote: >> >>> At 06:11 PM 6/11/2009, Paul Kyzivat wrote: >>> >>> >>>> Hadriel Kaplan wrote: >>>>> Hey Roni, >>>>> Being a middlebox man myself, a B2BUA doing the media >> forking makes >>>>> the most sense to me too, but some other folks don't do >> it/want-it >>>>> that way. So the proposed work is to cover both potential models. >>>>> The statement you cite reflects the belief that the >> solution to the >>>>> requirements will be to use SIP between the UA doing the media >>>>> forking, and the recorder doing the collection; and that >> the work of >>>>> specification will be to define that. >>>>> So one diagram could be this, where "TBD" is the >> To-Be-Defined work: >>>>> +-----+ +-----+ >>>>> | | Call | | >>>>> |UA-A +<------------>+UA-B | >>>>> | | | | >>>>> +-++--+ +-----+ >>>>> \\ >>>>> \\ >>>>> TBD \\ >>>>> \\+----------+ >>>>> \+ | >>>>> + Recorder | >>>>> | | >>>>> +----------+ >>>> This model actually can make a lot of sense in *some* >> circumstances. >>>> For instance, in a call center, where you may have control >> over what >>>> components are used throughout, it could make sense to do >> the media >>>> forking for recording and monitoring right at the agent phone. >>> Paul - how is your call center example *not* better >> accomplished with >>> the figure below instead of the figure above? >>> >>> It seems to me that any enterprise based call center would have to >>> have a SIP server of some form (i.e., the caller is not >> going to have >>> a pt-to-pt SIP established session directly with a call center call >>> taker). It seems much easier if that call center wants to >> record calls >>> (even some of the calls, that to the caller, the B2BUA is the UAS, >>> meaning the sRTP keys only have to be between the caller and the >>> B2BUA, and not all the way to the call taker. In this >> scenario, the >>> B2BUA merely replicates the RTP stream out towards the recording >>> device with RTCP in tact, an can allow the B2BUA provide >> any meta data >>> about the specifics of the call signaling it wants to also store. >>> >>> This scenario also means the caller is never aware the call >> is being >>> recorded, creating anonymity wrt that facet of the solution. >>> >>> I'm not advocating B2BUAs here, I just see this as a better >> solution >>> for call center type recording than pt-to-pt between caller >> and call taker. >>> >>>> But in those sorts of monitoring/recording we don't talk about in >>>> IETF, its essential that the recorded parties not be able to >>>> distinguish calls that are monitored from those that are not. >>>> Anything that requires cooperation by one of the endpoints is a >>>> no-go. Even something as simple as a middlebox replacing one media >>>> port with another in order to initiate monitoring might be >> enough to >>>> clue in the monitored parties. So in those cases you had >> better have >>>> a way that looks exactly the same whether recording is >> happening or >>>> not, which generally requires something like your picture below. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Or this: >>>>> >>>>> +-----+ +-----+ +-----+ >>>>> | | Call | | Call | | >>>>> |UA-A +<------------>+B2BUA+<------------>+UA-B | >>>>> | | | | | | >>>>> +-----+ +-++--+ +-----+ >>>>> \\ >>>>> \\ >>>>> TBD \\ >>>>> \\+----------+ >>>>> \+ | >>>>> + Recorder | >>>>> | | >>>>> +----------+ -hadriel >>>>> >>>>>> -----Original Message----- >>>>>> From: Roni Even [mailto:Even.roni@huawei.com] >>>>>> Sent: Thursday, June 11, 2009 3:54 PM >>>>>> To: Hadriel Kaplan; 'Hutton, Andrew'; 'Alan Johnston'; >> 'Romascanu, >>>>>> Dan (Dan)' >>>>>> Cc: 'Leon Portman'; dispatch@ietf.org; 'Jain, Rajnish' >>>>>> Subject: RE: [dispatch] Session recording in SIP >>>>>> >>>>>> Hadriel, >>>>>> I am still confused by the following text which was the >> reason for >>>>>> the previous question >>>>>> >>>>>> "This group will specify requirements for a SIP based protocol >>>>>> interface between a communications system and a recorder. The >>>>>> Communications System is responsible for establishing media >>>>>> sessions where the actual business is conducted. The Recorder is >>>>>> the sink of the recorded media." >>>>>> >>>>>> >>>>>> Can someone draw a figure showing the talking parties the >>>>>> Communication system and the recorder and explain where is this >>>>>> interface. According to your response I can think that >> there are at >>>>>> least two separate architectures your are proposing one >> where the >>>>>> parties (or one of them) in the call know the recorder >> and somehow >>>>>> forwards the media to it. The other architecture has >> some B2BUA in >>>>>> the call path who is either forking the media to the >> recorder and >>>>>> to the parties or the recorder is in the middle of the >> media path. >>>>> _______________________________________________ >>>>> 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 > -- Jonathan D. Rosenberg, Ph.D. 111 Wood Avenue South Cisco Fellow Iselin, NJ 08830 Cisco, Voice Technology Group jdrosen@cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com From HKaplan@acmepacket.com Fri Jun 12 13:08:10 2009 Return-Path: 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 9D6CD3A6826 for ; Fri, 12 Jun 2009 13:08:10 -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.550, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, J_CHICKENPOX_44=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 GGU0mvGIsX4j for ; Fri, 12 Jun 2009 13:08:09 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id B62463A681D for ; Fri, 12 Jun 2009 13:08:09 -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, 12 Jun 2009 16:08:16 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 12 Jun 2009 16:08:16 -0400 From: Hadriel Kaplan To: Roni Even , "'James M. Polk'" , 'Paul Kyzivat' Date: Fri, 12 Jun 2009 16:08:04 -0400 Thread-Topic: [dispatch] Session recording in SIP Thread-Index: AcnrA26dn6plCZIkQuayysm7FRTQJgAKyLQQABplEqA= Message-ID: References: <4A2ECDB2.7000601@alcatel-lucent.com> <4A2FB842.7050302@sipstation.com> <028a01c9ea12$5ec96e60$1c5c4b20$%roni@huawei.com> <719F9BBB3E7E71428A2D13F3D76C768F01C7BBE8@GBNTHT12009MSX.gb002.siemens.net> <002801c9ea82$0da51320$28ef3960$%roni@huawei.com> <719F9BBB3E7E71428A2D13F3D76C768F01C7BE97@GBNTHT12009MSX.gb002.siemens.net> <004a01c9eaa7$94ef7990$bece6cb0$%roni@huawei.com> <00ab01c9eace$58b7c190$0a2744b0$%roni@huawei.com> <4A318F1E.9080308@cisco.com> <00fd01c9eb2f$39fa3920$adeeab60$%roni@huawei.com> In-Reply-To: <00fd01c9eb2f$39fa3920$adeeab60$%roni@huawei.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 Cc: 'Leon Portman' , "dispatch@ietf.org" , "'Jain, Rajnish'" Subject: Re: [dispatch] Session recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 20:08:10 -0000 Huh, interesting idea. I don't see how that could easily work though. The= recorder needs to be able to associate specific audio streams with specifi= c calls, and from which called/calling party they came. Unless there's a c= ontrol channel between each UA and the recorder, you'd have to somehow get = the B2BUA to know what IP:port each UA can send the forked media from, and = provide each UA with the addr:port of the Recorder to send the forked media= to. Not to mention if we decide to allow a different codec to be used on = the forked-media connection vs. the in-call side (which I personally don't = like the idea of but others do). At the end of the day, I'd bet you'd have= one complicated protocol for all that to occur, with a bunch of re-INVITEs= /UPDATEs and all kinds of whacked corner-cases with pre-conditions, and IPv= 4/v6, and god-knows-what else. :) -hadriel > -----Original Message----- > From: Roni Even [mailto:Even.roni@huawei.com] > Sent: Friday, June 12, 2009 3:27 AM >=20 > James, > The B2BUA does not need to see the RTP/RTCP stream they can go directly > from > the source to the recorder >=20 >=20 > +-----+ +-----+ +-----+ > | | Call | | Call | | > |UA-A +<------------>+B2BUA+<------------>+UA-B | > | | | | | | > +-----+ +-++--+ +-----+ > . \\ . > . \\ control . > . RTP TBD \\ .RTP > . \\+----------+ . > . \+ |..... > . + Recorder | > | | > +----------+ >=20 > Roni =20 From mary.barnes@nortel.com Fri Jun 12 13:52:25 2009 Return-Path: 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 367653A6897; Fri, 12 Jun 2009 13:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.467 X-Spam-Level: X-Spam-Status: No, score=-6.467 tagged_above=-999 required=5 tests=[AWL=0.132, 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 WHwGXKm7o94h; Fri, 12 Jun 2009 13:52:24 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 0CBDA3A6862; Fri, 12 Jun 2009 13:52:23 -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 n5CKp9121134; Fri, 12 Jun 2009 20:51:09 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, 12 Jun 2009 15:54:30 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E7D859B@zrc2hxm0.corp.nortel.com> In-Reply-To: <1244835390.3768.62.camel@victoria-pingtel-com.us.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] draft-lawrence-sip-3rd-party-authorization-00 Thread-Index: AcnrlRbDZvGjDVZ5TPir0s0fgoUX3gACCmqg References: <1241379400.3528.50.camel@scott> <1ECE0EB50388174790F9694F77522CCF1E727FEF@zrc2hxm0.corp.nortel.com> <1244835390.3768.62.camel@victoria-pingtel-com.us.nortel.com> From: "Mary Barnes" To: "Dale Worley" Cc: SIP Operations , RAI DISPATCH 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 20:52:25 -0000 Correct - we are not discussing solutions because we don't develop solutions in DISPATCH. =20 The idea in DISPATCH if folks agree that there is a problem, is to then determine the scope of the problem to be solved - that's not been entirely concluded for this topic. If that can happen on the ML prior to Stockholm, then certainly no f2f time is needed - really the ideal operation of DISPATCH is that we don't need f2f time - i.e., work comes in, we figure out the scope of the problem, whether there is critical mass in the WG in terms of contributing to the work and then figure out whether we need a new WG, a BoF, an individual/AD doc, etc. =20 At this point, for this topic, there has not yet been a critical mass in terms of feedback on the proposal - that's what we're asking for now. Basically, we are still dealing with the "...what part or parts of that problem need to be solved" aspect of this topic. If we don't get more input it is highly unlikely that any progress could be made on this topic in Stockholm, which would put us at the point that you are suggesting we are now in terms of having nothing to discuss. That was the implication of my "However...". I'll be more blunt next time.=20 Thanks, Mary.=20 -----Original Message----- From: Worley, Dale (BL60:9D30)=20 Sent: Friday, June 12, 2009 2:37 PM To: Barnes, Mary (RICH2:AR00) Cc: RAI DISPATCH; SIP Operations Subject: Re: [dispatch] draft-lawrence-sip-3rd-party-authorization-00 On Thu, 2009-06-11 at 08:47 -0500, Mary Barnes wrote: > There seems to be sufficient interest in this topic to warrant f2f=20 > agenda time in Stockholm. However, additional feedback prior to=20 > IETF-75 is necessary to ensure that progress can be made in Stockholm. It looks like a good description of the problem. Since the I-D is not to discuss solutions, I'm not sure what there is to discuss until we open the discussion to solutions. Dale From scott.lawrence@nortel.com Fri Jun 12 14:04:32 2009 Return-Path: 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 015893A6A2A for ; Fri, 12 Jun 2009 14:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 VGgvP+wNJPGn for ; Fri, 12 Jun 2009 14:04:31 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 94C6C3A6A29 for ; Fri, 12 Jun 2009 14:04:29 -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 n5CL2w127277 for ; Fri, 12 Jun 2009 21:02:59 GMT Received: from [127.0.0.1] ([47.17.25.99]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Jun 2009 17:04:14 -0400 From: "Scott Lawrence" To: "dispatch@ietf.org" In-Reply-To: <4A32B18A.3010309@cisco.com> References: <4A32B18A.3010309@cisco.com> Content-Type: text/plain Organization: Nortel Networks Date: Fri, 12 Jun 2009 17:04:13 -0400 Message-Id: <1244840653.21162.349.camel@scott> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-1.fc10) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jun 2009 21:04:14.0872 (UTC) FILETIME=[5799A980:01C9EBA1] Subject: Re: [dispatch] Session recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 21:04:32 -0000 On Fri, 2009-06-12 at 15:50 -0400, Jonathan Rosenberg wrote: > I'll add - from a dispatch perspective - that the liveliness of this > discussion, and the breadth of opinions/options on architecture - show > pretty clearly that this is big enough to warrant its own group, rather > than just another thing to do in AVT or XCON. I certainly support getting some clarity around how to do this cleanly. I'm not crazy about some of the ideas thrown around so far, but the need is clear. I also agree with previous posters that while this overlaps with XCON and some other things, it's really a distinct problem and would probably be solvable more quickly in a more focused setting. One of the major ideas behind our recent reorg was that smaller, more time-limited WGs will work better than the perpetual ones we've been using. From Even.roni@huawei.com Fri Jun 12 14:09:01 2009 Return-Path: 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 5F9033A697C for ; Fri, 12 Jun 2009 14:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.025 X-Spam-Level: X-Spam-Status: No, score=0.025 tagged_above=-999 required=5 tests=[AWL=-0.680, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_24=0.6, J_CHICKENPOX_44=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6BqHXFdMq9Pj for ; Fri, 12 Jun 2009 14:09:00 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 7ACF53A681D for ; Fri, 12 Jun 2009 14:09:00 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KL50016K9EYCQ@szxga02-in.huawei.com> for dispatch@ietf.org; Sat, 13 Jun 2009 05:08:58 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KL500IVU9EYEA@szxga02-in.huawei.com> for dispatch@ietf.org; Sat, 13 Jun 2009 05:08:58 +0800 (CST) Received: from windows8d787f9 (bzq-79-177-76-15.red.bezeqint.net [79.177.76.15]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KL500JFC9ESR5@szxml01-in.huawei.com>; Sat, 13 Jun 2009 05:08:58 +0800 (CST) Date: Sat, 13 Jun 2009 00:07:17 +0300 From: Roni Even In-reply-to: To: 'Hadriel Kaplan' , "'James M. Polk'" , 'Paul Kyzivat' Message-id: <018c01c9eba1$c83c5930$58b50b90$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcnrA26dn6plCZIkQuayysm7FRTQJgAKyLQQABplEqAAAj/V0A== References: <4A2ECDB2.7000601@alcatel-lucent.com> <4A2FB842.7050302@sipstation.com> <028a01c9ea12$5ec96e60$1c5c4b20$%roni@huawei.com> <719F9BBB3E7E71428A2D13F3D76C768F01C7BBE8@GBNTHT12009MSX.gb002.siemens.net> <002801c9ea82$0da51320$28ef3960$%roni@huawei.com> <719F9BBB3E7E71428A2D13F3D76C768F01C7BE97@GBNTHT12009MSX.gb002.siemens.net> <004a01c9eaa7$94ef7990$bece6cb0$%roni@huawei.com> <00ab01c9eace$58b7c190$0a2744b0$%roni@huawei.com> <4A318F1E.9080308@cisco.com> <00fd01c9eb2f$39fa3920$adeeab60$%roni@huawei.com> Cc: 'Leon Portman' , dispatch@ietf.org, "'Jain, Rajnish'" Subject: Re: [dispatch] Session recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 21:09:01 -0000 Hadriel, This is what mediactrl is about. Look in http://tools.ietf.org/html/rfc5567 Roni -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Friday, June 12, 2009 11:08 PM To: Roni Even; 'James M. Polk'; 'Paul Kyzivat' Cc: 'Leon Portman'; dispatch@ietf.org; 'Jain, Rajnish' Subject: Re: [dispatch] Session recording in SIP Huh, interesting idea. I don't see how that could easily work though. The recorder needs to be able to associate specific audio streams with specific calls, and from which called/calling party they came. Unless there's a control channel between each UA and the recorder, you'd have to somehow get the B2BUA to know what IP:port each UA can send the forked media from, and provide each UA with the addr:port of the Recorder to send the forked media to. Not to mention if we decide to allow a different codec to be used on the forked-media connection vs. the in-call side (which I personally don't like the idea of but others do). At the end of the day, I'd bet you'd have one complicated protocol for all that to occur, with a bunch of re-INVITEs/UPDATEs and all kinds of whacked corner-cases with pre-conditions, and IPv4/v6, and god-knows-what else. :) -hadriel > -----Original Message----- > From: Roni Even [mailto:Even.roni@huawei.com] > Sent: Friday, June 12, 2009 3:27 AM > > James, > The B2BUA does not need to see the RTP/RTCP stream they can go directly > from > the source to the recorder > > > +-----+ +-----+ +-----+ > | | Call | | Call | | > |UA-A +<------------>+B2BUA+<------------>+UA-B | > | | | | | | > +-----+ +-++--+ +-----+ > . \\ . > . \\ control . > . RTP TBD \\ .RTP > . \\+----------+ . > . \+ |..... > . + Recorder | > | | > +----------+ > > Roni _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From Even.roni@huawei.com Fri Jun 12 14:16:35 2009 Return-Path: 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 914F73A697C for ; Fri, 12 Jun 2009 14:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.514 X-Spam-Level: X-Spam-Status: No, score=-0.514 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id laaey-kT9AL7 for ; Fri, 12 Jun 2009 14:16:34 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id C305D3A681D for ; Fri, 12 Jun 2009 14:16:34 -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 <0KL5008SX9RKVR@szxga04-in.huawei.com> for dispatch@ietf.org; Sat, 13 Jun 2009 05:16:32 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KL5007U19RKXO@szxga04-in.huawei.com> for dispatch@ietf.org; Sat, 13 Jun 2009 05:16:32 +0800 (CST) Received: from windows8d787f9 (bzq-79-177-76-15.red.bezeqint.net [79.177.76.15]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KL500MK39RG3C@szxml02-in.huawei.com>; Sat, 13 Jun 2009 05:16:32 +0800 (CST) Date: Sat, 13 Jun 2009 00:14:53 +0300 From: Roni Even In-reply-to: <1244840653.21162.349.camel@scott> To: 'Scott Lawrence' , dispatch@ietf.org Message-id: <019301c9eba2$d731e350$8595a9f0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcnroWonuEmBcLXwRGKSlA2bQymN6QAAOLvQ References: <4A32B18A.3010309@cisco.com> <1244840653.21162.349.camel@scott> Subject: Re: [dispatch] Session recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 21:16:35 -0000 Hi, I think that RAI have two wgs working on different aspects of a central server. One is XCON and the other is Mediactrl. I think that once an architecture for the recorder is specified it may be just another application (recording application) that can be based on one of these two WGs work. Recording is just another application for a central server or media server like conferencing, IVR, and others. Recording was even discussed in mediactrl but there were no requirement at the time. Roni Even -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Scott Lawrence Sent: Saturday, June 13, 2009 12:04 AM To: dispatch@ietf.org Subject: Re: [dispatch] Session recording in SIP On Fri, 2009-06-12 at 15:50 -0400, Jonathan Rosenberg wrote: > I'll add - from a dispatch perspective - that the liveliness of this > discussion, and the breadth of opinions/options on architecture - show > pretty clearly that this is big enough to warrant its own group, rather > than just another thing to do in AVT or XCON. I certainly support getting some clarity around how to do this cleanly. I'm not crazy about some of the ideas thrown around so far, but the need is clear. I also agree with previous posters that while this overlaps with XCON and some other things, it's really a distinct problem and would probably be solvable more quickly in a more focused setting. One of the major ideas behind our recent reorg was that smaller, more time-limited WGs will work better than the perpetual ones we've been using. _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From HKaplan@acmepacket.com Fri Jun 12 14:54:39 2009 Return-Path: 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 4B8D83A697C for ; Fri, 12 Jun 2009 14:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.87 X-Spam-Level: X-Spam-Status: No, score=-1.87 tagged_above=-999 required=5 tests=[AWL=-0.471, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, J_CHICKENPOX_44=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 YKY7Zlcy+xF3 for ; Fri, 12 Jun 2009 14:54:38 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 3F5AF3A68C1 for ; Fri, 12 Jun 2009 14:54:38 -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, 12 Jun 2009 17:54:44 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 12 Jun 2009 17:54:44 -0400 From: Hadriel Kaplan To: Roni Even , "'James M. Polk'" , 'Paul Kyzivat' Date: Fri, 12 Jun 2009 17:54:19 -0400 Thread-Topic: [dispatch] Session recording in SIP Thread-Index: AcnrA26dn6plCZIkQuayysm7FRTQJgAKyLQQABplEqAAAj/V0AAAcNKQ Message-ID: References: <4A2ECDB2.7000601@alcatel-lucent.com> <4A2FB842.7050302@sipstation.com> <028a01c9ea12$5ec96e60$1c5c4b20$%roni@huawei.com> <719F9BBB3E7E71428A2D13F3D76C768F01C7BBE8@GBNTHT12009MSX.gb002.siemens.net> <002801c9ea82$0da51320$28ef3960$%roni@huawei.com> <719F9BBB3E7E71428A2D13F3D76C768F01C7BE97@GBNTHT12009MSX.gb002.siemens.net> <004a01c9eaa7$94ef7990$bece6cb0$%roni@huawei.com> <00ab01c9eace$58b7c190$0a2744b0$%roni@huawei.com> <4A318F1E.9080308@cisco.com> <00fd01c9eb2f$39fa3920$adeeab60$%roni@huawei.com> <018c01c9eba1$c83c5930$58b50b90$%roni@huawei.com> In-Reply-To: <018c01c9eba1$c83c5930$58b50b90$%roni@huawei.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 Cc: 'Leon Portman' , "dispatch@ietf.org" , "'Jain, Rajnish'" Subject: Re: [dispatch] Session recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 21:54:39 -0000 I was about to write a long-winded reply on how your example was not the sa= me as mediactrl, but I just realized your drawing was subtly different from= what I had thought it implied. :) The example you're describing is one wh= ere the recorder is not being sent forked/replicated media content by the U= A's, but is just put in the media path itself for the real media, so the or= iginal media itself is going from UA to recorder to UA.=20 Right? If so, good point - I assume that's one possible deployment model to use. = I don't think it's how some (most?) people do it, because they can't or don= 't want to move the media path from where it began, especially for the UA s= ide that's outside their domain. (though I dunno much about why they do wh= at they do) But it is one interesting solution. -hadriel > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Roni Even > Sent: Friday, June 12, 2009 5:07 PM > To: Hadriel Kaplan; 'James M. Polk'; 'Paul Kyzivat' > Cc: 'Leon Portman'; dispatch@ietf.org; 'Jain, Rajnish' > Subject: Re: [dispatch] Session recording in SIP >=20 > Hadriel, > This is what mediactrl is about. Look in > http://tools.ietf.org/html/rfc5567 >=20 > Roni >=20 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf > Of Hadriel Kaplan > Sent: Friday, June 12, 2009 11:08 PM > To: Roni Even; 'James M. Polk'; 'Paul Kyzivat' > Cc: 'Leon Portman'; dispatch@ietf.org; 'Jain, Rajnish' > Subject: Re: [dispatch] Session recording in SIP >=20 >=20 > Huh, interesting idea. I don't see how that could easily work though. > The > recorder needs to be able to associate specific audio streams with > specific > calls, and from which called/calling party they came. Unless there's a > control channel between each UA and the recorder, you'd have to somehow > get > the B2BUA to know what IP:port each UA can send the forked media from, an= d > provide each UA with the addr:port of the Recorder to send the forked > media > to. Not to mention if we decide to allow a different codec to be used on > the forked-media connection vs. the in-call side (which I personally don'= t > like the idea of but others do). At the end of the day, I'd bet you'd > have > one complicated protocol for all that to occur, with a bunch of > re-INVITEs/UPDATEs and all kinds of whacked corner-cases with > pre-conditions, and IPv4/v6, and god-knows-what else. :) >=20 > -hadriel >=20 > > -----Original Message----- > > From: Roni Even [mailto:Even.roni@huawei.com] > > Sent: Friday, June 12, 2009 3:27 AM > > > > James, > > The B2BUA does not need to see the RTP/RTCP stream they can go directly > > from > > the source to the recorder > > > > > > +-----+ +-----+ +-----+ > > | | Call | | Call | | > > |UA-A +<------------>+B2BUA+<------------>+UA-B | > > | | | | | | > > +-----+ +-++--+ +-----+ > > . \\ . > > . \\ control . > > . RTP TBD \\ .RTP > > . \\+----------+ . > > . \+ |..... > > . + Recorder | > > | | > > +----------+ > > > > Roni >=20 > _______________________________________________ > 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 From Even.roni@huawei.com Sat Jun 13 23:49:30 2009 Return-Path: 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 002043A6A6D for ; Sat, 13 Jun 2009 23:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.856 X-Spam-Level: X-Spam-Status: No, score=-0.856 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, J_CHICKENPOX_44=0.6, URIBL_RHS_DOB=1.083] 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 uhkWNUgz94nO for ; Sat, 13 Jun 2009 23:49:29 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id AC74D3A686C for ; Sat, 13 Jun 2009 23:49:28 -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 <0KL700IAKUYOV2@szxga04-in.huawei.com> for dispatch@ietf.org; Sun, 14 Jun 2009 14:49:36 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KL700DVNUYO6T@szxga04-in.huawei.com> for dispatch@ietf.org; Sun, 14 Jun 2009 14:49:36 +0800 (CST) Received: from windows8d787f9 (bzq-79-183-127-37.red.bezeqint.net [79.183.127.37]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KL70046IUYB7C@szxml02-in.huawei.com>; Sun, 14 Jun 2009 14:49:36 +0800 (CST) Date: Sun, 14 Jun 2009 09:47:44 +0300 From: Roni Even In-reply-to: To: "'Jain, Rajnish'" , 'Hadriel Kaplan' , "'James M. Polk'" , 'Paul Kyzivat' Message-id: <01cd01c9ecbc$0cfc7c10$26f57430$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcnrA26dn6plCZIkQuayysm7FRTQJgAKyLQQABplEqAAAj/V0AAAcNKQADvJEYAACgT6EA== References: <4A2ECDB2.7000601@alcatel-lucent.com> <4A2FB842.7050302@sipstation.com> <028a01c9ea12$5ec96e60$1c5c4b20$%roni@huawei.com> <719F9BBB3E7E71428A2D13F3D76C768F01C7BBE8@GBNTHT12009MSX.gb002.siemens.net> <002801c9ea82$0da51320$28ef3960$%roni@huawei.com> <719F9BBB3E7E71428A2D13F3D76C768F01C7BE97@GBNTHT12009MSX.gb002.siemens.net> <004a01c9eaa7$94ef7990$bece6cb0$%roni@huawei.com> <00ab01c9eace$58b7c190$0a2744b0$%roni@huawei.com> <4A318F1E.9080308@cisco.com> <00fd01c9eb2f$39fa3920$adeeab60$%roni@huawei.com> <018c01c9eba1$c83c5930$58b50b90$%roni@huawei.com> Cc: 'Leon Portman' , dispatch@ietf.org Subject: Re: [dispatch] Session recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2009 06:49:30 -0000 Hi, This is a good observation but in the conferencing case you can have the media coming not from the UAs but from the media mixer or have the mixer functionality as part of the recorder. I understand the UA forking scenario for the call center application where the UAs in the call center will be required to support this functionality. Note that in this case if you have a multipoint video call you are recording just what the UA receives (you record the view point of the recording UA) and not the whole conference. If the handling UA is recording you may also miss in the call center scenario any side discussion between the customer and a supervisor if the handling UA is excluded from this part, in some cases he will not even know about being kept out of some side call. The general case is where you want to record a call but do not have the media forking and recording application on your UA. In this case my view is that you will need a recording application server in the network. It will need to record both point to point and multipoint calls. It can be like suggested by Hadriel where the RTP streams are forked by the Application Server (note that I am not calling it a general B2BUA) or using a decomposed Application Server like the mediactrl architecture. Roni Even -----Original Message----- From: Jain, Rajnish [mailto:Rajnish.Jain@ipc.com] Sent: Sunday, June 14, 2009 4:54 AM To: Hadriel Kaplan; Roni Even; 'James M. Polk'; 'Paul Kyzivat' Cc: 'Leon Portman'; dispatch@ietf.org Subject: RE: [dispatch] Session recording in SIP I think the UA-UA RTP line was missing in the diagram. Otherwise, the recorder is being expected to do conferencing (assuming more than 2 recordee UAs) and transcoding. That's really not the purpose of the recorders. -- Raj Jain -----Original Message----- From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Sent: Friday, June 12, 2009 5:54 PM To: Roni Even; 'James M. Polk'; 'Paul Kyzivat' Cc: 'Leon Portman'; dispatch@ietf.org; Jain, Rajnish Subject: RE: [dispatch] Session recording in SIP I was about to write a long-winded reply on how your example was not the same as mediactrl, but I just realized your drawing was subtly different from what I had thought it implied. :) The example you're describing is one where the recorder is not being sent forked/replicated media content by the UA's, but is just put in the media path itself for the real media, so the original media itself is going from UA to recorder to UA. Right? If so, good point - I assume that's one possible deployment model to use. I don't think it's how some (most?) people do it, because they can't or don't want to move the media path from where it began, especially for the UA side that's outside their domain. (though I dunno much about why they do what they do) But it is one interesting solution. -hadriel > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Roni Even > Sent: Friday, June 12, 2009 5:07 PM > To: Hadriel Kaplan; 'James M. Polk'; 'Paul Kyzivat' > Cc: 'Leon Portman'; dispatch@ietf.org; 'Jain, Rajnish' > Subject: Re: [dispatch] Session recording in SIP > > Hadriel, > This is what mediactrl is about. Look in > http://tools.ietf.org/html/rfc5567 > > Roni > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf > Of Hadriel Kaplan > Sent: Friday, June 12, 2009 11:08 PM > To: Roni Even; 'James M. Polk'; 'Paul Kyzivat' > Cc: 'Leon Portman'; dispatch@ietf.org; 'Jain, Rajnish' > Subject: Re: [dispatch] Session recording in SIP > > > Huh, interesting idea. I don't see how that could easily work though. > The > recorder needs to be able to associate specific audio streams with > specific > calls, and from which called/calling party they came. Unless there's a > control channel between each UA and the recorder, you'd have to somehow > get > the B2BUA to know what IP:port each UA can send the forked media from, and > provide each UA with the addr:port of the Recorder to send the forked > media > to. Not to mention if we decide to allow a different codec to be used on > the forked-media connection vs. the in-call side (which I personally don't > like the idea of but others do). At the end of the day, I'd bet you'd > have > one complicated protocol for all that to occur, with a bunch of > re-INVITEs/UPDATEs and all kinds of whacked corner-cases with > pre-conditions, and IPv4/v6, and god-knows-what else. :) > > -hadriel > > > -----Original Message----- > > From: Roni Even [mailto:Even.roni@huawei.com] > > Sent: Friday, June 12, 2009 3:27 AM > > > > James, > > The B2BUA does not need to see the RTP/RTCP stream they can go directly > > from > > the source to the recorder > > > > > > +-----+ +-----+ +-----+ > > | | Call | | Call | | > > |UA-A +<------------>+B2BUA+<------------>+UA-B | > > | | | | | | > > +-----+ +-++--+ +-----+ > > . \\ . > > . \\ control . > > . RTP TBD \\ .RTP > > . \\+----------+ . > > . \+ |..... > > . + Recorder | > > | | > > +----------+ > > > > Roni > > _______________________________________________ > 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 DISCLAIMER: This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unintended recipients are prohibited from taking action on the basis of information in this e-mail.E-mail messages may contain computer viruses or other defects, may not be accurately replicated on other systems, or may be intercepted, deleted or interfered with without the knowledge of the sender or the intended recipient. If you are not comfortable with the risks associated with e-mail messages, you may decide not to use e-mail to communicate with IPC. IPC reserves the right, to the extent and under circumstances permitted by applicable law, to retain, monitor and intercept e-mail messages to and from its systems. From rajnish.jain@ipc.com Sat Jun 13 18:54:27 2009 Return-Path: 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 6AEA93A695B for ; Sat, 13 Jun 2009 18:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.316 X-Spam-Level: X-Spam-Status: No, score=-0.316 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_24=0.6, J_CHICKENPOX_44=0.6, URIBL_RHS_DOB=1.083] 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 gcqQQDobBczi for ; Sat, 13 Jun 2009 18:54:26 -0700 (PDT) Received: from p01c12o144.mxlogic.net (p01c12o144.mxlogic.net [208.65.145.67]) by core3.amsl.com (Postfix) with ESMTP id 58A0F3A6805 for ; Sat, 13 Jun 2009 18:54:26 -0700 (PDT) Received: from unknown [65.244.37.52] (EHLO p01c12o144.mxlogic.net) by p01c12o144.mxlogic.net (mxl_mta-6.2.0-4) with ESMTP id b58543a4.3106868112.104280.00-504.p01c12o144.mxlogic.net (envelope-from ); Sat, 13 Jun 2009 19:54:35 -0600 (MDT) Received: from unknown [65.244.37.52] (EHLO smtp.ipc.com) by p01c12o144.mxlogic.net (mxl_mta-6.2.0-4) over TLS secured channel with ESMTP id c48543a4.3117357968.104232.00-020.p01c12o144.mxlogic.net (envelope-from ); Sat, 13 Jun 2009 19:54:21 -0600 (MDT) Received: from STSNYCMS1.corp.root.ipc.com ([10.201.40.91]) by STSNYHTCAS2.corp.root.ipc.com ([10.201.40.93]) with mapi; Sat, 13 Jun 2009 21:54:20 -0400 From: "Jain, Rajnish" To: Hadriel Kaplan , Roni Even , "'James M. Polk'" , 'Paul Kyzivat' Date: Sat, 13 Jun 2009 21:54:25 -0400 Thread-Topic: [dispatch] Session recording in SIP Thread-Index: AcnrA26dn6plCZIkQuayysm7FRTQJgAKyLQQABplEqAAAj/V0AAAcNKQADvJEYA= Message-ID: References: <4A2ECDB2.7000601@alcatel-lucent.com> <4A2FB842.7050302@sipstation.com> <028a01c9ea12$5ec96e60$1c5c4b20$%roni@huawei.com> <719F9BBB3E7E71428A2D13F3D76C768F01C7BBE8@GBNTHT12009MSX.gb002.siemens.net> <002801c9ea82$0da51320$28ef3960$%roni@huawei.com> <719F9BBB3E7E71428A2D13F3D76C768F01C7BE97@GBNTHT12009MSX.gb002.siemens.net> <004a01c9eaa7$94ef7990$bece6cb0$%roni@huawei.com> <00ab01c9eace$58b7c190$0a2744b0$%roni@huawei.com> <4A318F1E.9080308@cisco.com> <00fd01c9eb2f$39fa3920$adeeab60$%roni@huawei.com> <018c01c9eba1$c83c5930$58b50b90$%roni@huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-8.0.0.1307-5.600.1016-16700.004 x-tm-as-result: No--52.924900-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2009052001)] X-MAIL-FROM: X-SOURCE-IP: [65.244.37.52] X-AnalysisOut: [v=1.0 c=1 a=yoqeWMBPYRgA:10 a=yI7X_Uw_EMkA:10 a=D4USGbs0y0] X-AnalysisOut: [J827gn68Ljfg==:17 a=C7nHA56JAAAA:8 a=48vgC7mUAAAA:8 a=i0Ee] X-AnalysisOut: [H86SAAAA:8 a=YaNrmYCDIRQQ5aBOhv0A:9 a=t70lJICCz6wxnMd6q2MA] X-AnalysisOut: [:7 a=7zsL9aCHV4tuOve9ET8QXWR8Lh0A:4 a=HwvHyInW8OUA:10 a=lZ] X-AnalysisOut: [B815dzVvQA:10 a=hPjdaMEvmhQA:10 a=3zhXcAPKom1UAa-E:21 a=QV] X-AnalysisOut: [u0x2zUQzrM3__L:21] X-Mailman-Approved-At: Sun, 14 Jun 2009 07:21:51 -0700 Cc: 'Leon Portman' , "dispatch@ietf.org" Subject: Re: [dispatch] Session recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2009 01:54:27 -0000 I think the UA-UA RTP line was missing in the diagram. Otherwise, the recor= der is being expected to do conferencing (assuming more than 2 recordee UAs= ) and transcoding. That's really not the purpose of the recorders. -- Raj Jain -----Original Message----- From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Sent: Friday, June 12, 2009 5:54 PM To: Roni Even; 'James M. Polk'; 'Paul Kyzivat' Cc: 'Leon Portman'; dispatch@ietf.org; Jain, Rajnish Subject: RE: [dispatch] Session recording in SIP I was about to write a long-winded reply on how your example was not the sa= me as mediactrl, but I just realized your drawing was subtly different from= what I had thought it implied. :) The example you're describing is one wh= ere the recorder is not being sent forked/replicated media content by the U= A's, but is just put in the media path itself for the real media, so the or= iginal media itself is going from UA to recorder to UA. Right? If so, good point - I assume that's one possible deployment model to use. = I don't think it's how some (most?) people do it, because they can't or don= 't want to move the media path from where it began, especially for the UA s= ide that's outside their domain. (though I dunno much about why they do wh= at they do) But it is one interesting solution. -hadriel > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Roni Even > Sent: Friday, June 12, 2009 5:07 PM > To: Hadriel Kaplan; 'James M. Polk'; 'Paul Kyzivat' > Cc: 'Leon Portman'; dispatch@ietf.org; 'Jain, Rajnish' > Subject: Re: [dispatch] Session recording in SIP > > Hadriel, > This is what mediactrl is about. Look in > http://tools.ietf.org/html/rfc5567 > > Roni > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf > Of Hadriel Kaplan > Sent: Friday, June 12, 2009 11:08 PM > To: Roni Even; 'James M. Polk'; 'Paul Kyzivat' > Cc: 'Leon Portman'; dispatch@ietf.org; 'Jain, Rajnish' > Subject: Re: [dispatch] Session recording in SIP > > > Huh, interesting idea. I don't see how that could easily work though. > The > recorder needs to be able to associate specific audio streams with > specific > calls, and from which called/calling party they came. Unless there's a > control channel between each UA and the recorder, you'd have to somehow > get > the B2BUA to know what IP:port each UA can send the forked media from, an= d > provide each UA with the addr:port of the Recorder to send the forked > media > to. Not to mention if we decide to allow a different codec to be used on > the forked-media connection vs. the in-call side (which I personally don'= t > like the idea of but others do). At the end of the day, I'd bet you'd > have > one complicated protocol for all that to occur, with a bunch of > re-INVITEs/UPDATEs and all kinds of whacked corner-cases with > pre-conditions, and IPv4/v6, and god-knows-what else. :) > > -hadriel > > > -----Original Message----- > > From: Roni Even [mailto:Even.roni@huawei.com] > > Sent: Friday, June 12, 2009 3:27 AM > > > > James, > > The B2BUA does not need to see the RTP/RTCP stream they can go directly > > from > > the source to the recorder > > > > > > +-----+ +-----+ +-----+ > > | | Call | | Call | | > > |UA-A +<------------>+B2BUA+<------------>+UA-B | > > | | | | | | > > +-----+ +-++--+ +-----+ > > . \\ . > > . \\ control . > > . RTP TBD \\ .RTP > > . \\+----------+ . > > . \+ |..... > > . + Recorder | > > | | > > +----------+ > > > > Roni > > _______________________________________________ > 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 DISCLAIMER: This e-mail may contain information that is confidential, privi= leged or otherwise protected from disclosure. If you are not an intended re= cipient of this e-mail, do not duplicate or redistribute it by any means. P= lease delete it and any attachments and notify the sender that you have rec= eived it in error. Unintended recipients are prohibited from taking action = on the basis of information in this e-mail.E-mail messages may contain comp= uter viruses or other defects, may not be accurately replicated on other sy= stems, or may be intercepted, deleted or interfered with without the knowle= dge of the sender or the intended recipient. If you are not comfortable wit= h the risks associated with e-mail messages, you may decide not to use e-ma= il to communicate with IPC. IPC reserves the right, to the extent and under= circumstances permitted by applicable law, to retain, monitor and intercep= t e-mail messages to and from its systems. From rajnish.jain@ipc.com Sun Jun 14 18:42:37 2009 Return-Path: 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 8E9503A6BB2 for ; Sun, 14 Jun 2009 18:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.857 X-Spam-Level: X-Spam-Status: No, score=-2.857 tagged_above=-999 required=5 tests=[AWL=2.542, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, J_CHICKENPOX_44=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 G7d56TfKQLVO for ; Sun, 14 Jun 2009 18:42:36 -0700 (PDT) Received: from p01c12o145.mxlogic.net (p01c12o145.mxlogic.net [208.65.145.68]) by core3.amsl.com (Postfix) with ESMTP id 0F0C33A6A3F for ; Sun, 14 Jun 2009 18:42:35 -0700 (PDT) Received: from unknown [65.244.37.51] (EHLO p01c12o145.mxlogic.net) by p01c12o145.mxlogic.net (mxl_mta-6.2.0-4) with ESMTP id 617a53a4.2805361552.51338.00-501.p01c12o145.mxlogic.net (envelope-from ); Sun, 14 Jun 2009 19:42:46 -0600 (MDT) Received: from unknown [65.244.37.51] (EHLO smtp.ipc.com) by p01c12o145.mxlogic.net (mxl_mta-6.2.0-4) over TLS secured channel with ESMTP id df6a53a4.2742422416.51258.00-008.p01c12o145.mxlogic.net (envelope-from ); Sun, 14 Jun 2009 19:42:28 -0600 (MDT) Received: from STSNYCMS1.corp.root.ipc.com ([10.201.40.91]) by STSNYHTCAS1.corp.root.ipc.com ([10.201.40.92]) with mapi; Sun, 14 Jun 2009 21:42:20 -0400 From: "Jain, Rajnish" To: Roni Even , 'Hadriel Kaplan' , "'James M. Polk'" , 'Paul Kyzivat' Date: Sun, 14 Jun 2009 21:42:31 -0400 Thread-Topic: [dispatch] Session recording in SIP Thread-Index: AcnrA26dn6plCZIkQuayysm7FRTQJgAKyLQQABplEqAAAj/V0AAAcNKQADvJEYAACgT6EAAnb3eg Message-ID: References: <4A2ECDB2.7000601@alcatel-lucent.com> <4A2FB842.7050302@sipstation.com> <028a01c9ea12$5ec96e60$1c5c4b20$%roni@huawei.com> <719F9BBB3E7E71428A2D13F3D76C768F01C7BBE8@GBNTHT12009MSX.gb002.siemens.net> <002801c9ea82$0da51320$28ef3960$%roni@huawei.com> <719F9BBB3E7E71428A2D13F3D76C768F01C7BE97@GBNTHT12009MSX.gb002.siemens.net> <004a01c9eaa7$94ef7990$bece6cb0$%roni@huawei.com> <00ab01c9eace$58b7c190$0a2744b0$%roni@huawei.com> <4A318F1E.9080308@cisco.com> <00fd01c9eb2f$39fa3920$adeeab60$%roni@huawei.com> <018c01c9eba1$c83c5930$58b50b90$%roni@huawei.com> <01cd01c9ecbc$0cfc7c10$26f57430$%roni@huawei.com> In-Reply-To: <01cd01c9ecbc$0cfc7c10$26f57430$%roni@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-8.0.0.1307-5.600.1016-16702.004 x-tm-as-result: No--55.373600-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2009052001)] X-MAIL-FROM: X-SOURCE-IP: [65.244.37.51] X-AnalysisOut: [v=1.0 c=1 a=yoqeWMBPYRgA:10 a=yI7X_Uw_EMkA:10 a=z+2a4RCZxl] X-AnalysisOut: [tofrpCDsS06w==:17 a=i0EeH86SAAAA:8 a=48vgC7mUAAAA:8 a=vvKf] X-AnalysisOut: [UcgjAAAA:8 a=C7nHA56JAAAA:8 a=XzjqYJnEwfvu4TZCa2kA:9 a=MRE] X-AnalysisOut: [BTR4-QjQLXiSGAV0A:7 a=Q9tLqc_8paz2CiMT56zxVzIIKLoA:4 a=hPj] X-AnalysisOut: [daMEvmhQA:10 a=lZB815dzVvQA:10 a=OeN1TrMypwAA:10 a=HwvHyIn] X-AnalysisOut: [W8OUA:10 a=dMuyr8awREN_OiaV:21 a=0-xl_fZx6pdZRRcd:21] Cc: 'Leon Portman' , "dispatch@ietf.org" Subject: Re: [dispatch] Session recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 01:42:37 -0000 Hi, Inline: > -----Original Message----- > From: Roni Even [mailto:Even.roni@huawei.com] > Sent: Sunday, June 14, 2009 2:48 AM > To: Jain, Rajnish; 'Hadriel Kaplan'; 'James M. Polk'; 'Paul Kyzivat' > Cc: 'Leon Portman'; dispatch@ietf.org > Subject: RE: [dispatch] Session recording in SIP > > Hi, > This is a good observation but in the conferencing case you can have the > media coming not from the UAs but from the media mixer or have the mixer > functionality as part of the recorder. I think it'll help to model the mixer and the recorder as separate logical = entities. The mixer can feed the recorder if a conference call needs to be = recorded. Or the mixer can be used as a tapping device in case of non-forki= ng UAs. Below is how I'd draw it (control path from app server to recorder = not shown for brevity): SIP +------------+ SIP /----------| App Server |-------- / +------------+ \ / |SIP \ / | \ +-----+ +-----+ +-----+ | | RTP | | RTP | | |UA-A +<------------>+Mixer+<------------>+UA-B | | | | | | | +-----+ +-++--+ +-----+ | | RTP UA-A | | RTP UA-B (Rx+Tx) (Rx+Tx) V V +----------+ | | | Recorder | | | +----------+ > I understand the UA forking scenario for the call center application wher= e > the UAs in the call center will be required to support this functionality= . > Note that in this case if you have a multipoint video call you are record= ing > just what the UA receives (you record the view point of the recording UA) > and not the whole conference. If the handling UA is recording you may als= o > miss in the call center scenario any side discussion between the customer > and a supervisor if the handling UA is excluded from this part, in some > cases he will not even know about being kept out of some side call. Yes, you typically record the view point of the recording UA. But, there ma= y be requirement to record a conference call as opposed to individual parti= cipants to save disk space. > The general case is where you want to record a call but do not have the > media forking and recording application on your UA. In this case my view = is > that you will need a recording application server in the network. It will > need to record both point to point and multipoint calls. It can be like > suggested by Hadriel where the RTP streams are forked by the Application > Server (note that I am not calling it a general B2BUA) or using a decompo= sed > Application Server like the mediactrl architecture. Yes. I agree that an application server will compensate for non-forking UAs= , but I think the RTP streams will be forked by the media server and not th= e application server. The application server will dictate the media server = to do so. The diagram above reflects this arrangement. -- Raj Jain > -----Original Message----- > From: Jain, Rajnish [mailto:Rajnish.Jain@ipc.com] > Sent: Sunday, June 14, 2009 4:54 AM > To: Hadriel Kaplan; Roni Even; 'James M. Polk'; 'Paul Kyzivat' > Cc: 'Leon Portman'; dispatch@ietf.org > Subject: RE: [dispatch] Session recording in SIP > > I think the UA-UA RTP line was missing in the diagram. Otherwise, the > recorder is being expected to do conferencing (assuming more than 2 recor= dee > UAs) and transcoding. That's really not the purpose of the recorders. > > -- > Raj Jain > > > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Friday, June 12, 2009 5:54 PM > To: Roni Even; 'James M. Polk'; 'Paul Kyzivat' > Cc: 'Leon Portman'; dispatch@ietf.org; Jain, Rajnish > Subject: RE: [dispatch] Session recording in SIP > > > I was about to write a long-winded reply on how your example was not the > same as mediactrl, but I just realized your drawing was subtly different > from what I had thought it implied. :) The example you're describing is = one > where the recorder is not being sent forked/replicated media content by t= he > UA's, but is just put in the media path itself for the real media, so the > original media itself is going from UA to recorder to UA. > Right? > > If so, good point - I assume that's one possible deployment model to use.= I > don't think it's how some (most?) people do it, because they can't or don= 't > want to move the media path from where it began, especially for the UA si= de > that's outside their domain. (though I dunno much about why they do what > they do) But it is one interesting solution. > > -hadriel > > > > -----Original Message----- > > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > > Behalf Of Roni Even > > Sent: Friday, June 12, 2009 5:07 PM > > To: Hadriel Kaplan; 'James M. Polk'; 'Paul Kyzivat' > > Cc: 'Leon Portman'; dispatch@ietf.org; 'Jain, Rajnish' > > Subject: Re: [dispatch] Session recording in SIP > > > > Hadriel, > > This is what mediactrl is about. Look in > > http://tools.ietf.org/html/rfc5567 > > > > Roni > > > > -----Original Message----- > > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > > Behalf > > Of Hadriel Kaplan > > Sent: Friday, June 12, 2009 11:08 PM > > To: Roni Even; 'James M. Polk'; 'Paul Kyzivat' > > Cc: 'Leon Portman'; dispatch@ietf.org; 'Jain, Rajnish' > > Subject: Re: [dispatch] Session recording in SIP > > > > > > Huh, interesting idea. I don't see how that could easily work though. > > The > > recorder needs to be able to associate specific audio streams with > > specific > > calls, and from which called/calling party they came. Unless there's a > > control channel between each UA and the recorder, you'd have to somehow > > get > > the B2BUA to know what IP:port each UA can send the forked media from, = and > > provide each UA with the addr:port of the Recorder to send the forked > > media > > to. Not to mention if we decide to allow a different codec to be used = on > > the forked-media connection vs. the in-call side (which I personally do= n't > > like the idea of but others do). At the end of the day, I'd bet you'd > > have > > one complicated protocol for all that to occur, with a bunch of > > re-INVITEs/UPDATEs and all kinds of whacked corner-cases with > > pre-conditions, and IPv4/v6, and god-knows-what else. :) > > > > -hadriel > > > > > -----Original Message----- > > > From: Roni Even [mailto:Even.roni@huawei.com] > > > Sent: Friday, June 12, 2009 3:27 AM > > > > > > James, > > > The B2BUA does not need to see the RTP/RTCP stream they can go direct= ly > > > from > > > the source to the recorder > > > > > > > > > +-----+ +-----+ +-----+ > > > | | Call | | Call | | > > > |UA-A +<------------>+B2BUA+<------------>+UA-B | > > > | | | | | | > > > +-----+ +-++--+ +-----+ > > > . \\ . > > > . \\ control . > > > . RTP TBD \\ .RTP > > > . \\+----------+ . > > > . \+ |..... > > > . + Recorder | > > > | | > > > +----------+ > > > > > > Roni > > > > _______________________________________________ > > 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 > > DISCLAIMER: This e-mail may contain information that is confidential, > privileged or otherwise protected from disclosure. If you are not an > intended recipient of this e-mail, do not duplicate or redistribute it by > any means. Please delete it and any attachments and notify the sender tha= t > you have received it in error. Unintended recipients are prohibited from > taking action on the basis of information in this e-mail.E-mail messages = may > contain computer viruses or other defects, may not be accurately replicat= ed > on other systems, or may be intercepted, deleted or interfered with witho= ut > the knowledge of the sender or the intended recipient. If you are not > comfortable with the risks associated with e-mail messages, you may decid= e > not to use e-mail to communicate with IPC. IPC reserves the right, to the > extent and under circumstances permitted by applicable law, to retain, > monitor and intercept e-mail messages to and from its systems. DISCLAIMER: This e-mail may contain information that is confidential, privi= leged or otherwise protected from disclosure. If you are not an intended re= cipient of this e-mail, do not duplicate or redistribute it by any means. P= lease delete it and any attachments and notify the sender that you have rec= eived it in error. Unintended recipients are prohibited from taking action = on the basis of information in this e-mail.E-mail messages may contain comp= uter viruses or other defects, may not be accurately replicated on other sy= stems, or may be intercepted, deleted or interfered with without the knowle= dge of the sender or the intended recipient. If you are not comfortable wit= h the risks associated with e-mail messages, you may decide not to use e-ma= il to communicate with IPC. IPC reserves the right, to the extent and under= circumstances permitted by applicable law, to retain, monitor and intercep= t e-mail messages to and from its systems. From mizuno.shintaro@lab.ntt.co.jp Mon Jun 15 03:52:04 2009 Return-Path: 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 8A2FB28C131 for ; Mon, 15 Jun 2009 03:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.51 X-Spam-Level: X-Spam-Status: No, score=0.51 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 D-rv-QvqUSW5 for ; Mon, 15 Jun 2009 03:52:03 -0700 (PDT) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by core3.amsl.com (Postfix) with ESMTP id 3777228C13B for ; Mon, 15 Jun 2009 03:52:03 -0700 (PDT) Received: from mfs6.rdh.ecl.ntt.co.jp (mfs6.rdh.ecl.ntt.co.jp [129.60.39.149]) by tama50.ecl.ntt.co.jp (8.14.2/8.14.2) with ESMTP id n5FAoN0F001521; Mon, 15 Jun 2009 19:50:23 +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 0A702693A; Mon, 15 Jun 2009 19:50:23 +0900 (JST) Received: from img.m.ecl.ntt.co.jp (img0.m.ecl.ntt.co.jp [129.60.5.145]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id DCBC76604; Mon, 15 Jun 2009 19:50:22 +0900 (JST) Received: from trout2 ([129.60.215.44]) by img.m.ecl.ntt.co.jp (8.13.8/8.13.8) with SMTP id n5FAoMAK027696; Mon, 15 Jun 2009 19:50:22 +0900 (JST) Date: Mon, 15 Jun 2009 19:50:19 +0900 From: Shintaro Mizuno To: "'Henry Sinnreich'" , "'Eric Burger'" , "Dan Wing" Message-Id: <20090615195019.d076d216.mizuno.shintaro@lab.ntt.co.jp> In-Reply-To: <0d0901c9eaae$69ef9d90$b2676b80@cisco.com> References: <20090609220242.67b17e0a.mizuno.shintaro@lab.ntt.co.jp> <0d0901c9eaae$69ef9d90$b2676b80@cisco.com> X-Mailer: Sylpheed 2.5.0 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] Charter Proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 10:52:04 -0000 Mr. Sinnreich, Besides the fact that SIP is a well-deployed infrastructure, we also think that SIP has an advantage for its capabilities to negotiate parameters using SDP offer/answer. In case of IKE, these parameters are, for example, authentication parameters (fingerprint of a certificate) and role of IKE sessions (e.g. server/client in remote access), which usually need to be exchanged previously by the peers. This enables IKE to be established in a peer-to-peer situation. Best Regards, Shintaro On Thu, 11 Jun 2009 09:05:16 -0700 "Dan Wing" wrote: > > > > -----Original Message----- > > From: dispatch-bounces@ietf.org > > [mailto:dispatch-bounces@ietf.org] On Behalf Of Henry Sinnreich > > Sent: Tuesday, June 09, 2009 6:32 AM > > To: Shintaro Mizuno; Eric Burger > > Cc: dispatch@ietf.org > > Subject: Re: [dispatch] Charter Proposal > > > > You may also want to consider HIP, since it solves NAT > > traversal for all application layer protocols, including SIP. > > > > http://www.ietf.org/internet-drafts/draft-ietf-hip-nat-travers > > al-07.txt > > Yes, I am aware of HIP's NAT traversal capabilities, as I > encouraged its adoption of ICE methodologies. > > > It also takes care of the IPv4 to IPv6 transition for > > endpoints, mobility and multi-homing. > > Open source code is plentifully available for reference > > implementations. > > > > http://www.ietf.org/html.charters/hip-charter.html > > There are always new protocols. But it is often pragmatic to leverage the > investment of deployed protocols -- much like TCP which continues to evolve > even though SCTP and DCCP provide superior functionality, much like how IPsec > was originally intended for IPv6 but was then supported on IPv4, etc. > > We are interested in using SIP for establishing VPN sessions in much the same > way that SIP has embraced TLS (RFC4572) and embraced file transfer (RFC5547). > > -d > > > > Henry > > > > > > > > On 6/9/09 8:02 AM, "Shintaro Mizuno" > > wrote: > > > > > > > > Mr. Burger, > > Thank you for the comment. > > > > We don't necessary see a need for a WG to be formed to > > document the > > informational document we have listed, the document is > > there to see if > > the proposed way forward (informational document possibly > > as an independent submission) for the document listed > > is on track or > > whether something should be done at the WG level. > > > > On the other hand, we believe that use of SIP similar > > to what we > > have done for VPN will likely to happen more. And on > > that point, we are > > wanting to see whether IETF is interested in > > documenting a guideline > > for dealing with application that's not voice or video. > > As written in the discussion point of the charter, the > > question is how > > much should SIP be involved. > > > > 1. Should SIP just be used as a rendezvous protocol > > and leave the > > rest of the negotiation to whatever application? > > 2. Should SIP involve in management of the established > > session as it > > does for audio/video? > > 3. Should use of SIP not be standardized for peer to > > peer application > > beside audio/video? > > > > > > Regards, > > Shintaro > > > > > > On Mon, 8 Jun 2009 06:38:20 -0400 > > Eric Burger wrote: > > > > > Given the proposal is not really for an Internet > > standard, and the > > > product is not a protocol or standards track > > document, why are we > > > working on it here? > > > > > > On Jun 8, 2009, at 5:20 AM, Shintaro Mizuno wrote: > > > > > > > Dear DISPATCH Chair, ML members, > > > > > > > > I've finalized the charter proposal for on-demand > > media/application > > > > sharing. > > > > Added milestone/deliverables section and some > > descriptions on the > > > > usage > > > > of SIP, but most of the text remains the same. > > > > > > > > -------------------------------------------------- > > > > "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. > > > > > > > > SIP/SDP will be used to negotiate parameters > > necessary to establish > > > > IKE/IPsec such as IP address, port numbers and > > authentication > > > > information of peers. Current deployment uses SIP > > also to manage IPsec > > > > connection, e.g. use BYE to shut down media > > sessions for IKE/IPsec, > > > > however, further discussions can be made to find > > out if there are > > > > intrests or use cases in using SIP only as a > > rendezvous protocol. > > > > > > > > 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 be minor-updated to -05 to conform with this > > charter proposal) > > > > - 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. > > > > > > > > > > > > Milestone/Deliverables: > > > > - Aug 09 Issue Internet-Draft > > > > (by updating "draft-saito-mmusic-sdp-ike-05") > > > > - Nov 09 Submit I-D to IESG for publication as an > > RFC (Informational) > > > > > > > > -------------------------------------------------- > > > > Best Regards, > > > > Shintaro > > > > > > > > ---------------------------------------- > > > > Shintaro MIZUNO > > > > mizuno.shintaro@lab.ntt.co.jp > > > > > > > > NTT Information Sharing Platform Laboratories > > > > NTT Corporation > > > > ---------------------------------------- > > > > > > > > _______________________________________________ > > > > dispatch mailing list > > > > dispatch@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dispatch > > > > > > > > > > > > ---------------------------------------- > > Shintaro MIZUNO > > mizuno.shintaro@lab.ntt.co.jp > > > > NTT Information Sharing Platform Laboratories > > NTT Corporation > > ---------------------------------------- > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > > > > > > > > ---------------------------------------- Shintaro MIZUNO mizuno.shintaro@lab.ntt.co.jp NTT Information Sharing Platform Laboratories NTT Corporation ---------------------------------------- From hannes.tschofenig@nsn.com Mon Jun 15 09:56:59 2009 Return-Path: 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 52A413A6AF6 for ; Mon, 15 Jun 2009 09:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.307 X-Spam-Level: X-Spam-Status: No, score=-3.307 tagged_above=-999 required=5 tests=[AWL=-0.708, 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 y5Cil+j9UAk5 for ; Mon, 15 Jun 2009 09:56:58 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 4FFEE3A68B7 for ; Mon, 15 Jun 2009 09:56:57 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n5FGv5D5014291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 15 Jun 2009 18:57:05 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n5FGv571029184 for ; Mon, 15 Jun 2009 18:57:05 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Jun 2009 18:57:05 +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, 15 Jun 2009 19:59:05 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4501712A7A@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Session Recording -- Technical stuff Thread-Index: Acnt2pdZ6+4bqCM2QLOEjXcE+jO4zg== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 15 Jun 2009 16:57:05.0722 (UTC) FILETIME=[4FFA31A0:01C9EDDA] Subject: [dispatch] Session Recording -- Technical stuff X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 16:56:59 -0000 Without going too far into the solution space but we received some review comments from Ekr for http://tools.ietf.org/html/draft-wing-sipping-srtp-key-04. I believe it is valuable technical input. Here is his review: http://www.ietf.org/mail-archive/web/sipping/current/msg16652.html Ciao Hannes From HKaplan@acmepacket.com Wed Jun 17 11:29:48 2009 Return-Path: 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 A26C228C1B2; Wed, 17 Jun 2009 11:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.188, 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 0vrP-Vd6vO5V; Wed, 17 Jun 2009 11:29:47 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id ADCD028C278; Wed, 17 Jun 2009 11:29:47 -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; Wed, 17 Jun 2009 14:29:58 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 17 Jun 2009 14:29:58 -0400 From: Hadriel Kaplan To: "sip-clf@ietf.org" Date: Wed, 17 Jun 2009 14:29:47 -0400 Thread-Topic: I-D Action:draft-kaplan-sipping-clf-pcap-00.txt Thread-Index: AcnvADVbRjylz/iUR3uTiC6eLPbhbQAd2SIg Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_E6C2E8958BA59A4FB960963D475F7AC31941848484mail_" MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: [dispatch] FW: I-D Action:draft-kaplan-sipping-clf-pcap-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 18:29:48 -0000 --_002_E6C2E8958BA59A4FB960963D475F7AC31941848484mail_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Howdy, I have submitted an I-D for Yet Another SIP-CLF Format. This one is pure b= inary, and follows the libpcap/PCAP file format, encoding the fields into a= format which just happens to be decode-able as RADIUS messages by PCAP dec= oders. One of the advantages to this format is off-line decoders such as W= ireshark can decode it right now, with only a dictionary for the VSA used f= or SIP-CLF. For wireshark, for example, this can be done without re-compil= ing/upgrading wireshark. Just a 30-second procedure and restarting Wiresha= rk enables one to view, filter, and search through the SIP-CLF fields as is= . The I-D's link is below, and there's a sample CLF file and dictionary file = and Wireshark instructions (and even screenshot!) available on: https://sourceforge.net/projects/sip-clf/ There's also an open-source C-code library implementation available there. -hadriel > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org= ] > On Behalf Of Internet-Drafts@ietf.org >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 > Title : PCAP-compatible Binary Syntax for SIP Common Log > File Format > Author(s) : H. Kaplan > Filename : draft-kaplan-sipping-clf-pcap-00.txt > Pages : 20 > Date : 2009-06-16 >=20 > This document proposes a libpcap/PCAP-compatible binary syntax for > the SIP common log format (CLF). It does not cover semantic > issues, and is meant to be evaluated in the context of the other > efforts discussing SIP CLF. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-kaplan-sipping-clf-pcap-00.txt --_002_E6C2E8958BA59A4FB960963D475F7AC31941848484mail_ Content-Type: text/plain; name="draft-kaplan-sipping-clf-pcap-00.url.txt" Content-Description: draft-kaplan-sipping-clf-pcap-00.url.txt Content-Disposition: attachment; filename="draft-kaplan-sipping-clf-pcap-00.url.txt"; size=97; creation-date="Wed, 17 Jun 2009 00:00:53 GMT"; modification-date="Wed, 17 Jun 2009 00:00:53 GMT" Content-Transfer-Encoding: base64 VGhpcyBhdHRhY2htZW50IHdhcyByZW1vdmVkLg== --_002_E6C2E8958BA59A4FB960963D475F7AC31941848484mail_-- From mary.barnes@nortel.com Wed Jun 17 16:36:42 2009 Return-Path: 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 D0C323A6B3F for ; Wed, 17 Jun 2009 16:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.332 X-Spam-Level: X-Spam-Status: No, score=-6.332 tagged_above=-999 required=5 tests=[AWL=0.267, 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 VQPF1cEZPt2X for ; Wed, 17 Jun 2009 16:36:42 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id C27EB3A6A95 for ; Wed, 17 Jun 2009 16:36:41 -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 n5HNaoN18758; Wed, 17 Jun 2009 23:36:50 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, 17 Jun 2009 18:39:18 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E922A01@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E590C4B@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF-75 plans for DISPATCH thread-index: AcnNtXrnlTE+ihrURvGZPoNhaaFPuABmOAxgAC3W45AFJZzbIALAe8uA References: <1ECE0EB50388174790F9694F77522CCF1E590C4B@zrc2hxm0.corp.nortel.com> From: "Mary Barnes" To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 23:36:42 -0000 Hi folks, A tentative agenda for the IETF-75 DISPATCH WG has been submitted: http://www.ietf.org/proceedings/09jul/agenda/dispatch.html Per the various emails posted last week, we dispatched (or not) all the topics that had been put forth by June 8th, per the following summary: 1) 3rd party auth - on the agenda to discuss what part or parts of the problem need to be solved 2) CBUS - Christer to update his proposal at a later date 3) cc-uui - on the agenda to discuss a proposed charter (and not he solutions) for a new "mini" WG to progress the work which we anticipate is a single document. =20 4) CLF - a new WG has been proposed and is in the process of being formed. We will only allocate agenda time if open issues that cannot be resolved on the ML are identified.=20 5) Codec - a separate BoF has been requested. =20 6) Sound level indicator - work/discussion moved to the AVT WG 7) On demand media/app sharing - in order to dispatch this work, there needs to be more interest and feedback on this topic The additional topic on Session Recording was put forth after June 8th and has not yet been considered in the IETF-75 plans. However, if there is enough interest in the topic and folks committed to the work, then we may be able to allocate agenda time. =20 The following summarizes the status of the other two topics that are on the current DISPATCH WG charter: - Overload. A new mailing list is being setup to discuss solution options and determine the scope of work that might be done. The expectation would be that like the other work items above, a problem statement and proposed chartered work item(s) will be posted to the DISPATCH WG mailing list for discussion. I'll announce the new ML as soon as it's up and running. - Configuration/Datasets. Dale has been looking at the documents and trying to get WG feedback. But, there seems to be little interest in this work. An option being considered, since this work is a dependency for several SIP/SIPPING WG items to complete, would be to complete the work to satisfy the current dependencies and progress as AD sponsored.=20 As a reminder, the deadline for any -00 documents is July 6th, 17:00 PDT (less than three weeks!) and the final submission deadline is July 13th, 17:00 PDT (less than 4 weeks!).=20 We do appreciate everyone's patience with the new model, as well as the level of participation. Regards, Mary. DISPATCH WG co-chair From jmpolk@cisco.com Wed Jun 17 17:05:46 2009 Return-Path: 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 916903A682D for ; Wed, 17 Jun 2009 17:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.5 X-Spam-Level: X-Spam-Status: No, score=-6.5 tagged_above=-999 required=5 tests=[AWL=0.099, 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 Fd-Jl0Z3WhuE for ; Wed, 17 Jun 2009 17:05:45 -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 B82003A6407 for ; Wed, 17 Jun 2009 17:05:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,240,1243814400"; d="scan'208";a="326196756" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 18 Jun 2009 00:05:58 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n5I05wUE019384; Wed, 17 Jun 2009 17:05:58 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n5I05vVn017910; Thu, 18 Jun 2009 00:05:58 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Jun 2009 17:05:57 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.2.90]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Jun 2009 17:05:57 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 17 Jun 2009 19:05:56 -0500 To: "Mary Barnes" , From: "James M. Polk" In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E922A01@zrc2hxm0.corp.nor tel.com> References: <1ECE0EB50388174790F9694F77522CCF1E590C4B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E922A01@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 18 Jun 2009 00:05:57.0426 (UTC) FILETIME=[8E182120:01C9EFA8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=878; t=1245283558; x=1246147558; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[dispatch]=20IETF-75=20plans=20for=20DI SPATCH |Sender:=20; bh=+qs1bXM/IF5aMmcUKDPROZI1LBEGDXUi3ExgDRrUSjw=; b=uYBx0926rK+G0xdK+PdKQxaK/Rhbi7c/Me8Vc5RPuZpPjJS6vvAtqw7bjL JfKRk2gZCL5KclZPVyxJQ+cufQ4LLjXBOrFluuqnow0Qb1n6rxq0tqaFW+A4 /A2SHM1m4DQ/6N/uCkN61fC9BA9R36zRW3oeVM7aP4Kty3jglR8KQ=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: rai-ads@tools.ietf.org Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 00:05:46 -0000 At 06:39 PM 6/17/2009, Mary Barnes wrote: >The additional topic on Session Recording was put forth after June 8th >and has not yet been considered in the IETF-75 plans. However, if there >is enough interest in the topic and folks committed to the work, then we >may be able to allocate agenda time. I'm rather stunned that demonstrated interest isn't being considered sufficiently clear on this topic to the WG chairs or ADs. Of the last 75 messages to this list, more than half have been on this topic alone. I do agree this topic was late, but that ought to be stated as the only reason this topic doesn't progress at IETF75. Evidence of the vast debate we've had on this list proves folks are embracing this idea - even if they do not exactly have an idea of how it will look when finished - which is actually what we want in a WG, right? James From HKaplan@acmepacket.com Wed Jun 17 17:23:23 2009 Return-Path: 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 1137928C0D6 for ; Wed, 17 Jun 2009 17:23:23 -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 gj6tC+ABGGQD for ; Wed, 17 Jun 2009 17:23:22 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 26B223A6808 for ; Wed, 17 Jun 2009 17:23:22 -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; Wed, 17 Jun 2009 20:23:33 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 17 Jun 2009 20:23:33 -0400 From: Hadriel Kaplan To: "James M. Polk" , Mary Barnes , "dispatch@ietf.org" Date: Wed, 17 Jun 2009 20:23:21 -0400 Thread-Topic: [dispatch] IETF-75 plans for DISPATCH Thread-Index: AcnvqJ06EX1eG6D5SfinSq1O6e9vFAAAEuFQ Message-ID: References: <1ECE0EB50388174790F9694F77522CCF1E590C4B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E922A01@zrc2hxm0.corp.nortel.com> In-Reply-To: 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 Cc: "rai-ads@tools.ietf.org" Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 00:23:23 -0000 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of James M. Polk > Sent: Wednesday, June 17, 2009 8:06 PM >=20 > At 06:39 PM 6/17/2009, Mary Barnes wrote: > >The additional topic on Session Recording was put forth after June 8th > >and has not yet been considered in the IETF-75 plans. However, if there > >is enough interest in the topic and folks committed to the work, then we > >may be able to allocate agenda time. >=20 > I'm rather stunned that demonstrated interest isn't being considered > sufficiently clear on this topic to the WG chairs or ADs. +1. And considering the topic was put forth 10hrs and 1 minute after the d= eadline, it's not like the fewer 10 hours (and 1 minute) left people withou= t time to think about it. :) -hadriel From mary.barnes@nortel.com Wed Jun 17 18:19:15 2009 Return-Path: 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 F40D73A6B7F for ; Wed, 17 Jun 2009 18:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.336 X-Spam-Level: X-Spam-Status: No, score=-6.336 tagged_above=-999 required=5 tests=[AWL=0.263, 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 SYCLN5kO9Eng for ; Wed, 17 Jun 2009 18:19:14 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 08B3E3A6B18 for ; Wed, 17 Jun 2009 18:19:13 -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 n5I1Hsd19546; Thu, 18 Jun 2009 01:17:54 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, 17 Jun 2009 20:21:24 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E922A96@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] IETF-75 plans for DISPATCH thread-index: AcnvqJ06EX1eG6D5SfinSq1O6e9vFAAAEuFQAAJ3g6A= References: <1ECE0EB50388174790F9694F77522CCF1E590C4B@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E922A01@zrc2hxm0.corp.nortel.com> From: "Mary Barnes" To: "Hadriel Kaplan" , "James M. Polk" , Cc: rai-ads@tools.ietf.org Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 01:19:15 -0000 Actually, the topic was 2 weeks + 10hrs and 1 minute after the deadline - i.e., we asked for topics to be sent by May 25th, with any updates by June 8th. That said, certainly if folks have an interest, then we can consider discussing in Stockholm. It would be good for someone to summarize where the topic is - there seems to be a very broad range of views as to the scope of the problem and what would be potential deliverables. Thanks, Mary.=20 -----Original Message----- From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 Sent: Wednesday, June 17, 2009 7:23 PM To: James M. Polk; Barnes, Mary (RICH2:AR00); dispatch@ietf.org Cc: rai-ads@tools.ietf.org Subject: RE: [dispatch] IETF-75 plans for DISPATCH > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On=20 > Behalf Of James M. Polk > Sent: Wednesday, June 17, 2009 8:06 PM >=20 > At 06:39 PM 6/17/2009, Mary Barnes wrote: > >The additional topic on Session Recording was put forth after June=20 > >8th and has not yet been considered in the IETF-75 plans. However,=20 > >if there is enough interest in the topic and folks committed to the=20 > >work, then we may be able to allocate agenda time. >=20 > I'm rather stunned that demonstrated interest isn't being considered=20 > sufficiently clear on this topic to the WG chairs or ADs. +1. And considering the topic was put forth 10hrs and 1 minute after=20 +the deadline, it's not like the fewer 10 hours (and 1 minute) left=20 +people without time to think about it. :) -hadriel From sdoken@qualcomm.com Thu Jun 18 01:04:22 2009 Return-Path: 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 915423A6C1F for ; Thu, 18 Jun 2009 01:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_63=0.6, 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 BOVN74tKmBWZ for ; Thu, 18 Jun 2009 01:04:21 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 179A63A6B69 for ; Thu, 18 Jun 2009 01:04:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=sdoken@qualcomm.com; q=dns/txt; s=qcdkim; t=1245312273; x=1276848273; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Doken,=20Serhad"=20|To:=20 "James=20M.=20Polk"=20,=20Roni=20Even =20,=0D=0A=20=20=20=20=20=20=20=20" 'Alan=20Johnston'"=20,=0D=0A=20=20 =20=20=20=20=20=20"'Romascanu,=20Dan=20(Dan)'"=0D=0A=09|CC:=20"'Leon=20Portman'"=20,=0D=0A=20=20=20=20=20=20=20=20"dispatch@ietf .org"=0D=0A=09,=0D=0A=20=20=20=20=20 =20=20=20"'Jain,=09Rajnish'"=20,=0D =0A=20=20=20=20=20=20=20=20"'Hadriel=0D=0A=20Kaplan'"=20< HKaplan@acmepacket.com>|Date:=20Thu,=2018=20Jun=202009=20 01:04:15=20-0700|Subject:=20RE:=20[dispatch]=20Session=20 recording=20in=20SIP|Thread-Topic:=20[dispatch]=20Session =20recording=20in=20SIP|Thread-Index:=20AcnqFteRD33k6m4oR v+DHK94vaAJlwF0ckKg|Message-ID:=20 |References:=20<4A2ECDB2.7000601@alcatel-lucent.com>=0D =0A=09=0D=0A=09<4A2FB842.7050302@sipstation .com>=0D=0A=09<023d01c9e9e7$1b015880$51040980$%roni@huawe i.com>=0D=0A=20|In-Reply-To:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5649"=3B=20a=3D"19595236"; bh=r8RIglBN3AGBNNhuAcXLXfAkZrwhjEYActtZDEPWuO4=; b=FcVS5VkdmnBzTefKMChhJBVlhbQuan2DAOnWAij12XnQeGB5emEtqWFo 2Q8c4w1KW6CyC0/ps559hBrHm2Yd6IBRPnafqceNaIXOJxtnCXA33Em/m 799JIbBoeJdSCIwdQEVJPtHhHXi4Iu4SRP/8QwWSLWInk7dAIu0BmdZmm o=; X-IronPort-AV: E=McAfee;i="5300,2777,5649"; a="19595236" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Jun 2009 01:04:33 -0700 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n5I84W8X022447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 18 Jun 2009 01:04:32 -0700 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n5I84IFL032415 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 18 Jun 2009 01:04:19 -0700 Received: from NASANEXMB09.na.qualcomm.com ([129.46.53.121]) by nasanexhub03.na.qualcomm.com ([10.46.93.98]) with mapi; Thu, 18 Jun 2009 01:04:18 -0700 From: "Doken, Serhad" To: "James M. Polk" , Roni Even , "'Alan Johnston'" , "'Romascanu, Dan (Dan)'" Date: Thu, 18 Jun 2009 01:04:15 -0700 Thread-Topic: [dispatch] Session recording in SIP Thread-Index: AcnqFteRD33k6m4oRv+DHK94vaAJlwF0ckKg Message-ID: References: <4A2ECDB2.7000601@alcatel-lucent.com> <4A2FB842.7050302@sipstation.com> <023d01c9e9e7$1b015880$51040980$%roni@huawei.com> In-Reply-To: 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 Cc: 'Leon Portman' , "dispatch@ietf.org" , "'Jain, Rajnish'" , 'Hadriel Kaplan' Subject: Re: [dispatch] Session recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 08:04:22 -0000 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of James M. Polk > Sent: Wednesday, June 10, 2009 3:00 PM > To: Roni Even; 'Alan Johnston'; 'Romascanu, Dan (Dan)' > Cc: 'Leon Portman'; dispatch@ietf.org; 'Jain, Rajnish'; 'Hadriel > Kaplan' > Subject: Re: [dispatch] Session recording in SIP >=20 > Hey >=20 > I agree with Roni about this probably being best suited for XCON, > after all, any point to point recording is likely (merely) adding a > 3rd party (the recorder) to the session. >=20 > This brings up probably the most glaring whole (in my mind) that is > not mentioned below - the ability to have a recorder without at least > one side knowing it's there. Not every time, and in fact probably > most times, you don't want the other person knowing you are recording > them. It's likely more of a case of not explicitly asking the called > party "can I record this conversation", it just happens. As someone who have implemented SIP based recording which has been shipping= for several years, this thread caught my eye though I haven't read the who= le lively set of e-mails yet.=20 In most enterprise contact center environments(say 1-800-2CALLME), caller(l= et's call him customer) will get an announcement of some sort like "This ca= ll may/will be monitored/recorded for quality purposes" at the beginning of= the call. For limited cases, customer has a chance to accept/reject that o= r if refuses he/she can hang up. Called party(Agent) as an employee is almo= st always aware that call may be recorded since contact center businesses c= ollect quality and business analytic data based on those recordings. Moreov= er, in some deployments, periodic recording tones are played towards custom= er and agent phones to alert/remind them that call is being recorded. It co= uld be the case that sometimes all calls are recorded or sometimes calls to= a particular set of agent phones are recorded. On the other hand, a supervisor monitoring a conversation between a custome= r and agent may decide to record that conversation, at any random point, si= mply triggering it via a CTI application that is running on his desktop for= the whole call duration or may wish to stop that recording at any random p= oint. Serhad >=20 > James >=20 > At 11:18 AM 6/10/2009, Roni Even wrote: > >Hi, > >I agree that this is an important work but I am not sure about a WG. > This > >may be done in XCON and AVT. > >Note that the recording is not only for point to point call but at > least for > >three parties like in call center scenarios > > > >I also did not notice any mention of the playback part but it should > also be > >addressed > > > >Roni Even > > > >-----Original Message----- > >From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf > >Of Alan Johnston > >Sent: Wednesday, June 10, 2009 4:42 PM > >To: Romascanu, Dan (Dan) > >Cc: Leon Portman; dispatch@ietf.org; Jain, Rajnish; Hadriel Kaplan > >Subject: Re: [dispatch] Session recording in SIP > > > >This is important work to be done in RAI. Key management for secure > >recording is an important component that needs to be addressed. > > > >draft-wing-sipping-srtp-key-04 addresses many of these topics. > > > >Thanks, > >Alan > > > > > >Romascanu, Dan (Dan) wrote: > > > I believe that this is an important application, and I support > doing > > > work in this direction. > > > > > > Three comments on the preliminary words: > > > > > > 1. The requirement is for both signaling and media recording, > right? > > > Probably good to say it. > > > 2. Security and regulations on how the information is accessed and > > > protected are of high importance. They would probably be reflected > in > > > the requirements, but explicit wording in the future charter can > help. > > > 3. I suggest that we look at the IPFIX protocol as a possible > technology > > > to re-use > > > > > > Dan > > > > > > > > > > > >> -----Original Message----- > > >> From: dispatch-bounces@ietf.org > > >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Vijay K. Gurbani > > >> Sent: Wednesday, June 10, 2009 12:02 AM > > >> To: dispatch@ietf.org > > >> Cc: Leon Portman; Jain,Rajnish; Hadriel Kaplan > > >> Subject: [dispatch] Session recording in SIP > > >> > > >> Hi: I realize that the deadline for charter proposals was > > >> yesterday, but I hope that it is not too late to submit one more. > > >> > > >> A few interested people (Hadriel Kaplan, Dan Wing, Rajnish > > >> Jain, Leon Portman, Andrew Hutton and I) have been interested > > >> in RTP session recording in SIP. The requirement draft will > > >> be released shortly. > > >> > > >> We would like to request agenda time in dispatch to propose > > >> the formation of a new working group to define protocol > > >> extensions and an architecture for RTP recording. > > >> > > >> Session recording in SIP > > >> Mailing Lists: TBD > > >> Chairs: TBD > > >> Area Directorate: Real Time Applications (RAI) > > >> > > >> Purpose: > > >> > > >> Session recording is a critical operational requirement in > > >> many businesses, especially where voice is used as a medium > > >> for commerce and customer support. A prime example where > > >> voice is used for trade is the financial industry. The call > > >> recording requirements in this industry are quite stringent. > > >> The recorded calls are used for dispute resolution and > > >> regulatory compliance. Other businesses such as customer > > >> support call centers typically employ call recording for > > >> quality control or business analytics. > > >> > > >> Depending on the country and its regulatory requirements, > > >> financial trading floors typically must record all calls. The > > >> recorded media content must be an exact copy of the actual > > >> conversation (i.e. > > >> clipping and loss of media are unacceptable). Some > > >> deployments and regulations require that calls be aborted or > > >> rejected if the recording device is unavailable. > > >> > > >> This group will specify requirements for a SIP based protocol > > >> interface between a communications system and a recorder. The > > >> Communications System is responsible for establishing media > > >> sessions where the actual business is conducted. The Recorder > > >> is the sink of the recorded media. > > >> > > >> The recorded sessions can be of any kind such as voice, video > > >> and instant messaging. A recorded session is typically > > >> comprised of actual media content and the call metadata. The > > >> call metadata allows recording archives to be searched and > > >> filtered at a later time. > > >> The conveyance of call metadata from the communications > > >> system to the recorder is outside the scope of this document. > > >> > > >> This group will only looks into active recording, where the > > >> recorded system purposefully streams media to a recording > > >> device. Passive recording, where a recording device detects > > >> media directly from the network, is outside the scope of this > > >> document. In addition, lawful intercept is outside the scope > > >> of the group. > > >> > > >> Proposed deliverables: > > >> > > >> 1) Requirements document; > > >> 2) Solutions document, including reference architecture. > > >> > > >> 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/ > > >> _______________________________________________ > > >> 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 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From vkg@alcatel-lucent.com Thu Jun 18 06:16:49 2009 Return-Path: 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 05E3528C2F8 for ; Thu, 18 Jun 2009 06:16: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=[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 BfE7-BqFzo-z for ; Thu, 18 Jun 2009 06:16:48 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id E95F23A68FA for ; Thu, 18 Jun 2009 06:16:47 -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 n5IDGwXR013866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Jun 2009 08:16:58 -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 n5IDGvUR019820; Thu, 18 Jun 2009 08:16:57 -0500 (CDT) Message-ID: <4A3A3E49.2040000@alcatel-lucent.com> Date: Thu, 18 Jun 2009 08:16:57 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mary Barnes References: <1ECE0EB50388174790F9694F77522CCF1E590C4B@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E922A01@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E922A96@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E922A96@zrc2hxm0.corp.nortel.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, rai-ads@tools.ietf.org Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 13:16:49 -0000 Mary Barnes wrote: > That said, certainly if folks have an interest, then we can consider > discussing in Stockholm. Mary: The interest is there, and I agree with James and Hadriel that we should consider discussions in Stockholm. Rajnish Jain, the primary editor of the session recording requirement document, has the -00 version distributed among the co-authors and will be updating the document with list discussions before submission shortly. So there will be a concrete document to discuss by Stockholm. > It would be good for someone to summarize where the topic is - there > seems to be a very broad range of views as to the scope of the > problem and what would be potential deliverables. The potential deliverables in the form of 2-3 documents are listed in the call for proposals. Regarding the summary of list discussions, sure, I will attempt one over the weekend. 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/ From mary.barnes@nortel.com Thu Jun 18 06:21:42 2009 Return-Path: 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 A70BC3A6CD0 for ; Thu, 18 Jun 2009 06:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.34 X-Spam-Level: X-Spam-Status: No, score=-6.34 tagged_above=-999 required=5 tests=[AWL=0.259, 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 2l1f9IcVg8oA for ; Thu, 18 Jun 2009 06:21:41 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 6D6BC3A6CC7 for ; Thu, 18 Jun 2009 06:21:41 -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 n5IDKAS00331; Thu, 18 Jun 2009 13:20:10 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: Thu, 18 Jun 2009 08:23:42 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E922D37@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A3A3E49.2040000@alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] IETF-75 plans for DISPATCH thread-index: AcnwFxZbLbQrbTpITDqgy2xML6xG8gAAH6Lw References: <1ECE0EB50388174790F9694F77522CCF1E590C4B@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E922A01@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E922A96@zrc2hxm0.corp.nortel.com> <4A3A3E49.2040000@alcatel-lucent.com> From: "Mary Barnes" To: "Vijay K. Gurbani" Cc: dispatch@ietf.org, rai-ads@tools.ietf.org Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 13:21:42 -0000 Just keep in mind that the focus of discussions in DISPATCH is on the level of the scope of work, where it should be done and deliverables and not necessarily the technical details. Understanding of course that some consideration of technical details is required to figure out where the work should be done.=20 Thanks, Mary.=20 -----Original Message----- From: Vijay K. Gurbani [mailto:vkg@alcatel-lucent.com]=20 Sent: Thursday, June 18, 2009 8:17 AM To: Barnes, Mary (RICH2:AR00) Cc: dispatch@ietf.org; rai-ads@tools.ietf.org Subject: Re: [dispatch] IETF-75 plans for DISPATCH Mary Barnes wrote: > That said, certainly if folks have an interest, then we can consider=20 > discussing in Stockholm. Mary: The interest is there, and I agree with James and Hadriel that we should consider discussions in Stockholm. Rajnish Jain, the primary editor of the session recording requirement document, has the -00 version distributed among the co-authors and will be updating the document with list discussions before submission shortly. So there will be a concrete document to discuss by Stockholm. > It would be good for someone to summarize where the topic is - there=20 > seems to be a very broad range of views as to the scope of the problem > and what would be potential deliverables. The potential deliverables in the form of 2-3 documents are listed in the call for proposals. Regarding the summary of list discussions, sure, I will attempt one over the weekend. 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/ From vkg@alcatel-lucent.com Thu Jun 18 06:21:42 2009 Return-Path: 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 B0CA83A6CC7 for ; Thu, 18 Jun 2009 06:21:42 -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 lRQ+Yf01AASl for ; Thu, 18 Jun 2009 06:21:41 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id D27B33A6BEB for ; Thu, 18 Jun 2009 06:21:41 -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 n5IDLqTp018058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Jun 2009 08:21:52 -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 n5IDLpxY023628; Thu, 18 Jun 2009 08:21:51 -0500 (CDT) Message-ID: <4A3A3F6E.7080501@alcatel-lucent.com> Date: Thu, 18 Jun 2009 08:21:50 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mary Barnes , Gonzalo Camarillo References: <1ECE0EB50388174790F9694F77522CCF1E590C4B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E922A01@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E922A01@zrc2hxm0.corp.nortel.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, rai-ads@tools.ietf.org Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 13:21:42 -0000 Mary Barnes wrote: > 4) CLF - a new WG has been proposed and is in the process of being > formed. We will only allocate agenda time if open issues that cannot be > resolved on the ML are identified. Mary, Gonzalo: This is a process-related question -- when we form a WG as a result of deliberations in dispatch, is this a formal WG that needs to be scheduled and managed as such? Or does the dispatch-sponsored WG meet during an ad-hoc time, or even chew up some time in the dispatch slot? In other words, once dispatch agrees to create a WG, what are the next steps that should be done? 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/ From mary.barnes@nortel.com Thu Jun 18 06:26:50 2009 Return-Path: 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 223D53A6B4C for ; Thu, 18 Jun 2009 06:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.344 X-Spam-Level: X-Spam-Status: No, score=-6.344 tagged_above=-999 required=5 tests=[AWL=0.255, 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 Pp2wvTm+dmJx for ; Thu, 18 Jun 2009 06:26:49 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id EA4D43A6A8E for ; Thu, 18 Jun 2009 06:26:48 -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 n5IDQvE21563; Thu, 18 Jun 2009 13:26:58 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: Thu, 18 Jun 2009 08:29:07 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E922D5C@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A3A3F6E.7080501@alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] IETF-75 plans for DISPATCH thread-index: AcnwF9Q6TVhYEVw/S3Ge/3n/y9vOegAAG4XQ References: <1ECE0EB50388174790F9694F77522CCF1E590C4B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E922A01@zrc2hxm0.corp.nortel.com> <4A3A3F6E.7080501@alcatel-lucent.com> From: "Mary Barnes" To: "Vijay K. Gurbani" , "Gonzalo Camarillo" Cc: dispatch@ietf.org, rai-ads@tools.ietf.org Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 13:26:50 -0000 The ADs go through the normal process to get a WG setup. These will be regular WGs - i.e., own slots at meetings, chairs, etc. I refer to these as "mini" WGs because they may only have one WG deliverable. The CLF work is in the plans as a regular WG. Until the WG is setup, if you need time at the meeting to discuss issues, then we can use some of the DISPATCH WG allocated time. =20 Mary.=20 -----Original Message----- From: Vijay K. Gurbani [mailto:vkg@alcatel-lucent.com]=20 Sent: Thursday, June 18, 2009 8:22 AM To: Barnes, Mary (RICH2:AR00); Gonzalo Camarillo Cc: dispatch@ietf.org; rai-ads@tools.ietf.org Subject: Re: [dispatch] IETF-75 plans for DISPATCH Mary Barnes wrote: > 4) CLF - a new WG has been proposed and is in the process of being=20 > formed. We will only allocate agenda time if open issues that cannot=20 > be resolved on the ML are identified. Mary, Gonzalo: This is a process-related question -- when we form a WG as a result of deliberations in dispatch, is this a formal WG that needs to be scheduled and managed as such? Or does the dispatch-sponsored WG meet during an ad-hoc time, or even chew up some time in the dispatch slot? In other words, once dispatch agrees to create a WG, what are the next steps that should be done? 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/ From mary.barnes@nortel.com Thu Jun 18 07:11:52 2009 Return-Path: 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 D84633A6B87 for ; Thu, 18 Jun 2009 07:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.333 X-Spam-Level: X-Spam-Status: No, score=-6.333 tagged_above=-999 required=5 tests=[AWL=0.266, 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 vXmwIyBk2q+k for ; Thu, 18 Jun 2009 07:11:50 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 8FF683A68A4 for ; Thu, 18 Jun 2009 07:11:50 -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 n5IEAYS11758; Thu, 18 Jun 2009 14:10:35 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: Thu, 18 Jun 2009 09:14:26 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E922E66@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] IETF-75 plans for DISPATCH thread-index: AcnvqJBYBpn3SP/cQNWVjEJ3oFCn4QAdLDdw References: <1ECE0EB50388174790F9694F77522CCF1E590C4B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E922A01@zrc2hxm0.corp.nortel.com> From: "Mary Barnes" To: "James M. Polk" , Cc: rai-ads@tools.ietf.org Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 14:11:53 -0000 I just want to pull one thing out of here - not necessarily specific to this topic or picking on James, but some general comments on the model we're trying to achieve. Yes, there has been lots of discussion on this topic, but that's actually a concern with docs that come in late. The attention span in RAI tends to be very short - a good example being Identity that was such a hot topic over the past year - we burned a lot of f2f meeting time on that topic over the past year (at least). The idea of the early deadlines was so that we could limit the topics that folks would need to pay attention to. I am actually concerned that there hasn't been more discussion for some of the other topics - e.g., 3rd party auth - that doc was one of the earliest to be posted for discussion, yet we haven't had any discussion since May 27th. =20 The whole idea of the model we're trying to achieve is that we want to avoid the f2f meetings being entirely on the initial discussions of shiny new topics (in particular -00 documents submitted at the deadlines), but rather be having the f2f discussions at the point where the problems have been adequately discussed such that the problem statement and scope is quite clear and achievable deliverables have been defined.=20 Thanks, Mary.=20 -----Original Message----- From: James M. Polk [mailto:jmpolk@cisco.com]=20 Sent: Wednesday, June 17, 2009 7:06 PM To: Barnes, Mary (RICH2:AR00); dispatch@ietf.org Cc: rai-ads@tools.ietf.org Subject: Re: [dispatch] IETF-75 plans for DISPATCH At 06:39 PM 6/17/2009, Mary Barnes wrote: >The additional topic on Session Recording was put forth after June 8th=20 >and has not yet been considered in the IETF-75 plans. However, if=20 >there is enough interest in the topic and folks committed to the work,=20 >then we may be able to allocate agenda time. I'm rather stunned that demonstrated interest isn't being considered sufficiently clear on this topic to the WG chairs or ADs. Of the last 75 messages to this list, more than half have been on this topic alone. I do agree this topic was late, but that ought to be stated as the only reason this topic doesn't progress at IETF75. Evidence of the vast debate we've had on this list proves folks are embracing this idea - even if they do not exactly have an idea of how it will look when finished - which is actually what we want in a WG, right? James From sdoken@qualcomm.com Thu Jun 18 10:24:22 2009 Return-Path: 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 3688428C2EE for ; Thu, 18 Jun 2009 10:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.999 X-Spam-Level: X-Spam-Status: No, score=-103.999 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WkKZxKRnBhz for ; Thu, 18 Jun 2009 10:24:20 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id A9AE728C377 for ; Thu, 18 Jun 2009 10:24:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=sdoken@qualcomm.com; q=dns/txt; s=qcdkim; t=1245345873; x=1276881873; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Doken,=20Serhad"=20|To:=20 Francois=20Audet=20,=20"James=20M.=20Po lk"=20,=0D=0A=20=20=20=20=20=20=20=20Pa ul=20Kyzivat=20,=0D=0A=20=20=20=20=20 =20=20=20Hadriel=20Kaplan=20|CC: =20"'Leon=20Portman'"=20,=0D=0A=20 =20=20=20=20=20=20=20"dispatch@ietf.org"=0D=0A=09,=0D=0A=20=20=20=20=20=20=20=20"'Jain,=09Rajni sh'"=20,=0D=0A=20=20=20=20=20=20=20 =20Roni=20Even=0D=0A=09|Date:=20Thu ,=2018=20Jun=202009=2010:24:21=20-0700|Subject:=20RE:=20[ dispatch]=20Session=20recording=20in=20SIP|Thread-Topic: =20[dispatch]=20Session=20recording=20in=20SIP |Thread-Index:=20AcnrD9BjXrOnCAToRe+3AbjNNYbITQE3cG0w |Message-ID:=20|References:=20=0D=0A=20|In-Reply-To:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5650"=3B=20a=3D"19592294"; bh=NKhALI+Uo9S5GJf5VORnlv0OPYSIqqGktxPWkCjs9YQ=; b=bO4yJVXRkvCzxLRfO2ksHl6nDE6qnZCJqeUS9pKVEprxoyBrL5kfaE6K J593WpZmcVKkwh+t1VcYEMRlo6JGlondGo90qSmnp/wcHW3bH+L6kwuap xCA7Cm9+6EvGOcm+YmBD/wRpYo1IDePIlNEED8Lw7KmGaUejX0dFIZqfJ Y=; X-IronPort-AV: E=McAfee;i="5300,2777,5650"; a="19592294" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Jun 2009 10:24:33 -0700 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n5IHOWgP019460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 18 Jun 2009 10:24:32 -0700 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n5IHOSsI023892 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 18 Jun 2009 10:24:29 -0700 (PDT) Received: from NASANEXMB09.na.qualcomm.com ([129.46.53.121]) by nasanexhub03.na.qualcomm.com ([10.46.93.98]) with mapi; Thu, 18 Jun 2009 10:24:28 -0700 From: "Doken, Serhad" To: Francois Audet , "James M. Polk" , Paul Kyzivat , Hadriel Kaplan Date: Thu, 18 Jun 2009 10:24:21 -0700 Thread-Topic: [dispatch] Session recording in SIP Thread-Index: AcnrD9BjXrOnCAToRe+3AbjNNYbITQE3cG0w Message-ID: References: In-Reply-To: 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 Cc: 'Leon Portman' , "dispatch@ietf.org" , "'Jain, Rajnish'" , Roni Even Subject: Re: [dispatch] Session recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 17:24:22 -0000 Comment on (6) :=20 Once people pay for an expensive SIP Phone with fair Dsp power, they expect= that endpoint trigger the recording/fork the stream towards the recorder(s= ) as well. For those cases, it's hard to convince folks/justify the need to= increase the resources on the server/B2BUA/gateway to do recording for man= y endpoints when an endpoint itself is capable of doing so. Moreover, forking a stream is not all that expensive(cpu intensive). A phon= e, even a basic one, that can do 3-way conferencing can easily make a copy = of a stream and send somewhere else.=20 Serhad > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Francois Audet > Sent: Thursday, June 11, 2009 8:43 PM > To: James M. Polk; Paul Kyzivat; Hadriel Kaplan > Cc: 'Leon Portman'; dispatch@ietf.org; 'Jain, Rajnish'; Roni Even > Subject: Re: [dispatch] Session recording in SIP >=20 > I agree with James. >=20 > There are *some* scenarios where the UA-initiated recording will work, > but > they are very limited. They have the following disadvantages: > 1- It makes the client "aware" that it is being recorded > 2- It makes it very easy to avoid being recorded by interrupting the > media > stream > 3 - It makes it much easier to "dispute" (i.e., lawyers) the > authenticity of > a recorded conversation if there is potential for significant > differences in > the streams as seen by different ends > 4 - It doubles the bandwidth requirements on the UA, which can be a > problem > in some scenarios > 5 - It doubles the processing power required in the client (think > SRTP/key > negotiation & al). This can be a problem with many phones. > 6 - They require phones that actually support this. Which means, you > can't > use "normal" SIP phones. Which means, if you get the $30 phone, you > don't > get tapped into, but if you get the $300 phone, you don't. >=20 >=20 > But UA-initiated recording has very few advantages: > 1 - Less work on servers. This is actually a big advantage because lots > of > servers are so complex, it is difficult to do anything new on them. > 2 - Looks much more abstract and cool in an IETF RFC :-) >=20 >=20 > On Jun11 2009 19:13 , "James M. Polk" wrote: >=20 > > At 06:11 PM 6/11/2009, Paul Kyzivat wrote: > > > > > >> Hadriel Kaplan wrote: > >>> Hey Roni, > >>> Being a middlebox man myself, a B2BUA doing the media forking makes > >>> the most sense to me too, but some other folks don't do it/want-it > >>> that way. So the proposed work is to cover both potential models. > >>> The statement you cite reflects the belief that the solution to the > >>> requirements will be to use SIP between the UA doing the media > >>> forking, and the recorder doing the collection; and that the work > >>> of specification will be to define that. > >>> So one diagram could be this, where "TBD" is the To-Be-Defined > work: > >>> +-----+ +-----+ > >>> | | Call | | > >>> |UA-A +<------------>+UA-B | > >>> | | | | > >>> +-++--+ +-----+ > >>> \\ > >>> \\ > >>> TBD \\ > >>> \\+----------+ > >>> \+ | > >>> + Recorder | > >>> | | > >>> +----------+ > >> > >> This model actually can make a lot of sense in *some* circumstances. > >> For instance, in a call center, where you may have control over what > >> components are used throughout, it could make sense to do the media > >> forking for recording and monitoring right at the agent phone. > > > > Paul - how is your call center example *not* better accomplished with > > the figure below instead of the figure above? > > > > It seems to me that any enterprise based call center would have to > > have a SIP server of some form (i.e., the caller is not going to have > > a pt-to-pt SIP established session directly with a call center call > > taker). It seems much easier if that call center wants to record > > calls (even some of the calls, that to the caller, the B2BUA is the > > UAS, meaning the sRTP keys only have to be between the caller and the > > B2BUA, and not all the way to the call taker. In this scenario, the > > B2BUA merely replicates the RTP stream out towards the recording > > device with RTCP in tact, an can allow the B2BUA provide any meta > > data about the specifics of the call signaling it wants to also > store. > > > > This scenario also means the caller is never aware the call is being > > recorded, creating anonymity wrt that facet of the solution. > > > > I'm not advocating B2BUAs here, I just see this as a better solution > > for call center type recording than pt-to-pt between caller and call > taker. > > > > > >> But in those sorts of monitoring/recording we don't talk about in > >> IETF, its essential that the recorded parties not be able to > >> distinguish calls that are monitored from those that are not. > >> Anything that requires cooperation by one of the endpoints is a > >> no-go. Even something as simple as a middlebox replacing one media > >> port with another in order to initiate monitoring might be enough to > >> clue in the monitored parties. So in those cases you had better > >> have a way that looks exactly the same whether recording is > >> happening or not, which generally requires something like your > picture below. > >> > >> Thanks, > >> Paul > >> > >>> Or this: > >>> > >>> +-----+ +-----+ +-----+ > >>> | | Call | | Call | | > >>> |UA-A +<------------>+B2BUA+<------------>+UA-B | > >>> | | | | | | > >>> +-----+ +-++--+ +-----+ > >>> \\ > >>> \\ > >>> TBD \\ > >>> \\+----------+ > >>> \+ | > >>> + Recorder | > >>> | | > >>> +----------+ > >>> -hadriel > >>> > >>>> -----Original Message----- > >>>> From: Roni Even [mailto:Even.roni@huawei.com] > >>>> Sent: Thursday, June 11, 2009 3:54 PM > >>>> To: Hadriel Kaplan; 'Hutton, Andrew'; 'Alan Johnston'; 'Romascanu, > Dan > >>>> (Dan)' > >>>> Cc: 'Leon Portman'; dispatch@ietf.org; 'Jain, Rajnish' > >>>> Subject: RE: [dispatch] Session recording in SIP > >>>> > >>>> Hadriel, > >>>> I am still confused by the following text which was the reason for > the > >>>> previous question > >>>> > >>>> "This group will specify requirements for a SIP based protocol > interface > >>>> between a communications system and a recorder. The Communications > System > >>>> is > >>>> responsible for establishing media sessions where the actual > business is > >>>> conducted. The Recorder is the sink of the recorded media." > >>>> > >>>> > >>>> Can someone draw a figure showing the talking parties the > Communication > >>>> system and the recorder and explain where is this interface. > According to > >>>> your response I can think that there are at least two separate > >>>> architectures > >>>> your are proposing one where the parties (or one of them) in the > call know > >>>> the recorder and somehow forwards the media to it. The other > architecture > >>>> has some B2BUA in the call path who is either forking the media to > the > >>>> recorder and to the parties or the recorder is in the middle of > the media > >>>> path. > >>> _______________________________________________ > >>> 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 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From fluffy@cisco.com Thu Jun 18 11:58:05 2009 Return-Path: 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 AC85528C377 for ; Thu, 18 Jun 2009 11:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.579 X-Spam-Level: X-Spam-Status: No, score=-106.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 gN+S7OAZfCKp for ; Thu, 18 Jun 2009 11:58:05 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id F0F8328C2E0 for ; Thu, 18 Jun 2009 11:58:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,246,1243814400"; d="scan'208";a="81630742" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 18 Jun 2009 18:58:17 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n5IIwHEm012094 for ; Thu, 18 Jun 2009 11:58:17 -0700 Received: from dhcp-171-68-21-22.cisco.com (dhcp-171-68-21-22.cisco.com [171.68.21.22]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n5IIwHYj014491 for ; Thu, 18 Jun 2009 18:58:17 GMT Message-Id: From: Cullen Jennings To: dispatch@ietf.org In-Reply-To: <1244840653.21162.349.camel@scott> 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, 18 Jun 2009 11:58:19 -0700 References: <4A32B18A.3010309@cisco.com> <1244840653.21162.349.camel@scott> X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1257; t=1245351497; x=1246215497; 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 |Subject:=20Re=3A=20[dispatch]=20Session=20recording=20in=2 0SIP |Sender:=20; bh=cQo3oIy9qjL5hXHbom2RToT0IARZVx3sQjBnub7Xpk8=; b=fp0FcG2D6lZnzCrbloJwaN+kgBZQM3/H252XGQcWNIahFvlJYaP8aa9W8/ FLyA8ezHUORV7q2gaNfaMxrlhUgfPA+uZnT/I2jLZ3T2sSt6LfmZGS97wlFN K0wIznrrYW; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [dispatch] Session recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 18:58:05 -0000 Scott and Mary nicely expressed what I was thinking about where to run this discussion. On Jun 12, 2009, at 14:04 , Scott Lawrence wrote: > I also agree with previous posters that while this overlaps > with XCON and some other things, it's really a distinct problem and > would probably be solvable more quickly in a more focused setting. > One > of the major ideas behind our recent reorg was that smaller, more > time-limited WGs will work better than the perpetual ones we've been > using. On Jun 10, 2009, at 19:08 , Mary Barnes wrote: > At this stage, DISPATCH is the appropriate place to be having these > discussions. Since this topic was just introduced to the WG yesterday, > it's a bit too early, and not obvious based on the various opinions > expressed thus far, to decide that it might belong elsewhere, need a > new > WG/BoF, etc. So, let's continue the discussion on DISPATCH and refine > the problem space and solution scope. Lets focus the conversation on what is the problem to solve, what's the big picture, what needs to be standardized then we can send the right parts off to an existing group or form a new WG and do the technical work of developing the standard. Cullen From fluffy@cisco.com Thu Jun 18 12:05:28 2009 Return-Path: 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 7F50B3A69F9 for ; Thu, 18 Jun 2009 12:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.58 X-Spam-Level: X-Spam-Status: No, score=-106.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 DaR9VjF01r9j for ; Thu, 18 Jun 2009 12:05:27 -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 A7D3B3A68BD for ; Thu, 18 Jun 2009 12:05:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,246,1243814400"; d="scan'208";a="177940063" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 18 Jun 2009 19:05:40 +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 n5IJ5ebn006714 for ; Thu, 18 Jun 2009 12:05:40 -0700 Received: from dhcp-171-68-21-22.cisco.com (dhcp-171-68-21-22.cisco.com [171.68.21.22]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n5IJ5eQD023809 for ; Thu, 18 Jun 2009 19:05:40 GMT Message-Id: <40730EBC-4923-4EB1-A3E7-3234888F48FB@cisco.com> From: Cullen Jennings To: dispatch@ietf.org In-Reply-To: <023d01c9e9e7$1b015880$51040980$%roni@huawei.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: Thu, 18 Jun 2009 12:05:42 -0700 References: <4A2ECDB2.7000601@alcatel-lucent.com> <4A2FB842.7050302@sipstation.com> <023d01c9e9e7$1b015880$51040980$%roni@huawei.com> X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1155; t=1245351940; x=1246215940; 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 |Subject:=20Re=3A=20[dispatch]=20Session=20recording=20in=2 0SIP |Sender:=20; bh=1srMbNotGj7W97B9gBqyMMBNVN3x10kE8sDGrfMIpVM=; b=Dcgt4s58dyAkMqwCcsFCWKs1f8M+jUBEOS150ZhtdOX2U17GcUttRT9ZFH 7rVbMdq1Aj5K5OOctqR2Bz4sddtREipa+vsHGsifEQWAVDFfeeANiYYGUXo9 JjiFrAbLeV; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [dispatch] Session recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 19:05:28 -0000 I look forward to reading the requirements draft when that comes out as it may answer this but ... >>> A prime example where >>> voice is used for trade is the financial industry. The call >>> recording requirements in this industry are quite stringent. >>> The recorded calls are used for dispute resolution and >>> regulatory compliance. Other businesses such as customer >>> support call centers typically employ call recording for >>> quality control or business analytics. So in the case where a customer is talking to an agent, my understanding is that some of the deployments (often legal compliance type situations) require an accurate recording of what the agent heard while other sorts of deployments may (perhaps a post call statistical analysis) only care about an best effort approximation of the call. So in the first case, if the call could not be recorded, the call would not be set up but in the second case, the call would go ahead regardless. I'm assuming the scope of the work would cover both case. Does that sound about right to others? Cullen From fluffy@cisco.com Thu Jun 18 12:16:08 2009 Return-Path: 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 7ED983A68CE for ; Thu, 18 Jun 2009 12:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.581 X-Spam-Level: X-Spam-Status: No, score=-106.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 NX8dgoL8Sbfw for ; Thu, 18 Jun 2009 12:16:07 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 9C2353A6806 for ; Thu, 18 Jun 2009 12:16:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,246,1243814400"; d="scan'208";a="171158864" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 18 Jun 2009 19:16:18 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n5IJGIap012269; Thu, 18 Jun 2009 12:16:18 -0700 Received: from dhcp-171-68-21-22.cisco.com (dhcp-171-68-21-22.cisco.com [171.68.21.22]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id n5IJGIiZ020847; Thu, 18 Jun 2009 19:16:18 GMT Message-Id: From: Cullen Jennings To: "Vijay K. Gurbani" In-Reply-To: <4A3A3F6E.7080501@alcatel-lucent.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: Thu, 18 Jun 2009 12:16:19 -0700 References: <1ECE0EB50388174790F9694F77522CCF1E590C4B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E922A01@zrc2hxm0.corp.nortel.com> <4A3A3F6E.7080501@alcatel-lucent.com> X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=599; t=1245352578; x=1246216578; 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 |Subject:=20Re=3A=20[dispatch]=20IETF-75=20plans=20for=20DI SPATCH |Sender:=20; bh=LosKRf4Sor/pv2SvGmo4lDTTtpFDWhOQVnrNzP8zOt0=; b=2KppsDILbNMZILI/MRKJSphxELbRaGWmfVx3pShsSqGxBKPSK6fWoBubqt 2NbserjODl5sKWIgFs9GZ94dCnED9wXRtGrNqU/vyep2lcNyTGarE60Wdut9 Z/Rs2bQ5xV; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: dispatch@ietf.org, rai-ads@tools.ietf.org Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 19:16:08 -0000 On Jun 18, 2009, at 6:21 , Vijay K. Gurbani wrote: > > In other words, once dispatch agrees to create a WG, what > are the next steps that should be done? It's the standard IETF process. Typical flow for things coming from DISPATCH would be submit a charter to ADs. ADs will put it on IESG agenda for approval to go out to IETF. When this is approved it will be sent out for IETF Last Call and comments collect. Then it goes back on IESG agenda for approval as a working group. From that point on it is run as a normal WG and get time allocated at IETF meetings. Cullen From jgunn6@csc.com Thu Jun 18 12:27:01 2009 Return-Path: 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 AB8943A6A21; Thu, 18 Jun 2009 12:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zodo6o4IvNWL; Thu, 18 Jun 2009 12:27:00 -0700 (PDT) Received: from mail170.messagelabs.com (mail170.messagelabs.com [216.82.253.227]) by core3.amsl.com (Postfix) with ESMTP id 695E93A68CE; Thu, 18 Jun 2009 12:27:00 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-2.tower-170.messagelabs.com!1245353221!15854006!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [20.137.2.88] Received: (qmail 23393 invoked from network); 18 Jun 2009 19:27:02 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-2.tower-170.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 18 Jun 2009 19:27:02 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.3.3mp/Switch-3.3.3mp) with ESMTP id n5IJR0tC028541; Thu, 18 Jun 2009 15:27:01 -0400 In-Reply-To: To: Cullen Jennings MIME-Version: 1.0 X-Mailer: Lotus Notes 652HF83 November 04, 2004 From: Janet P Gunn Message-ID: Date: Thu, 18 Jun 2009 15:26:58 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF996|December 23, 2008) at 06/18/2009 03:28:53 PM, Serialize complete at 06/18/2009 03:28:53 PM Content-Type: multipart/alternative; boundary="=_alternative 006AD6B2852575D9_=" Cc: dispatch-bounces@ietf.org, dispatch@ietf.org, rai-ads@tools.ietf.org Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 19:27:01 -0000 This is a multipart message in MIME format. --=_alternative 006AD6B2852575D9_= Content-Type: text/plain; charset="US-ASCII" Does this mean that "dispatch" is effectively a continuous BoF? Or does it mean that AFTER you get the dispatch "seal of approval", THEN you have a BoF? Janet dispatch-bounces@ietf.org wrote on 06/18/2009 03:16:19 PM: > > On Jun 18, 2009, at 6:21 , Vijay K. Gurbani wrote: > > > > > In other words, once dispatch agrees to create a WG, what > > are the next steps that should be done? > > It's the standard IETF process. Typical flow for things coming from > DISPATCH would be submit a charter to ADs. ADs will put it on IESG > agenda for approval to go out to IETF. When this is approved it will > be sent out for IETF Last Call and comments collect. Then it goes back > on IESG agenda for approval as a working group. From that point on it > is run as a normal WG and get time allocated at IETF meetings. > > Cullen > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --=_alternative 006AD6B2852575D9_= Content-Type: text/html; charset="US-ASCII"

Does this mean that "dispatch" is effectively a continuous BoF?

Or does it mean that AFTER you get the dispatch "seal of approval", THEN you have a BoF?

Janet

dispatch-bounces@ietf.org wrote on 06/18/2009 03:16:19 PM:

>
> On Jun 18, 2009, at 6:21 , Vijay K. Gurbani wrote:
>
> >
> > In other words, once dispatch agrees to create a WG, what
> > are the next steps that should be done?
>
> It's the standard IETF process. Typical flow for things coming from  
> DISPATCH would be submit a charter to ADs. ADs will put it on IESG  
> agenda for approval to go out to IETF. When this is approved it will  
> be sent out for IETF Last Call and comments collect. Then it goes back  
> on IESG agenda for approval as a working group. From that point on it  
> is run as a normal WG and get time allocated at IETF meetings.
>
> Cullen
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
 --=_alternative 006AD6B2852575D9_=-- From mary.barnes@nortel.com Thu Jun 18 12:51:03 2009 Return-Path: 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 5FF3F28C2E0; Thu, 18 Jun 2009 12:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.276 X-Spam-Level: X-Spam-Status: No, score=-6.276 tagged_above=-999 required=5 tests=[AWL=0.322, 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 SkW2Dtma1wG5; Thu, 18 Jun 2009 12:51:02 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 1F56028C16D; Thu, 18 Jun 2009 12:51:01 -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 n5IJp8I03072; Thu, 18 Jun 2009 19:51:09 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_01C9F04E.14B4BF98" Date: Thu, 18 Jun 2009 14:53:20 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E97318D@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] IETF-75 plans for DISPATCH thread-index: AcnwStag991pSQbkSHOiVKEVKnrUPAAAvpXg References: From: "Mary Barnes" To: "Janet P Gunn" , "Cullen Jennings" Cc: dispatch@ietf.org, dispatch-bounces@ietf.org, rai-ads@tools.ietf.org Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 19:51:03 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9F04E.14B4BF98 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I wouldn't look at it that way. For example, for CLF, there was not a BoF and a new WG is planned - i.e., you don't have to have a BoF to start a new WG and I would think that would be more the rule than the exception. Out of the 7 items that were put on the table by June 8th, only one BoF is planned. So, dispatch is more of a continous discussion of new ideas and farming out the work to other WGs, a BoF, a new WG or as individual/AD sponsored work. That all said, some of the topic discussions in the DISPATCH WG f2f meetings might look like "mini" BoFs - for example the cc-uui topic.=20 =20 Regards, Mary.=20 ________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Janet P Gunn Sent: Thursday, June 18, 2009 2:27 PM To: Cullen Jennings Cc: dispatch-bounces@ietf.org; dispatch@ietf.org; rai-ads@tools.ietf.org Subject: Re: [dispatch] IETF-75 plans for DISPATCH Does this mean that "dispatch" is effectively a continuous BoF?=20 Or does it mean that AFTER you get the dispatch "seal of approval", THEN you have a BoF?=20 Janet=20 dispatch-bounces@ietf.org wrote on 06/18/2009 03:16:19 PM: >=20 > On Jun 18, 2009, at 6:21 , Vijay K. Gurbani wrote: >=20 > > > > In other words, once dispatch agrees to create a WG, what > > are the next steps that should be done? >=20 > It's the standard IETF process. Typical flow for things coming from =20 > DISPATCH would be submit a charter to ADs. ADs will put it on IESG =20 > agenda for approval to go out to IETF. When this is approved it will =20 > be sent out for IETF Last Call and comments collect. Then it goes back > on IESG agenda for approval as a working group. From that point on it > is run as a normal WG and get time allocated at IETF meetings. >=20 > Cullen >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch ------_=_NextPart_001_01C9F04E.14B4BF98 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I=20 wouldn't look at it that way.  For example, for CLF, there was not = a BoF=20 and a new WG is planned -  i.e., you don't have to have a BoF to = start a=20 new WG and I would think that would be more the rule than the exception. = Out of=20 the 7 items that were put on the table by June 8th, only one BoF is=20 planned.  So, dispatch is more of a continous discussion of new = ideas and=20 farming out the work to other WGs, a BoF, a new WG or as individual/AD = sponsored=20 work.  That all said, some of the topic discussions =  in the=20 DISPATCH WG f2f meetings might look like "mini" BoFs - for example the = cc-uui=20 topic.
 
Regards,
Mary.=20

From: dispatch-bounces@ietf.org=20 [mailto:dispatch-bounces@ietf.org] On Behalf Of Janet P=20 Gunn
Sent: Thursday, June 18, 2009 2:27 PM
To: = Cullen=20 Jennings
Cc: dispatch-bounces@ietf.org; dispatch@ietf.org;=20 rai-ads@tools.ietf.org
Subject: Re: [dispatch] IETF-75 plans = for=20 DISPATCH



Does this mean that = "dispatch"=20 is effectively a continuous BoF?

Or=20 does it mean that AFTER you get the dispatch "seal of approval", THEN = you have a=20 BoF?

Janet =

dispatch-bounces@ietf.org wrote on 06/18/2009 03:16:19=20 PM:

>
> On Jun 18, 2009, at 6:21 , Vijay K. Gurbani=20 wrote:
>
> >
> > In other words, once dispatch = agrees=20 to create a WG, what
> > are the next steps that should be=20 done?
>
> It's the standard IETF process. Typical flow for = things=20 coming from  
> DISPATCH would be submit a charter to ADs. = ADs will=20 put it on IESG  
> agenda for approval to go out to IETF. = When this=20 is approved it will  
> be sent out for IETF Last Call and = comments=20 collect. Then it goes back  
> on IESG agenda for approval as = a=20 working group. From that point on it  
> is run as a normal = WG and=20 get time allocated at IETF meetings.
>
> Cullen
> =
>=20 _______________________________________________
> dispatch mailing = list
> dispatch@ietf.org
>=20 https://www.ietf.org/mailman/listinfo/dispatch
 ------_=_NextPart_001_01C9F04E.14B4BF98-- From alan@sipstation.com Thu Jun 18 14:26:25 2009 Return-Path: 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 A00743A6C45 for ; Thu, 18 Jun 2009 14:26:25 -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 iZ2qNWX75zDe for ; Thu, 18 Jun 2009 14:26:24 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 925183A67E2 for ; Thu, 18 Jun 2009 14:26:24 -0700 (PDT) Received: from 24-107-193-18.dhcp.stls.mo.charter.com ([24.107.193.18] helo=aidan-DS.sipserver.homeip.net) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1MHP80-000P8G-JU; Thu, 18 Jun 2009 21:26:36 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.107.193.18 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19zx3NbNDwTW+Vchhd8FE2MpOdu95P9fkY= Message-ID: <4A3AB109.9080409@sipstation.com> Date: Thu, 18 Jun 2009 16:26:33 -0500 From: Alan Johnston User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Cullen Jennings References: <4A2ECDB2.7000601@alcatel-lucent.com> <4A2FB842.7050302@sipstation.com> <023d01c9e9e7$1b015880$51040980$%roni@huawei.com> <40730EBC-4923-4EB1-A3E7-3234888F48FB@cisco.com> In-Reply-To: <40730EBC-4923-4EB1-A3E7-3234888F48FB@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] Session recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 21:26:25 -0000 Cullen Jennings wrote: > > I look forward to reading the requirements draft when that comes out > as it may answer this but ... > >>>> A prime example where >>>> voice is used for trade is the financial industry. The call >>>> recording requirements in this industry are quite stringent. >>>> The recorded calls are used for dispute resolution and >>>> regulatory compliance. Other businesses such as customer >>>> support call centers typically employ call recording for >>>> quality control or business analytics. > > So in the case where a customer is talking to an agent, my > understanding is that some of the deployments (often legal compliance > type situations) require an accurate recording of what the agent heard > while other sorts of deployments may (perhaps a post call statistical > analysis) only care about an best effort approximation of the call. > So in the first case, if the call could not be recorded, the call > would not be set up but in the second case, the call would go ahead > regardless. > > I'm assuming the scope of the work would cover both case. Does that > sound about right to others? > Yes - we need to cover the various modes. We described four in our draft (http://tools.ietf.org/html/draft-wing-sipping-srtp-key): 1. Always On Recording 2. Recording On Demand 3. Required Recording 4. Pause and Resume Recording There may be others as well, but these cover all the ones we support in our systems today. Some are different by policy, others are different in actual call flows. Thanks, Alan > Cullen > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From volkerh@bell-labs.com Fri Jun 19 06:52:42 2009 Return-Path: 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 8EDAA3A689E for ; Fri, 19 Jun 2009 06:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[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 dbfZ6Zuwm7PV for ; Fri, 19 Jun 2009 06:52:41 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id DFE553A6879 for ; Fri, 19 Jun 2009 06:52:40 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n5JDqd3o017767 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 19 Jun 2009 15:52:39 +0200 Received: from [135.244.227.138] (135.120.57.7) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.1.340.0; Fri, 19 Jun 2009 15:52:39 +0200 Message-ID: <4A3B98E2.2090104@bell-labs.com> Date: Fri, 19 Jun 2009 15:55:46 +0200 From: Volker Hilt User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) 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 155.132.188.83 Subject: [dispatch] SIP overload control mailing list X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 13:52:42 -0000 All, we have set up a new mailing list for discussions around SIP overload control. We will move the discussions of the SIP overload control design team to the new list. Everyone interested in actively contributing to the topic is welcome to join. The URL of the list is: https://www.ietf.org/mailman/listinfo/sip-overload Thanks, Volker From vkg@alcatel-lucent.com Sun Jun 21 21:08:42 2009 Return-Path: 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 8966428C138 for ; Sun, 21 Jun 2009 21:08:42 -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 q+k0difQayQB for ; Sun, 21 Jun 2009 21:08:41 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 6D41C28C195 for ; Sun, 21 Jun 2009 21:08:40 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id n5M48qbu012784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 21 Jun 2009 23:08:52 -0500 (CDT) Received: from shoonya.ih.lucent.com (guard.research.bell-labs.com [135.104.2.10]) by umail.lucent.com (8.13.8/TPES) with ESMTP id n5M48pSf009731 for ; Sun, 21 Jun 2009 23:08:52 -0500 (CDT) Message-ID: <4A3F03F6.6060505@alcatel-lucent.com> Date: Sun, 21 Jun 2009 23:09:26 -0500 From: Vijay Gurbani 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.39 Subject: [dispatch] Summary on Session Recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 04:08:42 -0000 All: Here is the summary of the Session Recording thread from June 9 to June 19, 2009. If I misrepresented anything, please let me know. There was a fair amount of discussion on where to conduct this work. In the end, it was decided to continue discussions on dispatch, further decisions what to do -- new working group or put this work in an existing working group -- will be decided later. Regardless of where the work is done, opinions were expressed that the work is important that it should commence in the IETF. Need to be crisp about the purpose of this work: is it that users record sessions to hear later, or sessions need to be recorded because of some business needs? Or both? Is SRTP covered or only RTP? Solutions should cover: Always on recording Recording on demand Required recording Pause and resume recording Playback facilities and how they interact with recording Recording formats and protocols for controlling the stored recording. A lot of discussion ensued on the specific architecture or architectures that would be possible. No decision was reached on which specific architecture is good or bad, although various opinions were expressed in support for each. There are essentially four architectures to realize recording services: two that discuss where the media stream is forked out to the recorder -- at the UA or in a middlebox of some sort are outlined here: http://www.ietf.org/mail-archive/web/dispatch/current/msg00226.html The third architecture has both UAs sending media to a recorder. See: http://www.ietf.org/mail-archive/web/dispatch/current/msg00236.html A fourth architecture that is a superset of the third one is at: http://www.ietf.org/mail-archive/web/dispatch/current/msg00256.html - 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 fluffy@cisco.com Mon Jun 22 10:58:01 2009 Return-Path: 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 9CAAA28C22E for ; Mon, 22 Jun 2009 10:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.585 X-Spam-Level: X-Spam-Status: No, score=-106.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 R6hj2gRYxbVo for ; Mon, 22 Jun 2009 10:58:00 -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 487363A6C85 for ; Mon, 22 Jun 2009 10:57:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,270,1243814400"; d="scan'208";a="179105191" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 22 Jun 2009 17:58:15 +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 n5MHwEEa019177; Mon, 22 Jun 2009 10:58:14 -0700 Received: from dhcp-171-68-21-121.cisco.com (dhcp-171-68-21-121.cisco.com [171.68.21.121]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n5MHwEGq023073; Mon, 22 Jun 2009 17:58:14 GMT Message-Id: <525F1000-3AB8-4C0D-90AB-A14F20D892B1@cisco.com> From: Cullen Jennings To: Janet P Gunn In-Reply-To: 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: Mon, 22 Jun 2009 10:58:17 -0700 References: X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1390; t=1245693494; x=1246557494; 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 |Subject:=20Re=3A=20[dispatch]=20IETF-75=20plans=20for=20DI SPATCH |Sender:=20; bh=7VL+B1f2lBWtm/ujjZa5X78us4YdRK59C6CymAKo3+k=; b=uwKyWGwr+wvAOjwlrPizBU5TXXY69o+ikHRmV/suBm/O5rwPrB2ZRJ8gyp cUYpZ/fsW75DPJhjgNwKZQc6zCgWH9MEtGP4e0PR9e33pS1LSG0WCBHkoNtj iIghpFeW01; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: dispatch@ietf.org, rai-ads@tools.ietf.org Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 17:58:01 -0000 On Jun 18, 2009, at 12:26 , Janet P Gunn wrote: > > > Does this mean that "dispatch" is effectively a continuous BoF? > > Or does it mean that AFTER you get the dispatch "seal of approval", > THEN you have a BoF? > Closer to the first than the second. We certainly don't want to add an extra step to make it even take longer to form new WGs. The general plan is for things that get consensus or form a WG in DISPATCH, to go directly to IESG approval step without a BOF. > Janet > > dispatch-bounces@ietf.org wrote on 06/18/2009 03:16:19 PM: > > > > > On Jun 18, 2009, at 6:21 , Vijay K. Gurbani wrote: > > > > > > > > In other words, once dispatch agrees to create a WG, what > > > are the next steps that should be done? > > > > It's the standard IETF process. Typical flow for things coming from > > DISPATCH would be submit a charter to ADs. ADs will put it on IESG > > agenda for approval to go out to IETF. When this is approved it will > > be sent out for IETF Last Call and comments collect. Then it goes > back > > on IESG agenda for approval as a working group. From that point on > it > > is run as a normal WG and get time allocated at IETF meetings. > > > > Cullen > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch From pkyzivat@cisco.com Mon Jun 22 11:35:55 2009 Return-Path: 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 73EAE3A6DEE for ; Mon, 22 Jun 2009 11:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.554 X-Spam-Level: X-Spam-Status: No, score=-6.554 tagged_above=-999 required=5 tests=[AWL=0.045, 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 QJlJd63RBqvs for ; Mon, 22 Jun 2009 11:35:54 -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 68F963A6DB9 for ; Mon, 22 Jun 2009 11:35:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,270,1243814400"; d="scan'208";a="203928964" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-1.cisco.com with ESMTP; 22 Jun 2009 18:36:09 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n5MIa9Un029075; Mon, 22 Jun 2009 14:36:09 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n5MIa9hN022137; Mon, 22 Jun 2009 18:36:09 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.3959); Mon, 22 Jun 2009 14:36:09 -0400 Received: from [161.44.182.195] ([161.44.182.195]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Jun 2009 14:36:09 -0400 Message-ID: <4A3FCF18.6020403@cisco.com> Date: Mon, 22 Jun 2009 14:36:08 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Vijay Gurbani References: <4A3F03F6.6060505@alcatel-lucent.com> In-Reply-To: <4A3F03F6.6060505@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jun 2009 18:36:09.0114 (UTC) FILETIME=[4F6817A0:01C9F368] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2420; t=1245695769; x=1246559769; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[dispatch]=20Summary=20on=20Session=20R ecording=20in=20SIP |Sender:=20 |To:=20Vijay=20Gurbani=20; bh=YipbY1b65S39RG24DmEOV34fPZfKVeH573eE/ILATN4=; b=HG0f12guLnMGUIIzrbquPWcLvRVOUONsWnFvNWryMfeHnTnrqy4r6YarP1 YTytRlxXYaFhU6L+6apdDR99uYW/rctgeVKkFH76ashokf6MpqbYzcsNnsub bpWH9eIQV1; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: dispatch@ietf.org Subject: Re: [dispatch] Summary on Session Recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 18:35:55 -0000 A real simple question about intended scope: Does this include a direct session between a UAC and a UAS whose purpose is recording, such as for a VM system? (A VM system does seem to be a special case of "recording on demand", and also often includes playback facilities.) I had the impression that this work was more scoped toward cases where there is an interactive session between two or more parties, and that recording is intended to be supplemental to that. Thanks, Paul Vijay Gurbani wrote: > All: Here is the summary of the Session Recording thread from June 9 > to June 19, 2009. If I misrepresented anything, please let me know. > > There was a fair amount of discussion on where to conduct this > work. In the end, it was decided to continue discussions on > dispatch, further decisions what to do -- new working group or > put this work in an existing working group -- will be decided > later. Regardless of where the work is done, opinions were > expressed that the work is important that it should commence > in the IETF. > > Need to be crisp about the purpose of this work: is it that users > record sessions to hear later, or sessions need to be recorded > because of some business needs? Or both? Is SRTP covered or > only RTP? > > Solutions should cover: > Always on recording > Recording on demand > Required recording > Pause and resume recording > Playback facilities and how they interact with recording > Recording formats and protocols for controlling the stored recording. > > A lot of discussion ensued on the specific architecture or > architectures that would be possible. No decision was reached on > which specific architecture is good or bad, although various opinions > were expressed in support for each. > > There are essentially four architectures to realize recording > services: two that discuss where the media stream is forked > out to the recorder -- at the UA or in a middlebox of some > sort are outlined here: > http://www.ietf.org/mail-archive/web/dispatch/current/msg00226.html > > The third architecture has both UAs sending media to a > recorder. See: > http://www.ietf.org/mail-archive/web/dispatch/current/msg00236.html > > A fourth architecture that is a superset of the third one is at: > http://www.ietf.org/mail-archive/web/dispatch/current/msg00256.html > > - vijay From jmh@joelhalpern.com Mon Jun 22 11:55:44 2009 Return-Path: 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 CE1953A67A3 for ; Mon, 22 Jun 2009 11:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.654 X-Spam-Level: X-Spam-Status: No, score=-3.654 tagged_above=-999 required=5 tests=[AWL=-0.055, 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 sDjxkmecCnwu for ; Mon, 22 Jun 2009 11:55:43 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 41C7C3A6817 for ; Mon, 22 Jun 2009 11:55:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id E0487430287 for ; Mon, 22 Jun 2009 11:55:58 -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 4515343027F for ; Mon, 22 Jun 2009 11:55:58 -0700 (PDT) Message-ID: <4A3FD3B9.4080108@joelhalpern.com> Date: Mon, 22 Jun 2009 14:55:53 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: dispatch@ietf.org References: <4A3F03F6.6060505@alcatel-lucent.com> <4A3FCF18.6020403@cisco.com> In-Reply-To: <4A3FCF18.6020403@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] Summary on Session Recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 18:55:45 -0000 I am having trouble understanding why playback is part of this at all. There appear to be two cases: 1) Playback after the call has ended. That is clearly a distinct application. Whether it is delivered by SIP, HTTP, or some other applicaiton protocol does not matter. 2) Playback during a call. That would seem to be a combination of (1) plus the general problem of inserting media from another application into an ongoing call. Again not part of the recording problem. There do seem to be ligitmate items that need work in the SIP area on enabling several different kinds of call recording. So I think there is work to be done. I am just confused by the inclusion of this dimension (other than "because someone asked for it.") Yours, Joel Paul Kyzivat wrote: > A real simple question about intended scope: > > Does this include a direct session between a UAC and a UAS whose purpose > is recording, such as for a VM system? (A VM system does seem to be a > special case of "recording on demand", and also often includes playback > facilities.) > > I had the impression that this work was more scoped toward cases where > there is an interactive session between two or more parties, and that > recording is intended to be supplemental to that. > > Thanks, > Paul > > Vijay Gurbani wrote: >> All: Here is the summary of the Session Recording thread from June 9 >> to June 19, 2009. If I misrepresented anything, please let me know. >> >> There was a fair amount of discussion on where to conduct this >> work. In the end, it was decided to continue discussions on >> dispatch, further decisions what to do -- new working group or >> put this work in an existing working group -- will be decided >> later. Regardless of where the work is done, opinions were >> expressed that the work is important that it should commence >> in the IETF. >> >> Need to be crisp about the purpose of this work: is it that users >> record sessions to hear later, or sessions need to be recorded >> because of some business needs? Or both? Is SRTP covered or >> only RTP? >> >> Solutions should cover: >> Always on recording >> Recording on demand >> Required recording >> Pause and resume recording >> Playback facilities and how they interact with recording >> Recording formats and protocols for controlling the stored recording. >> >> A lot of discussion ensued on the specific architecture or >> architectures that would be possible. No decision was reached on >> which specific architecture is good or bad, although various opinions >> were expressed in support for each. >> >> There are essentially four architectures to realize recording >> services: two that discuss where the media stream is forked >> out to the recorder -- at the UA or in a middlebox of some >> sort are outlined here: >> http://www.ietf.org/mail-archive/web/dispatch/current/msg00226.html >> >> The third architecture has both UAs sending media to a >> recorder. See: >> http://www.ietf.org/mail-archive/web/dispatch/current/msg00236.html >> >> A fourth architecture that is a superset of the third one is at: >> http://www.ietf.org/mail-archive/web/dispatch/current/msg00256.html >> >> - vijay > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From vkg@alcatel-lucent.com Mon Jun 22 12:14:38 2009 Return-Path: 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 9E9EB3A6E0F for ; Mon, 22 Jun 2009 12:14:38 -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 sxYvXI+KzUwN for ; Mon, 22 Jun 2009 12:14:37 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 8924B3A6E0A for ; Mon, 22 Jun 2009 12:14:37 -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 n5MJEfSF015863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Jun 2009 14:14:41 -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 n5MJEefY028468; Mon, 22 Jun 2009 14:14:41 -0500 (CDT) Message-ID: <4A3FD820.1080706@alcatel-lucent.com> Date: Mon, 22 Jun 2009 14:14:40 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Paul Kyzivat References: <4A3F03F6.6060505@alcatel-lucent.com> <4A3FCF18.6020403@cisco.com> In-Reply-To: <4A3FCF18.6020403@cisco.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] Summary on Session Recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 19:14:38 -0000 Paul Kyzivat wrote: > A real simple question about intended scope: > > Does this include a direct session between a UAC and a UAS whose purpose > is recording, such as for a VM system? (A VM system does seem to be a > special case of "recording on demand", and also often includes playback > facilities.) > > I had the impression that this work was more scoped toward cases where > there is an interactive session between two or more parties, and that > recording is intended to be supplemental to that. Paul: When we (i.e., the author team) had initially started this work, the latter was more of what we had in mind. 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/ From spencer@wonderhamster.org Mon Jun 22 15:14:07 2009 Return-Path: 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 E64B53A68C3 for ; Mon, 22 Jun 2009 15:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[AWL=0.267, 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 bLj+GlnzbzOX for ; Mon, 22 Jun 2009 15:14:07 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 33AA83A6B2F for ; Mon, 22 Jun 2009 15:13:52 -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-1MIrm83x7t-000fyh; Mon, 22 Jun 2009 18:14:07 -0400 Message-ID: <49720E88946A4B0CB8AAA14F343896FA@china.huawei.com> From: "Spencer Dawkins" To: "Joel M. Halpern" , References: <4A3F03F6.6060505@alcatel-lucent.com> <4A3FCF18.6020403@cisco.com> <4A3FD3B9.4080108@joelhalpern.com> Date: Mon, 22 Jun 2009 17:13:44 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit 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: V01U2FsdGVkX18Yt2Q2o9DTA+5DzoEcKzFsXCGOC5+6LnAbEwC b1ZYN3isq8VBnpE08lgP5ki+gzCfGklnHKi7mmiClAUHljom7Q zCt5Ef1qnjwb/ar7AO49tqNe4zkUADPiE/SM43NQb8= Subject: Re: [dispatch] Summary on Session Recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 22:14:08 -0000 ----- Original Message ----- From: "Joel M. Halpern" To: Sent: Monday, June 22, 2009 1:55 PM Subject: Re: [dispatch] Summary on Session Recording in SIP >I am having trouble understanding why playback is part of this at all. As am I, FWIW... > There appear to be two cases: > 1) Playback after the call has ended. That is clearly a distinct > application. Whether it is delivered by SIP, HTTP, or some other > applicaiton protocol does not matter. > > 2) Playback during a call. That would seem to be a combination of (1) > plus the general problem of inserting media from another application > into an ongoing call. Again not part of the recording problem. > > There do seem to be ligitmate items that need work in the SIP area on > enabling several different kinds of call recording. So I think there is > work to be done. I am just confused by the inclusion of this dimension > (other than "because someone asked for it.") What Joel said. Thanks, Spencer From andrew.hutton@siemens-enterprise.com Tue Jun 23 02:35:36 2009 Return-Path: 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 D0E7E3A69FA for ; Tue, 23 Jun 2009 02:35:36 -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 UZO2OdNfnaod for ; Tue, 23 Jun 2009 02:35:36 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id C7BA73A6AFE for ; Tue, 23 Jun 2009 02:35:34 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KLO0094KQNPJ7@siemenscomms.co.uk> for dispatch@ietf.org; Tue, 23 Jun 2009 10:35:49 +0100 (BST) Date: Tue, 23 Jun 2009 10:35:52 +0100 From: "Hutton, Andrew" In-reply-to: <49720E88946A4B0CB8AAA14F343896FA@china.huawei.com> To: dispatch@ietf.org Message-id: <719F9BBB3E7E71428A2D13F3D76C768F01D299CD@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] Summary on Session Recording in SIP Thread-Index: AcnzhufOWoervf5rQ6OT0xHN+HButgAXuwPw Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4A3F03F6.6060505@alcatel-lucent.com> <4A3FCF18.6020403@cisco.com> <4A3FD3B9.4080108@joelhalpern.com> <49720E88946A4B0CB8AAA14F343896FA@china.huawei.com> Subject: Re: [dispatch] Summary on Session Recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 09:35:36 -0000 Hi, I would support dropping playback from the requirements, Regards Andy=20 >-----Original Message----- >From: dispatch-bounces@ietf.org=20 >[mailto:dispatch-bounces@ietf.org] On Behalf Of Spencer Dawkins >Sent: 22 June 2009 23:14 >To: Joel M. Halpern; dispatch@ietf.org >Subject: Re: [dispatch] Summary on Session Recording in SIP > > >----- Original Message -----=20 >From: "Joel M. Halpern" >To: >Sent: Monday, June 22, 2009 1:55 PM >Subject: Re: [dispatch] Summary on Session Recording in SIP > > >>I am having trouble understanding why playback is part of this at all. > >As am I, FWIW... > >> There appear to be two cases: >> 1) Playback after the call has ended. That is clearly a distinct=20 >> application. Whether it is delivered by SIP, HTTP, or some other=20 >> applicaiton protocol does not matter. >>=20 >> 2) Playback during a call. That would seem to be a=20 >combination of (1)=20 >> plus the general problem of inserting media from another application=20 >> into an ongoing call. Again not part of the recording problem. >>=20 >> There do seem to be ligitmate items that need work in the=20 >SIP area on=20 >> enabling several different kinds of call recording. So I=20 >think there is=20 >> work to be done. I am just confused by the inclusion of=20 >this dimension=20 >> (other than "because someone asked for it.") > >What Joel said. > >Thanks, > >Spencer > >_______________________________________________ >dispatch mailing list >dispatch@ietf.org >https://www.ietf.org/mailman/listinfo/dispatch > From john.elwell@siemens-enterprise.com Thu Jun 25 00:57:20 2009 Return-Path: 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 E4E413A6CA6 for ; Thu, 25 Jun 2009 00:57:20 -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 kAEbM7BnHsWL for ; Thu, 25 Jun 2009 00:57:19 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id B818E3A6896 for ; Thu, 25 Jun 2009 00:57:19 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KLS00E4FBD6C1@siemenscomms.co.uk> for dispatch@ietf.org; Thu, 25 Jun 2009 08:55:54 +0100 (BST) Date: Thu, 25 Jun 2009 08:55:55 +0100 From: "Elwell, John" In-reply-to: <4A3F03F6.6060505@alcatel-lucent.com> To: Vijay Gurbani , dispatch@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D00210592F@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] Summary on Session Recording in SIP Thread-Index: Acny7zwVVD/FcoLORrWurPJIRHlXZQCer8bA Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4A3F03F6.6060505@alcatel-lucent.com> Subject: Re: [dispatch] Summary on Session Recording in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 07:57:21 -0000 =20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Vijay Gurbani > Sent: 22 June 2009 05:09 > To: dispatch@ietf.org > Subject: [dispatch] Summary on Session Recording in SIP >=20 > All: Here is the summary of the Session Recording thread from June 9 > to June 19, 2009. If I misrepresented anything, please let me know. >=20 > There was a fair amount of discussion on where to conduct this > work. In the end, it was decided to continue discussions on > dispatch, further decisions what to do -- new working group or > put this work in an existing working group -- will be decided > later. Regardless of where the work is done, opinions were > expressed that the work is important that it should commence > in the IETF. >=20 > Need to be crisp about the purpose of this work: is it that users > record sessions to hear later, or sessions need to be recorded > because of some business needs? Or both? Is SRTP covered or > only RTP? [JRE] Whatever architecture(s) we adopt, must allow SRTP to be used on the original call. We can then discuss various options on the recorded leg, e.g., SRTP using the same keys as the original call (i.e., without decryption and re-encryption), SRTP with separate keys, or RTP. John >=20 > Solutions should cover: > Always on recording > Recording on demand > Required recording > Pause and resume recording > Playback facilities and how they interact with recording > Recording formats and protocols for controlling the stored=20 > recording. >=20 > A lot of discussion ensued on the specific architecture or > architectures that would be possible. No decision was reached on > which specific architecture is good or bad, although various opinions > were expressed in support for each. >=20 > There are essentially four architectures to realize recording > services: two that discuss where the media stream is forked > out to the recorder -- at the UA or in a middlebox of some > sort are outlined here: > http://www.ietf.org/mail-archive/web/dispatch/current/msg00226.html >=20 > The third architecture has both UAs sending media to a > recorder. See: > =20 > http://www.ietf.org/mail-archive/web/dispatch/current/msg00236.html >=20 > A fourth architecture that is a superset of the third one is at: > =20 > http://www.ietf.org/mail-archive/web/dispatch/current/msg00256.html >=20 > - vijay > --=20 > 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 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From mary.barnes@nortel.com Thu Jun 25 15:50:46 2009 Return-Path: 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 F24A33A6A22 for ; Thu, 25 Jun 2009 15:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.301 X-Spam-Level: X-Spam-Status: No, score=-6.301 tagged_above=-999 required=5 tests=[AWL=0.298, 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 jQKR0qaJP6O3 for ; Thu, 25 Jun 2009 15:50:44 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 8D3143A68D7 for ; Thu, 25 Jun 2009 15:50:44 -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 n5PMmPo14784; Thu, 25 Jun 2009 22:48: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: Thu, 25 Jun 2009 17:51:27 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EB26BD3@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated agenda for IETF-75 thread-index: Acn153kP1X5k/+9FT4+/LlrWl8aLvQ== From: "Mary Barnes" To: Subject: [dispatch] Updated agenda for IETF-75 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 22:50:46 -0000 Hi folks, We have uploaded a revised (tentative) agenda for IETF-75 for the DISPATCH WG session: http://www.ietf.org/proceedings/09jul/agenda/dispatch.html Due to popular demand, we have added a slot for Session Recording. Note, that the current agenda has us meeting on Thursday afternoon, but Cullen has asked for that to be changed to Monday. As always, the agenda is subject to change up until the meeting. As a reminder any new documents related to the agenda topics must be submitted by July 6th and any updates to current docs by July 13th. And, most importantly we really should be seeing traffic on the list on these topics before the meeting so we can have focused discussions with conclusions and a well defined way forward.=20 Please send any comments on the proposed agenda to the list and/or Gonzalo and myself. =20 Regards, Mary DISPATCH WG co-chair From john.elwell@siemens-enterprise.com Sun Jun 28 23:46:54 2009 Return-Path: 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 BBA703A6D4F for ; Sun, 28 Jun 2009 23:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] 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 bXj7h9GmuoIe for ; Sun, 28 Jun 2009 23:46: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 EC8343A69F9 for ; Sun, 28 Jun 2009 23:46: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 <0KLZ0076SMUPTW@siemenscomms.co.uk> for dispatch@ietf.org; Mon, 29 Jun 2009 07:47:13 +0100 (BST) Date: Mon, 29 Jun 2009 07:47:11 +0100 From: "Elwell, John" To: dispatch@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D00213AF3E@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-Topic: draft-elwell-dispatch-identity-reqs-00 posted Thread-Index: Acn4hW3lRfohm/vHRqCvvi2ysTrxJg== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: [dispatch] draft-elwell-dispatch-identity-reqs-00 posted X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 06:46:54 -0000 There was an extensive discussion at IETF#74 on SIP Identity, where a = good many views were put forward. The only consensus seemed to be to = continue to discuss the topic. One of the themes during that discussion was to focus more on = requirements, which the authors have attempted to do in this new draft: http://www.ietf.org/internet-drafts/draft-elwell-dispatch-identity-reqs-0= 0.txt We would appreciate feedback as to whether this is helpful and going in = the right direction, as well as detailed comments. I had hoped to do this a lot earlier, to trigger a discussion in time to = get something set up for DISPATCH at IETF#75, but I failed, and also I = failed to talk to the many of you who have interest in the topic and = expressed opinions in the past. But since the deadline is approaching, I = thought it best to post the draft and let discussion continue on that = basis. John